Risk-Aware Security Architecture

Risk-Aware Security Architecture

We continue the series to develop an on-going threat analysis and risk management process – as key requirements to guide architectural direction and also design/implementation to support mitigation of risks/threats via compensating controls and/or countermeasures or, enable the transfer of risk to other parties, acceptance as a business risk (exception process) or, seek avoidance.

Back to Security Basics

As a sidebar – the theme of the Adaptive Security Architecture Series blog is “Back to Basics“. We live in a world of rapid deployment but over time it results in a complex and fragmented infrastructure that increases the cost of operations, to manage and keep secure. The same way it is good to tidy your room and get organized, there is a continuous cycle of tidying infra and getting it organized and back in line.

Threat Level

Risk and Threat Analysis

Performing a comprehensive risk analysis with technically qualified independent and objective security consultants is the most important security activity. The risk-analysis process can logically be divided into three main activities, each providing additional insight into the security needs of the overall IT environment.

  • Sensitivity Assessment
  • Risk Assessment
  • Economic Assessment

Sensitivity Assessment is used to determine the actual value of the data and the criticality of the mission that is supported by IT resources.

Risk Assessment is the most significant activity of the overall risk analysis. It is used to define threats against the IT environment, vulnerabilities, and the risks that result from the exploitation of known vulnerabilities by the defined threats.

Economic Assessment is used to examine the potential loss expectancy given various threat execution scenarios. The Economic Assessment attempts to quantify, to the greatest extent possible, loss expectancy in terms of real dollars.

A risk analysis is based on the premise that it is not possible to have a risk-free environment. Risks, therefore, must be managed based on an organization’s tolerance. Any risk can be defined as the resultant value derived from the mapping of a potential threat against known vulnerabilities and/or weaknesses.

The qualification of risks is one of the necessary activities in determining which threats should be controlled and managed. Therefore, a risk analysis is used primarily to identify those risks that could potentially impact the secrecy, integrity, and/or operational continuity of the environment being evaluated. Insights gained from the risk-analysis process can then support risk management and the cost-effective application of security countermeasures.

Security Perimeter

Security architects should define and document the security perimeter. Defining the security perimeter bounds the problem and allows the risk analysis effort to be focused and structured. In today’s network economy, perimeter definition is somewhat complicated due to convergence of networks and the softening of perimeters into multiple layers and trust zones.

In many cases, organizations must simultaneously inter-work with mobile/remote workers; offsite contractors; partner companies with many point-to-point relationships; partly-owned subsidiaries; recent, undigested acquisitions; services outsourced to application service providers (Cloud, ASPs); e-business affiliate sites – or all of the above.

Risk ManagementProcess

Understand the Environment

The risk analysis team must spend the time necessary to understand the components and technical interactions that occur in the IT environment. The team must also understand the mission that the systems, networks, and applications support and how business requirements are satisfied through IT resources. Finally, the team must work to understand the organizations that utilize IT resources, how they interact, and any unique requirements or needs they may have.

Application Role and Relationships

System decomposition involves the logical separation of the IT environment into elements. The list includes systems, networks and applications. The resulting document must list these singly and graphically identify their inter-relationships from a dependency perspective. This is covered in more detail in a separate blog on Application Architecture Taxonomy and Application Connectivity Management and an information-centric approach to security and controls. It builds upon the asset, application and information discovery in the Security Architecture Baseline post.

Identification of Threats

Potential threats are defined for each IT element. The threat-definition process should be focused on those IT information elements more mission critical or important to operational posture or information confidentiality.

Many potential threats exist; however, the likelihood of their occurring may be negligible. Threat Rejection Logic is an important aspect of the risk-analysis process. For the purpose of performing trade-off analyses, the number of initial threat models can be large, though many are subsequently discarded as irrelevant to a particular environment. Only those threats determined to be relevant to your organization should be investigated further. Once threats are identified, analyze how those threats, through a logical threat-manifestation process, could cause one of the following events to occur:

  • Unauthorized disclosure of sensitive information
  • Unauthorized modification of sensitive information
  • Denial of service

Threats should be illustrated in threat logic tree format. A logic tree enables a specific threat to be traced from a general description (e.g., denial of service) to finer granularity (e.g., resource exhaustion). Each threat is explained in detail. For example, what does SQL injection mean and why is it a relevant threat to the network?

Vulnerability to Threats

An element’s vulnerability to a specific threat must be roughly calculated in the context of that threat’s probability of occurrence. The selection of the appropriate category or level (e.g., 3-High, 2-Moderate, and 1-Low) is a function of historical data, existing documents, practical experience, and a comprehensive analysis.

Degree of Risk

To determine any given risk level, combine and analyze the severity of the threat and the element’s level of vulnerability.

Risk Matrix


Countermeasure and/or compensating control application is used to reduce risk. The value of applying a countermeasure must be quantified. In some situations, a single countermeasure can reduce or eliminate risks in several areas. For example, encrypting certain data communications reduces the risks of information compromise and information modification.

Residual Risk

Residual Risk is defined as the remaining risk value after a countermeasure(s) has been applied. Residual risk is determined by comparing the initial risk level against the utility of the selected countermeasure.

Process Iteration

It may be necessary to iterate the two previous steps until residual risk is considered acceptable. The law of diminishing returns is applicable in the application of security countermeasures. At any given time, the utility of an additional countermeasure may not increase security but may be detrimental, affecting performance and increased system maintenance costs. Risk reduction must strike a balance between the level of protection and the performance and cost of managing the security of the environment.


In summary, several benefits are realized from conducting an on-going risk analysis and management. A risk analysis defines the system(s) being evaluated and sets the tone and direction for future security engineering activities. A risk analysis provides the ability to identify problems early in any information system program and supports expeditious problem resolution, programmatic visibility, and technical cognizance. A risk analysis provides justification for the acquisition and use of security countermeasures.

Risk Process Lifecycle

Blind application of security countermeasures, without first understanding the inherent risks of the environment, is likely to be unproductive, unjustified, and costly. A future blog in this series will cover practical Information and Data Classification.

Thanks for your interest!

Nige the Security Guy.


About secureadvisor
Security Guy

7 Responses to Risk-Aware Security Architecture

  1. Pingback: Security Series Master Index | Nige the Security Guy

  2. Pingback: Threat and Vulnerability Management | Nige the Security Guy

  3. Pingback: Architecture Case Study – Part 1 | Nige the Security Guy

  4. Pingback: Architecture Case Study – Part 2 | Nige the Security Guy

  5. Pingback: Security Program Best-Practices 3 | Nige the Security Guy

  6. Pingback: Advanced Threat Defense – Part 1 | Nige the Security Guy

  7. Pingback: Security Architecture Series Guide | Nige the Security Guy

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: