Kamis, 05 Mei 2005

Risk, Threat, and Vulnerability 101

In my last entry I took some heat from an anonymous poster who seems to think I invent definitions of security terms. I thought it might be helpful to reference discussions of terms like risk, threat, and vulnerability in various documents readers would recognize.

Let's start with NIST publication SP 800-30: Risk Management Guide for Information Technology Systems. In the text we read:

"Risk is a function of the likelihood of a given threat-source's exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization. To determine the likelihood of a future adverse event, threats to an IT system must be analyzed in conjunction with the potential vulnerabilities and the controls in place for the IT system."

The document outlines common threats:

  • Natural Threats: Floods, earthquakes, tornadoes, landslides, avalanches, electrical storms, and other such events.

  • Human Threats Events that are either enabled by or caused by human beings, such as unintentional acts (inadvertent data entry) or deliberate actions (network based attacks, malicious software upload, unauthorized access to confidential information).

  • Environmental Threats: Long-term power failure, pollution, chemicals, liquid leakage.


I see no mention of software weaknesses or coding problems there. So how does NIST define a vulnerability?

"Vulnerability: A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy."

The NIST pub's threat-vulnerability pairings table makes the difference between the two terms very clear:



SP 800-30 talks about how to perform a risk assessment. Part of the process is threat identification and vulnerability identification. Sources of threat data include "history of system attack, data from intelligence agencies, NIPC, OIG, FedCIRC, and mass media," while sources of vulnerability data are "reports from prior risk assessments, any audit comments, security requirements, and security test results."

The end of SP 800-30 provides a glossary:


  • Threat: The potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.

  • Threat-source: Either (1) intent and method targeted at the intentional exploitation of a vulnerability or (2) a situation and method that may accidentally trigger a vulnerability.

  • Threat Analysis: The examination of threat-sources against system vulnerabilities to determine the threats for a particular system in a particular operational environment.

  • Vulnerability: A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.


For those of you Microsoft-only shops, consider their take on the problem in the The Security Risk Management Guide. Chapter 1 offers these definitions:

  • Risk: The combination of the probability of an event and its consequence. (ISO Guide 73)

  • Risk management: The process of determining an acceptable level of risk, assessing the current level of risk, taking steps to reduce risk to the acceptable level, and maintaining that level of risk.

  • Threat: A potential cause of an unwanted impact to a system or organization. (ISO 13335-1)

  • Vulnerability: Any weakness, administrative process, or act or physical exposure that makes an information asset susceptible to exploit by a threat.


Microsoft then offers separate appendices with common threats and vulnerabilities. Their threats include catastrophic incidents, mechanical failures, malicious persons, and non-malicious persons, all with examples. Microsoft's vulnerabilities include physical, natural, hardware, software, media, communications, and human. Microsoft clearly delineates between threats and vulnerabilities by breaking out these two concepts.

I'd like to add that the comment on my earlier posting said I should look up "threat" at dictionary.com. I'd rather not think that "security professionals" use a dictionary as the source of their "professional" understanding of their terms. Still, I'll debate on those grounds. The poster wrote that dictionary.com delivers "something that is a source of danger" as its definition. Here is what that site actually says:

  1. An expression of an intention to inflict pain, injury, evil, or punishment.

  2. An indication of impending danger or harm.

  3. One that is regarded as a possible danger; a menace.


Remember what we are debating here. I am concerned that so-called "security professionals" are mixing and matching the terms "threat" and "vulnerability" and "risk" to suit their fancy.

Here's vulnerability, or actually "vulnerable":

  1. Susceptible to physical or emotional injury.

  2. Susceptible to attack: “We are vulnerable both by water and land, without either fleet or army” (Alexander Hamilton).

  3. Open to censure or criticism; assailable.

  4. Liable to succumb, as to persuasion or temptation.


You'll see both words are nouns. But -- a threat is a party, an actor, and a vulnerability is a condition, a weakness. Threats exploit vulnerabilities.

Finally, risk:

  1. The possibility of suffering harm or loss; danger.


Risk is also a noun, but it is a measure of possibility. These are three distinct terms. It is not my problem that I define them properly, in accordance with others who think clearly! I am not inventing any new terms. I'm using them correctly.

I'd like to thank Gunnar Peterson for reminding me of the NIST and Microsoft docs.

Rabu, 04 Mei 2005

