draft-ietf-sacm-information-model-01.txt   draft-ietf-sacm-information-model-02.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: August 24, 2015 DHS Expires: January 7, 2016 DHS
C. Kahn C. Kahn
L. Lorenzin L. Lorenzin
Pulse Secure, LLC Pulse Secure, LLC
February 20, 2015 July 6, 2015
SACM Information Model SACM Information Model
draft-ietf-sacm-information-model-01 draft-ietf-sacm-information-model-02
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 August 24, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 5 1.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 6
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Changes in Revision 02 . . . . . . . . . . . . . . . . . 7
2.1. Mapping to SACM Use Cases . . . . . . . . . . . . . . . . 7 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Mapping to SACM Use Cases . . . . . . . . . . . . . . . . 8
2.2. Referring to an Endpoint . . . . . . . . . . . . . . . . 8 2.2. Referring to an Endpoint . . . . . . . . . . . . . . . . 8
2.3. Dealing with Uncertainty . . . . . . . . . . . . . . . . 8 2.3. Dealing with Uncertainty . . . . . . . . . . . . . . . . 9
3. Conventions used in this document . . . . . . . . . . . . . . 9 3. Conventions used in this document . . . . . . . . . . . . . . 9
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 9 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 10
4. Elements of the SACM Information Model . . . . . . . . . . . 9 4. Elements of the SACM Information Model . . . . . . . . . . . 10
4.1. Software Component . . . . . . . . . . . . . . . . . . . 12 4.1. Identifying Attributes . . . . . . . . . . . . . . . . . 12
4.2. Software Instance . . . . . . . . . . . . . . . . . . . . 13 4.1.1. How Known . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Hardware Component . . . . . . . . . . . . . . . . . . . 14 4.1.2. Whether to Include . . . . . . . . . . . . . . . . . 13
4.4. Hardware Instance . . . . . . . . . . . . . . . . . . . . 14 4.1.3. IP Address . . . . . . . . . . . . . . . . . . . . . 13
4.5. Network Interface . . . . . . . . . . . . . . . . . . . . 14 4.1.3.1. Range of Values . . . . . . . . . . . . . . . . . 13
4.6. Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3.2. Meaning . . . . . . . . . . . . . . . . . . . . . 14
4.7. Identity . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3.3. Relationships . . . . . . . . . . . . . . . . . . 14
4.8. Location . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3.4. Multiplicity . . . . . . . . . . . . . . . . . . 15
4.9. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.3.5. Stability . . . . . . . . . . . . . . . . . . . . 15
4.10. Endpoint Attribute Assertion . . . . . . . . . . . . . . 17 4.1.3.6. Accuracy . . . . . . . . . . . . . . . . . . . . 15
4.10.1. Form and Precise Meaning . . . . . . . . . . . . . . 17 4.1.3.7. Data Model Requirements . . . . . . . . . . . . . 15
4.11. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 18 4.1.4. MAC Address . . . . . . . . . . . . . . . . . . . . . 16
4.11.1. Posture Attribute . . . . . . . . . . . . . . . . . 19 4.1.5. Hardware Serial Number . . . . . . . . . . . . . . . 16
4.11.2. Identifying Attributes . . . . . . . . . . . . . . . 19 4.1.5.1. Range of Values . . . . . . . . . . . . . . . . . 16
4.11.3. Evaluation Result . . . . . . . . . . . . . . . . . 21 4.1.5.2. Meaning . . . . . . . . . . . . . . . . . . . . . 16
4.12. Report . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.5.3. Multiplicity . . . . . . . . . . . . . . . . . . 16
4.13. SACM Component . . . . . . . . . . . . . . . . . . . . . 22 4.1.5.4. Stability . . . . . . . . . . . . . . . . . . . . 16
4.13.1. External Attribute Collector . . . . . . . . . . . . 22 4.1.5.5. Accuracy . . . . . . . . . . . . . . . . . . . . 16
4.13.2. Evaluator . . . . . . . . . . . . . . . . . . . . . 22 4.1.5.6. Data Model Requirements . . . . . . . . . . . . . 16
4.13.3. Report Generator . . . . . . . . . . . . . . . . . . 23 4.1.6. Certificate . . . . . . . . . . . . . . . . . . . . . 16
4.14. Organization? . . . . . . . . . . . . . . . . . . . . . . 23 4.1.6.1. Range of values . . . . . . . . . . . . . . . . . 16
4.15. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.6.2. Meaning . . . . . . . . . . . . . . . . . . . . . 17
4.15.1. Internal Collection Guidance . . . . . . . . . . . . 24 4.1.6.3. Multiplicity . . . . . . . . . . . . . . . . . . 17
4.15.2. External Collection Guidance . . . . . . . . . . . . 24 4.1.6.4. Stability . . . . . . . . . . . . . . . . . . . . 17
4.15.3. Evaluation Guidance . . . . . . . . . . . . . . . . 24 4.1.6.5. Accuracy . . . . . . . . . . . . . . . . . . . . 17
4.15.4. Retention Guidance . . . . . . . . . . . . . . . . . 24 4.1.6.6. Data model requirements . . . . . . . . . . . . . 17
4.15.5. Reporting Guidance . . . . . . . . . . . . . . . . . 24 4.1.7. Public Key . . . . . . . . . . . . . . . . . . . . . 17
4.16. Provenance of Information . . . . . . . . . . . . . . . . 24 4.1.8. Username? . . . . . . . . . . . . . . . . . . . . . . 18
4.17. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.9. Tool-Specific Identifier . . . . . . . . . . . . . . 18
4.17.1. Endpoint Identity . . . . . . . . . . . . . . . . . 25 4.1.10. Identification of Endpoints where SACM Components
4.17.2. Software Component . . . . . . . . . . . . . . . . . 25 Reside . . . . . . . . . . . . . . . . . . . . . . . 18
4.17.2.1. Unique Software Identifier . . . . . . . . . . . 26 4.1.11. Security Considerations . . . . . . . . . . . . . . . 18
4.18. User . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2. Software Component . . . . . . . . . . . . . . . . . . . 18
4.18.1. User Identity . . . . . . . . . . . . . . . . . . . 26 4.3. Software Instance . . . . . . . . . . . . . . . . . . . . 20
5. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 26 4.4. Hardware Component . . . . . . . . . . . . . . . . . . . 20
5.1. Graph Model for Detection of Posture Deviation . . . . . 27 4.5. Hardware Instance . . . . . . . . . . . . . . . . . . . . 20
5.1.1. Components . . . . . . . . . . . . . . . . . . . . . 27 4.6. Network Interface . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 27 4.7. Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 28 4.8. Identity . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.4. Relationships between Identifiers and Metadata . . . 29 4.9. Location . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 29 4.10. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 4.11. Endpoint Attribute Assertion . . . . . . . . . . . . . . 24
6.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 30 4.11.1. Form and Precise Meaning . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 4.11.2. Asserter . . . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 4.11.3. Example . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.11.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 31 4.11.5. Event . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 31 4.11.6. Difference between Attribute and Event . . . . . . . 26
Appendix A. Security Automation with TNC IF-MAP . . . . . . . . 37 4.12. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 26
A.1. What is Trusted Network Connect? . . . . . . . . . . . . 37 4.12.1. Unique Endpoint Identifier . . . . . . . . . . . . . 27
A.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 37 4.12.2. Posture Attribute . . . . . . . . . . . . . . . . . 27
A.3. What is the TNC Information Model? . . . . . . . . . . . 38 4.13. Evaluation Result . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Text for Possible Inclusion in the Terminology Draft 39 4.14. Report . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 39 4.15. SACM Component . . . . . . . . . . . . . . . . . . . . . 29
B.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 39 4.15.1. External Attribute Collector . . . . . . . . . . . . 29
B.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 39 4.15.2. Evaluator . . . . . . . . . . . . . . . . . . . . . 30
4.15.3. Report Generator . . . . . . . . . . . . . . . . . . 30
4.16. Organization? . . . . . . . . . . . . . . . . . . . . . . 30
4.17. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 31
4.17.1. Internal Collection Guidance . . . . . . . . . . . . 31
4.17.2. External Collection Guidance . . . . . . . . . . . . 31
4.17.3. Evaluation Guidance . . . . . . . . . . . . . . . . 31
4.17.4. Retention Guidance . . . . . . . . . . . . . . . . . 31
4.17.5. Reporting Guidance . . . . . . . . . . . . . . . . . 31
4.18. Provenance of Information . . . . . . . . . . . . . . . . 32
4.19. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 32
4.19.1. Endpoint Identity . . . . . . . . . . . . . . . . . 32
4.19.2. Software Component . . . . . . . . . . . . . . . . . 32
4.19.2.1. Unique Software Identifier . . . . . . . . . . . 33
4.20. User . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.20.1. User Identity . . . . . . . . . . . . . . . . . . . 34
5. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 34
5.1. Graph Model for Detection of Posture Deviation . . . . . 34
5.1.1. Components . . . . . . . . . . . . . . . . . . . . . 34
5.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 35
5.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 35
5.1.4. Relationships between Identifiers and Metadata . . . 36
5.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
6.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Security Automation with TNC IF-MAP . . . . . . . . 44
A.1. What is Trusted Network Connect? . . . . . . . . . . . . 44
A.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 45
A.3. What is the TNC Information Model? . . . . . . . . . . . 45
Appendix B. Text for Possible Inclusion in the Terminology Draft 46
B.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 46
B.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 46
B.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 47
Appendix C. Text for Possible Inclusion in the Architecture or Appendix C. Text for Possible Inclusion in the Architecture or
Use Cases . . . . . . . . . . . . . . . . . . . . . 40 Use Cases . . . . . . . . . . . . . . . . . . . . . 47
C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 40 C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 47
C.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 41 C.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 48
C.3. Architecture Assumptions . . . . . . . . . . . . . . . . 41 C.3. Architecture Assumptions . . . . . . . . . . . . . . . . 49
Appendix D. Text for Possible Inclusion in the Requirements Appendix D. Text for Possible Inclusion in the Requirements
Draft . . . . . . . . . . . . . . . . . . . . . . . 45 Draft . . . . . . . . . . . . . . . . . . . . . . . 52
D.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 45 D.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 52
D.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 45 D.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 52
Appendix E. Text With No Clear Home Yet . . . . . . . . . . . . 46 Appendix E. Text With No Clear Home Yet . . . . . . . . . . . . 53
E.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 46 E.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 53
E.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 46 E.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 53
E.2. From Information Needs to Information Elements . . . . . 47 E.2. From Information Needs to Information Elements . . . . . 54
E.3. Information Model Elements . . . . . . . . . . . . . . . 47 E.3. Information Model Elements . . . . . . . . . . . . . . . 54
E.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 49 E.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 56
E.3.1.2. Endpoint Identification . . . . . . . . . . . . . 51 E.3.1.2. Endpoint Identification . . . . . . . . . . . . . 58
E.3.1.3. Software Identification . . . . . . . . . . . . . 52 E.3.1.3. Software Identification . . . . . . . . . . . . . 59
E.3.1.4. Hardware Identification . . . . . . . . . . . . . 55 E.3.1.4. Hardware Identification . . . . . . . . . . . . . 62
E.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 55 E.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 62
E.3.2.1. Platform Configuration Item Identifier . . . . . 55 E.3.2.1. Platform Configuration Item Identifier . . . . . 62
E.3.2.2. Configuration Item Identifier . . . . . . . . . . 61 E.3.2.2. Configuration Item Identifier . . . . . . . . . . 68
E.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 63 E.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 70
E.3.3. Endpoint characterization . . . . . . . . . . . . . . 63 E.3.3. Endpoint characterization . . . . . . . . . . . . . . 70
E.3.4. Posture Attribute Expression . . . . . . . . . . . . 67 E.3.4. Posture Attribute Expression . . . . . . . . . . . . 74
E.3.4.2. Platform Configuration Attributes . . . . . . . . 67 E.3.4.2. Platform Configuration Attributes . . . . . . . . 74
E.3.5. Actual Value Representation . . . . . . . . . . . . . 69 E.3.5. Actual Value Representation . . . . . . . . . . . . . 76
E.3.5.1. Software Inventory . . . . . . . . . . . . . . . 69 E.3.5.1. Software Inventory . . . . . . . . . . . . . . . 76
E.3.5.2. Collected Platform Configuration Posture E.3.5.2. Collected Platform Configuration Posture
Attributes . . . . . . . . . . . . . . . . . . . 70 Attributes . . . . . . . . . . . . . . . . . . . 77
E.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 78
E.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 71 E.3.6.1. Configuration Evaluation Guidance . . . . . . . . 78
E.3.6.1. Configuration Evaluation Guidance . . . . . . . . 71 E.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 80
E.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 73 E.3.7.1. Configuration Evaluation Results . . . . . . . . 80
E.3.7.1. Configuration Evaluation Results . . . . . . . . 73 E.3.7.2. Software Inventory Evaluation Results . . . . . . 82
E.3.7.2. Software Inventory Evaluation Results . . . . . . 75 Appendix F. Graph Model . . . . . . . . . . . . . . . . . . . . 82
Appendix F. Graph Model . . . . . . . . . . . . . . . . . . . . 75 F.1. Background: Graph Models . . . . . . . . . . . . . . . . 83
F.1. Background: Graph Models . . . . . . . . . . . . . . . . 76 F.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 84
F.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 77 F.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 84
F.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 77 F.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 85
F.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 78 F.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 85
F.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 78 F.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 86
F.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 79 F.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 86
F.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 79 F.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 86
F.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
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 34 skipping to change at page 6, line 23
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. Changes in Revision 01
Added some proposed normative text.
For provenance:
o Added a class "Method"
o Added the produced-using relationship between an AVP and a method
o Added the produced-by relationship between a Guidance and a SACM
Component
o Added the hosted-by relationship between a SACM Component and an
Endpoint
asserted-by and summarized-by have been renamed to produced-by.
"User" is now "Account". If a user has different credentials, SACM
cannot know that they belong to the same user. But, per Kim W, many
organizations do have accounts that associate credentials.
The multiplicity of the based-on relationships has been corrected.
More relationships now have labels, per UML convention.
The diagram no longer has causal arrows. They had become redundant
and were nonstandard and clutter.
Renamed "credential" to "identity", following industry usage. A Renamed "credential" to "identity", following industry usage. A
credential includes proof, such as a key or password. A username or credential includes proof, such as a key or password. A username or
a distinguished name is called an "identity". a distinguished name is called an "identity".
Removed Session, because an endpoint's network activity is not SACM's Removed Session, because an endpoint's network activity is not SACM's
initial focus initial focus
Removed Authorization, for the same reason Removed Authorization, for the same reason
Added many-to-many relationship between Hardware Component and Added many-to-many relationship between Hardware Component and
skipping to change at page 6, line 39 skipping to change at page 7, line 5
Removed relationship between Network Interface and Account. The Removed relationship between Network Interface and Account. The
endpoint knows the identity it used to gain network access. The PDP endpoint knows the identity it used to gain network access. The PDP
also knows that. But they probably do not know the account. also knows that. But they probably do not know the account.
Added relationship between Network Interface and Identity. The Added relationship between Network Interface and Identity. The
endpoint and the PDP will typically know the identity. endpoint and the PDP will typically know the identity.
Made identity-to-account a many-to-one relationship. 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 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
skipping to change at page 8, line 33 skipping to change at page 9, line 9
o Internal posture attribute collectors are not present on all o Internal posture attribute collectors are not present on all
endpoints. They are not present on "dumb" devices such as endpoints. They are not present on "dumb" devices such as
Internet of Things (IoT) devices, or on Bring Your Own Device Internet of Things (IoT) devices, or on Bring Your Own Device
(BYOD) devices. In these cases, *no* observers have direct access (BYOD) devices. In these cases, *no* observers have direct access
to the unique endpoint identifier. to the unique endpoint identifier.
o An endpoint identifier is generally subject to cloning, when a o An endpoint identifier is generally subject to cloning, when a
system image is cloned. Then it is no longer unique. system image is cloned. Then it is no longer unique.
o Suppose the endpoint identifier is highly clone resistant -- such o Suppose the endpoint identifier is highly clone resistant -- such
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 2.3. Dealing with Uncertainty
With many information models, the information is considered certain. With many information models, the information is considered certain.
So it is OK to blur the difference between the representation and the
thing represented.
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
inferences against each other. They should be able to give weight if inferences against each other. They should be able to give weight if
an observation or inference is corroborated by more than one method. an observation or inference is corroborated by more than one method.
skipping to change at page 10, line 11 skipping to change at page 10, line 35
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 the the information model. Figure 1 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
1| |* | |___| |* | |___|
____________________| |_______| in> |_______| in>
| in> in>
.......|..............................................................
| |0..1 Figure 1: Model of an Endpoint
| |
| |* ISSUE (CEK): we agreed to remove location and account from the model,
| +-----+ +---------+___________________ did we not?
| | AVP |____________|Endpoint |* <based-on |
^| +-----+1..* 1|Attribute|________ | Figure 2 is the core of the information model. It represents the
hosted-by| *| |Assertion|* | | information elements and their relationships.
| | +---------+ | |
| |produced-using |* |* | *| +-----+ +---------+
| 1|V | |__________| +-------+ | AVP |____________|Endpoint |
| +--------+ | <based-on |Summary| +-----+1..* 1|Attribute|
| | Method | | +-------+ |Assertion|
| +--------+ |produced-by *| +---------+
|____________________ |V | |* +-------+
|* 1| | | |Summary|
+--------+1____________*+-----------+ | | +-------+
| | guides> | SACM |__________________________| |produced-by *|
|V |
1| |
+--------+ +-----------+ |
| | | SACM |__________________________|
|Guidance| | Component |1 <produced-by |Guidance| | Component |1 <produced-by
+--------+*____________1+-----------+ +--------+*____________1+-----------+
<produced-by <produced-by
------------------------------------------------------------- Figure 2: Information Elements
..... Above this line is the monitorable world
-------------------------------------------------------------
Figure 1: The Information Model Figure 3 is a potential alternative structure for assertions. It is
inspired by triple stores. See http://www.w3.org/TR/2014/REC-rdf11-
concepts-20140225/.
+-----+______________+---------+ +---------+
| AVP |1 <subject *|assertion|________________|predicate|
| |______________| |* predicate> 1+---------+
+-----+1 <object *+---------+
1^ |*
|_____________________|
<asserter
Figure 3: 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 - of some of the Need to be clear in the description that ???
relationships, will need some language and guidance to the interfaces
and relationships we expect to have happen, MUSTs and SHOULDs, as
well as explaining the extensibility that other relationships can
exist, show examples of how that can happen. Others that we haven't
thought of yet, might be added by another RFC or in another way
CEK: I suddenly wonder whether all of the relationships in the upper For some of the relationships, will need some language and guidance
right corner of the diagram are needed. At present, AVPs mostly to the interfaces and relationships we expect to have happen, MUSTs
mention instances of the classes in the upper half. The only and SHOULDs, as well as explaining the extensibility that other
relationship an endpoint attribute assertion expresses is that a set relationships can exist, show examples of how that can happen.
of AVPs are all true of some endpoint. We don't have a way to say Others that we haven't thought of yet, might be added by another RFC
that an address is bound to a particular interface. Such structures or in another way
*can* be modeled, using YANG, for example. But do we require that?
If we do, why? I do think we need to be able to relate a software
instance to the software component, and a hardware instance to the
hardware component.
The following subsections discuss the elements and relationships 4.1. Identifying Attributes
found in Figure 1.
4.1. Software Component Identifying attributes let a consumer identify an endpoint, for two
purposes:
o To tell whether two endpoint attribute assertions concern the same
endpoint (This is not simple, as Section 2.2 explains.)
o To respond to compliance measurements, for example by reporting,
remediating, and quarantining (SACM does not specify these
responses, but SACM exists to enable them.)
Out of scope of this section: *classifying* an endpoint so as to
apply appropriate collection guidance to it. We don't call this
"identification".
4.1.1. How Known
Each attribute-value pair or triple MUST be marked with how the
provider knows. There MUST be at least one marking. The possible
markings follow.
"Self" means that the endpoint furnished the information: it is
self-reported. "Self" does not (necessarily) mean that the
provider runs on the the monitored endpoint. Self-reported
information is generally subject to the Lying Endpoint Problem.
(TODO: citation)
"Authority" means that the provider got the information, directly
or indirectly, from an authority that assigned it. For example,
the producer got an IP-MAC association from a DHCP server (or was
itself the DHCP server).
"Observation" means that the provider got the information from
observations of network traffic. For example, the producer saw
the source address in an IP packet.
"Verification" means that the provider has verified the
information. For example:
* The provider does IP communication with the endpoint and knows
the IP address with which it communicates.
* The provider makes an SSH connection to the endpoint and knows
the endpoint's public key by virtue of authenticating it.
* The monitored endpoint is a virtual machine and the provider
knows by peeking into it.
TODO: Explain security considerations and how consumers are meant to
use these markings.
4.1.2. Whether to Include
When publishing an endpoint attribute assertion, the provider MUST
publish at least all common identifying AVPs that it knows through
verification. If the provider knows none through verification but it
knows at least one in another way, it MUST publish at least one. The
provider SHOULD publish all common identifying AVPs it knows.
4.1.3. IP Address
4.1.3.1. Range of Values
MUST be an IPv4 or IPv6 address, and optionally a scope string. MUST
NOT be a broadcast, multicast, or loopback address.
An IPv4 address MUST conform to [RFC0791], section 3.2.
An IPv6 address MUST conform to [RFC3587]. SHOULD NOT be a link-
local address.
Scope string: an administratively assigned string denoting the IP
routing domain. Implementations MUST support this. Administrators
may use it to avoid ambiguity, for example if network address
translation (NAT) is in use.
ISSUE (Jim Schaad): Scope strings are interesting. However does this
imply a potential need to create a new DHCP item so that it can be
sent out to a device for reporting back? Is there such a string
already?
(Cliff): Scope strings are like administrative-domain in IF-MAP. It
would solve many problems if DHCP servers could provide this string
to endpoints and to observers. I am not sure whether there is a
standard DHCP option that fills the bill or not. I am not sure how
easily application software can get the DHCP options from the
underlying OS. But this is worth exploring.
(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
network that is NATed on my machine. If those VMs reported [on
themselves] then the network configuring systems may not know about
that VM and there would not necessarily be a reasonable scope string
to report for it.
4.1.3.2. Meaning
Throughout the time interval of the AVP, the endpoint had the right
to use, or was communicating using, the specified IP address.
4.1.3.3. Relationships
A network profiler might know an endpoint's address and something
about the software running on the endpoint. The profiler might know
nothing else. So data models MUST support an endpoint attribute
assertion relating the IP address to a set of software components.
A data model MUST support the following relationships:
o An address is "bound to" a network interface.
o An address is considered "bound to" an endpoint just if the
address is "bound to" an interface that is "in" the endpoint.
o An address may be "in" one or more locations. (DELETE?)
4.1.3.4. Multiplicity
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,
largely because of Network Address Translation (NAT). Where
practical, a scope string SHOULD be included, to disambiguate.
In practice, an IP address can be used by only one endpoint in an IP
routing domain at a time.
4.1.3.5. Stability
The stability of IP address assignments varies widely. Some
assignments are persistent, some volatile. The time interval of the
AVP MUST NOT reach into the future, not even if (for example) the
DHCP lease is infinite.
4.1.3.6. Accuracy
For IP addresses that a provider knows by observation or
verification:
o Network Address Translation (NAT, RFC2663) is a pitfall.
o The provider MUST NOT include an IP address that the provider
knows to be a translated address.
o The provider SHOULD be configurable with a set of IP address
blocks to be excluded. Address blocks set aside for NAT devices
SHOULD be excluded, by administrators for example.
o ISSUE: In a later SACM version, it would be good to overcome this,
by publishing the association between the internal and external
address-port combinations.
For IP addresses that a provider knows by observation or
verification, IP address spoofing is a pitfall. Network
administrators SHOULD take countermeasures. Ingress filtering
(RFC3704) is one. DHCP snooping is another: many Network Access
Devices can confine endpoints to IP addresses assigned by authorized
DHCP servers.
4.1.3.7. Data Model Requirements
All SACM data models MUST support this entire subsection.
4.1.4. MAC Address
TODO
4.1.5. Hardware Serial Number
4.1.5.1. Range of Values
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.
4.1.5.2. Meaning
Throughout the time interval of the AVP, the endpoint had a hardware
component by the indicated manufacturer and having the specified
serial number.
4.1.5.3. Multiplicity
An endpoint may have any number of hardware instances, each with a
different serial number. An endpoint attribute assertion may contain
AVPs for any subset of the hardware instances.
Vendors generally ensure that each serial number goes to only one
hardware instance.
4.1.5.4. Stability
Each hardware component is immutably associated with a hardware
serial number. But hardware can be replaced or removed. As endpoint
attributes, hardware serial numbers are *persistent* but not
*immutable*.
4.1.5.5. Accuracy
4.1.5.6. Data Model Requirements
All SACM data models MUST support this entire subsection.
4.1.6. Certificate
4.1.6.1. Range of values
MUST be X.509 certificate, per [RFC5280].
4.1.6.2. Meaning
Throughout the time interval of the AVP, the endpoint had the private
key corresponding to the specified certificate.
Throughout the time interval, the certificate was valid: it had a
valid certificate chain from a CA certificate that the asserter
trusted; every certificate in the chain was time-valid; no
certificate in in the chain (excluding the CA certificate) was
revoked. ISSUE (CEK): Do we want to get this PKI-ish? If so, would
we include the CA certificate as well?
4.1.6.3. Multiplicity
An endpoint may use, or have the right to use, one or more
certificates.
Some certificates may be used on more than one endpoint. Other
certificates are (by intent) bound to a single endpoint. ISSUE
(CEK): Is there a standard way to distinguish the two? We could
perhaps provide a configurable criterion, as an information element.
Should we?
4.1.6.4. Stability
Certificates are replaced, due to expiration and other reasons. By
and large, they are not replaced often. A year is a typical
interval. In sum, they are persistent.
A private key is baked into hardware is almost immutable. But again,
hardware can be replaced.
4.1.6.5. Accuracy
If a certificate is known by verification, the attribute is highly
accurate.
4.1.6.6. Data model requirements
All SACM data models MUST support this entire subsection.
4.1.7. Public Key
TODO
4.1.8. Username?
ISSUE (CEK): If a user certificate can be an identifying attribute,
why not a username also? At an earlier stage of our discussions,
usernames were considered common identifying attributes. Did we
decide they should not be? Or just forget them?
Many endpoints do not have client certificates. An authenticated
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
and password to many multi-user servers. We would have to
distinguish personal endpoints from server endpoints somehow.
4.1.9. Tool-Specific Identifier
TODO
TODO: "Tool-specific identifier" suggests that two tools could never
agree on a tool-specific identifier. But a community may agree on an
identifier notation, and might even create a formal standard. All
that's important is that each of these attributes has a type and
meaning *not* specified by the SACM internet drafts. "Vendor-
specific identifier?" "Custom identifier?"
4.1.10. Identification of Endpoints where SACM Components Reside
Every information element needs identifying attributes of its
producer's endpoint. (TODO: Provide normative language. SHOULD?
MUST?)
Specifically, in an endpoint attribute assertion, we need identifying
attributes of the asserter's endpoint. If the asserter is external,
the assertion will contain identifying attributes of two endpoints.
(TODO: Discuss what this information is for.)
4.1.11. Security Considerations
Effects of misidentification
Things that can cause misidentification
How minimize misidentification
4.2. Software Component
An endpoint contains and runs software components. An endpoint contains and runs software components.
Relationship: Relationship:
o If an endpoint has an instance of a software component, we say o If an endpoint has an instance of a software component, we say
that the software component is "in" the endpoint. This is a that the software component is "in" the endpoint. This is a
shorthand. shorthand.
Some software components are assets. "Asset" is defined in RFC4949 Some software components are assets. "Asset" is defined in RFC4949
skipping to change at page 13, line 28 skipping to change at page 19, line 45
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
Software components SHOULD be disjoint from each other. In other Software components SHOULD be disjoint from each other. In other
words, software componenns SHOULD be so defined that a given byte of words, software componennts SHOULD be so defined that a given byte of
software on an endpoint belongs to only one software component. software on an endpoint belongs to only one software component.
Different versions of the same piece of software MUST be modeled as Different versions of the same piece of software MUST be modeled as
different components. Software versioning is not built into the different components. Software versioning is not built into the
information model. information model.
Each separately installable piece of software SHOULD be modeled as a Each separately installable piece of software SHOULD be modeled as a
component. Sometimes it may be better to divide more finely: what an component. Sometimes it may be better to divide more finely: what an
installer installs MAY be modeled as several components. installer installs MAY be modeled as several components.
A data model MAY identify a software component by parts of an ISO A data model MAY identify a software component by parts of an ISO
SWID tag. SWID tag.
4.2. Software Instance 4.3. Software Instance
Each copy of a piece of software is called a software instance. The Each copy of a piece of software is called a software instance. The
configuration of a software instance is regarded as part of the configuration of a software instance is regarded as part of the
software instance. Configuration can strongly affect security software instance. Configuration can strongly affect security
posture. posture.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o A software instance is an "instance of" a software component. o A software instance is an "instance of" a software component.
o A software instance is "in" an endpoint. o A software instance is "in" an endpoint.
A data model MAY use ISO SWID tags to identify software instances. A data model MAY use ISO SWID tags to describe software instances.
4.3. Hardware Component 4.4. Hardware Component
Hardware components may also be assets and/or harmful. For example, Hardware components may also be assets and/or harmful. For example,
a USB port on a system may be disabled to prevent information flow a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional into our out of a particular system; this provides an additional
layer of protection that can complement software based protections. layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm. that can be compromised in some way to do harm.
A data model MAY designate a hardware component by its manufacturer A data model MAY designate a hardware component by its manufacturer
and a part number. and a part number.
4.4. Hardware Instance 4.5. Hardware Instance
A hardware instance is just an instance of a particular component. A hardware instance is just an instance of a particular component.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o A hardware instance is an "instance of" a hardware component. o A hardware instance is an "instance of" a hardware component.
o A hardware instance is "in" an endpoint. o A hardware instance is "in" an endpoint.
Hardware instances may need to be modeled because (a) an endpoint may Hardware instances may need to be modeled because (a) an endpoint may
have multiple instances of a hardware component, (b) a hardware have multiple instances of a hardware component, (b) a hardware
instance may be compromised, whereas other instances may remain instance may be compromised, whereas other instances may remain
intact. intact.
A data model MAY designate a hardware instance by its component and a A data model MAY designate a hardware instance by its component and a
unique serial number. unique serial number.
4.5. Network Interface 4.6. Network Interface
CEK: I am not sure how to use network interfaces for endpoint
identification. As for compliance, is this too advanced for SACM at
this time?
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.
skipping to change at page 15, line 20 skipping to change at page 21, line 35
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) will be
aware of the identity. aware of the identity.
4.6. Address 4.7. Address
As used in this document, an address is any of: TODO: DELETE THIS SECTION. ISSUE (CEK): Do we still want to model
layer 4 addresses?
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
addresses, and MAY support others addresses, and MAY support others
o A layer 4 address; a data model MUST support an IP-address- o A layer 4 address; a data model MUST support an IP-address-
protocol-port combination, where protocol is TCP or UDP. It MAY protocol-port combination, where protocol is TCP or UDP. It MAY
support others support others
skipping to change at page 16, line 7 skipping to change at page 22, line 24
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.7. Identity 4.8. Identity
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,
if the endpoint is part of an Active Directory domain and Alice if the endpoint is part of an Active Directory domain and Alice
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 at once, such as a machine identity and a user than one identity, such as a machine identity and a user identity.
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.8. Location 4.9. Location
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 An endpoint 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
o An account may be "in" a location; this would happen if the o An account may be "in" a location; this would happen if the
account represents a user, and a physical access control system account represents a user, and a physical access control system
reports on the user's location reports on the user's location
Examples of location: Examples of location:
skipping to change at page 17, line 26 skipping to change at page 24, 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.9. Endpoint 4.10. Endpoint
An endpoint is the hollow center of the model. An endpoint is an An endpoint is the hollow center of the model. An endpoint is an
abstract ideal. Any endpoint attribute assertion that mentions an abstract ideal. Any endpoint attribute assertion that mentions an
endpoint mentions it by specifying identifying attributes. Even if endpoint mentions it by specifying identifying attributes. Even if
there is one preferred endpoint identity, that is modeled as an there is one preferred endpoint identity, that is modeled as an
identity. We do not anticipate any AVP whose attribute type is identity. We do not anticipate any AVP whose attribute type is
"endpoint". "endpoint".
4.10. Endpoint Attribute Assertion 4.11. Endpoint Attribute Assertion
Represents a direct observation by an attribute collector, or a 4.11.1. Form and Precise Meaning
conclusion drawn by an evaluator. It asserts that specified posture
attribute-value pairs were true of an identified endpoint, at a
specific time or throughout a specified time interval.
CEK: I think it asserts that there exists an endpoint for which all An endpoint attribute assertion has:
of the AVPs are true. The times and time intervals are features of
the AVPs, not of the endpoint attribute assertion.
4.10.1. Form and Precise Meaning o One or more attribute-value pairs (AVPs)
An endpoint attribute assertion MUST have: o Time intervals over which the AVPs hold
o One or more attribute-value pairs (AVPs) (see section XXX) o Endpoint uniquely identified? True or false
o Provenance information, including: (see section XXX)
Asserted attributes and their associated values are used to both o Provenance, including:
identify the target endpoint and to communicate aspects of the
endpoint's posture. This distinction is further explained in section
XXX(AVPs).
4.11. Attribute-Value Pair * The SACM component that made the assertion
DW: Pair is not a good word for this information since more than two * Information about the method used to derive the assertion
data points are required. We should consider a better term.
An attribute-value pair (AVP) is a tuple of information asserting an It means that over the specified time interval, there was an endpoint
observed aspect of endpoint posture and/or identity. for which all of the listed attribute-value pairs were true.
Each AVP MUST include the following data: If the "Endpoint uniquely identified" is true, the set of attributes-
value pairs together make this assertion apply to only one endpoint.
o Identification of a posture or identification attribute (see The attributes can include posture attributes and identification
section [Posture Attribute]) attributes. The model does not make a rigid distinction between the
two uses of attributes.
o The value(s) associated with the posture or identification Some of the attributes may be multi-valued.
attribute at the time the observation was made.
* The value MAY be structured. For example, it may something One of the AVPs may be a unique endpoint identifier. Not every
like XML. endpoint will have one. If there is one, the SACM component that
produces the Endpoint Attribute Assertion will not necessarily know
what it is.
* Some attributes will be multi-valued. Data models implementing 4.11.2. Asserter
this information model MUST support multiple values.
o Temporal information bounding the observation. Temporal An Endpoint Attribute Assertion may come from an attribute collector
information MUST consist of one of the following: 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
SACM component may derive it from other Endpoint Attribute
Assertions.
* A timestamp indicating the point-in-time the observation was 4.11.3. Example
made, or
* An interval establishing the duration for which the value(s) For example, an attribute assertion might have these attribute-value
have existed. pairs:
* Information about the method used to derive the assertion. (see mac-address = 01:23:45:67:89:ab
section [method])
If posture assertions are generated by monitoring a system for os = OS X
changes, describing the interval for which a given state was found to
be consistent enables additional information to be expressed over a
point-in-time observation. Since values may drift over time,
expressing this additional information provides important context to
downstream consumers of a posture assertion about the rate and time
of change.
4.11.1. Posture Attribute os-version = 10.6.8
Posture Attribute is defined in [RFC5209] as "attribute describing This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran
the configuration or status (posture) of a feature of the endpoint. OS X 10.6.8 throughout the specified time interval. A profiler might
A Posture Attribute represents a single property of an observed have provided this assertion.
state."
The set of attribute types MUST be extensible by other IETF 4.11.4. A Use Case
standards, by other standards groups, and by vendors. How to express
attribute types is not defined here, but is left to data models to
address.
Example posture attributes: [ This needs to be updated ] For example, Endpoint Attribute Assertions should help SACM
components to track an endpoint as it roams or stays stationary.
They must track endpoints because they must track endpoints' postures
over time. Tracking of an endpoint can employ many clues, such as:
o TBD The endpoint's MAC address
4.11.2. Identifying Attributes The authenticated identity (even if it identifies a user)
An identifying attribute is observation made at a specific point in The location of the endpoint and the user
time that can be used standalone or in combination with other
observations to identify an endpoint. While all endpoint posture
attributes can be used to establish an endpoint's identity, not all
attributes are equally suited. Primary identifying attributes are a
subset of posture attributes that have the following desirable
characteristics for use in identifying an endpoint:
o Available - Present on most platforms allowing for a breadth of 4.11.5. Event
interoperability between platforms.
o Stable - Change infrequently (e.g., assist with identifying an An event is represented as a Posture Attribute Assertion whose time
endpoint across network sessions) interval has length zero.
o Authentic - High level of assurance, attributes can be Some potential kinds of events are:
authenticated
Other posture attributes that do not possess these characteristics o A structured syslog message [RFC5424]
are considered secondary identifying attributes. They can often be
used to check an identity assertion or to further define the
endpoint's identity (e.g. configuration, software inventory,
capability). Examples of primary identifying attributes:
o Certificates (e.g., device, user, drive, other hardware) o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA]
MUST be provided if available on device; favored by consumers o A NetFlow message [RFC3954]
of the assertion
Others if available as associated with the session 4.11.6. Difference between Attribute and Event
ISSUE: Use whole cert or some aspect (e.g., public key)
o Hostname(s) - configured on the device; may be multiple and Author: Henk Birkholz
possibly of different kinds
Consider how to specify type: multiple attributes for each type "Attribute" and "event" are often used fairly interchangeably. A
or type qualifier clear distinction makes the words more useful.
o FQDN(s) (if available); some hosts may have multiple; also list An *attribute* tends not to change until something causes a change.
DNS aliases In contrast, an *event* occurs at a moment in time.
Sourced from the DNS infrastructure For a nontechnical example, let us consider "openness" as an
attribute of a door, with two values, "open" and "closed". A closed
door tends to stay closed until something opens it (a breeze, a
person, or a dog).
ISSUE: Think about the security considerations of insecure DNS The door's opening or closing is an event.
deployments
o Network Interface(s) (comprehensive, if possible) Similarly, "Host firewall enabled" may be modeled as a true/false
attribute of an endpoint. Enabling or disabling the host firewall
may be modeled as an event. An endpoint's crashing also may be
modeled as an event.
MAC and IP address(es) Although events are not attributes, we use one kind of information
element, the "Endpoint Attribute Assertion", to describe both
attributes and events.
Including additional IPs assigned to the interface 4.12. Attribute-Value Pair
Interfaces may be nested (e.g., overlay networks - VLANs) The set of attribute types must be extensible, by other IETF
standards, by other standards groups, and by vendors. How to express
attribute types is not defined here, but is left to data models.
NOTE: Need to verify that standardized methods are available to The value may be structured. For example, it may something like XML.
do this.
o Tool-specific Identifier - provided by the software making the The information model requires a standard attribute type (or possibly
assertion more than one) for each box in Figure 1:
SHOULD be provided if available o Hardware Component: the value identifies the hardware type. For
example, it may consist of the make and model number.
May be session scoped if the tool is not able to distinguish an o Hardware Instance: the value, together with the Hardware Component
endpoint across sessions value, uniquely identifies the hardware instance. For example, it
may be a manufacturer-assigned serial number. This notion might
not apply to all virtual hardware components.
May be omitted if the tool is unable to distinguish the o Software Component: the value identifies a unit of software. Each
endpoint across multiple assertions installable piece of software should be separately identifiable.
For example, this might be a Software Identifier (SWID).
o Identification information from bios/firmware (e.g., serial Therefore, a software inventory for an endpoint should be
numbers, asset tags, VM id) that can be queried on the device expressed as an Endpoint Attribute Assertion.
using software. NOTE: Need to discuss more.
Assets are compositional. Some components may have specific o Software Instance: the value describes how the software component
identifiers. It would be useful to indicate which component is installed and configured.
has a specific identifying attribute.
Information should be made available by all manufacturers o Endpoint: The value is a unique endpoint identifier.
If available should be provided as an attribute
o Other cryptographic information o Location
4.11.3. Evaluation Result o Identity: The value is the non-secret part of a credential. For
example, it may be a certificate, or just a subject Distinguished
Name extracted from a certificate. It may be a username.
o Network Interface: TBD
o User: [cek: Do we want this? If one user uses different
credentials at different times, do we think SACM components will
need know that it's the same user?]
o Address: The value is an IP, MAC, or other network address,
possibly qualified with its scope.
4.12.1. Unique Endpoint Identifier
An organization should try to uniquely identify and label an
endpoint, whether the endpoint is enrolled or is discovered in the
operational environment. The identifier should be assigned by or
used in the enrollment process.
Here "unique" means one-to-one. In practice, uniqueness is not
always attainable. Even if an endpoint has a unique identifier, an
attribute collector may not always know it.
If the attribute type of an AVP is "endpoint", the value is a unique
identifier of the endpoint.
4.12.2. Posture Attribute
Some AVPs will be posture attributes.
See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology].
Some potential kinds of posture attributes are:
o A NEA posture attribute (PA) [RFC5209]
o A YANG model [RFC6020]
o An IF-MAP device-characteristics metadata item
[TNC-IF-MAP-NETSEC-METADATA]
4.13. 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 1 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.12. Report 4.14. Report
ISSUE (CEK): Should we take modeling of reports out of scope? It is
clear that reports are needed. But is a *standard* for reports
needed, and does it deserve our priority?
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 21, line 46 skipping to change at page 29, line 4
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.13. SACM Component 4.15. 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?
4.13.1. External Attribute Collector ISSUE (CEK): Why do we need information elements that model SACM
compoments?
4.15.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 22, line 48 skipping to change at page 30, line 8
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.13.2. Evaluator 4.15.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.13.3. Report Generator 4.15.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.14. Organization? 4.16. 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.15. Guidance 4.17. 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.15.1. Internal Collection Guidance 4.17.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.15.2. External Collection Guidance 4.17.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.15.3. Evaluation Guidance 4.17.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.15.4. Retention Guidance 4.17.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.15.5. Reporting Guidance 4.17.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.
4.16. Provenance of Information 4.18. Provenance of Information
Each Endpoint Attribute Assertion and Report needs to be labeled with Each Endpoint Attribute Assertion and Report needs to be labeled with
its provenance. its provenance.
4.17. Endpoint 4.19. 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
(redundancy group) of multi-chassis setups to provide active (redundancy group) of multi-chassis setups to provide active
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
skipping to change at page 25, line 20 skipping to change at page 32, line 32
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.17.1. Endpoint Identity 4.19.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.17.2. Software Component 4.19.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 26, line 18 skipping to change at page 33, line 31
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.17.2.1. Unique Software Identifier 4.19.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.18. User 4.20. User
4.20.1. User Identity
4.18.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 5. 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 /
skipping to change at page 31, line 28 skipping to change at page 38, line 44
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 9. References
9.1. Normative References 9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[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, March 1997.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
9.2. Informative References 9.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/>.
skipping to change at page 32, line 24 skipping to change at page 39, line 48
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] [I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf- Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-07 (work in progress), April 2014. 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,
skipping to change at page 35, line 5 skipping to change at page 42, line 33
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007. 4949, August 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[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, June 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[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, March 2010.
[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, March 2010.
skipping to change at page 37, line 13 skipping to change at page 44, line 31
<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>.
9.3. URIs
[1] https://github.com/OVALProject/Sandbox/blob/master/x-netconf-
definitions-schema.xsd
Appendix A. Security Automation with TNC IF-MAP Appendix A. Security Automation with TNC IF-MAP
A.1. What is Trusted Network Connect? A.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
skipping to change at page 42, line 35 skipping to change at page 49, line 50
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 2, Consumers In the most trivial example, illustrated in Figure 4, 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 2: Example Producer/Consumer Interactions Figure 4: Example Producer/Consumer Interactions
As illustrated in Figure 3, writing and querying from data As illustrated in Figure 5, 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 3: Producer/Consumer Repository Interaction Figure 5: 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 44, line 48 skipping to change at page 51, line 48
+-----v--------+ +----+------+ +-----v--------+ +----+------+
|Evaluation | |Reporting | |Evaluation | |Reporting |
|Results | |Guidance | |Results | |Guidance |
|Consumer | |Repository | |Consumer | |Repository |
+---+----------+ +-----------+ +-------------+ +---+----------+ +-----------+ +-------------+
| | Results | | | Results |
+-----------------------------> Repository | +-----------------------------> Repository |
| | | |
+-------------+ +-------------+
Figure 4: Producer/Consumer Complex Example Figure 6: Producer/Consumer Complex Example
This illustrative example in Figure 4 provides a set of information This illustrative example in Figure 6 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 D. Text for Possible Inclusion in the Requirements Draft
D.1. Problem Statement D.1. Problem Statement
Scalable and sustainable collection, expression, and evaluation of Scalable and sustainable collection, expression, and evaluation of
skipping to change at page 50, line 19 skipping to change at page 57, line 19
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 5), providing for extension at any asset types/classes (see Figure 7), 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 50, line 42 skipping to change at page 57, line 42
| +-database | +-database
| +-network | +-network
| +-service | +-service
| +-software | +-software
| +-system | +-system
| +-website | +-website
+-data +-data
+-organization +-organization
+-person +-person
Figure 5: Asset Identification Class Hierarchy Figure 7: 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 31 skipping to change at page 65, 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 6: The OVAL Data Model Figure 8: The OVAL Data Model
The OVAL data model [OVAL-LANGUAGE], visualized in Figure 6, is The OVAL data model [OVAL-LANGUAGE], visualized in Figure 8, 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 71, line 13 skipping to change at page 78, line 13
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
network infrastructure vendors, it may useful to consider this network infrastructure vendors, 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 network infrastructure endpoints. data from network infrastructure endpoints.
As a side note, members of the OVAL Community have also developed a As a side note, members of the OVAL Community have also developed a
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 [1]. The proposal leverages XPath to NETCONF configuration data
extract the posture attribute data of interest from the XML data <https://github.com/OVALProject/Sandbox/blob/master/x-netconf-
returned by NETCONF. The collected posture attribute data can then definitions-schema.xsd>. The proposal leverages XPath to extract the
be evaluated using OVAL Definitions and the results of the evaluation posture attribute data of interest from the XML data returned by
can be expressed as OVAL Results. While this proposal is not NETCONF. The collected posture attribute data can then be evaluated
currently part of the OVAL Language, it may be worth considering. using OVAL Definitions and the results of the evaluation can be
expressed as OVAL Results. While this proposal is not currently part
of the OVAL Language, it may be worth considering.
E.3.5.2.1.3. SNMP-Based Collection E.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 E.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
skipping to change at page 77, line 12 skipping to change at page 84, line 12
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 7: Knowledge represented by a graph Figure 9: 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 F.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
 End of changes. 127 change blocks. 
365 lines changed or deleted 712 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/