Subject: Re: [sacm] http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 comments

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 1 Aug 2013 12:01:06 +0000

Comments inline marked [daw].
________________________________________
From: [email-masked] <[email-masked]> on behalf of Chris Inacio <[email-masked]>
Sent: Wednesday, July 31, 2013 8:57 PM
To: [email-masked]
Subject: [sacm] http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 comments

I think the architecture draft would be helped TREMENDOUSLY by defining some terminology and using it to describe the intents of the architecture.  By having everything be defined as "DF #", it isn't very descriptive.  It doesn't have to be named in any form that implies using any particular solution (obviously, that would be bad) but by defining an architecture, you are effectively splitting the problem into (hopefully) manageable components with defined tasks.

Maybe splitting terminology out of the use-case doc and into a separate doc so that everything can use it (and for easier reference in the future.)

[DAW: I see that adoption of the use case document as a WG document is on the agenda for a consensus call. If concesus is confirmed on the list, could we use the use case document as this reference?]

Additionally, since we are the IETF, maybe we want to call the DF's protocols - it's kind of our bread and butter. :)

[daw: +1.  I'm happy to make that change if others agree. ;-)]

Second general comment, I understand the goal of the document/architecture being such that an we could use a passive/active separate evaluator to create information about a <host> - but I think that's hard to discern from the architecture.  Second, from the architecture, it's hard to discern that the goal is to evaluate a <host>.  I'm using <host>, the charter uses endpoint.  Can we identify what that is - because I'm not so sure.  Does that include a manageable network switch?  A printer?  A laptop?  What if the printer runs Windows?

[daw: A few questions/comments:

 - That is the intention of the "sensor" component of the architecture. It can make observations about posture using various mechaisms (e.g., remote API calls, local API calls, passive analysis, network management protocols, etc.). This is not very clear in the current draft.  I'll address this in the next revision. Some of this confusion is centered around using the term "sensor". Would "collector" be better? Any ideas for other terms to use instead?
- We need to address terminology.  I can either reference a seperate terminology draft, the use case draft, or embed used terms.  Any thoughts on what would be best?]

RFC5209 (NEA requirements) defines endpoint as:

Endpoint - Any computing device that can be connected to a network.
      Such devices normally are associated with a particular link layer
      address before joining the network and potentially an IP address
      once on the network.  This includes: laptops, desktops, servers,
      cell phones, or any device that may have an IP address.

Is that the intended scope for SACM?  (It's copied into the use cases, and references 5209 there, that way.)

[daw: yes. This is the intent of the draft. I'll address this in the next revision.]

The Controller:

The controller receives data collection tasks?  From whom, where?

[daw: The evaluator is intended to dispatch collection tasks for posture information it needs for evaluation that cannot be retrieved from the data store. This is used to collect up-to-date or ad-hoc data as needed.]

In the LMAP working group, derived from the IPPM working group (mostly well aligned to the broadband forum) the terminology in use is Instructions and Reports.  From that paragraph, I would be, I imagine the controller as an intelligent MEDIATOR (stealing terminology from IPFIX) which can be inline to sensors and understands the sensor & evaluator infrastructure such that it can take complex tasks and allocate them appropriately - and then combine the results?

Is that the intention?

[daw: Yes. The controller is a request dispatcher for sensors (and potentially other controllers). It knows what information can be collected from which sensors for a single or a collection of endpoints. Using this information it will parse out tasking to individual sensors and will combine the results.  I'll add more detail to address this in the next revision.]

If I turn that into reality, then I might have something like:

And passive asset/vulnerability device at the border, and IDS at the border, a active scanner inside the appropriate network segment, some host based agents able to send back configuration status, and the software configuration system.  (Product wise, if it helps people, think:  passive inventory:Tennable PVS, active scanner: Nmap/metasploit, host agents: McAfee ePolicy Orchestrator/End Point Protection, software config management: Windows AD.)

At some central console (no idea where / if that fits into the architecture) I send a task (née Instruction) to the Controller.  The Controller, using something akin to a compiler, breaks the Instruction down into sub-Instructions and sends those to the passive asset/vuln detector, active vuln scanner, host based config agent, and software config management system.  Presumably, because this is about security, and we're not very trusting folks, the Controller asks as MANY as possible the same question.

Then the Controller receives the Reports, presumably it detects discrepancies.

[daw: This is a good example of the intended functionality.]

I'm nervous about what level of detail we dictate about the Controller, especially with respect to the Data Store.  That's really an implementors choice I think.  Not that we don't acknowledge its existence, but I'm not sure how detailed describing the iteration with data store should be.  We need describe the Controllers function, not how it gets it done.

[daw: +1 We need to describe the protocol that enables tasking a controller and the protocol(s) that the controller uses to communicate tasking to the other components. The rest can be an implementation choice.]

Can a Controller task another Controller?  Or can a Controller pretend its a sensor?  Is there a trust system involved?  Is the trust transitive?

[daw: Controllers tasking other controllers was intended, but not documented in the current draft. Gunner has also proposed this concept. Trust is something we need to discuss.]

Content Repository:

What are the security requirements for the Content Repository?  Everything accesses it, including potentially compromised endpoints.  Is that really necessary?  It seems almost as if the glueing together of the system is via the Content Repository.

I'm not really clear, what the Content Repository really is.  Is it a big Oracle system (or Postgres, CouchDB, MonetDB, MongoDB, or … for anyone who has their favorite DB system) with 3 extra protocols on top that aren't SQL?

[daw: The purpose of the content repository is to provide requested data sets on demand (e.g. vulnerability scores and characteristics, policy rules, collection rules, etc) that make the system more dynamic and data driven. The sensor accesses it to get collection rules. This enables a collection task to reference a set of rules that can be retrieved by then sensor. The controller can retrieve rule sets that instruct or inform how to decompose requests into sub-tasks. The evaluator can retrieve analysis rules that can be used to parameterize or define analysis processes. In all cases, use of the content repository should be optional, but doing so would make an implementation less configurable and more static in functionality.

Access to the content repository should be controlled to restrict unauthorized access. We need to work out how best to address this. If the endpoint is compromised, it may be possible to query the content repository.  Behaviorial analysis, provided by elements of the SACM system, can be used as a method to detect this and restrict access. This might be one way to eat our own dogfood? ;-) It is also likely in a compromise scenerio that much of the information the component has retrieved will be accessable by the attacker anyway.]

--
Chris Inacio
[email-masked]

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

---

From: David Harrington <[email-masked]>
Date: Thu, 01 Aug 2013 14:32:11 +0200

Comments inline as [dbh:]

On 8/1/13 2:01 PM, "Waltermire, David A." <[email-masked]>
wrote:

>Subject: [sacm] 
>http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 comments
>
>I think the architecture draft would be helped TREMENDOUSLY by defining
>some terminology and using it to describe the intents of the
>architecture.  By having everything be defined as "DF #", it isn't very
>descriptive.  It doesn't have to be named in any form that implies using
>any particular solution (obviously, that would be bad) but by defining an
>architecture, you are effectively splitting the problem into (hopefully)
>manageable components with defined tasks.
>
>Maybe splitting terminology out of the use-case doc and into a separate
>doc so that everything can use it (and for easier reference in the
>future.)
>
>[DAW: I see that adoption of the use case document as a WG document is on
>the agenda for a consensus call. If concesus is confirmed on the list,
>could we use the use case document as this reference?]

[dbh: for now, as we start with use cases, having the terminology there
makes things fairly simple.
However, we might want to put terminology on standards-track, but not use
cases, which are Informational.
So I think we should assume that the terminology might move in the future.
As we work in parallel on use cases, requirements, and architecture, we
can probably duplicate terminology in each document (if I as use-cases
author have to wait for David to add a term to his arch doc before I can
use it, that will slow work a lot.
We can reach consensus on terms and definitions as we go, and then extract
them to a common location later or as we go.]

>
>Additionally, since we are the IETF, maybe we want to call the DF's
>protocols - it's kind of our bread and butter. :)
>

[dbh: the problem with the term protocols is that protocol might mean
something different to you than to me, because we have different levels of
experience with specific protocols that have certain inherent properties.
DF is an obvious abstraction of the flow of data, which presumably flows
over some yet-to-be-determined-set of protocols, with some
yet-to-be-determined-set of properties. I prefer DF.]

>David Harrington
>[email-masked]