Integrated Security Architecture and Capstone Practice

Introduction

Security architecture is the disciplined design of people, processes, technologies and governance mechanisms that protect an organisation’s information assets while enabling its mission. In practice, security decisions are rarely isolated. A firewall affects identity design; identity controls affect incident response; logging affects privacy and storage costs; and resilience requirements influence architecture, testing and budgets.

This chapter brings together the principal ideas developed in Network & Information Security. It presents a risk-based method for producing and defending an integrated security solution for a realistic organisation. The emphasis is not on selecting the largest number of security products, but on demonstrating that proposed controls are proportionate to risk, technically coherent, testable, governable, ethically defensible and financially realistic.

A professional security proposal should answer five executive questions:

1. What could harm the organisation?
2. Which assets, services and stakeholders would be affected?
3. What controls reduce the most important risks?
4. How will the organisation know whether controls work?
5. What decisions, resources and residual risks require executive acceptance?

Learning Objectives

By the end of this chapter, students should be able to:

• develop an asset-centred and risk-based security architecture;
• integrate preventive, detective, corrective and recovery controls;
• map controls to business requirements and recognised frameworks;
• design testing, monitoring and incident-response arrangements;
• evaluate cost, residual risk, ethical issues and governance obligations;
• prepare and defend an executive-level security recommendation; and
• identify limitations, assumptions and uncertainties in a capstone proposal.

1. From Isolated Controls to Integrated Architecture

A security architecture is a system of interdependent safeguards. It includes technical layers—such as identity management, network segmentation, endpoint protection, encryption, backup and monitoring—as well as administrative and physical measures. Architecture is therefore broader than infrastructure design.

A useful principle is defence in depth: compromise of one control should not automatically result in compromise of the entire organisation. For example, a stolen password should be constrained by multi-factor authentication, conditional access, least privilege, segmentation, endpoint detection and monitored activity. Defence in depth is not the same as uncontrolled duplication. Controls should have distinct purposes and should be maintained according to their risk value.

A second principle is secure by design. Security requirements should be identified during business and system design rather than added after deployment. This includes data classification, threat modelling, privacy analysis, resilience requirements and secure defaults.

A third principle is zero trust. Zero trust does not mean that trust is impossible; it means that access is not granted solely because a user or device is inside a network boundary. Access decisions should consider identity, device condition, resource sensitivity, requested action and contextual risk. Authentication and authorisation should be continuously evaluated where proportionate.

Architectural layers

A sound architecture aligns these layers with business processes. For example, a payment process may require strong transaction authentication, segregation of duties, immutable audit records and tested recovery—not merely an additional network firewall.

Figure: An integrated architecture links business risk to prevention, detection, response and continuous improvement.

2. Risk-Based Design Method

A capstone solution should begin with the organisation’s mission and risk context, not with a preferred technology. The following sequence is suitable for a medium-sized organisation:

Step 1: Establish scope and assumptions

Define business units, locations, systems, data flows, third parties, legal jurisdictions and time horizon. State what is excluded. Explicit assumptions—such as cloud responsibility, staffing levels and recovery-site availability—make later conclusions defensible.

Step 2: Identify assets and business services

An asset is something of value, whereas a business service is an outcome the organisation must deliver. Examples include customer payments, clinical scheduling, payroll, manufacturing control and public web services. Service mapping reveals dependencies that an inventory alone may miss.

Step 3: Classify information

A practical classification scheme may contain public, internal, confidential and restricted categories. Classification should drive handling rules, access requirements, retention, encryption and disposal. Labels without enforceable handling procedures provide little protection.

Step 4: Model threats and vulnerabilities

Threats are potential causes of harm; vulnerabilities are weaknesses that can be exploited or triggered. Threat modelling can use attack trees, misuse cases, data-flow diagrams or STRIDE-style categories. Consider external attackers, insiders, suppliers, accidental errors, environmental events and technology failure.

Step 5: Assess risk

Risk assessment should combine likelihood, impact and uncertainty. A simple qualitative matrix is useful for prioritisation, but it should not be mistaken for precise prediction. Where data supports it, annualised loss expectancy can be estimated as:

Here, ALE is annualised loss expectancy in currency per year, SLE is single-loss expectancy in currency per event, and ARO is annual rate of occurrence in events per year. The expression assumes that loss events can be reasonably represented by an estimated average frequency and average impact. It is not reliable when event dependencies, catastrophic uncertainty or intangible impacts dominate.

