Subject: [sacm] A potential scope narrowing architectural approach

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 14 Nov 2012 03:26:07 -0500

At the IETF meeting in Atlanta I had a few conversations about reducing the scope and identifying an architectural approach for the SACM work.  The following are some of my thoughts on how we could approach the problem based on information in the current SACM Use Cases document.  The current draft can be found here:

http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases/

In the use cases document, use cases 2 and 3 depend on use case 1.  We may want to consider focusing the initial scope of the SACM charter on use case 1 to provide foundational capabilities that we can build on in the future.

Use Case 1: http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02#section-3.1

The following is not intended to be a complete treatment of an architectural approach.  Instead it is a rough outline for an approach that would require deeper specification of data flow, security, and network requirements.  The attached architecture image (please excuse the quality) is a result of some of the discussions I had.  It identifies 4 (or 5) functional components that work together to address use case 1 and provide a foundation to support the other use cases.  It contains the following logical functional components:

 1.  Data/Content Repository - A repository of security metadata that can be used to drive security-oriented processes (e.g. vulnerability, configuration, asset data, assessment/collection methods).  This is long-lived, infrequently changing information that is provided from a variety of external information sources.  The methods used to make this information available will likely be out of scope.
 2.  Management System - Responsible for directing collection activities based on organizational security policy and available relevant metadata from the content repository that may drive supported security processes.
 3.  Sensor/Collector - Responsible for collecting actual system state information (e.g. configurations, software inventory, patch) based on commands provided by the management system, potentially using collection instructions provided by the content repository (e.g. SCAP-style assessment content).  This could be an agent on an endpoint or a remote collection system.
 4.  Processor - An upstream component that receives collected state information.  This could be a data repository, an information processor that acts on the provided information or a process that routes information to other sources.  Information flowing to this component is expected to be time-sensitive and frequently changing.
Based on these components there are 4 data flows.  The arrows do not indicate the general flow of information and do not imply if the information is pushed or pulled across the interface.  The data flows are:

 1.  Management System <-> Content Repository - This data flow is used to provide supporting metadata that is needed to drive security processes.  The management system uses this data flow to acquire the information it needs to determine what actions to instruct the sensors to perform.  The management system may also store state information in the data/content repository to capture policy decisions for future use.
 2.  Management System -> Sensor/Collector - This is a control channel that is used to enable dynamic management of the information collected by the sensor/collector.  Commands containing instruction of what to collect would be passed using this data flow.  These instructions may point to assessment content stored in the data/content repository.
 3.  Data/Content Repository -> Sensor/Collector - Used to retrieve any data/content that is needed to perform collection activities.
 4.  Sensor/Collector -> Processor – Used to make collected information available to other “upstream” components that archive the information for future use or perform additional processing.  This is the entry point for use cases 2 and 3.
If content acquisition uses a pull-based protocol approach, data flows 1 and 3 could use the same protocol approach.  Furthermore, if it is not desirable to have sensors directly acquire content, content could be acquired by the management system using data flow 1 and then pass the content on to the sensor using data flow 2.

Another alternative to this architectural approach, pictured on the middle left, is a coordination component that abstracts dependencies between the management system, sensor and processor components.  This represents a common data flow alternative to the independent data flows between these components.  If this approach is used, specialized messages could be passed over a common protocol to address the exchanges defined by data flows 2 and 4 above.  This component would coordinate the exchange of the messages to the appropriate/designated peers.

The logical components in this architecture may be allocated in software as one or more software components.  Where components are combined, the data flows may be proprietary or unneeded.  My base assumption is that we would work to eventually define standards for all of the data flows.  In the short run it might be a good idea to focus on a subset of this work, and possibly point to existing protocols for some of this, at least in the short run.

This all assumes work on UC 1.  Is this the right slice of the use cases?  If so, does this sound like a reasonable approach?  Do you see any alternative approaches?

Sincerely,
Dave

---

From: Stephen Hanna <[email-masked]>
Date: Sat, 17 Nov 2012 13:13:22 +0000

Dave,

