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

From: "Waltermire, David A." <[email-masked]>
Date: Sun, 10 Feb 2013 19:44:52 -0500

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]] 
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

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 11 Feb 2013 13:17:04 -0500

Comments inline below marked [DAW].

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Monday, February 11, 2013 10:18 AM
To: Waltermire, David A.; [email-masked]
Subject: RE: [sacm] FW: New Version Notification for draft-waltermire-sacm-architecture-00.txt

David,

I assume this is more a data-driven than process-driven architecture.
It seems you have repositories for somewhat static control information and
for rather dynamic raw data.
Where is the processed data, aka information or intelligence data?

[DAW: The concept I am working with would place the intelligence data in the content repository.  Essentially, anything that can have a resource identifier (e.g. IRI, URI) associated with it could be a content record.  This would include configuration, vulnerability, and possible indicator/signature data in my mind.]

While data from many devices may be constantly updated, 
I suspect a current data set could be analyzed many times, 
perhaps looking for different signatures as they are discovered.

[DAW: IMHO, this is why it is important to separate the concepts of data collection from analysis. Do you or any others agree/disagree with this philosophy?]

I understand that the data may all reside in the same physical structure, 
so am just wondering if as we tease out the different functional components,

we also need to tease out the different functional data components a bit
more.

[DAW: I think this is critical.  We need to think about this less from a product boundary perspective and more from a functional boundary perspective.  This will help us understand the architecture from an interface view point. The interfaces will describe the data formats and network protocols needed to enable communications between functional components. This will drive the work we need to accomplish in SACM and other WGs.

Once we do this, implementers can draw the appropriate product boundaries around the functional components for their customer needs.  For functional components that fall inside the same product, the interfaces might not require standardized implementations. Interfaces enabling communications outside a product boundary would need standards-based implementations to be interoperable.

Do you have any thoughts to share on specific functional data components?]

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Waltermire, David A.
Sent: Sunday, February 10, 2013 7:45 PM
To: [email-masked]
Subject: [sacm] FW: New Version Notification for
draft-waltermire-sacm-architecture-00.txt

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]] 
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.tx
t
Status:
http://datatracker.ietf.org/doc/draft-waltermire-sacm-architecture
Htmlized:
http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00

Abstract:

The IETF Secretariat

_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 11 Feb 2013 13:52:16 -0500

> Once we do this, implementers can draw the appropriate product boundaries around the functional components for their customer needs.  For functional components that fall inside the same product, th…

I'd like to stress this last paragraph, because it expresses exactly the 
concept I am working from, expressed in considerably fewer words.

One of the repercussions, however, is the need for the ability to 
communicate what interfaces any software component implements.  This 
might be as simple as vendor documentation, but it would be nice if the 
capabilities could be automatically determined.

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 11 Feb 2013 17:02:52 -0500

Michael, one possibility:

When it comes to storing data items, part of the protocol would be a 
mechanism for specifying which collected items are of interest.  As long 
as derivative data items are associated with attributes such that an 
interested party can query for them, then they could simply be stored in 
the same data store as the original data items.  Retrieval would use the 
same protocol as any other data item(s).

--gun

