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:58:47 +0000

Hi Dave,

I have finally had an opportunity to read through the architecture
document - nice work.  I've also been through the list to get a feel for
the questions that have been asked.  Hopefully, the following comments
don't overlap too much.

I believe Gunnar asked a detailed question about what needs to be
communicated to sensors and what they provide back - the example used
OVAL.  I, too, would like clarification on this, but I'm wondering if this
should be clarified on a per checking system basis.  OVAL happens to be
split where it can do some analysis or provide just harvested values.
Other checking systems may not have such a split.

Also, I'm wondering if the sensors should pull or if the controller should
push...  It seems odd to me that the sensor would need to pull, which is
what I'm inferring from the present draft (see "Sensor Management under
2.1.1 and the more explicit mention in the second bullet under 3.1).

Also regarding sensors, we should consider a variety of different
proprietary architectures that exist today and recognize that what is
exposed as a "sensor" may not be a sensor at all, but instead a proxy to a
collection of sensors.

Under 3.2, I'd really like to see us steer away from describing
"potentially how to collect" information.  I believe that, if we stick to
describing "what" over "how" we'll allow for greater innovation by vendors.

I'm not convinced that we need 3.3 and 3.4 (Collected Data Publication and
Collected Data Query, respectively).  Data Publication implies an active
push of data to a publication location.  I'd rather provide an interface
from which available data is pulled.  This brings me to Data Query, which
I also don't think we need in any detailed manner - we should provide
wholesale results, but not necessarily enable queries into the details of
that data.  To me, it makes more sense to provide results in appropriate
data formats, provide an interface to those formats, then let the market
do the rest in terms of sucking up that data for further analysis.  A
query would still be needed, but it's not necessarily a complicated one or
even one that requires it's own language (I.e. Xquery, SQL, SPARQL, etc.).

Finally, looking again at Figure 1, I'm wondering why the Content
Repository and Data Storage locations aren't the same component.  Maybe
I'm making too many assumptions, but it seems that (especially if the Data
Publication and Data Query need not be overcomplicated) the Content
Repository could house not only pre-assessment content but post-assessment
results as well.

The net is that I think we can simplify the architecture somewhat by
reevaluating what we ought to standardize.  It might be reasonable to
reconsider DF1 (Content Retrieval) to enable retrieval of two types of
content: Processing/Instructional and Results.  Then, DF2 handles
collection tasking by asset set, and we have no need for two additional
interfaces.

Thoughts?

Adam

On 2/10/13 4:44 PM, "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]]
>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]
>https://www.ietf.org/mailman/listinfo/sacm
>
>