I like the idea of narrowing the scope even more. UC1 is probably the minimum that's still useful. Let's focus on that. We can always go back and add UC2 and UC3, if we design things properly.

Speaking of design, I like your overall design. I think the architectural components are mainly right but I think we need to design the system to be flexible enough to add UC2, UC3, and even other use cases as they may come up in the future. The best way to do that, in my view, is to design the system to use a small number of components and protocols that can serve multiple purposes not just UC1.

For example, the Content Repository is a nice, flexible component: a database. Let's use one protocol to access it (for data flows 1 and 3). And why can't the Sensor use the same Content Repository and protocol to store the information collected in data flow 4? By putting this information into a common repository and having a standard protocol for accessing it, this information can then be used by a variety of components: a compliance reporting tool, an analyst searching for machines known to have software with a newly discovered vulnerability, an enforcement system that handles UC2. UC3 can result in periodic or triggered updates to the Content Repository.

In addition to having the Content Repository as one flexible component, I would like to see a flexible control protocol with multi-party notification (e.g. IF-MAP or an ESB) that can be used for data flows 2 and 4 now and for other data flows later. For UC1, this control protocol should be used in data flow 2 to direct data collection and in data flow 4 to indicate that new data has been uploaded to the Content Repository. In UC1, this notification will be used only for reporting on system compliance. In UC2, an access controller can use the notification in data flow 4 to determine access. And in UC3, the same notification becomes part of real-time reporting and response. But this only works if the control protocol is flexible enough that it isn't bound to only one use case.

In summary, the Content Repository can be a standard database where content is stored and retrieved while the control protocol is a way of sending commands and notifications among the components in the system.

So I totally agree with the idea of focusing on UC1 for now. I just want to use general-purpose protocols and components that can be used to solve the other use cases later. And maybe we can use already existing standards for those protocols so that we don't have to invent them!

Thanks for moving us forward,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Wednesday, November 14, 2012 3:26 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] A potential scope narrowing architectural approach

  4.  Sensor/Collector -> Processor - Used to make collected information available to other "upstream" components that archive the information for future use or perform additional processing.  This is the entry point for use cases 2 and 3.

Sincerely,
Dave

---

From: "Chandrashekhar B" <[email-masked]>
Date: Mon, 19 Nov 2012 11:45:10 +0530

+1

I like the idea of having one protocol to store and retrieve both from
Content Repository and Processor. Implementers could keep them as separate
component if they choose to but, by having single protocol, we are allowing
combining these two components into one and call Content Repository. 

Thanks,

Chandra.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Hanna
Sent: Saturday, November 17, 2012 6:43 PM
To: Waltermire, David A.; [email-masked]
Subject: Re: [sacm] A potential scope narrowing architectural approach

Dave,

I like the idea of narrowing the scope even more. UC1 is probably the
minimum that's still useful. Let's focus on that. We can always go back and
add UC2 and UC3, if we design things properly.

Speaking of design, I like your overall design. I think the architectural
components are mainly right but I think we need to design the system to be
flexible enough to add UC2, UC3, and even other use cases as they may come
up in the future. The best way to do that, in my view, is to design the
system to use a small number of components and protocols that can serve
multiple purposes not just UC1.

For example, the Content Repository is a nice, flexible component: a
database. Let's use one protocol to access it (for data flows 1 and 3). And
why can't the Sensor use the same Content Repository and protocol to store
the information collected in data flow 4? By putting this information into a
common repository and having a standard protocol for accessing it, this
information can then be used by a variety of components: a compliance
reporting tool, an analyst searching for machines known to have software
with a newly discovered vulnerability, an enforcement system that handles
UC2. UC3 can result in periodic or triggered updates to the Content
Repository.

In addition to having the Content Repository as one flexible component, I
would like to see a flexible control protocol with multi-party notification
(e.g. IF-MAP or an ESB) that can be used for data flows 2 and 4 now and for
other data flows later. For UC1, this control protocol should be used in
data flow 2 to direct data collection and in data flow 4 to indicate that
new data has been uploaded to the Content Repository. In UC1, this
notification will be used only for reporting on system compliance. In UC2,
an access controller can use the notification in data flow 4 to determine
access. And in UC3, the same notification becomes part of real-time
reporting and response. But this only works if the control protocol is
flexible enough that it isn't bound to only one use case.