On 2/11/2013 2:54 PM, Michael Hammer wrote:
> Agree with the philosophy.
>
> Where I struggle is that there could be multiple derivatives of data,
> where some traditional management models define the first derivative,
> but then cross-functional processes digest it even further.
>
> So wondering if just having that first level separation of raw from derived
> is enough to bite off right now.
>
> Mike
>
>
> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Monday, February 11, 2013 1:52 PM
> To: Waltermire, David A.
> Cc: Michael Hammer; [email-masked]
> Subject: Re: [sacm] FW: New Version Notification for
>> Subject: RE: [sacm] FW: New Version Notification for
>> It seems you have repositories for somewhat static control information
>> and for rather dynamic raw data.
>> [DAW: The concept I am working with would place the intelligence data
>> in the content repository.  Essentially, anything that can have a
>> resource identifier (e.g. IRI, URI) associated with it could be a
>> content record.  This would include configuration, vulnerability, and
>> possible indicator/signature data in my mind.]
>>
>> While data from many devices may be constantly updated, I suspect a
>> current data set could be analyzed many times, perhaps looking for
>> different signatures as they are discovered.
>>
>> [DAW: IMHO, this is why it is important to separate the concepts of
>> data collection from analysis. Do you or any others agree/disagree
>> with this philosophy?]
>>
>> I understand that the data may all reside in the same physical
>> structure, so am just wondering if as we tease out the different
>> functional components,
>>
>> we also need to tease out the different functional data components a
>> bit more.
>>
>> [DAW: I think this is critical.  We need to think about this less from a
> product boundary perspective and more from a functional boundary
> perspective.  This will help us understand the architecture from an
> interface view point. The interfaces will describe the data formats and
> network protocols needed to enable communications between functional
> components. This will drive the work we need to accomplish in SACM and other
> WGs.
>>
>> Once we do this, implementers can draw the appropriate product boundaries
> around the functional components for their customer needs.  For functional
> components that fall inside the same product, the interfaces might not
> require standardized implementations. Interfaces enabling communications
> outside a product boundary would need standards-based implementations to be
> interoperable.
>
> communicate what interfaces any software component implements.  This might
> be as simple as vendor documentation, but it would be nice if the
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Waltermire, David A.
>> 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:
>> 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.
>>
>> concerns.  We have time before the 2/25 deadline for 00+ I-D
>> submissions to make an any updates.
>>
>> Sincerely,
>> Dave
>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 11 Feb 2013 19:02:39 -0500

I don't expect to be able to predict what attributes will be used, so I 
think the data repository protocol will be more open-ended and therefore 
broadly applicable.  A simple logic structure for producing set logic, 
for example, where the attributes are name+[value/pattern match] pairs. 
  Hopefully, therefore, a single protocol.

--gun

On 2/11/2013 6:13 PM, Michael Hammer wrote:
> Gunnar,
>
> I think we are saying similar things but saying it differently.
> I agree the same physical repository may be used, what you call the base
> retrieval protocol.
> Where I was thinking it is different logical data, you describe as
> distinguishable with associated attributes.
> Of course the devil is in defining what are those attributes, which to me
> starts amounting to a protocol.  :)
>
> Mike
>
>
> Sent: Monday, February 11, 2013 5:03 PM
> To: Michael Hammer
> Cc: [email-masked]; [email-masked]
> mechanism for specifying which collected items are of interest.  As long as
> derivative data items are associated with attributes such that an interested
> party can query for them, then they could simply be stored in the same data
> store as the original data items.  Retrieval would use the same protocol as
> any other data item(s).
>
>
> --gun
>
>
>> So wondering if just having that first level separation of raw from
>> derived is enough to bite off right now.
>>
>> Mike
>>
>>
>>> It seems you have repositories for somewhat static control
>>> information and for rather dynamic raw data.
>> interface view point. The interfaces will describe the data formats
>> and network protocols needed to enable communications between
>> functional components. This will drive the work we need to accomplish
>> in SACM and other WGs.
>>>
>> around the functional components for their customer needs.  For
>> functional components that fall inside the same product, the
>> interfaces might not require standardized implementations. Interfaces
>> enabling communications outside a product boundary would need
>> standards-based implementations to be interoperable.
>>
>> I'd like to stress this last paragraph, because it expresses exactly
>> the concept I am working from, expressed in considerably fewer words.
>>
>> might be as simple as vendor documentation, but it would be nice if
>> the capabilities could be automatically determined.
>>
>>
>>
>>
>>
>>
>>>
>>> http://www.ietf.org/internet-drafts/draft-waltermire-sacm-architectur
>>> e
>>> -00.tx
>>> t
>>> Status:

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 18 Feb 2013 01:35:17 +0000

Hi Dave,

I'm trying to catch up on the threads and drafts and trying to tease out
all of the pertinent requirements and work that would be needed to be
addressed in SACM.  As I can tell from the different drafts, it feels very
data centric and little on how the information is actually transported
(e.g. The appropriate network layers in which the information is to be
communicated), did I miss something or is this yet to be defined?

The architecture draft is a good start, but it is still not clear to me
whether the interfaces needed are at the application layer or lower (ala
TCP/UDP, or lower still, L2? Or some combination of?)  Also, can the
components span multiple (network) domains?  I suspect they might, but
it'd be good to list this outŠ..

I would like to start spelling out a list of requirements, but would like
to understand the scope and intent of the proposed data flows are to work,
so will look forward to seeing more clarification to the current drafts.

Here are some comments/questions on the current architecture draft:

- Section 2.1 Controller: I think is intended to be a "meta collector"
versus a potential collector within an endpoint, is this correct?  As the
current abstraction is written, it is possible that an endpoint could also
include a controller orchestrating internal sensors as wellŠ.is it
expected that the data flow from the sensors and evaluators go thru the
controller? Or the controller "directs" the activities to take place
amongst the evaluators and sensors?

