Re: [scap_interest] The Context Concept

David Solin <david@joval.org> Wed, 22 February 2012 05:28 UTC

Return-Path: <solin@farnamhallventures.com>
X-Original-To: scap_interest@ietfa.amsl.com
Delivered-To: scap_interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBBB21E806D for <scap_interest@ietfa.amsl.com>; Tue, 21 Feb 2012 21:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMsC1X-ESqe5 for <scap_interest@ietfa.amsl.com>; Tue, 21 Feb 2012 21:28:01 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29EEC21E804E for <scap_interest@ietf.org>; Tue, 21 Feb 2012 21:28:00 -0800 (PST)
Received: by ghbg16 with SMTP id g16so3731928ghb.31 for <scap_interest@ietf.org>; Tue, 21 Feb 2012 21:28:00 -0800 (PST)
Received-SPF: pass (google.com: domain of solin@farnamhallventures.com designates 10.101.10.39 as permitted sender) client-ip=10.101.10.39;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of solin@farnamhallventures.com designates 10.101.10.39 as permitted sender) smtp.mail=solin@farnamhallventures.com
Received: from mr.google.com ([10.101.10.39]) by 10.101.10.39 with SMTP id n39mr12686962ani.3.1329888480604 (num_hops = 1); Tue, 21 Feb 2012 21:28:00 -0800 (PST)
Received: by 10.101.10.39 with SMTP id n39mr9888104ani.3.1329888480476; Tue, 21 Feb 2012 21:28:00 -0800 (PST)
Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id r68sm59980654yhm.18.2012.02.21.21.27.58 (version=SSLv3 cipher=OTHER); Tue, 21 Feb 2012 21:27:59 -0800 (PST)
Sender: David Solin <solin@farnamhallventures.com>
Message-ID: <4F447CE0.4020803@joval.org>
Date: Tue, 21 Feb 2012 23:28:00 -0600
From: David Solin <david@joval.org>
Organization: jOVAL
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Waltermire, David A." <david.waltermire@nist.gov>
References: <4F3FF5E2.2080901@netpeas.com> <E3EFB6C0D90F82478AF227AA85ECF38015AE1F55@SXEMBP01.corp.dtcc.com> <578CCEEC-7B76-4E19-BBE6-0DC029D1417C@c3isecurity.com> <D7A0423E5E193F40BE6E94126930C4930B93F67E0A@MBCLUSTER.xchange.nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930B93F67E0A@MBCLUSTER.xchange.nist.gov>
Content-Type: multipart/alternative; boundary="------------060209020000000908020304"
X-Gm-Message-State: ALoCoQkxWj1rs5JH6GYgOHYWq6qOvXz4AICSrydQEeIJx0eJ5Wux0Rlq7E5l0TBCDiiWDjGoshOV
Cc: "scap_interest@ietf.org" <scap_interest@ietf.org>
Subject: Re: [scap_interest] The Context Concept
X-BeenThere: scap_interest@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." <scap_interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scap_interest>, <mailto:scap_interest-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/scap_interest>
List-Post: <mailto:scap_interest@ietf.org>
List-Help: <mailto:scap_interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scap_interest>, <mailto:scap_interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2012 05:31:08 -0000

Isn't this exactly what CIM is for?  CIM makes it possible to organize 
assets across many dimensions, including customer-defined "service" 
dimensions, that could easily serve as references for targeting 
purposes.  I can imagine mapping services with profiles, or more 
generally, CIM graph queries with profiles.

I've never understood what purpose AI is supposed to serve when CIM has 
been around for much longer, is already fairly well-adopted by CMDB 
vendors, and addresses the asset management problem domain quite well.

Anyway, just my $.02.

Regards,
--David Solin

-- 

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>



