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

From: [email-masked]
Date: Wed, 20 Feb 2013 11:19:34 -0600 (CST)

Hi Nancy:

Let me share with you my understanding.

CPE addresses hardware, operating systems, and applications.

AI (Asset Identification, IR 7693) encompases a much larger "anything that is of value to the organization" and leverages CPE for hardware, operating sytems, and applications.

David Oliva

On 02/20/13, Nancy Cam-Winget (ncamwing)<[email-masked]> wrote:

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.

On 2/19/13 8:12 AM, "Gunnar Engelbach" <[email-masked]>
wrote:

>
>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:
>> 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]
>> <mailto:[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]
>> <mailto:[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]>
>> > [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]> <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/sacm
>> >
>> >
>> > _______________________________________________
>> > sacm mailing list
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/sacm
>> >
>> _______________________________________________
>> 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

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 20 Feb 2013 13:12:26 -0500

True enough, but what I was actually thinking was that CPE is for 
identifying a general group of items whereas AI is for identifying a 
particular asset.

CPE trades granularity for a simple compact expressions.  AI is much 
more exhaustive in detail and granularity and better at identifying a 
specific asset and important details about that asset, particularly when 
that same asset is known by different characteristics between different 
systems.

As examples:

For inventory tracking I'd want to use AI, especially when any asset 
needs to be correlated between multiple repositories.

For applicability in a benchmark, possibly down to the individual rule 
level, I'd want to use CPE.

--gun

On 2/20/2013 12:19 PM, [email-masked] wrote:
> AI (Asset Identification, IR 7693) encompases a much larger "anything
> that is of value to the organization" and leverages CPE for hardware,
> operating sytems, and applications.
> David Oliva
> On 2/19/13 8:12 AM, "Gunnar Engelbach" <[email-masked]
> <mailto:[email-masked]>>
> wrote:
>
>  >
>  >On 2/19/2013 10:15 AM, [email-masked]
>  >> On 02/18/13, Gunnar Engelbach<[email-masked]
> <mailto:[email-masked]>> wrote:
>  >>
>  >> David,
>  >>
> <mailto:[email-masked]>
> <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 23 Feb 2013 09:26:22 -0500

Kathleen,

One of the secondary benefits of the
SACM work in the IETF is potential
convergence of parallel SACM like
universes.  At the ETSI annual
security workshop a few weeks
ago, the attached presentation
suggested that there was a SACM
like effort extant in France and Italy
that could usefully benefit for being
part of the SACM work.

It might be useful to keep this additional
benefit in mind as the group/work proceeds.

--tony

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Sat, 23 Feb 2013 10:10:23 -0500

Thanks, Tony!  The work is actually connected to MILE and references the standards from the IETF, NIST and ISO to build their work from international standards.  I reached out to the author and posted to MILE for those interested to see the slides.

Best regards,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Rutkowski
Sent: Saturday, February 23, 2013 9:26 AM
To: Moriarty, Kathleen
Cc: [email-masked]; Waltermire, David
Subject: [sacm] SACM parallel universes

Kathleen,

--tony