Understanding Security Architecture And Engineering

Introduction

Security architecture and security engineering are closely related disciplines within cybersecurity. They provide the principles, structures, methods, and engineering practices needed to design, build, implement, operate, and maintain secure systems.

Security architecture establishes the structure and design of security, while security engineering applies engineering principles to realize that security in practice. Although they have different areas of focus, they work together to ensure that security requirements are translated into practical and maintainable security capabilities.

Understanding security architecture and engineering requires an understanding of architecture, engineering, security principles, system design, security controls, trust, assurance, and the methods used to evaluate and maintain security.

Foundations of Architecture and Engineering

What Is an Architecture?

Architecture is the structured description and design of a system, including its components, relationships, principles, boundaries, and interactions.

An architecture provides a way to understand how the different elements of a system fit together and how they collectively achieve defined objectives.

Architecture is not simply a diagram or collection of technologies. It represents the structure, relationships, principles, and decisions that shape a system.

An architecture commonly addresses:

• Components and their responsibilities
• Relationships between components
• Interfaces and interactions
• Dependencies
• Boundaries
• Constraints
• Design principles
• Requirements
• Design decisions

Architecture therefore provides a foundation for understanding and designing complex systems in a structured manner.

What Is Engineering?

Engineering is the systematic application of scientific, mathematical, technical, and practical knowledge to design, build, implement, operate, maintain, and improve systems.

Engineering transforms concepts and requirements into working solutions.

It involves activities such as:

• Understanding requirements
• Designing solutions
• Selecting appropriate technologies
• Building and integrating components
• Testing and verification
• Deployment
• Operation and maintenance
• Troubleshooting
• Optimization
• Continuous improvement

Engineering is therefore concerned not only with creating something, but also with ensuring that the resulting system performs its intended functions reliably and safely within defined constraints.

Architecture and engineering are closely related. Architecture establishes the structure and design direction, while engineering applies technical knowledge to realize and sustain that design.

What Is Security Architecture?

Security architecture is the structured design of security within a system. It defines how security principles, requirements, controls, technologies, components, and relationships are organized to protect assets and achieve security objectives.

Security architecture considers questions such as:

• What needs to be protected?
• What security objectives must be achieved?
• What threats and risks must be addressed?
• What security requirements should be established?
• Where should security controls be applied?
• How should security components interact?
• How should trust be established and maintained?
• How should security be integrated across different layers and domains?

Security architecture provides the security structure and design direction from which secure solutions can be developed.

It can be applied to many types of systems, including information systems, applications, networks, cloud environments, computing platforms, data environments, identity systems, communication systems, operational technology, and embedded and connected systems.

The purpose is not simply to add security components to a system. It is to integrate security into the architecture of the system itself.

What Is Security Engineering?

Security engineering is the application of engineering principles and practices to design, build, implement, integrate, test, operate, maintain, and improve security capabilities.

Security engineering turns security requirements and architectural designs into functioning security mechanisms and controls.

It can involve:

• Designing secure components
• Implementing security controls
• Configuring security mechanisms
• Integrating security technologies
• Establishing secure interfaces
• Testing security functions
• Verifying security requirements
• Monitoring and maintaining security mechanisms

Security engineering therefore provides the technical realization of security architecture.

A security architecture may specify that access must be strongly authenticated and appropriately authorized. Security engineering determines how those requirements are technically implemented, integrated, tested, and maintained.

Relationship Between Security Architecture and Security Engineering

Security architecture and security engineering are distinct but interdependent.

Security architecture defines the intended security structure and design. Security engineering realizes that design through technical implementation and continuous engineering activities.

Security architecture focuses on structure, principles, requirements, relationships, boundaries, and design decisions. Security engineering focuses on turning those decisions into functioning capabilities through implementation, integration, configuration, testing, operation, and maintenance.

Security Architecture	Security Engineering
Defines security structure	Builds security solutions
Establishes principles	Applies engineering principles
Defines security requirements	Implements requirements
Designs security controls	Implements and integrates controls
Defines relationships and boundaries	Builds and configures components
Provides architectural direction	Provides technical realization
Evaluates architectural choices	Tests and validates implementations

The relationship is not strictly one-directional. Engineering experience can identify implementation constraints, integration problems, performance considerations, or other technical factors that may require architectural decisions to be reviewed or refined.

Architecture and engineering therefore form a continuous relationship between design and realization.

Why Security Architecture and Engineering Matter

Security architecture and engineering provide a systematic approach to building security into systems rather than treating security as an isolated or late-stage activity.

They help establish consistent security principles, clear requirements, structured designs, appropriate control placement, defined trust relationships, secure component interactions, and mechanisms for verification and resilience.

Without architectural thinking, security mechanisms can become fragmented and disconnected. Without engineering, architectural principles and designs cannot become functioning security capabilities.

Together, architecture and engineering help transform security objectives into structured, implementable, and verifiable security solutions.

Objectives of Security Architecture and Engineering

The primary objective is to ensure that security is systematically considered throughout the design and engineering of systems. These objectives provide a common direction for architectural decisions and engineering activities.

Protect Information and Resources

Security architecture and engineering protect information, systems, services, and other resources against unauthorized access, disclosure, modification, destruction, misuse, and disruption.

Protection begins by understanding what requires protection and the security properties that need to be preserved. These requirements influence architectural boundaries, component relationships, access mechanisms, information flows, and other security decisions.

Important considerations include:

• Identifying resources that require protection
• Defining appropriate protection requirements
• Protecting information, components, and interfaces
• Supporting detection and response when protection fails

Security architecture establishes how protection is structured, while security engineering implements and maintains the mechanisms that provide it.

Establish Security Requirements

Security requirements translate security objectives, risks, policies, and system needs into defined requirements that guide architecture and engineering.

They establish what security properties the system should provide and create a basis for design decisions, control selection, implementation, and verification. Clear requirements also provide criteria against which security can later be evaluated.

Security requirements may address confidentiality, integrity, availability, authentication, authorization, accountability, privacy, resilience, monitoring, and recovery.

The quality of security architecture and engineering depends significantly on whether these requirements are sufficiently clear, relevant, and aligned with the system’s security objectives.

Integrate Security

Security should be integrated into the architecture, components, interfaces, processes, and operational mechanisms of a system rather than added as a separate layer after the system has been designed.

Integration requires consideration of how security capabilities interact with functional components and with one another. A control that operates effectively in isolation may not provide the intended protection if its dependencies, interfaces, or surrounding architecture are not properly designed.

Key considerations include:

• Integrating security into system design
• Coordinating controls across architectural layers
• Protecting interfaces and boundaries
• Managing dependencies between security mechanisms

Security architecture establishes how security capabilities fit together, while engineering implements and integrates those capabilities.

Manage Trust

Security architecture and engineering must establish and manage appropriate trust relationships between entities that interact with a system.

Trust may exist between users, systems, applications, devices, services, processes, and other components. These relationships should be explicitly considered because excessive or poorly defined trust can create security weaknesses.

Trust management includes defining trust boundaries, establishing authentication and authorization requirements, limiting unnecessary trust, and validating conditions that influence whether trust should be maintained.

Architecture determines where and how trust is established, while engineering implements the mechanisms used to establish, enforce, and maintain those relationships.

Apply Security Controls

Security controls provide safeguards and countermeasures that address security requirements and risks.

Security architecture determines how controls fit into the overall design, including their placement, relationships, dependencies, and interactions. Security engineering then turns these decisions into functioning mechanisms through implementation, configuration, integration, testing, and maintenance.

Key considerations include:

• Selecting appropriate controls
• Designing effective control placement
• Integrating related controls
• Testing and verifying control operation

Security controls should therefore be considered as part of the overall security architecture rather than as isolated mechanisms.

Reduce Security Risk

