Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-architecture-00.txt

From: [email-masked]
Date: Tue, 19 Feb 2013 09:15:15 -0600 (CST)

Gunnar:

Do you anticipate CPE, CVE, and CVSS not making it to SACM?

David Oliva

On 02/18/13, Gunnar Engelbach<[email-masked]> wrote:

David,

The current SACM architecture just shows a breakout of the components in
the architecture and recognition in the broadest sense of the type of
communications that are expected between each, but doesn't say anything
about the format of those communications or how they are expected to be
processed at each node.

In SCAP terms, the Collector could easily accept OVAL documents as its
instructions for what to collect and return a System Characteristics
document as the returned payload. Similarly with an OCIL questionnaire
where the collector would be interactive and not automated.

The Evaluator could then use the SC file and completed OCIL
questionnaire in conjunction with OVAL/XCCDF to produce an XCCDF results
document as its payload.

However, at this point there's nothing to say that all this could not be
done via proprietary means.

At this point the desired overall architecture and resultant
requirements haven't been defined well enough to know whether or not any
existing standards such as SCAP will be the way to go.

On 2/17/2013 6:34 PM, [email-masked] wrote:
> David and all
> The document appears good to me, but I have some questions.
> 1. Does the current SCAP architecture resemble the proposed SACM
> architecture?
> 2. If the current SCAP architecture reflects the proposed SACM
> architecture, can you correlate the components from SCAP to SACM?
> David Oliva
> On 02/10/13, Waltermire, David A.<[email-masked]> wrote:
> I just posted an initial SACM Architecture document including what we
> have been discussing. The link is below.
>
> This draft is fairly skeletal right now. It currently includes a simple
> ASCII art diagram based on the discussion thread that Gunnar started.
> The core sections of the document where I have done some work are
> section 2: Functional Components and section 3: Data Flows. Section 2.1
> and 3.1 contain some example detail. Please let me know if this is the
> right approach. I'd like to capture additional details, but I am not
> sure what to include and how best to include it at this point. We need
> more discussion to fill this in. I'm happy to capture anything that we
> come up with.
>
> Please review this draft and let me know if you have any comments or
> concerns. We have time before the 2/25 deadline for 00+ I-D submissions
> to make an any updates.
>
> Sincerely,
> Dave
>
> -----Original Message-----
> From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]]
> Sent: Sunday, February 10, 2013 7:30 PM
> To: Waltermire, David A.
> Subject: New Version Notification for
> draft-waltermire-sacm-architecture-00.txt
>
>
> A new version of I-D, draft-waltermire-sacm-architecture-00.txt
> has been successfully submitted by David Waltermire and posted to the
> IETF repository.
>
> Filename: draft-waltermire-sacm-architecture
> Revision: 00
> Title: Security Automation and Continuous Monitoring (SACM) Architecture
> Creation date: 2013-02-11
> WG ID: Individual Submission
> Number of pages: 9
> URL:
> http://www.ietf.org/internet-drafts/draft-waltermire-sacm-architecture-00.txt
> Status: http://datatracker.ietf.org/doc/draft-waltermire-sacm-architecture
> Htmlized: http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00
>
>
> Abstract:
> This document identifies the architectural components, data flows,
> and the supporting standards needed to define an interoperable
> automation infrastructure required to support timely, accurate and
> actionable situational awareness over an organization's IT systems.
> This architecture is based on previous use case and requirements
> analysis. Automation tools implementing the continuous monitoring
> approach described in this document will utilize this infrastructure
> together with existing and emerging event, incident and network
> management standards to provide visibility into the state of assets,
> user activities and network behavior. Stakeholders will be able to
> use these tools to aggregate and analyze relevant security and
> operational data to understand the organizations security posture,
> quantify business risk, and make informed decisions that support
> organizational objectives while protecting critical information.
> Organizations will be able to use these tools to augment and automate
> information sharing activities to collaborate with partners to
> identify and mitigate threats. Other automation tools will be able
> to integrate with these capabilities to enforce policies based on
> human decisions to harden systems, prevent misuse and reduce the
> overall attack surface.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> sacm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 19 Feb 2013 11:12:30 -0500

CPE has had the most discussion so far, and Adam wrote an Asset 
Identification proposal that's well worth a read, but so far I see AI 
and CPE as complimentary and not mutually exclusive -- I see a definite 
need for both.  Whether or not CPE specifically is used to cover the gap 
AI doesn't remains to be seen and also depends on the acceptance of AI 
and how it mutates in the process.

Whether or not any of these come to live under SACM, I can't see content 
*not* continuing to use CVE as a common reference and repository.  It 
took a long time to get CVE used as widely as it is and I just don't 
think it's practical to expect the industry to switch to something 
different any time soon.

That would mean that CVSS vectors will still be pertinent, since they 
are published as part of the CVE entry.  I'd also like to see CCSS 
completed and broadly used as well, but that might just be me.

Stepping a little beyond your immediate question, it seems to me that 
leaving the payload of the data flows Dave outlined arbitrary achieves 
the greatest flexibility and therefore ability to adapt.  That means 
that the DF protocols would need the ability to query each software 
component about capabilities and supported data types.

For example, a Collector/Sensor would be any component that implemented 
the AssetDataItemCollection and AssetDataItemQuery interfaces, just to 
pick random names, with OVAL as the supported "language."  An Evaluator 
would implement interfaces for producing asset data item queries, 
consuming data item query collections, and producing assessment results, 
using OVAL for data item collection and OVAL/XCCDF for assessment.  And 
actual software implementation might in face implement all these 
interfaces into a single installable component and therefore be usable 
as both.

Regardless of what SACM lands on as the standards for evaluation, 
collection, etc, components need not be limited to those standards only.

Generalize this and in fact all data flows Dave laid out can be achieved 
with a single protocol, and a fairly simple one at that.

At least, that's how I see things at this point.  I'd like to hear from 
the others to see how well this jives with the group.

--gun

On 2/19/2013 10:15 AM, [email-masked] wrote:
> On 2/17/2013 6:34 PM, [email-masked]
> <mailto:[email-masked]> wrote:
>  > David and all
>  > On 02/10/13, Waltermire, David A.<[email-masked]
> <mailto:[email-masked]>> wrote:
> <mailto:[email-masked]>
>  > Status:
> http://datatracker.ietf.org/doc/draft-waltermire-sacm-architecture
>  > Htmlized:
> http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00
>  >
>  >
>  > Abstract:
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 20 Feb 2013 14:28:48 +0000

Hi Gunnar,

Not being versant in either CPE and coming up to speed on AIŠ.I'm not
understanding why both are needed.
Can a rationale be provided for why both would be needed, with some
analysis for the diffs that warrant
The need for both (I didn't quite extract that from all the drafts
submitted thus far)Š.

Thanks, Nancy.