For example, if a service outage is estimated to cost $40,000 per event and is expected 0.5 times per year, then:

ALE = $40,000 × 0.5 = $20,000 per year.

This is an estimate, not a guaranteed saving. A control costing $8,000 annually may be economically attractive if it substantially reduces this exposure, but implementation, residual risk and non-financial obligations must also be considered.

Step 6: Select and prioritise controls

Controls should be selected according to risk reduction, feasibility, dependencies and compliance requirements. A control may be preventive, detective, corrective, deterrent, compensating or recovery-oriented. Prioritisation should consider:

• reduction of high-impact attack paths;
• protection of safety, rights and essential services;
• reduction of common exploitable weaknesses;
• implementation effort and operational capacity;
• measurable effectiveness; and
• residual risk after implementation.

Step 7: Document residual risk

No architecture eliminates all risk. Residual risk is the risk remaining after controls. It should be assigned to an accountable owner, expressed in understandable terms and accepted only by an authority with suitable responsibility. “The system is secure” is not an acceptable risk statement; “the organisation accepts a low-probability interruption of the supplier portal because no affordable control reduces it further” is more meaningful.

3. Control Integration and Framework Alignment

Frameworks provide a common language, not an automatic security solution. The NIST Cybersecurity Framework 2.0 groups outcomes under Govern, Identify, Protect, Detect, Respond and Recover. ISO/IEC 27001 provides requirements for an information security management system. CIS Controls offer prioritised technical and operational practices. These approaches can be mapped rather than treated as competitors.

A control traceability matrix is useful:

The matrix prevents a common failure: describing a control without identifying who operates it, what evidence proves operation, or how effectiveness is tested.

4. Security Testing, Monitoring and Metrics

Testing should be risk-based and layered. Configuration reviews and vulnerability scanning provide breadth; penetration testing examines selected attack paths; code review and dependency analysis address application risk; tabletop exercises test decision-making; restore tests test recoverability. A penetration test cannot prove that a system is secure, and a clean vulnerability scan does not demonstrate effective incident response.

A test plan should define scope, authorisation, safety constraints, evidence handling, escalation and remediation tracking. Testing production systems without explicit authority can cause outages and may be unlawful.

Monitoring design

Monitoring should collect events that support a decision or response. Typical sources include identity providers, firewalls, endpoints, cloud control planes, applications, databases and physical access systems. Centralisation is valuable, but indiscriminate collection creates cost, privacy and analysis problems.

Useful metrics distinguish activity from outcomes:

• percentage of critical assets inventoried;
• percentage of privileged accounts protected by MFA;
• critical vulnerabilities beyond service-level target;
• median time to detect and median time to contain incidents;
• percentage of successful backup restoration tests;
• false-positive rate for high-priority alerts; and
• completion and effectiveness of security training.

Metrics require definitions. For example, mean time to detect depends on the starting point selected and may be distorted by late discovery. Dashboards should therefore show scope, data source, period, denominator and limitations.

5. Incident Response and Resilience

Incident response is an organisational capability, not merely a technical procedure. A practical lifecycle includes preparation; detection and analysis; containment; eradication; recovery; and lessons learned. Legal, communications, privacy, human-resources and executive roles should be defined before a crisis.

Playbooks should address likely scenarios such as ransomware, compromised privileged accounts, data exposure, denial of service and supplier compromise. Each playbook should specify decision points, evidence preservation, authority to isolate systems, notification criteria and recovery validation.

Business continuity and disaster recovery are related but distinct. Continuity preserves critical business functions; disaster recovery restores technology and data. Two common requirements are:

• Recovery time objective (RTO): maximum targeted time to restore a service after disruption.
• Recovery point objective (RPO): maximum targeted amount of data loss measured in time.

An RPO of 15 minutes means the organisation targets no more than approximately 15 minutes of data loss; it does not guarantee zero loss. RTO and RPO must be technically achievable and tested. Backups should be protected from the same compromise as production systems, with access separation, appropriate encryption and periodic restoration tests.

6. Governance, Ethics and Regulation

Governance allocates authority and accountability. A security steering committee may approve priorities, while asset owners accept operational risk and security specialists advise, implement and assure. Separation of duties is important in high-impact activities such as approving access, deploying code and reviewing audit evidence.

