Security Architecture and Design - ISSE Activity-1

Exam: ISC CISSP - Certified Information Systems Security Professional

Security Architecture and Design

ISSE Activity: Define the Security Architecture
The role of the ISSEP during this phase is to define the security architecture in coordination with the SEs defining the system architecture. This includes allocating security services to the functions, identifying security mechanisms and components, defining the relationships between the security components, and analyzing any constraints to the security functions.

When defining the architecture for a secure system, the ISSEPs perform the following activities:

• Review the system decomposition of subsystems and components identified by the SEs.
• Perform a security functional analysis and allocation based on the security requirements.
• For each subsystem, choose a security component that matches its style and meets the security requirement.
• Examine the relationships between subsystems and identify the communication channels between the entities.
• Choose communication security components that will enforce the security requirements for each interface.
• If the implementation of a security component will place a constraint on the system, document it as a system constraint.
• Document the rationalization of how the security components and their integration will meet the security requirements.

In this phase, previously documented information is used to define the security functions and to choose the security components that will perform the security functions - this process is the core element of designing the security architecture. The difference between defining the security requirements and defining the security architecture. That is, the target systems will now be defined.

The security architecture describes how the system will be put together to satisfy the security requirements. It is a design overview, describing the security functions and relationships between key elements of the system, such as hardware, operating systems, applications, networks, and other required components. It should describe how the functions in the system will follow the security requirements during the design and development process. For example, if the security requirements specify that the system must have a given level of assurance as to the correctness of the security controls, the security architecture must prescribe how these specifications will be met during the design and development process.

At this stage in the ISSE model, it is important for the ISSEP to explain to the customer that the security requirements are not added steps to the design or development process. Instead, it is the specifications outlined in the security architecture that influence all further design and development processes. Thus, the security architecture should outline high-level security issues, such as the system security policy, the level of assurance required, and any potential impacts security could have on the design process.

The security architecture should include a definition of expected residual risk and any expected failure in achieving full compliance with the system security requirements. The output of this phase is the detailed system security architecture, which translates into a stable, productive, cost- effective security design during Phase 4, Develop Detailed Security Design.

In theory, defining the security architecture sounds easy. In reality, there are always challenges to overcome. These "challenges" usually indicate that the SEs, ISSEPs, and maybe even the customer will need to make trade-offs (modifications) to the needs or requirements. When tradeoffs must be made, the ISSEP must also reevaluate the risk management strategy. Because the ability to make the right trade-off choices is a critical factor in the ISSEP process.

Begins with an example of a security architecture framework that could be used by ISSEPs to develop the security architecture. Just as in the SE activities, the ISSEP also conducts a security functional analysis and allocation. This also includes a requirements traceability matrix for matching security functions to security requirements.