draft-ietf-sacm-information-model-03.txt   draft-ietf-sacm-information-model-04.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: July 8, 2016 DHS Expires: September 18, 2016 DHS
C. Kahn C. Kahn
L. Lorenzin L. Lorenzin
Pulse Secure, LLC Pulse Secure, LLC
M. Cokus
D. Haynes D. Haynes
The MITRE Corporation The MITRE Corporation
January 5, 2016 March 17, 2016
SACM Information Model SACM Information Model
draft-ietf-sacm-information-model-03 draft-ietf-sacm-information-model-04
Abstract Abstract
This document proposes an information model for SACM. This document defines the 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 July 8, 2016. This Internet-Draft will expire on September 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8
1.1.1. Referring to an Endpoint . . . . . . . . . . . . . . 7 1.1.1. Referring to an Endpoint . . . . . . . . . . . . . . 9
1.1.2. Dealing with Uncertainty . . . . . . . . . . . . . . 8 1.1.2. Dealing with Uncertainty . . . . . . . . . . . . . . 10
2. Conventions used in this document . . . . . . . . . . . . . . 8 2. Conventions used in this document . . . . . . . . . . . . . . 11
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 9 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 11
3. Information Model Framework . . . . . . . . . . . . . . . . . 9 3. Information Model Framework . . . . . . . . . . . . . . . . . 11
3.1. Containers . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Relationships . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Designation . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Conventions for Modeling Information Model Objects . . . 10 3.4. Relationships . . . . . . . . . . . . . . . . . . . . . . 15
4. Information Model Assets . . . . . . . . . . . . . . . . . . 10 3.5. Designation . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Asset . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7. Type Space . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Hardware Component . . . . . . . . . . . . . . . . . . . 11 3.7.1. Abstract Data Types . . . . . . . . . . . . . . . . . 16
4.3.1. Hardware Instance . . . . . . . . . . . . . . . . . . 12 3.7.1.1. unsigned8 . . . . . . . . . . . . . . . . . . . . 16
4.4. Software Component . . . . . . . . . . . . . . . . . . . 12 3.7.1.2. unsigned16 . . . . . . . . . . . . . . . . . . . 16
4.4.1. Software Instance . . . . . . . . . . . . . . . . . . 14 3.7.1.3. unsigned32 . . . . . . . . . . . . . . . . . . . 16
4.5. Asset Identity . . . . . . . . . . . . . . . . . . . . . 14 3.7.1.4. unsigned64 . . . . . . . . . . . . . . . . . . . 16
4.6. Relationships . . . . . . . . . . . . . . . . . . . . . . 14 3.7.1.5. signed8 . . . . . . . . . . . . . . . . . . . . . 16
5. Information Model Elements . . . . . . . . . . . . . . . . . 14 3.7.1.6. signed16 . . . . . . . . . . . . . . . . . . . . 16
5.1. Identifying Attributes . . . . . . . . . . . . . . . . . 17 3.7.1.7. signed32 . . . . . . . . . . . . . . . . . . . . 17
5.1.1. How Known . . . . . . . . . . . . . . . . . . . . . . 17 3.7.1.8. signed64 . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Whether to Include . . . . . . . . . . . . . . . . . 18 3.7.1.9. float32 . . . . . . . . . . . . . . . . . . . . . 17
5.1.3. IP Address . . . . . . . . . . . . . . . . . . . . . 18 3.7.1.10. float64 . . . . . . . . . . . . . . . . . . . . . 17
5.1.3.1. Range of Values . . . . . . . . . . . . . . . . . 18 3.7.1.11. boolean . . . . . . . . . . . . . . . . . . . . . 17
5.1.3.2. Meaning . . . . . . . . . . . . . . . . . . . . . 19 3.7.1.12. macAddress . . . . . . . . . . . . . . . . . . . 17
5.1.3.3. Relationships . . . . . . . . . . . . . . . . . . 19 3.7.1.13. string . . . . . . . . . . . . . . . . . . . . . 17
5.1.3.4. Multiplicity . . . . . . . . . . . . . . . . . . 19 3.7.1.14. dateTimeSeconds . . . . . . . . . . . . . . . . . 17
5.1.3.5. Stability . . . . . . . . . . . . . . . . . . . . 19 3.7.1.15. dateTimeMilliseconds . . . . . . . . . . . . . . 17
5.1.3.6. Accuracy . . . . . . . . . . . . . . . . . . . . 19 3.7.1.16. dateTimeMicroseconds . . . . . . . . . . . . . . 18
5.1.3.7. Data Model Requirements . . . . . . . . . . . . . 20 3.7.1.17. dateTimeNanoseconds . . . . . . . . . . . . . . . 18
5.1.4. MAC Address . . . . . . . . . . . . . . . . . . . . . 20 3.7.1.18. ipv4Address . . . . . . . . . . . . . . . . . . . 18
5.1.5. Hardware Serial Number . . . . . . . . . . . . . . . 20 3.7.1.19. ipv6Address . . . . . . . . . . . . . . . . . . . 18
5.1.5.1. Range of Values . . . . . . . . . . . . . . . . . 20 3.7.1.20. basicList . . . . . . . . . . . . . . . . . . . . 18
5.1.5.2. Meaning . . . . . . . . . . . . . . . . . . . . . 20 3.7.1.21. subTemplateList . . . . . . . . . . . . . . . . . 18
5.1.5.3. Multiplicity . . . . . . . . . . . . . . . . . . 20 3.7.1.22. subTemplateMultiList . . . . . . . . . . . . . . 18
5.1.5.4. Stability . . . . . . . . . . . . . . . . . . . . 21 3.7.2. Data Type Semantics . . . . . . . . . . . . . . . . . 18
5.1.5.5. Accuracy . . . . . . . . . . . . . . . . . . . . 21 3.7.3. quantity . . . . . . . . . . . . . . . . . . . . . . 19
5.1.5.6. Data Model Requirements . . . . . . . . . . . . . 21 3.7.4. totalCounter . . . . . . . . . . . . . . . . . . . . 19
5.1.6. Certificate . . . . . . . . . . . . . . . . . . . . . 21 3.7.5. deltaCounter . . . . . . . . . . . . . . . . . . . . 19
5.1.6.1. Range of values . . . . . . . . . . . . . . . . . 21 3.7.6. identifier . . . . . . . . . . . . . . . . . . . . . 19
5.1.6.2. Meaning . . . . . . . . . . . . . . . . . . . . . 21 3.7.7. flags . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.6.3. Multiplicity . . . . . . . . . . . . . . . . . . 21 3.7.8. list . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.6.4. Stability . . . . . . . . . . . . . . . . . . . . 21 4. Information Model Assets . . . . . . . . . . . . . . . . . . 20
5.1.6.5. Accuracy . . . . . . . . . . . . . . . . . . . . 22 4.1. Asset . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.6.6. Data model requirements . . . . . . . . . . . . . 22 4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.7. Public Key . . . . . . . . . . . . . . . . . . . . . 22 4.3. Hardware Component . . . . . . . . . . . . . . . . . . . 22
5.1.8. Username? . . . . . . . . . . . . . . . . . . . . . . 22 4.3.1. Hardware Instance . . . . . . . . . . . . . . . . . . 22
5.1.9. Tool-Specific Identifier . . . . . . . . . . . . . . 22 4.4. Software Component . . . . . . . . . . . . . . . . . . . 22
5.1.10. Identification of Endpoints where SACM Components 4.4.1. Software Instance . . . . . . . . . . . . . . . . . . 24
Reside . . . . . . . . . . . . . . . . . . . . . . . 22 4.5. Asset Identity . . . . . . . . . . . . . . . . . . . . . 24
5.1.11. Security Considerations . . . . . . . . . . . . . . . 23 4.6. Relationships . . . . . . . . . . . . . . . . . . . . . . 24
5.2. Network Interface . . . . . . . . . . . . . . . . . . . . 23 5. Information Model Elements . . . . . . . . . . . . . . . . . 24
5.3. Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Identifying Attributes . . . . . . . . . . . . . . . . . 27
5.4. Identity . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.1. How Known . . . . . . . . . . . . . . . . . . . . . . 27
5.5. Location . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.2. Whether to Include . . . . . . . . . . . . . . . . . 28
5.6. Endpoint Attribute Assertion . . . . . . . . . . . . . . 26 5.1.3. Certificate . . . . . . . . . . . . . . . . . . . . . 28
5.6.1. Form and Precise Meaning . . . . . . . . . . . . . . 26 5.1.3.1. Range of values . . . . . . . . . . . . . . . . . 28
5.6.2. Asserter . . . . . . . . . . . . . . . . . . . . . . 26 5.1.3.2. Meaning . . . . . . . . . . . . . . . . . . . . . 28
5.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.3.3. Multiplicity . . . . . . . . . . . . . . . . . . 28
5.6.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 27 5.1.3.4. Stability . . . . . . . . . . . . . . . . . . . . 29
5.6.5. Event . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.3.5. Accuracy . . . . . . . . . . . . . . . . . . . . 29
5.6.6. Difference between Attribute and Event . . . . . . . 27 5.1.3.6. Data model requirements . . . . . . . . . . . . . 29
5.7. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 28 5.1.4. Public Key . . . . . . . . . . . . . . . . . . . . . 29
5.7.1. Unique Endpoint Identifier . . . . . . . . . . . . . 29 5.1.5. Username? . . . . . . . . . . . . . . . . . . . . . . 29
5.7.2. Posture Attribute . . . . . . . . . . . . . . . . . . 29 5.1.6. Tool-Specific Identifier . . . . . . . . . . . . . . 29
5.8. Evaluation Result . . . . . . . . . . . . . . . . . . . . 30 5.1.7. Identification of Endpoints where SACM Components
5.9. Report . . . . . . . . . . . . . . . . . . . . . . . . . 30 Reside . . . . . . . . . . . . . . . . . . . . . . . 30
5.10. SACM Component . . . . . . . . . . . . . . . . . . . . . 31 5.1.8. Security Considerations . . . . . . . . . . . . . . . 30
5.10.1. External Attribute Collector . . . . . . . . . . . . 31 5.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . 30
5.10.2. Evaluator . . . . . . . . . . . . . . . . . . . . . 32 5.3. Location . . . . . . . . . . . . . . . . . . . . . . . . 31
5.10.3. Report Generator . . . . . . . . . . . . . . . . . . 32 5.4. Endpoint Attribute Assertion . . . . . . . . . . . . . . 32
5.11. Organization? . . . . . . . . . . . . . . . . . . . . . . 32 5.4.1. Form and Precise Meaning . . . . . . . . . . . . . . 32
5.12. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 33 5.4.2. Asserter . . . . . . . . . . . . . . . . . . . . . . 32
5.12.1. Internal Collection Guidance . . . . . . . . . . . . 33 5.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 33
5.12.2. External Collection Guidance . . . . . . . . . . . . 33 5.4.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 33
5.12.3. Evaluation Guidance . . . . . . . . . . . . . . . . 33 5.4.5. Event . . . . . . . . . . . . . . . . . . . . . . . . 33
5.12.4. Retention Guidance . . . . . . . . . . . . . . . . . 33 5.4.6. Difference between Attribute and Event . . . . . . . 33
5.12.5. Reporting Guidance . . . . . . . . . . . . . . . . . 33 5.5. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 34
5.13. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 34 5.5.1. Unique Endpoint Identifier . . . . . . . . . . . . . 35
5.13.1. Endpoint Identity . . . . . . . . . . . . . . . . . 34 5.5.2. Posture Attribute . . . . . . . . . . . . . . . . . . 35
5.13.2. Software Component . . . . . . . . . . . . . . . . . 34 5.6. Evaluation Result . . . . . . . . . . . . . . . . . . . . 36
5.13.2.1. Unique Software Identifier . . . . . . . . . . . 35 5.7. SACM Component . . . . . . . . . . . . . . . . . . . . . 36
5.14. User . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.7.1. External Attribute Collector . . . . . . . . . . . . 36
5.14.1. User Identity . . . . . . . . . . . . . . . . . . . 35 5.7.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 37
6. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 36 5.8. Organization? . . . . . . . . . . . . . . . . . . . . . . 37
6.1. Graph Model for Detection of Posture Deviation . . . . . 36 5.9. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 38
6.1.1. Components . . . . . . . . . . . . . . . . . . . . . 36 5.9.1. Internal Collection Guidance . . . . . . . . . . . . 38
6.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 37 5.9.2. External Collection Guidance . . . . . . . . . . . . 38
6.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 37 5.9.3. Evaluation Guidance . . . . . . . . . . . . . . . . . 38
6.1.4. Relationships between Identifiers and Metadata . . . 38 5.9.4. Retention Guidance . . . . . . . . . . . . . . . . . 38
6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 38 5.10. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 39
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 5.10.1. Endpoint Identity . . . . . . . . . . . . . . . . . 39
7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 39 5.10.2. Software Component . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 5.10.2.1. Unique Software Identifier . . . . . . . . . . . 40
9. Operational Considerations . . . . . . . . . . . . . . . . . 40 5.11. User . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 5.11.1. User Identity . . . . . . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 5.12. hardwareSerialNumber . . . . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.13. interfaceName . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . 41 5.14. interfaceIndex . . . . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . 41 5.15. interfaceMacAddress . . . . . . . . . . . . . . . . . . . 41
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 47 5.16. interfaceType . . . . . . . . . . . . . . . . . . . . . . 42
A.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 47 5.17. interfaceFlags . . . . . . . . . . . . . . . . . . . . . 42
A.2. Changes in Revision 02 . . . . . . . . . . . . . . . . . 48 5.18. networkInterface . . . . . . . . . . . . . . . . . . . . 42
A.3. Changes in Revision 03 . . . . . . . . . . . . . . . . . 48 5.19. softwareIdentifier . . . . . . . . . . . . . . . . . . . 43
Appendix B. Mapping to SACM Use Cases . . . . . . . . . . . . . 48 5.20. softwareTitle . . . . . . . . . . . . . . . . . . . . . . 43
Appendix C. Security Automation with TNC IF-MAP . . . . . . . . 49 5.21. softwareCreator . . . . . . . . . . . . . . . . . . . . . 43
C.1. What is Trusted Network Connect? . . . . . . . . . . . . 49 5.22. simpleVersion . . . . . . . . . . . . . . . . . . . . . . 44
C.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 49 5.23. rpmVersion . . . . . . . . . . . . . . . . . . . . . . . 44
C.3. What is the TNC Information Model? . . . . . . . . . . . 50 5.24. ciscoTrainVersion . . . . . . . . . . . . . . . . . . . . 44
Appendix D. Text for Possible Inclusion in the Terminology Draft 51 5.25. softwareVersion . . . . . . . . . . . . . . . . . . . . . 44
D.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 51 5.26. lastUpdated . . . . . . . . . . . . . . . . . . . . . . . 45
D.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 51 5.27. softwareInstance . . . . . . . . . . . . . . . . . . . . 45
D.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 51 5.28. globallyUniqueIdentifier . . . . . . . . . . . . . . . . 46
5.29. dataOrigin . . . . . . . . . . . . . . . . . . . . . . . 46
5.30. dataSource . . . . . . . . . . . . . . . . . . . . . . . 46
5.31. creationTimestamp . . . . . . . . . . . . . . . . . . . . 46
5.32. collectionTimestamp . . . . . . . . . . . . . . . . . . . 46
5.33. publicationTimestamp . . . . . . . . . . . . . . . . . . 47
5.34. relayTimestamp . . . . . . . . . . . . . . . . . . . . . 47
5.35. storageTimestamp . . . . . . . . . . . . . . . . . . . . 47
5.36. type . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.37. protocolIdentifier . . . . . . . . . . . . . . . . . . . 48
5.38. sourceTransportPort . . . . . . . . . . . . . . . . . . . 48
5.39. sourceIPv4PrefixLength . . . . . . . . . . . . . . . . . 49
5.40. ingressInterface . . . . . . . . . . . . . . . . . . . . 49
5.41. destinationTransportPort . . . . . . . . . . . . . . . . 49
5.42. sourceIPv6PrefixLength . . . . . . . . . . . . . . . . . 50
5.43. sourceIPv4Prefix . . . . . . . . . . . . . . . . . . . . 50
5.44. destinationIPv4Prefix . . . . . . . . . . . . . . . . . . 50
5.45. sourceMacAddress . . . . . . . . . . . . . . . . . . . . 50
5.46. ipVersion . . . . . . . . . . . . . . . . . . . . . . . . 50
5.47. interfaceName . . . . . . . . . . . . . . . . . . . . . . 51
5.48. interfaceDescription . . . . . . . . . . . . . . . . . . 51
5.49. applicationDescription . . . . . . . . . . . . . . . . . 51
5.50. applicationId . . . . . . . . . . . . . . . . . . . . . . 51
5.51. applicationName . . . . . . . . . . . . . . . . . . . . . 51
5.52. exporterIPv4Address . . . . . . . . . . . . . . . . . . . 52
5.53. exporterIPv6Address . . . . . . . . . . . . . . . . . . . 52
5.54. portId . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.55. templateId . . . . . . . . . . . . . . . . . . . . . . . 52
5.56. collectorIPv4Address . . . . . . . . . . . . . . . . . . 53
5.57. collectorIPv6Address . . . . . . . . . . . . . . . . . . 53
5.58. informationElementIndex . . . . . . . . . . . . . . . . . 53
5.59. basicList . . . . . . . . . . . . . . . . . . . . . . . . 54
5.60. subTemplateList . . . . . . . . . . . . . . . . . . . . . 54
5.61. subTemplateMultiList . . . . . . . . . . . . . . . . . . 54
5.62. informationElementId . . . . . . . . . . . . . . . . . . 54
5.63. informationElementDataType . . . . . . . . . . . . . . . 54
5.64. informationElementDescription . . . . . . . . . . . . . . 55
5.65. informationElementName . . . . . . . . . . . . . . . . . 55
5.66. informationElementRangeBegin . . . . . . . . . . . . . . 56
5.67. informationElementRangeEnd . . . . . . . . . . . . . . . 56
5.68. informationElementSemantics . . . . . . . . . . . . . . . 56
5.69. informationElementUnits . . . . . . . . . . . . . . . . . 57
5.70. userName . . . . . . . . . . . . . . . . . . . . . . . . 57
5.71. applicationCategoryName . . . . . . . . . . . . . . . . . 57
5.72. mibObjectValueInteger . . . . . . . . . . . . . . . . . . 57
5.73. mibObjectValueOctetString . . . . . . . . . . . . . . . . 58
5.74. mibObjectValueOID . . . . . . . . . . . . . . . . . . . . 58
5.75. mibObjectValueBits . . . . . . . . . . . . . . . . . . . 59
5.76. mibObjectValueIPAddress . . . . . . . . . . . . . . . . . 59
5.77. mibObjectValueCounter . . . . . . . . . . . . . . . . . . 59
5.78. mibObjectValueGauge . . . . . . . . . . . . . . . . . . . 60
5.79. mibObjectValueTimeTicks . . . . . . . . . . . . . . . . . 60
5.80. mibObjectValueUnsigned . . . . . . . . . . . . . . . . . 60
5.81. mibObjectValueTable . . . . . . . . . . . . . . . . . . . 61
5.82. mibObjectValueRow . . . . . . . . . . . . . . . . . . . . 61
5.83. mibObjectIdentifier . . . . . . . . . . . . . . . . . . . 61
5.84. mibSubIdentifier . . . . . . . . . . . . . . . . . . . . 62
5.85. mibIndexIndicator . . . . . . . . . . . . . . . . . . . . 62
5.86. mibCaptureTimeSemantics . . . . . . . . . . . . . . . . . 62
5.87. mibContextEngineID . . . . . . . . . . . . . . . . . . . 63
5.88. mibContextName . . . . . . . . . . . . . . . . . . . . . 64
5.89. mibObjectName . . . . . . . . . . . . . . . . . . . . . . 64
5.90. mibObjectDescription . . . . . . . . . . . . . . . . . . 64
5.91. mibObjectSyntax . . . . . . . . . . . . . . . . . . . . . 64
5.92. mibModuleName . . . . . . . . . . . . . . . . . . . . . . 64
6. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 65
6.1. Graph Model for Detection of Posture Deviation . . . . . 65
6.1.1. Components . . . . . . . . . . . . . . . . . . . . . 65
6.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 66
6.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 66
6.1.4. Relationships between Identifiers and Metadata . . . 67
6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 67
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68
7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 68
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68
9. Operational Considerations . . . . . . . . . . . . . . . . . 69
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 69
11. Security Considerations . . . . . . . . . . . . . . . . . . . 69
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
12.1. Normative References . . . . . . . . . . . . . . . . . . 70
12.2. Informative References . . . . . . . . . . . . . . . . . 70
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 76
A.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 76
A.2. Changes in Revision 02 . . . . . . . . . . . . . . . . . 77
A.3. Changes in Revision 03 . . . . . . . . . . . . . . . . . 77
A.4. Changes in Revision 04 . . . . . . . . . . . . . . . . . 78
Appendix B. Mapping to SACM Use Cases . . . . . . . . . . . . . 78
Appendix C. Security Automation with TNC IF-MAP . . . . . . . . 78
C.1. What is Trusted Network Connect? . . . . . . . . . . . . 78
C.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 79
C.3. What is the TNC Information Model? . . . . . . . . . . . 79
Appendix D. Text for Possible Inclusion in the Terminology Draft 80
D.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 80
D.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 80
D.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 81
Appendix E. Text for Possible Inclusion in the Architecture or Appendix E. Text for Possible Inclusion in the Architecture or
Use Cases . . . . . . . . . . . . . . . . . . . . . 52 Use Cases . . . . . . . . . . . . . . . . . . . . . 81
E.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 52 E.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 82
E.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 53 E.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 82
E.3. Architecture Assumptions . . . . . . . . . . . . . . . . 53 E.3. Architecture Assumptions . . . . . . . . . . . . . . . . 83
Appendix F. Text for Possible Inclusion in the Requirements Appendix F. Text for Possible Inclusion in the Requirements
Draft . . . . . . . . . . . . . . . . . . . . . . . 57 Draft . . . . . . . . . . . . . . . . . . . . . . . 87
F.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 57 F.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 87
F.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 57 F.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 87
Appendix G. Text With No Clear Home Yet . . . . . . . . . . . . 58 Appendix G. Text With No Clear Home Yet . . . . . . . . . . . . 88
G.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 58 G.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 88
G.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 58 G.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 88
G.2. From Information Needs to Information Elements . . . . . 59 G.2. From Information Needs to Information Elements . . . . . 89
G.3. Information Model Elements . . . . . . . . . . . . . . . 59 G.3. Information Model Elements . . . . . . . . . . . . . . . 89
G.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 61 G.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 91
G.3.1.2. Endpoint Identification . . . . . . . . . . . . . 63 G.3.1.2. Endpoint Identification . . . . . . . . . . . . . 93
G.3.1.3. Software Identification . . . . . . . . . . . . . 64 G.3.1.3. Software Identification . . . . . . . . . . . . . 94
G.3.1.4. Hardware Identification . . . . . . . . . . . . . 67 G.3.1.4. Hardware Identification . . . . . . . . . . . . . 97
G.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 67 G.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 97
G.3.2.1. Platform Configuration Item Identifier . . . . . 67 G.3.2.1. Platform Configuration Item Identifier . . . . . 97
G.3.2.2. Configuration Item Identifier . . . . . . . . . . 73 G.3.2.2. Configuration Item Identifier . . . . . . . . . . 103
G.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 75 G.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 105
G.3.3. Endpoint characterization . . . . . . . . . . . . . . 105
G.3.3. Endpoint characterization . . . . . . . . . . . . . . 75 G.3.4. Posture Attribute Expression . . . . . . . . . . . . 109
G.3.4. Posture Attribute Expression . . . . . . . . . . . . 79 G.3.4.2. Platform Configuration Attributes . . . . . . . . 109
G.3.4.2. Platform Configuration Attributes . . . . . . . . 79 G.3.5. Actual Value Representation . . . . . . . . . . . . . 111
G.3.5. Actual Value Representation . . . . . . . . . . . . . 81 G.3.5.1. Software Inventory . . . . . . . . . . . . . . . 111
G.3.5.1. Software Inventory . . . . . . . . . . . . . . . 81
G.3.5.2. Collected Platform Configuration Posture G.3.5.2. Collected Platform Configuration Posture
Attributes . . . . . . . . . . . . . . . . . . . 82 Attributes . . . . . . . . . . . . . . . . . . . 112
G.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 83 G.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 113
G.3.6.1. Configuration Evaluation Guidance . . . . . . . . 83 G.3.6.1. Configuration Evaluation Guidance . . . . . . . . 113
G.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 85 G.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 115
G.3.7.1. Configuration Evaluation Results . . . . . . . . 85 G.3.7.1. Configuration Evaluation Results . . . . . . . . 115
G.3.7.2. Software Inventory Evaluation Results . . . . . . 87 G.3.7.2. Software Inventory Evaluation Results . . . . . . 117
Appendix H. Graph Model . . . . . . . . . . . . . . . . . . . . 87 Appendix H. Graph Model . . . . . . . . . . . . . . . . . . . . 117
H.1. Background: Graph Models . . . . . . . . . . . . . . . . 88 H.1. Background: Graph Models . . . . . . . . . . . . . . . . 118
H.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 89 H.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 119
H.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 89 H.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 119
H.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 90 H.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 120
H.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 90 H.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 120
H.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 91 H.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 121
H.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 91 H.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 121
H.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 91 H.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 121
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122
1. Introduction 1. Introduction
This document defines a notional information model for endpoint This document defines an information model for endpoint posture
posture assessment. It describes the information needed to perform assessment. The scope of the information model is to describe the
certain assessment activities. The scope of the information model is mandatory-to-implement information needs required to realize the
to describe the structure of the information carried to realize the assessment of an endpoint in a scalable and extensible way. The
assessment. It is meant to be a basis for the development of information model aims to inform the development of specific data
specific data models. The terms information model and data model models that support the endpoint posture assessment process. The
loosely align with the definitions in RFC3444 [RFC3444]. terms "information model" and "data model" align with the definitions
in [RFC3444].
The four primary activities to support this information model are: The five primary activities to support this information model are:
1. Endpoint Identification 1. Endpoint Identification
2. Endpoint Characterization 2. Endpoint Characterization
3. Endpoint Attribute Expression/Representation 3. Endpoint Attribute Expression
4. Policy evaluation expression and results reporting 4. Guidance Expression
5. Endpoint Evaluation Result Expression
These activities are aimed at the level of the technology that These activities are aimed at the level of the technology that
performs operations to support collection, evaluation, and reporting. performs operations to support the collection, communication, and
evaluation of endpoint information.
Review of the SACM Use Case [RFC7632] usage scenarios show a common Review of the SACM Use Case [RFC7632] usage scenarios show a common
set of business process areas that are critical to understanding set of business process areas that are critical to understanding
endpoint posture such that appropriate policies, security endpoint posture such that appropriate policies, security
capabilities, and decisions can be developed and implemented. capabilities, and decisions can be developed and implemented.
For this information model we have chosen to focus on the following For this information model we have chosen to focus on the following
business process areas: business process areas:
o Endpoint Management o Endpoint Management
o Software Management o Software Inventory Management
o Hardware Inventory Management
o Configuration Management o Configuration Management
o Vulnerability Management o Vulnerability Management
These management process areas are a way to connect the SACM use These management process areas are a way to connect the SACM use
cases and building blocks [RFC7632] to the organizational needs such cases and building blocks [RFC7632] to the organizational needs such
that the definition of information requirements has a clearly that the definition of information requirements has a clearly
understood context. (/wandw). For more information, Appendix B maps understood context. For more information, see Appendix B which maps
the SACM information model to the SACM use cases. the SACM information model to the SACM use cases.
The SACM information model offers a loose coupling between providers The SACM information model offers a loose coupling between providers
and consumers of security information. A provider can relay what it and consumers of security information. A provider can relay what it
observes or infers, without knowing which consumers will use the observes or infers, without knowing which consumers will use the
information, or how they will use it. A consumer need not know information, or how they will use it. A consumer need not know
exactly which provider generated a piece of information, or by what exactly which provider generated a piece of information, or by what
method. method.
At the same time, a consumer *can* know these things, if necessary. At the same time, a consumer *can* know these things, if necessary.
As things evolve, a provider can relay supplemental information. As things evolve, a provider can relay supplemental information.
Some consumers will understand and benefit from the supplemental Some consumers will understand and benefit from the supplemental
information; other consumers will not understand and will disregard information; other consumers will not understand and will disregard
it. it.
1.1. Problem Statement 1.1. Problem Statement
TODO: revise SACM requires a large and broad set of mission and business
processes, and to make the most effective use of technology, the same
data must support multiple processes. The activities and processes
described within this document tend to build off of each other to
enable more complex characterization and assessment. In an effort to
create an information model that serves a common set of management
processes represented by the usage scenarios in the SACM Use Cases
[RFC7632], we have narrowed down the scope of this model to focus on
the information needs required for endpoint identification, endpoint
characterization, endpoint attribute expression, guidance expression,
and endpoint evaluation result expression.
(wandw)SACM requires a large and broad set of mission and business
processes, and to make the most effective of use of technology, the
same data must support multiple processes. The activities and
processes described within this document tend to build off of each
other to enable more complex characterization and assessment. In an
effort to create an information model that serves a common set of
management processes represented by the usage scenarios in the SACM
Use Cases document, we have narrowed down the scope of this
model.(/wandw) [What does "narrowed down the scope of this model"
mean? - LL]
Administrators can't get technology from disparate sources to work Administrators can't get technology from disparate sources to work
together; they need information to make decisions, but the together; they need information to make decisions, but the
information is not available. Everyone is collecting the same data, information is not available. Everyone is collecting the same data,
but storing it as different information. Administrators therefore but storing it as different information. Administrators therefore
need to collect data and craft their own information, which may not need to collect data and craft their own information, which may not
be accurate or interoperable because it's customized by each be accurate or interoperable because it's customized by each
administrator, not shared. A standard information model enables administrator, not shared. A standard information model enables
flexibility in collecting, storing, and sharing information despite flexibility in collecting, storing, and exchanging information
platform differences. despite platform differences.
A way is needed to exchange information that (a) has breadth, meaning A way is needed to exchange information that (a) has breadth, meaning
the pieces of the notation are useful about a variety of endpoints the pieces of the notation are useful for a variety of endpoint
and software components, and (b) has longevity, meaning that the information, and (b) has longevity, meaning that the pieces of the
pieces of the notation will stay useful over time. notation will stay useful over time.
When creating standards, it's not sufficient to go from requirements When creating standards, it's not sufficient to go from the
directly to protocol; the standards must eliminate ambiguity in the requirements directly to the protocol; the standards must eliminate
information transported. This is the purpose of information models ambiguity in the information transported. This is the purpose of
generally. The SACM problem space is about integrating many information models generally. The SACM problem space is about
information sources. This information model addresses the need to integrating many information sources. This information model
integrate security components, support multiple data models, and addresses the need to integrate security components, support multiple
provide interoperability in a way that is platform agnostic, scales, data models, and provide interoperability in a way that is platform
and works over time. agnostic, scales, and works over time.
1.1.1. Referring to an Endpoint 1.1.1. Referring to an Endpoint
How to refer to an endpoint is problematic. Ideally, an endpoint How to refer to an endpoint is problematic. Ideally, an endpoint
would have a unique identifier. These identifiers would have a one- would have a unique identifier. These identifiers would have a one-
to-one relationship with endpoints. Every observation of an to-one relationship with endpoints. Every observation of an
endpoint, or inference about an endpoint would be labeled with its endpoint, or inference about an endpoint would be labeled with its
identifier. identifier.
However: However:
o An external posture attribute collector typically cannot observe o An external posture attribute collector typically cannot observe
the unique identifier directly. An external posture attribute the unique identifier directly. An external posture attribute
collector should be able to report exactly what it has observed, collector should be able to report exactly what it has observed,
unembellished. It should not have to *infer* which endpoint it unembellished. It should not have to *infer* which endpoint it
has observed; that inference should be leavable to other SACM has observed; that inference should be left to other SACM
components. So, SACM cannot require that every observation components. So, SACM cannot require that every observation
include the unique endpoint identifier. include the unique endpoint identifier.
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 as a unique certificate within a hardware cryptographic module.
so, it is possible to replace all of the software -- for example, Even so, it is possible to replace all of the software -- for
changing a Windows machine to a Linux machine. Is it still the example, changing a Windows machine to a Linux machine. Is it
same endpoint? For SACM purposes, it isn't really the same still the same endpoint? For SACM purposes, it isn't really the
endpoint. same 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.
1.1.2. Dealing with Uncertainty 1.1.2. Dealing with Uncertainty
With many information models, the information is considered certain. With many information models, the information is considered certain.
In SACM, information is not certain. Attackers may develop In SACM, information is not certain. Attackers may develop
countermeasures to fool some SACM components. Attackers may countermeasures to fool some SACM components. Attackers may
compromise some SACM components. compromise some SACM components.
So the model must let SACM components and humans reason with So the model must let SACM components and humans reason with
uncertainty. There are no facts, only assertions. uncertainty. There are no facts, only assertions.
SACM components must be able to cross check observations and SACM components must be able to cross check observations and
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.
Although SACM will probably not prescribe *how* to do this cross Although SACM will probably not prescribe *how* to do this cross
checking, SACM should provide the components with provenance checking, SACM should provide the components with information that
information. can be used to determine provenance.
SACM components must be able to consider the reputation of the SACM components must be able to consider the reputation of the
observer or inferrer. That reputation should account for the method observer or inferrer. That reputation should account for the method
of observing or inferring, the implementer of the SACM component that of observing or inferring, the implementer of the SACM component that
made the observation or inference, and the compliance status of the made the observation or inference, and the compliance status of the
endpoint on which the observation or inference was made. For endpoint on which the observation or inference was made. For
example, if some observers are found to be vulnerable to a Day 1 example, if some observers are found to be vulnerable to a Day 1
exploit, observations from those observers deserve less weight. The exploit, observations from those observers deserve less weight. The
details of reputation technology may be out of scope for SACM. details of reputation technology may be out of scope for SACM.
However, again, SACM should provide components with provenance However, again, SACM should provide components with information that
information. enables them to make this determination.
2. Conventions used in this document 2. Conventions used in this document
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Information Model Framework 3. Information Model Framework
The SACM information model is structured around a core framework that The SACM information model is structured around a core framework that
can be easily extended to support the modeling needs for endpoint can be easily extended to support the modeling needs for endpoint
skipping to change at page 9, line 15 skipping to change at page 11, line 18
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Information Model Framework 3. Information Model Framework
The SACM information model is structured around a core framework that The SACM information model is structured around a core framework that
can be easily extended to support the modeling needs for endpoint can be easily extended to support the modeling needs for endpoint
posture assessment. This section describes the key concepts that posture assessment. This section describes the key concepts that
make up this framework as well as the conventions used to model the make up this framework as well as the IP Information Flow Export
different information model objects in the following sections. (IPFIX) Information Model [RFC7012] syntax used to model the
different information model concepts.
3.1. Containers 3.1. Attributes
TODO: Explain containers at a conceptual level and how they are the Attributes are used to model specific endpoint information. At a
mechanism by which attributes and/or other containers can be minimum, an attribute must have a name and a value. Additional
logically grouped together to create more complex models. Additional information about attributes can be modeled using metadata as
information about containers can be modeled using metadata. described in Section 3.3.
QUESTION: We are not sure "container" is the correct term to use here
as it implies a hierarchy. Alternative terms might be "construct",
"object", or "class". This is something that needs to be decided.
3.2. Attributes 3.1.1. Syntax
TODO: Explain attributes at a conceptual level and how they are used Attributes must be defined using the IPFIX Information Element
to model posture attribute information on an endpoint. At a minimum, Specification Template as described in Section 2.1 of [RFC7012]. The
an attribute must have a name and a value. However, there is work following is a modified version of the template for Information
currently being done in the Endpoint ID Design Team to prepare a Elements provided in Section 9.1 of [RFC7013].
proposal for the working group to explain how triples (subject,
predicate, object) could be used to model attributes in the elementId: Element identifier goes here if known, or
information model. Additional information about attributes can be "TBD" if it will be assigned by IANA and
modeled using metadata. filled in at publication time.; obligatory
name: Name goes here.; obligatory
dataType: Data type goes here; obligatory
status: Status goes here; obligatory
description: Description goes here.; obligatory
For Information Elements that
represent flags, please include a
table that lists each flag value
(hexadecimal) and description.
The following is a template for that
table.
+-------+----------------------------------+
| Value | Description |
+-------+----------------------------------+
| | |
+-------+----------------------------------+
dataTypeSemantics: Data type semantics, if any, go here; optional
units: Units, if any, go here; optional
range: Range, if not implied by the data type, goes
here; optional
references: References to other RFCs or documents outside
the IETF, in which additional information is
given, or which are referenced by the
description, go here; optional
Figure 1
3.2. Objects
Objects are the mechanism by which attributes (Section 3.1) and/or
other objects can be logically grouped together to create more
complex models. Additional information about objects can be modeled
using metadata as described in Section 3.3.
3.2.1. Syntax
Objects are complex Information Elements that can be created using
one of the following IPFIX constructs that are defined in Section 3.1
of [RFC7012].
o basicList: a list of zero or more instances of any Information
Element
o subTemplateList: a list of zero or more instances of a single,
specific Template
o subTemplateMultiList: a list of zero or more instances of any
Template
The following is a modified version of the template for Information
Elements provided in Section 9.1 of [RFC7013] that can be used to
model objects.
elementId: Element identifier goes here if known, or
"TBD" if it will be assigned by IANA and
filled in at publication time.; obligatory
name: Name goes here.; obligatory
dataType: Data type goes here; obligatory
status: Status goes here; obligatory
description: Description goes here.; obligatory
Please include a high-level model diagram that uses
the following format which is a simplified version
of a high-level diagram format used in [RFC6313].
<IE-Name> = (<IE-DataType>, <IE-DataTypeSemantic>,
<IE-1>,
<IE-2>,
<IE-3>,
...
)
dataTypeSemantics: Data type semantics, if any, go here; optional
units: Units, if any, go here; optional
range: Range, if not implied by the data type, goes
here; optional
references: References to other RFCs or documents outside
the IETF, in which additional information is
given, or which are referenced by the
description, go here; optional
Figure 2
3.3. Metadata 3.3. Metadata
TODO: Explain metadata at a conceptual level and how it can be used Metadata allows components to annotate objects and attributes with
to provide additional information about containers and attributes. additional information that will allow other components to make a
We should be providing enough information so that SACM users can determination about the provenance of the objects and attributes
determine provenance (e.g. source of origin, time of collection, during exchanges and evaluations. A proposal outlining various
observation, reporting, etc.) and use it when sharing and evaluating options for representing metadata attributes/objects in the IPFIX
posture attribute information. syntax is being discussed on the mailing list. TODO: See IM issue
#39 at https://github.com/sacmwg/draft-ietf-sacm-information-model/
issues/39 for more information.
3.4. Relationships 3.4. Relationships
TODO: Define what a relationship is. At the end of the day, we want TODO: Define what a relationship is. At the end of the day, we want
to be able to describe the relationships between assets, endpoints, to be able to describe the relationships between assets, endpoints,
and attributes. QUESTION: Are relationships just metadata? Lisa's and attributes. QUESTION: Are relationships just metadata? Lisa's
notes have some information on relationships: notes have some information on relationships:
https://mailarchive.ietf.org/arch/msg/sacm/ https://mailarchive.ietf.org/arch/msg/sacm/
kWxlnboHAXD87cned9WavwPZy5w kWxlnboHAXD87cned9WavwPZy5w. We also want to consider the
relationships proposed by Nancy and Henk in
https://www.ietf.org/proceedings/94/slides/slides-94-sacm-7.pdf.
Nancy and Henk expect to provide additional information related to
their Information Model work that can be merged into this document at
some point. The information is expected to be ready in advance of
IETF 95. Please see issue #39 at https://github.com/sacmwg/draft-
ietf-sacm-information-model/issues/39 for more information.
3.5. Designation 3.5. Designation
TODO: In the IETF, there are privacy concerns with respect to TODO: In the IETF, there are privacy concerns with respect to
endpoint identity and monitoring. As a result, the Endpoint ID endpoint identity and monitoring. As a result, the Endpoint ID
Design Team proposes that "endpoint identity" be changed to "endpoint Design Team proposes that "endpoint identity" be changed to "endpoint
designation". Designation attributes can be used to correlate designation". Designation attributes can be used to correlate
endpoints, information about endpoints, events, etc. NOTE: endpoints, information about endpoints, events, etc. NOTE:
Designation attributes are just those that are mandatory-to- Designation attributes are just those that are mandatory-to-
implement. In practice, organizations may need to select additional implement. In practice, organizations may need to select additional
attributes beyond the mandatory-to-implement attributes to attributes beyond the mandatory-to-implement attributes to
successfully identify an endpoint on their network. Operational and successfully identify an endpoint on their network. Operational and
privacy concerns will be covered in Operational Considerations and privacy concerns will be covered in Operational Considerations and
Privacy Considerations sections respectively. Privacy Considerations sections respectively. A proposal outlining
various options for representing designation attributes/objects in
the IPFIX syntax is being discussed on the mailing list. See IM
issue #39 at https://github.com/sacmwg/draft-ietf-sacm-information-
model/issues/39 for more information.
3.6. Conventions for Modeling Information Model Objects 3.6. Privacy
TODO: The working group needs to select the conventions that will be TODO: In the IETF, there are privacy concerns with respect to
used to model the different objects defined in the information model. endpoint identity and monitoring. As a result, it was proposed that
Members of the Endpoint ID Design Team are looking into different a privacy property be included to denote when a information element
examples of how other working groups have modeled the objects in represents a privacy concern. A proposal outlining various options
their information models so that the working can select one that for representing privacy attributes/objects in the IPFIX syntax is
makes the most sense for SACM. Once conventions have been selected, being discussed on the mailing list. See IM issue #39 at
they should be documented here for future reference. https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39
for more information.
3.7. Type Space
This section describes the abstract data types that can be used for
the specification of the SACM Information Elements in Section 5.
Section 3.7.1 describes the set of abstract data types. This section
used Section 3 of [RFC7012] as a starting point and was modified to
address the needs of SACM.
3.7.1. Abstract Data Types
This section describes the set of valid abstract data types of the
SACM information model, independent of how they are implemented in a
data model. Note that further abstract data types may be specified
by future extensions of the SACM information model.
3.7.1.1. unsigned8
The type "unsigned8" represents a non-negative integer value in the
range of 0 to 255.
3.7.1.2. unsigned16
The type "unsigned16" represents a non-negative integer value in the
range of 0 to 65535.
3.7.1.3. unsigned32
The type "unsigned32" represents a non-negative integer value in the
range of 0 to 4294967295.
3.7.1.4. unsigned64
The type "unsigned64" represents a non-negative integer value in the
range of 0 to 18446744073709551615.
3.7.1.5. signed8
The type "signed8" represents an integer value in the range of -128
to 127.
3.7.1.6. signed16
The type "signed16" represents an integer value in the range of
-32768 to 32767.
3.7.1.7. signed32
The type "signed32" represents an integer value in the range of
-2147483648 to 2147483647.
3.7.1.8. signed64
The type "signed64" represents an integer value in the range of
-9223372036854775808 to 9223372036854775807.
3.7.1.9. float32
The type "float32" corresponds to an IEEE single-precision 32-bit
floating point type as defined in [IEEE.754.1985].
3.7.1.10. float64
The type "float64" corresponds to an IEEE double-precision 64-bit
floating point type as defined in [IEEE.754.1985].
3.7.1.11. boolean
The type "boolean" represents a binary value. The only allowed
values are "true" and "false".
3.7.1.12. macAddress
The type "macAddress" represents a MAC-48 address as defined in
[IEEE.802-3.2012].
3.7.1.13. string
The type "string" represents a finite-length string of valid
characters from the Unicode coded character set [ISO.10646]. Unicode
incorporates ASCII [RFC20] and the characters of many other
international character sets.
3.7.1.14. dateTimeSeconds
The type "dateTimeSeconds" represents a time value expressed with
second-level precision.
3.7.1.15. dateTimeMilliseconds
The type "dateTimeMilliseconds" represents a time value expressed
with millisecond-level precision.
3.7.1.16. dateTimeMicroseconds
The type "dateTimeMicroseconds" represents a time value expressed
with microsecond-level precision.
3.7.1.17. dateTimeNanoseconds
The type "dateTimeNanoseconds" represents a time value expressed with
nanosecond-level precision.
3.7.1.18. ipv4Address
The type "ipv4Address" represents an IPv4 address as defined in
[RFC0791].
3.7.1.19. ipv6Address
The type "ipv6Address" represents an IPv6 address as defined in
[RFC3587].
3.7.1.20. basicList
The type "basicList" represents a list of zero or more instances of
any Information Element as defined in [RFC6313].
3.7.1.21. subTemplateList
The type "subTemplateList" represents a list of zero or more
instances of a structured data type, where the data type of each list
element is the same and corresponds with a single Template Record as
defined in [RFC6313].
3.7.1.22. subTemplateMultiList
The type "subTemplateMultiList" represents a list of zero or more
instances of a structured data type, where the data type of each list
element can be different and corresponds with different Template
definitions as defined in [RFC6313].
3.7.2. Data Type Semantics
This section describes the set of valid data type semantics of the
IPFIX information model.
Further data type semantics may be specified by future updates to
this document. Changes to the associated "IPFIX Information Element
Semantics" subregistry [IANA-IPFIX] require a Standards Action
[RFC5226].
3.7.3. quantity
"quantity" is a numeric (integral or floating point) value
representing a measured value pertaining to the record. This is
distinguished from counters that represent an ongoing measured value
whose "odometer" reading is captured as part of a given record. This
is the default semantic type of all numeric data types.
3.7.4. totalCounter
"totalCounter" is an integral value reporting the value of a counter.
Counters are unsigned and wrap back to zero after reaching the limit
of the type. For example, an unsigned64 with counter semantics will
continue to increment until reaching the value of 2**64 - 1. At this
point, the next increment will wrap its value to zero and continue
counting from zero. The semantics of a total counter is similar to
the semantics of counters used in the Simple Network Management
Protocol (SNMP), such as Counter32 as defined in [RFC2578]. The only
difference between total counters and counters used in SNMP is that
the total counters have an initial value of 0. A total counter
counts independently of the export of its value.
3.7.5. deltaCounter
"deltaCounter" is an integral value reporting the value of a counter.
Counters are unsigned and wrap back to zero after reaching the limit
of the type. For example, an unsigned64 with counter semantics will
continue to increment until reaching the value of 2**64 - 1. At this
point, the next increment will wrap its value to zero and continue
counting from zero. The semantics of a delta counter is similar to
the semantics of counters used in SNMP, such as Counter32 as defined
in [RFC2578]. The only difference between delta counters and
counters used in SNMP is that the delta counters have an initial
value of 0. A delta counter is reset to 0 each time it is exported
and/or expires without export.
3.7.6. identifier
"identifier" is an integral value that serves as an identifier.
Specifically, mathematical operations on two identifiers (aside from
the equality operation) are meaningless. Identifiers MUST be one of
the signed or unsigned data types.
3.7.7. flags
"flags" is an integral value that represents a set of bit fields.
Logical operations are appropriate on such values, but other
mathematical operations are not. Flags MUST always be of an unsigned
data type.
3.7.8. list
A list represents an arbitrary-length sequence of zero or more
Information Elements, either composed of regular Information Elements
or composed of data conforming to a Template Record. See [RFC6313].
4. Information Model Assets 4. Information Model Assets
TODO: Explain the different SACM assets. Right now, we have TODO: Explain the different SACM assets. Right now, we have
distilled this down to an endpoint, hardware, software, and identity. distilled this down to an endpoint, hardware, software, and identity.
Previously, this diagram also included account, location, address, Previously, this diagram also included account, location, address,
and network inteface, but, these things are not assets and can either and network inteface, but, these things are not assets and can either
be consolidated into one of the existing asset types (e.g. network be consolidated into one of the existing asset types (e.g. network
interface => hardware, account => identity, etc.) or are just interface => hardware, account => identity, etc.) or are just
metadata about the assets (e.g. location => endpoint). We should metadata about the assets (e.g. location => endpoint). We should
skipping to change at page 11, line 27 skipping to change at page 21, line 27
|Instance |__________________|! !| |Instance |__________________|! !|
+---------+* in> 1|! !| +---------+* in> 1|! !|
|! !| |! !|
|! !|____ |! !|____
|! !|0..1| |! !|0..1|
+-----+ | +-----+ |
|* | |* |
|_______| |_______|
in> in>
Figure 1: Model of an Endpoint Figure 3: Model of an Endpoint
4.1. Asset 4.1. Asset
TODO: Define Asset here in the context of the information model. TODO: Define Asset here in the context of the information model.
[I-D.ietf-sacm-terminology] defines an asset as: Defined in
{{RFC4949}} as "a system resource that is (a) required to be
protected by an information system's security policy, (b) intended to
be protected by a countermeasure, or (c) required for a system's
mission". In the scope of SACM, an asset can be composed of other
assets. Examples of Assets include: Endpoints, Software, Guidance,
or X.509 public key certificates. An asset is not necessarily owned
by an organization.
4.2. Endpoint 4.2. Endpoint
TODO: Define an Endpoint asset. Explain how it is made up of HW TODO: Define an Endpoint asset. Explain how it is made up of HW
components, SW components, asset identity, etc. Take relevant components, SW components, asset identity, etc.
information from the
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.3. Hardware Component 4.3. Hardware Component
skipping to change at page 15, line 15 skipping to change at page 25, line 25
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 2 introduces the endpoint attributes and their relationships. Figure 4 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 |
skipping to change at page 15, line 39 skipping to change at page 25, line 49
|Instance|________________|! !| *|for |* |Instance|________________|! !| *|for |*
+--------+* in> 1|! !|______+---------+ +-------+ +--------+* in> 1|! !|______+---------+ +-------+
|! !|1 <in *|Network |1_______*|Address| |! !|1 <in *|Network |1_______*|Address|
|! !|____ |Interface| <bound +-------+ |! !|____ |Interface| <bound +-------+
|! !|0..1| +---------+ to |! !|0..1| +---------+ to
+-----+ | *| |0..1 +-----+ | *| |0..1
|* | |___| |* | |___|
|_______| in> |_______| in>
in> in>
Figure 2: Model of an Endpoint Figure 4: Model of an Endpoint
ISSUE (CEK): we agreed to remove location and account from the model, ISSUE (CEK): we agreed to remove location and account from the model,
did we not? TODO: Remove Network Interface, Location, Address, and did we not? TODO: Remove Network Interface, Location, Address, and
Account from this diagram if we end up removing the corresponding Account from this diagram if we end up removing the corresponding
sections from the information model. sections from the information model.
Figure 3 is the core of the information model. It represents the Figure 5 is the core of the information model. It represents the
information elements and their relationships. information elements and their relationships.
+-----+ +---------+ +-----+ +---------+
| AVP |____________|Endpoint | | AVP |____________|Endpoint |
+-----+1..* 1|Attribute| +-----+1..* 1|Attribute|
|Assertion| |Assertion|
+---------+ +---------+
|* +-------+ |* +-------+
| |Summary| | |Summary|
| +-------+ | +-------+
|produced-by *| |produced-by *|
|V | |V |
1| | 1| |
+--------+ +-----------+ | +--------+ +-----------+ |
| | | SACM |____________________| | | | SACM |____________________|
|Guidance| | Component |1 <produced-by |Guidance| | Component |1 <produced-by
+--------+*____________1+-----------+ +--------+*____________1+-----------+
<produced-by <produced-by
Figure 3: Information Elements Figure 5: Information Elements
Figure 4 is a potential alternative structure for assertions. It is Figure 6 is a potential alternative structure for assertions. It is
inspired by triple stores. See http://www.w3.org/TR/2014/REC-rdf11- inspired by triple stores. See http://www.w3.org/TR/2014/REC-rdf11-
concepts-20140225/. concepts-20140225/.
+-----+______________+---------+ +---------+ +-----+______________+---------+ +---------+
| AVP |1 <subject *|assertion|________________|predicate| | AVP |1 <subject *|assertion|________________|predicate|
| |______________| |* predicate> 1+---------+ | |______________| |* predicate> 1+---------+
+-----+1 <object *+---------+ +-----+1 <object *+---------+
1^ |* 1^ |*
|_____________________| |_____________________|
<asserter <asserter
Figure 4: Information Elements, Take 2 Figure 6: Information Elements, Take 2
Note: UML 2 is specified by [UML]. Note: UML 2 is specified by [UML].
TODO: update text to match new figure: TODO: update text to match new figure:
Need to be clear in the description that ??? Need to be clear in the description that ???
For some of the relationships, will need some language and guidance For some of the relationships, will need some language and guidance
to the interfaces and relationships we expect to have happen, MUSTs to the interfaces and relationships we expect to have happen, MUSTs
and SHOULDs, as well as explaining the extensibility that other and SHOULDs, as well as explaining the extensibility that other
relationships can exist, show examples of how that can happen. relationships can exist, show examples of how that can happen.
Others that we haven't thought of yet, might be added by another RFC Others that we haven't thought of yet, might be added by another RFC
or in another way or in another way
5.1. Identifying Attributes 5.1. Identifying Attributes
TODO: Need to rename this section to align with new "designation" TODO: Need to rename this section to align with new "designation"
skipping to change at page 18, line 19 skipping to change at page 28, line 28
use these markings. use these markings.
5.1.2. Whether to Include 5.1.2. Whether to Include
When publishing an endpoint attribute assertion, the provider MUST When publishing an endpoint attribute assertion, the provider MUST
publish at least all common identifying AVPs that it knows through publish at least all common identifying AVPs that it knows through
verification. If the provider knows none through verification but it verification. If the provider knows none through verification but it
knows at least one in another way, it MUST publish at least one. The knows at least one in another way, it MUST publish at least one. The
provider SHOULD publish all common identifying AVPs it knows. provider SHOULD publish all common identifying AVPs it knows.
5.1.3. IP Address 5.1.3. Certificate
5.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.
5.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.
5.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?)
5.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.
5.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.
5.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.
5.1.3.7. Data Model Requirements
All SACM data models MUST support this entire subsection.
5.1.4. MAC Address
TODO
5.1.5. Hardware Serial Number
5.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.
5.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.
5.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.
5.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*.
5.1.5.5. Accuracy
5.1.5.6. Data Model Requirements
All SACM data models MUST support this entire subsection.
5.1.6. Certificate
5.1.6.1. Range of values 5.1.3.1. Range of values
MUST be X.509 certificate, per [RFC5280]. MUST be X.509 certificate, per [RFC5280].
5.1.6.2. Meaning 5.1.3.2. Meaning
Throughout the time interval of the AVP, the endpoint had the private Throughout the time interval of the AVP, the endpoint had the private
key corresponding to the specified certificate. key corresponding to the specified certificate.
Throughout the time interval, the certificate was valid: it had a Throughout the time interval, the certificate was valid: it had a
valid certificate chain from a CA certificate that the asserter valid certificate chain from a CA certificate that the asserter
trusted; every certificate in the chain was time-valid; no trusted; every certificate in the chain was time-valid; no
certificate in in the chain (excluding the CA certificate) was certificate in in the chain (excluding the CA certificate) was
revoked. ISSUE (CEK): Do we want to get this PKI-ish? If so, would revoked. ISSUE (CEK): Do we want to get this PKI-ish? If so, would
we include the CA certificate as well? we include the CA certificate as well?
5.1.6.3. Multiplicity 5.1.3.3. Multiplicity
An endpoint may use, or have the right to use, one or more An endpoint may use, or have the right to use, one or more
certificates. certificates.
Some certificates may be used on more than one endpoint. Other Some certificates may be used on more than one endpoint. Other
certificates are (by intent) bound to a single endpoint. ISSUE certificates are (by intent) bound to a single endpoint. ISSUE
(CEK): Is there a standard way to distinguish the two? We could (CEK): Is there a standard way to distinguish the two? We could
perhaps provide a configurable criterion, as an information element. perhaps provide a configurable criterion, as an information element.
Should we? Should we?
5.1.6.4. Stability 5.1.3.4. Stability
Certificates are replaced, due to expiration and other reasons. By Certificates are replaced, due to expiration and other reasons. By
and large, they are not replaced often. A year is a typical and large, they are not replaced often. A year is a typical
interval. In sum, they are persistent. interval. In sum, they are persistent.
A private key is baked into hardware is almost immutable. But again, A private key is baked into hardware is almost immutable. But again,
hardware can be replaced. hardware can be replaced.
5.1.6.5. Accuracy 5.1.3.5. Accuracy
If a certificate is known by verification, the attribute is highly If a certificate is known by verification, the attribute is highly
accurate. accurate.
5.1.6.6. Data model requirements 5.1.3.6. Data model requirements
All SACM data models MUST support this entire subsection. All SACM data models MUST support this entire subsection.
5.1.7. Public Key 5.1.4. Public Key
TODO TODO
5.1.8. Username? 5.1.5. Username?
ISSUE (CEK): If a user certificate can be an identifying attribute, ISSUE (CEK): If a user certificate can be an identifying attribute,
why not a username also? At an earlier stage of our discussions, why not a username also? At an earlier stage of our discussions,
usernames were considered common identifying attributes. Did we usernames were considered common identifying attributes. Did we
decide they should not be? Or just forget them? decide they should not be? Or just forget them?
Many endpoints do not have client certificates. An authenticated Many endpoints do not have client certificates. An authenticated
username is a useful clue for identifying such an endpoint. I log in username is a useful clue for identifying such an endpoint. I log in
only to a handful of personal endpoints. I also present my username only to a handful of personal endpoints. I also present my username
and password to many multi-user servers. We would have to and password to many multi-user servers. We would have to
distinguish personal endpoints from server endpoints somehow. distinguish personal endpoints from server endpoints somehow.
5.1.9. Tool-Specific Identifier 5.1.6. Tool-Specific Identifier
TODO TODO
TODO: "Tool-specific identifier" suggests that two tools could never TODO: "Tool-specific identifier" suggests that two tools could never
agree on a tool-specific identifier. But a community may agree on an agree on a tool-specific identifier. But a community may agree on an
identifier notation, and might even create a formal standard. All identifier notation, and might even create a formal standard. All
that's important is that each of these attributes has a type and that's important is that each of these attributes has a type and
meaning *not* specified by the SACM internet drafts. "Vendor- meaning *not* specified by the SACM internet drafts. "Vendor-
specific identifier?" "Custom identifier?" specific identifier?" "Custom identifier?"
5.1.10. Identification of Endpoints where SACM Components Reside 5.1.7. Identification of Endpoints where SACM Components Reside
Every information element needs identifying attributes of its Every information element needs identifying attributes of its
producer's endpoint. (TODO: Provide normative language. SHOULD? producer's endpoint. (TODO: Provide normative language. SHOULD?
MUST?) MUST?)
Specifically, in an endpoint attribute assertion, we need identifying Specifically, in an endpoint attribute assertion, we need identifying
attributes of the asserter's endpoint. If the asserter is external, attributes of the asserter's endpoint. If the asserter is external,
the assertion will contain identifying attributes of two endpoints. the assertion will contain identifying attributes of two endpoints.
(TODO: Discuss what this information is for.) (TODO: Discuss what this information is for.)
5.1.11. Security Considerations 5.1.8. Security Considerations
Effects of misidentification Effects of misidentification
Things that can cause misidentification Things that can cause misidentification
How minimize misidentification How minimize misidentification
5.2. Network Interface 5.2. Identity
An endpoint generally has at least one network interface.
Interfaces nest. A virtual interface can nest in a physical
interface.
A data model MUST support the following relationships:
o A network interface is "in" an endpoint.
o A network interface is "in" another network interface; this is for
a nested interface. CEK: And this allows representing compliance
policies that are worthwhile. But is this too advanced for the
initial set of SACM RFCs?
o A network interface "acts for" an identity. This occurs, for
example, when the network interface is online because of
successful 802.1X. An internal collector may be aware of the
identity. An external collector (such as a RADIUS server
[RFC3580]) will be aware of the identity.
5.3. Address
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
MAY support others
o A layer 3 address; a data model MUST support IPv4 and IPv6
addresses, and MAY support others
o A layer 4 address; a data model MUST support an IP-address-
protocol-port combination, where protocol is TCP or UDP. It MAY
support others
Addresses from other layers may be added in the future.
These addresses are not necessarily globally unique. Therefore, a
data model SHOULD allow an address to be qualified with a scope.
o A data model SHOULD allow qualifying a MAC address with its
layer-2 broadcast domain. This MAY take the form of a VLAN ID and
an administratively assigned string denoting the LAN.
o A data model SHOULD allow qualifying an IP address with an
administratively assigned string denoting the IP routing domain.
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.
5.4. Identity
TODO: Delete this section? TODO: Delete this section?
An identity is the non-secret part of a credential. Examples are a An identity is the non-secret part of a credential. Examples are a
username, an X.500 distinguished name, and a public key. Passwords, username, an X.500 distinguished name, and a public key. Passwords,
private keys, and other secrets are not considered part of an private keys, and other secrets are not considered part of an
identity. identity.
A data model MUST support the following relationships: A data model MUST support the following relationships:
skipping to change at page 25, line 5 skipping to change at page 31, line 5
logs into the endpoint with her AD username (alice) and password, logs into the endpoint with her AD username (alice) and password,
the endpoint "acts for" alice. An endpoint MAY "act for" more the endpoint "acts for" alice. An endpoint MAY "act for" more
than one identity, such as a machine identity and a user identity. than one identity, such as a machine identity and a user identity.
o A identity may "belong to" an account. For example, an enterprise o A identity may "belong to" an account. For example, an enterprise
may have a database that maps identities to accounts. CEK: Is may have a database that maps identities to accounts. CEK: Is
this relevant? I don't see how we'd use the notion of an account this relevant? I don't see how we'd use the notion of an account
in identifying an endpoint or in specifying compliance in identifying an endpoint or in specifying compliance
measurements to be taken. measurements to be taken.
5.5. Location 5.3. Location
TODO: Delete this section? TODO: Delete this section?
Location can be logical or physical. Location can be a clue to an Location can be logical or physical. Location can be a clue to an
endpoint's identity. endpoint's identity.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o One or more endpoints may be "in" a location o One or more endpoints may be "in" a location
skipping to change at page 26, line 5 skipping to change at page 32, 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.
5.6. Endpoint Attribute Assertion 5.4. Endpoint Attribute Assertion
TODO: Integrate into the Section 3 as appropriate. TODO: Integrate into the Section 3 as appropriate.
5.6.1. Form and Precise Meaning 5.4.1. Form and Precise Meaning
An endpoint attribute assertion has: An endpoint attribute assertion has:
o One or more attribute-value pairs (AVPs) o One or more attribute-value pairs (AVPs)
o Time intervals over which the AVPs hold o Time intervals over which the AVPs hold
o Endpoint uniquely identified? True or false o Endpoint uniquely identified? True or false
o Provenance, including: o Provenance, including:
skipping to change at page 26, line 42 skipping to change at page 32, line 42
attributes. The model does not make a rigid distinction between the attributes. The model does not make a rigid distinction between the
two uses of attributes. two uses of attributes.
Some of the attributes may be multi-valued. Some of the attributes may be multi-valued.
One of the AVPs may be a unique endpoint identifier. Not every One of the AVPs may be a unique endpoint identifier. Not every
endpoint will have one. If there is one, the SACM component that endpoint will have one. If there is one, the SACM component that
produces the Endpoint Attribute Assertion will not necessarily know produces the Endpoint Attribute Assertion will not necessarily know
what it is. what it is.
5.6.2. Asserter 5.4.2. Asserter
An Endpoint Attribute Assertion may come from an attribute collector An Endpoint Attribute Assertion may come from an attribute collector
or an evaluator. It may come from a SACM component that derives it or an evaluator. It may come from a SACM component that derives it
from out-of-band sources, such as a physical inventory system. A from out-of-band sources, such as a physical inventory system. A
SACM component may derive it from other Endpoint Attribute SACM component may derive it from other Endpoint Attribute
Assertions. Assertions.
5.6.3. Example 5.4.3. Example
For example, an attribute assertion might have these attribute-value For example, an attribute assertion might have these attribute-value
pairs: pairs:
mac-address = 01:23:45:67:89:ab mac-address = 01:23:45:67:89:ab
os = OS X os = OS X
os-version = 10.6.8 os-version = 10.6.8
This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran
OS X 10.6.8 throughout the specified time interval. A profiler might OS X 10.6.8 throughout the specified time interval. A profiler might
have provided this assertion. have provided this assertion.
5.6.4. A Use Case 5.4.4. A Use Case
For example, Endpoint Attribute Assertions should help SACM For example, Endpoint Attribute Assertions should help SACM
components to track an endpoint as it roams or stays stationary. components to track an endpoint as it roams or stays stationary.
They must track endpoints because they must track endpoints' postures They must track endpoints because they must track endpoints' postures
over time. Tracking of an endpoint can employ many clues, such as: over time. Tracking of an endpoint can employ many clues, such as:
The endpoint's MAC address The endpoint's MAC address
The authenticated identity (even if it identifies a user) The authenticated identity (even if it identifies a user)
The location of the endpoint and the user The location of the endpoint and the user
5.6.5. Event 5.4.5. Event
An event is represented as a Posture Attribute Assertion whose time An event is represented as a Posture Attribute Assertion whose time
interval has length zero. interval has length zero.
Some potential kinds of events are: Some potential kinds of events are:
o A structured syslog message [RFC5424] o A structured syslog message [RFC5424]
o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA] o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA]
o A NetFlow message [RFC3954] o A NetFlow message [RFC3954]
5.6.6. Difference between Attribute and Event 5.4.6. Difference between Attribute and Event
Author: Henk Birkholz Author: Henk Birkholz
"Attribute" and "event" are often used fairly interchangeably. A "Attribute" and "event" are often used fairly interchangeably. A
clear distinction makes the words more useful. clear distinction makes the words more useful.
An *attribute* tends not to change until something causes a change. An *attribute* tends not to change until something causes a change.
In contrast, an *event* occurs at a moment in time. In contrast, an *event* occurs at a moment in time.
For a nontechnical example, let us consider "openness" as an For a nontechnical example, let us consider "openness" as an
skipping to change at page 28, line 24 skipping to change at page 34, line 24
Similarly, "Host firewall enabled" may be modeled as a true/false Similarly, "Host firewall enabled" may be modeled as a true/false
attribute of an endpoint. Enabling or disabling the host firewall attribute of an endpoint. Enabling or disabling the host firewall
may be modeled as an event. An endpoint's crashing also may be may be modeled as an event. An endpoint's crashing also may be
modeled as an event. modeled as an event.
Although events are not attributes, we use one kind of information Although events are not attributes, we use one kind of information
element, the "Endpoint Attribute Assertion", to describe both element, the "Endpoint Attribute Assertion", to describe both
attributes and events. attributes and events.
5.7. Attribute-Value Pair 5.5. Attribute-Value Pair
TODO: Integrate into the Section 3 as appropriate. TODO: Integrate into the Section 3 as appropriate.
The set of attribute types must be extensible, by other IETF The set of attribute types must be extensible, by other IETF
standards, by other standards groups, and by vendors. How to express standards, by other standards groups, and by vendors. How to express
attribute types is not defined here, but is left to data models. attribute types is not defined here, but is left to data models.
The value may be structured. For example, it may something like XML. The value may be structured. For example, it may something like XML.
The information model requires a standard attribute type (or possibly The information model requires a standard attribute type (or possibly
more than one) for each box in Figure 2: more than one) for each box in Figure 4:
o Hardware Component: the value identifies the hardware type. For o Hardware Component: the value identifies the hardware type. For
example, it may consist of the make and model number. example, it may consist of the make and model number.
o Hardware Instance: the value, together with the Hardware Component o Hardware Instance: the value, together with the Hardware Component
value, uniquely identifies the hardware instance. For example, it value, uniquely identifies the hardware instance. For example, it
may be a manufacturer-assigned serial number. This notion might may be a manufacturer-assigned serial number. This notion might
not apply to all virtual hardware components. not apply to all virtual hardware components.
o Software Component: the value identifies a unit of software. Each o Software Component: the value identifies a unit of software. Each
skipping to change at page 29, line 22 skipping to change at page 35, line 22
o Network Interface: TBD o Network Interface: TBD
o User: [cek: Do we want this? If one user uses different o User: [cek: Do we want this? If one user uses different
credentials at different times, do we think SACM components will credentials at different times, do we think SACM components will
need know that it's the same user?] need know that it's the same user?]
o Address: The value is an IP, MAC, or other network address, o Address: The value is an IP, MAC, or other network address,
possibly qualified with its scope. possibly qualified with its scope.
5.7.1. Unique Endpoint Identifier 5.5.1. Unique Endpoint Identifier
An organization should try to uniquely identify and label an An organization should try to uniquely identify and label an
endpoint, whether the endpoint is enrolled or is discovered in the endpoint, whether the endpoint is enrolled or is discovered in the
operational environment. The identifier should be assigned by or operational environment. The identifier should be assigned by or
used in the enrollment process. used in the enrollment process.
Here "unique" means one-to-one. In practice, uniqueness is not Here "unique" means one-to-one. In practice, uniqueness is not
always attainable. Even if an endpoint has a unique identifier, an always attainable. Even if an endpoint has a unique identifier, an
attribute collector may not always know it. attribute collector may not always know it.
If the attribute type of an AVP is "endpoint", the value is a unique If the attribute type of an AVP is "endpoint", the value is a unique
identifier of the endpoint. identifier of the endpoint.
5.7.2. Posture Attribute 5.5.2. Posture Attribute
Some AVPs will be posture attributes. Some AVPs will be posture attributes.
See the definition in the SACM Terminology for Security Assessment See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
Some potential kinds of posture attributes are: Some potential kinds of posture attributes are:
o A NEA posture attribute (PA) [RFC5209] o A NEA posture attribute (PA) [RFC5209]
o A YANG model [RFC6020] o A YANG model [RFC6020]
o An IF-MAP device-characteristics metadata item o An IF-MAP device-characteristics metadata item
[TNC-IF-MAP-NETSEC-METADATA] [TNC-IF-MAP-NETSEC-METADATA]
5.8. Evaluation Result 5.6. 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 2 does not show Attribute Assertions from which it derives. (Figure 4 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.
5.9. Report 5.7. SACM Component
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? Endpoint ID Design Team:
Yes, it should be removed.
TODO: This should be removed if the working group decides that
reports are out of scope for SACM.
An Endpoint Attribute Assertion concerns a single endpoint.
Assertions about a set of endpoints are also needed -- for example,
for trend analysis and for reports read by humans. These assertions
are termed "reports". SACM components will consume Endpoint
Attribute Assertions and generate reports.
A report contains its provenance, with the same form and meaning as
the provenance of an Endpoint Attribute Assertion.
A Report summarizes:
o Endpoint Attribute Assertions, which may include Evaluation
Results
o Other Reports
A Report may routine or ad hoc.
Some reports may be machine readable. Machine readable reports may
be consumable by SACM components and by automatic response systems
(not specified by SACM).
5.10. SACM Component
Although SACM components are mainly covered by the SACM architecture, Although SACM components are mainly covered by the SACM architecture,
we have some remarks. TODO: Move them to the architecture document? we have some remarks. TODO: Move them to the architecture document?
ISSUE (CEK): Why do we need information elements that model SACM ISSUE (CEK): Why do we need information elements that model SACM
compoments? compoments?
5.10.1. External Attribute Collector 5.7.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 32, line 8 skipping to change at page 37, line 26
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
5.10.2. Evaluator 5.7.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?]
5.10.3. Report Generator 5.8. Organization?
A report generator makes reports based on:
o Endpoint Attribute Assertions, including Evaluation Results
o Other Reports (a weekly report may be created from daily reports)
It may summarize data continually, as the data arrives. It also may
summarize data in response to an ad hoc query.
TODO: This should be removed if the working group decides that
reports are out of scope for SACM.
5.11. Organization?
[kkw-from a reporting standpoint there needs to be some concept like [kkw-from a reporting standpoint there needs to be some concept like
organization or system. without this, there is no way to produce organization or system. without this, there is no way to produce
result reports that can be acted upon to provide the insight or result reports that can be acted upon to provide the insight or
accountability that almost all continuous monitoring instances are accountability that almost all continuous monitoring instances are
trying to achieve. from a scoring or grading standpoint, an endpoint trying to achieve. from a scoring or grading standpoint, an endpoint
needs to be associated with exactly one organization or system. it needs to be associated with exactly one organization or system. it
can have a many to many relationship with other types of results can have a many to many relationship with other types of results
reporting "bins". is this important to include here? we had reporting "bins". is this important to include here? we had
organization as a core asset type for this reason, so i think it is a organization as a core asset type for this reason, so i think it is a
key information element. but i also know that i do not want to define key information element. but i also know that i do not want to define
all the different reporting types, so i am unsure.] all the different reporting types, so i am unsure.]
[cek-I had not thought of this at all. Would it make sense to treat [cek-I had not thought of this at all. Would it make sense to treat
the organization and the bins as part of the guidance for creating the organization and the bins as part of the guidance for creating
reports? Maybe not. We should discuss.] reports? Maybe not. We should discuss.]
5.12. Guidance 5.9. 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.
5.12.1. Internal Collection Guidance 5.9.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.
5.12.2. External Collection Guidance 5.9.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.
5.12.3. Evaluation Guidance 5.9.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.
5.12.4. Retention Guidance 5.9.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.
5.12.5. Reporting Guidance 5.10. Endpoint
A Report Generator typically needs Reporting Guidance to govern the
reports it generates. TODO: This should be removed if the working
group decides that reports are out of scope for SACM.
5.13. Endpoint
See the definition in the SACM Terminology for Security Assessment See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
In the model, an endpoint can be part of another endpoint. This In the model, an endpoint can be part of another endpoint. This
covers cases where multiple physical endpoints act as one endpoint. covers cases where multiple physical endpoints act as one endpoint.
The constituent endpoints may not be distinguishable by external The constituent endpoints may not be distinguishable by external
observation of network behavior. observation of network behavior.
For example, a hosting center may maintain a redundant set For example, a hosting center may maintain a redundant set
skipping to change at page 34, line 27 skipping to change at page 39, line 27
redundancy and load distribution on network paths to WAN gateways. redundancy and load distribution on network paths to WAN gateways.
Multi-chassis link aggregation groups make the chassis appear as one Multi-chassis link aggregation groups make the chassis appear as one
endpoint. Traditional security controls must be applied either to endpoint. Traditional security controls must be applied either to
physical endpoints or the redundancy groups they compose (and physical endpoints or the redundancy groups they compose (and
occasionally both). Loss of redundancy is difficult to detect or occasionally both). Loss of redundancy is difficult to detect or
mitigate without specific posture information about the current state mitigate without specific posture information about the current state
of redundancy groups. Even if a physical endpoint (e.g. router) that of redundancy groups. Even if a physical endpoint (e.g. router) that
is part of a redundancy group is replaced, the redundancy group can is part of a redundancy group is replaced, the redundancy group can
remain the same. remain the same.
5.13.1. Endpoint Identity 5.10.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.
5.13.2. Software Component 5.10.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 35, line 27 skipping to change at page 40, line 27
Examples of harmful software components: Examples of harmful software components:
o A malicious entertainment app o A malicious entertainment app
o A malicious executable o A malicious executable
o A web page that contains malicious JavaScript o A web page that contains malicious JavaScript
o A business application that shipped with a virus o A business application that shipped with a virus
5.13.2.1. Unique Software Identifier 5.10.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).
5.14. User 5.11. User
5.14.1. User Identity 5.11.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.12. hardwareSerialNumber
elementId: TBD
name: hardwareSerialNumber
dataType: string
dataTypeSemantics: default
status: current
description: A globally unique identifier for a particular
piece of hardware assigned by the vendor.
5.13. interfaceName
elementId: TBD
name: interfaceName
dataType: string
dataTypeSemantics: default
status: current
description: A short name uniquely describing an interface,
eg "Eth1/0". See [RFC2863] for the definition
of the ifName object.
5.14. interfaceIndex
elementId: TBD
name: interfaceIndex
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: The index of an interface installed on an endpoint.
The value matches the value of managed object
'ifIndex' as defined in [RFC2863]. Note that ifIndex
values are not assigned statically to an interface
and that the interfaces may be renumbered every time
the device's management system is re-initialized,
as specified in [RFC2863].
5.15. interfaceMacAddress
elementId: TBD
name: interfaceMacAddress
dataType: macAddress
dataTypeSemantics: default
status: current
description: The IEEE 802 MAC address associated with a network
interface on an endpoint.
5.16. interfaceType
elementId: TBD
name: interfaceType
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: The type of a network interface. The value matches
the value of managed object 'ifType' as defined in
[IANA registry ianaiftype-mib].
5.17. interfaceFlags
elementId: TBD
name: interfaceFlags
dataType: unsigned16
dataTypeSemantics: flags
status: current
description: This information element specifies the flags
associated with a network interface. Possible
values include:
+-------+----------------------------------+
| Value | Description |
+-------+----------------------------------+
| 0x1 | interface is up |
| 0x2 | broadcast address valid |
| 0x4 | turn on debugging |
| 0x8 | is a loopback net |
| 0x10 | interface is point-to-point link |
| 0x20 | avoid use of trailers |
| 0x40 | resources allocated |
| 0x80 | no address resolution protocol |
| 0x100 | receive all packets |
+-------+----------------------------------+
5.18. networkInterface
elementId: TBD
name: networkInterface
dataType: basicList
dataTypeSemantics: default
status: current
description: Information about a network interface
installed on an endpoint. The
following high-level digram
describes the structure of
networkInterface information
element.
networkInterface = (basicList, allof,
interfaceName,
interfaceIndex,
macAddress,
ifType,
flags
)
5.19. softwareIdentifier
elementId: TBD
name: softwareIdentifier
dataType: string
dataTypeSemantics: default
status: current
description: A globally unique identifier for a particular
software application.
5.20. softwareTitle
elementId: TBD
name: softwareTitle
dataType: string
dataTypeSemantics: default
status: current
description: The title of the software application.
5.21. softwareCreator
elementId: TBD
name: softwareCreator
dataType: string
dataTypeSemantics: default
status: current
description: The software developer (e.g., vendor or author).
5.22. simpleVersion
elementId: TBD
name: simpleVersion
dataType: simpleVersionType
dataTypeSemantics: default
status: current
description: The version string for a software application that
follows the simple versioning scheme.
5.23. rpmVersion
elementId: TBD
name: rpmVersion
dataType: rpmVersionType
dataTypeSemantics: default
status: current
description: The version string for a software application that
follows the RPM versioning scheme.
5.24. ciscoTrainVersion
elementId: TBD
name: ciscoTrainVersion
dataType: ciscoTrainVersionType
dataTypeSemantics: default
status: current
description: The version string for a software application that
follows the Cisco Train Release versioning scheme.
5.25. softwareVersion
elementId: TBD
name: softwareVerison
dataType: basicList
dataTypeSemantics: default
status: current
description: The version of the software application. Software
applications may be versioned using a number of
schemas. The following high-level digram describes
the structure of the softwareVersion information
element.
softwareVersion(basicList, exactlyOneOf,
simpleVersion,
rpmVersion,
ciscoTrainVersion,
...
)
5.26. lastUpdated
elementId: TBD
name: lastUpdated
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
description: The date and time when the software instance
was last updated on the system (e.g., new
version instlalled or patch applied)
5.27. softwareInstance
elementId: TBD
name: softwareInstance
dataType: subTemplateMultiList
dataTypeSemantics: default
status: current
description: Information about an instance of software
installed on an endpoint. The following
high-level digram describes the structure of
softwareInstance information element.
softwareInstance = (subTemplateMultiList, allof,
softwareIdentifier,
title,
creator,
softwareVersion,
lastUpdated
)
5.28. globallyUniqueIdentifier
elementId: TBD
name: globallyUniqueIdentifier
dataType: unsigned8
dataTypeSemantics: identifier
status: current
metadata: true
description: TODO.
5.29. dataOrigin
elementId: TBD
name: dataOrigin
dataType: string
dataTypeSemantics: default
status: current
metadata: true
description: The origin of the data. TODO make a better
description.
5.30. dataSource
elementId: TBD
name: dataSource
dataType: string
dataTypeSemantics: default
status: current
metadata: true
description: The source of the data. TODO make a better
description.
5.31. creationTimestamp
elementId: TBD
name: creationTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
information was created by a SACM Component.
5.32. collectionTimestamp
elementId: TBD
name: collectionTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
information was collected or observed by a SACM
Component.
5.33. publicationTimestamp
elementId: TBD
name: publicationTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
information was published.
5.34. relayTimestamp
elementId: TBD
name: relayTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
information was relayed to another SACM Component.
5.35. storageTimestamp
elementId: TBD
name: storageTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
information was stored in a Repository.
5.36. type
elementId: TBD
name: type
dataType: unsigned16
dataTypeSemantics: flags
status: current
metadata: true
description: The type of data model use to represent
some set of endpoint information. The following table
lists the set of data models supported by SACM.
+-------+----------------------------------+
| Value | Description |
+-------+----------------------------------+
| 0x00 | Data Model 1 |
+-------+----------------------------------+
| 0x01 | Data Model 2 |
+-------+----------------------------------+
| 0x02 | Data Model 3 |
+-------+----------------------------------+
|... | ... |
+-------+----------------------------------+
5.37. protocolIdentifier
elementId: TBD
name: protocolIdentifier
dataType: unsigned8
dataTypeSemantics: identifier
status: current
description: The value of the protocol number in the IP packet header.
The protocol number identifies the IP packet payload type.
Protocol numbers are defined in the IANA Protocol Numbers
registry.
In Internet Protocol version 4 (IPv4), this is carried in the
Protocol field. In Internet Protocol version 6 (IPv6), this
is carried in the Next Header field in the last extension
header of the packet.
5.38. sourceTransportPort
elementId: TBD
name: sourceTransportPort
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: The source port identifier in the transport header.
For the transport protocols UDP, TCP, and SCTP, this is the
source port number given in the respective header. This
field MAY also be used for future transport protocols that
have 16-bit source port identifiers.
5.39. sourceIPv4PrefixLength
elementId: TBD
name: sourceIPv4PrefixLength
dataType: unsigned8
dataTypeSemantics:
status: current
description: The number of contiguous bits that are relevant in the
sourceIPv4Prefix Information Element.
5.40. ingressInterface
elementId: TBD
name: ingressInterface
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: The index of the IP interface where packets of this Flow
are being received. The value matches the value of managed
object 'ifIndex' as defined in [RFC2863].
Note that ifIndex values are not assigned statically to an
interface and that the interfaces may be renumbered every
time the device's management system is re-initialized, as
specified in [RFC2863].
5.41. destinationTransportPort
elementId: TBD
name: destinationTransportPort
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: The destination port identifier in the transport header.
For the transport protocols UDP, TCP, and SCTP, this is the
destination port number given in the respective header.
This field MAY also be used for future transport protocols
that have 16-bit destination port identifiers.
5.42. sourceIPv6PrefixLength
elementId: TBD
name: sourceIPv6PrefixLength
dataType: unsigned8
dataTypeSemantics:
status: current
description: The number of contiguous bits that are relevant in the
sourceIPv6Prefix Information Element.
5.43. sourceIPv4Prefix
elementId: TBD
name: sourceIPv4Prefix
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: IPv4 source address prefix.
5.44. destinationIPv4Prefix
elementId: TBD
name: destinationIPv4Prefix
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: IPv4 destination address prefix.
5.45. sourceMacAddress
elementId: TBD
name: sourceMacAddress
dataType: macAddress
dataTypeSemantics: default
status: current
description: The IEEE 802 source MAC address field.
5.46. ipVersion
elementId: TBD
name: ipVersion
dataType: unsigned8
dataTypeSemantics: identifier
status: current
description: The IP version field in the IP packet header.
5.47. interfaceName
elementId: TBD
name: interfaceName
dataType: string
dataTypeSemantics: default
status: current
description: A short name uniquely describing an interface, eg "Eth1/0".
5.48. interfaceDescription
elementId: TBD
name: interfaceDescription
dataType: string
dataTypeSemantics: default
status: current
description: The description of an interface, eg "FastEthernet 1/0" or "ISP
connection".
5.49. applicationDescription
elementId: TBD
name: applicationDescription
dataType: string
dataTypeSemantics: default
status: current
description: Specifies the description of an application.
5.50. applicationId
elementId: TBD
name: applicationId
dataType: octetArray
dataTypeSemantics: default
status: current
description: Specifies an Application ID per [RFC6759].
5.51. applicationName
elementId: TBD
name: applicationName
dataType: string
dataTypeSemantics: default
status: current
description: Specifies the name of an application.
5.52. exporterIPv4Address
elementId: TBD
name: exporterIPv4Address
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: The IPv4 address used by the Exporting Process. This is used
by the Collector to identify the Exporter in cases where the
identity of the Exporter may have been obscured by the use of
a proxy.
5.53. exporterIPv6Address
elementId: TBD
name: exporterIPv6Address
dataType: ipv6Address
dataTypeSemantics: default
status: current
description: The IPv6 address used by the Exporting Process. This is used
by the Collector to identify the Exporter in cases where the
identity of the Exporter may have been obscured by the use of
a proxy.
5.54. portId
elementId: TBD
name: portId
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: An identifier of a line port that is unique per IPFIX
Device hosting an Observation Point. Typically, this
Information Element is used for limiting the scope
of other Information Elements.
5.55. templateId
elementId: TBD
name: templateId
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: An identifier of a Template that is locally unique within a
combination of a Transport session and an Observation Domain.
Template IDs 0-255 are reserved for Template Sets, Options
Template Sets, and other reserved Sets yet to be created.
Template IDs of Data Sets are numbered from 256 to 65535.
Typically, this Information Element is used for limiting
the scope of other Information Elements.
Note that after a re-start of the Exporting Process Template
identifiers may be re-assigned.
5.56. collectorIPv4Address
elementId: TBD
name: collectorIPv4Address
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: An IPv4 address to which the Exporting Process sends Flow
information.
5.57. collectorIPv6Address
elementId: TBD
name: collectorIPv6Address
dataType: ipv6Address
dataTypeSemantics: default
status: current
description: An IPv6 address to which the Exporting Process sends Flow
information.
5.58. informationElementIndex
elementId: TBD
name: informationElementIndex
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: A zero-based index of an Information Element
referenced by informationElementId within a Template referenced by
templateId; used to disambiguate scope for templates containing
multiple identical Information Elements.
5.59. basicList
elementId: TBD
name: basicList
dataType: basicList
dataTypeSemantics: list
status: current
description: Specifies a generic Information Element with a basicList abstract
data type. For example, a list of port numbers, a list of
interface indexes, etc.
5.60. subTemplateList
elementId: TBD
name: subTemplateList
dataType: subTemplateList
dataTypeSemantics: list
status: current
description: Specifies a generic Information Element with a subTemplateList
abstract data type.
5.61. subTemplateMultiList
elementId: TBD
name: subTemplateMultiList
dataType: subTemplateMultiList
dataTypeSemantics: list
status: current
description: Specifies a generic Information Element with a
subTemplateMultiList abstract data type.
5.62. informationElementId
elementId: TBD
name: informationElementId
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: This Information Element contains the ID of another Information
Element.
5.63. informationElementDataType
elementId: TBD
name: informationElementDataType
dataType: unsigned8
dataTypeSemantics:
status: current
description: A description of the abstract data type of an IPFIX
information element.These are taken from the abstract data types
defined in section 3.1 of the IPFIX Information Model [RFC5102];
see that section for more information on the types described
in the informationElementDataType sub-registry.
These types are registered in the IANA IPFIX Information Element
Data Type subregistry. This subregistry is intended to assign
numbers for type names, not to provide a mechanism for adding data
types to the IPFIX Protocol, and as such requires a Standards
Action [RFC5226] to modify.
5.64. informationElementDescription
elementId: TBD
name: informationElementDescription
dataType: string
dataTypeSemantics: default
status: current
description: A UTF-8 [RFC3629] encoded Unicode string containing a
human-readable description of an Information Element. The content
of the informationElementDescription MAY be annotated with one or
more language tags [RFC4646], encoded in-line [RFC2482] within the
UTF-8 string, in order to specify the language in which the
description is written. Description text in multiple languages
MAY tag each section with its own language tag; in this case, the
description information in each language SHOULD have equivalent
meaning. In the absence of any language tag, the "i-default"
[RFC2277] language SHOULD be assumed. See the Security
Considerations section for notes on string handling for
Information Element type records.
5.65. informationElementName
elementId: TBD
name: informationElementName
dataType: string
dataTypeSemantics: default
status: current
description: A UTF-8 [RFC3629] encoded Unicode string containing
the name of an Information Element, intended as a simple
identifier. See the Security Considerations section for notes on
string handling for Information Element type records.
5.66. informationElementRangeBegin
elementId: TBD
name: informationElementRangeBegin
dataType: unsigned64
dataTypeSemantics: quantity
status: current
description: Contains the inclusive low end of the range of
acceptable values for an Information Element.
5.67. informationElementRangeEnd
elementId: TBD
name: informationElementRangeEnd
dataType: unsigned64
dataTypeSemantics: quantity
status: current
description: Contains the inclusive high end of the range of
acceptable values for an Information Element.
5.68. informationElementSemantics
elementId: TBD
name: informationElementSemantics
dataType: unsigned8
dataTypeSemantics:
status: current
description: A description of the semantics of an IPFIX
Information Element. These are taken from the data type
semantics defined in section 3.2 of the IPFIX Information
Model [RFC5102]; see that section for more information
on the types defined in the informationElementSemantics
sub-registry. This field may take the values in Table ;
the special value 0x00 (default) is used to note that
no semantics apply to the field; it cannot be manipulated
by a Collecting Process or File Reader that does not
understand it a priori.
These semantics are registered in the IANA IPFIX
Information Element Semantics subregistry. This subregistry
is intended to assign numbers for semantics names, not
to provide a mechanism for adding semantics to the
IPFIX Protocol, and as such requires a Standards
Action [RFC5226] to modify.
5.69. informationElementUnits
elementId: TBD
name: informationElementUnits
dataType: unsigned16
dataTypeSemantics:
status: current
description: A description of the units of an IPFIX Information
Element. These correspond to the units implicitly defined in the
Information Element definitions in section 5 of the IPFIX
Information Model [RFC5102]; see that section for more information
on the types described in the informationElementsUnits sub-registry.
This field may take the values in Table 3 below; the special value
0x00 (none) is used to note that the field is unitless.
These types are registered in the IANA IPFIX Information Element
Units subregistry; new types may be added on a First Come First
Served [RFC5226] basis.
5.70. userName
elementId: TBD
name: userName
dataType: string
dataTypeSemantics: default
status: current
description: User name associated with the flow.
5.71. applicationCategoryName
elementId: TBD
name: applicationCategoryName
dataType: string
dataTypeSemantics: default
status: current
description: An attribute that provides a first level categorization for
each Application ID.
5.72. mibObjectValueInteger
elementId: TBD
name: mibObjectValueInteger
dataType: signed64
dataTypeSemantics: identifier
status: current
description: An IPFIX Information Element which denotes that the
integer value of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base Syntax of Integer32
and INTEGER with IPFIX Reduced Size Encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type
of signed64.
5.73. mibObjectValueOctetString
elementId: TBD
name: mibObjectValueOctetString
dataType: octetArray
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that an
Octet String or Opaque value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field
MUST be exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base Syntax
of OCTET STRING and Opaque. The value is encoded as per the
standard IPFIX Abstract Data Type of octetArray.
5.74. mibObjectValueOID
elementId: TBD
name: mibObjectValueOID
dataType: octetArray
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that an
Object Identifier or OID value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field
MUST be exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base Syntax
of OBJECT IDENTIFIER. Note - In this case the
"mibObjectIdentifier" will define which MIB object is being
exported while the value contained in this Information Element
will be an OID as a value. The mibObjectValueOID Information
Element is encoded as ASN.1/BER [BER] in an octetArray.
5.75. mibObjectValueBits
elementId: TBD
name: mibObjectValueBits
dataType: octetArray
dataTypeSemantics: flags
status: current
description: An IPFIX Information Element which denotes that a set
of Enumerated flags or bits from a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field
MUST be exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base Syntax
of BITS. The flags or bits are encoded as per the standard IPFIX
Abstract Data Type of octetArray, with sufficient length to
accommodate the required number of bits. If the number of bits is
not an integer multiple of octets then the most significant bits
at end of the octetArray MUST be set to zero.
5.76. mibObjectValueIPAddress
elementId: TBD
name: mibObjectValueIPAddress
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that the
IPv4 Address of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base Syntax of IPaddress.
The value is encoded as per the standard IPFIX Abstract Data Type
of ipv4Address.
5.77. mibObjectValueCounter
elementId: TBD
name: mibObjectValueCounter
dataType: unsigned64
dataTypeSemantics: snmpCounter
status: current
description: An IPFIX Information Element which denotes that the
counter value of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base Syntax of Counter32
or Counter64 with IPFIX Reduced Size Encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type
of unsigned64.
5.78. mibObjectValueGauge
elementId: TBD
name: mibObjectValueGauge
dataType: unsigned32
dataTypeSemantics: snmpGauge
status: current
description: An IPFIX Information Element which denotes that the
Gauge value of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base Syntax of Gauge32.
The value is encoded as per the standard IPFIX Abstract Data Type
of unsigned64. This value will represent a non-negative integer,
which may increase or decrease, but shall never exceed a maximum
value, nor fall below a minimum value.
5.79. mibObjectValueTimeTicks
elementId: TBD
name: mibObjectValueTimeTicks
dataType: unsigned32
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that the
TimeTicks value of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base Syntax of TimeTicks.
The value is encoded as per the standard IPFIX Abstract Data Type
of unsigned32.
5.80. mibObjectValueUnsigned
elementId: TBD
name: mibObjectValueUnsigned
dataType: unsigned64
dataTypeSemantics: identifier
status: current
description: An IPFIX Information Element which denotes that an
unsigned integer value of a MIB object will be exported. The MIB
Object Identifier ("mibObjectIdentifier") for this field MUST be
exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base Syntax
of unsigned64 with IPFIX Reduced Size Encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type
of unsigned64.
5.81. mibObjectValueTable
elementId: TBD
name: mibObjectValueTable
dataType: subTemplateList
dataTypeSemantics: list
status: current
description: An IPFIX Information Element which denotes that a
complete or partial conceptual table will be exported. The MIB
Object Identifier ("mibObjectIdentifier") for this field MUST be
exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with a SYNTAX of
SEQUENCE. This is encoded as a subTemplateList of mibObjectValue
Information Elements. The template specified in the
subTemplateList MUST be an Options Template and MUST include all
the Objects listed in the INDEX clause as Scope Fields.
5.82. mibObjectValueRow
elementId: TBD
name: mibObjectValueRow
dataType: subTemplateList
dataTypeSemantics: list
status: current
description: An IPFIX Information Element which denotes that a
single row of a conceptual table will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with a SYNTAX of SEQUENCE. This
is encoded as a subTemplateList of mibObjectValue Information
Elements. The subTemplateList exported MUST contain exactly one
row (i.e., one instance of the subtemplate). The template
specified in the subTemplateList MUST be an Options Template and
MUST include all the Objects listed in the INDEX clause as Scope
Fields.
5.83. mibObjectIdentifier
elementId: TBD
name: mibObjectIdentifier
dataType: octetArray
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that a MIB
Object Identifier (MIB OID) is exported in the (Options) Template
Record. The mibObjectIdentifier Information Element contains the
OID assigned to the MIB Object Type Definition encoded as ASN.1/
BER [BER].
5.84. mibSubIdentifier
elementId: TBD
name: mibSubIdentifier
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: A non-negative sub-identifier of an Object Identifier (OID).
5.85. mibIndexIndicator
elementId: TBD
name: mibIndexIndicator
dataType: unsigned64
dataTypeSemantics: flags
status: current
description: This set of bit fields is used for marking the
Information Elements of a Data Record that serve as INDEX MIB
objects for an indexed Columnar MIB object. Each bit represents
an Information Element in the Data Record with the n-th bit
representing the n-th Information Element. A bit set to value 1
indicates that the corresponding Information Element is an index
of the Columnar Object represented by the mibFieldValue. A bit
set to value 0 indicates that this is not the case.
If the Data Record contains more than 64 Information Elements, the
corresponding Template SHOULD be designed such that all INDEX
Fields are among the first 64 Information Elements, because the
mibIndexIndicator only contains 64 bits. If the Data Record
contains less than 64 Information Elements, then the extra bits in
the mibIndexIndicator for which no corresponding Information
Element exists MUST have the value 0, and must be disregarded by
the Collector. This Information Element may be exported with
IPFIX Reduced Size Encoding.
5.86. mibCaptureTimeSemantics
elementId: TBD
name: mibCaptureTimeSemantics
dataType: unsigned8
dataTypeSemantics: identifier
status: current
description: Indicates when in the lifetime of the flow the MIB
value was retrieved from the MIB for a mibObjectIdentifier. This
is used to indicate if the value exported was collected from the
MIB closer to flow creation or flow export time and will refer to
the Timestamp fields included in the same record. This field
SHOULD be used when exporting a mibObjectValue that specifies
counters or statistics.
If the MIB value was sampled by SNMP prior to the IPFIX Metering
Process or Exporting Process retrieving the value (i.e., the data
is already stale) and it's important to know the exact sampling
time, then an additional observationTime* element should be paired
with the OID using structured data. Similarly, if different
mibCaptureTimeSemantics apply to different mibObject elements
within the Data Record, then individual mibCaptureTimeSemantics
should be paired with each OID using structured data.
Values:
0. undefined
1. begin - The value for the MIB object is captured from the
MIB when the Flow is first observed
2. end - The value for the MIB object is captured from the MIB
when the Flow ends
3. export - The value for the MIB object is captured from the
MIB at export time
4. average - The value for the MIB object is an average of
multiple captures from the MIB over the observed life of the
Flow
5.87. mibContextEngineID
elementId: TBD
name: mibContextEngineID
dataType: octetArray
dataTypeSemantics: default
status: current
description: A mibContextEngineID that specifies the SNMP engine
ID for a MIB field being exported over IPFIX. Definition as per
[RFC3411] section 3.3.
5.88. mibContextName
elementId: TBD
name: mibContextName
dataType: string
dataTypeSemantics: default
status: current
description: This Information Element denotes that a MIB Context
Name is specified for a MIB field being exported over IPFIX.
Reference [RFC3411] section 3.3.
5.89. mibObjectName
elementId: TBD
name: mibObjectName
dataType: string
dataTypeSemantics: default
status: current
description: The name (called a descriptor in [RFC2578]
of an object type definition.
5.90. mibObjectDescription
elementId: TBD
name: mibObjectDescription
dataType: string
dataTypeSemantics: default
status: current
description: The value of the DESCRIPTION clause of an MIB object
type definition.
5.91. mibObjectSyntax
elementId: TBD
name: mibObjectSyntax
dataType: string
dataTypeSemantics: default
status: current
description: The value of the SYNTAX clause of an MIB object type
definition, which may include a Textual Convention or Subtyping.
See [RFC2578].
5.92. mibModuleName
elementId: TBD
name: mibModuleName
dataType: string
dataTypeSemantics: default
status: current
description: The textual name of the MIB module that defines a MIB
Object.
6. SACM Usage Scenario Example 6. SACM Usage Scenario Example
TODO: this section needs to refer out to wherever the operations / TODO: this section needs to refer out to wherever the operations /
generalized workflow content ends up generalized workflow content ends up
TODO: revise to eliminate graph references TODO: revise to eliminate graph references
This section illustrates the proposed SACM Information Model as This section illustrates the proposed SACM Information Model as
applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations
[RFC7632]. The following subsections describe the elements [RFC7632]. The following subsections describe the elements
(components and elements), graph model, and operations (sample (components and elements), graph model, and operations (sample
workflow) required to support the Detection of Posture Deviations workflow) required to support the Detection of Posture Deviations
scenario. scenario.
The Detection of Posture Deviations scenario involves multiple The Detection of Posture Deviations scenario involves multiple
elements interacting to accomplish the goals of the scenario. elements interacting to accomplish the goals of the scenario.
Figure 2 illustrates those elements along with their major Figure 4 illustrates those elements along with their major
communication paths. communication paths.
6.1. Graph Model for Detection of Posture Deviation 6.1. Graph Model for Detection of Posture Deviation
The following subsections contain examples of identifiers and The following subsections contain examples of identifiers and
metadata which would enable detection of posture deviation. These metadata which would enable detection of posture deviation. These
lists are by no means exhaustive - many other types of metadata would lists are by no means exhaustive - many other types of metadata would
be enumerated in a data model that fully addressed this usage be enumerated in a data model that fully addressed this usage
scenario. scenario.
skipping to change at page 41, line 9 skipping to change at page 70, line 9
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.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <http://www.rfc-editor.org/info/rfc3587>. August 2003, <http://www.rfc-editor.org/info/rfc3587>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information Export
(IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011,
<http://www.rfc-editor.org/info/rfc6313>.
12.2. Informative References 12.2. Informative References
[CCE] The National Institute of Standards and Technology, [CCE] The National Institute of Standards and Technology,
"Common Configuration Enumeration", 2014, "Common Configuration Enumeration", 2014,
<http://nvd.nist.gov/CCE/>. <http://nvd.nist.gov/CCE/>.
[CCI] United States Department of Defense Defense Information [CCI] United States Department of Defense Defense Information
Systems Agency, "Control Correlation Identifier", 2014, Systems Agency, "Control Correlation Identifier", 2014,
<http://iase.disa.mil/cci/>. <http://iase.disa.mil/cci/>.
skipping to change at page 43, line 7 skipping to change at page 72, line 14
[NISTIR-7693] [NISTIR-7693]
Wunder, J., Halbardier, A., and D. Waltermire, Wunder, J., Halbardier, A., and D. Waltermire,
"Specification for Asset Identification 1.1", NISTIR 7693, "Specification for Asset Identification 1.1", NISTIR 7693,
June 2011, June 2011,
<http://csrc.nist.gov/publications/nistir/ir7693/ <http://csrc.nist.gov/publications/nistir/ir7693/
NISTIR-7693.pdf>. NISTIR-7693.pdf>.
[NISTIR-7694] [NISTIR-7694]
Halbardier, A., Waltermire, D., and M. Johnson, Halbardier, A., Waltermire, D., and M. Johnson,
"Specification for the Asset Reporting Format 1.1", NISTIR "Specification for the Asset Reporting Format 1.1",
7694, June 2011, NISTIR 7694, June 2011,
<http://csrc.nist.gov/publications/nistir/ir7694/ <http://csrc.nist.gov/publications/nistir/ir7694/
NISTIR-7694.pdf>. NISTIR-7694.pdf>.
[NISTIR-7695] [NISTIR-7695]
Cheikes, B., Waltermire, D., and K. Scarfone, "Common Cheikes, B., Waltermire, D., and K. Scarfone, "Common
Platform Enumeration: Naming Specification Version 2.3", Platform Enumeration: Naming Specification Version 2.3",
NISTIR 7695, August 2011, NISTIR 7695, August 2011,
<http://csrc.nist.gov/publications/nistir/ir7695/ <http://csrc.nist.gov/publications/nistir/ir7695/
NISTIR-7695-CPE-Naming.pdf>. NISTIR-7695-CPE-Naming.pdf>.
skipping to change at page 44, line 12 skipping to change at page 73, line 17
Specification version 5.10.1", January 2012, Specification version 5.10.1", January 2012,
<https://oval.mitre.org/language/version5.10.1/>. <https://oval.mitre.org/language/version5.10.1/>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002, DOI 10.17487/RFC3411, December 2002,
<http://www.rfc-editor.org/info/rfc3411>. <http://www.rfc-editor.org/info/rfc3411>.
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)", STD for the Simple Network Management Protocol (SNMP)",
62, RFC 3416, DOI 10.17487/RFC3416, December 2002, STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002,
<http://www.rfc-editor.org/info/rfc3416>. <http://www.rfc-editor.org/info/rfc3416>.
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)", STD 62, the Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, DOI 10.17487/RFC3418, December 2002, RFC 3418, DOI 10.17487/RFC3418, December 2002,
<http://www.rfc-editor.org/info/rfc3418>. <http://www.rfc-editor.org/info/rfc3418>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, DOI Information Models and Data Models", RFC 3444,
10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>. <http://www.rfc-editor.org/info/rfc3444>.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, DOI 10.17487/ (RADIUS) Usage Guidelines", RFC 3580,
RFC3580, September 2003, DOI 10.17487/RFC3580, September 2003,
<http://www.rfc-editor.org/info/rfc3580>. <http://www.rfc-editor.org/info/rfc3580>.
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
<http://www.rfc-editor.org/info/rfc3954>. <http://www.rfc-editor.org/info/rfc3954>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>. December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <http://www.rfc-editor.org/info/rfc4949>.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, DOI Henderson, "Host Identity Protocol", RFC 5201,
10.17487/RFC5201, April 2008, DOI 10.17487/RFC5201, April 2008,
<http://www.rfc-editor.org/info/rfc5201>. <http://www.rfc-editor.org/info/rfc5201>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<http://www.rfc-editor.org/info/rfc5209>. <http://www.rfc-editor.org/info/rfc5209>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
10.17487/RFC5424, March 2009, DOI 10.17487/RFC5424, March 2009,
<http://www.rfc-editor.org/info/rfc5424>. <http://www.rfc-editor.org/info/rfc5424>.
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
(PA) Protocol Compatible with Trusted Network Connect (PA) Protocol Compatible with Trusted Network Connect
(TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010,
<http://www.rfc-editor.org/info/rfc5792>. <http://www.rfc-editor.org/info/rfc5792>.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793,
skipping to change at page 45, line 30 skipping to change at page 74, line 35
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI Transport Protocol over TLS (PT-TLS)", RFC 6876,
10.17487/RFC6876, February 2013, DOI 10.17487/RFC6876, February 2013,
<http://www.rfc-editor.org/info/rfc6876>. <http://www.rfc-editor.org/info/rfc6876>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<http://www.rfc-editor.org/info/rfc7012>.
[RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IP Flow Information Export (IPFIX)
Information Elements", BCP 184, RFC 7013,
DOI 10.17487/RFC7013, September 2013,
<http://www.rfc-editor.org/info/rfc7013>.
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
(PT) Protocol for Extensible Authentication Protocol (EAP) (PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014,
<http://www.rfc-editor.org/info/rfc7171>. <http://www.rfc-editor.org/info/rfc7171>.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632, DOI Posture Assessment: Enterprise Use Cases", RFC 7632,
10.17487/RFC7632, September 2015, DOI 10.17487/RFC7632, September 2015,
<http://www.rfc-editor.org/info/rfc7632>. <http://www.rfc-editor.org/info/rfc7632>.
[SP800-117] [SP800-117]
Quinn, S., Scarfone, K., and D. Waltermire, "Guide to Quinn, S., Scarfone, K., and D. Waltermire, "Guide to
Adopting and Using the Security Content Automation Adopting and Using the Security Content Automation
Protocol (SCAP) Version 1.2", SP 800-117, January 2012, Protocol (SCAP) Version 1.2", SP 800-117, January 2012,
<http://csrc.nist.gov/publications/drafts/800-117-R1/ <http://csrc.nist.gov/publications/drafts/800-117-R1/
Draft-SP800-117-r1.pdf>. Draft-SP800-117-r1.pdf>.
[SP800-126] [SP800-126]
Waltermire, D., Quinn, S., Scarfone, K., and A. Waltermire, D., Quinn, S., Scarfone, K., and A.
Halbardier, "The Technical Specification for the Security Halbardier, "The Technical Specification for the Security
Content Automation Protocol (SCAP): SCAP Version 1.2", SP Content Automation Protocol (SCAP): SCAP Version 1.2",
800-126, September 2011, SP 800-126, September 2011,
<http://csrc.nist.gov/publications/nistpubs/800-126-rev2/ <http://csrc.nist.gov/publications/nistpubs/800-126-rev2/
SP800-126r2.pdf>. SP800-126r2.pdf>.
[TNC-Architecture] [TNC-Architecture]
Trusted Computing Group, ""TNC Architecture", Trusted Computing Group, ""TNC Architecture",
Specification Version 1.5", May 2012. Specification Version 1.5", May 2012.
[TNC-IF-M-TLV-Binding] [TNC-IF-M-TLV-Binding]
Trusted Computing Group, ""TNC IF-M: TLV Binding", Trusted Computing Group, ""TNC IF-M: TLV Binding",
Specification Version 1.0", May 2014. Specification Version 1.0", May 2014.
skipping to change at page 48, line 9 skipping to change at page 77, line 17
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.
A.2. Changes in Revision 02 A.2. Changes in Revision 02
Added Section 5.1, Identifying Attributes. Added Section 5.1, Identifying Attributes.
Split the figure into Figure 2 and Figure 3. Split the figure into Figure 4 and Figure 5.
Added Figure 4, proposing a triple-store model. Added Figure 6, proposing a triple-store model.
Some editorial cleanup Some editorial cleanup
A.3. Changes in Revision 03 A.3. Changes in Revision 03
Moved Appendix A.1, Appendix A.2, and Appendix B into the Appendix. Moved Appendix A.1, Appendix A.2, and Appendix B into the Appendix.
Added a reference to it in Section 1 Added a reference to it in Section 1
Added the Section 3 section. Provided notes for the type of Added the Section 3 section. Provided notes for the type of
information we need to add in this section. information we need to add in this section.
skipping to change at page 48, line 40 skipping to change at page 78, line 5
figure it out. figure it out.
Updated references to the Endpoint Security Posture Assessment: Updated references to the Endpoint Security Posture Assessment:
Enterprise Use Cases document to reflect that it was published as an Enterprise Use Cases document to reflect that it was published as an
RFC. RFC.
Fixed the formatting of a few figures. Fixed the formatting of a few figures.
Included references to [RFC3580] where RADIUS is mentioned. Included references to [RFC3580] where RADIUS is mentioned.
A.4. Changes in Revision 04
Integrated the IPFIX [RFC7012] syntax into Section 3.
Converted many of the existing SACM Information Elements to the IPFIX
syntax.
Included existing IPFIX Information Elements and datatypes that could
likely be reused for SACM in Section 5 and Section 3 respectively.
Removed the sections related to reports as described in
https://github.com/sacmwg/draft-ietf-sacm-information-model/
issues/30.
Cleaned up other text throughout the document.
Appendix B. Mapping to SACM Use Cases Appendix B. Mapping to SACM Use Cases
TODO: revise TODO: revise
(wandw)This information model directly corresponds to all four use (wandw)This information model directly corresponds to all four use
cases defined in the SACM Use Cases draft [RFC7632]. It uses these cases defined in the SACM Use Cases draft [RFC7632]. It uses these
use cases in coordination to achieve a small set of well-defined use cases in coordination to achieve a small set of well-defined
tasks. tasks.
Sections [removed] thru [removed] address each of the process areas. Sections [removed] thru [removed] address each of the process areas.
skipping to change at page 54, line 35 skipping to change at page 84, line 20
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 5, Consumers In the most trivial example, illustrated in Figure 7, 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 5: Example Producer/Consumer Interactions Figure 7: Example Producer/Consumer Interactions
As illustrated in Figure 6, writing and querying from data As illustrated in Figure 8, 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 6: Producer/Consumer Repository Interaction Figure 8: 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 56, line 48 skipping to change at page 86, line 48
+-----v--------+ +----+------+ +-----v--------+ +----+------+
|Evaluation | |Reporting | |Evaluation | |Reporting |
|Results | |Guidance | |Results | |Guidance |
|Consumer | |Repository | |Consumer | |Repository |
+---+----------+ +-----------+ +-------------+ +---+----------+ +-----------+ +-------------+
| | Results | | | Results |
+-----------------------------> Repository | +-----------------------------> Repository |
| | | |
+-------------+ +-------------+
Figure 7: Producer/Consumer Complex Example Figure 9: Producer/Consumer Complex Example
This illustrative example in Figure 7 provides a set of information This illustrative example in Figure 9 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 F. Text for Possible Inclusion in the Requirements Draft Appendix F. Text for Possible Inclusion in the Requirements Draft
F.1. Problem Statement F.1. Problem Statement
Scalable and sustainable collection, expression, and evaluation of Scalable and sustainable collection, expression, and evaluation of
skipping to change at page 62, line 14 skipping to change at page 92, line 14
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 8), providing for extension at any asset types/classes (see Figure 10), 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 62, line 37 skipping to change at page 92, line 37
| +-database | +-database
| +-network | +-network
| +-service | +-service
| +-software | +-software
| +-system | +-system
| +-website | +-website
+-data +-data
+-organization +-organization
+-person +-person
Figure 8: Asset Identification Class Hierarchy Figure 10: 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 70, line 31 skipping to change at page 100, 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 9: The OVAL Data Model Figure 11: The OVAL Data Model
The OVAL data model [OVAL-LANGUAGE], visualized in Figure 9, is The OVAL data model [OVAL-LANGUAGE], visualized in Figure 11, 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 89, line 12 skipping to change at page 119, 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 10: Knowledge represented by a graph Figure 12: 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].
H.2. Graph Model Overview H.2. Graph Model Overview
The proposed model, influenced by IF-MAP, is a labeled graph: each The proposed model, influenced by IF-MAP, is a labeled graph: each
skipping to change at page 93, line 12 skipping to change at page 123, line 12
Email: cliffordk@pulsesecure.net Email: cliffordk@pulsesecure.net
Lisa Lorenzin Lisa Lorenzin
Pulse Secure, LLC Pulse Secure, LLC
2700 Zanker Road, Suite 200 2700 Zanker Road, Suite 200
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: llorenzin@pulsesecure.net Email: llorenzin@pulsesecure.net
Michael Cokus
The MITRE Corporation
903 Enterprise Parkway, Suite 200
Hampton, VA 23666
USA
Email: msc@mitre.org
Daniel Haynes Daniel Haynes
The MITRE Corporation The MITRE Corporation
202 Burlington Road 202 Burlington Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: dhaynes@mitre.org Email: dhaynes@mitre.org
 End of changes. 121 change blocks. 
592 lines changed or deleted 1858 lines changed or added

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