Ethical security practice requires:

• informed authorisation for testing and monitoring;
• proportional collection and retention of personal information;
• transparency about surveillance and automated decisions;
• protection of vulnerable users and non-discrimination;
• responsible vulnerability disclosure; and
• preservation of confidentiality during investigations.

Privacy principles commonly include purpose limitation, data minimisation, accuracy, retention control, security and accountability. Regulatory duties vary by jurisdiction and sector; therefore, a proposal should identify applicable laws and obtain specialist legal advice rather than claim universal compliance. Compliance is a baseline obligation, not proof that risk is acceptably managed.

Artificial intelligence may assist alert triage, anomaly detection, control analysis and drafting. However, models can produce false positives, expose sensitive data, encode bias or generate unreviewable decisions. Human accountability, access restrictions, validation data, logging and an appeal or override process are necessary when AI influences security or employment decisions.

7. Cost-Constrained Executive Decision-Making

A credible recommendation distinguishes one-time expenditure, recurring operating expenditure, staffing, training, integration and opportunity cost. A low licence price may conceal migration, tuning and skilled-person requirements. Conversely, a modest process improvement—such as removing dormant privileged accounts—may reduce risk more than an expensive product.

A useful business case compares options rather than presenting a single predetermined solution:

Executive recommendations should state the decision requested, expected risk reduction, dependencies, implementation phases, success measures and risks that remain. They should avoid unexplained technical jargon and false precision.

8. Illustrative Capstone Case: Northbridge Community Health Network

This is a fictional illustrative case. Northbridge Community Health Network (NCHN) operates three clinics, a telehealth service and a small diagnostic laboratory. It employs 420 people and relies on a cloud-based electronic health record, internet-facing appointment services, medical devices, email and several specialist suppliers. The board has approved a security programme but has limited funds for the first year.

Background and problem

NCHN recently experienced a phishing incident in which an employee’s mailbox was accessed for two days. No confirmed clinical-record disclosure was found, but the organisation could not quickly determine which messages had been viewed. Backups exist, yet restoration has never been tested. Medical devices run a mixture of supported and legacy operating systems. The chief executive wants improved assurance without interrupting clinical care.

Analysis

The most important services are clinical care, emergency communications, appointment scheduling, laboratory reporting and payroll. The highest risks are:

1. identity compromise leading to access to patient information;
2. ransomware affecting clinical systems and shared files;
3. exploitation of legacy medical devices;
4. supplier or cloud-account compromise; and
5. inability to establish facts during a privacy incident.

The impact includes patient harm, service interruption, legal exposure, loss of trust and financial cost. The analysis also identifies constraints: a small security team, limited maintenance windows, dependence on suppliers and strict confidentiality obligations.

Proposed architecture and controls

NCHN should first establish a reliable asset and data-flow inventory. All workforce accounts should use phishing-resistant MFA where supported, with conditional access based on device health and sign-in risk. Privileged accounts should be separate from ordinary user accounts and subject to just-in-time or time-limited elevation.

Clinical, administrative, laboratory and guest networks should be segmented. Legacy devices should be placed in restricted zones with only documented required communication paths. Unsupported devices should have compensating controls, a replacement plan and explicit risk ownership rather than indefinite informal exemption.

Endpoints should use centrally managed protection, secure configuration baselines and prioritised patching. Internet-facing services should use web application protection, secure development practices and independent testing. Sensitive data should be encrypted in transit and at rest where appropriate, with key management separated from ordinary administrator access.

Logs from identity, endpoint, cloud, firewall and critical applications should be sent to a managed monitoring service. Collection should be minimised to operational and investigative needs, with defined retention and access controls. Alerts should prioritise impossible travel, suspicious mailbox rules, mass file encryption, privilege escalation and unusual data transfer.

NCHN should maintain offline or immutable backups, test restoration quarterly and define RTOs and RPOs with clinical owners. An incident-response team should include IT, clinical operations, privacy, legal, communications and executive decision-makers. A phishing exercise should be conducted ethically, without shaming individuals or collecting unnecessary personal data.

Phased implementation

First 90 days: inventory critical services; enforce MFA for administrators and remote access; disable dormant accounts; protect email; establish incident contacts; isolate the highest-risk legacy devices; and test a representative backup restoration.

