Perimeter
6/3/2009
02:45 PM
John H. Sawyer
John H. Sawyer
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Security Incident Ratings Made Easy

Management likes numbers. They get the the warm fuzzies when numbers can be graphed in a way that they can quickly discern what's going on. Of course, if the numbers are bad, then they may not feel those warm fuzzies. In the IT security world, we try to provide useful numbers to show what a great job we're doing, but it's hard to quantify thwarted attacks -- other than relying on numbers from an IPS and anti-malware system.

Management likes numbers. They get the the warm fuzzies when numbers can be graphed in a way that they can quickly discern what's going on. Of course, if the numbers are bad, then they may not feel those warm fuzzies. In the IT security world, we try to provide useful numbers to show what a great job we're doing, but it's hard to quantify thwarted attacks -- other than relying on numbers from an IPS and anti-malware system.Rating systems for attacks and vulnerabilities have been around for a while, but most are crude, risk-based matrices that rate security incidents with high, medium, and low ratings for probability on one axis, and impact on the other. Otherwise, I haven't seen anything that rates incidents well until a recent post from Richard Bejtlich on the TaoSecurity blog.

I'm not going to rehash his rating scheme, but what I do want to bring attention to are two factors: the granularity of the 10-point scale and moving it into the high/medium/low categorization, and the use of vulnerability as a type of incident.

A couple of readers commented that having 10 levels was too granular, but I disagree. If you need to break ratings down to a high, medium, or low classification, then Richard offers the option of viewing 1-3 as low, 4-6 as medium, 7-9 as high, and 10 as game over. The granularity is good for better reporting later on. I personally like graphs that have a smaller scale and more points to graph than ones that are more jagged. I think it helps to pinpoint more subtle changes in the data over time.

Richard said his reasoning for including vulnerabilities as an incident type is that some of his businesses classify them as such, even though it goes against how traditional incident detectors and responders think. I have mixed feelings on this one. The incident responder in me wants to agree and say that vulnerabilities shouldn't be included, but the security pro in me who wears many hats says it should. Why?

For security teams who are small and do incident response, vulnerability scanning, and penetration testing, detecting vulnerabilities and dealing with incidents tends to blur. If their experience is like mine, you have one ticketing system to manage it all, so it's often easy to simply and have an incident type of vulnerability. In fact, sometimes the detection of the vulnerability leads to a determination that a true incident has occurred already as a result of the vulnerability.

For teams who already have a mature incident rating system, this may seem old hat, but for those of you who don't, it may be just what you're looking for. And, remember, you don't have to use it verbatim. You can mix it up and use it as you please so that it best fits your organization.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-3304
Published: 2014-10-30
Directory traversal vulnerability in Dell EqualLogic PS4000 with firmware 6.0 allows remote attackers to read arbitrary files via a .. (dot dot) in the default URI.

CVE-2013-7409
Published: 2014-10-30
Buffer overflow in ALLPlayer 5.6.2 through 5.8.1 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a long string in a .m3u (playlist) file.

CVE-2014-3446
Published: 2014-10-30
SQL injection vulnerability in wcm/system/pages/admin/getnode.aspx in BSS Continuity CMS 4.2.22640.0 allows remote attackers to execute arbitrary SQL commands via the nodeid parameter.

CVE-2014-3584
Published: 2014-10-30
The SamlHeaderInHandler in Apache CXF before 2.6.11, 2.7.x before 2.7.8, and 3.0.x before 3.0.1 allows remote attackers to cause a denial of service (infinite loop) via a crafted SAML token in the authorization header of a request to a JAX-RS service.

CVE-2014-3623
Published: 2014-10-30
Apache WSS4J before 1.6.17 and 2.x before 2.0.2, as used in Apache CXF 2.7.x before 2.7.13 and 3.0.x before 3.0.2, when using TransportBinding, does properly enforce the SAML SubjectConfirmation method security semantics, which allows remote attackers to conduct spoofing attacks via unspecified vect...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.