ja_mageia

Apple has fixed an RSS vulnerability in Safari discovered by Clint Ruoho of Laconic Security, Brian Mastenbrook and Billy Rios of Microsoft. The patches are contained in Security Update 2009-001 and Safari 3.2.2.
Home Blog Risk The Elements of Risk
The Elements of Risk
Written by Fred Thiele   
Friday, 28 March 2008 06:15
Ask 10 security experts what risk is and you will get 10 different answers. Risk is the art/science of balancing the potential for financial loss with effective countermeasures to reduce or prevent that loss. Simply stated, risk is the measure of financial uncertainty inherent in business operations.

Risk is also a business issue. As such, we (as security professionals) must present risk in a way that makes sense to the business, not just security people. To effectively communicate risk, it must be interpreted consistently across the organization and be explained clearly to all business units.

No matter if the subject is project risk, legal risk or information security risk, the elements or risk are all very similar:

  • The frequency of some negative event occurring
  • The potential for that event to be successful
  • The financial impact of that successful event

Utilizing these elements, information security risk is defined by the following equation:

Risk = Threat x Vulnerability x Impact

Where threat is a frequency, vulnerability is binary (yes/no) and impact is a dollar amount. Note, that if any of these numbers are 0, the answer to risk is zero (which is also very important when explaining information security risk). For example, an organization may be constantly bombarded by the latest Unix vulnerability, but if the organization is a Microsoft shop (i.e., vulnerability is 0), there is no Risk.

I find that risk is one of the most commonly misunderstood concepts in information security. This is because risk is a difficult and abstract notion. Most people interchange threat, vulnerability and risk, using them as if all three were the same thing.  This confusion may seem to be a semantic mix-up at first, but it can lead to organizational  dysfunction when performing risk assessments and making business decisions based on those assessments.

So what is the best way to explain abstract ideas such as risk? Risk isn’t vulnerability, nor is it threat. So how do you explain this to a director, executive, manager or technologist? The easiest way I’ve found is by using something we’re all familiar with: a sentence. A risk sentence, or statement of risk, is the backbone of any risk analysis. Remember, our formula calls for threat, vulnerability and impact to be part of risk. Here is an example:

A malicious attacker compromises the confidentiality of a database by performing an SQL  injection attack against an internet facing web application resulting in a loss of data and a public disclosure of the theft.

A fairly straight forward picture is painted of a situation in which we account for all aspects of risk. For a risk-minded security person , this statement is something we think about every day. But for the rest of the enterprise (e.g., everyone outside the security group) it is an imperative that we explain each aspect to effectively communicate risk.

Let’s dissect the elements of risk in this sentence.

Subject Action Object


[A malicious attacker][compromises the confidentiality][of a database]…

This is the threat, which in itself, consists of many pieces. First, the subject: a malicious attacker. Second, the action: compromises the confidentiality. Third, the object: a database. So a threat is defined as a subject, action and object.
Our job as security professionals in risk analysis is to determine the frequency of this event. Unfortunately, a good set of actuarial data to determine how often attackers successfully compromise databases is non-existent. Many vendors publish numbers, and research firms spend thousands on studies, but most of these numbers are very subjective and based on a very limited set of data (i.e. the data is not statistically representative). Furthermore, studies contradict themselves so determining an accurate number often comes at the price of a high margin of error.

…by performing an SQL injection attack against an internet facing web application…

This is the vulnerability. The web application is vulnerable to an SQL Injection attack . If the application was not vulnerable in the first place, there would be no risk and therefore the risk statement would be not applicable.

NOTE: this vulnerability statement does not account for layered controls (i.e., defense in depth) , it is focused on individual vulnerability. When performing risk assessments, there will be many other factors that play into vulnerability, including effectiveness of layered controls. When considering compensating controls, vulnerability normally takes on a less binary and more statistical property.

…resulting in the loss of data and a public disclosure of the theft.

This is the impact. A loss of data that results in public disclosure of the incident has many financial impacts, both direct and indirect. Consider that the incident may result in fraud charges (direct costs). If you lose 200,000 credit card numbers, the card issuers will charge your company to reissue cards. These are tangible amounts that can be estimated rather accurately.

What about the intangibles? How does this breach negatively impact your brand image in the marketplace? What are the costs of marketing, PR and legal surrounding an incident of this nature? How widespread is the incident? All of these difficult to answer questions are reasons risk analysts are paid to do what they do. This is also the hardest part of a risk assessment – accurately assessing intangible financial impact.

Risk assessments are widely misunderstood in the enterprise. To effectively communicate risk, security personnel must ensure risk is understood at the highest level of the company, commonly defined and incorporated across all other risk programs within the organization.

About the author: Fred Thiele has developed quantitative risk programs for the upper echelon of Fortune 500 companies and has implemented risk-based security programs for government contractors. Fred has an extensive background in risk-based compliance, penetration testing, business intelligence, professional services and managed security services over the past ten years of his infosec career.

 

Corporate Brochure

Download the Laconic Security corporate brochure.