Subject: Re: [sacm] comments about draft-coffin-sacm-vuln-scenario-00

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 2 Dec 2015 13:32:10 +0000

Hi Dan,

Thanks for the feedback!

Comments inline below.  Please let me know if I am misunderstanding anything.

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, November 18, 2015 10:44 AM
To: [email-masked]
Subject: [sacm] comments about draft-coffin-sacm-vuln-scenario-00

Hi,

I read about draft-coffin-sacm-vuln-scenario-00 and I consider it a very useful document, that can help focus the work of the SACM WG and which complements well RFC 7632.

Here are my comments (as contributor).

1.       (nit) I-D editing recommendations suggest to avoid including references in the Abstract section of the I-Ds.

[danny]: what is the best way for us to address this?  Is it to simply remove the reference (i.e. [RFC7632])?  Or, do we need to rework the abstract so it doesn't specifically call out the use cases document and by doing so eliminate the need to include [RFC7632]?

2.       Please expand CMDB at first occurrence

[danny]: will do.

3.       In 3.1 - Endpoint IDs should be not only unique but also persistent. This aspect should be emphasized. Because of the persistency aspect IP addresses are problematic as endpoint IDs - maybe they should be taken out of the list of examples, or maybe the whole list should be taken out.

[danny]:  I agree persistence is important and we will emphasize.  Regarding persistency, one thing we discovered in the Endpoint ID Design Team is that identifying attributes have various levels of persistency (e.g. DHCP assigned IP address versus a statically assigned IP address) and what identifiers get considered with respect to identifying an endpoint are dependent on the organization and their infrastructure (e.g. a device certificate is a great unique identifier, however, not all organizations have them deployed in their networks).

At the end of the day, what is most important is for an organization to know what attributes it considers necessary for identifying an endpoint on their network as well as having an understanding of the persistency of those attributes to be able to accurately track them over time and across sensors deployed in the infrastructure.  That is, I am not sure we can exclude attributes for endpoint identity just because they change over time.  Anyways, I will try to capture this at a high-level in the document since going into detail may go beyond the scope of this document (e.g. gets into other things discussed on the list such as a matching algorithm, etc.) and is probably best served for the information model.

Regarding the list of examples, it is by no means comprehensive more just to help the reader understand what we are talking about.  I think I would prefer to keep the list in there for that reason, but, it would be great to hear what others think.

4.       In 3.3 - Open port / running services - this should be complemented with the active (or activated) services. Some services may be installed but not activated, or may be suspended. Other services or endpoints may be in dormant mode.

[danny]:  aren't running services "active" services?  Or, are you just saying that rather than only considering running services, we should be more broad and consider all services and include their corresponding state (active, suspended, dormant, etc.)?

5.       Location is not always a human-assigned attribute. Actually the whole use case description seems to ignore the mobility scenario, as well as BYOD which is mentioned once, but in a different context, and which also comes typically together with mobility. In such cases location is an acquired/computed attribute, and the security characteristics may differ function of the location (some services may be allowed only within a perimeter, etc.)

[danny]: agree. You might be able to get a sense for location by looking at the switch, wireless access point, cellphone tower, etc. an endpoint is connected to or possibly through other means like GPS, etc.  We can add this to the list of pre-assessment data collection as it is probably something you want to track about endpoints over time.  With that said, there are also some comments in the information model that ask if certain location information (e.g. location of an IP address in the network topology, geographic location, etc.) are too complicated for a first pass for SACM.

Regarding mobility and BYOD in general, given that we created this scenario to focus our efforts, do we want to scope this out for now?  That is, we would just focus on traditional endpoints in this first pass (workstations, servers, network infrastructure)?

6.       Section 4 - beyond Ingest Date and Date of Report Release, there is one more piece of similar metadata which seems useful to include - Data Retrieval Date (which can be obviously different from the previous)

[danny]:  is "data retrieval date" referring to when data was collected off an endpoint?  If so, is it associated with data collection in general or just data when collected for a specific report?

7.       Section 8 - Security Considerations - needs at least to mention that the Security Considerations of RFC 7632 apply. Also, the vulnerability reports themselves include very sensitive security information, the disclosure, destroy, modification of their contents may be a significant threat. This needs to be mentioned.

[danny]:  We will make the update with respect to RFC 7632.

Regarding "vulnerability reports", in this scenario, I believe they would be publicly available.  That is, a vulnerability report is published by a vendor for consumption by consumers as opposed to the information that a researcher sends a vendor that discloses a vulnerability in a piece of software.  With that said, knowing what vulnerability reports an organization cares about may be useful for an attacker in that it will provide insight into what software is installed and may help .  Regarding destroying, modification, etc., I think it would be covered by referencing the security considerations in RFC 7632 which discusses maintaining the confidentiality and integrity of security automation data at rest and in transit.

8.       In table C1 - please mention what the head of column 'Reporting' means - I guess it's about continuous / periodical reporting, but this requires clarification

[danny]:  these column headings are supposed to align with the different processes outlined in the assessment scenario, but, were shortened.  We will update them to be explicit.

Vuln. Report    => Vulnerability Reports
Init. Collection => Endpoint Identification and Initial (Pre-Assessment) Data Collection

Assessment     => Endpoint Applicability and Assessment

Reporting         => Assessment Reports

9.       I believe that section C.2 as it stands now is not useful, actually can cause harm. We do have a terminology document in SACM and duplicating terminology definitions is not good. If this document progresses I suggest to eliminate this section and refer to the terminology I-D. If there are terms with conflicting definitions, these need to be raised in the framework of the terminology I-D and aligned. If there are missing terms these need to be added to the terminology I-D.

[danny]:  makes sense.  We will tackle this comment if the document is adopted by the WG.

10.   Several examples are Microsoft oriented (e.g. Microsoft Windows registry referred in C.2). I suggest to either try to find vendor-agnostic examples, or use multiple vendors equivalent examples

[danny]: We can add examples for other vendors such as Apple Configuration Profiles and Defaults (Mac OS), GConf (UNIX), Proc (UNIX), etc.

I hope this helps.

Regards,

Dan