In summary, the Content Repository can be a standard database where content
is stored and retrieved while the control protocol is a way of sending
commands and notifications among the components in the system.

So I totally agree with the idea of focusing on UC1 for now. I just want to
use general-purpose protocols and components that can be used to solve the
other use cases later. And maybe we can use already existing standards for
those protocols so that we don't have to invent them!

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Waltermire, David A.
Sent: Wednesday, November 14, 2012 3:26 AM
To: [email-masked]
Subject: [sacm] A potential scope narrowing architectural approach

At the IETF meeting in Atlanta I had a few conversations about reducing the
scope and identifying an architectural approach for the SACM work.  The
following are some of my thoughts on how we could approach the problem based
on information in the current SACM Use Cases document.  The current draft
can be found here: 

In the use cases document, use cases 2 and 3 depend on use case 1.  We may
want to consider focusing the initial scope of the SACM charter on use case
1 to provide foundational capabilities that we can build on in the future.

Use Case 1:
http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02#section-3.1

The following is not intended to be a complete treatment of an architectural
approach.  Instead it is a rough outline for an approach that would require
deeper specification of data flow, security, and network requirements.  The
attached architecture image (please excuse the quality) is a result of some
of the discussions I had.  It identifies 4 (or 5) functional components that
work together to address use case 1 and provide a foundation to support the
other use cases.  It contains the following logical functional components: 

1.	Data/Content Repository - A repository of security metadata that can
be used to drive security-oriented processes (e.g. vulnerability,
configuration, asset data, assessment/collection methods).  This is
long-lived, infrequently changing information that is provided from a
variety of external information sources.  The methods used to make this
information available will likely be out of scope. 
2.	Management System - Responsible for directing collection activities
based on organizational security policy and available relevant metadata from
the content repository that may drive supported security processes. 
3.	Sensor/Collector - Responsible for collecting actual system state
information (e.g. configurations, software inventory, patch) based on
commands provided by the management system, potentially using collection
instructions provided by the content repository (e.g. SCAP-style assessment
content).  This could be an agent on an endpoint or a remote collection
system. 
4.	Processor - An upstream component that receives collected state
information.  This could be a data repository, an information processor that
acts on the provided information or a process that routes information to
other sources.  Information flowing to this component is expected to be
time-sensitive and frequently changing.

Based on these components there are 4 data flows.  The arrows do not
indicate the general flow of information and do not imply if the information
is pushed or pulled across the interface.  The data flows are:

1.	Management System <-> Content Repository - This data flow is used to
provide supporting metadata that is needed to drive security processes.  The
management system uses this data flow to acquire the information it needs to
determine what actions to instruct the sensors to perform.  The management
system may also store state information in the data/content repository to
capture policy decisions for future use. 
2.	Management System -> Sensor/Collector - This is a control channel
that is used to enable dynamic management of the information collected by
the sensor/collector.  Commands containing instruction of what to collect
would be passed using this data flow.  These instructions may point to
assessment content stored in the data/content repository. 
3.	Data/Content Repository -> Sensor/Collector - Used to retrieve any
data/content that is needed to perform collection activities. 
4.	Sensor/Collector -> Processor - Used to make collected information
available to other "upstream" components that archive the information for
future use or perform additional processing.  This is the entry point for
use cases 2 and 3.

If content acquisition uses a pull-based protocol approach, data flows 1 and
3 could use the same protocol approach.  Furthermore, if it is not desirable
to have sensors directly acquire content, content could be acquired by the
management system using data flow 1 and then pass the content on to the
sensor using data flow 2. 

Another alternative to this architectural approach, pictured on the middle
left, is a coordination component that abstracts dependencies between the
management system, sensor and processor components.  This represents a
common data flow alternative to the independent data flows between these
components.  If this approach is used, specialized messages could be passed
over a common protocol to address the exchanges defined by data flows 2 and
4 above.  This component would coordinate the exchange of the messages to
the appropriate/designated peers.