Three to nine months: implement segmentation, endpoint detection, central logging, vulnerability prioritisation, privileged access management and supplier-risk reviews. Conduct a tabletop ransomware exercise and an authorised penetration test of public services.

Nine to eighteen months: replace unsupported devices where feasible, mature data classification, automate access reviews, improve resilience testing and integrate security metrics into board reporting.

Cost and outcome assessment

The first phase deliberately prioritises controls with broad risk reduction and relatively low disruption. NCHN should not purchase a complex security platform before assigning staff to tune alerts and respond to them. Success measures include 100% MFA coverage for privileged and remote accounts, documented critical assets, tested restoration within agreed targets, reduced critical vulnerability exposure and measured incident-response performance.

Residual risks remain around legacy devices, supplier dependency and clinical availability during containment. The board should formally accept, transfer or fund treatment of these risks. The recommendation is therefore not that NCHN becomes “secure,” but that it obtains materially stronger protection, evidence of control operation and a transparent basis for further investment.

Learning points

The case demonstrates that architecture begins with services and consequences. It also shows why controls must be integrated: MFA without monitoring may delay detection; backups without restoration tests may be unusable; segmentation without asset knowledge may interrupt care; and compliance statements without evidence do not provide assurance.

Challenges and Limitations

Risk estimates are uncertain, especially for rare catastrophic events. Qualitative matrices can hide disagreement behind colours, while quantitative estimates may create false confidence. Framework mappings can become checklist exercises if they are not linked to real services and evidence. Security controls may introduce usability burdens, excessive surveillance or safety risks. Third-party assurances may be incomplete, and cloud customers may misunderstand the shared-responsibility model.

A capstone proposal should therefore state assumptions, identify evidence gaps, propose validation activities and explain what would change the recommendation. Professional judgement includes knowing when available evidence is insufficient.

Best-Practice Checklist for a Capstone Defence

Before presenting a solution, confirm that it:

• identifies critical services, assets, data and dependencies;
• connects each major control to a specific risk;
• names owners, evidence and testing methods;
• includes identity, network, endpoint, data, monitoring and recovery measures;
• addresses people, suppliers, governance and privacy;
• distinguishes target state from first-phase priorities;
• explains cost, staffing and operational constraints;
• records residual risks and acceptance authority;
• defines measurable outcomes; and
• communicates clearly to both technical and executive audiences.

Chapter Summary

Integrated security architecture aligns business objectives, risk appetite, technology, people and governance. A defensible design begins with scope, services, assets, data classification and threat analysis. Risk assessment supports prioritisation, but estimates must disclose assumptions and uncertainty. Effective architecture combines preventive, detective, responsive and recovery controls through defence in depth, least privilege, segmentation, secure design and context-aware access.

Frameworks such as NIST Cybersecurity Framework 2.0, ISO/IEC 27001 and CIS Controls can organise and communicate a programme, but they do not replace judgement or evidence. Testing must include technical controls, procedures, restoration and decision-making. Monitoring should produce actionable evidence, while incident response requires cross-functional authority and rehearsed playbooks. Governance determines ownership and risk acceptance; ethical practice protects privacy, fairness and safety. Finally, executive recommendations should compare options, disclose costs and residual risks, and propose phased, measurable implementation.

Key Terms

Asset: Something of value that requires protection.

Business continuity: Capability to continue critical functions during and after disruption.

Control: A safeguard or measure that modifies risk.

Defence in depth: Use of multiple, complementary security layers.

Incident response: Coordinated capability to detect, contain, eradicate and recover from incidents.

Least privilege: Granting only the access necessary for an authorised task.

Residual risk: Risk remaining after controls are applied.

Risk appetite: The amount and type of risk an organisation is willing to pursue or retain.

Risk assessment: Process of identifying, analysing and evaluating risk.

Recovery point objective: Target maximum time-equivalent amount of data loss after disruption.

Recovery time objective: Target maximum time to restore a service after disruption.

Security architecture: Structured design of security capabilities, relationships and responsibilities.

Segmentation: Dividing systems or networks to constrain access and movement.

Security information and event management: Technology and processes for collecting, correlating and analysing security events.

Single-loss expectancy: Estimated loss from one occurrence of a risk event.

Annualised loss expectancy: Estimated average annual loss, calculated as SLE × ARO under stated assumptions.

Threat modelling: Structured analysis of threats, attack paths and mitigations.

Zero trust: Security approach that avoids implicit trust based solely on network location.

