Subject: Re: [sacm] I-D Action: draft-ietf-sacm-architecture-01.txt

From: "Adam W. Montville" <[email-masked]>
Date: Mon, 1 Dec 2014 15:58:03 -0600

Hi Lisa,

Thank you for updating the architecture draft.  I like the update to Figures 1 (design team architecture diagram) and 2 (communications model diagram).  I’m still on the fence about Figure 3 - it’s just difficult for me to follow, but that doesn’t mean others don’t find value in it.

I read through the problem statement and it gave me a couple of ideas, which I present below not necessarily as a replacement, but as a way to shorten things up a bit.  I also have a concern that the problem statement is much broader than this working group had originally intended.  We started out (pre-charter days) talking about endpoint posture assessment in the context of configuration and vulnerability assessment.  The way the problem statement is worded (including my version presented below) can be interpreted as a much larger problem than that which we had originally set out to solve.  I think we can work to scope it back some.

[Problem Statement]

Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes: Many information security practitioners spend much of their time on manual processes; Administrators can't get technology from disparate sources to work together; and, technology vendors often collect the  same data, but store or format it differently from each other.  Additionally, many of the vendors support different information security processes, yet ultimately rely on the same data, which translates to multiple data collection cycles.

Security automation and continuous monitoring require a large and broad set of mission and business processes; to make the most effective of use of technology, the same data must support multiple processes.  The need for complex characterization and assessment necessitates components and functions that interoperate and can build off each other to enable far-ranging and/or deep-diving analysis.

[/Problem Statement]

I’m also particularly interested to see how the capabilities-related sections come out in the end.  I’m reading these capabilities as somewhat different from the controlled vocabulary of capabilities I mentioned during the milestone discussion, but I could be wrong. 

Regards,

Adam

> On Nov 19, 2014, at 3:39 PM, Lorenzin, Lisa <[email-masked]> wrote:
> 
> Hi folks,
> 
> Based on our conversation in the Friday morning F2F, I've taken a crack at updating the architecture draft:
> 
> * revised both the original design team architectural diagram and the new communications-model diagram that Dave & I proposed last week
> * added a draft problem statement based on the charter and some text from the Information Model draft that we felt was more relevant to the SACM problem overall than to the information model problem
> * re-ordered the interfaces based on feedback Friday
> * misc copy-editing and small content updates
> * added a few TODO notes reflecting action items from previous F2F and interim discussions
> 
> I'd love to hear any feedback both on whether these changes (to the diagrams, especially) accurately reflect our discussion Friday morning, and on how the draft is shaping up overall!
> 
> Regards,
> Lisa
> 
> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, November 19, 2014 4:23 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [sacm] I-D Action: draft-ietf-sacm-architecture-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Security Automation and Continuous Monitoring Working Group of the IETF.
> 
>        Title           : Secure Automation and Continuous Monitoring (SACM) Architecture
>        Authors         : Nancy Cam-Winget
>                          Brian Ford
>                          Lisa Lorenzin
>                          Ira E McDonald
>                          Aaron Woland
> 	Filename        : draft-ietf-sacm-architecture-01.txt
> 	Pages           : 16
> 	Date            : 2014-11-19
> 
> Abstract:
>   This document describes an architecture for standardization of
>   interfaces, protocols and information models related to security
>   automation and continuous monitoring.  It describes the basic
>   architecture, components and their interfaces defined to enable the
>   collection, acquisition and verification of Posture and Posture
>   Assessments.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sacm-architecture/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-sacm-architecture-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-architecture-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 01 Dec 2014 17:13:38 -0500

I prefer that the problem statement for this draft not be made specific 
to vulnerability and configuration compliance.

Keeping the original charter in mind will drive the scope of what this 
working group actually works to solve, but this also recognizes that the 
work of this group can be used for other purposes and that it makes 
sense to allow for that kind of reuse as long it doesn't negatively 
impact our ability to achieve the original charter.

What does concern me, however, is this bottom-up design of this whole 
thing.  Keeping in mind the charter of this working group it seems to me 
that the most important aspect is the ability to express desired 
endpoint states in a format that can be automated.  Things like 
information models, data models, collection, etc, are tools needed to 
fulfill that automation and should therefore be designed with that need 
in mind.  Instead this is being designed in the reverse direction and 
that makes me wonder what kind of compromises will end up having to be 
made when it comes to actually being able to automate the security 
assessments.

--gun

---

From: "Adam W. Montville" <[email-masked]>
Date: Tue, 2 Dec 2014 06:50:15 -0600

> On Dec 1, 2014, at 4:13 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> I prefer that the problem statement for this draft not be made specific to vulnerability and configuration compliance.
> 
> Keeping the original charter in mind will drive the scope of what this working group actually works to solve, but this also recognizes that the work of this group can be used for other purposes and that it makes sense to allow for that kind of reuse as long it doesn't negatively impact our ability to achieve the original charter.

That’s fair, and we should all guard against scope creep if we leave it this way.

> 
> 
> What does concern me, however, is this bottom-up design of this whole thing.  Keeping in mind the charter of this working group it seems to me that the most important aspect is the ability to express desired endpoint states in a format that can be automated.  Things like information models, data models, collection, etc, are tools needed to fulfill that automation and should therefore be designed with that need in mind.  Instead this is being designed in the reverse direction and that makes me wonder what kind of compromises will end up having to be made when it comes to actually being able to automate the security assessments.

What would a top-down design look like to you?  Are you alluding to the notion of control frameworks, configuration benchmarks/baselines, and the like?

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 02 Dec 2014 12:09:13 -0500

> What would a top-down design look like to you?  Are you alluding to the notion of control frameworks, configuration benchmarks/baselines, and the like?

There's progression that starts with the prose descriptions that 
describe vulnerabilities or the desired state of an endpoint in regards 
to security configuration.

At some point these descriptions must be translated into a language 
(format, protocol, whatever) that can be machine executed.  Within the 
scope of SACM, that language is the topmost entry point and is what 
encapsulates what SACM needs to achieve.

Doing things like endpoint discovery and obtaining the necessary (and 
unambiguous) endpoint attributes are operations that are necessary for 
and in service to using that language to arrive at a computed result and 
should be designed accordingly.  Which is hard to do when that language 
is not known.

When starting the design from the bottom the decisions being made are 
subject to the horizon effect.  That is, because the needs of the end 
goal are not visible a perfectly rational choice on a decision tree 
could in fact have an adverse affect on the ability to achieve the goal.