OCTAVE Properly Distinguishes Between Threats and Vulnerabilities

You may have heard of Carnegie Mellon's Software Engineering Institute. Within SEI's Networked Systems Survivability program is the Survivable Enterprise Management group. Members of this group developed the Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) method. OCTAVE is "a self-directed approach for assessing and managing information security risks. OCTAVE allows an enterprise to identify the information assets that are important to the mission of the organization, the threats to those assets, and vulnerabilities that may expose the information assets to the identified threats." Already you should notice that the OCTAVE crew is using the terms risk, asset, threat, and vulnerability properly. In fact, a look at the OCTAVE Threat Profiles (.pdf) document reveals additional understanding of the differences between threats and vulnerabilities:

"Below is an expanded classification of threat actors.

  • non-malicious employees: people within the organization who accidentally abuse or misuse computer systems and their information

  • disgruntled employees: people within the organization who deliberately abuse or misuse computer systems and their information

  • attackers: people who attack computer systems for challenge, status, or thrill

  • spies: people who attack computer systems for political gain

  • terrorists: people who attack computer systems to cause fear for political gain

  • competitors: people who attack computer systems for economic gain

  • criminals: people who attack computer systems for personal financial gain

  • vandals: people who attack computer systems to cause damage"


What, no mention of problems with Microsoft RPC services on port 135 TCP? No Cisco router denial of service condition? OCTAVE and the SEI know the difference between threats and vulnerabilities and they speak authoritatively on the subject. Kudos to them for being rigorous with their terms and work.

Selasa, 03 Mei 2005

There's more coming out of the Forum of Incident Response and Security Teams (FIRST) these days now they've updated their Web page! I just read an announcement that the Department of Homeland Security has named FIRST the custodian of the Common Vulnerability Scoring System (CVSS). CVSS is a way to quantify the severity of a vulnerability using three groups: a base metric group, a temporal group, and an environmental group. The sample scoring shows some of the values for recent vulnerabilities.

The definitive documents on CVSS are available on the FIRST CVSS site. I think this system will have some legs, so keep an eye on it. My only concern is that some documents which explain CVSS confuse threats with vulnerabilities -- a common theme on this blog. Consider the following:

"Current scoring systems, in use by the Computer Emergency Response Team/Coordination Center (CERT/CC), Symantec, Internet Security Systems, Cisco Systems, and others, rate vulnerabilities according to a variety of metrics and determine a single overall threat score by weighing these metrics."

They shouldn't say "threat score"; they mean "vulnerability score."

Further in the document we read this:

"Common causes of vulnerabilities are design flaws in software and hardware, botched administrative processes, lack of awareness and education in information security, technological advancements or improvements to current practices, any of which may result in real threats to mission-critical information systems."

Again, there's no threat here. A threat is a party with the capabilities and intentions to exploit a vulnerability. Either "vulnerabilities" or "risks" is more appropriate here.

Another case:

"Potential Threat: These are vulnerabilities that are dependent on the exploitation of other vulnerabilities before they become a risk."

Argh, this is even worse, as it defines a threat as a vulnerability. Wrong again.

"Real-time Attack Scoring: CVSS does not have any capacity for tracking the threats posed by the ongoing exploitation of vulnerabilities."

They probably mean "risks" here.

"A vulnerability that is remotely exploitable is considered to be a higher risk threat than one that is only locally exploitable, since the pool of potential attackers is greater."

Great, all three terms are mixed up here. Delete "threat" from the sentence and it makes more sense.

So what is the document I've been citing? It's the National Infrastructure Advisory Council, in their final recommendations and report on CVSS available in .pdf form here. At the time the report was written, John Chambers (CEO of Cisco) and John Thompson (CEO of Symantec) were in charge. I would expect them to exercise a little more intellectual rigor on the documents their group produces. I have no expectations at all that a report headed by someone like my favorite graduate professor Phil Zelikow would make these sorts of amateur mistakes!

While on the subject of vulnerabilities, it's worth noting the release of the latest SANS Most Critical New Vulnerabilities Discovered or Patched During the First Quarter of 2005. Let's see if they can keep threats and vulnerabilities as distinct ideas:

"However, since new Internet threats are discovered daily, user organizations that rely on the Top20 as a list of high priority threats have been asking for more frequent updates."