- Section 3.2: why would there not be management tasks (especially from a
security/authorization view) between the controller and the content
repository or data storage?

- Section 3.4: what is the use case for this?

Thanks, Nancy.

On 2/10/13 4:44 PM, "Waltermire, David A." <[email-masked]>
wrote:

>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.
>
>concerns.  We have time before the 2/25 deadline for 00+ I-D submissions
>to make an any updates.
>
>Sincerely,
>Dave
>
>http://www.ietf.org/internet-drafts/draft-waltermire-sacm-architecture-00.
>txt
>Status:

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 18 Feb 2013 01:39:50 +0000

Hi,

I also had some comments/questions on the asset-identification draft:

This draft seems to be about how to model ³content² for identifying
assets, but it is still not clear to me it¹s actual applicability.  If
would be good if there were a few concrete example uses cases showing the
workflow where a common ai is used to convey the information.  Appendix B
is a very good start, but it seems that the ³real value² of this group is
to state that the very same organizations are using the same data for
different purposes (e.g. correlation of sensed data that include/require
correlation to the asset id,  remediation actions are also correlating to
the same asset id data base, etc)Š.more explicitly, the use cases by a
naïve reader can interpret them as being independent data sources, where I
believe that is not the case or intent?

Section 2
As there are references to a ³tool², it would be good to define what is
meant by a ³tool² (I am presuming it is software, or perhaps a complex
form of software application?)

Section 4
Circuit: ³single connection between two endpoints² may need better clarity
as it is meant to be a bidirectional connection (e.g. duplex) or not (as
in the case of a client-server model where communications)

Database: given that this is virtual, is it also an abstracted repository
as given very large scalable systems, the data may actually be distributed
into multiple repositories?

Extension identifier: is this meant to be additional asset id elements not
defined in a particular schema?

Identity information: how is this different from an asset id element?

Synthetic identifier: does this imply that assed id elements and id
information is of global scope?

Missing acronym: urn

Section 4.1.1
I don¹t think its reasonable to expect implementations to support all
implementations.  I think the intent given the last sentence is
appropriate so perhaps last phrase of first sentence should change from
³or otherwise be unable to fully process asset identification elements
that include extension identifiers² to ³when it processes asset
identification elements or in particular, must be able to gracefully
ignore or process extension identification elements.²

Section 5
5.1 Scope am presuming that ³tool² is an application or software?
It seems that the presumption in this model is that it is only IT that can
own services, data, network, etc.  In today¹s structure, some of these can
be outsourced, and as such, I can very easily see services (as they¹re
outsourced) being part of an organizationŠor am I misinterpreting this
model?  That is, Company X can outsource network services from a service
provider (say ATT)Šso I would view ATT as the organization that owns the
networkŠ.not ITŠ

That is, it seems that this model is not adequately representing the
evolving trends of ³the cloud² and SDN architecturesŠ.
I also do not see physical assets (e.g. printers, cameras, phones, etc)
being identified in the model?

Nit request: a table of contents should be included in the draft.

Thanks, Nancy.

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 19 Feb 2013 19:33:00 -0500

Nancy,

These are great questions that represent where we need further discussion. My thoughts are inline.  Any feedback is appreciated.

Thanks,
Dave

> From: Nancy Cam-Winget (ncamwing) [mailto:[email-masked]]
> Sent: Sunday, February 17, 2013 8:35 PM
> Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-
> architecture-00.txt
> 
> Hi Dave,
> 
> I'm trying to catch up on the threads and drafts and trying to tease out all of
> the pertinent requirements and work that would be needed to be addressed
> in SACM.  As I can tell from the different drafts, it feels very data centric and
> little on how the information is actually transported (e.g. The appropriate
> network layers in which the information is to be communicated), did I miss
> something or is this yet to be defined?

Agreed.  We need to get to more specificity regarding transport.

> The architecture draft is a good start, but it is still not clear to me whether the
> interfaces needed are at the application layer or lower (ala TCP/UDP, or
> lower still, L2? Or some combination of?)  Also, can the components span
> multiple (network) domains?  I suspect they might, but it'd be good to list this
> outŠ..

It's my hope that we can leverage existing application layer and lower protocols as part of this effort.  In my mind we should be focusing on profiles and extensions to existing application protocols where practical, leveraging existing lower level specifications for network transport. I believe this would allow us to produce something useful and adoptable in a shorter amount of time.

