1 Security Architecture Foundations

Learn how to translate stakeholder protection needs into system boundaries, threat analysis, and verifiable security architecture requirements.

Set security objectives

Secure architecture starts by deciding what the system must protect, from whom, and how its design will enforce that protection. These decisions should be made early and revisited when the system or its operating environment changes.

Security architecture describes system components, security domains, their relationships, and the mechanisms that enforce security policies. Security objectives express the outcomes stakeholders need; they guide design choices and trade-offs but are not, by themselves, implementation instructions.

Choose outcomes that fit the system

Common security objectives include:

Confidentiality: prevent unauthorized disclosure of information.
Integrity: prevent or detect unauthorized alteration or destruction.
Availability: keep systems and information accessible when needed.
Authenticity and accountability: establish who or what performed an action and preserve evidence of it.
Privacy: limit the collection, use, and disclosure of information about people.

Objectives should reflect the system’s purpose and the consequences of failure. For example, a hospital system may need to keep clinical records confidential while ensuring authorized clinicians can access them during an emergency.

Identify assets and protection needs

An is something of value that could be harmed, lost, exposed, or misused. Assets include data, services, software, credentials, cryptographic keys, infrastructure, and business processes. Identify direct assets, such as customer records, as well as supporting assets, such as the identity service needed to access those records.

For each important , record:

Its owner or responsible stakeholder.
Its value and sensitivity.
The harms that could result from disclosure, modification, loss, or unavailability.
Its location, movement, and retention needs.

This analysis turns broad objectives into protection needs. For instance, the need to protect customer records can be refined into restricted access, integrity checks, secure backups, and appropriate deletion.

Map system context and trust boundaries

A system boundary defines what is included in the system being considered. A marks a point where data or control crosses between components, users, or environments with different trust assumptions. Boundaries can be logical as well as physical: two services on the same network may have different privileges and should not automatically trust each other.

Map the system’s components, actors, data stores, data flows, and external dependencies. Describe context and boundaries through interfaces and interactions with external entities. Mark crossings such as a public client calling an API, an application querying a database, or a service sending data to a vendor.

At each crossing, make explicit decisions about authentication, authorization, validation, and protection in transit.

Analyze threats systematically

A helps teams reason about how a system could be attacked or misused before implementation makes changes expensive. A common starting point is a data-flow diagram showing actors, processes, data stores, flows, and trust boundaries.

For each component and flow, consider:

What assets are involved, and what could go wrong?
Who or what could cause harm, intentionally or accidentally?
What access, capabilities, or system weaknesses could make that harm possible?
What safeguards reduce the likelihood or impact, and what risk remains?

Record significant threats with their affected assets and components, assumptions, proposed responses, and residual risk.

Use as a prompt

is one useful prompt for technical threats. Its categories are spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It organizes threat questions; it does not guarantee that every threat has been found.

Use the categories alongside consideration of the system’s components and data flows, rather than treating the list as proof that the analysis is complete.

Turn findings into verifiable requirements

Architectural requirements state what the design must achieve and where responsibility lies. Derive them from objectives, -protection needs, system boundaries, and threat analysis. Make each requirement specific, testable, and traceable to the concern it addresses.

For example, the vague requirement “secure access to records” can be made actionable:

The records service shall authenticate every calling service before returning a record.
The authorization decision shall verify that the caller is permitted to access the requested record.
The system shall log denied access attempts with the actor, resource, and time.

Requirements can call for technical, physical, or procedural safeguards. Specify a verification method, such as a design review, configuration check, or security test. Architecture views can show how the requirements are met.

Apply the workflow to an appointment service

Consider a service where patients book appointments through a public website. Its key assets include patient identity details, appointment records, staff credentials, and service availability. Important objectives include preventing unauthorized access to records, preserving appointment accuracy, and keeping booking available.

A high-level model might include a patient browser, a public API, an appointment service, a database, a staff portal, and an external notification provider. Trust boundaries exist at the public API, between the application and database, and where appointment information is sent to the provider.

Threat analysis would consider forged requests, altered appointment data, stolen staff credentials, data exposure, and service disruption. Resulting requirements might specify authentication at each relevant interface, server-side authorization for record access, integrity-protected updates, restricted disclosures to the provider, and tested recovery procedures.

The workflow is to identify objectives and assets, map the system and its trust boundaries, analyze threats, and express safeguards as verifiable architectural requirements.

Maintain the security architecture

Security architecture translates stakeholder protection needs into system structure and requirements. Identify objectives and valuable assets, define system context and trust boundaries, model plausible threats, and convert findings into specific, testable requirements.

Revisit the analysis as the architecture, dependencies, or operating assumptions change.