draft-ietf-sacm-information-model-02.txt   draft-ietf-sacm-information-model-03.txt 
SACM D. Waltermire, Ed. SACM D. Waltermire, Ed.
Internet-Draft NIST Internet-Draft NIST
Intended status: Informational K. Watson Intended status: Informational K. Watson
Expires: January 7, 2016 DHS Expires: July 8, 2016 DHS
C. Kahn C. Kahn
L. Lorenzin L. Lorenzin
Pulse Secure, LLC Pulse Secure, LLC
July 6, 2015 D. Haynes
The MITRE Corporation
January 5, 2016
SACM Information Model SACM Information Model
draft-ietf-sacm-information-model-02 draft-ietf-sacm-information-model-03
Abstract Abstract
This document proposes an information model for SACM. This document proposes an information model for SACM.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016. This Internet-Draft will expire on July 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 6 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6
1.2. Changes in Revision 02 . . . . . . . . . . . . . . . . . 7 1.1.1. Referring to an Endpoint . . . . . . . . . . . . . . 7
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 1.1.2. Dealing with Uncertainty . . . . . . . . . . . . . . 8
2.1. Mapping to SACM Use Cases . . . . . . . . . . . . . . . . 8 2. Conventions used in this document . . . . . . . . . . . . . . 8
2.2. Referring to an Endpoint . . . . . . . . . . . . . . . . 8 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 9
2.3. Dealing with Uncertainty . . . . . . . . . . . . . . . . 9 3. Information Model Framework . . . . . . . . . . . . . . . . . 9
3. Conventions used in this document . . . . . . . . . . . . . . 9 3.1. Containers . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 10 3.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 9
4. Elements of the SACM Information Model . . . . . . . . . . . 10 3.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Identifying Attributes . . . . . . . . . . . . . . . . . 12 3.4. Relationships . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. How Known . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Designation . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Whether to Include . . . . . . . . . . . . . . . . . 13 3.6. Conventions for Modeling Information Model Objects . . . 10
4.1.3. IP Address . . . . . . . . . . . . . . . . . . . . . 13 4. Information Model Assets . . . . . . . . . . . . . . . . . . 10
4.1.3.1. Range of Values . . . . . . . . . . . . . . . . . 13 4.1. Asset . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3.2. Meaning . . . . . . . . . . . . . . . . . . . . . 14 4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3.3. Relationships . . . . . . . . . . . . . . . . . . 14 4.3. Hardware Component . . . . . . . . . . . . . . . . . . . 11
4.1.3.4. Multiplicity . . . . . . . . . . . . . . . . . . 15 4.3.1. Hardware Instance . . . . . . . . . . . . . . . . . . 12
4.1.3.5. Stability . . . . . . . . . . . . . . . . . . . . 15 4.4. Software Component . . . . . . . . . . . . . . . . . . . 12
4.1.3.6. Accuracy . . . . . . . . . . . . . . . . . . . . 15 4.4.1. Software Instance . . . . . . . . . . . . . . . . . . 14
4.1.3.7. Data Model Requirements . . . . . . . . . . . . . 15 4.5. Asset Identity . . . . . . . . . . . . . . . . . . . . . 14
4.1.4. MAC Address . . . . . . . . . . . . . . . . . . . . . 16 4.6. Relationships . . . . . . . . . . . . . . . . . . . . . . 14
4.1.5. Hardware Serial Number . . . . . . . . . . . . . . . 16 5. Information Model Elements . . . . . . . . . . . . . . . . . 14
4.1.5.1. Range of Values . . . . . . . . . . . . . . . . . 16 5.1. Identifying Attributes . . . . . . . . . . . . . . . . . 17
4.1.5.2. Meaning . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. How Known . . . . . . . . . . . . . . . . . . . . . . 17
4.1.5.3. Multiplicity . . . . . . . . . . . . . . . . . . 16 5.1.2. Whether to Include . . . . . . . . . . . . . . . . . 18
4.1.5.4. Stability . . . . . . . . . . . . . . . . . . . . 16 5.1.3. IP Address . . . . . . . . . . . . . . . . . . . . . 18
4.1.5.5. Accuracy . . . . . . . . . . . . . . . . . . . . 16 5.1.3.1. Range of Values . . . . . . . . . . . . . . . . . 18
4.1.5.6. Data Model Requirements . . . . . . . . . . . . . 16 5.1.3.2. Meaning . . . . . . . . . . . . . . . . . . . . . 19
4.1.6. Certificate . . . . . . . . . . . . . . . . . . . . . 16 5.1.3.3. Relationships . . . . . . . . . . . . . . . . . . 19
4.1.6.1. Range of values . . . . . . . . . . . . . . . . . 16 5.1.3.4. Multiplicity . . . . . . . . . . . . . . . . . . 19
4.1.6.2. Meaning . . . . . . . . . . . . . . . . . . . . . 17 5.1.3.5. Stability . . . . . . . . . . . . . . . . . . . . 19
4.1.6.3. Multiplicity . . . . . . . . . . . . . . . . . . 17 5.1.3.6. Accuracy . . . . . . . . . . . . . . . . . . . . 19
4.1.6.4. Stability . . . . . . . . . . . . . . . . . . . . 17 5.1.3.7. Data Model Requirements . . . . . . . . . . . . . 20
4.1.6.5. Accuracy . . . . . . . . . . . . . . . . . . . . 17 5.1.4. MAC Address . . . . . . . . . . . . . . . . . . . . . 20
4.1.6.6. Data model requirements . . . . . . . . . . . . . 17 5.1.5. Hardware Serial Number . . . . . . . . . . . . . . . 20
4.1.7. Public Key . . . . . . . . . . . . . . . . . . . . . 17 5.1.5.1. Range of Values . . . . . . . . . . . . . . . . . 20
4.1.8. Username? . . . . . . . . . . . . . . . . . . . . . . 18 5.1.5.2. Meaning . . . . . . . . . . . . . . . . . . . . . 20
4.1.9. Tool-Specific Identifier . . . . . . . . . . . . . . 18 5.1.5.3. Multiplicity . . . . . . . . . . . . . . . . . . 20
4.1.10. Identification of Endpoints where SACM Components 5.1.5.4. Stability . . . . . . . . . . . . . . . . . . . . 21
Reside . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.5.5. Accuracy . . . . . . . . . . . . . . . . . . . . 21
4.1.11. Security Considerations . . . . . . . . . . . . . . . 18 5.1.5.6. Data Model Requirements . . . . . . . . . . . . . 21
4.2. Software Component . . . . . . . . . . . . . . . . . . . 18 5.1.6. Certificate . . . . . . . . . . . . . . . . . . . . . 21
4.3. Software Instance . . . . . . . . . . . . . . . . . . . . 20 5.1.6.1. Range of values . . . . . . . . . . . . . . . . . 21
4.4. Hardware Component . . . . . . . . . . . . . . . . . . . 20 5.1.6.2. Meaning . . . . . . . . . . . . . . . . . . . . . 21
4.5. Hardware Instance . . . . . . . . . . . . . . . . . . . . 20 5.1.6.3. Multiplicity . . . . . . . . . . . . . . . . . . 21
4.6. Network Interface . . . . . . . . . . . . . . . . . . . . 21 5.1.6.4. Stability . . . . . . . . . . . . . . . . . . . . 21
4.7. Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.6.5. Accuracy . . . . . . . . . . . . . . . . . . . . 22
4.8. Identity . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1.6.6. Data model requirements . . . . . . . . . . . . . 22
4.9. Location . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1.7. Public Key . . . . . . . . . . . . . . . . . . . . . 22
4.10. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.8. Username? . . . . . . . . . . . . . . . . . . . . . . 22
4.11. Endpoint Attribute Assertion . . . . . . . . . . . . . . 24 5.1.9. Tool-Specific Identifier . . . . . . . . . . . . . . 22
4.11.1. Form and Precise Meaning . . . . . . . . . . . . . . 24 5.1.10. Identification of Endpoints where SACM Components
4.11.2. Asserter . . . . . . . . . . . . . . . . . . . . . . 25 Reside . . . . . . . . . . . . . . . . . . . . . . . 22
4.11.3. Example . . . . . . . . . . . . . . . . . . . . . . 25 5.1.11. Security Considerations . . . . . . . . . . . . . . . 23
4.11.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 25 5.2. Network Interface . . . . . . . . . . . . . . . . . . . . 23
4.11.5. Event . . . . . . . . . . . . . . . . . . . . . . . 25 5.3. Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.11.6. Difference between Attribute and Event . . . . . . . 26 5.4. Identity . . . . . . . . . . . . . . . . . . . . . . . . 24
4.12. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 26 5.5. Location . . . . . . . . . . . . . . . . . . . . . . . . 25
4.12.1. Unique Endpoint Identifier . . . . . . . . . . . . . 27 5.6. Endpoint Attribute Assertion . . . . . . . . . . . . . . 26
4.12.2. Posture Attribute . . . . . . . . . . . . . . . . . 27 5.6.1. Form and Precise Meaning . . . . . . . . . . . . . . 26
4.13. Evaluation Result . . . . . . . . . . . . . . . . . . . . 28 5.6.2. Asserter . . . . . . . . . . . . . . . . . . . . . . 26
4.14. Report . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 27
4.15. SACM Component . . . . . . . . . . . . . . . . . . . . . 29 5.6.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 27
4.15.1. External Attribute Collector . . . . . . . . . . . . 29 5.6.5. Event . . . . . . . . . . . . . . . . . . . . . . . . 27
4.15.2. Evaluator . . . . . . . . . . . . . . . . . . . . . 30 5.6.6. Difference between Attribute and Event . . . . . . . 27
4.15.3. Report Generator . . . . . . . . . . . . . . . . . . 30 5.7. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 28
4.16. Organization? . . . . . . . . . . . . . . . . . . . . . . 30 5.7.1. Unique Endpoint Identifier . . . . . . . . . . . . . 29
4.17. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 31 5.7.2. Posture Attribute . . . . . . . . . . . . . . . . . . 29
4.17.1. Internal Collection Guidance . . . . . . . . . . . . 31 5.8. Evaluation Result . . . . . . . . . . . . . . . . . . . . 30
4.17.2. External Collection Guidance . . . . . . . . . . . . 31 5.9. Report . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.17.3. Evaluation Guidance . . . . . . . . . . . . . . . . 31 5.10. SACM Component . . . . . . . . . . . . . . . . . . . . . 31
4.17.4. Retention Guidance . . . . . . . . . . . . . . . . . 31 5.10.1. External Attribute Collector . . . . . . . . . . . . 31
4.17.5. Reporting Guidance . . . . . . . . . . . . . . . . . 31 5.10.2. Evaluator . . . . . . . . . . . . . . . . . . . . . 32
4.18. Provenance of Information . . . . . . . . . . . . . . . . 32 5.10.3. Report Generator . . . . . . . . . . . . . . . . . . 32
4.19. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 32 5.11. Organization? . . . . . . . . . . . . . . . . . . . . . . 32
4.19.1. Endpoint Identity . . . . . . . . . . . . . . . . . 32 5.12. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 33
4.19.2. Software Component . . . . . . . . . . . . . . . . . 32 5.12.1. Internal Collection Guidance . . . . . . . . . . . . 33
4.19.2.1. Unique Software Identifier . . . . . . . . . . . 33 5.12.2. External Collection Guidance . . . . . . . . . . . . 33
4.20. User . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.12.3. Evaluation Guidance . . . . . . . . . . . . . . . . 33
4.20.1. User Identity . . . . . . . . . . . . . . . . . . . 34 5.12.4. Retention Guidance . . . . . . . . . . . . . . . . . 33
5. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 34 5.12.5. Reporting Guidance . . . . . . . . . . . . . . . . . 33
5.1. Graph Model for Detection of Posture Deviation . . . . . 34 5.13. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.1. Components . . . . . . . . . . . . . . . . . . . . . 34 5.13.1. Endpoint Identity . . . . . . . . . . . . . . . . . 34
5.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 35 5.13.2. Software Component . . . . . . . . . . . . . . . . . 34
5.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 35 5.13.2.1. Unique Software Identifier . . . . . . . . . . . 35
5.1.4. Relationships between Identifiers and Metadata . . . 36 5.14. User . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 36 5.14.1. User Identity . . . . . . . . . . . . . . . . . . . 35
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 6. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 36
6.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 37 6.1. Graph Model for Detection of Posture Deviation . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 6.1.1. Components . . . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 6.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 38 6.1.4. Relationships between Identifiers and Metadata . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . 39 6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Security Automation with TNC IF-MAP . . . . . . . . 44 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
A.1. What is Trusted Network Connect? . . . . . . . . . . . . 44 7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 39
A.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
A.3. What is the TNC Information Model? . . . . . . . . . . . 45 9. Operational Considerations . . . . . . . . . . . . . . . . . 40
Appendix B. Text for Possible Inclusion in the Terminology Draft 46 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40
B.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
B.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 46 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 47 12.1. Normative References . . . . . . . . . . . . . . . . . . 41
Appendix C. Text for Possible Inclusion in the Architecture or 12.2. Informative References . . . . . . . . . . . . . . . . . 41
Use Cases . . . . . . . . . . . . . . . . . . . . . 47 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 47
C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 47 A.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 47
C.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 48 A.2. Changes in Revision 02 . . . . . . . . . . . . . . . . . 48
C.3. Architecture Assumptions . . . . . . . . . . . . . . . . 49 A.3. Changes in Revision 03 . . . . . . . . . . . . . . . . . 48
Appendix D. Text for Possible Inclusion in the Requirements Appendix B. Mapping to SACM Use Cases . . . . . . . . . . . . . 48
Draft . . . . . . . . . . . . . . . . . . . . . . . 52 Appendix C. Security Automation with TNC IF-MAP . . . . . . . . 49
D.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 52 C.1. What is Trusted Network Connect? . . . . . . . . . . . . 49
D.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 52 C.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 49
Appendix E. Text With No Clear Home Yet . . . . . . . . . . . . 53 C.3. What is the TNC Information Model? . . . . . . . . . . . 50
E.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 53 Appendix D. Text for Possible Inclusion in the Terminology Draft 51
E.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 53 D.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 51
E.2. From Information Needs to Information Elements . . . . . 54 D.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 51
E.3. Information Model Elements . . . . . . . . . . . . . . . 54 D.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 51
E.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 56 Appendix E. Text for Possible Inclusion in the Architecture or
E.3.1.2. Endpoint Identification . . . . . . . . . . . . . 58 Use Cases . . . . . . . . . . . . . . . . . . . . . 52
E.3.1.3. Software Identification . . . . . . . . . . . . . 59 E.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 52
E.3.1.4. Hardware Identification . . . . . . . . . . . . . 62 E.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 53
E.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 62 E.3. Architecture Assumptions . . . . . . . . . . . . . . . . 53
E.3.2.1. Platform Configuration Item Identifier . . . . . 62 Appendix F. Text for Possible Inclusion in the Requirements
E.3.2.2. Configuration Item Identifier . . . . . . . . . . 68 Draft . . . . . . . . . . . . . . . . . . . . . . . 57
E.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 70 F.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 57
E.3.3. Endpoint characterization . . . . . . . . . . . . . . 70 F.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 57
E.3.4. Posture Attribute Expression . . . . . . . . . . . . 74 Appendix G. Text With No Clear Home Yet . . . . . . . . . . . . 58
E.3.4.2. Platform Configuration Attributes . . . . . . . . 74 G.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 58
E.3.5. Actual Value Representation . . . . . . . . . . . . . 76 G.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 58
E.3.5.1. Software Inventory . . . . . . . . . . . . . . . 76 G.2. From Information Needs to Information Elements . . . . . 59
E.3.5.2. Collected Platform Configuration Posture G.3. Information Model Elements . . . . . . . . . . . . . . . 59
Attributes . . . . . . . . . . . . . . . . . . . 77 G.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 61
E.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 78 G.3.1.2. Endpoint Identification . . . . . . . . . . . . . 63
E.3.6.1. Configuration Evaluation Guidance . . . . . . . . 78 G.3.1.3. Software Identification . . . . . . . . . . . . . 64
E.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 80 G.3.1.4. Hardware Identification . . . . . . . . . . . . . 67
E.3.7.1. Configuration Evaluation Results . . . . . . . . 80 G.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 67
E.3.7.2. Software Inventory Evaluation Results . . . . . . 82 G.3.2.1. Platform Configuration Item Identifier . . . . . 67
Appendix F. Graph Model . . . . . . . . . . . . . . . . . . . . 82 G.3.2.2. Configuration Item Identifier . . . . . . . . . . 73
F.1. Background: Graph Models . . . . . . . . . . . . . . . . 83 G.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 75
F.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 84
F.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 84 G.3.3. Endpoint characterization . . . . . . . . . . . . . . 75
F.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 85 G.3.4. Posture Attribute Expression . . . . . . . . . . . . 79
F.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 85 G.3.4.2. Platform Configuration Attributes . . . . . . . . 79
F.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 86 G.3.5. Actual Value Representation . . . . . . . . . . . . . 81
F.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 86 G.3.5.1. Software Inventory . . . . . . . . . . . . . . . 81
F.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 86 G.3.5.2. Collected Platform Configuration Posture
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87 Attributes . . . . . . . . . . . . . . . . . . . 82
G.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 83
G.3.6.1. Configuration Evaluation Guidance . . . . . . . . 83
G.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 85
G.3.7.1. Configuration Evaluation Results . . . . . . . . 85
G.3.7.2. Software Inventory Evaluation Results . . . . . . 87
Appendix H. Graph Model . . . . . . . . . . . . . . . . . . . . 87
H.1. Background: Graph Models . . . . . . . . . . . . . . . . 88
H.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 89
H.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 89
H.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 90
H.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 90
H.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 91
H.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 91
H.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 91
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
1. Introduction 1. Introduction
This document defines a notional information model for endpoint This document defines a notional information model for endpoint
posture assessment. It describes the information needed to perform posture assessment. It describes the information needed to perform
certain assessment activities. The scope of the information model is certain assessment activities. The scope of the information model is
to describe the structure of the information carried to realize the to describe the structure of the information carried to realize the
assessment. It is meant to be a basis for the development of assessment. It is meant to be a basis for the development of
specific data models. The terms information model and data model specific data models. The terms information model and data model
loosely align with the definitions in RFC3444 [RFC3444]. loosely align with the definitions in RFC3444 [RFC3444].
skipping to change at page 5, line 33 skipping to change at page 5, line 51
2. Endpoint Characterization 2. Endpoint Characterization
3. Endpoint Attribute Expression/Representation 3. Endpoint Attribute Expression/Representation
4. Policy evaluation expression and results reporting 4. Policy evaluation expression and results reporting
These activities are aimed at the level of the technology that These activities are aimed at the level of the technology that
performs operations to support collection, evaluation, and reporting. performs operations to support collection, evaluation, and reporting.
Review of the SACM Use Case [I-D.ietf-sacm-use-cases] usage scenarios Review of the SACM Use Case [RFC7632] usage scenarios show a common
show a common set of business process areas that are critical to set of business process areas that are critical to understanding
understanding endpoint posture such that appropriate policies, endpoint posture such that appropriate policies, security
security capabilities, and decisions can be developed and capabilities, and decisions can be developed and implemented.
implemented.
For this information model we have chosen to focus on the following For this information model we have chosen to focus on the following
business process areas: business process areas:
o Endpoint Management o Endpoint Management
o Software Management o Software Management
o Configuration Management o Configuration Management
o Vulnerability Management o Vulnerability Management
These management process areas are a way to connect the SACM use These management process areas are a way to connect the SACM use
cases and building blocks [I-D.ietf-sacm-use-cases] to the cases and building blocks [RFC7632] to the organizational needs such
organizational needs such that the definition of information that the definition of information requirements has a clearly
requirements has a clearly understood context.(/wandw) understood context. (/wandw). For more information, Appendix B maps
the SACM information model to the SACM use cases.
The SACM information model offers a loose coupling between providers The SACM information model offers a loose coupling between providers
and consumers of security information. A provider can relay what it and consumers of security information. A provider can relay what it
observes or infers, without knowing which consumers will use the observes or infers, without knowing which consumers will use the
information, or how they will use it. A consumer need not know information, or how they will use it. A consumer need not know
exactly which provider generated a piece of information, or by what exactly which provider generated a piece of information, or by what
method. method.
At the same time, a consumer *can* know these things, if necessary. At the same time, a consumer *can* know these things, if necessary.
As things evolve, a provider can relay supplemental information. As things evolve, a provider can relay supplemental information.
Some consumers will understand and benefit from the supplemental Some consumers will understand and benefit from the supplemental
information; other consumers will not understand and will disregard information; other consumers will not understand and will disregard
it. it.
1.1. Changes in Revision 01 1.1. Problem Statement
Renamed "credential" to "identity", following industry usage. A
credential includes proof, such as a key or password. A username or
a distinguished name is called an "identity".
Removed Session, because an endpoint's network activity is not SACM's
initial focus
Removed Authorization, for the same reason
Added many-to-many relationship between Hardware Component and
Endpoint, for clarity
Added many-to-many relationship between Software Component and
Endpoint, for clarity
Added "contains" relationship between Network Interface and Network
Interface
Removed relationship between Network Interface and Account. The
endpoint knows the identity it used to gain network access. The PDP
also knows that. But they probably do not know the account.
Added relationship between Network Interface and Identity. The
endpoint and the PDP will typically know the identity.
Made identity-to-account a many-to-one relationship.
1.2. Changes in Revision 02
Added Section 4.1, Identifying Attributes.
Split the figure into Figure 1 and Figure 2.
Added Figure 3, proposing a triple-store model.
Some editorial cleanup
2. Problem Statement
TODO: revise TODO: revise
(wandw)SACM requires a large and broad set of mission and business (wandw)SACM requires a large and broad set of mission and business
processes, and to make the most effective of use of technology, the processes, and to make the most effective of use of technology, the
same data must support multiple processes. The activities and same data must support multiple processes. The activities and
processes described within this document tend to build off of each processes described within this document tend to build off of each
other to enable more complex characterization and assessment. In an other to enable more complex characterization and assessment. In an
effort to create an information model that serves a common set of effort to create an information model that serves a common set of
management processes represented by the usage scenarios in the SACM management processes represented by the usage scenarios in the SACM
skipping to change at page 8, line 5 skipping to change at page 7, line 28
When creating standards, it's not sufficient to go from requirements When creating standards, it's not sufficient to go from requirements
directly to protocol; the standards must eliminate ambiguity in the directly to protocol; the standards must eliminate ambiguity in the
information transported. This is the purpose of information models information transported. This is the purpose of information models
generally. The SACM problem space is about integrating many generally. The SACM problem space is about integrating many
information sources. This information model addresses the need to information sources. This information model addresses the need to
integrate security components, support multiple data models, and integrate security components, support multiple data models, and
provide interoperability in a way that is platform agnostic, scales, provide interoperability in a way that is platform agnostic, scales,
and works over time. and works over time.
2.1. Mapping to SACM Use Cases 1.1.1. Referring to an Endpoint
TODO: revise
(wandw)This information model directly corresponds to all four use
cases defined in the SACM Use Cases draft [I-D.ietf-sacm-use-cases].
It uses these use cases in coordination to achieve a small set of
well-defined tasks.
Sections [removed] thru [removed] address each of the process areas.
For each process area, a "Process Area Description" sub-section
represent an end state that is consistent with all the General
Requirements and many of the Use Case Requirements identified in the
requirements draft [I-D.ietf-sacm-requirements].
The management process areas and supporting operations defined in
this memo directly support REQ004 Endpoint Discovery; REQ005-006
Attribute and Information Based Queries, and REQ0007 Asynchronous
Publication.
In addition, the operations that defined for each business process in
this memo directly correlate with the typical workflow identified in
the SACM Use Case document.(/wandw)
2.2. Referring to an Endpoint
How to refer to an endpoint is problematic. Ideally, an endpoint How to refer to an endpoint is problematic. Ideally, an endpoint
would have a unique identifier. These identifiers would have a one- would have a unique identifier. These identifiers would have a one-
to-one relationship with endpoints. Every observation of an to-one relationship with endpoints. Every observation of an
endpoint, or inference about an endpoint would be labeled with its endpoint, or inference about an endpoint would be labeled with its
identifier. identifier.
However: However:
o An external posture attribute collector typically cannot observe o An external posture attribute collector typically cannot observe
skipping to change at page 9, line 19 skipping to change at page 8, line 19
a unique certificate within a trusted platform module TPM. Even a unique certificate within a trusted platform module TPM. Even
so, it is possible to replace all of the software -- for example, so, it is possible to replace all of the software -- for example,
changing a Windows machine to a Linux machine. Is it still the changing a Windows machine to a Linux machine. Is it still the
same endpoint? For SACM purposes, it isn't really the same same endpoint? For SACM purposes, it isn't really the same
endpoint. endpoint.
So SACM components must be able to put disparate observations So SACM components must be able to put disparate observations
together and form a picture of an endpoint -- somewhat like a together and form a picture of an endpoint -- somewhat like a
detective. The SACM information model must facilitate this. detective. The SACM information model must facilitate this.
2.3. Dealing with Uncertainty 1.1.2. Dealing with Uncertainty
With many information models, the information is considered certain. With many information models, the information is considered certain.
In SACM, information is not certain. Attackers may develop In SACM, information is not certain. Attackers may develop
countermeasures to fool some SACM components. Attackers may countermeasures to fool some SACM components. Attackers may
compromise some SACM components. compromise some SACM components.
So the model must let SACM components and humans reason with So the model must let SACM components and humans reason with
uncertainty. There are no facts, only assertions. uncertainty. There are no facts, only assertions.
SACM components must be able to cross check observations and SACM components must be able to cross check observations and
skipping to change at page 9, line 47 skipping to change at page 8, line 47
observer or inferrer. That reputation should account for the method observer or inferrer. That reputation should account for the method
of observing or inferring, the implementer of the SACM component that of observing or inferring, the implementer of the SACM component that
made the observation or inference, and the compliance status of the made the observation or inference, and the compliance status of the
endpoint on which the observation or inference was made. For endpoint on which the observation or inference was made. For
example, if some observers are found to be vulnerable to a Day 1 example, if some observers are found to be vulnerable to a Day 1
exploit, observations from those observers deserve less weight. The exploit, observations from those observers deserve less weight. The
details of reputation technology may be out of scope for SACM. details of reputation technology may be out of scope for SACM.
However, again, SACM should provide components with provenance However, again, SACM should provide components with provenance
information. information.
3. Conventions used in this document 2. Conventions used in this document
3.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
4. Elements of the SACM Information Model 3. Information Model Framework
The SACM information model is structured around a core framework that
can be easily extended to support the modeling needs for endpoint
posture assessment. This section describes the key concepts that
make up this framework as well as the conventions used to model the
different information model objects in the following sections.
3.1. Containers
TODO: Explain containers at a conceptual level and how they are the
mechanism by which attributes and/or other containers can be
logically grouped together to create more complex models. Additional
information about containers can be modeled using metadata.
QUESTION: We are not sure "container" is the correct term to use here
as it implies a hierarchy. Alternative terms might be "construct",
"object", or "class". This is something that needs to be decided.
3.2. Attributes
TODO: Explain attributes at a conceptual level and how they are used
to model posture attribute information on an endpoint. At a minimum,
an attribute must have a name and a value. However, there is work
currently being done in the Endpoint ID Design Team to prepare a
proposal for the working group to explain how triples (subject,
predicate, object) could be used to model attributes in the
information model. Additional information about attributes can be
modeled using metadata.
3.3. Metadata
TODO: Explain metadata at a conceptual level and how it can be used
to provide additional information about containers and attributes.
We should be providing enough information so that SACM users can
determine provenance (e.g. source of origin, time of collection,
observation, reporting, etc.) and use it when sharing and evaluating
posture attribute information.
3.4. Relationships
TODO: Define what a relationship is. At the end of the day, we want
to be able to describe the relationships between assets, endpoints,
and attributes. QUESTION: Are relationships just metadata? Lisa's
notes have some information on relationships:
https://mailarchive.ietf.org/arch/msg/sacm/
kWxlnboHAXD87cned9WavwPZy5w
3.5. Designation
TODO: In the IETF, there are privacy concerns with respect to
endpoint identity and monitoring. As a result, the Endpoint ID
Design Team proposes that "endpoint identity" be changed to "endpoint
designation". Designation attributes can be used to correlate
endpoints, information about endpoints, events, etc. NOTE:
Designation attributes are just those that are mandatory-to-
implement. In practice, organizations may need to select additional
attributes beyond the mandatory-to-implement attributes to
successfully identify an endpoint on their network. Operational and
privacy concerns will be covered in Operational Considerations and
Privacy Considerations sections respectively.
3.6. Conventions for Modeling Information Model Objects
TODO: The working group needs to select the conventions that will be
used to model the different objects defined in the information model.
Members of the Endpoint ID Design Team are looking into different
examples of how other working groups have modeled the objects in
their information models so that the working can select one that
makes the most sense for SACM. Once conventions have been selected,
they should be documented here for future reference.
4. Information Model Assets
TODO: Explain the different SACM assets. Right now, we have
distilled this down to an endpoint, hardware, software, and identity.
Previously, this diagram also included account, location, address,
and network inteface, but, these things are not assets and can either
be consolidated into one of the existing asset types (e.g. network
interface => hardware, account => identity, etc.) or are just
metadata about the assets (e.g. location => endpoint). We should
also explain the types of assets below rather than just referencing
out to the Terminology draft.
TODO: The figure below needs to be updated to show the relationships
between the different types of assets.
+---------+*______in>_______*+-----+
|Hardware | |! !|
|Component| +---------+ |! !|
+---------+ |Software |in> |! !|
1| |Component|____|! !|
| +---------+* *|! !|
| 1| |! !|
| *| | | +----------+
| +---------+ |End- |*_____*| Identity |
*| |Software |in> |point| acts +----------+
+---------+ |Instance |____| | for>
|Hardware | +---------+* 1|! !|
|Instance |__________________|! !|
+---------+* in> 1|! !|
|! !|
|! !|____
|! !|0..1|
+-----+ |
|* |
|_______|
in>
Figure 1: Model of an Endpoint
4.1. Asset
TODO: Define Asset here in the context of the information model.
4.2. Endpoint
TODO: Define an Endpoint asset. Explain how it is made up of HW
components, SW components, asset identity, etc. Take relevant
information from the
An endpoint is the hollow center of the model. An endpoint is an
abstract ideal. Any endpoint attribute assertion that mentions an
endpoint mentions it by specifying identifying attributes. Even if
there is one preferred endpoint identity, that is modeled as an
identity. We do not anticipate any AVP whose attribute type is
"endpoint".
4.3. Hardware Component
TODO: Define a Hardware Component asset. Explain how it is things
like motherboards, network cards, etc.
Hardware components may also be assets and/or harmful. For example,
a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional
layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm.
A data model MAY designate a hardware component by its manufacturer
and a part number.
4.3.1. Hardware Instance
A hardware instance is just an instance of a particular component.
A data model MUST support the following relationships:
o A hardware instance is an "instance of" a hardware component.
o A hardware instance is "in" an endpoint.
Hardware instances may need to be modeled because (a) an endpoint may
have multiple instances of a hardware component, (b) a hardware
instance may be compromised, whereas other instances may remain
intact.
A data model MAY designate a hardware instance by its component and a
unique serial number.
4.4. Software Component
TODO: Define a Software Component asset. Explain how it is the
software installed on the endpoint including the operating system.
An endpoint contains and runs software components.
Relationship:
o If an endpoint has an instance of a software component, we say
that the software component is "in" the endpoint. This is a
shorthand.
Some software components are assets. "Asset" is defined in RFC4949
[RFC4949] as "a system resource that is (a) required to be protected
by an information system's security policy, (b) intended to be
protected by a countermeasure, or (c) required for a system's
mission."
An examination of software needs to consider both (a) software assets
and (b) software that may do harm. A posture attribute collector may
not know (a) from (b). It is useful to define Software Component as
the union of (a) and (b).
Examples of Software Assets:
o An application
o A patch
o The operating system kernel
o A boot loader
o Firmware that controls a disk drive
o A piece of JavaScript found in a web page the user visits
Examples of harmful software components:
o A malicious entertainment app
o A malicious executable
o A web page that contains malicious JavaScript
o A business application that shipped with a virus
Software components SHOULD be disjoint from each other. In other
words, software componennts SHOULD be so defined that a given byte of
software on an endpoint belongs to only one software component.
Different versions of the same piece of software MUST be modeled as
different components. Software versioning is not built into the
information model.
Each separately installable piece of software SHOULD be modeled as a
component. Sometimes it may be better to divide more finely: what an
installer installs MAY be modeled as several components.
A data model MAY identify a software component by parts of an ISO
SWID tag.
4.4.1. Software Instance
Each copy of a piece of software is called a software instance. The
configuration of a software instance is regarded as part of the
software instance. Configuration can strongly affect security
posture.
A data model MUST support the following relationships:
o A software instance is an "instance of" a software component.
o A software instance is "in" an endpoint.
A data model MAY use ISO SWID tags to describe software instances.
4.5. Asset Identity
TODO: Define an Asset Identity asset. Explain how it is things like
user, device, etc. where certificates, usernames, etc. come into
place since they are not really hardware or software. NOTE: Make
sure it is clear that this is not identity in the sense of what we
have been saying endpoint identity (now designation).
4.6. Relationships
TODO: Define the relationships between assets (endpoints, hardware,
software, etc.). These will depicted in the overview diagram.
5. Information Model Elements
TODO: Define specific containers, attributes, and metadata. We may
want to consider adding small diagrams showing the relationships
between each (see Lisa's notes:
https://mailarchive.ietf.org/arch/msg/sacm/
kWxlnboHAXD87cned9WavwPZy5w). This may be too much work, but, not
sure yet.
The SACM Information Model contains several elements of the The SACM Information Model contains several elements of the
architecture, including: architecture, including:
o SACM Components, which may be Collectors, Evaluators, etc. o SACM Components, which may be Collectors, Evaluators, etc.
Collectors may be internal (performed within the endpoint itself) Collectors may be internal (performed within the endpoint itself)
or external (performed outside of the endpoint, such as by a or external (performed outside of the endpoint, such as by a
hypervisor or remote sensor) hypervisor or remote sensor)
o Guidance, which tells SACM components what to do o Guidance, which tells SACM components what to do
skipping to change at page 10, line 35 skipping to change at page 15, line 15
representation of a software component, endpoint identity, user representation of a software component, endpoint identity, user
identity, address, location, and authorization constraining the identity, address, location, and authorization constraining the
endpoint endpoint
The SACM Information Model does not (in this draft) specify how long The SACM Information Model does not (in this draft) specify how long
information is retained. Historical information is modeled the same information is retained. Historical information is modeled the same
way as current information. Historical information may be way as current information. Historical information may be
represented differently in an implementation, but that difference represented differently in an implementation, but that difference
would be in data models, not in the information model. would be in data models, not in the information model.
Figure 1 introduces the endpoint attributes and their relationships. Figure 2 introduces the endpoint attributes and their relationships.
+---------+*______in>_______*+-----+ +---------+*____in>______*+-----+
|Hardware | |! !| |Hardware | |! !|
|Component| +---------+ |! !| +--------+*________________ |Component| +---------+ |! !| +--------+*______________
+---------+ |Software |in> |! !|*_____*|Location|___________ <in| +---------+ |Software |in>|! !|*____*|Location|_________ <in|
1| |Component|____|! !| in> +--------+* <in *| | 1| |Component|___|! !| in> +--------+* <in *| |
| +---------+* *|! !| +-------+ | | +---------+* *|! !| +-------+ |
| 1| |! !| |Account| | | 1| |! !| |Account| |
| *| | | +----------+ +-------+ | | *| | | +----------+ +-------+ |
| +---------+ |End- |*_____*| Identity |_________|0..1 | | +--------+ |End- |*____*| Identity |______|0..1 |
*| |Software |in> |point| acts +----------+* belongs | *| |Software|in> |point| acts +----------+* belongs |
+---------+ |Instance |____| | for> 0..1|^ to> | +--------+ |Instance|_____| | for> 0..1|^ to> |
|Hardware | +---------+* 1|! !| |acts | |Hardware| +--------+* 1|! !| |acts |
|Instance |__________________|! !| *|for |* |Instance|________________|! !| *|for |*
+---------+* in> 1|! !|_______+---------+ +-------+ +--------+* in> 1|! !|______+---------+ +-------+
|! !|1 <in *|Network |1_______*|Address| |! !|1 <in *|Network |1_______*|Address|
|! !|____ |Interface| <bound +-------+ |! !|____ |Interface| <bound +-------+
|! !|0..1| +---------+ to |! !|0..1| +---------+ to
+-----+ | *| |0..1 +-----+ | *| |0..1
|* | |___| |* | |___|
|_______| in> |_______| in>
in> in>
Figure 1: Model of an Endpoint Figure 2: Model of an Endpoint
ISSUE (CEK): we agreed to remove location and account from the model, ISSUE (CEK): we agreed to remove location and account from the model,
did we not? did we not? TODO: Remove Network Interface, Location, Address, and
Account from this diagram if we end up removing the corresponding
sections from the information model.
Figure 2 is the core of the information model. It represents the Figure 3 is the core of the information model. It represents the
information elements and their relationships. information elements and their relationships.
+-----+ +---------+ +-----+ +---------+
| AVP |____________|Endpoint | | AVP |____________|Endpoint |
+-----+1..* 1|Attribute| +-----+1..* 1|Attribute|
|Assertion| |Assertion|
+---------+ +---------+
|* +-------+ |* +-------+
| |Summary| | |Summary|
| +-------+ | +-------+
|produced-by *| |produced-by *|
|V | |V |
1| | 1| |
+--------+ +-----------+ | +--------+ +-----------+ |
| | | SACM |__________________________| | | | SACM |____________________|
|Guidance| | Component |1 <produced-by |Guidance| | Component |1 <produced-by
+--------+*____________1+-----------+ +--------+*____________1+-----------+
<produced-by <produced-by
Figure 2: Information Elements Figure 3: Information Elements
Figure 3 is a potential alternative structure for assertions. It is Figure 4 is a potential alternative structure for assertions. It is
inspired by triple stores. See http://www.w3.org/TR/2014/REC-rdf11- inspired by triple stores. See http://www.w3.org/TR/2014/REC-rdf11-
concepts-20140225/. concepts-20140225/.
+-----+______________+---------+ +---------+ +-----+______________+---------+ +---------+
| AVP |1 <subject *|assertion|________________|predicate| | AVP |1 <subject *|assertion|________________|predicate|
| |______________| |* predicate> 1+---------+ | |______________| |* predicate> 1+---------+
+-----+1 <object *+---------+ +-----+1 <object *+---------+
1^ |* 1^ |*
|_____________________| |_____________________|
<asserter <asserter
Figure 3: Information Elements, Take 2 Figure 4: Information Elements, Take 2
Note: UML 2 is specified by [UML]. Note: UML 2 is specified by [UML].
TODO: update text to match new figure: TODO: update text to match new figure:
Need to be clear in the description that ??? Need to be clear in the description that ???
For some of the relationships, will need some language and guidance For some of the relationships, will need some language and guidance
to the interfaces and relationships we expect to have happen, MUSTs to the interfaces and relationships we expect to have happen, MUSTs
and SHOULDs, as well as explaining the extensibility that other and SHOULDs, as well as explaining the extensibility that other
relationships can exist, show examples of how that can happen. relationships can exist, show examples of how that can happen.
Others that we haven't thought of yet, might be added by another RFC Others that we haven't thought of yet, might be added by another RFC
or in another way or in another way
4.1. Identifying Attributes 5.1. Identifying Attributes
TODO: Need to rename this section to align with new "designation"
term.
Identifying attributes let a consumer identify an endpoint, for two Identifying attributes let a consumer identify an endpoint, for two
purposes: purposes:
o To tell whether two endpoint attribute assertions concern the same o To tell whether two endpoint attribute assertions concern the same
endpoint (This is not simple, as Section 2.2 explains.) endpoint (This is not simple, as Section 1.1.1 explains.)
o To respond to compliance measurements, for example by reporting, o To respond to compliance measurements, for example by reporting,
remediating, and quarantining (SACM does not specify these remediating, and quarantining (SACM does not specify these
responses, but SACM exists to enable them.) responses, but SACM exists to enable them.)
Out of scope of this section: *classifying* an endpoint so as to Out of scope of this section: *classifying* an endpoint so as to
apply appropriate collection guidance to it. We don't call this apply appropriate collection guidance to it. We don't call this
"identification". "identification".
4.1.1. How Known 5.1.1. How Known
Each attribute-value pair or triple MUST be marked with how the Each attribute-value pair or triple MUST be marked with how the
provider knows. There MUST be at least one marking. The possible provider knows. There MUST be at least one marking. The possible
markings follow. markings follow.
"Self" means that the endpoint furnished the information: it is "Self" means that the endpoint furnished the information: it is
self-reported. "Self" does not (necessarily) mean that the self-reported. "Self" does not (necessarily) mean that the
provider runs on the the monitored endpoint. Self-reported provider runs on the the monitored endpoint. Self-reported
information is generally subject to the Lying Endpoint Problem. information is generally subject to the Lying Endpoint Problem.
(TODO: citation) (TODO: citation)
skipping to change at page 13, line 35 skipping to change at page 18, line 11
* The provider makes an SSH connection to the endpoint and knows * The provider makes an SSH connection to the endpoint and knows
the endpoint's public key by virtue of authenticating it. the endpoint's public key by virtue of authenticating it.
* The monitored endpoint is a virtual machine and the provider * The monitored endpoint is a virtual machine and the provider
knows by peeking into it. knows by peeking into it.
TODO: Explain security considerations and how consumers are meant to TODO: Explain security considerations and how consumers are meant to
use these markings. use these markings.
4.1.2. Whether to Include 5.1.2. Whether to Include
When publishing an endpoint attribute assertion, the provider MUST When publishing an endpoint attribute assertion, the provider MUST
publish at least all common identifying AVPs that it knows through publish at least all common identifying AVPs that it knows through
verification. If the provider knows none through verification but it verification. If the provider knows none through verification but it
knows at least one in another way, it MUST publish at least one. The knows at least one in another way, it MUST publish at least one. The
provider SHOULD publish all common identifying AVPs it knows. provider SHOULD publish all common identifying AVPs it knows.
4.1.3. IP Address 5.1.3. IP Address
4.1.3.1. Range of Values 5.1.3.1. Range of Values
MUST be an IPv4 or IPv6 address, and optionally a scope string. MUST MUST be an IPv4 or IPv6 address, and optionally a scope string. MUST
NOT be a broadcast, multicast, or loopback address. NOT be a broadcast, multicast, or loopback address.
An IPv4 address MUST conform to [RFC0791], section 3.2. An IPv4 address MUST conform to [RFC0791], section 3.2.
An IPv6 address MUST conform to [RFC3587]. SHOULD NOT be a link- An IPv6 address MUST conform to [RFC3587]. SHOULD NOT be a link-
local address. local address.
Scope string: an administratively assigned string denoting the IP Scope string: an administratively assigned string denoting the IP
skipping to change at page 14, line 32 skipping to change at page 19, line 7
easily application software can get the DHCP options from the easily application software can get the DHCP options from the
underlying OS. But this is worth exploring. underlying OS. But this is worth exploring.
(Jim): We may need to look at what happens if a scope identifier is (Jim): We may need to look at what happens if a scope identifier is
either not set or not available. I am thinking of the virtual either not set or not available. I am thinking of the virtual
network that is NATed on my machine. If those VMs reported [on network that is NATed on my machine. If those VMs reported [on
themselves] then the network configuring systems may not know about themselves] then the network configuring systems may not know about
that VM and there would not necessarily be a reasonable scope string that VM and there would not necessarily be a reasonable scope string
to report for it. to report for it.
4.1.3.2. Meaning 5.1.3.2. Meaning
Throughout the time interval of the AVP, the endpoint had the right Throughout the time interval of the AVP, the endpoint had the right
to use, or was communicating using, the specified IP address. to use, or was communicating using, the specified IP address.
4.1.3.3. Relationships 5.1.3.3. Relationships
A network profiler might know an endpoint's address and something A network profiler might know an endpoint's address and something
about the software running on the endpoint. The profiler might know about the software running on the endpoint. The profiler might know
nothing else. So data models MUST support an endpoint attribute nothing else. So data models MUST support an endpoint attribute
assertion relating the IP address to a set of software components. assertion relating the IP address to a set of software components.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o An address is "bound to" a network interface. o An address is "bound to" a network interface.
o An address is considered "bound to" an endpoint just if the o An address is considered "bound to" an endpoint just if the
address is "bound to" an interface that is "in" the endpoint. address is "bound to" an interface that is "in" the endpoint.
o An address may be "in" one or more locations. (DELETE?) o An address may be "in" one or more locations. (DELETE?)
4.1.3.4. Multiplicity 5.1.3.4. Multiplicity
An endpoint attribute assertion MAY contain one or more IP addresses. An endpoint attribute assertion MAY contain one or more IP addresses.
An IP address may be used by more than one endpoint at a time, An IP address may be used by more than one endpoint at a time,
largely because of Network Address Translation (NAT). Where largely because of Network Address Translation (NAT). Where
practical, a scope string SHOULD be included, to disambiguate. practical, a scope string SHOULD be included, to disambiguate.
In practice, an IP address can be used by only one endpoint in an IP In practice, an IP address can be used by only one endpoint in an IP
routing domain at a time. routing domain at a time.
4.1.3.5. Stability 5.1.3.5. Stability
The stability of IP address assignments varies widely. Some The stability of IP address assignments varies widely. Some
assignments are persistent, some volatile. The time interval of the assignments are persistent, some volatile. The time interval of the
AVP MUST NOT reach into the future, not even if (for example) the AVP MUST NOT reach into the future, not even if (for example) the
DHCP lease is infinite. DHCP lease is infinite.
4.1.3.6. Accuracy 5.1.3.6. Accuracy
For IP addresses that a provider knows by observation or For IP addresses that a provider knows by observation or
verification: verification:
o Network Address Translation (NAT, RFC2663) is a pitfall. o Network Address Translation (NAT, RFC2663) is a pitfall.
o The provider MUST NOT include an IP address that the provider o The provider MUST NOT include an IP address that the provider
knows to be a translated address. knows to be a translated address.
o The provider SHOULD be configurable with a set of IP address o The provider SHOULD be configurable with a set of IP address
skipping to change at page 15, line 48 skipping to change at page 20, line 23
by publishing the association between the internal and external by publishing the association between the internal and external
address-port combinations. address-port combinations.
For IP addresses that a provider knows by observation or For IP addresses that a provider knows by observation or
verification, IP address spoofing is a pitfall. Network verification, IP address spoofing is a pitfall. Network
administrators SHOULD take countermeasures. Ingress filtering administrators SHOULD take countermeasures. Ingress filtering
(RFC3704) is one. DHCP snooping is another: many Network Access (RFC3704) is one. DHCP snooping is another: many Network Access
Devices can confine endpoints to IP addresses assigned by authorized Devices can confine endpoints to IP addresses assigned by authorized
DHCP servers. DHCP servers.
4.1.3.7. Data Model Requirements 5.1.3.7. Data Model Requirements
All SACM data models MUST support this entire subsection. All SACM data models MUST support this entire subsection.
4.1.4. MAC Address 5.1.4. MAC Address
TODO TODO
4.1.5. Hardware Serial Number 5.1.5. Hardware Serial Number
4.1.5.1. Range of Values 5.1.5.1. Range of Values
MUST be a vendor ID string and a serial number string string. The MUST be a vendor ID string and a serial number string string. The
vendor ID string MAY be empty, a URI, or a vendor number. vendor ID string MAY be empty, a URI, or a vendor number.
4.1.5.2. Meaning 5.1.5.2. Meaning
Throughout the time interval of the AVP, the endpoint had a hardware Throughout the time interval of the AVP, the endpoint had a hardware
component by the indicated manufacturer and having the specified component by the indicated manufacturer and having the specified
serial number. serial number.
4.1.5.3. Multiplicity 5.1.5.3. Multiplicity
An endpoint may have any number of hardware instances, each with a An endpoint may have any number of hardware instances, each with a
different serial number. An endpoint attribute assertion may contain different serial number. An endpoint attribute assertion may contain
AVPs for any subset of the hardware instances. AVPs for any subset of the hardware instances.
Vendors generally ensure that each serial number goes to only one Vendors generally ensure that each serial number goes to only one
hardware instance. hardware instance.
4.1.5.4. Stability 5.1.5.4. Stability
Each hardware component is immutably associated with a hardware Each hardware component is immutably associated with a hardware
serial number. But hardware can be replaced or removed. As endpoint serial number. But hardware can be replaced or removed. As endpoint
attributes, hardware serial numbers are *persistent* but not attributes, hardware serial numbers are *persistent* but not
*immutable*. *immutable*.
4.1.5.5. Accuracy 5.1.5.5. Accuracy
4.1.5.6. Data Model Requirements 5.1.5.6. Data Model Requirements
All SACM data models MUST support this entire subsection. All SACM data models MUST support this entire subsection.
4.1.6. Certificate 5.1.6. Certificate
4.1.6.1. Range of values 5.1.6.1. Range of values
MUST be X.509 certificate, per [RFC5280]. MUST be X.509 certificate, per [RFC5280].
4.1.6.2. Meaning 5.1.6.2. Meaning
Throughout the time interval of the AVP, the endpoint had the private Throughout the time interval of the AVP, the endpoint had the private
key corresponding to the specified certificate. key corresponding to the specified certificate.
Throughout the time interval, the certificate was valid: it had a Throughout the time interval, the certificate was valid: it had a
valid certificate chain from a CA certificate that the asserter valid certificate chain from a CA certificate that the asserter
trusted; every certificate in the chain was time-valid; no trusted; every certificate in the chain was time-valid; no
certificate in in the chain (excluding the CA certificate) was certificate in in the chain (excluding the CA certificate) was
revoked. ISSUE (CEK): Do we want to get this PKI-ish? If so, would revoked. ISSUE (CEK): Do we want to get this PKI-ish? If so, would
we include the CA certificate as well? we include the CA certificate as well?
4.1.6.3. Multiplicity 5.1.6.3. Multiplicity
An endpoint may use, or have the right to use, one or more An endpoint may use, or have the right to use, one or more
certificates. certificates.
Some certificates may be used on more than one endpoint. Other Some certificates may be used on more than one endpoint. Other
certificates are (by intent) bound to a single endpoint. ISSUE certificates are (by intent) bound to a single endpoint. ISSUE
(CEK): Is there a standard way to distinguish the two? We could (CEK): Is there a standard way to distinguish the two? We could
perhaps provide a configurable criterion, as an information element. perhaps provide a configurable criterion, as an information element.
Should we? Should we?
4.1.6.4. Stability 5.1.6.4. Stability
Certificates are replaced, due to expiration and other reasons. By Certificates are replaced, due to expiration and other reasons. By
and large, they are not replaced often. A year is a typical and large, they are not replaced often. A year is a typical
interval. In sum, they are persistent. interval. In sum, they are persistent.
A private key is baked into hardware is almost immutable. But again, A private key is baked into hardware is almost immutable. But again,
hardware can be replaced. hardware can be replaced.
4.1.6.5. Accuracy 5.1.6.5. Accuracy
If a certificate is known by verification, the attribute is highly If a certificate is known by verification, the attribute is highly
accurate. accurate.
4.1.6.6. Data model requirements 5.1.6.6. Data model requirements
All SACM data models MUST support this entire subsection. All SACM data models MUST support this entire subsection.
4.1.7. Public Key 5.1.7. Public Key
TODO TODO
4.1.8. Username? 5.1.8. Username?
ISSUE (CEK): If a user certificate can be an identifying attribute, ISSUE (CEK): If a user certificate can be an identifying attribute,
why not a username also? At an earlier stage of our discussions, why not a username also? At an earlier stage of our discussions,
usernames were considered common identifying attributes. Did we usernames were considered common identifying attributes. Did we
decide they should not be? Or just forget them? decide they should not be? Or just forget them?
Many endpoints do not have client certificates. An authenticated Many endpoints do not have client certificates. An authenticated
username is a useful clue for identifying such an endpoint. I log in username is a useful clue for identifying such an endpoint. I log in
only to a handful of personal endpoints. I also present my username only to a handful of personal endpoints. I also present my username
and password to many multi-user servers. We would have to and password to many multi-user servers. We would have to
distinguish personal endpoints from server endpoints somehow. distinguish personal endpoints from server endpoints somehow.
4.1.9. Tool-Specific Identifier 5.1.9. Tool-Specific Identifier
TODO TODO
TODO: "Tool-specific identifier" suggests that two tools could never TODO: "Tool-specific identifier" suggests that two tools could never
agree on a tool-specific identifier. But a community may agree on an agree on a tool-specific identifier. But a community may agree on an
identifier notation, and might even create a formal standard. All identifier notation, and might even create a formal standard. All
that's important is that each of these attributes has a type and that's important is that each of these attributes has a type and
meaning *not* specified by the SACM internet drafts. "Vendor- meaning *not* specified by the SACM internet drafts. "Vendor-
specific identifier?" "Custom identifier?" specific identifier?" "Custom identifier?"
4.1.10. Identification of Endpoints where SACM Components Reside 5.1.10. Identification of Endpoints where SACM Components Reside
Every information element needs identifying attributes of its Every information element needs identifying attributes of its
producer's endpoint. (TODO: Provide normative language. SHOULD? producer's endpoint. (TODO: Provide normative language. SHOULD?
MUST?) MUST?)
Specifically, in an endpoint attribute assertion, we need identifying Specifically, in an endpoint attribute assertion, we need identifying
attributes of the asserter's endpoint. If the asserter is external, attributes of the asserter's endpoint. If the asserter is external,
the assertion will contain identifying attributes of two endpoints. the assertion will contain identifying attributes of two endpoints.
(TODO: Discuss what this information is for.) (TODO: Discuss what this information is for.)
4.1.11. Security Considerations 5.1.11. Security Considerations
Effects of misidentification Effects of misidentification
Things that can cause misidentification Things that can cause misidentification
How minimize misidentification How minimize misidentification
4.2. Software Component 5.2. Network Interface
An endpoint contains and runs software components.
Relationship:
o If an endpoint has an instance of a software component, we say
that the software component is "in" the endpoint. This is a
shorthand.
Some software components are assets. "Asset" is defined in RFC4949
[RFC4949] as "a system resource that is (a) required to be protected
by an information system's security policy, (b) intended to be
protected by a countermeasure, or (c) required for a system's
mission."
An examination of software needs to consider both (a) software assets
and (b) software that may do harm. A posture attribute collector may
not know (a) from (b). It is useful to define Software Component as
the union of (a) and (b).
Examples of Software Assets:
o An application
o A patch
o The operating system kernel
o A boot loader
o Firmware that controls a disk drive
o A piece of JavaScript found in a web page the user visits
Examples of harmful software components:
o A malicious entertainment app
o A malicious executable
o A web page that contains malicious JavaScript
o A business application that shipped with a virus
Software components SHOULD be disjoint from each other. In other
words, software componennts SHOULD be so defined that a given byte of
software on an endpoint belongs to only one software component.
Different versions of the same piece of software MUST be modeled as
different components. Software versioning is not built into the
information model.
Each separately installable piece of software SHOULD be modeled as a
component. Sometimes it may be better to divide more finely: what an
installer installs MAY be modeled as several components.
A data model MAY identify a software component by parts of an ISO
SWID tag.
4.3. Software Instance
Each copy of a piece of software is called a software instance. The
configuration of a software instance is regarded as part of the
software instance. Configuration can strongly affect security
posture.
A data model MUST support the following relationships:
o A software instance is an "instance of" a software component.
o A software instance is "in" an endpoint.
A data model MAY use ISO SWID tags to describe software instances.
4.4. Hardware Component
Hardware components may also be assets and/or harmful. For example,
a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional
layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm.
A data model MAY designate a hardware component by its manufacturer
and a part number.
4.5. Hardware Instance
A hardware instance is just an instance of a particular component.
A data model MUST support the following relationships:
o A hardware instance is an "instance of" a hardware component.
o A hardware instance is "in" an endpoint.
Hardware instances may need to be modeled because (a) an endpoint may
have multiple instances of a hardware component, (b) a hardware
instance may be compromised, whereas other instances may remain
intact.
A data model MAY designate a hardware instance by its component and a
unique serial number.
4.6. Network Interface
An endpoint generally has at least one network interface. An endpoint generally has at least one network interface.
Interfaces nest. A virtual interface can nest in a physical Interfaces nest. A virtual interface can nest in a physical
interface. interface.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o A network interface is "in" an endpoint. o A network interface is "in" an endpoint.
o A network interface is "in" another network interface; this is for o A network interface is "in" another network interface; this is for
a nested interface. CEK: And this allows representing compliance a nested interface. CEK: And this allows representing compliance
policies that are worthwhile. But is this too advanced for the policies that are worthwhile. But is this too advanced for the
initial set of SACM RFCs? initial set of SACM RFCs?
o A network interface "acts for" an identity. This occurs, for o A network interface "acts for" an identity. This occurs, for
example, when the network interface is online because of example, when the network interface is online because of
successful 802.1X. An internal collector may be aware of the successful 802.1X. An internal collector may be aware of the
identity. An external collector (such as a RADIUS server) will be identity. An external collector (such as a RADIUS server
aware of the identity. [RFC3580]) will be aware of the identity.
4.7. Address 5.3. Address
TODO: DELETE THIS SECTION. ISSUE (CEK): Do we still want to model TODO: DELETE THIS SECTION. ISSUE (CEK): Do we still want to model
layer 4 addresses? layer 4 addresses?
An address SHALL BE any of: An address SHALL BE any of:
o A layer 2 address; a data model MUST support MAC addresses, and o A layer 2 address; a data model MUST support MAC addresses, and
MAY support others MAY support others
o A layer 3 address; a data model MUST support IPv4 and IPv6 o A layer 3 address; a data model MUST support IPv4 and IPv6
skipping to change at page 22, line 24 skipping to change at page 24, line 30
A data model MUST support the following relationships: A data model MUST support the following relationships:
o An address is "bound to" a network interface. o An address is "bound to" a network interface.
o An address is considered "bound to" an endpoint just if the o An address is considered "bound to" an endpoint just if the
address is "bound to" an interface that is "in" the endpoint. address is "bound to" an interface that is "in" the endpoint.
o An address may be "in" one or more locations. o An address may be "in" one or more locations.
4.8. Identity 5.4. Identity
TODO: delete this section TODO: Delete this section?
An identity is the non-secret part of a credential. Examples are a An identity is the non-secret part of a credential. Examples are a
username, an X.500 distinguished name, and a public key. Passwords, username, an X.500 distinguished name, and a public key. Passwords,
private keys, and other secrets are not considered part of an private keys, and other secrets are not considered part of an
identity. identity.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o An endpoint may "act for" an identity. This SHALL mean that the o An endpoint may "act for" an identity. This SHALL mean that the
endpoint claims or proves that it has this identity. For example, endpoint claims or proves that it has this identity. For example,
skipping to change at page 22, line 48 skipping to change at page 25, line 5
logs into the endpoint with her AD username (alice) and password, logs into the endpoint with her AD username (alice) and password,
the endpoint "acts for" alice. An endpoint MAY "act for" more the endpoint "acts for" alice. An endpoint MAY "act for" more
than one identity, such as a machine identity and a user identity. than one identity, such as a machine identity and a user identity.
o A identity may "belong to" an account. For example, an enterprise o A identity may "belong to" an account. For example, an enterprise
may have a database that maps identities to accounts. CEK: Is may have a database that maps identities to accounts. CEK: Is
this relevant? I don't see how we'd use the notion of an account this relevant? I don't see how we'd use the notion of an account
in identifying an endpoint or in specifying compliance in identifying an endpoint or in specifying compliance
measurements to be taken. measurements to be taken.
4.9. Location 5.5. Location
TODO: Delete this section? TODO: Delete this section?
Location can be logical or physical. Location can be a clue to an Location can be logical or physical. Location can be a clue to an
endpoint's identity. endpoint's identity.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o One or more endpoints may be "in" a location o One or more endpoints may be "in" a location
o A location may be "in" one or more locations o A location may be "in" one or more locations
o A network address may be "in" a location o A network address may be "in" a location
skipping to change at page 24, line 5 skipping to change at page 26, line 5
CEK: If we do drop them, all we have left is the device and port at CEK: If we do drop them, all we have left is the device and port at
which the endpoint is linked to the network. Maybe we should regard which the endpoint is linked to the network. Maybe we should regard
that as a kind of address. that as a kind of address.
A data model MUST support switch + port number, access point, and VPN A data model MUST support switch + port number, access point, and VPN
gateway as locations. The other examples are optional. gateway as locations. The other examples are optional.
More than one of kind of location may pertain to an endpoint. More than one of kind of location may pertain to an endpoint.
Endpoint has a many-to-many relationship with Location. Endpoint has a many-to-many relationship with Location.
4.10. Endpoint 5.6. Endpoint Attribute Assertion
An endpoint is the hollow center of the model. An endpoint is an
abstract ideal. Any endpoint attribute assertion that mentions an
endpoint mentions it by specifying identifying attributes. Even if
there is one preferred endpoint identity, that is modeled as an
identity. We do not anticipate any AVP whose attribute type is
"endpoint".
4.11. Endpoint Attribute Assertion TODO: Integrate into the Section 3 as appropriate.
4.11.1. Form and Precise Meaning 5.6.1. Form and Precise Meaning
An endpoint attribute assertion has: An endpoint attribute assertion has:
o One or more attribute-value pairs (AVPs) o One or more attribute-value pairs (AVPs)
o Time intervals over which the AVPs hold o Time intervals over which the AVPs hold
o Endpoint uniquely identified? True or false o Endpoint uniquely identified? True or false
o Provenance, including: o Provenance, including:
skipping to change at page 25, line 5 skipping to change at page 26, line 42
attributes. The model does not make a rigid distinction between the attributes. The model does not make a rigid distinction between the
two uses of attributes. two uses of attributes.
Some of the attributes may be multi-valued. Some of the attributes may be multi-valued.
One of the AVPs may be a unique endpoint identifier. Not every One of the AVPs may be a unique endpoint identifier. Not every
endpoint will have one. If there is one, the SACM component that endpoint will have one. If there is one, the SACM component that
produces the Endpoint Attribute Assertion will not necessarily know produces the Endpoint Attribute Assertion will not necessarily know
what it is. what it is.
4.11.2. Asserter 5.6.2. Asserter
An Endpoint Attribute Assertion may come from an attribute collector An Endpoint Attribute Assertion may come from an attribute collector
or an evaluator. It may come from a SACM component that derives it or an evaluator. It may come from a SACM component that derives it
from out-of-band sources, such as a physical inventory system. A from out-of-band sources, such as a physical inventory system. A
SACM component may derive it from other Endpoint Attribute SACM component may derive it from other Endpoint Attribute
Assertions. Assertions.
4.11.3. Example 5.6.3. Example
For example, an attribute assertion might have these attribute-value For example, an attribute assertion might have these attribute-value
pairs: pairs:
mac-address = 01:23:45:67:89:ab mac-address = 01:23:45:67:89:ab
os = OS X os = OS X
os-version = 10.6.8 os-version = 10.6.8
This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran
OS X 10.6.8 throughout the specified time interval. A profiler might OS X 10.6.8 throughout the specified time interval. A profiler might
have provided this assertion. have provided this assertion.
4.11.4. A Use Case 5.6.4. A Use Case
For example, Endpoint Attribute Assertions should help SACM For example, Endpoint Attribute Assertions should help SACM
components to track an endpoint as it roams or stays stationary. components to track an endpoint as it roams or stays stationary.
They must track endpoints because they must track endpoints' postures They must track endpoints because they must track endpoints' postures
over time. Tracking of an endpoint can employ many clues, such as: over time. Tracking of an endpoint can employ many clues, such as:
The endpoint's MAC address The endpoint's MAC address
The authenticated identity (even if it identifies a user) The authenticated identity (even if it identifies a user)
The location of the endpoint and the user The location of the endpoint and the user
4.11.5. Event 5.6.5. Event
An event is represented as a Posture Attribute Assertion whose time An event is represented as a Posture Attribute Assertion whose time
interval has length zero. interval has length zero.
Some potential kinds of events are: Some potential kinds of events are:
o A structured syslog message [RFC5424] o A structured syslog message [RFC5424]
o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA] o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA]
o A NetFlow message [RFC3954] o A NetFlow message [RFC3954]
4.11.6. Difference between Attribute and Event 5.6.6. Difference between Attribute and Event
Author: Henk Birkholz Author: Henk Birkholz
"Attribute" and "event" are often used fairly interchangeably. A "Attribute" and "event" are often used fairly interchangeably. A
clear distinction makes the words more useful. clear distinction makes the words more useful.
An *attribute* tends not to change until something causes a change. An *attribute* tends not to change until something causes a change.
In contrast, an *event* occurs at a moment in time. In contrast, an *event* occurs at a moment in time.
For a nontechnical example, let us consider "openness" as an For a nontechnical example, let us consider "openness" as an
skipping to change at page 26, line 31 skipping to change at page 28, line 24
Similarly, "Host firewall enabled" may be modeled as a true/false Similarly, "Host firewall enabled" may be modeled as a true/false
attribute of an endpoint. Enabling or disabling the host firewall attribute of an endpoint. Enabling or disabling the host firewall
may be modeled as an event. An endpoint's crashing also may be may be modeled as an event. An endpoint's crashing also may be
modeled as an event. modeled as an event.
Although events are not attributes, we use one kind of information Although events are not attributes, we use one kind of information
element, the "Endpoint Attribute Assertion", to describe both element, the "Endpoint Attribute Assertion", to describe both
attributes and events. attributes and events.
4.12. Attribute-Value Pair 5.7. Attribute-Value Pair
TODO: Integrate into the Section 3 as appropriate.
The set of attribute types must be extensible, by other IETF The set of attribute types must be extensible, by other IETF
standards, by other standards groups, and by vendors. How to express standards, by other standards groups, and by vendors. How to express
attribute types is not defined here, but is left to data models. attribute types is not defined here, but is left to data models.
The value may be structured. For example, it may something like XML. The value may be structured. For example, it may something like XML.
The information model requires a standard attribute type (or possibly The information model requires a standard attribute type (or possibly
more than one) for each box in Figure 1: more than one) for each box in Figure 2:
o Hardware Component: the value identifies the hardware type. For o Hardware Component: the value identifies the hardware type. For
example, it may consist of the make and model number. example, it may consist of the make and model number.
o Hardware Instance: the value, together with the Hardware Component o Hardware Instance: the value, together with the Hardware Component
value, uniquely identifies the hardware instance. For example, it value, uniquely identifies the hardware instance. For example, it
may be a manufacturer-assigned serial number. This notion might may be a manufacturer-assigned serial number. This notion might
not apply to all virtual hardware components. not apply to all virtual hardware components.
o Software Component: the value identifies a unit of software. Each o Software Component: the value identifies a unit of software. Each
skipping to change at page 27, line 28 skipping to change at page 29, line 22
o Network Interface: TBD o Network Interface: TBD
o User: [cek: Do we want this? If one user uses different o User: [cek: Do we want this? If one user uses different
credentials at different times, do we think SACM components will credentials at different times, do we think SACM components will
need know that it's the same user?] need know that it's the same user?]
o Address: The value is an IP, MAC, or other network address, o Address: The value is an IP, MAC, or other network address,
possibly qualified with its scope. possibly qualified with its scope.
4.12.1. Unique Endpoint Identifier 5.7.1. Unique Endpoint Identifier
An organization should try to uniquely identify and label an An organization should try to uniquely identify and label an
endpoint, whether the endpoint is enrolled or is discovered in the endpoint, whether the endpoint is enrolled or is discovered in the
operational environment. The identifier should be assigned by or operational environment. The identifier should be assigned by or
used in the enrollment process. used in the enrollment process.
Here "unique" means one-to-one. In practice, uniqueness is not Here "unique" means one-to-one. In practice, uniqueness is not
always attainable. Even if an endpoint has a unique identifier, an always attainable. Even if an endpoint has a unique identifier, an
attribute collector may not always know it. attribute collector may not always know it.
If the attribute type of an AVP is "endpoint", the value is a unique If the attribute type of an AVP is "endpoint", the value is a unique
identifier of the endpoint. identifier of the endpoint.
4.12.2. Posture Attribute 5.7.2. Posture Attribute
Some AVPs will be posture attributes. Some AVPs will be posture attributes.
See the definition in the SACM Terminology for Security Assessment See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
Some potential kinds of posture attributes are: Some potential kinds of posture attributes are:
o A NEA posture attribute (PA) [RFC5209] o A NEA posture attribute (PA) [RFC5209]
o A YANG model [RFC6020] o A YANG model [RFC6020]
o An IF-MAP device-characteristics metadata item o An IF-MAP device-characteristics metadata item
[TNC-IF-MAP-NETSEC-METADATA] [TNC-IF-MAP-NETSEC-METADATA]
4.13. Evaluation Result 5.8. Evaluation Result
Evaluation Results (see [I-D.ietf-sacm-terminology]) are modeled as Evaluation Results (see [I-D.ietf-sacm-terminology]) are modeled as
Endpoint Attribute Assertions. Endpoint Attribute Assertions.
An Evaluation Result derives from one or more other Endpoint An Evaluation Result derives from one or more other Endpoint
Attribute Assertions. Attribute Assertions.
An example is: a NEA access recommendation [RFC5793] An example is: a NEA access recommendation [RFC5793]
An evaluator may be able to evaluate better if history is available. An evaluator may be able to evaluate better if history is available.
This is a use case for retaining Endpoint Attribute Assertions for a This is a use case for retaining Endpoint Attribute Assertions for a
time. time.
An Evaluation Result may be retained longer than the Endpoint An Evaluation Result may be retained longer than the Endpoint
Attribute Assertions from which it derives. (Figure 1 does not show Attribute Assertions from which it derives. (Figure 2 does not show
this.) In the limiting case, Endpoint Attribute Assertions are not this.) In the limiting case, Endpoint Attribute Assertions are not
retained. When as an Endpoint Attribute Assertion arrives, an retained. When as an Endpoint Attribute Assertion arrives, an
evaluator produces an Evaluation Result. These mechanics are out of evaluator produces an Evaluation Result. These mechanics are out of
the scope of the Information Model. the scope of the Information Model.
4.14. Report 5.9. Report
ISSUE (CEK): Should we take modeling of reports out of scope? It is ISSUE (CEK): Should we take modeling of reports out of scope? It is
clear that reports are needed. But is a *standard* for reports clear that reports are needed. But is a *standard* for reports
needed, and does it deserve our priority? needed, and does it deserve our priority? Endpoint ID Design Team:
Yes, it should be removed.
TODO: This should be removed if the working group decides that
reports are out of scope for SACM.
An Endpoint Attribute Assertion concerns a single endpoint. An Endpoint Attribute Assertion concerns a single endpoint.
Assertions about a set of endpoints are also needed -- for example, Assertions about a set of endpoints are also needed -- for example,
for trend analysis and for reports read by humans. These assertions for trend analysis and for reports read by humans. These assertions
are termed "reports". SACM components will consume Endpoint are termed "reports". SACM components will consume Endpoint
Attribute Assertions and generate reports. Attribute Assertions and generate reports.
A report contains its provenance, with the same form and meaning as A report contains its provenance, with the same form and meaning as
the provenance of an Endpoint Attribute Assertion. the provenance of an Endpoint Attribute Assertion.
skipping to change at page 29, line 4 skipping to change at page 30, line 51
A report contains its provenance, with the same form and meaning as A report contains its provenance, with the same form and meaning as
the provenance of an Endpoint Attribute Assertion. the provenance of an Endpoint Attribute Assertion.
A Report summarizes: A Report summarizes:
o Endpoint Attribute Assertions, which may include Evaluation o Endpoint Attribute Assertions, which may include Evaluation
Results Results
o Other Reports o Other Reports
A Report may routine or ad hoc. A Report may routine or ad hoc.
Some reports may be machine readable. Machine readable reports may Some reports may be machine readable. Machine readable reports may
be consumable by SACM components and by automatic response systems be consumable by SACM components and by automatic response systems
(not specified by SACM). (not specified by SACM).
4.15. SACM Component 5.10. SACM Component
Although SACM components are mainly covered by the SACM architecture, Although SACM components are mainly covered by the SACM architecture,
we have some remarks. TODO: Move them? we have some remarks. TODO: Move them to the architecture document?
ISSUE (CEK): Why do we need information elements that model SACM ISSUE (CEK): Why do we need information elements that model SACM
compoments? compoments?
4.15.1. External Attribute Collector 5.10.1. External Attribute Collector
An external collector is a collector that observes endpoints from An external collector is a collector that observes endpoints from
outside. [kkw-many of these [collectors] are actually configured and outside. [kkw-many of these [collectors] are actually configured and
operated to manage assets for reasons other than posture assessments. operated to manage assets for reasons other than posture assessments.
it is critical to bring them into this, so i like it...but does it it is critical to bring them into this, so i like it...but does it
matter if the [collector] isn't intended to support posture matter if the [collector] isn't intended to support posture
assessment, but happens to have information that can be used by assessment, but happens to have information that can be used by
posture assessment collection consumers? do we lump them together posture assessment collection consumers? do we lump them together
with collectors that are intended to support posture assessment but with collectors that are intended to support posture assessment but
run external to the endpoint?] [jmf: ditto. The exampled below are run external to the endpoint?] [jmf: ditto. The exampled below are
skipping to change at page 29, line 41 skipping to change at page 31, line 40
[cek-to kkw's comment, I think the purpose here is to capture their [cek-to kkw's comment, I think the purpose here is to capture their
contribution to continuous monitoring. I don't see the need to contribution to continuous monitoring. I don't see the need to
separate things whose primary job is monitoring from things whose separate things whose primary job is monitoring from things whose
primary job is something else. Is there a need?] primary job is something else. Is there a need?]
[cek-to jmf's comment, that is what they are examples of; is a text [cek-to jmf's comment, that is what they are examples of; is a text
change needed?] change needed?]
Examples: Examples:
o A RADIUS server whereby an endpoint has logged onto the network o A RADIUS server [RFC3580] whereby an endpoint has logged onto the
network
o A network profiling system, which discovers and classifies network o A network profiling system, which discovers and classifies network
nodes nodes
o A Network Intrusion Detection System (NIDS) sensor o A Network Intrusion Detection System (NIDS) sensor
o A vulnerability scanner o A vulnerability scanner
o A hypervisor that peeks into the endpoint, the endpoint being a o A hypervisor that peeks into the endpoint, the endpoint being a
virtual machine virtual machine
o A management system that configures and installs software on the o A management system that configures and installs software on the
endpoint endpoint
4.15.2. Evaluator 5.10.2. Evaluator
An evaluator can consume endpoint attribute assertions, previous An evaluator can consume endpoint attribute assertions, previous
evaluations of posture attributes, or previous reports of evaluation evaluations of posture attributes, or previous reports of evaluation
results. [kkw-i don't think this conflicts with the definition in the results. [kkw-i don't think this conflicts with the definition in the
terminology doc re: that evaluation tasks evaluate posture terminology doc re: that evaluation tasks evaluate posture
attributes.] attributes.]
[cek-I like the change. I think it *does* require a change in the [cek-I like the change. I think it *does* require a change in the
terminology doc, though.] terminology doc, though.]
Example: a NEA posture validator [RFC5209] Example: a NEA posture validator [RFC5209]
[jmf- a NEA posture validator is not an example of this definition. [jmf- a NEA posture validator is not an example of this definition.
A NEA posture assessment is, maybe?] A NEA posture assessment is, maybe?]
[cek-Why isn't a NEA posture validator an example?] [cek-Why isn't a NEA posture validator an example?]
4.15.3. Report Generator 5.10.3. Report Generator
A report generator makes reports based on: A report generator makes reports based on:
o Endpoint Attribute Assertions, including Evaluation Results o Endpoint Attribute Assertions, including Evaluation Results
o Other Reports (a weekly report may be created from daily reports) o Other Reports (a weekly report may be created from daily reports)
It may summarize data continually, as the data arrives. It also may It may summarize data continually, as the data arrives. It also may
summarize data in response to an ad hoc query. summarize data in response to an ad hoc query.
4.16. Organization? TODO: This should be removed if the working group decides that
reports are out of scope for SACM.
5.11. Organization?
[kkw-from a reporting standpoint there needs to be some concept like [kkw-from a reporting standpoint there needs to be some concept like
organization or system. without this, there is no way to produce organization or system. without this, there is no way to produce
result reports that can be acted upon to provide the insight or result reports that can be acted upon to provide the insight or
accountability that almost all continuous monitoring instances are accountability that almost all continuous monitoring instances are
trying to achieve. from a scoring or grading standpoint, an endpoint trying to achieve. from a scoring or grading standpoint, an endpoint
needs to be associated with exactly one organization or system. it needs to be associated with exactly one organization or system. it
can have a many to many relationship with other types of results can have a many to many relationship with other types of results
reporting "bins". is this important to include here? we had reporting "bins". is this important to include here? we had
organization as a core asset type for this reason, so i think it is a organization as a core asset type for this reason, so i think it is a
key information element. but i also know that i do not want to define key information element. but i also know that i do not want to define
all the different reporting types, so i am unsure.] all the different reporting types, so i am unsure.]
[cek-I had not thought of this at all. Would it make sense to treat [cek-I had not thought of this at all. Would it make sense to treat
the organization and the bins as part of the guidance for creating the organization and the bins as part of the guidance for creating
reports? Maybe not. We should discuss.] reports? Maybe not. We should discuss.]
4.17. Guidance 5.12. Guidance
[jmf- the guidance sections need more detail. . .] [jmf- the guidance sections need more detail. . .]
[cek - What is missing? We would welcome a critique or text.] [cek - What is missing? We would welcome a critique or text.]
Guidance is generally configurable by human administrators. Guidance is generally configurable by human administrators.
4.17.1. Internal Collection Guidance 5.12.1. Internal Collection Guidance
An internal collector may need guidance to govern what it collects An internal collector may need guidance to govern what it collects
and when. and when.
4.17.2. External Collection Guidance 5.12.2. External Collection Guidance
An external collector may need guidance to govern what it collects An external collector may need guidance to govern what it collects
and when. and when.
4.17.3. Evaluation Guidance 5.12.3. Evaluation Guidance
An evaluator typically needs Evaluation Guidance to govern what it An evaluator typically needs Evaluation Guidance to govern what it
considers to be a good or bad security posture. considers to be a good or bad security posture.
4.17.4. Retention Guidance 5.12.4. Retention Guidance
A SACM deployment may retain posture attributes, events, or A SACM deployment may retain posture attributes, events, or
evaluation results for some time. Retention supports ad hoc evaluation results for some time. Retention supports ad hoc
reporting and other use cases. reporting and other use cases.
If information is retained, retention guidance controls what is If information is retained, retention guidance controls what is
retained and for how long. retained and for how long.
If two or more pieces of retention guidance apply to a piece of If two or more pieces of retention guidance apply to a piece of
information, the guidance calling for the longest retention should information, the guidance calling for the longest retention should
take precedence. take precedence.
4.17.5. Reporting Guidance 5.12.5. Reporting Guidance
A Report Generator typically needs Reporting Guidance to govern the A Report Generator typically needs Reporting Guidance to govern the
reports it generates. reports it generates. TODO: This should be removed if the working
group decides that reports are out of scope for SACM.
4.18. Provenance of Information
Each Endpoint Attribute Assertion and Report needs to be labeled with
its provenance.
4.19. Endpoint 5.13. Endpoint
See the definition in the SACM Terminology for Security Assessment See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
In the model, an endpoint can be part of another endpoint. This In the model, an endpoint can be part of another endpoint. This
covers cases where multiple physical endpoints act as one endpoint. covers cases where multiple physical endpoints act as one endpoint.
The constituent endpoints may not be distinguishable by external The constituent endpoints may not be distinguishable by external
observation of network behavior. observation of network behavior.
For example, a hosting center may maintain a redundant set For example, a hosting center may maintain a redundant set
skipping to change at page 32, line 32 skipping to change at page 34, line 27
redundancy and load distribution on network paths to WAN gateways. redundancy and load distribution on network paths to WAN gateways.
Multi-chassis link aggregation groups make the chassis appear as one Multi-chassis link aggregation groups make the chassis appear as one
endpoint. Traditional security controls must be applied either to endpoint. Traditional security controls must be applied either to
physical endpoints or the redundancy groups they compose (and physical endpoints or the redundancy groups they compose (and
occasionally both). Loss of redundancy is difficult to detect or occasionally both). Loss of redundancy is difficult to detect or
mitigate without specific posture information about the current state mitigate without specific posture information about the current state
of redundancy groups. Even if a physical endpoint (e.g. router) that of redundancy groups. Even if a physical endpoint (e.g. router) that
is part of a redundancy group is replaced, the redundancy group can is part of a redundancy group is replaced, the redundancy group can
remain the same. remain the same.
4.19.1. Endpoint Identity 5.13.1. Endpoint Identity
An endpoint identity provides both identification and authentication An endpoint identity provides both identification and authentication
of the endpoint. For example, an identity may be an X.509 of the endpoint. For example, an identity may be an X.509
certificate [RFC5280] and corresponding private key. [jmf- this certificate [RFC5280] and corresponding private key. [jmf- this
example should be formatted like the other examples in this section] example should be formatted like the other examples in this section]
Not all kinds of identities are guaranteed to be unique. Not all kinds of identities are guaranteed to be unique.
4.19.2. Software Component 5.13.2. Software Component
An endpoint contains and runs software components. An endpoint contains and runs software components.
Some of the software components are assets. "Asset" is defined in Some of the software components are assets. "Asset" is defined in
RFC4949 [RFC4949] as "a system resource that is (a) required to be RFC4949 [RFC4949] as "a system resource that is (a) required to be
protected by an information system's security policy, (b) intended to protected by an information system's security policy, (b) intended to
be protected by a countermeasure, or (c) required for a system's be protected by a countermeasure, or (c) required for a system's
mission." mission."
An examination of software needs to consider both (a) software assets An examination of software needs to consider both (a) software assets
skipping to change at page 33, line 31 skipping to change at page 35, line 27
Examples of harmful software components: Examples of harmful software components:
o A malicious entertainment app o A malicious entertainment app
o A malicious executable o A malicious executable
o A web page that contains malicious JavaScript o A web page that contains malicious JavaScript
o A business application that shipped with a virus o A business application that shipped with a virus
4.19.2.1. Unique Software Identifier 5.13.2.1. Unique Software Identifier
Organizations need to be able to uniquely identify and label software Organizations need to be able to uniquely identify and label software
installed or run on an endpoint. Specifically, they need to know the installed or run on an endpoint. Specifically, they need to know the
name, publisher, unique ID, and version; and any related patches. In name, publisher, unique ID, and version; and any related patches. In
some cases the software's identity might be known a priori by the some cases the software's identity might be known a priori by the
organization; in other cases, a software identity might be first organization; in other cases, a software identity might be first
detected by an organization when the software is first inventoried in detected by an organization when the software is first inventoried in
an operational environment. Due to this, it is important that an an operational environment. Due to this, it is important that an
organization have a stable and consistent means to identify software organization have a stable and consistent means to identify software
found during collection. found during collection.
A piece of software may have a unique identifier, such as a SWID tag A piece of software may have a unique identifier, such as a SWID tag
(ISO/IEC 19770). (ISO/IEC 19770).
4.20. User 5.14. User
4.20.1. User Identity
5.14.1. User Identity
An endpoint is often - but not always - associated with one or more An endpoint is often - but not always - associated with one or more
users. users.
A user's identity provides both identification and authentication of A user's identity provides both identification and authentication of
the user. @@@ Eh? the user. @@@ Eh?
5. SACM Usage Scenario Example 6. SACM Usage Scenario Example
TODO: this section needs to refer out to wherever the operations / TODO: this section needs to refer out to wherever the operations /
generalized workflow content ends up generalized workflow content ends up
TODO: revise to eliminate graph references TODO: revise to eliminate graph references
This section illustrates the proposed SACM Information Model as This section illustrates the proposed SACM Information Model as
applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations
[I-D.ietf-sacm-use-cases]. The following subsections describe the [RFC7632]. The following subsections describe the elements
elements (components and elements), graph model, and operations (components and elements), graph model, and operations (sample
(sample workflow) required to support the Detection of Posture workflow) required to support the Detection of Posture Deviations
Deviations scenario. scenario.
The Detection of Posture Deviations scenario involves multiple The Detection of Posture Deviations scenario involves multiple
elements interacting to accomplish the goals of the scenario. elements interacting to accomplish the goals of the scenario.
Figure 1 illustrates those elements along with their major Figure 2 illustrates those elements along with their major
communication paths. communication paths.
5.1. Graph Model for Detection of Posture Deviation 6.1. Graph Model for Detection of Posture Deviation
The following subsections contain examples of identifiers and The following subsections contain examples of identifiers and
metadata which would enable detection of posture deviation. These metadata which would enable detection of posture deviation. These
lists are by no means exhaustive - many other types of metadata would lists are by no means exhaustive - many other types of metadata would
be enumerated in a data model that fully addressed this usage be enumerated in a data model that fully addressed this usage
scenario. scenario.
5.1.1. Components 6.1.1. Components
The proposed SACM Information Model contains three components, as The proposed SACM Information Model contains three components, as
defined in the SACM Architecture [I-D.ietf-sacm-architecture]: defined in the SACM Architecture [I-D.ietf-sacm-architecture]:
Posture Attribute Information Provider, Posture Attribute Information Posture Attribute Information Provider, Posture Attribute Information
Consumer, and Control Plane. Consumer, and Control Plane.
In this example, the components are instantiated as follows: In this example, the components are instantiated as follows:
o The Posture Attribute Information Provider is an endpoint security o The Posture Attribute Information Provider is an endpoint security
service which monitors the compliance state of the endpoint and service which monitors the compliance state of the endpoint and
skipping to change at page 35, line 15 skipping to change at page 37, line 7
o The Posture Attribute Information Consumer is an analytics engine o The Posture Attribute Information Consumer is an analytics engine
which absorbs information from around the network and generates a which absorbs information from around the network and generates a
"heat map" of which areas in the network are seeing unusually high "heat map" of which areas in the network are seeing unusually high
rates of posture deviations. rates of posture deviations.
o The Control Plane is a security automation broker which receives o The Control Plane is a security automation broker which receives
subscription requests from the analytics engine and authorizes subscription requests from the analytics engine and authorizes
access to appropriate information from the endpoint security access to appropriate information from the endpoint security
service. service.
5.1.2. Identifiers 6.1.2. Identifiers
To represent the elements listed above, the set of identifiers might To represent the elements listed above, the set of identifiers might
include (but is not limited to): include (but is not limited to):
o Identity - a device itself, or a user operating a device, o Identity - a device itself, or a user operating a device,
categorized by type of identity (e.g. username or X.509 categorized by type of identity (e.g. username or X.509
certificate [RFC5280]) certificate [RFC5280])
o Software asset o Software asset
skipping to change at page 35, line 40 skipping to change at page 37, line 32
[RFC5201], etc.) [RFC5201], etc.)
o Task - categorized by type of task (e.g. internal collector, o Task - categorized by type of task (e.g. internal collector,
external collector, evaluator, or reporting task) external collector, evaluator, or reporting task)
o Result - categorized by type of result (e.g. evaluation result or o Result - categorized by type of result (e.g. evaluation result or
report) report)
o Guidance o Guidance
5.1.3. Metadata 6.1.3. Metadata
To characterize the elements listed above, the set of metadata types To characterize the elements listed above, the set of metadata types
might include (but is not limited to): might include (but is not limited to):
o Authorization metadata attached to an identity identifier, or to a o Authorization metadata attached to an identity identifier, or to a
link between a network session identifier and an identity link between a network session identifier and an identity
identifier, or to a link between a network session identifier and identifier, or to a link between a network session identifier and
an address identifier. an address identifier.
o Location metadata attached to a link between a network session o Location metadata attached to a link between a network session
skipping to change at page 36, line 21 skipping to change at page 38, line 14
attached to the identity identifier of the endpoint, to notify attached to the identity identifier of the endpoint, to notify
consumers of the change in endpoint state. consumers of the change in endpoint state.
o Posture attribute metadata attached to an identity identifier of o Posture attribute metadata attached to an identity identifier of
an endpoint. For example, when required security software is not an endpoint. For example, when required security software is not
running, an internal collector associated with an endpoint running, an internal collector associated with an endpoint
security service might publish posture attribute metadata attached security service might publish posture attribute metadata attached
to the identity identifier of the endpoint, to notify consumers of to the identity identifier of the endpoint, to notify consumers of
the current state of the endpoint. the current state of the endpoint.
5.1.4. Relationships between Identifiers and Metadata 6.1.4. Relationships between Identifiers and Metadata
Interaction between multiple sets of identifiers and metadata lead to Interaction between multiple sets of identifiers and metadata lead to
some fairly common patterns, or "constellations", of metadata. For some fairly common patterns, or "constellations", of metadata. For
example, an authenticated-session metadata constellation might example, an authenticated-session metadata constellation might
include a central network session with authorizations and location include a central network session with authorizations and location
attached, and links to a user identity, an endpoint identity, a MAC attached, and links to a user identity, an endpoint identity, a MAC
address, an IP address, and the identity of the policy server that address, an IP address, and the identity of the policy server that
authorized the session, for the duration of the network session. authorized the session, for the duration of the network session.
These constellations may be independent of each other, or one These constellations may be independent of each other, or one
skipping to change at page 36, line 43 skipping to change at page 38, line 36
authenticated-session metadata constellation may be created when a authenticated-session metadata constellation may be created when a
user connects an endpoint to the network; separately, an endpoint- user connects an endpoint to the network; separately, an endpoint-
posture metadata constellation may be created when an endpoint posture metadata constellation may be created when an endpoint
security system and other collectors gather and publish posture security system and other collectors gather and publish posture
information related to an endpoint. These two constellations are not information related to an endpoint. These two constellations are not
necessarily connected to each other, but may be joined if the necessarily connected to each other, but may be joined if the
component publishing the authenticated-session metadata constellation component publishing the authenticated-session metadata constellation
is able to link the network session identifier to the identity is able to link the network session identifier to the identity
identifier of the endpoint. identifier of the endpoint.
5.2. Workflow 6.2. Workflow
The workflow for exchange of information supporting detection of The workflow for exchange of information supporting detection of
posture deviation, using a standard publish/subscribe/query transport posture deviation, using a standard publish/subscribe/query transport
model such as available with IF-MAP [TNC-IF-MAP-SOAP-Binding] or model such as available with IF-MAP [TNC-IF-MAP-SOAP-Binding] or
XMPP-Grid [I-D.salowey-sacm-xmpp-grid], is as follows: XMPP-Grid [I-D.salowey-sacm-xmpp-grid], is as follows:
1. The analytics engine (Posture Assessment Information Consumer) 1. The analytics engine (Posture Assessment Information Consumer)
establishes connectivity and authorization with the transport establishes connectivity and authorization with the transport
fabric, and subscribes to updates on posture deviations. fabric, and subscribes to updates on posture deviations.
skipping to change at page 37, line 23 skipping to change at page 39, line 20
posture deviation, and publishes information on the posture posture deviation, and publishes information on the posture
deviation. deviation.
5. The transport fabric notifies the analytics engine, based on its 5. The transport fabric notifies the analytics engine, based on its
subscription of the new posture deviation information. subscription of the new posture deviation information.
Other components, such as access control policy servers or Other components, such as access control policy servers or
remediation systems, may also consume the posture deviation remediation systems, may also consume the posture deviation
information provided by the endpoint security service. information provided by the endpoint security service.
6. Acknowledgements 7. Acknowledgements
Many of the specifications in this document have been developed in a Many of the specifications in this document have been developed in a
public-private partnership with vendors and end-users. The hard work public-private partnership with vendors and end-users. The hard work
of the SCAP community is appreciated in advancing these efforts to of the SCAP community is appreciated in advancing these efforts to
their current level of adoption. their current level of adoption.
Over the course of developing the initial draft, Brant Cheikes, Matt Over the course of developing the initial draft, Brant Cheikes, Matt
Hansbury, Daniel Haynes, Scott Pope, Charles Schmidt, and Steve Hansbury, Daniel Haynes, Scott Pope, Charles Schmidt, and Steve
Venema have contributed text to many sections of this document. Venema have contributed text to many sections of this document.
6.1. Contributors 7.1. Contributors
The RFC guidelines no longer allow RFCs to be published with a large The RFC guidelines no longer allow RFCs to be published with a large
number of authors. Some additional authors contributed to specific number of authors. Some additional authors contributed to specific
sections of this document; their names are listed in the individual sections of this document; their names are listed in the individual
section headings as well as alphabetically listed with their section headings as well as alphabetically listed with their
affiliations below. affiliations below.
+---------------+----------------+---------------------------------+ +---------------+----------------+---------------------------------+
| Name | Affiliation | Contact | | Name | Affiliation | Contact |
+---------------+----------------+---------------------------------+ +---------------+----------------+---------------------------------+
| Henk Birkholz | Fraunhofer SIT | henk.birkholz@sit.fraunhofer.de | | Henk Birkholz | Fraunhofer SIT | henk.birkholz@sit.fraunhofer.de |
+---------------+----------------+---------------------------------+ +---------------+----------------+---------------------------------+
7. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 9. Operational Considerations
TODO: Need to include various operational considerations here.
Proposed sections include timestamp accuracy and which attributes
attributes designate an endpoint.
10. Privacy Considerations
TODO: Need to include various privacy considerations here.
11. Security Considerations
Posture Assessments need to be performed in a safe and secure manner. Posture Assessments need to be performed in a safe and secure manner.
In that regard, there are multiple aspects of security that apply to In that regard, there are multiple aspects of security that apply to
the communications between components as well as the capabilities the communications between components as well as the capabilities
themselves. Due to time constraints, this information model only themselves. Due to time constraints, this information model only
contains an initial listing of items that need to be considered with contains an initial listing of items that need to be considered with
respect to security. This list is not exhaustive, and will need to respect to security. This list is not exhaustive, and will need to
be augmented as the model continues to be developed/refined. be augmented as the model continues to be developed/refined.
Initial list of security considerations include: Initial list of security considerations include:
skipping to change at page 38, line 40 skipping to change at page 41, line 5
Restricted Access: Access to the information collected, evaluated, Restricted Access: Access to the information collected, evaluated,
reported, and stored should only be viewable/consumable to reported, and stored should only be viewable/consumable to
authenticated and authorized entities. authenticated and authorized entities.
The TNC IF-MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] and TNC IF- The TNC IF-MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] and TNC IF-
MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA] MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA]
document security considerations for sharing information via security document security considerations for sharing information via security
automation. Most, and possibly all, of these considerations also automation. Most, and possibly all, of these considerations also
apply to information shared via this proposed information model. apply to information shared via this proposed information model.
9. References 12. References
9.1. Normative References 12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
1981. 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003. Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <http://www.rfc-editor.org/info/rfc3587>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
9.2. Informative References 12.2. Informative References
[CCE] The National Institute of Standards and Technology, [CCE] The National Institute of Standards and Technology,
"Common Configuration Enumeration", 2014, "Common Configuration Enumeration", 2014,
<http://nvd.nist.gov/CCE/>. <http://nvd.nist.gov/CCE/>.
[CCI] United States Department of Defense Defense Information [CCI] United States Department of Defense Defense Information
Systems Agency, "Control Correlation Identifier", 2014, Systems Agency, "Control Correlation Identifier", 2014,
<http://iase.disa.mil/cci/>. <http://iase.disa.mil/cci/>.
[CPE-WEBSITE] [CPE-WEBSITE]
skipping to change at page 39, line 45 skipping to change at page 42, line 15
[I-D.ietf-sacm-requirements] [I-D.ietf-sacm-requirements]
Cam-Winget, N. and L. Lorenzin, "Secure Automation and Cam-Winget, N. and L. Lorenzin, "Secure Automation and
Continuous Monitoring (SACM) Requirements", draft-ietf- Continuous Monitoring (SACM) Requirements", draft-ietf-
sacm-requirements-01 (work in progress), October 2014. sacm-requirements-01 (work in progress), October 2014.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., and N. Cam- Waltermire, D., Montville, A., Harrington, D., and N. Cam-
Winget, "Terminology for Security Assessment", draft-ietf- Winget, "Terminology for Security Assessment", draft-ietf-
sacm-terminology-05 (work in progress), August 2014. sacm-terminology-05 (work in progress), August 2014.
[I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-10 (work in progress), July 2015.
[I-D.salowey-sacm-xmpp-grid] [I-D.salowey-sacm-xmpp-grid]
Salowey, J., Lorenzin, L., Kahn, C., Pope, S., Appala, S., Salowey, J., Lorenzin, L., Kahn, C., Pope, S., Appala, S.,
Woland, A., and N. Cam-Winget, "XMPP Protocol Extensions Woland, A., and N. Cam-Winget, "XMPP Protocol Extensions
for Use in SACM Information Transport", draft-salowey- for Use in SACM Information Transport", draft-salowey-
sacm-xmpp-grid-00 (work in progress), July 2014. sacm-xmpp-grid-00 (work in progress), July 2014.
[IM-LIAISON-STATEMENT-NIST] [IM-LIAISON-STATEMENT-NIST]
Montville, A., "Liaison Statement: Call for Contributions Montville, A., "Liaison Statement: Call for Contributions
for the SACM Information Model to NIST", May 2014, for the SACM Information Model to NIST", May 2014,
<http://datatracker.ietf.org/liaison/1329/>. <http://datatracker.ietf.org/liaison/1329/>.
skipping to change at page 41, line 48 skipping to change at page 44, line 8
draft_nistir_7848.pdf>. draft_nistir_7848.pdf>.
[OVAL-LANGUAGE] [OVAL-LANGUAGE]
Baker, J., Hansbury, M., and D. Haynes, "The OVAL Language Baker, J., Hansbury, M., and D. Haynes, "The OVAL Language
Specification version 5.10.1", January 2012, Specification version 5.10.1", January 2012,
<https://oval.mitre.org/language/version5.10.1/>. <https://oval.mitre.org/language/version5.10.1/>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. DOI 10.17487/RFC3411, December 2002,
<http://www.rfc-editor.org/info/rfc3411>.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
Simple Network Management Protocol (SNMP)", STD 62, RFC for the Simple Network Management Protocol (SNMP)", STD
3416, December 2002. 62, RFC 3416, DOI 10.17487/RFC3416, December 2002,
<http://www.rfc-editor.org/info/rfc3416>.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
Simple Network Management Protocol (SNMP)", STD 62, RFC the Simple Network Management Protocol (SNMP)", STD 62,
3418, December 2002. RFC 3418, DOI 10.17487/RFC3418, December 2002,
<http://www.rfc-editor.org/info/rfc3418>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January Information Models and Data Models", RFC 3444, DOI
2003. 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, DOI 10.17487/
RFC3580, September 2003,
<http://www.rfc-editor.org/info/rfc3580>.
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
9", RFC 3954, October 2004. Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
<http://www.rfc-editor.org/info/rfc3954>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
4949, August 2007. 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
"Host Identity Protocol", RFC 5201, April 2008. Henderson, "Host Identity Protocol", RFC 5201, DOI
10.17487/RFC5201, April 2008,
<http://www.rfc-editor.org/info/rfc5201>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008. Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<http://www.rfc-editor.org/info/rfc5209>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI
10.17487/RFC5424, March 2009,
<http://www.rfc-editor.org/info/rfc5424>.
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
(PA) Protocol Compatible with Trusted Network Connect (PA) Protocol Compatible with Trusted Network Connect
(TNC)", RFC 5792, March 2010. (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010,
<http://www.rfc-editor.org/info/rfc5792>.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", RFC 5793, March 2010. Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793,
March 2010, <http://www.rfc-editor.org/info/rfc5793>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Bierman, "Network Configuration Protocol (NETCONF)", RFC and A. Bierman, Ed., "Network Configuration Protocol
6241, June 2011. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", RFC 6876, February Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI
2013. 10.17487/RFC6876, February 2013,
<http://www.rfc-editor.org/info/rfc6876>.
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
(PT) Protocol for Extensible Authentication Protocol (EAP) (PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods", RFC 7171, May 2014. Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014,
<http://www.rfc-editor.org/info/rfc7171>.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632, DOI
10.17487/RFC7632, September 2015,
<http://www.rfc-editor.org/info/rfc7632>.
[SP800-117] [SP800-117]
Quinn, S., Scarfone, K., and D. Waltermire, "Guide to Quinn, S., Scarfone, K., and D. Waltermire, "Guide to
Adopting and Using the Security Content Automation Adopting and Using the Security Content Automation
Protocol (SCAP) Version 1.2", SP 800-117, January 2012, Protocol (SCAP) Version 1.2", SP 800-117, January 2012,
<http://csrc.nist.gov/publications/drafts/800-117-R1/ <http://csrc.nist.gov/publications/drafts/800-117-R1/
Draft-SP800-117-r1.pdf>. Draft-SP800-117-r1.pdf>.
[SP800-126] [SP800-126]
Waltermire, D., Quinn, S., Scarfone, K., and A. Waltermire, D., Quinn, S., Scarfone, K., and A.
skipping to change at page 44, line 31 skipping to change at page 47, line 19
<http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225>. <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225>.
[W3C.REC-soap12-part1-20070427] [W3C.REC-soap12-part1-20070427]
Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J.,
Nielsen, H., Karmarkar, A., and Y. Lafon, "SOAP Version Nielsen, H., Karmarkar, A., and Y. Lafon, "SOAP Version
1.2 Part 1: Messaging Framework (Second Edition)", World 1.2 Part 1: Messaging Framework (Second Edition)", World
Wide Web Consortium Recommendation REC- Wide Web Consortium Recommendation REC-
soap12-part1-20070427, April 2007, soap12-part1-20070427, April 2007,
<http://www.w3.org/TR/2007/REC-soap12-part1-20070427>. <http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
Appendix A. Security Automation with TNC IF-MAP Appendix A. Change Log
A.1. What is Trusted Network Connect? A.1. Changes in Revision 01
Renamed "credential" to "identity", following industry usage. A
credential includes proof, such as a key or password. A username or
a distinguished name is called an "identity".
Removed Session, because an endpoint's network activity is not SACM's
initial focus
Removed Authorization, for the same reason
Added many-to-many relationship between Hardware Component and
Endpoint, for clarity
Added many-to-many relationship between Software Component and
Endpoint, for clarity
Added "contains" relationship between Network Interface and Network
Interface
Removed relationship between Network Interface and Account. The
endpoint knows the identity it used to gain network access. The PDP
also knows that. But they probably do not know the account.
Added relationship between Network Interface and Identity. The
endpoint and the PDP will typically know the identity.
Made identity-to-account a many-to-one relationship.
A.2. Changes in Revision 02
Added Section 5.1, Identifying Attributes.
Split the figure into Figure 2 and Figure 3.
Added Figure 4, proposing a triple-store model.
Some editorial cleanup
A.3. Changes in Revision 03
Moved Appendix A.1, Appendix A.2, and Appendix B into the Appendix.
Added a reference to it in Section 1
Added the Section 3 section. Provided notes for the type of
information we need to add in this section.
Added the Section 4 section. Moved sections on Endpoint, Hardware
Component, Software Component, Hardware Instance, and Software
Instance there. Provided notes for the type of information we need
to add in this section.
Removed the Provenance of Information Section. SACM is not going to
solve provenance rather give organizations enough information to
figure it out.
Updated references to the Endpoint Security Posture Assessment:
Enterprise Use Cases document to reflect that it was published as an
RFC.
Fixed the formatting of a few figures.
Included references to [RFC3580] where RADIUS is mentioned.
Appendix B. Mapping to SACM Use Cases
TODO: revise
(wandw)This information model directly corresponds to all four use
cases defined in the SACM Use Cases draft [RFC7632]. It uses these
use cases in coordination to achieve a small set of well-defined
tasks.
Sections [removed] thru [removed] address each of the process areas.
For each process area, a "Process Area Description" sub-section
represent an end state that is consistent with all the General
Requirements and many of the Use Case Requirements identified in the
requirements draft [I-D.ietf-sacm-requirements].
The management process areas and supporting operations defined in
this memo directly support REQ004 Endpoint Discovery; REQ005-006
Attribute and Information Based Queries, and REQ0007 Asynchronous
Publication.
In addition, the operations that defined for each business process in
this memo directly correlate with the typical workflow identified in
the SACM Use Case document.(/wandw)
Appendix C. Security Automation with TNC IF-MAP
C.1. What is Trusted Network Connect?
Trusted Network Connect (TNC) is a vendor-neutral open architecture Trusted Network Connect (TNC) is a vendor-neutral open architecture
[TNC-Architecture] and a set of open standards for network security [TNC-Architecture] and a set of open standards for network security
developed by the Trusted Computing Group (TCG). TNC standards developed by the Trusted Computing Group (TCG). TNC standards
integrate security components across end user systems, servers, and integrate security components across end user systems, servers, and
network infrastructure devices into an intelligent, responsive, network infrastructure devices into an intelligent, responsive,
coordinated defense. TNC standards have been widely adopted by coordinated defense. TNC standards have been widely adopted by
vendors and customers; the TNC endpoint assessment protocols [TNC-IF- vendors and customers; the TNC endpoint assessment protocols [TNC-IF-
M-TLV-Binding][TNC-IF-TNCCS-TLV-Binding][TNC-IF-T-Tunneled-EAP][TNC-I M-TLV-Binding][TNC-IF-TNCCS-TLV-Binding][TNC-IF-T-Tunneled-EAP][TNC-I
F-T-TLS] were used as the base for the IETF NEA RFCs F-T-TLS] were used as the base for the IETF NEA RFCs
skipping to change at page 45, line 9 skipping to change at page 49, line 43
security, etc. The TNC architecture enables the integration and security, etc. The TNC architecture enables the integration and
categorization of security telemetry sources via the information categorization of security telemetry sources via the information
model contained in its Interface for Metadata Access Points (IF-MAP) model contained in its Interface for Metadata Access Points (IF-MAP)
[TNC-IF-MAP-SOAP-Binding]. IF-MAP provides a query-able repository [TNC-IF-MAP-SOAP-Binding]. IF-MAP provides a query-able repository
of security telemetry that may be used for storage or retrieval of of security telemetry that may be used for storage or retrieval of
such data by multiple types of security systems and endpoints on a such data by multiple types of security systems and endpoints on a
vendor-neutral basis. The information model underlying the IF-MAP vendor-neutral basis. The information model underlying the IF-MAP
repository covers, directly or indirectly, all of the security repository covers, directly or indirectly, all of the security
information types required to serve SACM use-cases. information types required to serve SACM use-cases.
A.2. What is TNC IF-MAP? C.2. What is TNC IF-MAP?
IF-MAP provides a standard client-server protocol for MAP clients to IF-MAP provides a standard client-server protocol for MAP clients to
exchange security-relevant information via database server known as exchange security-relevant information via database server known as
the Metadata Access Point or MAP. The data (known as "metadata") the Metadata Access Point or MAP. The data (known as "metadata")
stored in the MAP is XML data. Each piece of metadata is tagged with stored in the MAP is XML data. Each piece of metadata is tagged with
a metadata type that indicates the meaning of the metadata and a metadata type that indicates the meaning of the metadata and
identifies an XML schema for it. Due to the XML language, the set of identifies an XML schema for it. Due to the XML language, the set of
metadata types is easily extensible. metadata types is easily extensible.
The MAP is a graph database, not a relational database. Metadata can The MAP is a graph database, not a relational database. Metadata can
be associated with an identifier (e.g. the email address be associated with an identifier (e.g. the email address
"user@example.com") or with a link between two identifiers (e.g. the "user@example.com") or with a link between two identifiers (e.g. the
link between MAC address 00:11:22:33:44:55 and IPv4 address link between MAC address 00:11:22:33:44:55 and IPv4 address
192.0.2.1) where the link defines an association (for example: a 192.0.2.1) where the link defines an association (for example: a
relation or state) between the identifiers. These links between relation or state) between the identifiers. These links between
pairs of identifiers create an ad hoc graph of relationships between pairs of identifiers create an ad hoc graph of relationships between
identifiers. The emergent structure of this graph reflects a identifiers. The emergent structure of this graph reflects a
continuously evolving knowledge base of security-related metadata continuously evolving knowledge base of security-related metadata
that is shared between various providers and consumers. that is shared between various providers and consumers.
A.3. What is the TNC Information Model? C.3. What is the TNC Information Model?
The TNC Information Model underlying IF-MAP relies on the graph The TNC Information Model underlying IF-MAP relies on the graph
database architecture to enable a (potentially distributed) MAP database architecture to enable a (potentially distributed) MAP
service to act as a shared clearinghouse for information that service to act as a shared clearinghouse for information that
infrastructure devices can act upon. The IF-MAP operations and infrastructure devices can act upon. The IF-MAP operations and
metadata schema specifications (TNC IF-MAP Binding for SOAP metadata schema specifications (TNC IF-MAP Binding for SOAP
[TNC-IF-MAP-SOAP-Binding], TNC IF-MAP Metadata for Network Security [TNC-IF-MAP-SOAP-Binding], TNC IF-MAP Metadata for Network Security
[TNC-IF-MAP-NETSEC-METADATA], and TNC IF-MAP Metadata for ICS [TNC-IF-MAP-NETSEC-METADATA], and TNC IF-MAP Metadata for ICS
Security [TNC-IF-MAP-ICS-METADATA]) define an extensible set of Security [TNC-IF-MAP-ICS-METADATA]) define an extensible set of
identifiers and data types. identifiers and data types.
skipping to change at page 46, line 18 skipping to change at page 51, line 5
The reader is invited to review the existing IF-MAP specification The reader is invited to review the existing IF-MAP specification
[TNC-IF-MAP-SOAP-Binding] for more details on the above graph data [TNC-IF-MAP-SOAP-Binding] for more details on the above graph data
store operation requests and their associated arguments. store operation requests and their associated arguments.
The current IF-MAP specification provides a SOAP The current IF-MAP specification provides a SOAP
[W3C.REC-soap12-part1-20070427] binding for the above operations, as [W3C.REC-soap12-part1-20070427] binding for the above operations, as
well as associated SOAP operations for managing sessions, error well as associated SOAP operations for managing sessions, error
handling, etc. handling, etc.
Appendix B. Text for Possible Inclusion in the Terminology Draft Appendix D. Text for Possible Inclusion in the Terminology Draft
B.1. Terms and Definitions D.1. Terms and Definitions
This section describes terms that have been defined by other RFCs and This section describes terms that have been defined by other RFCs and
Internet Drafts, as well as new terms introduced in this document. Internet Drafts, as well as new terms introduced in this document.
B.1.1. Pre-defined and Modified Terms D.1.1. Pre-defined and Modified Terms
This section contains pre-defined terms that are sourced from other This section contains pre-defined terms that are sourced from other
IETF RFCs and Internet Drafts. Descriptions of terms in this section IETF RFCs and Internet Drafts. Descriptions of terms in this section
will reference the original source of the term and will provide will reference the original source of the term and will provide
additional specific context for the use of each term in SACM. For additional specific context for the use of each term in SACM. For
sake of brevity, terms from [I-D.ietf-sacm-terminology] are not sake of brevity, terms from [I-D.ietf-sacm-terminology] are not
repeated here unless the original meaning has been changed in this repeated here unless the original meaning has been changed in this
document. document.
Asset For this Information Model it is necessary to change the Asset For this Information Model it is necessary to change the
skipping to change at page 47, line 9 skipping to change at page 51, line 45
value to an organization, including, but not limited to, value to an organization, including, but not limited to,
another organization, person, computing device, information another organization, person, computing device, information
technology (IT) system, IT network, IT circuit, software technology (IT) system, IT network, IT circuit, software
(both an installed instance and a physical instance), virtual (both an installed instance and a physical instance), virtual
computing platform (common in cloud and virtualized computing platform (common in cloud and virtualized
computing), and related hardware (e.g., locks, cabinets, computing), and related hardware (e.g., locks, cabinets,
keyboards)." This definition aligns better with common keyboards)." This definition aligns better with common
dictionary definitions of the term and better fits the needs dictionary definitions of the term and better fits the needs
of this document. of this document.
B.1.2. New Terms D.1.2. New Terms
IT Asset Originally defined in [RFC4949] as "a system resource that IT Asset Originally defined in [RFC4949] as "a system resource that
is (a) required to be protected by an information system's is (a) required to be protected by an information system's
security policy, (b) intended to be protected by a security policy, (b) intended to be protected by a
countermeasure, or (c) required for a system's mission." countermeasure, or (c) required for a system's mission."
Security Content Automation Protocol (SCAP) According to SP800-126, Security Content Automation Protocol (SCAP) According to SP800-126,
SCAP, pronounced "ess-cap", is "a suite of specifications SCAP, pronounced "ess-cap", is "a suite of specifications
that standardize the format and nomenclature by which that standardize the format and nomenclature by which
software flaw and security configuration information is software flaw and security configuration information is
communicated, both to machines and humans." SP800-117 communicated, both to machines and humans." SP800-117
revision 1 [SP800-117] provides a general overview of SCAP revision 1 [SP800-117] provides a general overview of SCAP
1.2. The 11 specifications that comprise SCAP 1.2 are 1.2. The 11 specifications that comprise SCAP 1.2 are
synthesized by a master specification, SP800-126 revision 2 synthesized by a master specification, SP800-126 revision 2
[SP800-126], that addresses integration of the specifications [SP800-126], that addresses integration of the specifications
into a coherent whole. The use of "protocol" in its name is into a coherent whole. The use of "protocol" in its name is
a misnomer, as SCAP defines only data models. SCAP has been a misnomer, as SCAP defines only data models. SCAP has been
adopted by a number of operating system and security tool adopted by a number of operating system and security tool
vendors. vendors.
Appendix C. Text for Possible Inclusion in the Architecture or Use Appendix E. Text for Possible Inclusion in the Architecture or Use
Cases Cases
C.1. Introduction E.1. Introduction
The posture of an endpoint is the status of the endpoint with respect The posture of an endpoint is the status of the endpoint with respect
to the security policies and risk models of the organization. to the security policies and risk models of the organization.
A system administrator needs to be able to determine which elements A system administrator needs to be able to determine which elements
of an endpoint have a security problem and which do not conform the of an endpoint have a security problem and which do not conform the
organization's security policies. The CIO needs to be able to organization's security policies. The CIO needs to be able to
determine whether endpoints have security postures that conform to determine whether endpoints have security postures that conform to
the organization's policies to ensure that the organization is the organization's policies to ensure that the organization is
complying with its fiduciary and regulatory responsibilities. The complying with its fiduciary and regulatory responsibilities. The
skipping to change at page 48, line 19 skipping to change at page 53, line 5
implement security automation standards in the form of data formats, implement security automation standards in the form of data formats,
interfaces, and protocols to be able to assess, in a timely and interfaces, and protocols to be able to assess, in a timely and
secure fashion, all assets on all endpoints within their enterprise. secure fashion, all assets on all endpoints within their enterprise.
This information model provides a basis to identify the desirable This information model provides a basis to identify the desirable
characteristics of data models to support these scenarios. Other characteristics of data models to support these scenarios. Other
SACM specifications, such as the SACM Architecture, will describe the SACM specifications, such as the SACM Architecture, will describe the
potential components of an interoperable system solution based on the potential components of an interoperable system solution based on the
SACM information model to address the requirements for scalability, SACM information model to address the requirements for scalability,
timeliness, and security. timeliness, and security.
C.2. Core Principles E.2. Core Principles
This information model is built on the following core principles: This information model is built on the following core principles:
o Collection and Evaluation are separate tasks. o Collection and Evaluation are separate tasks.
o Collection and Evaluation can be performed on the endpoint, at a o Collection and Evaluation can be performed on the endpoint, at a
local server that communicates directly with the endpoint, or local server that communicates directly with the endpoint, or
based on data queried from a back end data store that does not based on data queried from a back end data store that does not
communicate directly with any endpoints. communicate directly with any endpoints.
skipping to change at page 49, line 14 skipping to change at page 53, line 48
associated with policy or may be queried dynamically based on associated with policy or may be queried dynamically based on
associated metadata. associated metadata.
o Guidance can be gathered from multiple data stores. It may be o Guidance can be gathered from multiple data stores. It may be
retrieved at the point of use or may be packaged and forwarded for retrieved at the point of use or may be packaged and forwarded for
later use. Guidance may be retrieved in event of a collection or later use. Guidance may be retrieved in event of a collection or
evaluation trigger or it may be gathered ahead of time and stored evaluation trigger or it may be gathered ahead of time and stored
locally for use/reference during collection and evaluation locally for use/reference during collection and evaluation
activities. activities.
C.3. Architecture Assumptions E.3. Architecture Assumptions
This information model will focus on WHAT information needs to be This information model will focus on WHAT information needs to be
exchanged to support the business process areas. The architecture exchanged to support the business process areas. The architecture
document is the best place to represent the HOW and the WHERE this document is the best place to represent the HOW and the WHERE this
information is used. In an effort to ensure that the data models information is used. In an effort to ensure that the data models
derived from this information model scale to the architecture, four derived from this information model scale to the architecture, four
core architectural components need to be defined. They are core architectural components need to be defined. They are
producers, consumers, capabilities, and repositories. These elements producers, consumers, capabilities, and repositories. These elements
are defined as follows: are defined as follows:
skipping to change at page 49, line 50 skipping to change at page 54, line 35
o Repositories (e.g., Enterprise Repository) store information items o Repositories (e.g., Enterprise Repository) store information items
that are input to or output from Capabilities, Producers, and that are input to or output from Capabilities, Producers, and
Consumers. For this model we refer to generic Enterprise and Consumers. For this model we refer to generic Enterprise and
Guidance Repositories. Guidance Repositories.
Information that needs to be communicated by or made available to any Information that needs to be communicated by or made available to any
of these components will be specified in each of the business process of these components will be specified in each of the business process
areas. areas.
In the most trivial example, illustrated in Figure 4, Consumers In the most trivial example, illustrated in Figure 5, Consumers
either request information from, or are notified by, Producers. either request information from, or are notified by, Producers.
+----------+ Request +----------+ +----------+ Request +----------+
| <-----------------+ | | <-----------------+ |
| Producer | | Consumer | | Producer | | Consumer |
| +-----------------> | | +-----------------> |
+----------+ Response +----------+ +----------+ Response +----------+
+----------+ +----------+ +----------+ +----------+
| | Notify | | | | Notify | |
| Producer +-----------------> Consumer | | Producer +-----------------> Consumer |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
Figure 4: Example Producer/Consumer Interactions Figure 5: Example Producer/Consumer Interactions
As illustrated in Figure 5, writing and querying from data As illustrated in Figure 6, writing and querying from data
repositories are a way in which this interaction can occur in an repositories are a way in which this interaction can occur in an
asynchronous fashion. asynchronous fashion.
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| Producer | | Consumer | | Producer | | Consumer |
| | | | | | | |
+-----+----+ +----^-----+ +-----+----+ +----^-----+
| | | |
Write | +------------+ | Query Write | +------------+ | Query
| | | | | | | |
+-----> Repository +-------+ +-----> Repository +-------+
| | | |
+------------+ +------------+
Figure 5: Producer/Consumer Repository Interaction Figure 6: Producer/Consumer Repository Interaction
To perform an assessment, these elements are chained together. The To perform an assessment, these elements are chained together. The
diagram below is illustrative of this and process, and is meant to diagram below is illustrative of this and process, and is meant to
demonstrate WHAT basic information exchanges need to occur, while demonstrate WHAT basic information exchanges need to occur, while
trying to maintain flexibility in HOW and WHERE they occur. trying to maintain flexibility in HOW and WHERE they occur.
For example: For example:
o the collection capability can reside on the endpoint or not. o the collection capability can reside on the endpoint or not.
skipping to change at page 51, line 48 skipping to change at page 56, line 48
+-----v--------+ +----+------+ +-----v--------+ +----+------+
|Evaluation | |Reporting | |Evaluation | |Reporting |
|Results | |Guidance | |Results | |Guidance |
|Consumer | |Repository | |Consumer | |Repository |
+---+----------+ +-----------+ +-------------+ +---+----------+ +-----------+ +-------------+
| | Results | | | Results |
+-----------------------------> Repository | +-----------------------------> Repository |
| | | |
+-------------+ +-------------+
Figure 6: Producer/Consumer Complex Example Figure 7: Producer/Consumer Complex Example
This illustrative example in Figure 6 provides a set of information This illustrative example in Figure 7 provides a set of information
exchanges that need to occur to perform a posture assessment. The exchanges that need to occur to perform a posture assessment. The
rest of this information model is using this set of exchanges based rest of this information model is using this set of exchanges based
on these core architectural components as the basis for determining on these core architectural components as the basis for determining
information elements. information elements.
Appendix D. Text for Possible Inclusion in the Requirements Draft Appendix F. Text for Possible Inclusion in the Requirements Draft
D.1. Problem Statement F.1. Problem Statement
Scalable and sustainable collection, expression, and evaluation of Scalable and sustainable collection, expression, and evaluation of
endpoint information is foundational to SACM's objectives. To secure endpoint information is foundational to SACM's objectives. To secure
and defend one's network one must reliably determine what devices are and defend one's network one must reliably determine what devices are
on the network, how those devices are configured from a hardware on the network, how those devices are configured from a hardware
perspective, what software products are installed on those devices, perspective, what software products are installed on those devices,
and how those products are configured. We need to be able to and how those products are configured. We need to be able to
determine, share, and use this information in a secure, timely, determine, share, and use this information in a secure, timely,
consistent, and automated manner to perform endpoint posture consistent, and automated manner to perform endpoint posture
assessments. assessments.
D.2. Problem Scope F.2. Problem Scope
The goal of this iteration of the information model is to define the The goal of this iteration of the information model is to define the
information needs for an organization to effectively monitor the information needs for an organization to effectively monitor the
endpoints operating on their network, the software installed on those endpoints operating on their network, the software installed on those
endpoints, and the configuration of that software. Once we have endpoints, and the configuration of that software. Once we have
those three business processes in place, we can identify vulnerable those three business processes in place, we can identify vulnerable
endpoints in a very efficient manner. endpoints in a very efficient manner.
The four business process areas represent a large set of tasks that The four business process areas represent a large set of tasks that
support endpoint posture assessment. In an effort to address the support endpoint posture assessment. In an effort to address the
skipping to change at page 53, line 12 skipping to change at page 58, line 12
for an acceptable data element or attribute value. A system for an acceptable data element or attribute value. A system
administrator can also identify specific data elements and administrator can also identify specific data elements and
attributes that represent problems, such as vulnerabilities, that attributes that represent problems, such as vulnerabilities, that
need to be detected on an endpoint. need to be detected on an endpoint.
4. Evaluate the collected instances of the asset data against those 4. Evaluate the collected instances of the asset data against those
expressed in the policy. expressed in the policy.
5. Report the results of the evaluation. 5. Report the results of the evaluation.
Appendix E. Text With No Clear Home Yet Appendix G. Text With No Clear Home Yet
E.1. Operations G.1. Operations
Operations that may be carried out the proposed SACM Information Operations that may be carried out the proposed SACM Information
Model are: Model are:
o Publish data: Security information is made available in the o Publish data: Security information is made available in the
information model when a component publishes data to it. information model when a component publishes data to it.
o Subscribe to data: A component seeking to consume an on-going o Subscribe to data: A component seeking to consume an on-going
stream of security information "subscribes" to such data from the stream of security information "subscribes" to such data from the
information model. information model.
o Query: This operation enables a component to request a specific o Query: This operation enables a component to request a specific
set of security data regarding a specific asset (such as a set of security data regarding a specific asset (such as a
specific user endpoint). specific user endpoint).
The subscribe capability will allow SACM components to monitor for The subscribe capability will allow SACM components to monitor for
selected security-related changes in the graph data store without selected security-related changes in the graph data store without
incurring the performance penalties associated with polling for such incurring the performance penalties associated with polling for such
changes. changes.
E.1.1. Generalized Workflow G.1.1. Generalized Workflow
The proposed SACM Information Model would be most commonly used with The proposed SACM Information Model would be most commonly used with
a suitable transport protocol for collecting and distributing a suitable transport protocol for collecting and distributing
security data across appropriate network platforms and endpoints. security data across appropriate network platforms and endpoints.
The information model is transport agnostic and can be used with its The information model is transport agnostic and can be used with its
native transport provided by IF-MAP or by other data transport native transport provided by IF-MAP or by other data transport
protocols such as the recently proposed XMPP-Grid. protocols such as the recently proposed XMPP-Grid.
1. A Posture Assessment Information Consumer (Consumer) establishes 1. A Posture Assessment Information Consumer (Consumer) establishes
connectivity and authorization with the transport fabric. connectivity and authorization with the transport fabric.
skipping to change at page 54, line 17 skipping to change at page 59, line 17
security data) for the requesting components. security data) for the requesting components.
4. Components may either publish security data, subscribe to 4. Components may either publish security data, subscribe to
security data, query for security data, or any combination of security data, query for security data, or any combination of
these operations. these operations.
Any component sharing information - either as Provider or Consumer - Any component sharing information - either as Provider or Consumer -
may do so on a one-to-one, one-to-many and/or many-to-many meshed may do so on a one-to-one, one-to-many and/or many-to-many meshed
basis. basis.
E.2. From Information Needs to Information Elements G.2. From Information Needs to Information Elements
The previous sections highlighted information needs for a set of The previous sections highlighted information needs for a set of
management process areas that use posture assessment to achieve management process areas that use posture assessment to achieve
organizational security goals. A single information need may be made organizational security goals. A single information need may be made
up of multiple information elements. Some information elements may up of multiple information elements. Some information elements may
be required for two different process areas, resulting in two be required for two different process areas, resulting in two
different requirements. In an effort to support the main idea of different requirements. In an effort to support the main idea of
collect once and reuse the data to support multiple processes, we try collect once and reuse the data to support multiple processes, we try
to define a singular set of information elements that will support to define a singular set of information elements that will support
all the associated information needs. all the associated information needs.
E.3. Information Model Elements G.3. Information Model Elements
TODO: Kim to pull up relevant content into section 4 / Elements TODO: Kim to pull up relevant content into section 4 / Elements
Traditionally, one would use the SACM architecture to define Traditionally, one would use the SACM architecture to define
interfaces that required information exchanges. Identified interfaces that required information exchanges. Identified
information elements would then be based on those exchanges. Because information elements would then be based on those exchanges. Because
the SACM architecture document is still in the personal draft stage, the SACM architecture document is still in the personal draft stage,
this information model uses a different approach to the this information model uses a different approach to the
identification of information elements. First it lists the four main identification of information elements. First it lists the four main
endpoint posture assessment activities. Then it identifies endpoint posture assessment activities. Then it identifies
management process areas that use endpoint posture assessment to management process areas that use endpoint posture assessment to
achieve organizational security objectives. These process areas were achieve organizational security objectives. These process areas were
then broken down into operations that mirrored the typical workflow then broken down into operations that mirrored the typical workflow
from the SACM Use Cases draft [I-D.ietf-sacm-use-cases]. These from the SACM Use Cases draft [RFC7632]. These operations identify
operations identify architectural components and their information architectural components and their information needs. In this
needs. In this section, information elements derived from those section, information elements derived from those information needs
information needs are mapped back to the four main activities listed are mapped back to the four main activities listed above.
above.
The original liaison statement [IM-LIAISON-STATEMENT-NIST] requested The original liaison statement [IM-LIAISON-STATEMENT-NIST] requested
contributions for the SACM information model in the four areas contributions for the SACM information model in the four areas
described below. Based on the capabilities defined previously in described below. Based on the capabilities defined previously in
this document, the requested areas alone do not provide a sufficient this document, the requested areas alone do not provide a sufficient
enough categorization of the necessary information model elements. enough categorization of the necessary information model elements.
The following sub-sections directly address the requested areas as The following sub-sections directly address the requested areas as
follows: follows:
1. Endpoint Identification 1. Endpoint Identification
A. Appendix E.3.1 Asset Identifiers: Describes identification of A. Appendix G.3.1 Asset Identifiers: Describes identification of
many different asset types including endpoints. many different asset types including endpoints.
2. Endpoint Characterization 2. Endpoint Characterization
A. Appendix E.3.3 Endpoint characterization: This directly maps A. Appendix G.3.3 Endpoint characterization: This directly maps
to the requested area. to the requested area.
3. Endpoint Attribute Expression/Representation 3. Endpoint Attribute Expression/Representation
A. Appendix E.3.4 Posture Attribute Expression: This corresponds A. Appendix G.3.4 Posture Attribute Expression: This corresponds
to the first part of "Endpoint Attribute Expression/ to the first part of "Endpoint Attribute Expression/
Representation." Representation."
B. Appendix E.3.5 Actual Value Representation: This corresponds B. Appendix G.3.5 Actual Value Representation: This corresponds
to the second part of "Endpoint Attribute Expression/ to the second part of "Endpoint Attribute Expression/
Representation." Representation."
4. Policy evaluation expression and results reporting 4. Policy evaluation expression and results reporting
A. Appendix E.3.6 Evaluation Guidance: This corresponds to the A. Appendix G.3.6 Evaluation Guidance: This corresponds to the
first part of "Policy evaluation expression and results first part of "Policy evaluation expression and results
reporting." reporting."
B. Appendix E.3.7 Evaluation Result Reporting: corresponds to B. Appendix G.3.7 Evaluation Result Reporting: corresponds to
the second part of "Policy evaluation expression and results the second part of "Policy evaluation expression and results
reporting." reporting."
Additionally, Appendix E.3.2 Other Identifiers: describes other Additionally, Appendix G.3.2 Other Identifiers: describes other
important identification concepts that were not directly requested by important identification concepts that were not directly requested by
the liaison statement. the liaison statement.
Per the liaison statement, each subsection references related work Per the liaison statement, each subsection references related work
that provides a basis for potential data models. Some analysis is that provides a basis for potential data models. Some analysis is
also included for each area of related work on how directly also included for each area of related work on how directly
applicable the work is to the SACM efforts. In general, much of the applicable the work is to the SACM efforts. In general, much of the
related work does not fully address the general or use case-based related work does not fully address the general or use case-based
requirements for SACM, but they do contain some parts that can be requirements for SACM, but they do contain some parts that can be
used as the basis for data models that correspond to the information used as the basis for data models that correspond to the information
skipping to change at page 56, line 18 skipping to change at page 61, line 17
discussion is needed to include other related work in standards and discussion is needed to include other related work in standards and
technology communities that could and should be listed here. The technology communities that could and should be listed here. The
authors intend to continue this work in subsequent revisions of this authors intend to continue this work in subsequent revisions of this
draft. draft.
Where possible when selecting and developing data models in support Where possible when selecting and developing data models in support
of these information model elements, extension points and IANA of these information model elements, extension points and IANA
registries SHOULD be used to provide for extensibility which will registries SHOULD be used to provide for extensibility which will
allow for future data models to be addressed. allow for future data models to be addressed.
E.3.1. Asset Identifiers G.3.1. Asset Identifiers
In this context an "asset" refers to "anything that has value to an In this context an "asset" refers to "anything that has value to an
organization" (see [NISTIR-7693]). This use of the term "asset" is organization" (see [NISTIR-7693]). This use of the term "asset" is
broader than the current definition in [I-D.ietf-sacm-terminology]. broader than the current definition in [I-D.ietf-sacm-terminology].
To support SACM use cases, a number of different asset types will To support SACM use cases, a number of different asset types will
need to be addressed. For each type of asset, one or more type of need to be addressed. For each type of asset, one or more type of
asset identifier will be needed for use in establishing contextual asset identifier will be needed for use in establishing contextual
relationships within the SACM information model. The following asset relationships within the SACM information model. The following asset
types are referenced or implied by the SACM use cases: types are referenced or implied by the SACM use cases:
skipping to change at page 56, line 46 skipping to change at page 61, line 45
within an endpoint. within an endpoint.
Network: Identifies a network for which a given endpoint may be Network: Identifies a network for which a given endpoint may be
connected or request a connection to. connected or request a connection to.
Organization: Identifies an organizational unit. Organization: Identifies an organizational unit.
Person: Identifies an individual, often within an organizational Person: Identifies an individual, often within an organizational
context. context.
E.3.1.1. Related Work G.3.1.1. Related Work
E.3.1.1.1. Asset Identification
G.3.1.1.1. Asset Identification
The Asset Identification specification [NISTIR-7693] is an XML-based The Asset Identification specification [NISTIR-7693] is an XML-based
data model that "provides the necessary constructs to uniquely data model that "provides the necessary constructs to uniquely
identify assets based on known identifiers and/or known information identify assets based on known identifiers and/or known information
about the assets." Asset identification plays an important role in about the assets." Asset identification plays an important role in
an organization's ability to quickly correlate different sets of an organization's ability to quickly correlate different sets of
information about assets. The Asset Identification specification information about assets. The Asset Identification specification
provides the necessary constructs to uniquely identify assets based provides the necessary constructs to uniquely identify assets based
on known identifiers and/or known information about the assets. on known identifiers and/or known information about the assets.
Asset Identification provides a relatively flat and extensible model Asset Identification provides a relatively flat and extensible model
for capturing the identifying information about a one or more assets, for capturing the identifying information about a one or more assets,
and also provides a way to represent relationships between assets. and also provides a way to represent relationships between assets.
The model is organized using an inheritance hierarchy of specialized The model is organized using an inheritance hierarchy of specialized
asset types/classes (see Figure 7), providing for extension at any asset types/classes (see Figure 8), providing for extension at any
level of abstraction. For a given asset type, a number of properties level of abstraction. For a given asset type, a number of properties
are defined that provide for capturing identifying characteristics are defined that provide for capturing identifying characteristics
and the referencing of namespace qualified asset identifiers, called and the referencing of namespace qualified asset identifiers, called
"synthetic IDs." "synthetic IDs."
The following figure illustrates the class hierarchy defined by the The following figure illustrates the class hierarchy defined by the
Asset Identification specification. Asset Identification specification.
asset asset
+-it-asset +-it-asset
skipping to change at page 57, line 42 skipping to change at page 62, line 37
| +-database | +-database
| +-network | +-network
| +-service | +-service
| +-software | +-software
| +-system | +-system
| +-website | +-website
+-data +-data
+-organization +-organization
+-person +-person
Figure 7: Asset Identification Class Hierarchy Figure 8: Asset Identification Class Hierarchy
This table presents a mapping of notional SACM asset types to those This table presents a mapping of notional SACM asset types to those
asset types provided by the Asset Identification specification. asset types provided by the Asset Identification specification.
+--------------+------------------+---------------------------------+ +--------------+------------------+---------------------------------+
| SACM Asset | Asset | Notes | | SACM Asset | Asset | Notes |
| Type | Identification | | | Type | Identification | |
| | Type | | | | Type | |
+--------------+------------------+---------------------------------+ +--------------+------------------+---------------------------------+
| Endpoint | computing-device | This is not a direct mapping | | Endpoint | computing-device | This is not a direct mapping |
skipping to change at page 58, line 42 skipping to change at page 63, line 42
+--------------+------------------+---------------------------------+ +--------------+------------------+---------------------------------+
| Person | person | Direct mapping. | | Person | person | Direct mapping. |
+--------------+------------------+---------------------------------+ +--------------+------------------+---------------------------------+
Table 1: Mapping of SACM to Asset Identification Asset Types Table 1: Mapping of SACM to Asset Identification Asset Types
This specification has been adopted by a number of SCAP validated This specification has been adopted by a number of SCAP validated
products. It can be used to address asset identification and products. It can be used to address asset identification and
categorization needs within SACM with minor modification. categorization needs within SACM with minor modification.
E.3.1.2. Endpoint Identification G.3.1.2. Endpoint Identification
An unique name for an endpoint. This is a foundational piece of An unique name for an endpoint. This is a foundational piece of
information that will enable collected posture attributes to be information that will enable collected posture attributes to be
related to the endpoint from which they were collected. It is related to the endpoint from which they were collected. It is
important that this name either be created from, provide, or be important that this name either be created from, provide, or be
associated with operational information (e.g., MAC address, hardware associated with operational information (e.g., MAC address, hardware
certificate) that is discoverable from the endpoint or its certificate) that is discoverable from the endpoint or its
communications on the network. It is also important to have a method communications on the network. It is also important to have a method
of endpoint identification that can persist across network sessions of endpoint identification that can persist across network sessions
to allow for correlation of collected data over time. to allow for correlation of collected data over time.
E.3.1.2.1. Related Work G.3.1.2.1. Related Work
The previously introduced asset identification specification (see The previously introduced asset identification specification (see
Appendix E.3.1.1.1 provides a basis for endpoint identification using Appendix G.3.1.1.1 provides a basis for endpoint identification using
the "computing-device" class. While the meaning of this class is the "computing-device" class. While the meaning of this class is
broader than the current definition of an endpoint in the SACM broader than the current definition of an endpoint in the SACM
terminology [I-D.ietf-sacm-terminology], either that class or an terminology [I-D.ietf-sacm-terminology], either that class or an
appropriate sub-class extension can be used to capture identification appropriate sub-class extension can be used to capture identification
information for various endpoint types. information for various endpoint types.
E.3.1.3. Software Identification G.3.1.3. Software Identification
A unique name for a unit of installable software. Software names A unique name for a unit of installable software. Software names
should generally represent a unique release or installable version of should generally represent a unique release or installable version of
software. Identification approaches should allow for identification software. Identification approaches should allow for identification
of commercially available, open source, and organizationally of commercially available, open source, and organizationally
developed custom software. As new software releases are created, a developed custom software. As new software releases are created, a
new software identifier should be created by the releasing party new software identifier should be created by the releasing party
(e.g., software creator, publisher, licensor). Such an identifier is (e.g., software creator, publisher, licensor). Such an identifier is
useful to: useful to:
skipping to change at page 59, line 44 skipping to change at page 64, line 44
based on what software is installed on that endpoint. based on what software is installed on that endpoint.
o Define guidance related to a software unit that represents o Define guidance related to a software unit that represents
collection, evaluation, or other automatable policies. collection, evaluation, or other automatable policies.
In general, an extensible method of software identification is needed In general, an extensible method of software identification is needed
to provide for adequate coverage and to address legacy identification to provide for adequate coverage and to address legacy identification
approaches. Use of an IANA registry supporting multiple software approaches. Use of an IANA registry supporting multiple software
identification methods would be an ideal way forward. identification methods would be an ideal way forward.
E.3.1.3.1. Related Work G.3.1.3.1. Related Work
While we are not aware of a one-size-fits-all solution for software While we are not aware of a one-size-fits-all solution for software
identification, there are two existing specifications that should be identification, there are two existing specifications that should be
considered as part of the solution set. They are described in the considered as part of the solution set. They are described in the
following subsections. following subsections.
E.3.1.3.1.1. Common Platform Enumeration G.3.1.3.1.1. Common Platform Enumeration
E.3.1.3.1.1.1. Background G.3.1.3.1.1.1. Background
The Common Platform Enumeration (CPE) [CPE-WEBSITE] is composed of a The Common Platform Enumeration (CPE) [CPE-WEBSITE] is composed of a
family of four specification that are layered to build on lower-level family of four specification that are layered to build on lower-level
functionality. The following describes each specification: functionality. The following describes each specification:
1. CPE Naming: A standard machine-readable format [NISTIR-7695] for 1. CPE Naming: A standard machine-readable format [NISTIR-7695] for
encoding names of IT products and platforms. This defines the encoding names of IT products and platforms. This defines the
notation used to encode the vendor, software name, edition, notation used to encode the vendor, software name, edition,
version and other related information for each platform or version and other related information for each platform or
product. With the 2.3 version of CPE, a second, more advanced product. With the 2.3 version of CPE, a second, more advanced
skipping to change at page 61, line 12 skipping to change at page 66, line 12
organizations for curation. This centralized curation requirement organizations for curation. This centralized curation requirement
ensures that the effort has difficulty scaling. ensures that the effort has difficulty scaling.
o Not enough primary source vendors provide platform and product o Not enough primary source vendors provide platform and product
naming information. As a result, this pushes too much of the naming information. As a result, this pushes too much of the
effort out onto third-party groups and non-authoritative effort out onto third-party groups and non-authoritative
organizations. This exacerbates the ambiguity in names used for organizations. This exacerbates the ambiguity in names used for
identical platforms and products and further reduces the utility identical platforms and products and further reduces the utility
of the effort. of the effort.
E.3.1.3.1.1.2. Applicability to Software Identification G.3.1.3.1.1.2. Applicability to Software Identification
The Common Platform Enumeration (CPE) Naming specification version The Common Platform Enumeration (CPE) Naming specification version
2.3 defines a scheme for human-readable standardized identifiers of 2.3 defines a scheme for human-readable standardized identifiers of
hardware and software products. hardware and software products.
CPE names are the identifier format for software and hardware CPE names are the identifier format for software and hardware
products used in SCAP 1.2 and is currently adopted by a number of products used in SCAP 1.2 and is currently adopted by a number of
SCAP product vendors. SCAP product vendors.
CPE names can be directly referenced in the asset identification CPE names can be directly referenced in the asset identification
software class (see Appendix E.3.1.1.1.) software class (see Appendix G.3.1.1.1.)
Although relevant, CPE has an unsustainable maintenance "tail" due to Although relevant, CPE has an unsustainable maintenance "tail" due to
the need for centralized curation and naming-consistency enforcement. the need for centralized curation and naming-consistency enforcement.
Its mention in this document is to support the historic inclusion of Its mention in this document is to support the historic inclusion of
CPE as part of SCAP and implementation of this specification in a CPE as part of SCAP and implementation of this specification in a
number of security processes and products. Going forward, software number of security processes and products. Going forward, software
identification (SWID) tags are recommended as a replacement for CPE. identification (SWID) tags are recommended as a replacement for CPE.
To this end, work has been started to align both efforts to provide To this end, work has been started to align both efforts to provide
translation for software units identified using SWID tags to CPE translation for software units identified using SWID tags to CPE
Names. This translation would allow tools that currently use CPE- Names. This translation would allow tools that currently use CPE-
based identifiers to map to SWID identifiers during a transition based identifiers to map to SWID identifiers during a transition
period. period.
E.3.1.3.1.2. Software Identification (SWID) Tags G.3.1.3.1.2. Software Identification (SWID) Tags
The software identification tag specification [ISO.19770-2] is an The software identification tag specification [ISO.19770-2] is an
XML-based data model that is used to describe a unit of installable XML-based data model that is used to describe a unit of installable
software. A SWID tag contains data elements that: software. A SWID tag contains data elements that:
o Identify a specific unit of installable software, o Identify a specific unit of installable software,
o Enable categorization of the software (e.g., edition, bundle), o Enable categorization of the software (e.g., edition, bundle),
o Identification and hashing of software artifacts (e.g., o Identification and hashing of software artifacts (e.g.,
skipping to change at page 62, line 31 skipping to change at page 67, line 31
2. As the source of unique identifiers for installed software. 2. As the source of unique identifiers for installed software.
In addition to usage for software identification, a SWID tag can In addition to usage for software identification, a SWID tag can
provide the necessary data needed to target guidance based on provide the necessary data needed to target guidance based on
included metadata, and to support verification of installed software included metadata, and to support verification of installed software
and software media using cryptographic hashes. This added and software media using cryptographic hashes. This added
information increases the value of using SWID tags as part of the information increases the value of using SWID tags as part of the
larger security automation and continuous monitoring solution space. larger security automation and continuous monitoring solution space.
E.3.1.4. Hardware Identification G.3.1.4. Hardware Identification
Due to the time constraints, research into information elements and Due to the time constraints, research into information elements and
related work for identifying hardware is not included in this related work for identifying hardware is not included in this
revision of the information model. revision of the information model.
E.3.2. Other Identifiers G.3.2. Other Identifiers
In addition to identifying core asset types, it is also necessary to In addition to identifying core asset types, it is also necessary to
have stable, globally unique identifiers to represent other core have stable, globally unique identifiers to represent other core
concepts pertaining to posture attribute collection and evaluation. concepts pertaining to posture attribute collection and evaluation.
The concept of "global uniqueness" ensures that identifiers provided The concept of "global uniqueness" ensures that identifiers provided
by multiple organization do not collide. This may be handled by a by multiple organization do not collide. This may be handled by a
number of different mechanisms (e.g., use of namespaces). number of different mechanisms (e.g., use of namespaces).
E.3.2.1. Platform Configuration Item Identifier G.3.2.1. Platform Configuration Item Identifier
A name for a low-level, platform-dependent configuration mechanism as A name for a low-level, platform-dependent configuration mechanism as
determined by the authoritative primary source vendor. New determined by the authoritative primary source vendor. New
identifiers will be created when the source vendor makes changes to identifiers will be created when the source vendor makes changes to
the underlying platform capabilities (e.g., adding new settings, the underlying platform capabilities (e.g., adding new settings,
replacing old settings with new settings). When created each replacing old settings with new settings). When created each
identifier should remain consistent with regards to what it identifier should remain consistent with regards to what it
represents. Generally, a change in meaning would constitute the represents. Generally, a change in meaning would constitute the
creation of a new identifier. creation of a new identifier.
For example, if the configuration item is for "automatic execution of For example, if the configuration item is for "automatic execution of
code", then the platform vendor would name the low-level mechanism code", then the platform vendor would name the low-level mechanism
for their platform (e.g., autorun for mounted media). for their platform (e.g., autorun for mounted media).
E.3.2.1.1. Related Work G.3.2.1.1. Related Work
E.3.2.1.1.1. Common Configuration Enumeration G.3.2.1.1.1. Common Configuration Enumeration
The Common Configuration Enumeration (CCE) [CCE] is an effort managed The Common Configuration Enumeration (CCE) [CCE] is an effort managed
by NIST. CCE provides a unique identifier for platform-specific by NIST. CCE provides a unique identifier for platform-specific
configuration items that facilitates fast and accurate correlation of configuration items that facilitates fast and accurate correlation of
configuration items across multiple information sources and tools. configuration items across multiple information sources and tools.
CCE does this by providing an identifier, a human readable CCE does this by providing an identifier, a human readable
description of the configuration control, parameters needed to description of the configuration control, parameters needed to
implement the configuration control, various technical mechanisms implement the configuration control, various technical mechanisms
that can be used to implement the configuration control, and that can be used to implement the configuration control, and
references to documentation that describe the configuration control references to documentation that describe the configuration control
skipping to change at page 64, line 5 skipping to change at page 69, line 5
rely on a central point of coordination for assignment of new CCE rely on a central point of coordination for assignment of new CCE
identifiers. This approach to assignment requires a single identifiers. This approach to assignment requires a single
organization, currently NIST, to manage allocations of CCE organization, currently NIST, to manage allocations of CCE
identifiers which doesn't scale well and introduces sustainability identifiers which doesn't scale well and introduces sustainability
challenges for large volumes of identifier assignment. If this challenges for large volumes of identifier assignment. If this
approach is used going forward by SACM, a namespaced approach is approach is used going forward by SACM, a namespaced approach is
recommended for identifier assignment that allows vendors to manage recommended for identifier assignment that allows vendors to manage
their own namespace of CCE identifiers. This change would require their own namespace of CCE identifiers. This change would require
additional work to specify and implement. additional work to specify and implement.
E.3.2.1.1.2. Open Vulnerability and Assessment Language G.3.2.1.1.2. Open Vulnerability and Assessment Language
E.3.2.1.1.2.1. Background G.3.2.1.1.2.1. Background
The Open Vulnerability and Assessment Language (OVAL(R)) is an XML The Open Vulnerability and Assessment Language (OVAL(R)) is an XML
schema-based data model developed as part of a public-private schema-based data model developed as part of a public-private
information security community effort to standardize how to assess information security community effort to standardize how to assess
and report upon the security posture of endpoints. OVAL provides an and report upon the security posture of endpoints. OVAL provides an
established framework for making assertions about an endpoint's established framework for making assertions about an endpoint's
posture by standardizing the three main steps of the assessment posture by standardizing the three main steps of the assessment
process: process:
1. representing the current endpoint posture; 1. representing the current endpoint posture;
skipping to change at page 65, line 31 skipping to change at page 70, line 31
| Definitions | | | | | Results | | Definitions | | | | | Results |
| | +--------^--------+ +-+ | | | +--------^--------+ +-+ |
| | | | | | | | | |
| | +------------+ | | | +------------+ |
+------^------+ +-------+----+ +------^------+ +-------+----+
| | | |
+--------------------------------------+ +--------------------------------------+
Note: The direction of the arrows indicate a model dependency Note: The direction of the arrows indicate a model dependency
Figure 8: The OVAL Data Model Figure 9: The OVAL Data Model
The OVAL data model [OVAL-LANGUAGE], visualized in Figure 8, is The OVAL data model [OVAL-LANGUAGE], visualized in Figure 9, is
composed of a number of different components. The components are: composed of a number of different components. The components are:
o Common: Constructs, enumerations, and identifier formats that are o Common: Constructs, enumerations, and identifier formats that are
used throughout the other model components. used throughout the other model components.
o Definitions: Constructs that describe assertions about system o Definitions: Constructs that describe assertions about system
state. This component also includes constructs for internal state. This component also includes constructs for internal
variable creation and manipulation through a variety of functions. variable creation and manipulation through a variety of functions.
The core elements are: The core elements are:
skipping to change at page 68, line 17 skipping to change at page 73, line 17
o The current process for releasing a new version of OVAL, bundle o The current process for releasing a new version of OVAL, bundle
releases of the core language with release of community recognized releases of the core language with release of community recognized
platform schema. The revision processes for the core and platform platform schema. The revision processes for the core and platform
schema need to be decoupled. Each platform schema should use some schema need to be decoupled. Each platform schema should use some
mechanism to declare which core language version it relies on. mechanism to declare which core language version it relies on.
If adopted by SCAM, these issues will need to be addressed as part of If adopted by SCAM, these issues will need to be addressed as part of
the SCAM engineering work to make OVAL more broadly adoptable as a the SCAM engineering work to make OVAL more broadly adoptable as a
general purpose data model for posture collection and evaluation. general purpose data model for posture collection and evaluation.
E.3.2.1.1.2.2. Applicability to Platform Configuration Item G.3.2.1.1.2.2. Applicability to Platform Configuration Item
Identification Identification
Each OVAL Object is identified by a globally unique identifier. This Each OVAL Object is identified by a globally unique identifier. This
globally unique identifier could be used by the SACM community to globally unique identifier could be used by the SACM community to
identify platform-specific configuration items and at the same time identify platform-specific configuration items and at the same time
serve as collection guidance. If used in this manner, OVAL Objects serve as collection guidance. If used in this manner, OVAL Objects
would likely need to undergo changes in order to decouple it from would likely need to undergo changes in order to decouple it from
evaluation guidance and to provide more robust collection evaluation guidance and to provide more robust collection
capabilities to support the needs of the SACM community. capabilities to support the needs of the SACM community.
E.3.2.2. Configuration Item Identifier G.3.2.2. Configuration Item Identifier
An identifier for a high-level, platform-independent configuration An identifier for a high-level, platform-independent configuration
control. This identification concept is necessary to allow similar control. This identification concept is necessary to allow similar
configuration item concepts to be comparable across platforms. For configuration item concepts to be comparable across platforms. For
example, a configuration item might be created for the minimum example, a configuration item might be created for the minimum
password length configuration control, which may then have a number password length configuration control, which may then have a number
of different platform-specific configuration settings. Without this of different platform-specific configuration settings. Without this
type of identification, it will be difficult to perform evaluation of type of identification, it will be difficult to perform evaluation of
expected versus actual state in a platform-neutral way. expected versus actual state in a platform-neutral way.
High-level configuration items tend to change much less frequently High-level configuration items tend to change much less frequently
than the platform-specific configuration items (see Appendix E.3.2.1) than the platform-specific configuration items (see Appendix G.3.2.1)
that might be associated with them. To provide for the greatest that might be associated with them. To provide for the greatest
amount of sustainability, collections of configuration item amount of sustainability, collections of configuration item
identifiers are best defined by specific communities of interest, identifiers are best defined by specific communities of interest,
while platform-specific identifiers are best defined by the source while platform-specific identifiers are best defined by the source
vendor of the platform. Under this model, the primary source vendors vendor of the platform. Under this model, the primary source vendors
would map their platform-specific configuration controls to the would map their platform-specific configuration controls to the
appropriate platform-independent item allowing end-user organizations appropriate platform-independent item allowing end-user organizations
to make use of these relationships. to make use of these relationships.
To support different communities of interest, it may be necessary to To support different communities of interest, it may be necessary to
support multiple methods for identification of configuration items support multiple methods for identification of configuration items
and for associating related metadata. Use of an IANA registry and for associating related metadata. Use of an IANA registry
supporting multiple configuration item identification methods would supporting multiple configuration item identification methods would
be an ideal way forward. To the extent possible, a few number of be an ideal way forward. To the extent possible, a few number of
configuration item identification approaches is desirable, to configuration item identification approaches is desirable, to
maximize the update by vendors who would be maintain mapping of maximize the update by vendors who would be maintain mapping of
platform-specific configuration identifiers to the more general platform-specific configuration identifiers to the more general
platform-neutral configuration identifiers. platform-neutral configuration identifiers.
E.3.2.2.1. Related Work G.3.2.2.1. Related Work
E.3.2.2.1.1. Control Correlation Identifier G.3.2.2.1.1. Control Correlation Identifier
The Control Correlation Identifier (CCI) [CCI] is developed and The Control Correlation Identifier (CCI) [CCI] is developed and
managed by the United States Department of Defense (US-DoD) Defense managed by the United States Department of Defense (US-DoD) Defense
Information Systems Agency (DISA). According to their website, CCI Information Systems Agency (DISA). According to their website, CCI
"provides a standard identifier and description for each of the "provides a standard identifier and description for each of the
singular, actionable statements that comprise an information singular, actionable statements that comprise an information
assurance (IA) control or IA best practice. CCI bridges the gap assurance (IA) control or IA best practice. CCI bridges the gap
between high-level policy expressions and low-level technical between high-level policy expressions and low-level technical
implementations. CCI allows a security requirement that is expressed implementations. CCI allows a security requirement that is expressed
in a high-level policy framework to be decomposed and explicitly in a high-level policy framework to be decomposed and explicitly
skipping to change at page 69, line 42 skipping to change at page 74, line 42
across disparate technologies." across disparate technologies."
It is recommended that this approach be analysed as a potential It is recommended that this approach be analysed as a potential
candidate for use as a configuration item identifier method. candidate for use as a configuration item identifier method.
Note: This reference to CCI is for informational purposes. Since the Note: This reference to CCI is for informational purposes. Since the
editors do not represent DISA's interests, its inclusion in this editors do not represent DISA's interests, its inclusion in this
document does not indicate the presence or lack of desire to document does not indicate the presence or lack of desire to
contribute aspects of this effort to SACM. contribute aspects of this effort to SACM.
E.3.2.2.1.2. A Potential Alternate Approach G.3.2.2.1.2. A Potential Alternate Approach
There will likely be a desire by different communities to create There will likely be a desire by different communities to create
different collections of configuration item identifiers. This different collections of configuration item identifiers. This
fracturing may be caused by: fracturing may be caused by:
o Different requirements for levels of abstraction, o Different requirements for levels of abstraction,
o Varying needs for timely maintenance of the collection, and o Varying needs for timely maintenance of the collection, and
o Differing scopes of technological needs. o Differing scopes of technological needs.
skipping to change at page 70, line 25 skipping to change at page 75, line 25
configuration items provided by vendors to create groupings at configuration items provided by vendors to create groupings at
various levels of abstractions. By utilizing data provided by various levels of abstractions. By utilizing data provided by
vendors, technological needs and the timeliness of information can be vendors, technological needs and the timeliness of information can be
addressed based on customer requirements. addressed based on customer requirements.
SACM should consider this and other approaches to satisfy the need SACM should consider this and other approaches to satisfy the need
for configuration item roll-up in a way that provides the broadest for configuration item roll-up in a way that provides the broadest
benefit, while achieving a sensible degree of scalability and benefit, while achieving a sensible degree of scalability and
sustainability. sustainability.
E.3.2.3. Vulnerability Identifier G.3.2.3. Vulnerability Identifier
An unique name for a known software flaw that exists in specific An unique name for a known software flaw that exists in specific
versions of one or more units of software. One use of a versions of one or more units of software. One use of a
vulnerability identifier in the SACM context is to associate a given vulnerability identifier in the SACM context is to associate a given
flaw with the vulnerable software using software identifiers. For flaw with the vulnerable software using software identifiers. For
this reason at minimum, software identifiers should identify a this reason at minimum, software identifiers should identify a
software product to the patch or version level, and not just to the software product to the patch or version level, and not just to the
level that the product is licensed. level that the product is licensed.
E.3.2.3.1. Related Work G.3.2.3.1. Related Work
E.3.2.3.1.1. Common Vulnerabilities and Exposures G.3.2.3.1.1. Common Vulnerabilities and Exposures
Common Vulnerabilities and Exposures (CVE) [CVE-WEBSITE] is a MITRE Common Vulnerabilities and Exposures (CVE) [CVE-WEBSITE] is a MITRE
led effort to assign common identifiers to publicly known security led effort to assign common identifiers to publicly known security
vulnerabilities in software to facilitate the sharing of information vulnerabilities in software to facilitate the sharing of information
related to the vulnerabilities. CVE is the industry standard by related to the vulnerabilities. CVE is the industry standard by
which software vendors, tools, and security professionals identify which software vendors, tools, and security professionals identify
vulnerabilities and could be used to address SACM's need for a vulnerabilities and could be used to address SACM's need for a
vulnerability identifier. vulnerability identifier.
E.3.3. Endpoint characterization G.3.3. Endpoint characterization
Target when policies (collection, evaluated, guidance) apply Target when policies (collection, evaluated, guidance) apply
Collection can be used to further characterize Collection can be used to further characterize
Also human input Also human input
Information required to characterize an endpoint is used to determine Information required to characterize an endpoint is used to determine
what endpoints are the target of a posture assessment. It is also what endpoints are the target of a posture assessment. It is also
used to determine the collection, evaluation, and/or reporting used to determine the collection, evaluation, and/or reporting
policies and the associated guidance that apply to the assessment. policies and the associated guidance that apply to the assessment.
skipping to change at page 71, line 21 skipping to change at page 76, line 21
o A manual input process and entered into records associated with o A manual input process and entered into records associated with
the endpoint, or the endpoint, or
o Using information collected and evaluated by an assessment. o Using information collected and evaluated by an assessment.
Regardless of the method of collection, it will be necessary to query Regardless of the method of collection, it will be necessary to query
and exchange endpoint characterization information as part of the and exchange endpoint characterization information as part of the
assessment planning workflow. assessment planning workflow.
E.3.3.1. Related Work G.3.3.1. Related Work
E.3.3.1.1. Extensible Configuration Checklist Description Format G.3.3.1.1. Extensible Configuration Checklist Description Format
E.3.3.1.1.1. Background G.3.3.1.1.1. Background
The Extensible Configuration Checklist Description Format (XCCDF) is The Extensible Configuration Checklist Description Format (XCCDF) is
a specification that provides an XML-based format for expressing a specification that provides an XML-based format for expressing
security checklists. The XCCDF 1.2 specification is published by security checklists. The XCCDF 1.2 specification is published by
International Organization for Standardization (ISO) [ISO.18180]. International Organization for Standardization (ISO) [ISO.18180].
XCCDF contains multiple components and capabilities, and various XCCDF contains multiple components and capabilities, and various
components align with different elements of this information model. components align with different elements of this information model.
This specification was originally published by NIST [NISTIR-7275]. This specification was originally published by NIST [NISTIR-7275].
When contributed to ISO Joint Technical Committee 1 (JTC 1), a When contributed to ISO Joint Technical Committee 1 (JTC 1), a
comment was introduced indicating an interest in the IETF becoming comment was introduced indicating an interest in the IETF becoming
the maintenance organization for this standard. If the SACM working the maintenance organization for this standard. If the SACM working
group is interested in taking on engineering work pertaining to group is interested in taking on engineering work pertaining to
XCCDF, a contribution through a national body can be made to create a XCCDF, a contribution through a national body can be made to create a
ballot resolution for transition of this standard to the IETF for ballot resolution for transition of this standard to the IETF for
maintenance. maintenance.
E.3.3.1.1.2. Applicability to Endpoint characterization G.3.3.1.1.2. Applicability to Endpoint characterization
The target component of XCCDF provides a mechanism for capturing The target component of XCCDF provides a mechanism for capturing
characteristics about an endpoint including the fully qualified characteristics about an endpoint including the fully qualified
domain name, network address, references to external identification domain name, network address, references to external identification
information (e.g. Asset Identification), and is extensible to information (e.g. Asset Identification), and is extensible to
support other useful information (e.g. MAC address, globally unique support other useful information (e.g. MAC address, globally unique
identifier, certificate, etc.). XCCDF may serve as a good starting identifier, certificate, etc.). XCCDF may serve as a good starting
point for understanding the types of information that should be used point for understanding the types of information that should be used
to identify an endpoint. to identify an endpoint.
E.3.3.1.2. Asset Reporting Format G.3.3.1.2. Asset Reporting Format
E.3.3.1.2.1. Background G.3.3.1.2.1. Background
The Asset Reporting Format (ARF) [NISTIR-7694] is a data model to The Asset Reporting Format (ARF) [NISTIR-7694] is a data model to
express information about assets, and the relationships between express information about assets, and the relationships between
assets and reports. It facilitates the reporting, correlating, and assets and reports. It facilitates the reporting, correlating, and
fusing of asset information within and between organizations. ARF is fusing of asset information within and between organizations. ARF is
vendor and technology neutral, flexible, and suited for a wide vendor and technology neutral, flexible, and suited for a wide
variety of reporting applications. variety of reporting applications.
There are four major sub-components of ARF: There are four major sub-components of ARF:
skipping to change at page 72, line 43 skipping to change at page 77, line 43
subsequently generated. subsequently generated.
o Relationship: The relationship component element links assets, o Relationship: The relationship component element links assets,
reports, and report requests together with well-defined reports, and report requests together with well-defined
relationships. Each relationship is defined as {subject} relationships. Each relationship is defined as {subject}
{predicate} {object}, where {subject} is the asset, report {predicate} {object}, where {subject} is the asset, report
request, or report of interest, {predicate} is the relationship request, or report of interest, {predicate} is the relationship
type being established, and {object} is one or more assets, report type being established, and {object} is one or more assets, report
requests, or reports. requests, or reports.
E.3.3.1.2.2. Relationship to Endpoint Characterization G.3.3.1.2.2. Relationship to Endpoint Characterization
For Endpoint Characterization, ARF can be used in multiple ways due For Endpoint Characterization, ARF can be used in multiple ways due
to its flexibility. ARF supports the use of the Asset Identification to its flexibility. ARF supports the use of the Asset Identification
specification (more in Appendix E.3.3.1.2.3) to embed the specification (more in Appendix G.3.3.1.2.3) to embed the
representation of one or more assets as well as relationships between representation of one or more assets as well as relationships between
those assets. It also allows the inclusion of report-requests, which those assets. It also allows the inclusion of report-requests, which
can provide details on what data was required for an assessment. can provide details on what data was required for an assessment.
ARF is agnostic to the data formats of the collected posture ARF is agnostic to the data formats of the collected posture
attributes and therefore can be used within the SACM Architecture to attributes and therefore can be used within the SACM Architecture to
provide Endpoint Characterization without dictating data formats for provide Endpoint Characterization without dictating data formats for
the encoding of posture attributes. The embedded Asset the encoding of posture attributes. The embedded Asset
Identification data model (see Appendix E.3.1.1.1) can be used to Identification data model (see Appendix G.3.1.1.1) can be used to
characterize one or more endpoints to allow targeting for collection, characterize one or more endpoints to allow targeting for collection,
evaluation, etc. Additionally, the report-request model can dictate evaluation, etc. Additionally, the report-request model can dictate
the type of reporting that has been requested, thereby providing the type of reporting that has been requested, thereby providing
context as to which endpoints the guidance applies. context as to which endpoints the guidance applies.
E.3.3.1.2.3. Asset Identification G.3.3.1.2.3. Asset Identification
Described earlier Described earlier
In the context of Endpoint Characterization, the Asset Identification In the context of Endpoint Characterization, the Asset Identification
data model could be used to encode information that identifies data model could be used to encode information that identifies
specific endpoints and/or classes of endpoints to which a particular specific endpoints and/or classes of endpoints to which a particular
assessment is relevant. The flexibility in the Asset Identification assessment is relevant. The flexibility in the Asset Identification
specification allows usage of various endpoint identifiers as defined specification allows usage of various endpoint identifiers as defined
by the SACM engineering work. by the SACM engineering work.
As stated in Appendix E.3.3.1.2.3, the Asset Identification As stated in Appendix G.3.3.1.2.3, the Asset Identification
specification is included within the Asset Reporting Framework (ARF) specification is included within the Asset Reporting Framework (ARF)
and therefore can be used in concert with that specification as well. and therefore can be used in concert with that specification as well.
E.3.3.1.3. The CPE Applicability Language G.3.3.1.3. The CPE Applicability Language
CPE described earlier CPE described earlier
Applicability in CPE is defined as an XML language [NISTIR-7698] for Applicability in CPE is defined as an XML language [NISTIR-7698] for
using CPE names to create applicability statements using logical using CPE names to create applicability statements using logical
expressions. These expressions can be used to applicability expressions. These expressions can be used to applicability
statements that can drive decisions about assets, whether or not to statements that can drive decisions about assets, whether or not to
do things like collect data, report data, and execute policy do things like collect data, report data, and execute policy
compliance checks. compliance checks.
skipping to change at page 74, line 8 skipping to change at page 79, line 8
This will allow use of SWID, CPE Names, or other identifiers to be This will allow use of SWID, CPE Names, or other identifiers to be
used, perhaps supported by an IANA registry of identifier types. used, perhaps supported by an IANA registry of identifier types.
The other key aspect that should be evolved is the ability to make The other key aspect that should be evolved is the ability to make
use of the Applicability Language against a centralized repository of use of the Applicability Language against a centralized repository of
collected posture attributes. The language should be able to make collected posture attributes. The language should be able to make
applicability statements against previously collected posture applicability statements against previously collected posture
attributes, such that an enterprise can quickly query the correct set attributes, such that an enterprise can quickly query the correct set
of applicable endpoints in an automated and scalable manner. of applicable endpoints in an automated and scalable manner.
E.3.4. Posture Attribute Expression G.3.4. Posture Attribute Expression
Discuss the catalog concept. Listing of things that can be chosen Discuss the catalog concept. Listing of things that can be chosen
from. Things we can know about. Vendors define catalogs. Ways for from. Things we can know about. Vendors define catalogs. Ways for
users to get vendor-provided catalogs. users to get vendor-provided catalogs.
To support the collection of posture attributes, there needs to be a To support the collection of posture attributes, there needs to be a
way for operators to identify and select from a set of platform- way for operators to identify and select from a set of platform-
specific attribute(s) to collect. The same identified attributes specific attribute(s) to collect. The same identified attributes
will also need to be identified post-collection to associate the will also need to be identified post-collection to associate the
actual value of that attribute pertaining to an endpoint as it was actual value of that attribute pertaining to an endpoint as it was
skipping to change at page 74, line 32 skipping to change at page 79, line 32
software to provide a listing, or catalog, of the available posture software to provide a listing, or catalog, of the available posture
attributes to operators that can be collected. Ideally, a federated attributes to operators that can be collected. Ideally, a federated
approach will be used to allow organizations to identify the location approach will be used to allow organizations to identify the location
for a repository containing catalogs of posture attributes provided for a repository containing catalogs of posture attributes provided
by authoritative primary source vendors. By querying these by authoritative primary source vendors. By querying these
repositories, operators will be able to acquire the appropriate repositories, operators will be able to acquire the appropriate
listings of available posture attributes for their deployed assets. listings of available posture attributes for their deployed assets.
One or more posture attribute expressions are needed to support these One or more posture attribute expressions are needed to support these
exchanges. exchanges.
E.3.4.1. Related Work G.3.4.1. Related Work
The ATOM Syndication Format [RFC4287] provides an extensible, The ATOM Syndication Format [RFC4287] provides an extensible,
flexible XML-based expression for organizing a collection of data flexible XML-based expression for organizing a collection of data
feeds consisting of entries. This standard can be used to express feeds consisting of entries. This standard can be used to express
one or more catalogs of posture attributes represented as data feeds. one or more catalogs of posture attributes represented as data feeds.
Groupings of posture attributes would be represented as entries. Groupings of posture attributes would be represented as entries.
These entries could be defined using the data models described in the These entries could be defined using the data models described in the
"Related Work" sections below. Additionally, this approach can also "Related Work" sections below. Additionally, this approach can also
be used more generally for guidance repositories allowing other forms be used more generally for guidance repositories allowing other forms
of security automation guidance to be exchanged using the same of security automation guidance to be exchanged using the same
format. format.
E.3.4.2. Platform Configuration Attributes G.3.4.2. Platform Configuration Attributes
A low-level, platform-dependent posture attribute as determined by A low-level, platform-dependent posture attribute as determined by
the authoritative primary source vendor. Collection guidance will be the authoritative primary source vendor. Collection guidance will be
derived from catalogs of platform specific posture attributes. derived from catalogs of platform specific posture attributes.
For example, a primary source vendor would create a platform-specific For example, a primary source vendor would create a platform-specific
posture attribute that best models the posture attribute data for posture attribute that best models the posture attribute data for
their platform. their platform.
E.3.4.2.1. Related Work G.3.4.2.1. Related Work
E.3.4.2.1.1. Open Vulnerability and Assessment Language G.3.4.2.1.1. Open Vulnerability and Assessment Language
A general overview of OVAL was provided previously in A general overview of OVAL was provided previously in
Appendix E.3.2.1.1.2.1. The OVAL System Characteristics platform Appendix G.3.2.1.1.2.1. The OVAL System Characteristics platform
extension models provide a catalog of the posture attributes that can extension models provide a catalog of the posture attributes that can
be collected from an endpoint. In OVAL these posture attributes are be collected from an endpoint. In OVAL these posture attributes are
further grouped into logical constructs called OVAL Items. For further grouped into logical constructs called OVAL Items. For
example, the passwordpolicy_item that is part of the Windows platform example, the passwordpolicy_item that is part of the Windows platform
extension groups together all the posture attributes related to extension groups together all the posture attributes related to
passwords for an endpoint running Windows (e.g. maximum password age, passwords for an endpoint running Windows (e.g. maximum password age,
minimum password length, password complexity, etc.). The various minimum password length, password complexity, etc.). The various
OVAL Items defined in the OVAL System Characteristics may serve as a OVAL Items defined in the OVAL System Characteristics may serve as a
good starting for the types of posture attribute data that needs to good starting for the types of posture attribute data that needs to
be collected from endpoints. be collected from endpoints.
OVAL platform extension models may be shared using the ATOM OVAL platform extension models may be shared using the ATOM
Syndication Format. Syndication Format.
E.3.4.2.1.2. Network Configuration Protocol and YANG Data Modeling G.3.4.2.1.2. Network Configuration Protocol and YANG Data Modeling
Language Language
The Network Configuration Protocol (NETCONF) [RFC6241] defines a The Network Configuration Protocol (NETCONF) [RFC6241] defines a
mechanism for managing and retrieving posture attribute data from mechanism for managing and retrieving posture attribute data from
network infrastructure endpoints. The posture attribute data that network infrastructure endpoints. The posture attribute data that
can be collected from a network infrastructure endpoint is highly can be collected from a network infrastructure endpoint is highly
extensible and can defined using the YANG modeling language extensible and can defined using the YANG modeling language
[RFC6020]. Models exist for common datatypes, interfaces, and [RFC6020]. Models exist for common datatypes, interfaces, and
routing subsystem information among other subjects. The YANG routing subsystem information among other subjects. The YANG
modeling language may be useful in providing an extensible framework modeling language may be useful in providing an extensible framework
for the SACM community to define one or more catalogs of posture for the SACM community to define one or more catalogs of posture
attribute data that can be collected from network infrastructure attribute data that can be collected from network infrastructure
endpoints. endpoints.
Custom YANG modules may also be shared using the ATOM Syndication Custom YANG modules may also be shared using the ATOM Syndication
Format. Format.
E.3.4.2.1.3. Simple Network Management Protocol and Management G.3.4.2.1.3. Simple Network Management Protocol and Management
Information Base Entry Information Base Entry
The Simple Network Protocol (SNMP) [RFC3411] defines a protocol for The Simple Network Protocol (SNMP) [RFC3411] defines a protocol for
managing and retrieving posture attribute data from endpoints on a managing and retrieving posture attribute data from endpoints on a
network . The posture attribute data that can be collected of an network . The posture attribute data that can be collected of an
endpoint and retrieved by SNMP is defined by the Management endpoint and retrieved by SNMP is defined by the Management
Information Base (MIB) [RFC3418] which is hierarchical collection of Information Base (MIB) [RFC3418] which is hierarchical collection of
information that is referenced using Object Identifiers . Given this, information that is referenced using Object Identifiers . Given this,
MIBs may provide an extensible way for the SACM community to define a MIBs may provide an extensible way for the SACM community to define a
catalog of posture attribute data that can be collected off of catalog of posture attribute data that can be collected off of
endpoints using SNMP. endpoints using SNMP.
MIBs may be shared using the ATOM Syndication Format. MIBs may be shared using the ATOM Syndication Format.
E.3.5. Actual Value Representation G.3.5. Actual Value Representation
Discuss instance concept. Discuss instance concept.
The actual value of a posture attribute is collected or published The actual value of a posture attribute is collected or published
from an endpoint. The identifiers discussed previously provide names from an endpoint. The identifiers discussed previously provide names
for the posture attributes (i.e., software or configuration item) for the posture attributes (i.e., software or configuration item)
that can be the subject of an assessment. The information items that can be the subject of an assessment. The information items
listed below are the actual values collected during the assessment listed below are the actual values collected during the assessment
and are all associated with a specific endpoint. and are all associated with a specific endpoint.
E.3.5.1. Software Inventory G.3.5.1. Software Inventory
A software inventory is a list of software identifiers (or content) A software inventory is a list of software identifiers (or content)
associated with a specific endpoint. Software inventories are associated with a specific endpoint. Software inventories are
maintained in some organized fashion so that entities can interact maintained in some organized fashion so that entities can interact
with it. Just having software publish identifiers onto an endpoint with it. Just having software publish identifiers onto an endpoint
is not enough, there needs to be an organized listing of all those is not enough, there needs to be an organized listing of all those
identifiers associated with that endpoint. identifiers associated with that endpoint.
E.3.5.1.1. Related Work G.3.5.1.1. Related Work
E.3.5.1.1.1. Asset Summary Reporting G.3.5.1.1.1. Asset Summary Reporting
The Asset Summary Reporting (ASR) specification [NISTIR-7848] The Asset Summary Reporting (ASR) specification [NISTIR-7848]
provides a format for capturing summary information about one or more provides a format for capturing summary information about one or more
assets. Specifically, it provides the ability to express a assets. Specifically, it provides the ability to express a
collection of records from some defined data source and map them to collection of records from some defined data source and map them to
some set of assets. As a result, this specification may be useful some set of assets. As a result, this specification may be useful
for capturing the software installed on an endpoint, its relevant for capturing the software installed on an endpoint, its relevant
attributes, and associating it with a particular endpoint. attributes, and associating it with a particular endpoint.
E.3.5.1.1.2. Software Identification Tags G.3.5.1.1.2. Software Identification Tags
SWID tag were previously introduced in Appendix E.3.1.3.1.2. As SWID tag were previously introduced in Appendix G.3.1.3.1.2. As
stated before, SWID tags are ideally deployed to an endpoint during stated before, SWID tags are ideally deployed to an endpoint during
software installation. In the less ideal case, they may also be software installation. In the less ideal case, they may also be
generated based on information retrieved from a proprietary software generated based on information retrieved from a proprietary software
installation data store. At minimum, SWID tag must contain an installation data store. At minimum, SWID tag must contain an
identifier for each unit of installed software. Given this, SWID identifier for each unit of installed software. Given this, SWID
tags may be a viable way for SACM to express detailed information tags may be a viable way for SACM to express detailed information
about the software installed on an endpoint. about the software installed on an endpoint.
E.3.5.2. Collected Platform Configuration Posture Attributes G.3.5.2. Collected Platform Configuration Posture Attributes
Configurations associated with a software instance associated with an Configurations associated with a software instance associated with an
endpoint endpoint
A list of the configuration posture attributes associated with the A list of the configuration posture attributes associated with the
actual values collected from the endpoint during the assessment as actual values collected from the endpoint during the assessment as
required/expressed by any related guidance. Additionally, each required/expressed by any related guidance. Additionally, each
configuration posture attribute is associated with the installed configuration posture attribute is associated with the installed
software instance it pertains to. software instance it pertains to.
E.3.5.2.1. Related Work G.3.5.2.1. Related Work
E.3.5.2.1.1. Open Vulnerability and Assessment Language G.3.5.2.1.1. Open Vulnerability and Assessment Language
A general overview of OVAL was provided previously in A general overview of OVAL was provided previously in
Appendix E.3.2.1.1.2.1. As mentioned earlier, the OVAL System Appendix G.3.2.1.1.2.1. As mentioned earlier, the OVAL System
Characteristics platform extensions provide a catalog of the posture Characteristics platform extensions provide a catalog of the posture
attributes that can be collected and assessed in the form of OVAL attributes that can be collected and assessed in the form of OVAL
Items. These OVAL Items also serve as a model for representing Items. These OVAL Items also serve as a model for representing
posture attribute data and associated values that are collected off posture attribute data and associated values that are collected off
an endpoint. Furthermore, the OVAL System Characteristics model an endpoint. Furthermore, the OVAL System Characteristics model
provides a system_info construct that captures information that provides a system_info construct that captures information that
identifies and characterizes the endpoint from which the posture identifies and characterizes the endpoint from which the posture
attribute data was collected. Specifically, it includes operating attribute data was collected. Specifically, it includes operating
system name, operating system version, endpoint architecture, system name, operating system version, endpoint architecture,
hostname, network interfaces, and an extensible construct to support hostname, network interfaces, and an extensible construct to support
arbitrary additional information that may be useful in identifying arbitrary additional information that may be useful in identifying
the endpoint in an enterprise such as information capture in Asset the endpoint in an enterprise such as information capture in Asset
Identification constructs. The OVAL System Characteristics model Identification constructs. The OVAL System Characteristics model
could serve as a useful starting point for representing posture could serve as a useful starting point for representing posture
attribute data collected from an endpoint although it may need to attribute data collected from an endpoint although it may need to
undergo some changes to satisfy the needs of the SACM community. undergo some changes to satisfy the needs of the SACM community.
E.3.5.2.1.2. NETCONF-Based Collection G.3.5.2.1.2. NETCONF-Based Collection
Introduced earlier in Appendix E.3.4.2.1.2, NETCONF defines a Introduced earlier in Appendix G.3.4.2.1.2, NETCONF defines a
protocol for managing and retrieving posture attribute data from protocol for managing and retrieving posture attribute data from
network infrastructure endpoints. NETCONF provides the <get-config> network infrastructure endpoints. NETCONF provides the <get-config>
and <get> operations to retrieve the configuration data, and and <get> operations to retrieve the configuration data, and
configuration data and state data respectively from a network configuration data and state data respectively from a network
infrastructure endpoint. Upon successful completion of these infrastructure endpoint. Upon successful completion of these
operations, the current posture attribute data of the network operations, the current posture attribute data of the network
infrastructure endpoint will be made available. NETCONF also infrastructure endpoint will be made available. NETCONF also
provides a variety of filtering mechanisms (XPath, subtree, content provides a variety of filtering mechanisms (XPath, subtree, content
matching, etc.) to trim down the posture attribute data that is matching, etc.) to trim down the posture attribute data that is
collected from the endpoint. Given that NETCONF is widely adopted by collected from the endpoint. Given that NETCONF is widely adopted by
skipping to change at page 78, line 22 skipping to change at page 83, line 22
proposal to extend the OVAL Language to support the assessment of proposal to extend the OVAL Language to support the assessment of
NETCONF configuration data NETCONF configuration data
<https://github.com/OVALProject/Sandbox/blob/master/x-netconf- <https://github.com/OVALProject/Sandbox/blob/master/x-netconf-
definitions-schema.xsd>. The proposal leverages XPath to extract the definitions-schema.xsd>. The proposal leverages XPath to extract the
posture attribute data of interest from the XML data returned by posture attribute data of interest from the XML data returned by
NETCONF. The collected posture attribute data can then be evaluated NETCONF. The collected posture attribute data can then be evaluated
using OVAL Definitions and the results of the evaluation can be using OVAL Definitions and the results of the evaluation can be
expressed as OVAL Results. While this proposal is not currently part expressed as OVAL Results. While this proposal is not currently part
of the OVAL Language, it may be worth considering. of the OVAL Language, it may be worth considering.
E.3.5.2.1.3. SNMP-Based Collection G.3.5.2.1.3. SNMP-Based Collection
The SNMP, previously introduced in Appendix E.3.4.2.1.3, defines a The SNMP, previously introduced in Appendix G.3.4.2.1.3, defines a
protocol for managing and retrieving posture attribute data from protocol for managing and retrieving posture attribute data from
endpoints on a network [RFC3411]. SNMP provides three protocol endpoints on a network [RFC3411]. SNMP provides three protocol
operations [RFC3416] (GetRequest, GetNextRequest, and GetBulkRequest) operations [RFC3416] (GetRequest, GetNextRequest, and GetBulkRequest)
for retrieving posture attribute data defined by MIB objects. Upon for retrieving posture attribute data defined by MIB objects. Upon
successful completion of these operations, the requested posture successful completion of these operations, the requested posture
attribute data of the endpoint will be made available to the attribute data of the endpoint will be made available to the
requesting application. Given that SNMP is widely adopted by requesting application. Given that SNMP is widely adopted by
vendors, and the MIBs that define posture attribute data on an vendors, and the MIBs that define posture attribute data on an
endpoint are highly extensible, it may useful to consider this endpoint are highly extensible, it may useful to consider this
protocol as a standardized mechanism for collecting posture attribute protocol as a standardized mechanism for collecting posture attribute
data from endpoints in an enterprise. data from endpoints in an enterprise.
E.3.6. Evaluation Guidance G.3.6. Evaluation Guidance
E.3.6.1. Configuration Evaluation Guidance G.3.6.1. Configuration Evaluation Guidance
The evaluation guidance is applied by evaluators during posture The evaluation guidance is applied by evaluators during posture
assessment of an endpoint. This guidance must be able to reference assessment of an endpoint. This guidance must be able to reference
or be associated with the following previously defined information or be associated with the following previously defined information
elements: elements:
o configuration item identifiers, o configuration item identifiers,
o platform configuration identifiers, and o platform configuration identifiers, and
o collected Platform Configuration Posture Attributes. o collected Platform Configuration Posture Attributes.
E.3.6.1.1. Related Work G.3.6.1.1. Related Work
E.3.6.1.1.1. Open Vulnerability and Assessment Language G.3.6.1.1.1. Open Vulnerability and Assessment Language
A general overview of OVAL was provided previously in A general overview of OVAL was provided previously in
Appendix E.3.2.1.1.2.1. The OVAL Definitions model provides an Appendix G.3.2.1.1.2.1. The OVAL Definitions model provides an
extensible framework for making assertions about the state of posture extensible framework for making assertions about the state of posture
attribute data collected from an endpoint. Guidance written against attribute data collected from an endpoint. Guidance written against
this model consists of one or more OVAL Tests, which can be logically this model consists of one or more OVAL Tests, which can be logically
combined, where each OVAL Test defines what posture attributes should combined, where each OVAL Test defines what posture attributes should
be collected from an endpoint (as OVAL Objects) and optionally be collected from an endpoint (as OVAL Objects) and optionally
defines the expected state of the posture attributes (as OVAL defines the expected state of the posture attributes (as OVAL
States). While the OVAL Definitions model may be a useful starting States). While the OVAL Definitions model may be a useful starting
point for evaluation guidance, it will likely require some changes to point for evaluation guidance, it will likely require some changes to
decouple collection and evaluation concepts to satisfy the needs of decouple collection and evaluation concepts to satisfy the needs of
the SACM community. the SACM community.
E.3.6.1.1.2. XCCDF Rule G.3.6.1.1.2. XCCDF Rule
A general description of XCCDF was provided in Appendix E.3.3.1.1.1. A general description of XCCDF was provided in Appendix G.3.3.1.1.1.
As noted there, an XCCDF document represents a checklist of items As noted there, an XCCDF document represents a checklist of items
against which a given endpoint's state is compared and evaluated. An against which a given endpoint's state is compared and evaluated. An
XCCDF Rule represents one assessed item in this checklist. A Rule XCCDF Rule represents one assessed item in this checklist. A Rule
contains both a prose description of the assessed item (either for contains both a prose description of the assessed item (either for
presentation to the user in a tool's user interface, or for rendering presentation to the user in a tool's user interface, or for rendering
into a prose checklist for human consumption) and can also contain into a prose checklist for human consumption) and can also contain
instructions to support automated evaluation of the assessed item, if instructions to support automated evaluation of the assessed item, if
such automated assessment is possible. Automated assessment such automated assessment is possible. Automated assessment
instructions can be provided either within the XCCDF Rule itself, or instructions can be provided either within the XCCDF Rule itself, or
by providing a reference to instructions expressed in other by providing a reference to instructions expressed in other
skipping to change at page 80, line 9 skipping to change at page 85, line 9
environments (providing a common baseline for configuration of the environments (providing a common baseline for configuration of the
given operating system) and thus be common to the checking given operating system) and thus be common to the checking
instructions for both types of endpoints. XCCDF supports this by instructions for both types of endpoints. XCCDF supports this by
allowing a single checklist to be defined, but then tailored to the allowing a single checklist to be defined, but then tailored to the
needs of the assessed endpoint. In the previous example, some Rules needs of the assessed endpoint. In the previous example, some Rules
that apply only to the DMZ endpoint would be disabled during the that apply only to the DMZ endpoint would be disabled during the
assessment of an internal endpoint and would not be exercised during assessment of an internal endpoint and would not be exercised during
the assessment or count towards the assessment results. To the assessment or count towards the assessment results. To
accomplish this, XCCDF uses the CPE Applicability Language. By accomplish this, XCCDF uses the CPE Applicability Language. By
enhancing this applicability language to support other aspects of enhancing this applicability language to support other aspects of
endpoint characterization (see Appendix E.3.3.1.3), XCCDF will also endpoint characterization (see Appendix G.3.3.1.3), XCCDF will also
benefit from these enhancements. benefit from these enhancements.
In addition, XCCDF Rules also support parameterization, allowing In addition, XCCDF Rules also support parameterization, allowing
customization of the expected value for a given check item. For customization of the expected value for a given check item. For
example, the DMZ endpoint might require a password of at least 12 example, the DMZ endpoint might require a password of at least 12
characters, while an internal endpoint may only need 8 or more characters, while an internal endpoint may only need 8 or more
characters in its password. By employing parameterization of the characters in its password. By employing parameterization of the
XCCDF Rule, the same Rule can be used when assessing either type of XCCDF Rule, the same Rule can be used when assessing either type of
endpoint, and simply be provided with a different target parameter endpoint, and simply be provided with a different target parameter
each time to reflect the different role-based requirements. Sets of each time to reflect the different role-based requirements. Sets of
customizations can be stored within the XCCDF document itself: XCCDF customizations can be stored within the XCCDF document itself: XCCDF
Values store parameters values that can be used in tailoring, while Values store parameters values that can be used in tailoring, while
XCCDF Profiles store sets of tailoring instructions, including XCCDF Profiles store sets of tailoring instructions, including
selection of certain Values as parameters and the enabling and selection of certain Values as parameters and the enabling and
disabling of certain Rules. The tailoring capabilities supported by disabling of certain Rules. The tailoring capabilities supported by
XCCDF allow a single XCCDF document to encapsulate configuration XCCDF allow a single XCCDF document to encapsulate configuration
evaluation guidance that applies to a broad range of endpoint roles. evaluation guidance that applies to a broad range of endpoint roles.
E.3.7. Evaluation Result Reporting G.3.7. Evaluation Result Reporting
E.3.7.1. Configuration Evaluation Results G.3.7.1. Configuration Evaluation Results
The evaluation guidance applied during posture assessment of an The evaluation guidance applied during posture assessment of an
endpoint to customize the behavior of evaluators. Guidance can be endpoint to customize the behavior of evaluators. Guidance can be
used to define specific result output formats or to select the level- used to define specific result output formats or to select the level-
of-detail for the generated results. This guidance must be able to of-detail for the generated results. This guidance must be able to
reference or be associated with the following previously defined reference or be associated with the following previously defined
information elements: information elements:
o configuration item identifiers, o configuration item identifiers,
o platform configuration identifiers, and o platform configuration identifiers, and
o collected Platform Configuration Posture Attributes. o collected Platform Configuration Posture Attributes.
E.3.7.1.1. Related Work G.3.7.1.1. Related Work
E.3.7.1.1.1. XCCDF TestResults G.3.7.1.1.1. XCCDF TestResults
A general description of the eXtensible Configuration Checklist A general description of the eXtensible Configuration Checklist
Description Format (XCCDF) was provided in section Description Format (XCCDF) was provided in section
Appendix E.3.3.1.1.1. The XCCDF TestResult structure captures the Appendix G.3.3.1.1.1. The XCCDF TestResult structure captures the
outcome of assessing a single endpoint against the assessed items outcome of assessing a single endpoint against the assessed items
(i.e., XCCDF Rules) contained in an XCCDF instance document. XCCDF (i.e., XCCDF Rules) contained in an XCCDF instance document. XCCDF
TestResults capture a number of important pieces of information about TestResults capture a number of important pieces of information about
the assessment including: the assessment including:
o The identity of the assessed endpoint. See Appendix E.3.3.1.1.2 o The identity of the assessed endpoint. See Appendix G.3.3.1.1.2
for more about XCCDF structures used for endpoint identification. for more about XCCDF structures used for endpoint identification.
o Any tailoring of the checklist that might have been employed. See o Any tailoring of the checklist that might have been employed. See
Appendix E.3.6.1.1.2 for more on how XCCDF supports tailoring. Appendix G.3.6.1.1.2 for more on how XCCDF supports tailoring.
o The individual results of the assessment of each enabled XCCDF o The individual results of the assessment of each enabled XCCDF
Rule in the checklist. See Appendix E.3.6.1.1.2 for more on XCCDF Rule in the checklist. See Appendix G.3.6.1.1.2 for more on XCCDF
Rules. Rules.
The individual results for a given XCCDF Rule capture only whether The individual results for a given XCCDF Rule capture only whether
the rule "passed", "failed", or experienced some exceptional the rule "passed", "failed", or experienced some exceptional
condition, such as if an error was encountered during assessment. condition, such as if an error was encountered during assessment.
XCCDF 1.2 Rule results do not capture the actual state of the XCCDF 1.2 Rule results do not capture the actual state of the
endpoint. For example, an XCCDF Rule result might indicate that an endpoint. For example, an XCCDF Rule result might indicate that an
endpoint failed to pass requirement that passwords be of a length endpoint failed to pass requirement that passwords be of a length
greater than or equal to 8, but it would not capture that the greater than or equal to 8, but it would not capture that the
endpoint was, in fact, only requiring passwords of 4 or more endpoint was, in fact, only requiring passwords of 4 or more
skipping to change at page 81, line 39 skipping to change at page 86, line 39
OVAL Definition to effect the Rule's evaluation, then the actual OVAL Definition to effect the Rule's evaluation, then the actual
endpoint state may be captured in the corresponding OVAL System endpoint state may be captured in the corresponding OVAL System
Characteristics file. Characteristics file.
The XCCDF TestResult structure does provide a useful structure for The XCCDF TestResult structure does provide a useful structure for
understanding the overall assessment that was conducted and the understanding the overall assessment that was conducted and the
results thereof. The ability to quickly determine the Rules that are results thereof. The ability to quickly determine the Rules that are
not complied with on a given endpoint allow administrators to quickly not complied with on a given endpoint allow administrators to quickly
identify where remediation needs to occur. identify where remediation needs to occur.
E.3.7.1.1.2. Open Vulnerability and Assessment Language G.3.7.1.1.2. Open Vulnerability and Assessment Language
A general overview of OVAL was provided previously in A general overview of OVAL was provided previously in
Appendix E.3.2.1.1.2.1. OVAL Results provides a model for expressing Appendix G.3.2.1.1.2.1. OVAL Results provides a model for expressing
the results of the assessment of the actual state of the posture the results of the assessment of the actual state of the posture
attribute values collected of an endpoint (represented as an OVAL attribute values collected of an endpoint (represented as an OVAL
System Characteristics document) against the expected posture System Characteristics document) against the expected posture
attribute values (defined in an OVAL Definitions document. Using attribute values (defined in an OVAL Definitions document. Using
OVAL Directives, the granularity of OVAL Results can also be OVAL Directives, the granularity of OVAL Results can also be
specified. The OVAL Results model may be useful in providing a specified. The OVAL Results model may be useful in providing a
format for capturing the results of an assessment. format for capturing the results of an assessment.
E.3.7.1.1.3. Asset Summary Reporting G.3.7.1.1.3. Asset Summary Reporting
A general overview of ASR was provided previously in A general overview of ASR was provided previously in
Appendix E.3.5.1.1.1. As ASR provides a way to report summary Appendix G.3.5.1.1.1. As ASR provides a way to report summary
information about assets, it can be used within the SACM Architecture information about assets, it can be used within the SACM Architecture
to provide a way to aggregate asset information for later use. It to provide a way to aggregate asset information for later use. It
makes no assertions about the data formats used by the assessment, makes no assertions about the data formats used by the assessment,
but rather provides an XML, record-based way to collect aggregated but rather provides an XML, record-based way to collect aggregated
information about assets. information about assets.
By using ASR to collect this summary information within the SACM By using ASR to collect this summary information within the SACM
Architecture, one can provide a way to encode the details used by Architecture, one can provide a way to encode the details used by
various reporting requirements, including user-definable reports. various reporting requirements, including user-definable reports.
E.3.7.1.1.4. ARF G.3.7.1.1.4. ARF
A general overview of ARF was provided previously in A general overview of ARF was provided previously in
Appendix E.3.3.1.2.1. Because ARF is data model agnostic, it can Appendix G.3.3.1.2.1. Because ARF is data model agnostic, it can
provide a flexible format for exchanging collection and evaluation provide a flexible format for exchanging collection and evaluation
information from endpoints. It additionally provides a way to encode information from endpoints. It additionally provides a way to encode
relationships between guidance and assets, and as such, can be used relationships between guidance and assets, and as such, can be used
to associate assessment results with guidance. This could be the to associate assessment results with guidance. This could be the
guidance that directly triggered the assessment, or for guidance that guidance that directly triggered the assessment, or for guidance that
is run against collected posture attributes located in a central is run against collected posture attributes located in a central
repository. repository.
E.3.7.2. Software Inventory Evaluation Results G.3.7.2. Software Inventory Evaluation Results
The results of an evaluation of an endpoint's software inventory The results of an evaluation of an endpoint's software inventory
against an authorized software list. The authorized software list against an authorized software list. The authorized software list
represents the policy for what software units are allowed, represents the policy for what software units are allowed,
prohibited, and mandatory for an endpoint. prohibited, and mandatory for an endpoint.
Appendix F. Graph Model Appendix H. Graph Model
TODO: Write text on how the information model above can be realized TODO: Write text on how the information model above can be realized
in this kind of graph model. in this kind of graph model.
The graph model describes how security information is structured, The graph model describes how security information is structured,
related, and accessed. Control of operations to supply and/or access related, and accessed. Control of operations to supply and/or access
the data is architecturally distinct from the structuring of the data the data is architecturally distinct from the structuring of the data
in the information model. Authorization may be applied by the in the information model. Authorization may be applied by the
Control Plane (as defined in the SACM Architecture Control Plane (as defined in the SACM Architecture
[I-D.ietf-sacm-architecture]) to requests for information from a [I-D.ietf-sacm-architecture]) to requests for information from a
skipping to change at page 83, line 32 skipping to change at page 88, line 32
o Captures and organizes evolving information and information o Captures and organizes evolving information and information
relationships for multiple data publishers relationships for multiple data publishers
o Provides access to the published information via publish, query, o Provides access to the published information via publish, query,
and subscribe operations and subscribe operations
o Leverages the knowledge and experience gained from incorporating o Leverages the knowledge and experience gained from incorporating
TNC IF-MAP into many disparate products that have to integrate and TNC IF-MAP into many disparate products that have to integrate and
share an information model in a scalable, extensible manner share an information model in a scalable, extensible manner
F.1. Background: Graph Models H.1. Background: Graph Models
Knowledge is often represented with graph-based formalisms. A common Knowledge is often represented with graph-based formalisms. A common
formalism defines a graph as follows: formalism defines a graph as follows:
o A set of *vertices* o A set of *vertices*
o A set of *edges*, each connecting two vertices (technically, an o A set of *edges*, each connecting two vertices (technically, an
edge is an ordered pair of vertices) edge is an ordered pair of vertices)
o A set of zero or more *properties* attached to each vertices and o A set of zero or more *properties* attached to each vertices and
edges. Each property consists of a type and a optionally a value. edges. Each property consists of a type and a optionally a value.
The type and the value are typically just strings The type and the value are typically just strings
+------------------+ +-----------------+ +------------------+ +-----------------+
| Id: 1 | parent-of |Id: 2 | | Id: 1 | parent-of |Id: 2 |
| Given name: Sue | --------------> |Given name: Ann | | Given name: Sue | --------------> |Given name: Ann |
| Family name: Wong| |Family name: Wong| | Family name: Wong| |Family name: Wong|
+------------------+ +-----------------+ +------------------+ +-----------------+
A VERTEX AN EDGE A VERTEX A VERTEX AN EDGE A VERTEX
Figure 9: Knowledge represented by a graph Figure 10: Knowledge represented by a graph
A pair of vertices connected by an edge is commonly referred to as a A pair of vertices connected by an edge is commonly referred to as a
triple that comprises subject, predicate and object. For example, triple that comprises subject, predicate and object. For example,
subject = Sue Wong, predicate = is-parent-of, object = Ann Wong. A subject = Sue Wong, predicate = is-parent-of, object = Ann Wong. A
common language that uses this representation is the Resource common language that uses this representation is the Resource
Description Framework (RDF) [W3C.REC-rdf11-concepts-20140225]. Description Framework (RDF) [W3C.REC-rdf11-concepts-20140225].
F.2. Graph Model Overview H.2. Graph Model Overview
The proposed model, influenced by IF-MAP, is a labeled graph: each The proposed model, influenced by IF-MAP, is a labeled graph: each
vertex has a label. vertex has a label.
A table of synonyms follows. A table of synonyms follows.
+----------------+-----------------+--------------------------------+ +----------------+-----------------+--------------------------------+
| Graph Theory | Graph Databases | IF-MAP and This Internet Draft | | Graph Theory | Graph Databases | IF-MAP and This Internet Draft |
+----------------+-----------------+--------------------------------+ +----------------+-----------------+--------------------------------+
| Vertex or Node | Node | - | | Vertex or Node | Node | - |
skipping to change at page 84, line 44 skipping to change at page 89, line 44
+----------------+-----------------+--------------------------------+ +----------------+-----------------+--------------------------------+
In this mode, identifiers and metadata have hierarchical structure. In this mode, identifiers and metadata have hierarchical structure.
The graphical aspect makes this model well suited to non-hierarchical The graphical aspect makes this model well suited to non-hierarchical
relationships, such as connectivity in a computer network. relationships, such as connectivity in a computer network.
Hierarchical properties allow this model to accommodate structures Hierarchical properties allow this model to accommodate structures
such as YANG [RFC6020] data models. such as YANG [RFC6020] data models.
F.3. Identifiers H.3. Identifiers
Each identifier is an XML element. For extensibility, schemas use Each identifier is an XML element. For extensibility, schemas use
xsd:anyAttribute and such. xsd:anyAttribute and such.
Alternately, this model could be changed to use another hierarchical Alternately, this model could be changed to use another hierarchical
notation, such as JSON. notation, such as JSON.
Identifiers are unique: two different vertices cannot have equivalent Identifiers are unique: two different vertices cannot have equivalent
identifiers. identifiers.
skipping to change at page 85, line 24 skipping to change at page 90, line 24
to be standardized for SACM use cases. to be standardized for SACM use cases.
Any number of metadata items can be attached to an identifier. Any number of metadata items can be attached to an identifier.
Some identifiers, especially those relating to identity, address, and Some identifiers, especially those relating to identity, address, and
location, require the ability to specify an administrative domain location, require the ability to specify an administrative domain
(such as AD domain, L2 broadcast domain / L3 routing domain, or (such as AD domain, L2 broadcast domain / L3 routing domain, or
geographic domain) in order to differentiate between instances with geographic domain) in order to differentiate between instances with
the same name occurring in different realms. the same name occurring in different realms.
F.4. Links H.4. Links
A link can be thought of as an ordered pair of identifiers. A link can be thought of as an ordered pair of identifiers.
Any number of metadata items can be attached to a link. Any number of metadata items can be attached to a link.
F.5. Metadata H.5. Metadata
A metadata item is the basic unit of information, and is attached to A metadata item is the basic unit of information, and is attached to
an identifier or to a link. an identifier or to a link.
A given metadata item is an XML document. In IF-MAP metadata items A given metadata item is an XML document. In IF-MAP metadata items
are generally small. However, larger ones, such as YANG data models, are generally small. However, larger ones, such as YANG data models,
can also fit. For extensibility, the XML schemas of metadata items can also fit. For extensibility, the XML schemas of metadata items
use xsd:anyAttribute and such. use xsd:anyAttribute and such.
Alternately, this model could be changed to use another hierarchical Alternately, this model could be changed to use another hierarchical
skipping to change at page 86, line 5 skipping to change at page 91, line 5
of metadata types. If the metadata item is XML, the type is based on of metadata types. If the metadata item is XML, the type is based on
the XML schema. An example metadata type is the XML schema. An example metadata type is
http://www.trustedcomputinggroup.org/2010/IFMAP-METADATA/2#device- http://www.trustedcomputinggroup.org/2010/IFMAP-METADATA/2#device-
characteristic. characteristic.
TNC IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA] TNC IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA]
and TNC IF-MAP Metadata for ICS Security [TNC-IF-MAP-ICS-METADATA] and TNC IF-MAP Metadata for ICS Security [TNC-IF-MAP-ICS-METADATA]
define many pertinent metadata types. More will need to be define many pertinent metadata types. More will need to be
standardized for SACM use cases. standardized for SACM use cases.
F.6. Use for SACM H.6. Use for SACM
Many of the information elements can be represented as vertices, and Many of the information elements can be represented as vertices, and
many of the relationships can be represented as edges. many of the relationships can be represented as edges.
Identifiers are like database keys. For example, there would be Identifiers are like database keys. For example, there would be
identifiers for addresses, identities, unique endpoint identifiers, identifiers for addresses, identities, unique endpoint identifiers,
software component identifiers, and hardware component identifiers. software component identifiers, and hardware component identifiers.
The inventory of software instances and hardware instances within an The inventory of software instances and hardware instances within an
endpoint might be expressed using a single YANG description, as a endpoint might be expressed using a single YANG description, as a
single metadata item in the graph. Where to put Endpoint Attribute single metadata item in the graph. Where to put Endpoint Attribute
Assertions, Evaluation Results, and the like is an open question. Assertions, Evaluation Results, and the like is an open question.
F.7. Provenance H.7. Provenance
Provenance helps to protect the SACM ecosystem against a misled or Provenance helps to protect the SACM ecosystem against a misled or
malicious provider. malicious provider.
The provenance of a metadata item includes: The provenance of a metadata item includes:
o The time when the item was produced o The time when the item was produced
o The component that produced the item, including its software and o The component that produced the item, including its software and
version version
skipping to change at page 86, line 43 skipping to change at page 91, line 43
scan) scan)
How provenance should be expressed is an open question. For How provenance should be expressed is an open question. For
reference, in IF-MAP provenance of a metadata item is expressed reference, in IF-MAP provenance of a metadata item is expressed
within the metadata item [TNC-IF-MAP-NETSEC-METADATA]. For example, within the metadata item [TNC-IF-MAP-NETSEC-METADATA]. For example,
there is a top-level XML attribute called "timestamp". there is a top-level XML attribute called "timestamp".
It is critical that provenance be secure from tampering. How to It is critical that provenance be secure from tampering. How to
achieve that security is out of scope of this document. achieve that security is out of scope of this document.
F.8. Extensibility H.8. Extensibility
Anyone can define an identifier type or a metadata type, by creating Anyone can define an identifier type or a metadata type, by creating
an XML schema (or other specification). There is no need for a an XML schema (or other specification). There is no need for a
central authority. Some deployments may exercise administrative central authority. Some deployments may exercise administrative
control over the permitted identifier types and metadata types; control over the permitted identifier types and metadata types;
others may leave components free rein. others may leave components free rein.
A community of components can agree on and use new identifier and A community of components can agree on and use new identifier and
metadata types, if the administrators allow it. This allows rapid metadata types, if the administrators allow it. This allows rapid
innovation. Intermediate software that conveys graph changes from innovation. Intermediate software that conveys graph changes from
skipping to change at line 4064 skipping to change at page 93, line 11
USA USA
Email: cliffordk@pulsesecure.net Email: cliffordk@pulsesecure.net
Lisa Lorenzin Lisa Lorenzin
Pulse Secure, LLC Pulse Secure, LLC
2700 Zanker Road, Suite 200 2700 Zanker Road, Suite 200
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: llorenzin@pulsesecure.net Email: llorenzin@pulsesecure.net
Daniel Haynes
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA
Email: dhaynes@mitre.org
 End of changes. 274 change blocks. 
661 lines changed or deleted 902 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/