This chapter covers the security architecture review process for cybersecurity analysts, focusing on how to evaluate network and system architectures against security best practices and compliance requirements. Understanding architecture review is critical for the CS0-003 exam, as approximately 10-15% of questions in Domain 4 (Reporting and Communication) assess your ability to identify architectural weaknesses and recommend improvements. You will learn the systematic approach to reviewing architectures, common pitfalls, and how to communicate findings effectively to stakeholders.
Jump to a section
A security architecture review is like a building inspection performed by a structural engineer before a renovation. The inspector doesn't just look at the paint (surface vulnerabilities) — they examine the load-bearing walls (network segmentation), the foundation (identity and access management), the electrical wiring (data flows), and the fire suppression system (incident response). They carry a blueprint (architecture diagram) and verify that each beam (security control) is rated for the expected load (threat model). They check that the fire doors (firewalls) close properly and that the sprinklers (IDS/IPS) are positioned to cover all areas. They also look for code violations (compliance gaps) like missing handrails (logging) or blocked exits (lack of redundancy). The inspector produces a report with findings (risks) prioritized by severity: red tags (critical, immediate fix), yellow tags (moderate, schedule repair), and green tags (minor, monitor). The building owner (CISO) uses this report to decide which renovations (security investments) to approve. Just as a building inspection prevents a floor from collapsing during a party, a security architecture review prevents a breach during a high-traffic period. The inspector's value is in seeing how all systems interact — a firewall might be perfect, but if it's bypassed by a rogue access point (shadow IT), the entire security posture is compromised.
What is Security Architecture Review?
A security architecture review is a systematic evaluation of an organization's IT infrastructure, applications, and security controls to identify design flaws, misconfigurations, and compliance gaps. Unlike a vulnerability scan that looks for known software bugs, an architecture review examines the overall design — how components interact, where trust boundaries exist, and whether security is 'baked in' rather than 'bolted on.' The review typically follows a framework such as the Sherwood Applied Business Security Architecture (SABSA), the Open Group Architecture Framework (TOGAF), or the NIST Cybersecurity Framework (CSF). For the CS0-003 exam, you need to understand the key components of a review: network segmentation, identity and access management (IAM), data protection, logging and monitoring, and incident response capabilities.
How an Architecture Review Works Internally
The process begins with scoping: defining the systems, networks, and applications under review. The analyst gathers documentation — network diagrams, data flow diagrams, system configuration files, and policy documents. Next, the analyst maps the architecture against a reference model, such as the NIST 800-53 control catalog or the CIS Critical Security Controls. Each control is evaluated for existence, design, and effectiveness. For example, a review might check whether network segmentation is implemented using VLANs or firewalls, whether access controls follow the principle of least privilege, and whether encryption is used for data at rest and in transit. The analyst identifies 'control gaps' — areas where a required control is missing or insufficient. These gaps are then prioritized based on risk: the likelihood of exploitation and the potential business impact. Finally, the analyst produces a report with findings, recommendations, and a remediation roadmap.
Key Components, Values, and Defaults
Network Segmentation: Look for VLANs, ACLs, and firewall rules that separate trust zones. Common defaults: Cisco VLANs use 802.1Q tagging; default ACLs often permit all traffic (e.g., Cisco ACL implicit permit).
Identity and Access Management (IAM): Check for multi-factor authentication (MFA) enforcement, role-based access control (RBAC), and least privilege. Default Windows domain groups include Domain Admins (overprivileged by default).
Data Protection: Encryption at rest (AES-256 for databases), encryption in transit (TLS 1.2/1.3), and data masking. Default TLS versions on older servers may be 1.0 or 1.1 (vulnerable).
Logging and Monitoring: Centralized logging (e.g., syslog, SIEM), log retention periods (typically 90-365 days), and alerting thresholds. Default Windows Event Log sizes are 20 MB (often too small).
Incident Response: Documented IR plan, defined roles, communication channels, and containment procedures. Default timeout for session locks: 15 minutes (e.g., Windows GPO).
Configuration and Verification Commands
Network segmentation verification: show vlan (Cisco), show access-lists, traceroute to verify path isolation.
IAM audit: net group "Domain Admins" /domain (Windows), ldapsearch (Linux) to enumerate group members.
Encryption check: openssl s_client -connect host:443 -tls1_2 (test TLS version), cipherscan (test cipher suites).
Logging configuration: show logging (Cisco), Get-EventLog -LogName Security -Newest 10 (PowerShell).
Incident response test: Conduct tabletop exercises; verify call tree with Get-ADUser -Filter * (PowerShell).
Interaction with Related Technologies
Security architecture review does not exist in a vacuum. It interacts with: - Vulnerability Management: Architecture findings may inform which vulnerabilities are most critical (e.g., a missing firewall segment increases the risk of an internal exploit). - Compliance Audits: Frameworks like PCI DSS, HIPAA, and GDPR require specific architectural controls (e.g., PCI DSS Requirement 1: firewall segmentation). - Threat Modeling: Tools like Microsoft Threat Modeling Tool or OWASP Threat Dragon identify threats based on architecture diagrams. The review validates that threats are mitigated. - Change Management: Architecture changes must go through review to avoid introducing new risks. The review process often integrates with ITIL change management.
Common Exam Traps
Trap 1: Confusing 'architecture review' with 'vulnerability scan.' An architecture review is design-level; a vulnerability scan is operational.
Trap 2: Assuming that a control exists just because it is documented. The review must verify actual configuration.
Trap 3: Overlooking the 'human element' — architecture reviews should include administrative controls like policies and training.
Trap 4: Ignoring 'shadow IT' — systems not in the official architecture (e.g., cloud instances spun up by developers) are often the weakest link.
Step-by-Step Review Process
Scoping and Documentation Gathering: Define the boundaries of the review. Collect network diagrams, data flow diagrams, system configurations, and existing security policies. Verify that diagrams are current (e.g., check last modified date).
Mapping to a Reference Model: Choose a framework (e.g., NIST 800-53, CIS Controls). Map each component to the relevant control. For example, a firewall maps to AC-4 (Access Control) and SC-7 (Boundary Protection).
Control Verification: For each mapped control, verify its existence and effectiveness. Check firewall rules against the principle of least privilege; verify that MFA is enforced for all administrative accounts.
Gap Analysis: Identify missing or insufficient controls. Prioritize gaps using a risk matrix (likelihood vs. impact). For example, missing encryption for sensitive data in transit is high risk.
Reporting and Remediation Roadmap: Document findings in a clear report with executive summary, technical details, and prioritized recommendations. Include a timeline for remediation (e.g., critical within 30 days, moderate within 90 days).
Real-World Example
Consider a company migrating from on-premises to AWS. The architecture review would check: - VPC Segmentation: Are public and private subnets properly isolated? Are NACLs and security groups configured correctly? - IAM Roles: Are EC2 instances using instance profiles with least privilege? Are root credentials avoided? - S3 Bucket Policies: Are buckets private by default? Is server-side encryption enabled? - Logging: Is CloudTrail enabled for all regions? Are logs sent to a centralized S3 bucket with MFA delete? - Incident Response: Are AWS Config rules set up to detect changes? Is there a response plan for compromised IAM keys?
A common misconfiguration is allowing all traffic from 0.0.0.0/0 to port 22 (SSH) in security groups. The review would flag this as a critical finding.
Summary
Security architecture review is a proactive, design-level assessment that complements reactive vulnerability scanning. It requires a deep understanding of network, system, and application architectures, as well as security frameworks. On the CS0-003 exam, you will be asked to identify architectural weaknesses, recommend controls, and interpret review findings. Master the key components, common defaults, and verification commands to succeed.
Scoping and Documentation Gathering
Define the boundaries of the review — which systems, networks, and applications are in scope. Collect all relevant documentation: network diagrams (logical and physical), data flow diagrams, system configuration files, and existing security policies. Verify that the documentation is current by checking timestamps or version numbers. For example, a network diagram should show all VLANs, firewalls, and routing paths. Incomplete or outdated docs are a common finding themselves. This step sets the foundation for the entire review.
Mapping to a Reference Model
Choose a security framework such as NIST SP 800-53, CIS Controls, or ISO 27001. Map each component of the architecture to the appropriate control. For instance, a firewall maps to AC-4 (Access Control) and SC-7 (Boundary Protection). An identity provider maps to IA-2 (Identification and Authentication). This mapping ensures that no control area is overlooked. The exam expects you to know which controls correspond to common components. Use a spreadsheet to track mapping.
Control Verification
For each mapped control, verify that it is implemented correctly. This involves checking actual configurations, not just documentation. For example, verify firewall rules with `show access-lists` (Cisco) or `aws ec2 describe-security-groups` (AWS). Check that MFA is enforced by reviewing IAM policies. Use automated tools where possible (e.g., Nessus for configuration auditing). Document any deviations from the expected control state.
Gap Analysis and Risk Prioritization
Identify controls that are missing or insufficient. For each gap, assess the risk using a likelihood-impact matrix. For example, missing encryption for sensitive data in transit has high likelihood (if data traverses the internet) and high impact (data breach), so it is critical. Prioritize gaps as Critical, High, Medium, or Low. The exam will test your ability to prioritize based on risk. Common gaps: no network segmentation, weak passwords, lack of logging.
Reporting and Remediation Roadmap
Produce a report with an executive summary, technical details, and a prioritized remediation plan. Include specific recommendations with timelines: critical issues within 30 days, high within 60 days, medium within 90 days. Use a standard template (e.g., SANS report format). The report should be clear enough for non-technical stakeholders (executive summary) and detailed enough for engineers (technical findings). The exam may ask you to interpret a sample report.
Scenario 1: Healthcare Provider Migrating to Cloud
A large hospital network is moving its electronic health records (EHR) system to AWS. The architecture review reveals that the VPC design uses a single public subnet for all application tiers, with security groups allowing 0.0.0.0/0 on port 443. This violates HIPAA's requirement for network segmentation (45 CFR §164.312(a)(1)). The analyst recommends creating separate public and private subnets, with the web servers in public subnets and application/database servers in private subnets. Security groups are tightened to allow only necessary traffic. Additionally, the review finds that S3 buckets containing PHI have block public access disabled. The fix is to enable 'Block all public access' and enable server-side encryption with AWS KMS. The remediation is prioritized as critical and completed within two weeks.
Scenario 2: Financial Services Firm with Legacy Network
A bank has a flat network with no segmentation between the corporate LAN and the payment card processing environment. This violates PCI DSS Requirement 1 (firewall segmentation). The architecture review identifies that all workstations can reach the cardholder data environment (CDE) directly. The recommendation is to deploy a next-generation firewall between the corporate network and the CDE, with strict ACLs allowing only necessary traffic (e.g., only specific IPs on port 443). The review also finds that administrative access to the CDE uses shared local accounts — a violation of PCI DSS Requirement 8 (unique IDs). The fix is to implement a privileged access management (PAM) solution with MFA. The remediation is scheduled over 90 days due to complexity.
Scenario 3: E-commerce Company with Microservices
A retail company uses Kubernetes for its microservices architecture. The architecture review reveals that all pods can communicate with each other without network policies — a flat pod network. This is a security risk because a compromised pod can laterally move to sensitive services (e.g., payment service). The recommendation is to implement Kubernetes Network Policies to restrict traffic based on labels and namespaces. For example, only the frontend namespace can talk to the backend namespace on port 8080. The review also finds that secrets are stored in environment variables rather than using a secrets manager like HashiCorp Vault. The fix is to migrate secrets to Vault and use sidecar containers to inject them. These changes are implemented in sprints over three months.
What CS0-003 Tests
Objective 4.1: 'Given a scenario, analyze the output of a security architecture review and recommend appropriate controls.' The exam expects you to:
Interpret network diagrams and data flow diagrams to identify security weaknesses.
Match missing controls to specific frameworks (NIST, CIS, ISO).
Prioritize findings based on risk (critical, high, medium, low).
Recommend specific controls (e.g., firewall segmentation, MFA, encryption).
Understand the difference between architecture review and vulnerability scan.
Common Wrong Answers and Why Candidates Choose Them
Wrong: 'Run a vulnerability scanner to find missing patches.' Why wrong: The question is about architecture review, not vulnerability scanning. Candidates confuse the two because both involve security assessments. But architecture review is design-level; vulnerability scanning is operational.
Wrong: 'Implement a WAF to fix the architecture issue.' Why wrong: A WAF is a tactical control, not a design fix. For example, if the network is flat, a WAF won't segment it. Candidates often suggest a single product as a silver bullet.
Wrong: 'Ignore the finding because it's low risk.' Why wrong: Even low-risk findings should be documented and addressed if they accumulate. Candidates may think low risk means no action, but the exam expects a risk-based approach.
Wrong: 'The architecture is fine because it passed a penetration test.' Why wrong: A penetration test may not cover all design flaws (e.g., lack of redundancy). Candidates over-rely on testing rather than design review.
Specific Numbers and Terms That Appear on the Exam
NIST SP 800-53 control IDs (e.g., AC-4, SC-7, IA-2).
CIS Control 3 (Data Protection), Control 12 (Boundary Defense).
PCI DSS Requirement 1 (firewall segmentation), Requirement 8 (unique IDs).
Default VLAN 1 (Cisco) — should not be used for user traffic.
Default SNMP community strings (public/private) — should be changed.
Default admin accounts (e.g., Administrator on Windows, root on Linux) — should be renamed or disabled.
Edge Cases and Exceptions
Cloud vs. On-Premises: Architecture review in the cloud focuses on IAM, security groups, and S3 policies; on-premises focuses on physical security and network segmentation.
Microservices: Network policies, service mesh, and secrets management are critical.
OT/IoT: In operational technology, architecture review must consider safety and availability over confidentiality (e.g., IEC 62443).
How to Eliminate Wrong Answers
If the answer suggests a reactive measure (e.g., 'run a scan'), it's likely wrong for a design review question.
If the answer focuses on a single technology rather than a control (e.g., 'deploy a SIEM' instead of 'implement centralized logging'), it may be too specific.
If the answer ignores the risk priority (e.g., 'fix all findings immediately'), it's unrealistic.
Always map the answer to a specific control or framework requirement.
Security architecture review evaluates design and configuration against frameworks like NIST SP 800-53 and CIS Controls.
Common findings include lack of network segmentation, weak IAM, missing encryption, and inadequate logging.
Prioritize findings using risk (likelihood x impact): critical (30-day fix), high (60-day), medium (90-day).
Always verify actual configurations, not just documentation (e.g., check firewall rules with CLI).
Cloud architecture review focuses on VPC segmentation, security groups, S3 policies, and IAM roles.
Architecture review is distinct from vulnerability scanning and penetration testing; they are complementary.
Default values (VLAN 1, SNMP public, admin accounts) are common weaknesses to flag.
These come up on the exam all the time. Here's how to tell them apart.
Architecture Review
Evaluates design and configuration
Focuses on controls like segmentation, IAM, encryption
Uses frameworks (NIST, CIS) as reference
Identifies missing or misconfigured controls
Produces a report with risk-prioritized recommendations
Vulnerability Scan
Scans for known vulnerabilities (CVEs)
Focuses on missing patches and software bugs
Uses vulnerability databases (NVD, OSVDB)
Identifies outdated software versions
Produces a list of vulnerabilities with severity scores (CVSS)
Mistake
An architecture review is the same as a vulnerability scan.
Correct
An architecture review evaluates design and configuration, not known vulnerabilities. Vulnerability scans look for missing patches or software bugs; architecture reviews look at segmentation, IAM, and encryption design. They are complementary but distinct.
Mistake
If a system passes a penetration test, its architecture is secure.
Correct
Penetration tests are point-in-time and may not cover all attack vectors (e.g., insider threats, social engineering). Architecture reviews identify design flaws that a pen test might miss, such as lack of redundancy or improper trust boundaries.
Mistake
All findings from an architecture review must be fixed immediately.
Correct
Findings should be prioritized based on risk. Critical and high findings need prompt action, but medium and low findings can be scheduled. Immediate fixes for all findings are often impractical due to resource constraints.
Mistake
Cloud architectures don't need segmentation because the provider handles it.
Correct
Cloud providers offer segmentation tools (e.g., VPCs, security groups), but it's the customer's responsibility to configure them correctly. Misconfigurations (e.g., open S3 buckets) are common and lead to breaches.
Mistake
Security architecture review is only for new systems.
Correct
Existing systems should also be reviewed periodically, especially after major changes (e.g., mergers, migrations). Continuous review ensures that security keeps pace with evolving threats and business needs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A security architecture review evaluates the design and configuration of systems against best practices and compliance frameworks, focusing on controls like segmentation, IAM, and encryption. A vulnerability assessment scans for known software vulnerabilities (CVEs) and missing patches. Architecture review is proactive and design-level; vulnerability assessment is reactive and operational. For the CS0-003 exam, understand that both are needed but serve different purposes.
Use a risk matrix with likelihood (how likely the weakness will be exploited) and impact (what damage if exploited). Critical = high likelihood + high impact (e.g., missing firewall segmentation for sensitive data). High = moderate likelihood + high impact. Medium = low likelihood + high impact or vice versa. Low = low likelihood + low impact. Remediation timelines: critical within 30 days, high within 60, medium within 90. The exam tests your ability to prioritize based on risk.
Top findings include: (1) flat network without segmentation, (2) default or weak credentials, (3) lack of MFA for administrative access, (4) unencrypted sensitive data in transit or at rest, (5) insufficient logging and monitoring, (6) missing incident response plan, (7) shadow IT (unauthorized cloud services). These appear frequently on the CS0-003 exam.
Common frameworks include NIST SP 800-53 (control catalog), CIS Critical Security Controls (prioritized actions), ISO 27001 (management standard), and PCI DSS (for payment card environments). The exam may ask you to map a finding to a specific control (e.g., 'missing firewall segmentation violates CIS Control 12' or 'no encryption violates NIST SC-8').
Use commands like `show access-lists` (Cisco) for firewall rules, `Get-ADUser` (PowerShell) for IAM, `openssl s_client` for TLS, and `aws ec2 describe-security-groups` for cloud. Also check configuration files (e.g., /etc/ssh/sshd_config for SSH settings). Automated tools (e.g., Nessus, Qualys) can help, but manual verification is often required for design-level checks.
The analyst gathers documentation, maps components to controls, verifies configurations, identifies gaps, prioritizes risks, and produces a report. They must communicate findings to both technical teams (engineers) and non-technical stakeholders (management). The exam tests your ability to interpret diagrams and recommend appropriate controls.
Reviews should be done at least annually, and also after major changes (e.g., new application deployment, cloud migration, M&A). For high-risk environments (e.g., financial services, healthcare), reviews may be quarterly. The exam may ask about the frequency based on compliance requirements (e.g., PCI DSS requires annual review of firewall rules).
You've just covered Security Architecture Review for Analysts — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?