Security architecture and engineering should identify and address weaknesses, vulnerabilities, threats, and architectural risks that could affect systems, information, services, and other protected resources.

Risk reduction involves understanding potential security problems and applying appropriate architectural and engineering measures to reduce their likelihood or impact. This includes considering weaknesses in design, implementation, configuration, interfaces, dependencies, trust relationships, and security controls.

Important considerations include:

• Identifying weaknesses, vulnerabilities, and threats
• Reducing unnecessary exposure and attack surface
• Addressing architectural and implementation weaknesses
• Evaluating remaining security risk

Security architecture reduces risk through structural and design decisions, while security engineering implements, integrates, tests, and maintains the mechanisms used to manage those risks.

Support Resilience

Security architecture and engineering should enable systems to withstand, respond to, recover from, and adapt to failures, attacks, and disruptive events.

Resilience considers not only prevention but also the ability of a system to continue required functions or restore them when security protections, components, dependencies, or supporting capabilities are affected.

Resilience may involve redundancy, fault tolerance, isolation, recovery mechanisms, backup and restoration, dependency management, and appropriate failure handling.

Architecture determines how resilience is incorporated into the system, while engineering implements and validates the mechanisms that support continued operation and recovery.

Enable Verification and Assurance

Security architecture and engineering should provide evidence that security requirements, designs, controls, and implementations achieve their intended security properties.

Verification focuses on determining whether defined requirements have been correctly implemented. Assurance provides confidence that security mechanisms and processes can be relied upon to provide the expected protection.

Activities may include architecture reviews, requirements reviews, design analysis, security testing, control validation, configuration verification, and independent evaluation.

Verification and assurance therefore help identify gaps between intended security and actual security and provide evidence that security objectives have been addressed.

Support Continuous Improvement

Security architecture and engineering should support the ongoing improvement of security throughout the system lifecycle.

Systems, technologies, dependencies, requirements, threats, vulnerabilities, and operating conditions can change over time. Security therefore needs to be periodically reviewed and improved rather than treated as a fixed property established only during initial design.

Continuous improvement may involve reviewing architectural decisions, reassessing requirements, updating controls, addressing vulnerabilities, improving security mechanisms, re-evaluating trust relationships, and incorporating lessons from testing and security events.

Continuous improvement keeps security architecture and engineering aligned with changing system characteristics and security requirements.

Ultimately, security architecture provides the security blueprint, while security engineering provides the technical realization. Both are essential for developing systems in which security is deliberately designed, systematically implemented, verified, and continuously maintained.

Core Principles of Security Architecture and Engineering

Security architecture and engineering are guided by a set of principles that help shape how security is designed, implemented, and maintained within a system. These principles provide general guidance for making security decisions and help ensure that security mechanisms work together as part of the overall system rather than operating as isolated controls.

Some principles primarily influence architectural decisions, while others have a stronger engineering focus. Many, however, apply to both. Architecture uses these principles to establish structure, boundaries, relationships, requirements, and security decisions, while engineering applies them when implementing, integrating, testing, operating, and maintaining the resulting security capabilities.

Defense in Depth

Defense in depth is the use of multiple layers of complementary security controls so that the failure or compromise of one control does not automatically result in the compromise of the entire system.

Different layers may provide preventive, detective, corrective, or recovery capabilities. For example, access control, network segmentation, endpoint protection, monitoring, and recovery mechanisms can provide different forms of protection.

The principle reduces dependence on any single security mechanism and helps limit the impact of a control failure or successful attack.

Least Privilege

Least privilege requires a subject, process, application, device, or other entity to have only the permissions and access necessary to perform its intended function.

Providing unnecessary privileges increases the potential impact of misuse, compromise, or error. Least privilege therefore limits what an entity can access and what actions it can perform.

The principle applies to users as well as technical components and services. Architecture establishes appropriate access relationships and trust boundaries, while engineering implements them through permissions, roles, access controls, privilege management, and other mechanisms.

Separation of Duties

Separation of duties divides sensitive responsibilities among different individuals, roles, processes, or components so that a single entity does not have complete control over a critical activity.

The separation can reduce the possibility of unauthorized actions and provide opportunities for independent approval, review, or verification.

For example, the person who requests a sensitive change may be different from the person who approves it, while the person responsible for auditing the activity may have a separate role.

Complete Mediation

Complete mediation requires access to protected resources to be checked according to the applicable security policy whenever access occurs.

A previous authorization decision should not automatically be assumed to remain valid if the relevant security conditions can change.

This principle helps ensure that security enforcement remains effective throughout the operation of a system rather than relying solely on an earlier access decision.

Fail-Safe Defaults

Fail-safe defaults means that access should be denied unless an explicit security policy or authorization permits the requested operation.

This principle establishes a secure default condition when a security decision is unavailable, incomplete, or ambiguous.

It is particularly important when designing access-control mechanisms because an error or absence of an explicit permission should not unintentionally result in access being granted.

Economy of Mechanism

Economy of mechanism emphasizes keeping security mechanisms as simple and focused as practical.

Unnecessary complexity can make security mechanisms more difficult to understand, analyze, test, verify, operate, and maintain. Complex designs can also introduce additional dependencies and opportunities for implementation errors.

The principle does not mean that every system must be simple. Rather, security mechanisms should avoid unnecessary complexity and should provide only the functionality required by their intended purpose.

Minimize Attack Surface

Minimizing attack surface involves reducing unnecessary interfaces, services, functionality, privileges, connections, and other points through which a system could potentially be attacked or misused.

Every exposed component or interface may introduce additional security requirements and potential weaknesses. Reducing unnecessary exposure can therefore simplify the security architecture and reduce potential attack paths.

Attack surface reduction should be considered during architecture and design as well as during implementation and operation.

Isolation

Isolation separates components, processes, resources, users, or security domains so that an issue affecting one area does not unnecessarily affect another.

Isolation can limit the spread of compromise, restrict access to sensitive resources, separate different trust levels, and contain failures.

It can be implemented through architectural boundaries as well as technical mechanisms such as process isolation, virtualization, segmentation, and controlled access between security domains.

Secure by Design

Secure by Design means that security is considered as an integral part of system architecture and design rather than being added after the system has already been designed.

Security requirements should influence architectural decisions, component selection, interfaces, information flows, trust relationships, and control placement from the beginning.

This approach helps address security concerns at the design level, where fundamental architectural decisions can have a significant influence on the security of the resulting system.

Secure by Default

Secure by Default means that a system should provide an appropriate level of security under its initial or default configuration without requiring extensive security changes before basic protection is established.

Unnecessary services, permissions, interfaces, and functionality should not be enabled without a defined requirement.

Secure defaults reduce the likelihood that a system will remain unnecessarily exposed because security configuration was overlooked during deployment or operation.

Continuous Verification

Continuous verification recognizes that security conditions can change throughout the lifecycle and operation of a system.

Changes in identity, device state, system configuration, network conditions, resource sensitivity, vulnerabilities, or other factors can affect whether a previously acceptable security decision remains appropriate.

Verification should therefore be performed at appropriate points rather than relying exclusively on a single initial assessment or authorization decision.

These principles provide a common foundation for security architecture and security engineering. They influence how systems are structured, how security requirements are translated into designs, how controls are implemented, and how security is maintained throughout the system lifecycle.

CIA Triad: Foundation of Security Architecture and Engineering

The CIA triad represents three fundamental security objectives: Confidentiality, Integrity, and Availability. These objectives provide a foundation for defining security requirements and designing security controls within information systems.

Security architecture uses the CIA triad to determine the security properties that a system, component, or information resource must protect. Security engineering then translates those requirements into mechanisms and controls that can be implemented, tested, operated, and maintained.

Confidentiality

Confidentiality is the protection of information against unauthorized access or disclosure.

