CompTIA Security+: Risk Management and Business Impact Analysis

For an interesting look at dealing with risks, you can read “Antifragile.”  Otherwise, stick around for a riveting look into the world of risk management analysis from a security perspective.

This is a continuation of my blog post series on the CompTIA Security+ exam.

Businesses are around to make money.  Risk management processes allow them to maximize their returns on investment, which is to say, make more money.

Business Impact Analysis Concepts

Business impact analysis (BIA) is the process of determining the source and relative impact values of risk elements in a process.  It also outlines how the loss of any critical function will impact an organization.

What are the possible impacts?

Impact

If risk is the chance of something not working as planned, impact is the cost associated with that (realized) risk.  Impact can come in several forms:

Calculations

The book offers a number of terms and equations.  It says that the exam might ask these questions, but none of the practice questions include calculations.  Anyway…

Availability is the amount of time a system performs its intended functions.  Reliability is a measure of the frequency of system failures.

RTO is the recovery time objective.  This is the target time for the resumption of operations after an incident.

Recovery point objective, RPO, is the time period representing the maximum period of acceptable data loss.  The data loss part is the differentiator.  This relates to backup frequency.

MTBF is reliability of a system.  It’s mean time between failures.  It’s the sum of (start of downtime – start of uptime), divided by the total number of failures.

Mean time to repair (MTTR) is a measure of how long it takes to repair a failure.  This is total downtime divided by total breakdowns.

Mission-Essential Functions

Mission-essential functions are those that MUST occur.  If they don’t occur, or are performed improperly, the mission of the business is directly impacted.  As such, they need to be restored first.

Once you know what your critical functions are, identifying the systems and data that support those functions is called identification of critical systems.

If a single component can cause the failure of the entire system, it’s a single point of failure.  Make sure your mission-essential functions don’t rely on a component like this.

Privacy

Similar to a business impact assessment, the book also discusses privacy impact assessment (PIA).  This is a way of determining the gap between desired privacy performance and actual performance.  It is an analysis of how personally identifiable information (PII) is handled during storage, use and communication.  A privacy threshold analysis will determine whether PII is collected or maintained by a system (although to me, this seems fairly straightforward?)

Risk Management Concepts

These are all elements of threat assessment, risk assessment and security implementation concepts.  They all come from a business management perspective.

Threat Assessment

This is a structured analysis of threats that confront an enterprise.  You can’t change the threats, only how they affect you.  Threats might be:

Risk Assessment

This is a method of analyzing potential risk based on statistical or mathematical models.  You know what that means… even more equations!  Lucky you!

SLE is single loss expectancy.  It’s the value of a loss expected from a single event.  It’s calculated by asset value (how much it will take to replace an asset) multiplied by the exposure factor (i.e. 50% loss of functionality -> factor of 0.5).

Annualized rate of occurrence (ARO) is how many times per year you think something will happen.  This is usually based off of historical data.

Annual loss expectancy (ALE) is SLE multiplied by ARO.

A risk register is a list of risks associated with a system.  It might also include calculations or impact data for each one.

Qualitative vs Quantitative

Likelihood of occurrence for a given risk is the chance it will occur. It can be qualitative or quantitative.

Quantitative is an objective determination of the impact of an event.  This means there are numbers involved, and it’s easier to calculate risks and make decisions.

Qualitative is when you are subjectively determining risk impact.  You might not be able to provide numerical values, especially in catastrophic events.

A half-way measure between the two is when you make qualitative estimates (low, medium, high) and assign weights to the risk levels, and other factors.  These factors could include the business impact, how costly the fix will be, and so on.

Supply Chain Assessment

Keep in mind that your risk assessment should extend to your supply chain.  If you have components that have very long lead times, or are no longer in production, you face even high risk if something happens to your system.

Vulnerability and Penetration Testing

These were covered in an earlier chapter.  These are ways of figuring out what issues exist so you can mitigate or plan for them.  Make sure that you obtain authorization, in writing, before you perform either of these tests.

Change Management

This has its roots in systems engineering (where it is called configuration management).  Configuration control, on the other hand, is the process of controlling changes to an item that has been baselined.  Both of these are important when managing risk.  Structure and processes help mitigate risk.

Risk Responses

The book gets unintentionally philosophical here.  You can’t remove or eliminate a risk.  It’s an absolute.  There are other options for dealing with them, though.  You can:

Security Controls

If you want to reduce your exposure and mitigate risk by applying security controls, there are several different classes.