Risk is defined as an exposure to loss, injury, or damage due to threats, vulnerabilities, and attacks. Risk management is to manage the risks.
Identifying threats and vulnerabilities, attacks, estimating potential impact, and establishing and implementing suitable controls to treat the risk are functional steps in risk management. Monitoring, reviewing, communicating the results, and improving the security posture are continual improvement processes in the risk management cycle.
Observe the following illustration, which is a typical web application network infrastructure consisting of the N-tier architecture:
Fig 2
In the preceding architecture, various assets are involved in the business process of accessing, updating, or modifying the information. For example, an employee (people asset) accesses a web application (information asset) in a web server (hardware and software assets). The web application accesses the application server, which in turn accesses and processes the data in the database server. In this chain of connections and processes, each asset will have certain levels of CIA requirements. For example, the applications in the application server and the data they access will have higher confidentiality and integrity requirements than the web server. Also, observe that there are some existing controls, such as the firewall, authentication systems, and access control mechanisms.
Threat is an event that could compromise the information security by causing loss or damage to assets. The threat is predominantly external to an organization. Examples of threats are fire, flood, hacking, and so on.
Vulnerability is a hole or a weakness in the system. Threat can exploit vulnerabilities through its agents called threat agents. For example, having no antivirus software is a vulnerability, which a threat agent like a virus could exploit. Similarly, hacking is a threat that could exploit a weakness in the system through its agent, for instance, a hacker.
A threat event exploiting a vulnerability is called as an attack. The end result of an attack can lead to a security violation. An attack either compromises a security control or lack of it and can affect the CIA requirements of the asset.
Note
Having vulnerabilities and threats alone may not end in attacks. An attack can be a motivated action to commit financial fraud or adventure action, such as stopping a service or adversarial action for competitive gain, revenge, and so on. Proper assessment has to be done to ascertain the chance of an attack, the tenet of CIA it can affect, and the resulting damage if the attack succeeds. In a nutshell, attacks can either be motivated or inadvertent.
Observe the following illustration, which now provides threat and vulnerability scenarios in the same network depicted earlier. It is apparent, that due to vulnerabilities in the system, threat agents may be able to attack and possibly succeed in penetrating the network and obtain confidential information, alter sensitive data, or stop a service. However, we still do not know yet that such an attack could materialize with prevailing controls in place. But we will be able to estimate the possible impact if such an attack materializes. In other words, we will be able to estimate potential loss.
Fig 3
Hence, in a threat risk modeling process, the following steps are necessary to estimate potential loss:
- Identify assets and their CIA requirements.
- Identify threats to those assets.
- Identify vulnerabilities in those assets.
- Identify attack possibilities.
- Identify existing controls.
- Perform vulnerability assessment and penetration tests on the assets and the infrastructure.
- Estimate risk (potential loss).
We have reviewed assets and CIA requirements of assets in the previous chapter. The rest of the steps are covered in the following topics.
In a threat risk-modeling scenario, the infrastructure/application has to be broken down into various types of assets. Observe the following flow diagram:
Fig 4
During threat and vulnerability analysis, the following questions are pertinent to determine the risks:
Q1. What are the security objectives (requirements)?
Security objectives are based on policies, such as the information security policy, legal/regulatory requirements as mandated in privacy laws, Service Level Agreements (SLA) as required in infrastructure availability, or data integrity assurance requirements as required in financial transactions.
Q2. What is the overall infrastructure?
What are the individual components in the infrastructure? What are the CIA values of the assets (people, infrastructure, application, data, and so on)? Will the CIA values change due to certain factors? If so, what are those factors?
Infrastructure consists of physical security requirements, such as secure locations, and environmental requirements, such as clean power, heating, ventilation and air conditioning, and so on.
Application security requirements are based on access control, data flows, trust boundaries, and so on.
Q3. What threats are applicable based on the type of assets (threat register)? What are the prevailing threats to these assets?
Identify and document threats to the infrastructure, threats to the application, and threats to data.
Q4. What are the vulnerabilities (vulnerability register) that these threats can compromise? Which of these vulnerabilities are identified in these assets?
Identify and document vulnerabilities in infrastructure, applications in data flow, and so on.
When a corporation compiles the answers to the preceding questions, it is in the process of threat and vulnerability analysis. The end result of such an exercise will be a documented matrix of assets, threats, and vulnerabilities.
Based on the matrix of threats and vulnerabilities and based on the results of security testing, a few attack scenarios can be constructed. Such a scenario is called as an attack tree.
Observe the following single dimensional attack tree. This attack tree is based on Fig 2 in the previous page:
Fig 5
Tip
Note that some of the technical jargon used in the illustration, such as custom payload, CSRF, and so on, is covered in Chapter 6, Day 6 – Security Engineering - Security Design, Practices, Models, and Vulnerability Mitigation.
Hence, an attack tree is constructed based on the following questions:
Q1. What are the various attacks that are possible based on the type of assets (attack vectors)?
Attack possibilities can be created based on vulnerability assessment, penetration testing, application security testing, and also based on the existing documentation of attacks that are available from trusted sources.
Q2. What will happen when the attack succeeds?
Identify the system or data that will be compromised, CIA values that will be affected and so on. It is also important to identify cascading effects of such a compromise. For example, if an attacker compromises a webserver, will the other servers that have trust relationships established with the webserver be compromised?
Q3. What will be the loss? Is the loss quantifiable?
Identify loss in terms of money, time to recover, policy violation and its impact, loss of competitive advantage, customer loss, compliance violation and its impact, and so on.
Tip
Threat, vulnerability, and attack analysis provide information to perform risk analysis. Few online dictionaries and databases are available that provide common weaknesses and attack possibilities to applications or to infrastructure and so on. References and URLs for such resources are provided in Chapter 5, Day 5 — Exam Cram and Practice Questions.
Risk is an exposure to loss or damage due to threats, vulnerabilities, and attacks. Hence, risk analysis is used to estimate the probability of an attack, identify prevailing controls and their effectiveness in combating the attacks, and estimate the consequence of such an attack in terms of potential loss.
Risk has to be understood from the following perspectives:
- Risk to what?
Risks are generally to assets. Assets can be tangible or intangible.
- Risk from what?
Risks are from threat sources, such as earthquakes, floods, hacking, fires, viruses, disgruntled employees, and so on.
- Risk of what?
When an asset is compromised by a threat, it may result in a security violation. Hence, there could be loss or damage. The damage can be monetary loss, image loss, customer loss, or legal issues. Hence, there is a risk of losing money, a risk of losing customers, or a risk of facing legal/regulatory consequences due to the security breach.
The damage caused due to a security violation is called as an impact. The magnitude of such an impact is the potential loss or, in other words, risk.
If the magnitude of an impact can be calculated in monetary terms (say, a dollar value), then the risk is defined in quantitative terms. If the magnitude cannot be determined in terms of monetary value, but can be measured in relative terms (such as high, medium, or low), then the risk is defined in qualitative terms.
In terms of information security, ISO/IEC 27000 defines risk as the probability of a threat exploiting the vulnerability and the consequence of loss or damage to the asset due to that event. This is called probability versus consequence analysis and is a type of risk analysis.
Note
Different types of risk assessments can be conducted based on the type of assets and applicability and based on regulatory requirements. Some of them are, Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE), Asset based risk assessment method based on ISO/IEC 27005, NISTSP 800:30, DREAD, and so on. References to many such risk assessment methodologies and a brief overview of them are provided in Chapter 5, Day 5 — Exam Cram and Practice Questions.
The results of probability versus consequence risk analysis will provide four scenarios. Refer to the following illustration (Fig 6):
Fig 6
- The probability is low and the consequence is low, represented as the green zone at the bottom left corner
- The probability is low and the consequence is high, represented as the amber zone at the top left corner
- The probability is high and the consequence is low, represented as the amber zone at bottom right corner
- The probability is high and the consequence is high, represented as the red zone on top right corner
By systematically analyzing the probability of a threat exploiting vulnerability and the related consequences, one can deduce the risk.
The process of determining the risk level in terms of threats and a vulnerabilities and the probability versus consequence analysis is called risk analysis. In other words, risk analysis is a systematic process of identifying the risks and estimating the loss if the risk materializes.
In the risk analysis process, related parameters of threats, vulnerabilities, and attacks are taken into consideration to derive a value. The value can be a number (quantitative) or an expression (qualitative). This derived value is called the risk value. For example, an insurance agent may consider different parameters, such as age, health conditions, hereditary diseases, habits, and so on, before determining a premium for life insurance. Similarly, in information security, parameters are based on assets, their required CIA values, threats, vulnerabilities, and attacks.
Risk analysis process involves two distinctive activities. One is to measure the impact of the risk. The analysis process tries to estimate the loss in terms of monetary value if a risk materializes. However, assets are tangible or intangible in nature. It is not possible to always determine the value of assets in monetary terms. Hence, two types of analysis are used to determine loss expectancy. One is called quantitative risk analysis and the other is called qualitative risk analysis.
Both quantitative and qualitative risk analysis processes require that the value of the asset is determined. The terms of reference by which the significance of the risk is determined called are risk criteria.
This type of risk analysis provides risk values in numeric terms. For example, monetary loss. In other words, quantify the risk or derive a dollar value of a risk. Mathematical models are available to estimate the monetary value of a risk. One such model is provided here.
When a threat event happens, the percentage of loss of an asset is based on its exposure level to that particular threat. Generally, an exposure level is represented in terms of a numerical value between 0 and 1.
For example, refer to the network diagram in Fig 3. The web server has a higher exposure level from external sources than the application server . It is possible to approximate this exposure level based on threats, vulnerabilities, and attacks. The primary firewall in Fig 3 has a weak rule that allows a custom payload to be deployed on the web server. If the web server contains a confidential file that can be obtained due to the attack, then the exposure value of the web server and the file will be 1.
If an exposure value is represented in percentage, then the percentage will be called the Exposure Factor (EF) of that asset. In the preceding web server example, the exposure value will be 1, which will give an exposure factor of 100%. Exposure factor is calculated based on the other controls that are in place. For example, if the web server is protected with a host-based firewall or privilege-based access controls are implemented, then the exposure factor will be less.
When a monetary value or a dollar value is assigned for the expected loss due to a single threat event, it is called Single Loss Expectancy (SLE), whereas, the monetary value of the asset is called the Asset Value (AV).
SLE is the AV multiplied by the EF. In other words, SLE = AV X EF. In the previous example, assuming the asset value of the confidential file is $10, then SLE = 10 X 100% = $10.
The estimated frequency or probability of a threat event occurring in a year is called Annualized Rate of Occurrence (ARO). For example, if the web server is compromised five times in a year, ARO = 5.
When SLE is multiplied by ARO, the resultant value is called Annualized Loss Expectancy (ALE). In this example, ARO = 10x5 = $50.
ALE is a dollar figure that is a quantified financial loss per annum.
Qualitative risk analysis provides risk values in relative terms, such as a rating scales. For example, high, medium, or low; or a grading scale of 1, 2, 3; or red, amber, green, and so on.
For example, if an asset value is categorized as high, medium, or low based on the business impact, then the risk will be based on such rating scales rather than monetary values.
Using risk analysis methods, either quantitative or qualitative risk values are obtained. This activity of assigning values to risk is called risk estimation. Once the risks are identified, it is important to understand their significance in terms of the impact to the business. This process of estimating the impact is called risk evaluation. Overall, the process of risk analysis and risk evaluation is called risk assessment.
Based on the risk assessment, suitable strategies are devised to mitigate the risks. These strategies are called controls or counter measures, which are safeguards against the risk. There are four types of risk mitigation strategies followed in the information security domain:
Fig. 7
- Risk acceptance is a strategy adopted when both probability and consequence are low. For example, if the cost of protecting the file is higher than the cost of controls, then the risk may be accepted. That is, the consequence is lower than the control cost.
- Risk reduction is a strategy adopted when the probability is high and the consequence is low. For example, not storing a confidential file in the web server or controls, such as encryption, will reduce the risk of disclosure of confidential files.
- Risk transfer is a strategy adopted when the probability is low and the consequence is high. For example, threat event, such as earthquakes or other natural calamities. When the probability is low and the consequence is high, implementing a control may be cost prohibitive, but accepting risk could be catastrophic. In situations like these, transferring risk through insurance would be most appropriate.
- Risk avoidance is a strategy adopted when both the probability and the consequence are high. Risks that will have a catastrophic impact on the business have to be avoided or, by using disaster recovery methods, moved to an acceptable level.
Suitable plans need to be drawn up and controls are identified to mitigate the risks. Such plans are called risk treatment plans.
Coordinated activities to manage the risk by way of risk assessment, risk treatment, risk acceptance, risk communication to stakeholder, risk monitoring, and risk review are collectively called risk management.
Due to the heterogeneous nature of information systems, even after applying the controls, it may not be possible to assure either 100% security or 0% risk to assets. There is an amount of risk that will remain after implementing safeguards. This risk is called residual risk. For example, assume the SLE for the company website is 50,000. The EF is currently 1. Firewall A will reduce the EF to .10 and cost 10,000. Firewall B will reduce the EF to .0 and cost 50,000. Going with Firewall A will cost 40,000 less, but will still leave you with 5,000 of residual risk. Given that it would cost 40,000 to remove 5,000 of the risk, it is prudent to allow residual risk instead of implementing additional controls. In this scenario, risk acceptance is the best strategy.
Generally, risk mitigation strategies for confidentiality and integrity-related risks are implemented through various operational and technical means. They are covered in domains, such as cryptography, telecommunication network security, access control, and so on. Risk mitigation strategies to address risks in terms of the availability of assets is addressed through the business continuity management processes.
In the business continuity domain, the focus is on specific threat events that could have a devastating impact on the functioning of the organization as a whole and the IT infrastructure in specific. Examples of such events are fires, floods, earthquakes, tornados, terrorist attacks, and so on.
Generally, an organization may not have controls to prevent such events. Such events are termed as disruptive events. In other words, an event that could impact regular operations for a prolonged period of time is a disruptive event. Hurricane Katrina, the attacks on the World Trade Center in 2001, or the collapse of large organizations, such as Enron, are examples of disruptive threat events.
Business continuity management involves the following:
- Risk analysis and review to identify disruptive threat events
- Business Impact Analysis (BIA) to estimate potential
- Strategies for safeguarding business interests
- Business Continuity Plans (BCP) that are instituted to respond to potential threats
- Tests and exercises to verify the continuity processes
- Regular and systematic reviews through program management
Business continuity management consists of policies as stipulated by the senior management, processes that involve business continuity-related activities, people with required skill sets, and infrastructure resources to support critical business functions.
Addressing the risks by way of plans and procedures for the continuation of business operations during and after a disruptive event is called Business Continuity Planning (BCP). The aim is to prevent interruptions to business operations.
This domain is concerned with the continuation of critical business processes and business support systems in the event of an incident, emergency, or disaster. For example, critical business processes may include accounting, payroll, Customer Relationship Management (CRM), and so on.
BCP involves the following:
Fig. 8
- Scoping in terms of assets, operations, and business processes.
- Initiating the planning process.
- Performing Business Impact Analysis (BIA).
- Developing the BCP.
- Implementing, testing, and creating awareness.
- Maintenance of plans.
While designing the BCP, availability should be considered the primary factor. The objective of BCP is to avoid any serious damage to the business also to enable the recovery of information systems within an acceptable timeframe. This time frame is derived from Business Impact Analysis.
Note
Business Impact Analysis (BIA) is a type of risk assessment exercise that tries to assess qualitative and quantitative impacts on the business due to a disruptive event. Qualitative impacts are generally operational impacts, such as the inability to deliver, while quantitative impacts are related to financial losses.
BCP should be as follows:
- Appropriate: The scoping process should cover the essential resources
- Adequate: Based on BIA, the adequacy of available resources pertaining to continuity and recovery should be established
- Complete: The plan should include all of the resources required based on the analysis
BCP resources should include the availability of processes and the availability of people to implement the processes.
The BCP process should include testing the plans and day-to-day functions/activities to be performed to make the plan effective and ready at all times.
BCP measures should include preventative measures to control known issues and facilitating measures to act in a timely manner on the issues that are not under the control of the organization.
BCP should identify mission-critical systems, business impact due to the nonavailability of critical systems (loss of revenue, loss of profits, inability to comply with laws, damage to reputation, and so on), preventive controls, and recovery controls.
BCP objectives should include recovery time by way of Recovery Time Objectives (RTO) and recovery points by way of Recovery Point Objectives (RPO).
Note
Recovery Time Objective (RTO): A timeframe within which the systems should be recovered (indicated in terms of hours/days). For example, if RTO is less than 8 hours, then a virtual environment with active/passive data center will an be significantly faster.
Recovery Point Objective (RPO): The maximum period of time (or amount) of transaction data that the business can afford to lose during a successful recovery. For example, if RPO is 10 mins, then the backup plan should be to conduct backups every 10 mins.
Business continuity procedures should include the procedure for testing plans and the procedure for updating plans.
The BCP should include the following:
- Notification
- Call trees
- Response teams
- Updating mechanism for contacts
- Step-by-step procedure for recovery
- Appropriate testing
- Restoring normalcy to the primary website or stable state
- Required records and the format of the records
- Awareness of people