A system provides confidentiality when information is accessible only to subjects or entities that are authorized to access it. Confidentiality requirements therefore influence how information is classified, where it is stored, how it is transmitted, and who or what is permitted to access it.

Confidentiality can be supported through mechanisms such as:

• Access control
• Authentication and authorization
• Encryption
• Information classification
• Secure communication

Security architecture establishes the boundaries, trust relationships, and access requirements needed to protect confidentiality, while security engineering implements the mechanisms that enforce those requirements.

Integrity

Integrity is the protection of information and system resources against unauthorized modification or destruction.

Integrity ensures that information remains accurate, complete, consistent, and trustworthy according to its intended requirements. It applies not only to stored information but also to information while it is processed or transmitted.

Integrity can be supported through mechanisms such as:

• Access controls
• Integrity checking
• Digital signatures
• Validation mechanisms
• Change controls
• Audit mechanisms

Security architecture determines where integrity protection is required and how it should be incorporated into the system. Security engineering implements and validates the mechanisms used to prevent, detect, and respond to unauthorized changes.

Availability

Availability ensures that authorized subjects and entities can access required information, systems, services, and resources when needed.

A system may lose availability because of hardware or software failures, resource exhaustion, disruptions, dependencies, or attacks. Security architecture therefore needs to consider how the system can continue providing required functions when individual components or supporting services become unavailable.

Availability can be supported through:

• Redundancy
• Fault tolerance
• Resilience
• Capacity management
• Backup and recovery
• Failure handling

Security architecture establishes how availability and resilience are incorporated into the system, while security engineering implements and maintains the mechanisms that support continued operation and recovery.

CIA in Security Architecture

The CIA objectives influence architectural decisions throughout the system.

Confidentiality requirements can influence trust boundaries, access relationships, information flows, and protection mechanisms. Integrity requirements can influence how components interact and how changes to information are controlled. Availability requirements can influence redundancy, dependencies, fault tolerance, and recovery.

The three objectives can also compete with one another. A security architecture therefore needs to consider the requirements of the system and determine the appropriate balance between confidentiality, integrity, and availability.

CIA in Security Engineering

Security engineering translates CIA requirements into functioning technical capabilities.

For example, confidentiality requirements may result in authentication, authorization, and encryption mechanisms. Integrity requirements may result in access controls, validation, integrity verification, and controlled modification. Availability requirements may result in redundancy, fault tolerance, monitoring, and recovery mechanisms.

The CIA triad therefore provides a fundamental basis for security requirements, architectural decisions, control selection, and engineering implementation.

Security Controls

Security controls are safeguards and countermeasures designed to protect information, systems, facilities, personnel, and other resources from security threats and risks. They help implement security requirements and support the protection of the confidentiality, integrity, and availability of information and resources.

Security controls can be established through organizational practices, technical mechanisms, and physical measures. They can also perform different functions, such as preventing unwanted activity, detecting security events, correcting security problems, or restoring systems after a disruption.

Administrative Controls

Administrative controls establish the governance, policies, standards, procedures, responsibilities, and management practices that direct and support security.

They define how security should be planned, implemented, managed, and maintained and establish the responsibilities of personnel and other stakeholders. Administrative controls provide the organizational foundation for implementing and maintaining security requirements.

Examples include security policies, risk assessments, security awareness training, personnel security, vendor management, change management, and incident response planning.

Technical Controls

Technical controls are technology-based safeguards that protect information systems, applications, networks, devices, and digital assets.

They enforce or support security requirements through technical mechanisms and can help prevent unauthorized access, protect information, detect security events, and support response activities.

Examples include authentication and authorization mechanisms, multi-factor authentication (MFA), encryption, firewalls, intrusion detection and prevention systems (IDS/IPS), endpoint protection, SIEM, VPNs, and access-control mechanisms.

Physical Controls

Physical controls protect facilities, personnel, equipment, and supporting infrastructure against unauthorized physical access, theft, damage, environmental hazards, and other physical threats.

They establish physical protection around the resources that support information systems and security operations.

Examples include security guards, locks, access cards, biometric systems, CCTV surveillance, perimeter fencing, fire suppression systems, environmental monitoring, and backup power.

Functional Security Controls

Functional security controls describe the purpose or function performed by a security control. They address different security needs, from preventing unwanted activity and detecting security events to correcting security problems and restoring systems after disruption.

Preventive Controls

Preventive controls are designed to prevent security incidents or reduce their likelihood before they occur. They restrict unauthorized access, prevent unwanted actions, reduce exposure, and address conditions that could enable a security incident.

Detective Controls

Detective controls are designed to identify and report security events, suspicious activities, policy violations, or other conditions that may indicate a security incident. They provide visibility into system and user activity and support monitoring, investigation, and response.

Corrective Controls

Corrective controls are designed to address security problems after an incident or failure has occurred and help return affected systems or processes to an acceptable security state. They may involve correcting vulnerabilities, removing unauthorized changes, containing the effects of an incident, or restoring appropriate security configurations.

Directive Controls

Directive controls provide instructions, policies, standards, procedures, and requirements that guide individuals and organizations in carrying out security-related activities. They establish expectations and responsibilities for protecting information, systems, and other resources.

Deterrent Controls

Deterrent controls are intended to discourage unauthorized or undesirable activities by increasing the perceived likelihood of detection or consequences. They influence behavior by making inappropriate activities more visible or by establishing consequences for violating security requirements.

Compensating Controls

Compensating controls provide alternative safeguards when a primary control cannot be implemented as intended because of technical, operational, architectural, or other limitations. They provide another means of addressing the underlying security requirement while maintaining an appropriate level of protection.

Recovery Controls

Recovery controls are designed to restore information, systems, services, and operations following a security incident, failure, disaster, or other disruptive event. They help return affected resources to an acceptable operating state and reduce the duration and impact of disruption.

How Security Controls Work Together

Security controls rarely operate in isolation. Different controls are combined to provide complementary protection across systems, processes, facilities, and operations.

Administrative controls establish security policies, requirements, responsibilities, and processes. Technical controls implement and enforce many of those requirements within information systems and networks, while physical controls protect the facilities, equipment, and infrastructure that support those systems.

The functional purpose of controls complements these implementation types. A technical firewall, for example, can perform a preventive function by blocking unauthorized traffic. Security monitoring can provide a detective function, while corrective and recovery mechanisms can help address and restore systems following an incident.

A single control can therefore have both an implementation type and a functional purpose. Combining these controls creates layered protection, allowing security architecture and engineering to address security requirements through multiple complementary safeguards rather than relying on a single mechanism.

Policy, Standard, Framework, Guidelines, Procedure, Baseline

Security governance uses different forms of documentation and structured guidance to establish security expectations, define requirements, provide direction, and support consistent implementation. These elements operate at different levels, from organizational direction to specific implementation requirements.

Policy

A policy establishes high-level management direction and mandatory organizational intent. It defines what the organization requires, the security objectives it expects to achieve, and the responsibilities that must be followed.

Security policies provide the foundation for developing more specific security requirements and practices. They may address areas such as information protection, access control, acceptable use, incident management, data protection, and system security.

Standard

A standard defines specific and mandatory requirements that support and implement organizational policies. Standards make policy expectations more precise by establishing requirements that systems, processes, technologies, and personnel are expected to follow.

For example, a policy may require strong authentication, while an authentication standard can define the minimum authentication mechanisms, password requirements, or multi-factor authentication requirements that must be implemented.

Framework

A framework provides a structured model for organizing security practices, processes, requirements, and controls. It helps organizations establish a consistent approach to managing security and provides a common structure for assessing, implementing, and improving security capabilities.

Frameworks generally operate at a broader level than individual policies or standards and can bring together multiple security activities within a coherent structure.

Guidelines