`

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 06 Mar 2013 14:12:11 -0500

Dave, pardon, I'm going to jump in on a couple of Adam's comments.

1) Pull vice push

I think both pull and push at the "sensor" level need to be supportable.

The architecture Dave is proposing seems to be oriented on change 
detection at the endpoints, which is a good goal.

But my experience is that that is not sufficient:  security managers 
want to be able to do user-initiated assessments, both partial and full. 
  Initiating from the top down needs the capability to actively poll the 
endpoint for data item(s).

Additionally there is the possibility of what to do when a new 
vulnerability is announced and available in the content repository. 
Ideally this would then trigger an immediate evaluation of applicable 
endpoints, which is again a top-down initiated action.

2) Combined data store

Not to put words in Dave's mouth, but I think we're both championing the 
idea of defining each component in terms of implemented "interfaces" or 
"capabilities."

The ability to store/retrieve assessment results is a capability that 
defines a results repository (or what Micheal Hammer referred to as 
"derivatives", which could also be derivatives of previous derivatives). 
  That same repository can also implement the interfaces necessary to be 
used as a content repository and/or collected data repository.

At the topmost level where a content repository is the definitive source 
(for example, the vulnerability repository at NVD) it doesn't make sense 
for it to implement the ability to store results and/or collected data 
items.  And so on.

Also, consider that a content repository is fairly static and services 
requests with potentially large data globs, whereas a collected data 
repository in an event-oriented network will be highly transactional 
with small data items.  Database tuning for these two cases would not be 
the same.

3) Proxy to sensors

Absolutely.  To do an evaluation there is a need to specify what data 
items are needed and get them back in a usable format.  That returned 
data set should include an indicator of the currency of each data item 
(how long ago it was collected) and some sort of reliability measure 
such as the proximity to the actual endoint.  But other than that, I 
don't see a need to build any assumptions into the data exchanges.  The 
collector could be the actual endpoint, a proxy with the ability to 
query multiple endpoints, or a data store.

Consider a hybrid case as an example, where an evaluation is triggered 
when then makes a data request of a sensor, which in this case is a 
CMDB.  The CMDB then fulfills the data request with all known items but 
also brokers a direct query of the endpoint for those data items that 
are not in the CMDB or are not current enough and then responds with the 
completed data set.

The originating data request can contain attributes to indicate 
preferred handling -- what level of currency is acceptable, if an actual 
query of the endpoint is required or disallowed, etc.

---

From: Adam Montville <[email-masked]>
Date: Wed, 6 Mar 2013 21:30:45 +0000

Gunnar, thanks for the feedback!

I think what I really want to steer away from is getting so detailed in
being able to query the results of what is produced that it essentially
prescribes a reporting framework of some kind.  Perhaps unwarranted, but
I'm definitely trying to keep it simple.

Adam

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 06 Mar 2013 19:18:05 -0500

> I'm definitely trying to keep it simple.

Well, my take anyway.  I'll be interested to hear if anybody has a 
different view.

But I don't think we can stay away from having to get to a much lower 
level of detail.

Right now maybe it's enough to talk about the general data flows that 
enable this, but I don't think it will be of much use if we don't also 
define at least a basic minimum payload for each data flow.

And if you take that a step further, how useful is a set of endpoint 
artifacts if you don't have any trust in how they were collected?  Same 
for derivative results.

If we go the other direction and simply define these data flows but 
allow them to be used with arbitrary payloads, who would bother 
implementing that?  Proprietary systems could talk to themselves but not 
with others, which is what they're already doing.

I certainly think that we shouldn't define a single payload definition 
and leave it at that.  The actual payload for each dataflow should be 
unlimited, with the caveat that the one specific one we define *must* be 
supported on request for each published interface.

And yeah, what I'm advocating from the collection end sounds a lot like 
OVAL.  At this early point I don't want to say that OVAL or any other 
existing standard should be adopted, I just happen to strongly agree 
with many of the original design principles behind OVAL.

If you can see a way to keep things simple within those constraints, 
heck yeah.

---

From: "Baker, Jon" <[email-masked]>
Date: Mon, 11 Mar 2013 16:50:05 +0000

>Other checking systems may not have such a split.

[Baker, Jon] For those of you that are less familiar with OVAL, I should explain Adam's comment about OVAL doing some analysis and or some representation of harvested values. OVAL currently defines three primary data models:

- OVAL Definitions Model - The definitions model provides an extensible framework for making assertions about machine state. For example, the minimum password length setting is set to 8 characters. Assertions ranging from very simple to highly complex can be expressed as needed. The model then has a set of defined extension points to allow for the expression of assertions about platform specific constructs (RPMs, Registry Keys, etc). 

- OVAL System Characteristics - The system characteristics model is an extensible framework for representing machine state, or as Adam called it "harvested values". Key components in this model allow for the representation of some basic system information (what OS is running, FQDN, IP Address, MAC address) and the system data (in adam's words "harvested values" like file info, registry keys, RPMs, etc), and basic information about the tool that was used to harvest this data. Here too, the platform specific constructs are all defined by extensions to the core model.

- OVAL Results - The results model leverages the other two models and adds in the ability to express detailed assessment results. 

OVAL attempts to not define how you collect information. This is an important distinction to understand. For example, OVAL allows for assertions about windows registry keys, but does not require one method for collecting the registry key information. One product might use the C++ apis on the endpoint and another might use remote registry access in an agentless mode, and yet another might simply query a database that happens to hold the needed registry information. This allows for flexibility across endpoint operating systems, environments, and tools implementations.