The logical components in this architecture may be allocated in software as
one or more software components.  Where components are combined, the data
flows may be proprietary or unneeded.  My base assumption is that we would
work to eventually define standards for all of the data flows.  In the short
run it might be a good idea to focus on a subset of this work, and possibly
point to existing protocols for some of this, at least in the short run.

This all assumes work on UC 1.  Is this the right slice of the use cases?
If so, does this sound like a reasonable approach?  Do you see any
alternative approaches?

Sincerely,

Dave

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2793 / Virus Database: 2629/5900 - Release Date: 11/16/12

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 20 Nov 2012 12:00:44 -0500

+1

I agree, this is a great start, thank you!  The narrowing of scope to UC1 makes sense.

To build upon the message below, I would suggest that we look at the requirements for the flows/interfaces before proposing solutions to hit upon the requirements gathering request of the BoF attendees.  I went through UC1 in the use case document and will send out comments in addition to this initial list of considerations on requirements.  We will also need requirements on the functional components, this list is just meant to touch upon protocol and format requirements for consideration.

If you look at the list of functional components and flows listed below, what are the requirements for each?  
   I see mention of a pull requirement, which flows does this apply?  
   Would another requirement be that the interface to access data is uniform, but the storage of that data does not necessarily need to be uniform?  
   Which functional components or flows have sensitivity levels (authentication, confidentiality, integrity, non-repudiation) that require greater security?  For example, is there a need for transport security protection against session hijack protection for all flows?  Are these security requirements just for flows and not data formats/languages?
   Do some of the functional components require tight access controls (which) or should they be open to all?  
   Is extensibility a requirement, and where?  
   Internationalization would be a requirement for any exchange formats/languages (where does that apply to the functional components and flows).  Are multi-lingual reports permitted/required?
   Formats and languages - would they be required to be separate from transports?  I think yes.
   Will some or all formats require globally unique identifiers - which ones?

Any thoughts on this list of requirements?  Are there other requirements that should be considered for the architecture and flows to other aspects of UC1?

Thanks,
Kathleen
  
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Chandrashekhar B [[email-masked]]
Sent: Monday, November 19, 2012 1:15 AM
To: 'Stephen Hanna'; 'Waltermire, David A.'; [email-masked]
Subject: Re: [sacm] A potential scope narrowing architectural approach

+1

I like the idea of having one protocol to store and retrieve both from Content Repository and Processor. Implementers could keep them as separate component if they choose to but, by having single protocol, we are allowing combining these two components into one and call Content Repository.

Thanks,
Chandra.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Saturday, November 17, 2012 6:43 PM
To: Waltermire, David A.; [email-masked]
Subject: Re: [sacm] A potential scope narrowing architectural approach

Dave,

I like the idea of narrowing the scope even more. UC1 is probably the minimum that’s still useful. Let’s focus on that. We can always go back and add UC2 and UC3, if we design things properly.

For example, the Content Repository is a nice, flexible component: a database. Let’s use one protocol to access it (for data flows 1 and 3). And why can’t the Sensor use the same Content Repository and protocol to store the information collected in data flow 4? By putting this information into a common repository and having a standard protocol for accessing it, this information can then be used by a variety of components: a compliance reporting tool, an analyst searching for machines known to have software with a newly discovered vulnerability, an enforcement system that handles UC2. UC3 can result in periodic or triggered updates to the Content Repository.

In addition to having the Content Repository as one flexible component, I would like to see a flexible control protocol with multi-party notification (e.g. IF-MAP or an ESB) that can be used for data flows 2 and 4 now and for other data flows later. For UC1, this control protocol should be used in data flow 2 to direct data collection and in data flow 4 to indicate that new data has been uploaded to the Content Repository. In UC1, this notification will be used only for reporting on system compliance. In UC2, an access controller can use the notification in data flow 4 to determine access. And in UC3, the same notification becomes part of real-time reporting and response. But this only works if the control protocol is flexible enough that it isn’t bound to only one use case.

So I totally agree with the idea of focusing on UC1 for now. I just want to use general-purpose protocols and components that can be used to solve the other use cases later. And maybe we can use already existing standards for those protocols so that we don’t have to invent them!