Guidelines provide recommended practices and advice for implementing security requirements. Unlike standards, guidelines are generally not mandatory and allow flexibility based on the characteristics, risks, and operational requirements of a particular environment.

Guidelines help personnel and technical teams make consistent security decisions while allowing appropriate variation where a single implementation approach is not required.

Procedure

A procedure provides detailed instructions for performing a specific security activity. It translates requirements and established practices into a defined sequence of actions that personnel can follow consistently.

Procedures may describe activities such as provisioning user access, responding to security incidents, configuring systems, performing backups, or conducting security reviews.

Baseline

A baseline establishes a minimum defined level of security configuration or protection that a system, device, application, or environment is expected to maintain.

Baselines provide a consistent reference for determining whether systems meet minimum security requirements. They may define configuration settings, enabled or disabled services, authentication requirements, logging requirements, security software, and other minimum security conditions.

Security Architecture Requirements

Security architecture requirements define the security capabilities and properties that a system must provide to protect its information, resources, users, and services.

They translate security objectives, organizational policies, risk considerations, and system requirements into specific requirements that can guide architecture and engineering decisions. They provide a basis for determining how systems should be designed, what security controls are required, and how security can later be verified.

Security architecture requirements may address areas such as confidentiality, integrity, availability, authentication, authorization, accountability, privacy, resilience, monitoring, and recovery.

For example, a requirement stating that sensitive information must be accessible only to authorized users can influence identity management, authentication, authorization, access controls, information flows, and trust boundaries.

Clear security requirements are important because architectural decisions and security controls should be traceable back to defined security needs. They also provide criteria for evaluating whether the resulting architecture and implementation satisfy the intended security objectives.

Trust and Assurance

Trust and assurance are important concepts in security architecture and engineering. Trust concerns the confidence placed in an entity or relationship, while assurance concerns the confidence that a system, control, or mechanism will provide its intended security protection.

Trust

Trust is the confidence placed in an entity, component, system, service, process, or mechanism to behave as expected or satisfy defined security requirements.

Trust relationships may exist between users and systems, applications and services, devices and networks, or components within a system. Security architecture must identify these relationships and determine where trust can be established and where it must be limited.

Excessive or poorly defined trust can create security weaknesses. Security architecture therefore considers trust boundaries, authentication, authorization, isolation, and other mechanisms that establish and control trust.

Security engineering implements and maintains the mechanisms used to establish, enforce, and evaluate these trust relationships.

Assurance

Assurance is the confidence that a system, component, security control, or mechanism satisfies its intended security requirements and can provide the expected protection.

Assurance is established through activities such as requirements review, architecture analysis, design review, testing, verification, security assessment, control evaluation, and independent evaluation.

Verification helps determine whether security requirements have been correctly implemented, while assurance provides confidence that the resulting implementation can be relied upon to provide the expected security properties.

Open Systems and Closed Systems

Open and closed systems describe the degree to which a system interacts with external entities, components, systems, or environments. This distinction is relevant to security architecture because external interaction influences trust relationships, interfaces, dependencies, information flows, and attack surface.

Open Systems

An open system is designed to interact with external systems, components, users, services, or environments through defined interfaces.

Open systems support interoperability, integration, communication, and extensibility. However, interaction with external entities introduces additional security considerations.

Security architecture must therefore consider external interfaces, trust relationships, authentication and authorization, information flows, dependencies, and the exposure created by those interactions.

Closed Systems

A closed system restricts interaction with external systems, components, users, or environments. Its interfaces, dependencies, and access relationships are generally more controlled.

A closed system may reduce certain forms of external exposure, but being closed does not automatically make a system secure. Internal vulnerabilities, configuration weaknesses, excessive privileges, and trusted relationships can still introduce security risks.

Security architecture must therefore consider both external and internal security boundaries regardless of whether a system is open or closed.

Subjects and Objects

Subjects and objects are fundamental concepts in access control and security models. They provide a basic way to describe who or what requests access, what resource is being accessed, and how security mechanisms determine whether an operation should be permitted.

Subject

A subject is an active entity that initiates an action or requests access to a resource. A subject can act on behalf of a user, system, process, or other entity and can request operations such as reading, writing, modifying, executing, or deleting a resource.

Examples of subjects include users, applications, processes, services, and devices. The identity and attributes of a subject can be used by security mechanisms when making access-control decisions.

For example, when a user attempts to open a file, the user’s authenticated identity or the process acting on the user’s behalf can be treated as the subject making the access request.

Object

An object is a resource that is accessed or operated on by a subject. Objects represent the resources that require protection and can exist at different levels within a system.

Examples include files, databases, database records, applications, devices, memory areas, network resources, and other information resources. The security policy determines what operations a subject may perform on a particular object.

For example, a file can be an object, and permitted operations may include reading, writing, modifying, or deleting that file.

Access Relationship Between Subjects and Objects

The relationship between a subject and an object forms the basis of an access-control decision. When a subject requests an operation on an object, the security mechanism evaluates the request against the applicable security policy, permissions, attributes, and other access-control conditions.

For example, a user may be authorized to read a particular document but not modify or delete it. The user is the subject, the document is the object, and the permitted operations define the access relationship between them.

This relationship can become more complex when subjects operate through processes or applications, when objects contain other objects, or when access decisions depend on attributes such as identity, role, security level, location, time, or device.

The subject-object concept provides a foundation for understanding access-control models and security policies. Models such as Bell-LaPadula, Biba, Clark-Wilson, and access-control matrices use these concepts to reason about how subjects interact with protected objects and what operations should be permitted.

The distinction between subjects and objects provides a foundation for understanding access-control decisions, authorization relationships, and formal security models such as Bell-LaPadula, Biba, Clark-Wilson, and other security models.

Security Models

Security models provide formal or conceptual representations of security requirements, policies, rules, and relationships within a system. They provide a structured way to reason about how security should be maintained and how a system should behave under defined security conditions. Rather than describing a specific security product or implementation, a security model establishes the underlying principles and rules used to describe, analyze, or evaluate security.

Different security models address different security concerns. Some focus on maintaining a system in a secure state, while others examine access rights, the relationship between subjects and objects, or the flow of information between security domains. Other models focus specifically on confidentiality, integrity, noninterference, separation of duties, or conflicts of interest.

The following are some of the important security models that have shaped the development of information security. Each model addresses a particular security concern or provides a different way of understanding security, including system states, access control, information flow, confidentiality, integrity, and conflicts of interest.

State Machine Model

The State Machine Model represents a system as a collection of states and transitions between those states. A state represents the security-relevant condition of a system at a particular point in time, including subjects, objects, access rights, and other conditions that affect security.

A state transition occurs when an operation or event changes the system from one state to another. Examples include a user logging in, a file being created, a permission being changed, or a process accessing a resource. Each transition is evaluated against the applicable security rules.

The fundamental principle is that a system should begin in a secure state and remain in a secure state after every authorized transition. If an operation would cause the system to enter an insecure state, that transition should not be permitted.

For example, if a file is initially accessible only to an authorized user and an operation changes its permissions so that an unauthorized user can access it, the system has transitioned from a secure state to an insecure state. A security mechanism should prevent that transition.

The State Machine Model therefore provides a general foundation for reasoning about secure states, authorized operations, state transitions, and preservation of security properties throughout system operation.

Information Flow Model

The Information Flow Model focuses on how information moves between subjects, objects, processes, components, or security domains.

Rather than considering only whether a subject is authorized to access an object, it examines whether information is permitted to flow from one entity or security level to another. This makes it useful for analyzing unauthorized information movement and potential information leakage.

For example, information classified at a higher security level may be restricted from flowing into a lower security domain, even if the receiving component can technically communicate with the source.

The model is therefore concerned with controlling the direction and permitted paths of information movement within a system.

