Subject: [sacm] Use Case Document and UC1

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

Hello All,

Adam & Dave, nice job on the updated Use Case document!  In an effort to narrow the scope and continue the conversation on requirements, focused on UC1, I took a look at the document again with that focus and would like to know what others think from their review and/or my comments/questions.

Use Case document:

If we are to select UC1, is asset management in scope as detailed in Section 4?  If this is out-of-scope, should we come up with a statement on where this data is obtained, existing standards that we just reference?

In section 4, Functional capabilities, I believe the second sentence should say UC2.  Then in Capabilities to support UC1, this also talks about enforcement to connect to the network, was this meant to be UC2 as well?

If we plan to align to UC1, knowing the scope will help to determine the requirements, then an architecture can be formalized.  Would 4.1 change to something like: "This is essentially a configuration assessment check for all registered assets on the assessed network."

Data collection seems to be in scope as an obvious requirement (need to get more specific as to what this means for requirements though).

For Security Configuration Management, what are the set of requirements?  Does this include one or multiple methods of getting information?  Is this device or system specific with an aggregation/translation method to a single method? Or are multiple methods okay?

4.1.2.2: Vulnerability Management:
What are the requirements here?  Is it that we are able to retrieve a commonly formatted set of vulnerability information (or multiple) and use that in our security assessment tools against our asset repository/database (using any method or a specific method)?  I would think any method would be allowed…

Section 4.1.3:
I think this is getting closer to setting requirements.  Would we require the use of a control framework for caparison?  Keeping in mind that a control framework does not set the requirement level, but rather the policy does that uses the control framework to provide a uniform structure to make it easier to compare controls and ensure a holistic view of security is considered.

Section 4.1.4 Content Management:
Are there any requirements on content management?  I would argue that you may only want a common interface to shared content and that the data can be stored in other formats.  Does this also set up a requirement for repository access?

Please feel free to comment, correct, expand upon, etc. this list and the Use Case document to help get the requirements further along.

Thank you!
Kathleen

---

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

> If we are to select UC1, is asset management in scope as detailed in Section 4?  If this is out-of-scope, should we come up with a statement on where this data is obtained, existing standards that…

I would view only asset identification as necessarily in scope. 

> In section 4, Functional capabilities, I believe the second sentence should say UC2.  Then in Capabilities to support UC1, this also talks about enforcement to connect to the network, was this mean…

OK.  Can take a look.

> For Security Configuration Management, what are the set of requirements?  Does this include one or multiple methods of getting information?  Is this device or system specific with an aggregation/tr…

In a separate thread, I suggested we look at the 20 Critical Security Controls (numbers 3, 4, and 10) as being the top-down drivers of Security Configuration Management.

How do people on this list feel about deriving top-down requirements in an informational draft vs. on the list?  I can put something together.

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

---

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

Thank you for the great comments!  My responses are marked with [daw] below.

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, November 20, 2012 12:48 PM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [sacm] Use Case Document and UC1

[daw: +1]

OK.  Can take a look.

[daw: Good catch! It looks like the second sentence should reference UC2.  The third sentence should reference UC3.  The text in "Capabilities Supporting UC1"  does reference enforcement to connect to the network which is out of scope for UC1.  The text should probably be adjusted to eliminate any confusion.]

> If we plan to align to UC1, knowing the scope will help to determine the requirements, then an architecture can be formalized.  Would 4.1 change to something like: "This is essentially a configurat…

[daw: How about "...for one or more identified assets on the assessed network"?]

> Data collection seems to be in scope as an obvious requirement (need to get more specific as to what this means for requirements though).

[daw: +1]

> For Security Configuration Management, what are the set of requirements?  Does this include one or multiple methods of getting information?  Is this device or system specific with an aggregation/tr…

[daw: I think we would be best served to make this aspect extensible, allow for multiple methods to be used.  We probably need to define a mechanism to identify multiple gathering methods, maybe using an IANA table.  MTI issues will eventually need to be discussed when we start to work a draft on this subject.]

[daw: We have a start to defining some of the requirements in the use cases draft.  It is a skeleton that needs some fleshing out.  This seems like the kind of content that could help with that.]

> What are the requirements here?  Is it that we are able to retrieve a commonly formatted set of vulnerability information (or multiple) and use that in our security assessment tools against our asset repository/database (using any method or a specific method)?  I would think any method would be allowed...

[daw: It sounds like if we generalize the approach to use multiple gathering methods (see above), we could allow for both host-based gathering as well as database-based gathering.]

> I think this is getting closer to setting requirements.  Would we require the use of a control framework for caparison?  Keeping in mind that a control framework does not set the requirement level,…

[daw: I think we need to have some discussion here about how high (or low) we go with reporting requirements here.  In the SCAP effort we identify check or rule identifiers (e.g. XCCDF Rule Ids, OVAL definition Ids) that map to vulnerability or configuration identifiers (e.g. CVE, CCE).  These in turn can map to control identifiers (e.g. SP 800-53) and framework identifiers.  By taking a similar approach, we could use lower level identifiers and/or references as a means provide a mapping to higher level identifiers.  On some level we need to resist the urge to directly reference framework identifiers in low level content, as we will want to support addressing compliance with multiple frameworks using a single assessment.]

> Are there any requirements on content management?  I would argue that you may only want a common interface to shared content and that the data can be stored in other formats.  Does this also set up…

[daw: This is how I envision it.  We want flexibility in what data formats can be used to allow for future growth and evolution.  This seems to be a good point where we need extensibility.]

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 20 Nov 2012 13:59:02 -0500

Thanks, Adam!

I think a draft on requirements would be helpful to at least have a single place where requirements are collected.  There are other examples of this that do not get published, but help in organizing the effort.  The requirements are starting to come out a bit more clearly in several threads.

I'll take a look at the 20 critical controls as well.

Thanks,
Kathleen
________________________________________
From: Adam Montville [[email-masked]]
Sent: Tuesday, November 20, 2012 12:48 PM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [sacm] Use Case Document and UC1

OK.  Can take a look.

---

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

Thanks for the quick response!  DO others want to weigh in on what they see as requirements on this list or thier own?

Thanks!
Kathleen
________________________________________
From: Waltermire, David A. [[email-masked]]
Sent: Tuesday, November 20, 2012 1:25 PM
To: Adam Montville; Moriarty, Kathleen
Cc: [email-masked]
Subject: RE: [sacm] Use Case Document and UC1

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, November 20, 2012 12:48 PM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [sacm] Use Case Document and UC1

[daw: +1]

OK.  Can take a look.

[daw: +1]