Do you have any thoughts on this?

> I would like to start spelling out a list of requirements, but would like to
> understand the scope and intent of the proposed data flows are to work, so
> will look forward to seeing more clarification to the current drafts.

Great.  I'd appreciate any input you have.

> versus a potential collector within an endpoint, is this correct?  As the current
> abstraction is written, it is possible that an endpoint could also include a
> controller orchestrating internal sensors as wellŠ.is it expected that the data
> flow from the sensors and evaluators go thru the controller? Or the
> controller "directs" the activities to take place amongst the evaluators and
> sensors?

In my mind the controller would be responsible for orchestrating different sensors insuring the appropriate data collection activities are carried out. Before exploring this further it might help to talk a bit about the nature of the sensors that would require management.

I see two different classes of sensors: network-oriented and endpoint-oriented.

A network-oriented sensor makes observations related to network state (e.g. traffic, connections, protocol data, network events) based on its visibility to a network and any bits flowing through it between two or more endpoints. Examples of network sensors might be network IDS (e.g. traffic analysis, network events) or netflow sensors (e.g. IPFIX). Based on the current charter, it's not clear if management of this type of sensor is in scope as it doesn't relate to endpoint posture directly.

An endpoint-oriented sensor makes observations about device state (e.g. software inventory, configurations, host events) and may do this directly on the endpoint or by instrumenting the endpoint remotely. Thus, an endpoint-oriented sensor might be either internal or external to an endpoint. For sensors that are internal to the endpoint, it may be necessary to have an internal endpoint controller that manages all sensors internal to the endpoint.

Thus the controller may work in two scenarios:

1) The controller orchestrates all sensors directly, regardless of their relationship to the endpoint (external or internal).

Controller -> Endpoint Sensor 1
                     -> Endpoint Sensor 2
                     -> External Sensor A

2) The controller orchestrates all external sensors and the internal endpoint controllers for any associated endpoints.

Controller -> Internal Endpoint Controller -> Sensor 1
                                                                                     -> Sensor 2
                     -> External Sensor A

It may also be desirable to have controllers that manage specific types of sensors or internal endpoint controllers. It's possible to imagine many different scenarios that mix and match these approaches, supporting different levels of delegation. Considering all of this, we need to be careful not to introduce needless complexity.  Anyone have any thoughts on the right balance for this?

In the current architecture document, the notions of data collection and evaluation are separated. This enables a collect-once-analyze-many approach where a single set of collected data might be used by many different analysis processes. This enables shared situational awareness to drive different business processes requiring different kinds of measurements based on the same collected data.

Here is a typical scenario: 

1) The evaluator would use DF2 to ask the controller for any collection needed to support current or future analysis.  This could be a one-time, periodic, or ongoing real-time data collection task. The task would include a list of endpoints or an abstract description of endpoints (e.g. all printers).
2) The controller would decompose this task into discrete tasks that would then be directed to the appropriate sensors, or subordinate controllers (see above), responsible for the associated endpoints. The controller(s) and sensor would query any content needed to process the task using DF1.
3) The sensor would carry out the data collection, providing the data collection results either back to the controller (Sensor -> DF2 -> Controller -> DF3 -> Data Storage), or directly to the data storage (Sensor -> DF3 alt -> Storage) and then notify the Controller when complete (Sensor -> DF2 -> Controller).
4) The Controller could notify the Evaluator that new data is available, and analysis can be performed by querying the data using DF4.

Although this scenario assumes that the Evaluator is requesting data collection from the Controller, it might make sense for the Controller to direct both data collection and evaluation. This may be the better alternative.  Any thoughts?

> repository or data storage?

I see no reason why there couldn't be management tasks handled in this way.  Do you have any specific scenarios in mind? Does this need to be addressed in our initial work? Is this something that could be added on later?

> - Section 3.4: what is the use case for this?

This would provide data query capabilities needed to make previously collected data available in a standardized way for evaluation/analysis. We may want to further reduce the scope of the SACM effort to focus entirely on data collection to avoid needing to address this.  Doing so would require evaluation to occur either at the sensor or not as part of our scope of work. If the latter, this may eliminate the need for defining the Evaluation component in the architecture. At minimum it could be treated as a generalized client of the Controller that requests data collection tasking for some higher purpose. Any thoughts?

> >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:
> >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.
> >