Re: [scap_interest] The Context Concept

Adam Montville <amontville@tripwire.com> Tue, 21 February 2012 18:55 UTC

Return-Path: <amontville@tripwire.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 6318021F87CC for <scap_interest@ietfa.amsl.com>; Tue, 21 Feb 2012 10:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.64
X-Spam-Level:
X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=0.959, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 LVXRHgdrS9Sz for <scap_interest@ietfa.amsl.com>; Tue, 21 Feb 2012 10:55:19 -0800 (PST)
Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id B528B21F8891 for <scap_interest@ietf.org>; Tue, 21 Feb 2012 10:55:19 -0800 (PST)
Received: from mail173-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Feb 2012 18:55:14 +0000
Received: from mail173-tx2 (localhost [127.0.0.1]) by mail173-tx2-R.bigfish.com (Postfix) with ESMTP id 029922E01DD; Tue, 21 Feb 2012 18:55:14 +0000 (UTC)
X-SpamScore: -31
X-BigFish: VPS-31(zz9371IfacL98dKf10Kzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h946h)
X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI
Received: from mail173-tx2 (localhost.localdomain [127.0.0.1]) by mail173-tx2 (MessageSwitch) id 1329850421568959_27351; Tue, 21 Feb 2012 18:53:41 +0000 (UTC)
Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.254]) by mail173-tx2.bigfish.com (Postfix) with ESMTP id CC41A40176; Tue, 21 Feb 2012 18:53:20 +0000 (UTC)
Received: from PDXHB01.tripwire.com (174.47.84.216) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Feb 2012 18:53:19 +0000
Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 11:02:00 -0800
Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Feb 2012 10:53:22 -0800
From: Adam Montville <amontville@tripwire.com>
To: "Waltermire, David A." <david.waltermire@nist.gov>, Luis Nunez <lnunez@c3isecurity.com>, "Chernin, Michael A." <mchernin@DTCC.COM>
Thread-Topic: [scap_interest] The Context Concept
Thread-Index: AQHM7m/8UU2pLwB0k0+y1LokvyzghpZH+LUAgAA8UYCAAAZZAP//e/GA
Date: Tue, 21 Feb 2012 18:53:22 +0000
Message-ID: <CB69278E.9711%amontville@tripwire.com>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930B93F67E0A@MBCLUSTER.xchange.nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.16.97.217]
x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <A6D7C4BC8A83DE449B85756B0311A948@tripwire.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: tripwire.com
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: Tue, 21 Feb 2012 18:55:24 -0000

Perhaps we should discuss what "risk" means in the grand scheme of things.  Measuring a level of risk based on location is just one way to do it.  I'm not sure where to start that discussion, but we should be thinking in terms of enabling risk-immature and risk-mature organizations to benefit equally by providing a blend of qualitative and quantitative techniques over a spectrum of risk management capabilities.

Adam

From: "Waltermire, David A." <david.waltermire@nist.gov<mailto:david.waltermire@nist.gov>>
Date: Tue, 21 Feb 2012 13:46:06 -0500
To: Luis Nunez <lnunez@c3isecurity.com<mailto:lnunez@c3isecurity.com>>, "Chernin, Michael A." <mchernin@DTCC.COM<mailto:mchernin@DTCC.COM>>
Cc: "scap_interest@ietf.org<mailto:scap_interest@ietf.org>" <scap_interest@ietf.org<mailto:scap_interest@ietf.org>>
Subject: Re: [scap_interest] The Context Concept

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> [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<mailto: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<mailto:scap_interest@ietf.org> https://www.ietf.org/mailman/listinfo/scap_interest