Re: [scap_interest] Gaps in Risk Management

Adam Montville <> Tue, 14 February 2012 21:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 276E721F85AF for <>; Tue, 14 Feb 2012 13:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.774
X-Spam-Status: No, score=-4.774 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jjRwXaJdcp0r for <>; Tue, 14 Feb 2012 13:07:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 229F221F85A7 for <>; Tue, 14 Feb 2012 13:07:43 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server id; Tue, 14 Feb 2012 21:07:39 +0000
Received: from mail25-ch1 (localhost []) by (Postfix) with ESMTP id 694734A0347; Tue, 14 Feb 2012 21:07:43 +0000 (UTC)
X-SpamScore: -34
X-BigFish: VPS-34(zz9371I9f17R98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h946h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;;; EFVD:NLI
Received: from mail25-ch1 (localhost.localdomain []) by mail25-ch1 (MessageSwitch) id 132925366156212_22803; Tue, 14 Feb 2012 21:07:41 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id 01F8F24004A; Tue, 14 Feb 2012 21:07:41 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 14 Feb 2012 21:07:36 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 13:16:25 -0800
Received: from ([fe80::f997:7b65:8e64:438e]) by ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 14 Feb 2012 13:07:38 -0800
From: Adam Montville <>
To: Karen Scarfone <>
Thread-Topic: [scap_interest] Gaps in Risk Management
Thread-Index: AQHM61pd/+qf+nsvQUKFi0HafiSh75Y9ZeAA//98xwA=
Date: Tue, 14 Feb 2012 21:07:37 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [scap_interest] Gaps in Risk Management
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Feb 2012 21:07:47 -0000

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.


From: Karen Scarfone <<>>
Date: Tue, 14 Feb 2012 15:57:18 -0500
To: Adam Montville <<>>
Cc: "<>" <<>>
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).


On Tue, Feb 14, 2012 at 3:51 PM, Adam Montville <<>> wrote:

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?


Adam W. Montville | Security and Compliance Architect

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


scap_interest mailing list<>

Karen Scarfone, Principal Consultant, Scarfone Cybersecurity<>   (703)401-1018