Subject: [OPSEC] Feedback on the SACM Vulnerability Assessment Scenario

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 19 Nov 2015 13:51:20 +0000

Hi,

I am reiterating a request that I made at IETF 94 in the OPSAWG meeting, and also sent to the mail lists of opsec and opsawg. The SACM WG is considering a document https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ that describes the operational practice of vulnerability reports, which we believe is an important use case in the security assessment life cycle. We are requiring feedback from operators about the scenario describe in this document - does it make sense? Is it similar with what you do in operational real life? Are you using similar or different methods for vulnerability assessment in your networks? A quick reading and short feedback would be greatly appreciated.

Thanks and Regards,

Dan

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 19 Nov 2015 20:36:19 +0000

Reading through the document has made me feel that the Title of the draft is misleading.
Based on the title I was expecting to see the Vulnerability Assessment of various network scenarios, which will be very useful information for enterprise and service provider network administrators to put in adequate tools to protect those vulnerability.

But the document only describes the procedure in authenticating a end user/points and states that you need to compare with the Vulnerability report (almost like a common sense ) without saying how and what.  I guess I had too high the expectation, but a little disappointed of not finding the information I was looking for.

Linda Dunbar

From: OPSAWG [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, November 19, 2015 7:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario

Hi,

Thanks and Regards,

Dan

---

From: "Stevens, Josh (Cyber Security)" <[email-masked]>
Date: Fri, 20 Nov 2015 03:37:29 +0000

Hi Dan,

Agreed, this does help focus the work for this SACM Working Group.  After reading the draft-coffin-sacm-vuln-scenario, I had some initial feedback from an enterprise defense perspective that might be incorporated.  Here are my contributions:

1.       In the abstract, a vulnerability report is referenced, however it's not clear whether an authenticated or unauthenticated vulnerability scan report (or both) is being referred to.  If it can consume both, I would call that out. If what's being referred to is actually a recurring industry standard vulnerability report from a vendor, that could also clear up the abstract prior to the scope statement where the vulnerability report is defined.

2.       In the abstract, there isn't a reference to the endpoint based approach that is detailed in the next section. Ideally, instead of "It begins with an enterprise ingesting a vulnerability report and ends at the point of identifying affected endpoints",  this could be better summarized as "Endpoint data is pushed to a central point for comparison with vulnerability criteria to enable posture assessment."

3.       3.3 A few comments on page 7, paragraph 4  "The attributes could be manually entered into a CMDB by a human, This would include any attributes that cannot be collected programmatically." I believe the intent here is to leave fields open for the user to define and leverage as needed, however I'm not sure we want to advocate manual entry? Ideally, if we can use a common set of algorithms that can be *manually* adjusted to provide exception based rules to the overall effort.  If we give a user the chance to mangle data sets, they probably will - I'm in favor of providing additional fields that can be interfaced with other security API's where automation is the default workflow choice.   Here are some alternatives to manual entry for these three categories:

a.       Location - for a global organization consider the DNS sub domain infrastructure, for a smaller organization consider SIEM events that stamp the closest proximity security infrastructure into an event (zone based), others might be ARP cache, DNS cache, etc.

b.      Role - compare with external maps to identify external facing endpoints, fingerprint web server packages with a local agent, scrape local process table to gauge TCP connections to the web server (is it really a web server), etc.

c.       Criticality - analytics on logins, active sessions, user account counts and net flow will provide a strong enterprise criticality score

4.       5.1 If the authenticated or unauthenticated data sets do get merged or compared, a decision tree will have to be pre-established - does the authenticated/agent based score override a more recent  but unauthenticated scan finding?

5.       For Appendix B: Priority should include cyber intelligence and campaign based vulnerability scores. For example, in 2013 - CVE's leveraged by the "Red October Advanced Cyber Espionage Campaign targeting Diplomatic officials" should be prioritized well above the CVE's used in Conficker , etc. How can this standard be directed or modified to accept industry standard Indicator of Compromise (IOC)'s and provide intel driven posture assessments?

6.       Other general comments:

o   Are mutex string acquisition, DLL fingerprinting, IOC processing and auto remediation out of the scope for the current Working Group?  In addition, to Vulnerability assessment, these would all go nicely together as part of a standard endpoint spec for vendors to communicate through.  I've seen email traffic from the group on several of these related topics.

o   Section 3. The multiple references to CMDB make some potential assumptions about managed vs. unmanaged endpoints

?  It's possible that unmanaged endpoints won't be found in a CMDB, does this model account in any way for those?

?  An alternative is to consider continuous netflow analytics updating a repository / data lake

o   Is Rogue Device Detection under consideration as a data point or even an Endpoint Type?

o   Discovering neighboring endpoints

o   ARP as sensor data

o   Once a rogue device has been detected, a detailed (or secondary) vulnerability assessment should begin automatically.

Hope this helps.

Josh Stevens
Hewlett Packard Enterprise

From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, November 19, 2015 7:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [sacm] Feedback on the SACM Vulnerability Assessment Scenario

Hi,

Thanks and Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 22 Nov 2015 14:48:07 +0000

Hi Linda,

Thanks for answering the call for review and having a look at this work.

Concerning your 'little disappointment': This I-D needs to be read in the context of the current charter of the SACM WG. The WG charter focus for this phase is on the 'endpoint posture' and on the 'enterprise use case'. Maybe this makes things somehow more clear.

Regards,

Dan

From: sacm [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, November 19, 2015 10:36 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario

Linda Dunbar

From: OPSAWG [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, November 19, 2015 7:51 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario

Hi,

I am reiterating a request that I made at IETF 94 in the OPSAWG meeting, and also sent to the mail lists of opsec and opsawg. The SACM WG is considering a document https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dcoffin-2Dsacm-2Dvuln-2Dscenario_&d=BQMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=DXOABUhWgQkWYGVviFzuEvwgbivmgrBaeyHQ3_W-Hyg&s=S_CieVlne2x4XqE2cNL0Y_mb0dcPAGm4cN6hKa5k-6Q&e=> that describes the operational practice of vulnerability reports, which we believe is an important use case in the security assessment life cycle. We are requiring feedback from operators about the scenario describe in this document - does it make sense? Is it similar with what you do in operational real life? Are you using similar or different methods for vulnerability assessment in your networks? A quick reading and short feedback would be greatly appreciated.

Thanks and Regards,

Dan