I guess not. In both cases they mean vulnerabilities here. Nothing has changed since I last reported on this semantic muddle. Oh well.

Minggu, 01 Mei 2005

TaoSecurity Announces Network Security Operations Class

img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYKHiguSwVRJZEdROlQWyvthmxWTLC3QTDiDvUxg46HtObfVUH_hn2bRcLQ-j7c-ihbNh6EVQqxBSx6BaL3JNP02lnZn4L1Ceiw-v-7W7iTnuSaJ53hDscpZ_3tAnWbdSpSwRaC-23a_E/s1600/taosecurity_s.png" align=right>I am proud to announce that flyers are available for my new four-day class Network Security Operations. You can view either the color .pdf or the grayscale .pdf formats. The course offers four sections:

  1. Network Security Monitoring

  2. Network Incident Response

  3. Network Forensics

  4. Live Fire Exercises


For more information, please refer to the flyers, and email richard at taosecurity dot com. Thank you!

Report from the CISSP Exam

No, I did not take the CISSP test again -- thank goodness. A friend of mine just did, however. He agreed to share his story with you.

"I attended the Intense School CISSP bootcamp last week and took the test last Sunday. I received my test result today and I passed! It was the hardest and most obscure test I have ever taken. I was convinced I did not pass. Usually, I perform well on test, but this was a monster. I never want to take it again and wouldn’t wish my version of the test on anyone!

It took me two hours and 50 minutes. I guess that is fast compared to the average. I can’t imagine sitting there for six hours staring at those questions. I just answered/guessed and moved on and didn’t go back and change any answers. I think I was the first CISSP test taker done in the room. I am so relieved."

I had the same experience almost four years ago, except I finished in 90 minutes. The room was so cold, I just wanted to be done and get out of there as fast as possible!

I thought a majority of the CISSP questions were silly and had nothing to do with real security practitioner work. As I've written before, the main reason I took and held the CISSP cert was its Code of Ethics. This is one of the features that separates professionals from the rest of the field, in my opinion.

Sabtu, 30 April 2005

Reviews of VoIP Security, The Internet and Its Protocols Posted

I refused to let April end without finishing and reviewing these two books kindly provided by Elsevier Press. The first was a disappointment. Amazon.com just posted my three star review of VoIP Security. From the review:

"I decided to read VoIP Security because I thought it would describe VoIP protocols and ways to secure them. The table of contents looked very strong and the preface seemed to meet my goals: "For one to truly understand Internet telephony, the reader must have a solid understanding of digital voice, telephony, networking, Internet protocols, and, most important of all, how all of these technologies are put together." Unfortunately, the book is confusing at times and is not an improvement over earlier VoIP security books. So-called 'reviewers' who write that this book 'goes heavily into explaining the low level mechanics of VoIP' reveal they don't read the books they purport to review."

Thankfully, I was very pleased to read the second book Elsevier sent me. Amazon.com just posted my five star review of Adrian Farrel's The Internet and Its Protocols. From the review:

"Adrian Farrel's The Internet and Its Protocols (TIAIP) blew me away. I read this book because it explains the Internet I know, but also how new protocols work with that Internet and make it different from the network I first encountered over a decade ago. Farrel's amusing yet clear writing style delivers a great deal of knowledge in a hefty hardcover. If you want to learn about the protocols that make the Internet work, you need to read TIAIP."

If you want to get a handle on the new protocols appearing in your network, like Multi-Protocol Label Switching (MPLS) or Stream Control Transmission Protocol (SCTP), you should read The Internet and Its Protocols.

FreeBSD 5.4-RC4 Imminent

As I guessed recently, we should see FreeBSD 5.4 RELEASE arrive next week or very soon thereafter. Scott Long posted an update on the release status of 5.4 this morning. He says:

"As you probably noticed, we are a bit behind on the 5.4 release. There was a major stability problem reported several weeks ago in a particlar high load, high profile environment, and we decided that it was in everyones best interest to get it resolved before the release. Well, thanks to the tireless efforts of Doug White and Stephen Uphoff and several others, the bug has been found, fixed, and verified. As soon as it and a few other fixes get merged in, we will start the RC4 build process and hopefully release it for testing late this weekend. After that, unless another show-stopper comes up, we expect to build and release 5.4-RELEASE next weekend."

I hope to test 5.4-RC4 this week, assuming it arrives tomorrow. Thanks FreeBSD release team!