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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 18 Nov 2015 15:44:02 +0000

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.

2.       Please expand CMDB at first occurrence

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.

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.

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.)

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)

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.

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

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.

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

I hope this helps.

Regards,

Dan