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

From: Adam Montville <[email-masked]>
Date: Wed, 6 Mar 2013 17:27:24 +0000

Right (really late to these discussions)...  CPE specifies a class of
asset and AI identifies an instance of that class (in addition to being
more encompassing).

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

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