Noninterference Model

The Noninterference Model focuses on preventing activity in one security domain from influencing what can be observed in another security domain.

The objective is to ensure that sensitive activity does not produce observable effects in a domain that should remain independent of that information. This provides a formal way to reason about information leakage and isolation between security domains.

For example, if a system processes both highly sensitive and less-sensitive information, activity involving the sensitive information should not produce observable changes that allow a lower-level user to infer that information.

The model therefore addresses whether the behavior of one security domain can interfere with or influence another domain.

Lattice-Based Security

A lattice-based security approach represents security levels or labels as an ordered structure in which relationships such as higher than, lower than, or dominates can be defined.

A lattice provides a mathematical foundation for reasoning about security relationships between subjects and objects. Access or information flow can be evaluated according to the relationship between their assigned security labels.

Lattice-based concepts are particularly important in multilevel security and are closely associated with models such as Bell-LaPadula and Biba. Bell-LaPadula uses security levels to protect confidentiality, while Biba uses integrity levels to control information and access relationships.

The lattice concept therefore provides a structured way to reason about ordered security levels and permitted relationships between them.

Access Control Matrix

The Access Control Matrix provides a conceptual representation of which subjects can perform which operations on which objects.

Subjects are represented against objects, with each relationship containing the operations that are permitted, such as read, write, execute, or modify.

Subject	Operation	Object	Decision
Alice	Read	File A	Allowed
Alice	Write	File A	Allowed
Alice	Delete	File A	Denied

The access control matrix provides a fundamental representation of the subject-object access relationship. Practical systems may represent this information through mechanisms such as access-control lists or capability-based structures.

Take-Grant Model

The Take-Grant Model focuses on access rights and how those rights can be acquired or transferred within a system.

It represents subjects, objects, and the rights associated with them and provides rules for analyzing how a subject may obtain or transfer access rights. The model can be used to determine whether a subject could eventually acquire a particular right through a sequence of permitted operations.

For example, if one subject possesses a right that allows it to grant another right to a different subject, the model can be used to analyze how that right may propagate through the system.

Bell-LaPadula Model

The Bell-LaPadula Model (BLP) is a formal security model designed primarily to protect confidentiality. It controls how subjects access objects based on their security levels and restricts information flows that could result in unauthorized disclosure.

The model uses three important properties.

Simple Security Property

The Simple Security Property is commonly expressed as “No Read Up.” A subject cannot read an object at a higher security level than the subject’s authorized level.

For example, a subject cleared at the Secret level cannot read an object classified as Top Secret.

*-Property (Star Property)

The *-Property is commonly expressed as “No Write Down.” A subject cannot write information to an object at a lower security level.

For example, a subject operating at the Secret level cannot write information to an object classified as Confidential, because this could allow sensitive information to flow to a lower security level.

Strong *-Property (Strong Star Property)

The Strong *-Property requires read and write operations to occur at the same security level. A subject cannot read from or write to an object at a different security level.

Bell-LaPadula Property	Rule	Purpose
Simple Security Property	No Read Up	Prevents reading information at a higher level
*-Property	No Write Down	Prevents writing information to a lower level
Strong *-Property	Read and write at the same level	Prevents cross-level read/write operations

Biba Model

The Biba Model is a formal security model designed primarily to protect integrity. It controls how subjects interact with objects according to their integrity levels and helps prevent lower-integrity information from improperly influencing higher-integrity information.

The model includes three important properties.

Simple Integrity Axiom

The Simple Integrity Axiom is commonly expressed as “No Read Down.” A subject cannot read an object at a lower integrity level.

For example, a subject operating at High Integrity cannot read information at Low Integrity, because less-trusted information could influence a higher-integrity environment.

*-Integrity Axiom

The *-Integrity Axiom is commonly expressed as “No Write Up.” A subject cannot write information to an object at a higher integrity level.

For example, a subject operating at Low Integrity cannot modify an object at High Integrity, because this could allow lower-integrity information to influence trusted information.

Invocation Property

The Invocation Property prevents a subject from requesting services or invoking another subject that operates at a higher integrity level.

This prevents a lower-integrity subject from indirectly influencing a higher-integrity subject through service invocation.

Biba Property	Rule	Purpose
Simple Integrity Axiom	No Read Down	Prevents reading lower-integrity information
*-Integrity Axiom	No Write Up	Prevents writing to higher-integrity objects
Invocation Property	No invocation of higher-integrity subjects	Prevents lower-integrity subjects from influencing higher-integrity subjects

Clark-Wilson Model

The Clark-Wilson Model is an integrity model designed to maintain the correctness and consistency of information through controlled transactions, authorized procedures, and separation of duties.

Rather than relying primarily on security levels, the model controls how protected data can be accessed and modified. It uses four important concepts.

Transformation Procedures (TPs)

Transformation Procedures (TPs) are authorized programs or procedures that perform operations on protected data. Subjects do not directly modify protected data; instead, they use approved procedures that enforce the required rules.

Constrained Data Items (CDIs)

Constrained Data Items (CDIs) are data items whose integrity must be protected. They can be modified only through authorized Transformation Procedures.

For example, account balances in a banking system can be treated as CDIs because their values must remain accurate and consistent.

Unconstrained Data Items (UDIs)

Unconstrained Data Items (UDIs) are data items that are not subject to the same integrity constraints as CDIs. They may originate from outside the trusted system or may not yet have been validated.

Information received from an external source can initially be treated as a UDI and then validated through an approved procedure before it is used to modify protected data.

Integrity Verification Procedures (IVPs)

Integrity Verification Procedures (IVPs) verify that CDIs remain in a valid and consistent state.

They check whether the integrity rules established for protected data continue to hold and can identify violations or inconsistencies.

Concept	Role
TP	Performs an authorized operation on protected data
CDI	Protected data whose integrity must be maintained
UDI	Unconstrained data that may require validation
IVP	Verifies that protected data remains valid and consistent

Brewer and Nash Model

The Brewer and Nash Model, commonly known as the Chinese Wall Model, is designed to prevent conflicts of interest when a subject has access to information belonging to competing organizations.

The model is based on the principle that access to information can affect what information a subject should be permitted to access afterward. Once a subject accesses information belonging to one organization within a particular conflict-of-interest class, the subject may be restricted from accessing information belonging to a competing organization in the same class.

For example, a consultant may work with several competing banks. If the consultant accesses confidential information belonging to Bank A, the model can restrict subsequent access to confidential information belonging to Bank B.

Previous Access	Requested Access	Result
Bank A	Bank A	Allowed
Bank A	Bank B	Restricted
Bank A	Telecom A	Allowed
Bank A	Healthcare A	Allowed

The important characteristic is that access history becomes part of the security decision.

Goguen-Meseguer Model

The Goguen-Meseguer Model focuses on noninterference and information-flow security. It examines whether actions performed within one security domain can improperly influence the behavior or observable results of another domain.

The model is concerned with ensuring that activities involving sensitive information do not create observable effects that could allow information to be inferred by unauthorized domains.

It provides a formal approach for reasoning about controlled interaction and information leakage between security domains.

Sutherland Model

The Sutherland Model focuses on information-flow security and interactions between entities.

It provides a way to reason about how information can move through interactions within a system and whether those interactions could result in unauthorized information transfer.

The model is particularly concerned with controlling and analyzing information flows between entities and understanding how those flows may affect security.

Graham-Denning Model

The Graham-Denning Model is a formal security model for controlling the creation, deletion, and management of subjects, objects, and access rights within a system.

The model considers three fundamental elements:

Element	Purpose
Subject	Active entity that can perform operations
Object	Protected resource
Right	Permission defining what a subject can do with an object

A key aspect of the model is the controlled management of these elements. It defines operations for creating and deleting subjects and objects and for managing the rights associated with them.