Steve

Sincerely,
Dave
________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2013.0.2793 / Virus Database: 2629/5900 - Release Date: 11/16/12

---

From: Adam Montville <[email-masked]>
Date: Tue, 20 Nov 2012 17:45:24 +0000

+1 (Sorry to have been away for the past week or so)

> Any thoughts on this list of requirements?  Are there other requirements that should be considered for the architecture and flows to other aspects of UC1?

I had thought we could look for high level requirements by using controls described here: http://www.sans.org/critical-security-controls/

Those controls should be migrated from the SANS.org domain to a separate domain at some point in the future.  I'm thinking that UC1 pertains to controls 3, 10, and 4, while supporting a piece of controls 1 and 2 (asset identification).

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

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 20 Nov 2012 12:58:28 -0500

Kathleen,

Comments below marked [daw].

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Tuesday, November 20, 2012 12:01 PM
To: [email-masked]; 'Stephen Hanna'; Waltermire, David A.; [email-masked]
Subject: Re: [sacm] A potential scope narrowing architectural approach

+1

[daw: Agreed.  It is important that we don't skip ahead to a solution without understanding the requirements first.]

[daw: I'll respond to your other email with some thoughts in this area.]

[daw: The pull requirement was a suggestion for the data flows #1 and #3 for data\content repository access.  I think it would be ideal to use a uniform transport and messaging model, but to allow flexibility in the content of the messages to allow for different data models to be exchanged.]

[daw: We do need to understand at what level is security protection needed.  How this is handled could greatly affect the degree of interoperability we get from the base protocol.  For example, if confidentiality and/or integrity is handled at the data format level, then different mechanisms may be used across the same protocol.  This is less than desirable in my mind from an interoperability perspective.  If instead it is handled at the transport or messaging layer in a way that supports confidentiality or integrity of any data that is passed, we are in a position to allow for greater interoperability (e.g. TLS).  My hope is that authentication hooks may be provided at the protocol level potentially allowing for authorization mechanisms within implementations.  We may want to treat authorization as out of scope for the time being.]

[daw: All good questions that we need answers to.  It might make sense to get agreement in general on the data flows and then dive deep to answer these questions for each one.  It might be easier to follow the conversation if we treat it that way.]

Thanks,
Kathleen

+1

Thanks,
Chandra.

Dave,

Steve

Sincerely,
Dave
Version: 2013.0.2793 / Virus Database: 2629/5900 - Release Date: 11/16/12 _______________________________________________

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 20 Nov 2012 13:34:32 -0500

I am on the fence for using the same approach for both exchanging content that supports assessment and the results of assessment.  I think the data access patterns are very different and might be better served by different protocol approaches.  For example, content supporting assessment will likely change infrequently (daily/weekly/monthly) with high concurrency,  short-term access, while result of assessment or the publication of events may change frequently (seconds/minutes) with potentially long running connections with less concurrency.  Essentially there will be a greater likelihood of having more processors compared to content repositories by the nature of what they do.

Sincerely,
Dave

From: Chandrashekhar B [mailto:[email-masked]]
Sent: Monday, November 19, 2012 1:15 AM
To: 'Stephen Hanna'; Waltermire, David A.; [email-masked]
Subject: RE: [sacm] A potential scope narrowing architectural approach

+1

Thanks,
Chandra.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Saturday, November 17, 2012 6:43 PM
To: Waltermire, David A.; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] A potential scope narrowing architectural approach

Dave,

Steve

Sincerely,
Dave

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 20 Nov 2012 14:09:24 -0500

I think if we focus on requirements (functional components and flows) for now, then we will be able to figure out if the same protocols can be used or if requirements lead us to another answer.

Thoughts?

Thanks,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Waltermire, David A. [[email-masked]]
Sent: Tuesday, November 20, 2012 1:34 PM
To: [email-masked]; 'Stephen Hanna'; [email-masked]
Subject: Re: [sacm] A potential scope narrowing architectural approach

Sincerely,
Dave

+1

Thanks,
Chandra.

Dave,

Steve

Sincerely,
Dave