Archive for August, 2009

A Formula for Information Security Risk Analysis

Monday, August 10th, 2009

A recent thread on a security email list has prompted me to take a stab at explaining the risk equation I have been using for years. There have been several discussions about different risk formulas, most of them derived from the guidance in the NIST SP 800-30 documentation. One interpretation is:

Risk = Likelihood x Impact

Another is:

Risk = Threat x Vulnerability

Before you can choose an appropriate formula, it is important to first define the terms we are using:

A risk is the possibility of a threat (source) acting upon a vulnerability (weakness) causing harm to a resource.

A risk is qualified (measured) by how likely the event is to happen and how severe the consequences would be.

A resource refers to one or more computers that support a shared function and the same data flows.

Before any risk analysis can be performed, a Security Risk Profile must first be created for the resource in question.  The security risk profile gathers information about the resource to help rate its sensitivity to security risks.  Factors that are considered include Financial, Legal, and Reputational damages or Regulatory constraints/restrictions that may result from a security violation.  The idea is for the Resource Owner to rate the resource’s importance to the organization from an information security perspective and relative to the enterprise environment.  This profile should be at a high enough level that it can be completed even before any implementation decisions are made for the resource.  Resources are assigned a value (High, Moderate, Low) relative to their tolerance for risk.

A vulnerability is the weakness that makes the resource susceptible to the threat.

A threat is anything capable of acting against a resource in a manner that can result in harm (intentionally or accidentally).

The likelihood is a measure of how probable it is that the threat/vulnerability pair will be realized.

The severity is a measure of the magnitude of the consequences that result from the threat/vulnerability pair being realized for that resource.

These variables can be combined in many ways. I use two simple formulas to represent the final risk rating (which I refer to as the risk exposure):

1) Risk Exposure = Likelihood x Severity

2) Applied Risk Exposure = Likelihood x Severity x Risk Sensitivity

Keep in mind that each variable here is independent and I never use a zero.  If any component is truly zero, there is no point assessing the risk.

I use the latter equation to normalize risks across applications or environments, because it accounts for the sensitivity (or criticality) of the resource. An example of this would be assessing the risk associated with a policy exception request.

I use the former equation in Threat & Vulnerability Management exercises to prioritize remediation. For example, a team may only be responsible for resources of a certain sensitivity level, so for them it is valuable to calculate the risk without taking sensitivity into account.  If I were presenting the vulnerability risks across all the environments to senior management, I would include the sensitivity variable.

For my purposes I use this scale, but this is subjective to your environment:

Likelihood:

Critical (5) – Exposure is apparent through casual use or with publicly available information, and the weakness is accessible publicly on the Internet
High (4) – The threat-source is highly motivated and sufficiently capable, and controls to prevent the vulnerability from being exercised are ineffective.
Moderate (3) – The threat-source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability.
Low (2) – The threat-source lacks motivation or capability, or controls are in place to prevent, or at least significantly impede, the vulnerability from being exercised
Extremely Low (1) – The threat-source is part of a small and trusted group, controls prevent exploitation without physical access to the target, significant inside knowledge is necessary, or purely theoretical

Severity:

Critical (4) – May allow full access to or control of the application, system, or communication including all data and functionality
High (3) - May allow limited access to or control of the application, system, or communication including only certain data and functionality
Moderate (2) – May indirectly contribute to unauthorized activity or just have no known attack vector.  Impact may vary as other vulnerabilities or attack vectors are identified.
Low (1) – May indirectly contribute to unauthorized activity or just have no known attack vector.  Impact may vary as other vulnerabilities or attack vectors are identified.

Risk Exposure:

1 – 4 Low -  May have some minor effect on the system, but likely little impact to the organization overall.  Recovering from such an impact will require minimal expenditures and resources.  A single issue, by itself, may not place the integrity, availability, or confidentiality of a system at risk.  Multiple issues in this category could be combined, however, in an exploit attempt.
5 – 7             Moderate - May result in some tangible impact to the organization.  The impact could be narrow in focus and perhaps only noted by a few individuals or parts of the organization. May cause organizational embarrassment.  Recovering from such an impact will require some expenditure and resources.
8 – 11          High - May cause an extensive system outage, and/or loss of customer or business confidence.  May also result in compromise of a large amount of the organization’s information or services, including sensitive information.  Recovering from such an impact will require a substantial amount of expenditure, resources, and time.  These vulnerabilities should be taken seriously and addressed quickly.
12+             Critical - This level of risk exposure is unacceptable for any aspect of the environment.  It introduces a level of exposure that cannot be maintained over time.  The remaining categories may be acceptable depending on the risk tolerance range.

Applied Risk Exposure:

1 – 8             Low -  Acceptable without review by management
9 – 25         Moderate -   Management must determine whether corrective actions are required or decide to accept the risk
26 – 39      High -  Undesirable and requires corrective action.  A plan must be developed to incorporate these actions within a reasonable period of time based on the discretion of management.
40+             Critical -  Undesirable and requires immediate corrective action

I hope people find this helpful.  It is the result of developing these models for many years and for many different organizations, but mostly in the financial sector.  I have taken bits and pieces from the NIST, OCTAVE, and COSO frameworks and developed a model that works for me.

Launching New Forensics Blog Site with RSA

Saturday, August 8th, 2009

I am thrilled to announce that I launched a new blog last week on the RSA365 Conference site (https://365.rsaconference.com/blogs/cybercrime).  This new blog will focus specifically on Digital Forensics.

Together with four other friends and colleagues in the field, we will be discussing weekly topics related to digital forensics.  I hope this blog will provide a different perspective on this area of information security from what is already available online.

The following is the description of the blog:

Take a Byte Out of CyberCrime

A star panel of digital forensic and incident response experts discuss a proactive approach to forensics, covering preventative measures to implement before an incident occurs.

The other members of our virtual panel are:

  • Jim DeLorimier – CIRT/Forensic Team Leader, NJ Manufacturer’s Insurance
  • Eric Gentry – Principal Consultant, Verizon Business
  • Lt. John McLean – Detective, NEMLEC Computer Crime Unit, Medford Police
  • David Thomas – Attorney, Greenberg Traurig, LLP

I hope you will find these discussions helpful when preparing for future investigations.