The model therefore focuses not simply on whether an access request is allowed, but on how subjects, objects, and access rights are securely managed throughout their lifecycle.

Harrison-Ruzzo-Ullman (HRU) Model

The Harrison-Ruzzo-Ullman (HRU) Model is a formal access-control model used to analyze the creation, deletion, and propagation of access rights within a system.

The model extends the concept of an access-control matrix by allowing operations to change the access-control state itself. It therefore considers not only what rights exist at a particular point in time, but also how those rights can change through authorized operations.

The model represents subjects, objects, access rights, and commands that can modify the access-control state.

Element	Purpose
Subjects	Active entities that perform operations
Objects	Protected resources
Access Rights	Permissions defining permitted operations
Commands	Operations that can modify access-control state
Safety	Examines whether rights can eventually propagate to a subject

A key concern of the HRU Model is safety—whether an access right that does not currently exist could eventually be acquired by a subject as a result of a sequence of authorized commands.

The security models discussed above are not limited to a particular type of technology or system. Their principles can be applied across hardware, software, operating systems, applications, networks and infrastructure, databases, cloud environments, and data security, depending on the security requirement being addressed. Access-control models can be used to define and analyze permissions between subjects and resources, information-flow models can be applied to control the movement of information between components or security domains, and confidentiality and integrity models can be applied wherever information requires protection at different security levels. Similarly, transaction-based and conflict-of-interest models can be applied to environments where data integrity or controlled access is important. In practice, these models provide conceptual and formal foundations for analyzing security requirements across different technology and security domains, while their specific implementation depends on the architecture, system, and security objectives involved.

Security Modes of Operation

Security modes of operation define the conditions under which a system, its users, and its resources can operate based on the security clearances, authorizations, and information classifications involved. They are particularly associated with environments that process information at different security levels or within different security compartments.

The purpose of security modes is to establish what information a system may process, which users may access that information, and under what conditions access is permitted. The mode selected depends on the relationship between the users, the information being processed, and the security controls implemented by the system.

Dedicated Security Mode

Dedicated Security Mode is a mode in which the system is authorized to process information at a specific classification or sensitivity level for a defined set of users who are appropriately cleared and authorized for that information.

All users are generally cleared and authorized to access the information processed by the system. Because the users and information have compatible security requirements, the system does not need to support the same degree of separation between users and information as required in more restrictive multilevel environments.

For example, a system dedicated to processing Secret information may be accessible only to users who are appropriately cleared and authorized to access that information.

The primary characteristic of dedicated mode is that the system operates within a defined security environment with users who have the necessary authorization for the information being processed.

System High Security Mode

System High Security Mode allows a system to process information at multiple classification or sensitivity levels, but all users who can access the system must have the necessary clearance and authorization for the highest level of information processed by the system.

However, being cleared for the highest level does not necessarily mean that every user is authorized to access every piece of information. Additional access restrictions, such as need-to-know requirements, may still apply.

For example, a system may process both Confidential and Secret information. All users may need to be cleared for Secret information, while access to particular information can still be restricted according to authorization and need-to-know.

The important distinction is that the system operates at a high security level, while individual access to information can still be controlled through additional security mechanisms.

Compartmented Security Mode

Compartmented Security Mode introduces additional separation requirements for information belonging to different security compartments.

Users must have the appropriate clearance and authorization for the information they need to access, including the relevant compartments. A user may therefore be cleared for the overall classification level but still be unable to access information belonging to a particular compartment.

For example, a user may have a Secret clearance but be authorized for only one particular compartment. Information belonging to another Secret compartment remains inaccessible unless the user has the required authorization.

This mode provides greater separation between information sets and is useful when classification alone is not sufficient to determine whether access should be permitted.

Multilevel Security Mode

Multilevel Security Mode allows a system to process information at different security levels and compartments while supporting users with different clearances and authorizations.

Unlike System High Security Mode, not every user must necessarily have authorization for the highest level of information processed by the system. The system must therefore enforce stronger access-control and information-flow rules to ensure that users can access only the information they are authorized to access.

For example, the same system may contain Confidential, Secret, and Top Secret information while serving users with different levels of authorization. Security mechanisms must ensure that each user can access only the information permitted by their clearance, authorization, need-to-know, and applicable security policy.

Multilevel security is therefore closely related to concepts such as security labels, access control, information flow, and lattice-based security models.

Trusted Computing Base

The Trusted Computing Base (TCB) is the collection of hardware, firmware, software, and other security-relevant mechanisms that are relied upon to enforce the security policy of a system. The TCB forms the trusted portion of the system because the system’s security depends on these components performing their security-related functions correctly.

The TCB is not necessarily the entire system. Its scope depends on the architecture, security requirements, and security policy. Components that do not participate in enforcing or maintaining security properties do not need to be part of the TCB. Clearly identifying the TCB helps define what must be protected, evaluated, tested, and trusted.

Trusted Computing Base Components

A TCB can contain components across multiple layers of a system, including:

• Hardware — processor protection mechanisms, memory protection, and hardware security mechanisms
• Firmware — security-critical firmware involved in establishing or enforcing the trusted environment
• Operating system components — mechanisms responsible for isolation, access control, and protection
• Security kernel — core mechanisms that enforce security policy
• Reference monitor mechanisms — mechanisms that mediate access between subjects and objects
• Authentication mechanisms — mechanisms that establish and verify identities
• Security management mechanisms — mechanisms that manage security policies, privileges, and security configurations

The exact composition of the TCB depends on the system. A component is part of the TCB when the system relies on that component for enforcing or maintaining a security property.

Trusted Computing Base and Security Enforcement

The TCB provides the trusted foundation for security-policy enforcement. When a subject requests access to an object, security mechanisms within the TCB can evaluate the request against the applicable security policy and enforce the resulting decision.

For example, when a user attempts to access a protected file, the operating system may identify the user, determine the applicable permissions, evaluate the requested operation, and either allow or deny access. The security mechanisms responsible for these functions are part of the trusted base when the system depends on them to enforce its security policy.

A security architecture should clearly define the boundaries and responsibilities of the TCB. Keeping the trusted base well-defined and limited to security-relevant components can make the system easier to analyze, test, verify, and maintain.

Trusted Path

A Trusted Path is a protected communication path between a user and a trusted security mechanism. It is intended to ensure that security-sensitive interactions take place with the intended trusted component rather than with an untrusted application or process impersonating that component.

A trusted path may be used for security-sensitive operations such as authentication or invoking privileged security functions. The important characteristic is that the communication path itself is protected against interference or interception by untrusted components.

For example, an operating system may provide a protected mechanism through which a user can directly invoke a trusted login function rather than entering credentials into an untrusted application.

The trusted path therefore helps establish confidence in the identity of the security mechanism with which the user is communicating.

Trusted Shell

A Trusted Shell is a trusted interface or controlled execution environment through which users can interact with system functions while the applicable security policy is enforced.

A trusted shell can provide controlled access to system resources and security-relevant functions based on the user’s identity, privileges, and authorization. It operates as part of the trusted environment rather than relying entirely on ordinary, untrusted application mechanisms.

The trusted shell is related to the trusted path, but they address different concepts. The trusted path provides protected communication with a trusted security mechanism, while the trusted shell provides a trusted interface or environment for controlled interaction with system functions.

Security Kernel

The Security Kernel is the core part of a system responsible for enforcing the security policy. It provides the fundamental mechanisms required to control access, isolate subjects and objects, and maintain the security properties defined by the system.

The security kernel is closely associated with the TCB, but the terms are not interchangeable. The security kernel is a core security-enforcement mechanism, while the TCB encompasses the broader set of components that must be trusted to enforce or maintain the system’s security policy.

Security Kernel Functions

