Re: [scap_interest] Gaps in Risk Management

Great points, Karen!  These are issues that should be discussed.  Maybe the end goal would be to get to an ability to represent risk, but the interim step is to more completely represent vulnerabilities and their relationships.  Whatever we come up with for the automation piece should certainly feed into a larger risk management picture which could take into account the "human vulnerability" measurements.  In other words, I believe that we can provide risk measurement in a modular way, where conveying misconfiguration risk would complement vulnerability risk, and vice versa, without necessarily requiring the other elements of risk management to be present – these would feed up into the risk management system.

I could see vocabulary of relationships being established as part of closing these gaps.  At the same time, we could be working to understand the variety of risk management frameworks that are out there and determine how to feed our data into those in an appropriate manner – this seems to imply a risk reporting effort of some kind.

BTW, I wholeheartedly agree that relating configuration items to other configuration items is an issue that needs to be addressed.  If we look at many control frameworks, we'll see some control with a derived requirement for "strong authentication."  What does that mean for a Windows Server 2008 box managing users with user/pass credentials?  We have to take into account not just password length, history, complexity and the like, but also account management settings (lockout, threshold and so on) and attack effectiveness as well (so it's not just relating configuration items to other configuration items).  It becomes rather complicated.

Adam

From: Karen Scarfone <karen@scarfonecybersecurity.com<mailto:karen@scarfonecybersecurity.com>>
Date: Tue, 14 Feb 2012 15:57:18 -0500
To: Adam Montville <amontville@tripwire.com<mailto:amontville@tripwire.com>>
Cc: "scap_interest@ietf.org<mailto:scap_interest@ietf.org>" <scap_interest@ietf.org<mailto:scap_interest@ietf.org>>
Subject: Re: [scap_interest] Gaps in Risk Management

A few quick thoughts on this:

* We can't aggregate all these vulnerabilities unless we can model their relationships. For example, a particular configuration setting might nullify the applicability of a particular software flaw, and configuration settings certainly affect each other.

* There's a whole other class of vulnerabilities besides software flaws and configurations. Basically, any other vulnerability can be considered a trust misuse/abuse vulnerability: social engineering and insider attacks, for example. A risk management methodology that addresses software flaws and misconfigurations is inadequate if it doesn't capture the other vulnerabilities as well. We do have a spec, CMSS, designed to provide scoring for these vulnerabilities just like CVSS does for software flaws and CCSS does for misconfigurations. What we don't yet have is a (heaven help me) dictionary or taxonomy of CMSS vulnerabilities. (Fortunately, I'd expect this to be pretty small and straightforward to create, compared to CVE and CCE).

Karen

On Tue, Feb 14, 2012 at 3:51 PM, Adam Montville <amontville@tripwire.com<mailto:amontville@tripwire.com>> wrote:
All,

Security automation seeks to automate what we can ultimately within the framework of risk management.  Scoring is not enough to measure risk.  What appears to be needed is a method by which we can automate risk measurement.  It would be interesting to discuss various ways in which such automation might be achieved along both qualitative and quantitative lines.

The scoring methods we have in place today for vulnerabilities and configurations (CVSS and CCSS respectively) can measure risk of a particular instance of a class of concepts in our domain.  What I don't see being possible at this point is a way to measure the aggregate instances of vulnerabilities and misconfigurations for some set of assets (whether that be a single asset or a composite asset representing an entire network).

Risk management methodologies are not scarce – NIST, ISO, CobiT, OCTAVE and others all present some method of managing risk, and they are similar.  How can we apply automation in support of these various risk management methods while providing both qualitative and quantitative risk assessment under the hood?

Regards,

Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815

TRIPWIRE | Take CONTROL
http://www.tripwire.com

_______________________________________________
scap_interest mailing list
scap_interest@ietf.org<mailto:scap_interest@ietf.org>
https://www.ietf.org/mailman/listinfo/scap_interest

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
karen@scarfonecybersecurity.com<mailto:karen@scarfonecybersecurity.com>   (703)401-1018