Review Questions

Short Answer Questions

1. What distinguishes a security architecture from a collection of security products?
2. Define residual risk and explain who should accept it.
3. State the difference between RTO and RPO.
4. Why should security metrics include definitions and data sources?
5. Give two ethical requirements for security monitoring.

Long Answer Questions

1. Explain how an organisation can move from business services to a risk-based security architecture.
2. Compare the purposes and limitations of vulnerability scanning, penetration testing and tabletop exercises.
3. Discuss how identity, segmentation, monitoring and recovery controls work together against ransomware.
4. Explain how governance and framework alignment support—but do not replace—security assurance.
5. Develop a phased security programme for a resource-constrained organisation and justify its priorities.

Analytical / Application Questions

1. An organisation estimates a loss of $60,000 per incident and an occurrence rate of 0.25 per year. Calculate ALE and explain why the result should not be treated as a guaranteed saving.
2. A hospital wants to place unsupported medical devices on the same network as administrative laptops to reduce management effort. Analyse the security, safety and governance consequences and recommend an alternative.
3. Design a control traceability matrix for a cloud payroll service covering identity compromise, data leakage and service outage. Include owners, evidence and testing frequency.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a risk-based security architecture?

A. It selects the maximum number of available security products.

B. It aligns controls with business services, threats, impacts and constraints.

C. It relies exclusively on perimeter firewalls.

D. It treats regulatory compliance as proof that all risk is eliminated.

Correct Answer: B. It aligns controls with business services, threats, impacts and constraints.

Question 2

An event has a single-loss expectancy of $40,000 and an annual rate of occurrence of 0.5. What is its ALE?

A. $8,000 per year

B. $20,000 per year

C. $40,000 per year

D. $80,000 per year

Correct Answer: B. $20,000 per year

Question 3

What does an RPO of 15 minutes primarily specify?

A. The maximum targeted time to restore a service

B. The maximum targeted number of users during recovery

C. The maximum targeted time-equivalent data loss

D. The maximum time allowed for vulnerability scanning

Correct Answer: C. The maximum targeted time-equivalent data loss

Question 4

Which control most directly limits the damage caused by a compromised ordinary user account?

A. Least privilege and network segmentation

B. Increasing public website bandwidth

C. Removing all system logs

D. Allowing shared administrator accounts

Correct Answer: A. Least privilege and network segmentation

Question 5

Why is a backup restoration test necessary?

A. A backup inventory automatically proves recoverability.

B. It verifies that data and procedures can restore service within agreed objectives.

C. It eliminates the need for incident response.

D. It guarantees that no data will ever be lost.

Correct Answer: B. It verifies that data and procedures can restore service within agreed objectives.

Question 6

Which activity is primarily a detective control?

A. Encrypting a database

B. Applying a secure configuration baseline

C. Analysing identity and endpoint events in a SIEM

D. Restricting access using MFA

Correct Answer: C. Analysing identity and endpoint events in a SIEM

Question 7

What is the main governance purpose of assigning a residual-risk owner?

A. To ensure someone is accountable for deciding whether remaining risk is acceptable.

B. To guarantee that the risk has been eliminated.

C. To transfer all technical work to the auditor.

D. To avoid documenting assumptions.

Correct Answer: A. To ensure someone is accountable for deciding whether remaining risk is acceptable.

Question 8

Which statement about zero trust is most accurate?

A. It means all internal traffic is automatically trusted.

B. It eliminates the need for authentication after a user enters the network.

C. It evaluates access using identity, resource sensitivity and context rather than location alone.

D. It requires every organisation to operate without a network perimeter.

Correct Answer: C. It evaluates access using identity, resource sensitivity and context rather than location alone.

Question 9

Which option is an ethical requirement for security testing?

A. Testing without authorisation to obtain realistic results

B. Publishing personal data discovered during testing

C. Defining scope, authority and safety constraints before testing

D. Deleting evidence immediately after finding a vulnerability

Correct Answer: C. Defining scope, authority and safety constraints before testing

Question 10

Which is the strongest executive recommendation?

A. Purchase the most advanced tool available immediately.

B. State the requested decision, expected risk reduction, costs, dependencies and residual risks.

C. Report only the number of products installed.

D. Promise that the organisation will become completely secure.

Correct Answer: B. State the requested decision, expected risk reduction, costs, dependencies and residual risks.