A security kernel may provide or support several fundamental security functions, including:

• Access control enforcement
• Subject and object isolation
• Security-domain separation
• Protection of security-critical resources
• Controlled communication between security domains
• Security-policy enforcement
• Support for identification and authentication

For example, when one process attempts to access resources belonging to another protected process, the security kernel can enforce the applicable isolation and access-control rules.

The security kernel therefore provides a central foundation for enforcing fundamental security requirements within the system.

Security Kernel Requirements

A security kernel is traditionally associated with several important requirements.

Complete mediation requires that access to protected resources be subject to the applicable security policy. A subject should not be able to bypass the security mechanism through an alternative access path.

Isolation requires that the security-enforcement mechanisms themselves be protected against unauthorized modification or interference.

Verifiability requires that the security-enforcement mechanisms be sufficiently structured and controlled so that their correctness can be analyzed, tested, and, where appropriate, formally verified.

These requirements support confidence that the security kernel can reliably enforce the security policy.

Reference Monitor

The Reference Monitor is an abstract security concept representing the mechanism that mediates access between subjects and objects.

When a subject requests an operation on an object, the reference monitor evaluates the request according to the applicable security policy and determines whether the operation should be permitted.

The reference monitor therefore provides a conceptual foundation for understanding access-control enforcement. It does not necessarily refer to one specific software component; an operating system, hypervisor, access-control mechanism, or combination of mechanisms may implement the reference-monitor function.

Reference Monitor Functions

The reference monitor performs three fundamental functions:

Access mediation ensures that access requests from subjects to protected objects are evaluated before the requested operation is allowed.

Security-policy enforcement ensures that access decisions are made according to the rules established by the applicable security policy.

Protection of the mediation mechanism ensures that the mechanism responsible for controlling access cannot itself be bypassed or modified by unauthorized entities.

For example, when Alice attempts to read a protected file, the system’s access-control mechanism can evaluate Alice’s identity and permissions before allowing the requested read operation.

The reference monitor therefore acts as the security enforcement point between a subject and an object.

Reference Monitor Requirements

The reference monitor is traditionally described through three fundamental properties:

Complete mediation requires that every access to a protected resource be checked by the reference monitor.

Tamper resistance requires that the reference monitor be protected from unauthorized modification.

Verifiability requires that the reference-monitor mechanism be sufficiently small, simple, and well-defined to allow its correctness to be effectively analyzed and verified.

Together, these properties provide the foundation for a security mechanism that can reliably mediate subject-to-object access according to the security policy.

Security Perimeter

A Security Perimeter defines the boundary between components, resources, processes, or environments that operate under a particular security policy and those outside that trusted environment. It establishes where a particular set of security assumptions, controls, and trust relationships applies.

A security perimeter does not have to be a physical boundary. It can be physical or logical, depending on the architecture. The purpose is to identify where trust begins and ends, what is protected, and where security enforcement is required when crossing from one security domain to another.

Trusted and Untrusted Components

A trusted component is a component that the system relies upon to perform a security-relevant function correctly. An untrusted component is not relied upon to enforce the security policy and should therefore be treated as potentially unreliable or hostile from the perspective of that policy.

Trust is context-dependent. A component may be trusted for one function but not trusted for another.

For example, an operating system may be trusted to enforce process isolation and file permissions, while an application running on that operating system may not be trusted with unrestricted access to system resources.

The security architecture should clearly identify which components are trusted, what they are trusted to do, and what controls are applied when untrusted components interact with trusted components.

Security Boundary

A Security Boundary is the logical or physical boundary that separates one security domain or trust environment from another. Crossing a security boundary may require appropriate security controls to ensure that the security policy continues to be enforced.

A security boundary can be physical or logical.

A physical security boundary can be represented by a physical separation, such as a controlled facility, restricted room, or isolated network infrastructure.

A logical security boundary exists through technical mechanisms rather than physical separation. For example, the separation between user mode and kernel mode in an operating system is a logical security boundary. Applications execute in user mode with restricted privileges, while the operating-system kernel operates in a privileged mode. Hardware protection mechanisms, memory protection, and controlled system calls prevent ordinary user processes from directly accessing protected kernel resources.

Other examples of logical security boundaries include:

• Process boundaries that prevent one process from directly accessing another process’s protected memory
• Virtual machine boundaries enforced by a hypervisor
• Container boundaries that isolate processes and resources
• Application boundaries that restrict one application from accessing another application’s protected resources
• Database security boundaries that restrict access to particular databases, schemas, tables, or records
• Network security boundaries that logically separate different security zones or segments

The boundary itself is not necessarily the security control. It identifies where a change in trust or security policy occurs and where appropriate enforcement mechanisms must operate.

Security Domains

A Security Domain is a collection of subjects, objects, processes, systems, or resources that operate under a defined set of security rules, privileges, and trust assumptions.

Different security domains can have different security requirements. For example, an enterprise environment may contain separate domains for:

• Standard users
• Privileged administrators
• Application services
• Sensitive data
• Management systems
• External or third-party services

Security domains help the architecture define who or what can interact with whom, what resources can be accessed, and what security controls must be applied between domains.

The separation of security domains is an important architectural principle because a compromise within one domain should not automatically provide unrestricted access to other domains. Controls between domains can therefore limit unauthorized access, privilege propagation, and unwanted information flow.

Security Evaluation Criteria and Frameworks

Security evaluation criteria and frameworks provide structured methods for assessing the security functionality and assurance of systems and products. Different criteria emerged at different times and from different organizations, but they share the broad objective of providing a consistent basis for evaluating security.

Important approaches include TCSEC, ITSEC, and Common Criteria. They represent different stages in the development of trusted-system security evaluation and differ in how they define security functionality, assurance, evaluation requirements, and results.

TCSEC (Trusted Computer System Evaluation Criteria)

Trusted Computer System Evaluation Criteria (TCSEC) was developed by the U.S. Department of Defense to establish criteria for evaluating the security of trusted computer systems.

TCSEC defined security requirements and organized evaluated systems into classes ranging from D through A1, with increasing requirements for security functionality and assurance.

Orange Book

The Orange Book is the commonly used name for the Trusted Computer System Evaluation Criteria (TCSEC) publication, named for the color of its cover. It defined the criteria used to evaluate trusted computer systems, including requirements related to security policy, accountability, assurance, and documentation.

The Orange Book is therefore not a separate evaluation framework from TCSEC. It is the principal TCSEC publication that established the foundation for trusted-system security evaluation and the associated evaluation classes.

TCSEC Evaluation Classes

TCSEC defined a hierarchy of evaluation classes ranging from D through A1. The classes progress from minimal protection through increasingly rigorous requirements for discretionary access control, mandatory access control, security labeling, architectural structuring, and assurance.

Class	Name	General Focus
D	Minimal Protection	Systems that do not meet the requirements of the higher TCSEC classes
C1	Discretionary Access Protection	Basic discretionary access control
C2	Controlled Access Protection	Stronger discretionary access control, individual accountability, and auditing
B1	Labeled Security Protection	Mandatory access control and security labeling
B2	Structured Protection	Stronger security architecture, defined security domains, and increased assurance
B3	Security Domains	Stronger security enforcement and protection of security mechanisms
A1	Verified Design	Highest TCSEC class, with rigorous formal specification and verification of the security design

Trusted Product Evaluation Program (TPEP)

The Trusted Product Evaluation Program (TPEP) was associated with the U.S. government process for evaluating trusted computer products against security evaluation criteria such as TCSEC.

It provided the evaluation structure through which security products could undergo formal assessment against recognized trusted-system requirements.

Evaluated Products List (EPL)

The Evaluated Products List (EPL) provided a listing of products that had undergone formal evaluation under the applicable trusted-product evaluation process.

It served as a reference for identifying products that had been evaluated and the evaluation results associated with those products.