On 2/21/2012 12:46 PM, Waltermire, David A. wrote:
>
> There are a variety of use cases that can benefit from synthesizing 
> asset technical information (e.g., IPs, network address, default 
> gateways, machine accessable asset tags, configurations) with 
> organizational information (e.g., device role, criticality, etc).  For 
> example, if you can generate a network graph of devices and their 
> connections, and combine that with firewall rules and other topology 
> concerns to determine visibility between hosts, you can then perform 
> attack graph analysis to determine at what points a security related 
> change will provide the greatest security benefit.  This can be one 
> method used to prioritize the implementation of various security 
> controls.  As Karen Scarfone pointed out earlier, this is also needed 
> to support host-, network-, and system-oriented metrics starting with 
> things like CVSS and CCSS scores and utilizing the composition of 
> software on hosts and hosts on networks to support roll-up.
>
> This and similar use cases are supported by asset identification, but 
> require greater formalization around asset data management to enable 
> implementation neutral, interoperable approaches.
>
> Sincerely,
>
> David Waltermire
>
> *From:*scap_interest-bounces@ietf.org 
> [mailto:scap_interest-bounces@ietf.org] *On Behalf Of *Luis Nunez
> *Sent:* Tuesday, February 21, 2012 1:23 PM
> *To:* Chernin, Michael A.
> *Cc:* scap_interest@ietf.org
> *Subject:* Re: [scap_interest] The Context Concept
>
> We also need to look at vulnerabilities as it applies an environment. 
>  An inherent vulnerability may have differing levels of exposure 
> depending on what, where and how the node is deployed.
>
> We maybe able to leverage Asset Identification (AI) to correlate what 
> role the node is playing in the environment (endpoint, Server, 
> Inter-networking Device,..) and determine level of exposure.  The 
> level of risk could also be applied depending on where the node is 
> situated.
>
> - Directly connected to internet.
>
> - DMZ controlled
>
> - Internal Network
>
> - Secure enclave
>
> -ln
>
> On Feb 21, 2012, at 9:47 AM, Chernin, Michael A. wrote:
>
>
>
> I agree that when dealing with "threats" that context matters. 
> However, vulnerabilities alone do not imply or guarantee there is an 
> associated threat or risk.
>
> In my perfect world there would be a threat indicator standard that 
> links to a structured threat standard that then could describe the 
> CVEs used. This would allow us to continue doing vulnerability 
> management by exposure (no threat context) or by specific threat 
> (which provides context).
>
> Aharon
>
> DTCC Non-Confidential (White)
> ---------------------------------------------------
> Michael "Aharon" Chernin
> Security Automation Program Manager
> Corporate Information Security -Depository Trust & Clearing Corporation
> O: 813-470-2173
>
> *From:*scap_interest-bounces@ietf.org 
> <mailto:scap_interest-bounces@ietf.org>[mailto:scap_interest-bounces@ietf.org]*On 
> Behalf Of*Jerome Athias
> *Sent:*Saturday, February 18, 2012 2:03 PM
> *To:*scap_interest@ietf.org <mailto:scap_interest@ietf.org>
> *Subject:*[scap_interest] The Context Concept
>
> In a private discussion I had at ToorCon 9, with Matt Miller (skape);
> we came to the conclusion that a key (and unresolved) point of 
> automation is the (automatic) definition of the Context in which you 
> are where dealing with a vulnerability (threat).
> It was also identified (validated?), and introduced by Druid.
> And then, the Druid's work was related (validated?) at FRHACK 01 by 
> Rodrigo Branco (bsdaemon).
>
> /Situation awareness 
> (http://en.wikipedia.org/wiki/Situation_awareness) should be taken 
> into account.//
> /Maybe search for "military situational awareness"./
>
> /My 2 dirhams/
> //JA//
>
>
> _____________________________________________________________
> DTCC DISCLAIMER: This email and any files transmitted with it are 
> confidential and intended solely for the use of the individual or 
> entity to whom they are addressed. If you have received this email in 
> error, please notify us immediately and delete the email and any 
> attachments from your system. The recipient should check this email 
> and any attachments for the presence of viruses. The company accepts 
> no liability for any damage caused by any virus transmitted by this 
> email._______________________________________________
> scap_interest mailing list
> scap_interest@ietf.org <mailto:scap_interest@ietf.org>
> https://www.ietf.org/mailman/listinfo/scap_interest
>
>
>
> _______________________________________________
> scap_interest mailing list
> scap_interest@ietf.org
> https://www.ietf.org/mailman/listinfo/scap_interest