ITSEC (Information Technology Security Evaluation Criteria)

Information Technology Security Evaluation Criteria (ITSEC) was a European approach to evaluating the security of information technology products and systems.

An important characteristic of ITSEC was its separation of security functionality from assurance. This allowed the required security functions to be specified independently from the degree of confidence required in their implementation.

ITSEC therefore provided greater flexibility than approaches in which functionality and assurance were combined into a single evaluation classification.

Common Criteria (CC)

Common Criteria (CC) is an internationally recognized framework for evaluating the security properties of information technology products and systems.

Common Criteria provides a structured approach for defining security requirements, specifying security functionality, establishing assurance requirements, and conducting security evaluations.

It separates the description of what security functionality is required from the assurance activities used to establish confidence in that functionality.

Protection Profiles (PPs)

A Protection Profile (PP) defines a set of security requirements for a particular category of products or systems.

It describes the security problem being addressed and establishes security objectives and requirements that products of that category are expected to satisfy.

Security Targets (STs)

A Security Target (ST) defines the security claims and requirements for a particular product or system being evaluated.

It identifies the security objectives, security functionality, and assurance requirements that apply to the specific product.

Security Functional Requirements (SFRs)

Security Functional Requirements (SFRs) describe the security functions that a product or system is required to provide.

They can address areas such as access control, identification and authentication, security audit, security management, cryptographic support, and protection of the security functions.

SFRs therefore describe what security functionality is required.

Security Assurance Requirements (SARs)

Security Assurance Requirements (SARs) describe the requirements used to establish confidence in the correct implementation and operation of the security functions.

They address areas such as development, documentation, testing, vulnerability assessment, and other assurance activities.

SARs therefore focus on how confidence is established in the security functionality.

Evaluation Assurance Levels (EALs)

Evaluation Assurance Levels (EALs) provide predefined packages of assurance requirements within Common Criteria. The levels range from EAL1 through EAL7, with increasing rigor in development, analysis, testing, and verification.

EAL	Name	General Focus
EAL1	Functionally Tested	Basic assurance through functional testing
EAL2	Structurally Tested	Additional analysis and structured testing
EAL3	Methodically Tested and Checked	Systematic design, development examination, and testing
EAL4	Methodically Designed, Tested, and Reviewed	Methodical design, testing, and review
EAL5	Semiformally Designed and Tested	Greater use of semiformal design and analysis
EAL6	Semiformally Verified Design and Tested	Extensive semiformal verification and analysis
EAL7	Formally Verified Design and Tested	Highest EAL, with rigorous formal analysis and verification

Rainbow Series

The Rainbow Series is a collection of U.S. government publications that expanded upon, interpreted, and provided guidance related to trusted computer systems, TCSEC, and security evaluation.

The publications addressed different aspects of trusted-system security and provided additional guidance concerning areas such as security models, trusted networks, databases, and the interpretation and application of trusted-system security requirements.

The Rainbow Series is therefore not a single evaluation framework equivalent to TCSEC, ITSEC, or Common Criteria. Instead, it represents a collection of supporting publications that developed and explained concepts associated with trusted-system security and evaluation.

Certification and Accreditation

Certification is the formal assessment of a system, product, or security capability to determine whether it satisfies defined security requirements. It provides documented evidence that the evaluated subject meets the applicable security criteria and requirements.

Accreditation is the formal decision by an authorized authority to accept the risks associated with operating a system in a particular environment. While certification provides evidence from an assessment, accreditation is the management decision to authorize operation based on that evidence and the remaining risk.

Certification

Certification establishes confidence that the security requirements identified for a system or product have been assessed against defined criteria.

The certification process can involve:

• Defining security requirements
• Assessing security controls and mechanisms
• Reviewing architecture and design
• Examining implementation
• Performing security testing
• Evaluating evidence
• Documenting findings and results

Certification does not mean that a system is completely secure. It indicates that the system has been evaluated against a defined set of requirements and criteria.

Accreditation

Accreditation is the formal authorization to operate a system within a defined environment based on an assessment of its security posture and associated risks.

The authorization decision considers factors such as:

• Security requirements
• Assessment results
• Identified vulnerabilities
• Residual risk
• Operational environment
• Compensating controls
• Business or mission requirements

The authority responsible for accreditation accepts or rejects the risk associated with operating the system.

Certification and Accreditation Process

Certification and accreditation are related but represent different decisions.

Certification focuses primarily on assessment and evidence: has the system been evaluated against the required security criteria?

Accreditation focuses on risk acceptance and authorization: is the organization willing to accept the remaining risk and authorize the system to operate?

The two activities therefore connect technical security assessment with organizational risk management and operational decision-making.

Defense in Depth

Defense in Depth is a security architecture principle in which multiple layers of protection are used so that the failure or compromise of one security control does not automatically result in complete compromise of the protected system or information.

Rather than depending on a single security mechanism, defense in depth distributes protection across different controls, technologies, processes, and architectural layers.

For example, protecting an application may involve network segmentation, identity controls, application security, endpoint protection, data protection, logging, monitoring, and recovery capabilities. If one control is bypassed, other controls can continue to provide protection or detect the resulting activity.

Layers of Defense

Defense in depth can be implemented through multiple layers, including:

• Physical security — protects facilities, equipment, and physical infrastructure
• Network security — controls communication and network access
• Identity and access security — controls who can access systems and resources
• Endpoint security — protects devices and operating environments
• Application security — protects applications and their execution environments
• Data security — protects information through access control, encryption, classification, and other mechanisms
• Security monitoring — detects suspicious or unauthorized activity
• Incident response — provides mechanisms for containing and responding to security events
• Business continuity and recovery — helps restore services and information after disruptive events

These layers should work together rather than operate as isolated controls.

Defense in Depth Across Security Domains

Defense in depth can extend across different security domains and trust boundaries. Controls can be applied at the physical, infrastructure, network, application, identity, and data levels, creating multiple opportunities to prevent, detect, contain, and recover from security events.

For example, a compromised user account should not automatically provide unrestricted access to sensitive information. Authentication controls establish identity, authorization limits access, network controls restrict communication, application controls enforce application-level permissions, data controls protect sensitive information, and monitoring can identify abnormal activity.

The principle is therefore broader than simply deploying multiple security products. Effective defense in depth combines different types of security controls at different architectural layers and security domains, reducing dependence on any single control.

Conclusion

Security architecture provides the structure through which security requirements, principles, models, controls, trust relationships, and enforcement mechanisms are brought together. Concepts such as subjects and objects, security models, security modes of operation, the Trusted Computing Base, security kernel, reference monitor, and security boundaries provide the foundations for understanding how security can be represented and enforced within a system.

Security evaluation extends these concepts by providing methods for assessing whether security functionality and assurance requirements are satisfied. The development from TCSEC and its Orange Book foundation, through ITSEC and Common Criteria, illustrates the evolution of formal approaches to evaluating trusted systems and security products.

Ultimately, security architecture is not limited to a particular technology or implementation. The same architectural principles can be applied across hardware, software, infrastructure, networks, applications, cloud environments, data, and enterprise systems. Defense in depth further strengthens the architecture by distributing protection across multiple layers, while certification and accreditation connect technical evaluation with organizational assurance, risk acceptance, and authorization decisions.

References

European Commission – Information Technology Security Evaluation Criteria (ITSEC)
Provides the official European Commission publication for the Information Technology Security Evaluation Criteria (ITSEC).

National Institute of Standards and Technology (NIST) – Engineering Trustworthy Secure Systems
Provides established guidance on systems security engineering and the development of trustworthy secure systems.

Common Criteria Recognition Arrangement (CCRA) – Common Criteria Portal
Provides the official international Common Criteria framework, evaluation information, and certification resources.