draft-ietf-sacm-information-model-04.txt   draft-ietf-sacm-information-model-05.txt 
SACM D. Waltermire, Ed. SACM D. Waltermire, Ed.
Internet-Draft NIST Internet-Draft NIST
Intended status: Informational K. Watson Intended status: Standards Track K. Watson
Expires: September 18, 2016 DHS Expires: December 10, 2016 DHS
C. Kahn C. Kahn
L. Lorenzin L. Lorenzin
Pulse Secure, LLC Pulse Secure, LLC
M. Cokus M. Cokus
D. Haynes D. Haynes
The MITRE Corporation The MITRE Corporation
March 17, 2016 June 8, 2016
SACM Information Model SACM Information Model
draft-ietf-sacm-information-model-04 draft-ietf-sacm-information-model-05
Abstract Abstract
This document defines the information model for SACM. This document defines the information elements that are transported
between SACM components and their interconnected relationships. The
primary purpose of the Secure Automation and Continuous Monitoring
(SACM) Information Model is to ensure the interoperability of
corresponding SACM data models and addresses the use cases defined by
SACM. The information elements and corresponding types are
maintained as the IANA "SACM Information Elements" registry.
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 September 18, 2016. This Internet-Draft will expire on December 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 2. Conventions used in this document . . . . . . . . . . . . . . 8
1.1.1. Referring to an Endpoint . . . . . . . . . . . . . . 9 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 8
1.1.2. Dealing with Uncertainty . . . . . . . . . . . . . . 10 2.2. Information Element Examples . . . . . . . . . . . . . . 8
2. Conventions used in this document . . . . . . . . . . . . . . 11 3. Information Elements . . . . . . . . . . . . . . . . . . . . 9
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 11 3.1. Context of Information Elements . . . . . . . . . . . . . 9
3. Information Model Framework . . . . . . . . . . . . . . . . . 11 3.2. Extensibility of Information Elements . . . . . . . . . . 9
3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 11 4. Structure of Information Elements . . . . . . . . . . . . . . 9
3.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Attribute Syntax . . . . . . . . . . . . . . . . . . . . 11
3.2. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Subject Syntax . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. SACM Content Elements . . . . . . . . . . . . . . . . . . 14
3.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. SACM Statements . . . . . . . . . . . . . . . . . . . . . 15
3.4. Relationships . . . . . . . . . . . . . . . . . . . . . . 15 4.5. Relationships . . . . . . . . . . . . . . . . . . . . . . 16
3.5. Designation . . . . . . . . . . . . . . . . . . . . . . . 15 4.6. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.7. Categories . . . . . . . . . . . . . . . . . . . . . . . 19
3.7. Type Space . . . . . . . . . . . . . . . . . . . . . . . 16 4.8. Designation . . . . . . . . . . . . . . . . . . . . . . . 19
3.7.1. Abstract Data Types . . . . . . . . . . . . . . . . . 16 4.9. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7.1.1. unsigned8 . . . . . . . . . . . . . . . . . . . . 16 4.10. Type Space . . . . . . . . . . . . . . . . . . . . . . . 20
3.7.1.2. unsigned16 . . . . . . . . . . . . . . . . . . . 16 4.10.1. Abstract Data Types . . . . . . . . . . . . . . . . 20
3.7.1.3. unsigned32 . . . . . . . . . . . . . . . . . . . 16 4.10.1.1. unsigned8 . . . . . . . . . . . . . . . . . . . 20
3.7.1.4. unsigned64 . . . . . . . . . . . . . . . . . . . 16 4.10.1.2. unsigned16 . . . . . . . . . . . . . . . . . . . 20
3.7.1.5. signed8 . . . . . . . . . . . . . . . . . . . . . 16 4.10.1.3. unsigned32 . . . . . . . . . . . . . . . . . . . 20
3.7.1.6. signed16 . . . . . . . . . . . . . . . . . . . . 16 4.10.1.4. unsigned64 . . . . . . . . . . . . . . . . . . . 20
3.7.1.7. signed32 . . . . . . . . . . . . . . . . . . . . 17 4.10.1.5. signed8 . . . . . . . . . . . . . . . . . . . . 20
3.7.1.8. signed64 . . . . . . . . . . . . . . . . . . . . 17 4.10.1.6. signed16 . . . . . . . . . . . . . . . . . . . . 20
3.7.1.9. float32 . . . . . . . . . . . . . . . . . . . . . 17 4.10.1.7. signed32 . . . . . . . . . . . . . . . . . . . . 21
3.7.1.10. float64 . . . . . . . . . . . . . . . . . . . . . 17 4.10.1.8. signed64 . . . . . . . . . . . . . . . . . . . . 21
3.7.1.11. boolean . . . . . . . . . . . . . . . . . . . . . 17 4.10.1.9. float32 . . . . . . . . . . . . . . . . . . . . 21
3.7.1.12. macAddress . . . . . . . . . . . . . . . . . . . 17 4.10.1.10. float64 . . . . . . . . . . . . . . . . . . . . 21
3.7.1.13. string . . . . . . . . . . . . . . . . . . . . . 17 4.10.1.11. boolean . . . . . . . . . . . . . . . . . . . . 21
3.7.1.14. dateTimeSeconds . . . . . . . . . . . . . . . . . 17 4.10.1.12. macAddress . . . . . . . . . . . . . . . . . . . 21
3.7.1.15. dateTimeMilliseconds . . . . . . . . . . . . . . 17 4.10.1.13. octetArray . . . . . . . . . . . . . . . . . . . 21
3.7.1.16. dateTimeMicroseconds . . . . . . . . . . . . . . 18 4.10.1.14. string . . . . . . . . . . . . . . . . . . . . . 21
3.7.1.17. dateTimeNanoseconds . . . . . . . . . . . . . . . 18 4.10.1.15. dateTimeSeconds . . . . . . . . . . . . . . . . 21
3.7.1.18. ipv4Address . . . . . . . . . . . . . . . . . . . 18 4.10.1.16. dateTimeMilliseconds . . . . . . . . . . . . . . 22
3.7.1.19. ipv6Address . . . . . . . . . . . . . . . . . . . 18 4.10.1.17. dateTimeMicroseconds . . . . . . . . . . . . . . 22
3.7.1.20. basicList . . . . . . . . . . . . . . . . . . . . 18 4.10.1.18. dateTimeNanoseconds . . . . . . . . . . . . . . 22
3.7.1.21. subTemplateList . . . . . . . . . . . . . . . . . 18 4.10.1.19. ipv4Address . . . . . . . . . . . . . . . . . . 22
3.7.1.22. subTemplateMultiList . . . . . . . . . . . . . . 18 4.10.1.20. ipv6Address . . . . . . . . . . . . . . . . . . 22
3.7.2. Data Type Semantics . . . . . . . . . . . . . . . . . 18 4.10.1.21. ciscoTrainSoftwareVersion . . . . . . . . . . . 22
3.7.3. quantity . . . . . . . . . . . . . . . . . . . . . . 19 4.10.1.22. rpmSoftwareVersion . . . . . . . . . . . . . . . 22
3.7.4. totalCounter . . . . . . . . . . . . . . . . . . . . 19 4.10.1.23. simpleSoftwareVersion . . . . . . . . . . . . . 22
3.7.5. deltaCounter . . . . . . . . . . . . . . . . . . . . 19 4.10.1.24. basicList . . . . . . . . . . . . . . . . . . . 22
3.7.6. identifier . . . . . . . . . . . . . . . . . . . . . 19 4.10.1.25. subTemplateList . . . . . . . . . . . . . . . . 23
3.7.7. flags . . . . . . . . . . . . . . . . . . . . . . . . 19 4.10.1.26. subTemplateMultiList . . . . . . . . . . . . . . 23
3.7.8. list . . . . . . . . . . . . . . . . . . . . . . . . 20 4.10.2. Data Type Semantics . . . . . . . . . . . . . . . . 23
4. Information Model Assets . . . . . . . . . . . . . . . . . . 20 4.10.3. quantity . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Asset . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.10.4. totalCounter . . . . . . . . . . . . . . . . . . . . 23
4.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 21 4.10.5. deltaCounter . . . . . . . . . . . . . . . . . . . . 24
4.3. Hardware Component . . . . . . . . . . . . . . . . . . . 22 4.10.6. identifier . . . . . . . . . . . . . . . . . . . . . 24
4.3.1. Hardware Instance . . . . . . . . . . . . . . . . . . 22 4.10.7. flags . . . . . . . . . . . . . . . . . . . . . . . 24
4.4. Software Component . . . . . . . . . . . . . . . . . . . 22 4.10.8. list . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1. Software Instance . . . . . . . . . . . . . . . . . . 24 5. Information Model Assets . . . . . . . . . . . . . . . . . . 24
4.5. Asset Identity . . . . . . . . . . . . . . . . . . . . . 24 5.1. Asset . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6. Relationships . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 25
5. Information Model Elements . . . . . . . . . . . . . . . . . 24 5.3. Hardware Component . . . . . . . . . . . . . . . . . . . 26
5.1. Identifying Attributes . . . . . . . . . . . . . . . . . 27 5.3.1. Hardware Instance . . . . . . . . . . . . . . . . . . 26
5.1.1. How Known . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Software Component . . . . . . . . . . . . . . . . . . . 26
5.1.2. Whether to Include . . . . . . . . . . . . . . . . . 28 5.4.1. Software Instance . . . . . . . . . . . . . . . . . . 28
5.1.3. Certificate . . . . . . . . . . . . . . . . . . . . . 28 5.5. Asset Identity . . . . . . . . . . . . . . . . . . . . . 28
5.1.3.1. Range of values . . . . . . . . . . . . . . . . . 28 5.6. Asset Relationships . . . . . . . . . . . . . . . . . . . 28
5.1.3.2. Meaning . . . . . . . . . . . . . . . . . . . . . 28 6. Information Model Elements . . . . . . . . . . . . . . . . . 28
5.1.3.3. Multiplicity . . . . . . . . . . . . . . . . . . 28 6.1. Identifying Attributes . . . . . . . . . . . . . . . . . 31
5.1.3.4. Stability . . . . . . . . . . . . . . . . . . . . 29 6.1.1. How Known . . . . . . . . . . . . . . . . . . . . . . 31
5.1.3.5. Accuracy . . . . . . . . . . . . . . . . . . . . 29 6.1.2. Whether to Include . . . . . . . . . . . . . . . . . 32
5.1.3.6. Data model requirements . . . . . . . . . . . . . 29 6.1.3. Certificate . . . . . . . . . . . . . . . . . . . . . 32
5.1.4. Public Key . . . . . . . . . . . . . . . . . . . . . 29 6.1.3.1. Range of values . . . . . . . . . . . . . . . . . 32
5.1.5. Username? . . . . . . . . . . . . . . . . . . . . . . 29 6.1.3.2. Meaning . . . . . . . . . . . . . . . . . . . . . 32
5.1.6. Tool-Specific Identifier . . . . . . . . . . . . . . 29 6.1.3.3. Multiplicity . . . . . . . . . . . . . . . . . . 32
5.1.7. Identification of Endpoints where SACM Components 6.1.3.4. Stability . . . . . . . . . . . . . . . . . . . . 33
Reside . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.3.5. Accuracy . . . . . . . . . . . . . . . . . . . . 33
5.1.8. Security Considerations . . . . . . . . . . . . . . . 30 6.1.3.6. Data model requirements . . . . . . . . . . . . . 33
5.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.4. Public Key . . . . . . . . . . . . . . . . . . . . . 33
5.3. Location . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.5. Username? . . . . . . . . . . . . . . . . . . . . . . 33
5.4. Endpoint Attribute Assertion . . . . . . . . . . . . . . 32 6.1.6. Tool-Specific Identifier . . . . . . . . . . . . . . 33
5.4.1. Form and Precise Meaning . . . . . . . . . . . . . . 32 6.1.7. Identification of Endpoints where SACM Components
5.4.2. Asserter . . . . . . . . . . . . . . . . . . . . . . 32 Reside . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 33 6.1.8. Security Considerations . . . . . . . . . . . . . . . 34
5.4.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 33 6.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.5. Event . . . . . . . . . . . . . . . . . . . . . . . . 33 6.3. Location . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4.6. Difference between Attribute and Event . . . . . . . 33 6.4. Endpoint Attribute Assertion . . . . . . . . . . . . . . 36
5.5. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 34 6.4.1. Form and Precise Meaning . . . . . . . . . . . . . . 36
5.5.1. Unique Endpoint Identifier . . . . . . . . . . . . . 35 6.4.2. Asserter . . . . . . . . . . . . . . . . . . . . . . 36
5.5.2. Posture Attribute . . . . . . . . . . . . . . . . . . 35 6.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 37
5.6. Evaluation Result . . . . . . . . . . . . . . . . . . . . 36 6.4.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 37
5.7. SACM Component . . . . . . . . . . . . . . . . . . . . . 36 6.4.5. Difference between Attribute and Event . . . . . . . 37
5.7.1. External Attribute Collector . . . . . . . . . . . . 36 6.5. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 38
5.7.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 37 6.5.1. Unique Endpoint Identifier . . . . . . . . . . . . . 39
5.8. Organization? . . . . . . . . . . . . . . . . . . . . . . 37 6.5.2. Posture Attribute . . . . . . . . . . . . . . . . . . 39
5.9. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 38 6.6. Evaluation Result . . . . . . . . . . . . . . . . . . . . 39
5.9.1. Internal Collection Guidance . . . . . . . . . . . . 38 6.7. Organization? . . . . . . . . . . . . . . . . . . . . . . 40
5.9.2. External Collection Guidance . . . . . . . . . . . . 38 6.8. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 40
5.9.3. Evaluation Guidance . . . . . . . . . . . . . . . . . 38 6.8.1. Internal Collection Guidance . . . . . . . . . . . . 40
5.9.4. Retention Guidance . . . . . . . . . . . . . . . . . 38 6.8.2. External Collection Guidance . . . . . . . . . . . . 40
5.10. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 39 6.8.3. Evaluation Guidance . . . . . . . . . . . . . . . . . 41
5.10.1. Endpoint Identity . . . . . . . . . . . . . . . . . 39 6.8.4. Retention Guidance . . . . . . . . . . . . . . . . . 41
5.10.2. Software Component . . . . . . . . . . . . . . . . . 39 6.9. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 41
5.10.2.1. Unique Software Identifier . . . . . . . . . . . 40 6.9.1. Endpoint Identity . . . . . . . . . . . . . . . . . . 41
5.11. User . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.9.2. Software Component . . . . . . . . . . . . . . . . . 42
5.11.1. User Identity . . . . . . . . . . . . . . . . . . . 40 6.9.2.1. Unique Software Identifier . . . . . . . . . . . 42
5.12. hardwareSerialNumber . . . . . . . . . . . . . . . . . . 41 6.10. User . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.13. interfaceName . . . . . . . . . . . . . . . . . . . . . . 41 6.10.1. User Identity . . . . . . . . . . . . . . . . . . . 43
5.14. interfaceIndex . . . . . . . . . . . . . . . . . . . . . 41 6.11. hardwareSerialNumber . . . . . . . . . . . . . . . . . . 43
5.15. interfaceMacAddress . . . . . . . . . . . . . . . . . . . 41 6.12. interfaceName . . . . . . . . . . . . . . . . . . . . . . 43
5.16. interfaceType . . . . . . . . . . . . . . . . . . . . . . 42 6.13. interfaceIndex . . . . . . . . . . . . . . . . . . . . . 43
5.17. interfaceFlags . . . . . . . . . . . . . . . . . . . . . 42 6.14. interfaceMacAddress . . . . . . . . . . . . . . . . . . . 44
5.18. networkInterface . . . . . . . . . . . . . . . . . . . . 42 6.15. interfaceType . . . . . . . . . . . . . . . . . . . . . . 44
5.19. softwareIdentifier . . . . . . . . . . . . . . . . . . . 43 6.16. interfaceFlags . . . . . . . . . . . . . . . . . . . . . 44
5.20. softwareTitle . . . . . . . . . . . . . . . . . . . . . . 43 6.17. networkInterface . . . . . . . . . . . . . . . . . . . . 45
5.21. softwareCreator . . . . . . . . . . . . . . . . . . . . . 43 6.18. softwareIdentifier . . . . . . . . . . . . . . . . . . . 45
5.22. simpleVersion . . . . . . . . . . . . . . . . . . . . . . 44 6.19. softwareTitle . . . . . . . . . . . . . . . . . . . . . . 46
5.23. rpmVersion . . . . . . . . . . . . . . . . . . . . . . . 44 6.20. softwareCreator . . . . . . . . . . . . . . . . . . . . . 46
5.24. ciscoTrainVersion . . . . . . . . . . . . . . . . . . . . 44 6.21. simpleSoftwareVersion . . . . . . . . . . . . . . . . . . 46
5.25. softwareVersion . . . . . . . . . . . . . . . . . . . . . 44 6.22. rpmSoftwareVersion . . . . . . . . . . . . . . . . . . . 46
5.26. lastUpdated . . . . . . . . . . . . . . . . . . . . . . . 45 6.23. ciscoTrainSoftwareVersion . . . . . . . . . . . . . . . . 46
5.27. softwareInstance . . . . . . . . . . . . . . . . . . . . 45 6.24. softwareVersion . . . . . . . . . . . . . . . . . . . . . 47
5.28. globallyUniqueIdentifier . . . . . . . . . . . . . . . . 46 6.25. lastUpdated . . . . . . . . . . . . . . . . . . . . . . . 47
5.29. dataOrigin . . . . . . . . . . . . . . . . . . . . . . . 46 6.26. softwareInstance . . . . . . . . . . . . . . . . . . . . 47
5.30. dataSource . . . . . . . . . . . . . . . . . . . . . . . 46 6.27. globallyUniqueIdentifier . . . . . . . . . . . . . . . . 48
5.31. creationTimestamp . . . . . . . . . . . . . . . . . . . . 46 6.28. dataOrigin . . . . . . . . . . . . . . . . . . . . . . . 48
5.32. collectionTimestamp . . . . . . . . . . . . . . . . . . . 46 6.29. dataSource . . . . . . . . . . . . . . . . . . . . . . . 48
5.33. publicationTimestamp . . . . . . . . . . . . . . . . . . 47 6.30. creationTimestamp . . . . . . . . . . . . . . . . . . . . 49
5.34. relayTimestamp . . . . . . . . . . . . . . . . . . . . . 47 6.31. collectionTimestamp . . . . . . . . . . . . . . . . . . . 49
5.35. storageTimestamp . . . . . . . . . . . . . . . . . . . . 47 6.32. publicationTimestamp . . . . . . . . . . . . . . . . . . 49
5.36. type . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.33. relayTimestamp . . . . . . . . . . . . . . . . . . . . . 49
5.37. protocolIdentifier . . . . . . . . . . . . . . . . . . . 48 6.34. storageTimestamp . . . . . . . . . . . . . . . . . . . . 50
5.38. sourceTransportPort . . . . . . . . . . . . . . . . . . . 48 6.35. type . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.39. sourceIPv4PrefixLength . . . . . . . . . . . . . . . . . 49 6.36. protocolIdentifier . . . . . . . . . . . . . . . . . . . 51
5.40. ingressInterface . . . . . . . . . . . . . . . . . . . . 49 6.37. sourceTransportPort . . . . . . . . . . . . . . . . . . . 51
5.41. destinationTransportPort . . . . . . . . . . . . . . . . 49 6.38. sourceIPv4PrefixLength . . . . . . . . . . . . . . . . . 51
5.42. sourceIPv6PrefixLength . . . . . . . . . . . . . . . . . 50 6.39. ingressInterface . . . . . . . . . . . . . . . . . . . . 51
5.43. sourceIPv4Prefix . . . . . . . . . . . . . . . . . . . . 50 6.40. destinationTransportPort . . . . . . . . . . . . . . . . 52
5.44. destinationIPv4Prefix . . . . . . . . . . . . . . . . . . 50 6.41. sourceIPv6PrefixLength . . . . . . . . . . . . . . . . . 52
5.45. sourceMacAddress . . . . . . . . . . . . . . . . . . . . 50 6.42. sourceIPv4Prefix . . . . . . . . . . . . . . . . . . . . 52
5.46. ipVersion . . . . . . . . . . . . . . . . . . . . . . . . 50 6.43. destinationIPv4Prefix . . . . . . . . . . . . . . . . . . 53
5.47. interfaceName . . . . . . . . . . . . . . . . . . . . . . 51 6.44. sourceMacAddress . . . . . . . . . . . . . . . . . . . . 53
5.48. interfaceDescription . . . . . . . . . . . . . . . . . . 51 6.45. ipVersion . . . . . . . . . . . . . . . . . . . . . . . . 53
5.49. applicationDescription . . . . . . . . . . . . . . . . . 51 6.46. interfaceDescription . . . . . . . . . . . . . . . . . . 53
5.50. applicationId . . . . . . . . . . . . . . . . . . . . . . 51 6.47. applicationDescription . . . . . . . . . . . . . . . . . 53
5.51. applicationName . . . . . . . . . . . . . . . . . . . . . 51 6.48. applicationId . . . . . . . . . . . . . . . . . . . . . . 54
5.52. exporterIPv4Address . . . . . . . . . . . . . . . . . . . 52 6.49. applicationName . . . . . . . . . . . . . . . . . . . . . 54
5.53. exporterIPv6Address . . . . . . . . . . . . . . . . . . . 52 6.50. exporterIPv4Address . . . . . . . . . . . . . . . . . . . 54
5.54. portId . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.51. exporterIPv6Address . . . . . . . . . . . . . . . . . . . 54
5.55. templateId . . . . . . . . . . . . . . . . . . . . . . . 52 6.52. portId . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.56. collectorIPv4Address . . . . . . . . . . . . . . . . . . 53 6.53. templateId . . . . . . . . . . . . . . . . . . . . . . . 55
5.57. collectorIPv6Address . . . . . . . . . . . . . . . . . . 53 6.54. collectorIPv4Address . . . . . . . . . . . . . . . . . . 55
5.58. informationElementIndex . . . . . . . . . . . . . . . . . 53 6.55. collectorIPv6Address . . . . . . . . . . . . . . . . . . 55
5.59. basicList . . . . . . . . . . . . . . . . . . . . . . . . 54 6.56. informationElementIndex . . . . . . . . . . . . . . . . . 56
5.60. subTemplateList . . . . . . . . . . . . . . . . . . . . . 54 6.57. informationElementId . . . . . . . . . . . . . . . . . . 56
5.61. subTemplateMultiList . . . . . . . . . . . . . . . . . . 54 6.58. informationElementDataType . . . . . . . . . . . . . . . 56
5.62. informationElementId . . . . . . . . . . . . . . . . . . 54 6.59. informationElementDescription . . . . . . . . . . . . . . 57
5.63. informationElementDataType . . . . . . . . . . . . . . . 54 6.60. informationElementName . . . . . . . . . . . . . . . . . 57
5.64. informationElementDescription . . . . . . . . . . . . . . 55 6.61. informationElementRangeBegin . . . . . . . . . . . . . . 58
5.65. informationElementName . . . . . . . . . . . . . . . . . 55 6.62. informationElementRangeEnd . . . . . . . . . . . . . . . 58
5.66. informationElementRangeBegin . . . . . . . . . . . . . . 56 6.63. informationElementSemantics . . . . . . . . . . . . . . . 58
5.67. informationElementRangeEnd . . . . . . . . . . . . . . . 56 6.64. informationElementUnits . . . . . . . . . . . . . . . . . 59
5.68. informationElementSemantics . . . . . . . . . . . . . . . 56 6.65. userName . . . . . . . . . . . . . . . . . . . . . . . . 60
5.69. informationElementUnits . . . . . . . . . . . . . . . . . 57 6.66. applicationCategoryName . . . . . . . . . . . . . . . . . 60
5.70. userName . . . . . . . . . . . . . . . . . . . . . . . . 57 6.67. mibObjectValueInteger . . . . . . . . . . . . . . . . . . 60
5.71. applicationCategoryName . . . . . . . . . . . . . . . . . 57 6.68. mibObjectValueOctetString . . . . . . . . . . . . . . . . 60
5.72. mibObjectValueInteger . . . . . . . . . . . . . . . . . . 57 6.69. mibObjectValueOID . . . . . . . . . . . . . . . . . . . . 61
5.73. mibObjectValueOctetString . . . . . . . . . . . . . . . . 58 6.70. mibObjectValueBits . . . . . . . . . . . . . . . . . . . 61
5.74. mibObjectValueOID . . . . . . . . . . . . . . . . . . . . 58 6.71. mibObjectValueIPAddress . . . . . . . . . . . . . . . . . 62
5.75. mibObjectValueBits . . . . . . . . . . . . . . . . . . . 59 6.72. mibObjectValueCounter . . . . . . . . . . . . . . . . . . 62
5.76. mibObjectValueIPAddress . . . . . . . . . . . . . . . . . 59 6.73. mibObjectValueGauge . . . . . . . . . . . . . . . . . . . 63
5.77. mibObjectValueCounter . . . . . . . . . . . . . . . . . . 59 6.74. mibObjectValueTimeTicks . . . . . . . . . . . . . . . . . 63
5.78. mibObjectValueGauge . . . . . . . . . . . . . . . . . . . 60 6.75. mibObjectValueUnsigned . . . . . . . . . . . . . . . . . 64
5.79. mibObjectValueTimeTicks . . . . . . . . . . . . . . . . . 60 6.76. mibObjectValueTable . . . . . . . . . . . . . . . . . . . 64
5.80. mibObjectValueUnsigned . . . . . . . . . . . . . . . . . 60 6.77. mibObjectValueRow . . . . . . . . . . . . . . . . . . . . 65
5.81. mibObjectValueTable . . . . . . . . . . . . . . . . . . . 61 6.78. mibObjectIdentifier . . . . . . . . . . . . . . . . . . . 65
5.82. mibObjectValueRow . . . . . . . . . . . . . . . . . . . . 61 6.79. mibSubIdentifier . . . . . . . . . . . . . . . . . . . . 66
5.83. mibObjectIdentifier . . . . . . . . . . . . . . . . . . . 61 6.80. mibIndexIndicator . . . . . . . . . . . . . . . . . . . . 66
5.84. mibSubIdentifier . . . . . . . . . . . . . . . . . . . . 62 6.81. mibCaptureTimeSemantics . . . . . . . . . . . . . . . . . 67
5.85. mibIndexIndicator . . . . . . . . . . . . . . . . . . . . 62 6.82. mibContextEngineID . . . . . . . . . . . . . . . . . . . 68
5.86. mibCaptureTimeSemantics . . . . . . . . . . . . . . . . . 62 6.83. mibContextName . . . . . . . . . . . . . . . . . . . . . 69
5.87. mibContextEngineID . . . . . . . . . . . . . . . . . . . 63 6.84. mibObjectName . . . . . . . . . . . . . . . . . . . . . . 69
5.88. mibContextName . . . . . . . . . . . . . . . . . . . . . 64 6.85. mibObjectDescription . . . . . . . . . . . . . . . . . . 69
5.89. mibObjectName . . . . . . . . . . . . . . . . . . . . . . 64 6.86. mibObjectSyntax . . . . . . . . . . . . . . . . . . . . . 69
5.90. mibObjectDescription . . . . . . . . . . . . . . . . . . 64 6.87. mibModuleName . . . . . . . . . . . . . . . . . . . . . . 69
5.91. mibObjectSyntax . . . . . . . . . . . . . . . . . . . . . 64 7. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 70
5.92. mibModuleName . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Graph Model for Detection of Posture Deviation . . . . . 70
6. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 65 7.1.1. Components . . . . . . . . . . . . . . . . . . . . . 70
6.1. Graph Model for Detection of Posture Deviation . . . . . 65 7.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 71
6.1.1. Components . . . . . . . . . . . . . . . . . . . . . 65 7.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 71
6.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 66 7.1.4. Relationships between Identifiers and Metadata . . . 72
6.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 66 7.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1.4. Relationships between Identifiers and Metadata . . . 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73
6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 67 8.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 73
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 68 10. Operational Considerations . . . . . . . . . . . . . . . . . 74
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74
9. Operational Considerations . . . . . . . . . . . . . . . . . 69 12. Security Considerations . . . . . . . . . . . . . . . . . . . 74
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
11. Security Considerations . . . . . . . . . . . . . . . . . . . 69 13.1. Normative References . . . . . . . . . . . . . . . . . . 75
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 13.2. Informative References . . . . . . . . . . . . . . . . . 75
12.1. Normative References . . . . . . . . . . . . . . . . . . 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 81
12.2. Informative References . . . . . . . . . . . . . . . . . 70 A.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 81
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 76 A.2. Changes in Revision 02 . . . . . . . . . . . . . . . . . 82
A.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 76 A.3. Changes in Revision 03 . . . . . . . . . . . . . . . . . 82
A.2. Changes in Revision 02 . . . . . . . . . . . . . . . . . 77 A.4. Changes in Revision 04 . . . . . . . . . . . . . . . . . 82
A.3. Changes in Revision 03 . . . . . . . . . . . . . . . . . 77 A.5. Changes in Revision 05 . . . . . . . . . . . . . . . . . 83
A.4. Changes in Revision 04 . . . . . . . . . . . . . . . . . 78 Appendix B. Mapping to SACM Use Cases . . . . . . . . . . . . . 83
Appendix B. Mapping to SACM Use Cases . . . . . . . . . . . . . 78 Appendix C. Security Automation with TNC IF-MAP . . . . . . . . 83
Appendix C. Security Automation with TNC IF-MAP . . . . . . . . 78 C.1. What is Trusted Network Connect? . . . . . . . . . . . . 83
C.1. What is Trusted Network Connect? . . . . . . . . . . . . 78 C.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 84
C.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 79 C.3. What is the TNC Information Model? . . . . . . . . . . . 84
C.3. What is the TNC Information Model? . . . . . . . . . . . 79 Appendix D. Text for Possible Inclusion in the Terminology Draft 85
Appendix D. Text for Possible Inclusion in the Terminology Draft 80 D.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 85
D.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 80 D.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 85
D.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 80 D.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 86
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 . . . . . . . . . . . . . . . . . . . . . 81 Use Cases . . . . . . . . . . . . . . . . . . . . . 86
E.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 82 E.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 86
E.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 82 E.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 87
E.3. Architecture Assumptions . . . . . . . . . . . . . . . . 83 E.3. Architecture Assumptions . . . . . . . . . . . . . . . . 88
Appendix F. Text for Possible Inclusion in the Requirements Appendix F. Text for Possible Inclusion in the Requirements
Draft . . . . . . . . . . . . . . . . . . . . . . . 87 Draft . . . . . . . . . . . . . . . . . . . . . . . 92
F.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 87 F.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 92
F.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 87 F.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 92
Appendix G. Text With No Clear Home Yet . . . . . . . . . . . . 88 Appendix G. Text With No Clear Home Yet . . . . . . . . . . . . 93
G.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 88 G.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 93
G.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 88 G.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 93
G.2. From Information Needs to Information Elements . . . . . 89 G.2. From Information Needs to Information Elements . . . . . 94
G.3. Information Model Elements . . . . . . . . . . . . . . . 89 G.3. Information Model Elements . . . . . . . . . . . . . . . 94
G.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 91 G.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 96
G.3.1.2. Endpoint Identification . . . . . . . . . . . . . 93 G.3.1.2. Endpoint Identification . . . . . . . . . . . . . 98
G.3.1.3. Software Identification . . . . . . . . . . . . . 94 G.3.1.3. Software Identification . . . . . . . . . . . . . 99
G.3.1.4. Hardware Identification . . . . . . . . . . . . . 97 G.3.1.4. Hardware Identification . . . . . . . . . . . . . 102
G.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 97
G.3.2.1. Platform Configuration Item Identifier . . . . . 97 G.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 102
G.3.2.2. Configuration Item Identifier . . . . . . . . . . 103 G.3.2.1. Platform Configuration Item Identifier . . . . . 102
G.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 105 G.3.2.2. Configuration Item Identifier . . . . . . . . . . 108
G.3.3. Endpoint characterization . . . . . . . . . . . . . . 105 G.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 110
G.3.4. Posture Attribute Expression . . . . . . . . . . . . 109 G.3.3. Endpoint characterization . . . . . . . . . . . . . . 110
G.3.4.2. Platform Configuration Attributes . . . . . . . . 109 G.3.4. Posture Attribute Expression . . . . . . . . . . . . 114
G.3.5. Actual Value Representation . . . . . . . . . . . . . 111 G.3.4.2. Platform Configuration Attributes . . . . . . . . 114
G.3.5.1. Software Inventory . . . . . . . . . . . . . . . 111 G.3.5. Actual Value Representation . . . . . . . . . . . . . 116
G.3.5.1. Software Inventory . . . . . . . . . . . . . . . 116
G.3.5.2. Collected Platform Configuration Posture G.3.5.2. Collected Platform Configuration Posture
Attributes . . . . . . . . . . . . . . . . . . . 112 Attributes . . . . . . . . . . . . . . . . . . . 117
G.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 113 G.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 118
G.3.6.1. Configuration Evaluation Guidance . . . . . . . . 113 G.3.6.1. Configuration Evaluation Guidance . . . . . . . . 118
G.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 115 G.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 120
G.3.7.1. Configuration Evaluation Results . . . . . . . . 115 G.3.7.1. Configuration Evaluation Results . . . . . . . . 120
G.3.7.2. Software Inventory Evaluation Results . . . . . . 117 G.3.7.2. Software Inventory Evaluation Results . . . . . . 122
Appendix H. Graph Model . . . . . . . . . . . . . . . . . . . . 117 Appendix H. Graph Model . . . . . . . . . . . . . . . . . . . . 122
H.1. Background: Graph Models . . . . . . . . . . . . . . . . 118 H.1. Background: Graph Models . . . . . . . . . . . . . . . . 123
H.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 119 H.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 124
H.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 119 H.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 124
H.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 120 H.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 125
H.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 120 H.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 125
H.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 121 H.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 126
H.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 121 H.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 126
H.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 121 H.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 126
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127
1. Introduction 1. Introduction
This document defines an information model for endpoint posture The SACM Information Model (IM) serves multiple purposes:
assessment. The scope of the information model is to describe the
mandatory-to-implement information needs required to realize the
assessment of an endpoint in a scalable and extensible way. The
information model aims to inform the development of specific data
models that support the endpoint posture assessment process. The
terms "information model" and "data model" align with the definitions
in [RFC3444].
The five primary activities to support this information model are: o to ensure interoperability between SACM data models that are used
as transport encodings,
1. Endpoint Identification o to provide a standardized set of information elements - the SACM
Vocabulary - to enable the exchange of content vital to automated
security posture assessment, and
2. Endpoint Characterization o to enable secure information sharing in a scalable and extensible
fashion in order to support the tasks conducted by SACM
components.
3. Endpoint Attribute Expression A complete set of requirements imposed on the IM can be found in
[I-D.ietf-sacm-requirements]. The SACM IM is intended to be used for
standardized data exchange between SACM components (data in motion).
Nevertheless, the information elements (IE) and their relationships
defined in this document can be leveraged to create and align
corresponding data models for data at rest.
4. Guidance Expression The information model expresses, for example, target endpoint (TE)
attributes, guidance, and evaluation results. The corresponding
information elements are consumed and produced by SACM components as
they carry out tasks.
5. Endpoint Evaluation Result Expression The primary tasks that this information model supports (on data,
control, and management plane) are:
These activities are aimed at the level of the technology that o TE Discovery
performs operations to support the collection, communication, and
evaluation of endpoint information.
Review of the SACM Use Case [RFC7632] usage scenarios show a common o TE Characterization
set of business process areas that are critical to understanding
endpoint posture such that appropriate policies, security
capabilities, and decisions can be developed and implemented.
For this information model we have chosen to focus on the following o TE Classification
business process areas:
o Endpoint Management o Collection
o Software Inventory Management o Evaluation
o Hardware Inventory Management o Information Sharing
o Configuration Management o SACM Component Discovery
o Vulnerability Management o SACM Component Authentication
These management process areas are a way to connect the SACM use o SACM Component Authorization
cases and building blocks [RFC7632] to the organizational needs such
that the definition of information requirements has a clearly
understood context. For more information, see Appendix B which maps
the SACM information model to the SACM use cases.
The SACM information model offers a loose coupling between providers o SACM Component Registration
and consumers of security information. A provider can relay what it
observes or infers, without knowing which consumers will use the
information, or how they will use it. A consumer need not know
exactly which provider generated a piece of information, or by what
method.
At the same time, a consumer *can* know these things, if necessary. These tasks are defined in [I-D.ietf-sacm-terminology].
As things evolve, a provider can relay supplemental information. 2. Conventions used in this document
Some consumers will understand and benefit from the supplemental
information; other consumers will not understand and will disregard
it.
1.1. Problem Statement 2.1. Requirements Language
SACM requires a large and broad set of mission and business The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
processes, and to make the most effective use of technology, the same "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
data must support multiple processes. The activities and processes document are to be interpreted as described in RFC 2119 [RFC2119].
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.
Administrators can't get technology from disparate sources to work 2.2. Information Element Examples
together; they need information to make decisions, but the
information is not available. Everyone is collecting the same data,
but storing it as different information. Administrators therefore
need to collect data and craft their own information, which may not
be accurate or interoperable because it's customized by each
administrator, not shared. A standard information model enables
flexibility in collecting, storing, and exchanging information
despite platform differences.
A way is needed to exchange information that (a) has breadth, meaning The notation used to define the SACM Information Elements (IEs) is
the pieces of the notation are useful for a variety of endpoint based on a customized version of the IPFIX information model syntax
information, and (b) has longevity, meaning that the pieces of the [RFC7012] which is described in Section 4.1 and Section 4.2.
notation will stay useful over time. However, there are several examples presented throughout the document
that use a simplified pseudo-code to illustrate the basic structure.
It should be noted that while they include actual names of subjects
and attributes as well as values, they are not intended to influence
how corresponding SACM IEs should be defined in Section 6. The
examples are provided for demonstration purposes only.
When creating standards, it's not sufficient to go from the 3. Information Elements
requirements directly to the protocol; the standards must eliminate
ambiguity in the information transported. This is the purpose of
information models generally. The SACM problem space is about
integrating many information sources. This information model
addresses the need to integrate security components, support multiple
data models, and provide interoperability in a way that is platform
agnostic, scales, and works over time.
1.1.1. Referring to an Endpoint The IEs defined in this document comprise the building blocks by
which all SACM content is composed. They are consumed and provided
by SACM components on the data plane. Every information element has
a unique label: its name. Every type of IE defined by the SACM IM is
registered as a type at the IANA registry. The Integer Index of the
IANA SMI number tables can be used by SACM data models.
How to refer to an endpoint is problematic. Ideally, an endpoint 3.1. Context of Information Elements
would have a unique identifier. These identifiers would have a one-
to-one relationship with endpoints. Every observation of an
endpoint, or inference about an endpoint would be labeled with its
identifier.
However: The IEs in this information model represent information related to
the following areas (based on the use cases described in [RFC7632]):
o An external posture attribute collector typically cannot observe o Endpoint Management
the unique identifier directly. An external posture attribute
collector should be able to report exactly what it has observed,
unembellished. It should not have to *infer* which endpoint it
has observed; that inference should be left to other SACM
components. So, SACM cannot require that every observation
include the unique endpoint identifier.
o Internal posture attribute collectors are not present on all o Software Inventory Management
endpoints. They are not present on "dumb" devices such as
Internet of Things (IoT) devices, or on Bring Your Own Device
(BYOD) devices. In these cases, *no* observers have direct access
to the unique endpoint identifier.
o An endpoint identifier is generally subject to cloning, when a o Hardware Inventory Management
system image is cloned. Then, it is no longer unique.
o Suppose the endpoint identifier is highly clone resistant -- such o Configuration Management
as a unique certificate within a hardware cryptographic module.
Even so, it is possible to replace all of the software -- for
example, changing a Windows machine to a Linux machine. Is it
still the same endpoint? For SACM purposes, it isn't really the
same endpoint.
So SACM components must be able to put disparate observations o Vulnerability Management
together and form a picture of an endpoint -- somewhat like a
detective. The SACM information model must facilitate this.
1.1.2. Dealing with Uncertainty 3.2. Extensibility of Information Elements
With many information models, the information is considered certain. A SACM data model based on this information model MAY include
In SACM, information is not certain. Attackers may develop additional information elements that are not defined here. The
countermeasures to fool some SACM components. Attackers may labels of additional information elements included in different SACM
compromise some SACM components. data models MUST NOT conflict with the labels of the information
elements defined by this information model, and the names of
additional information elements MUST NOT conflict with each other or
across multiple data models. In order to avoid naming conflicts, the
labels of additional IEs SHOULD be prefixed to avoid collisions
across extensions. The prefix MUST include an organizational
identifier and therefore, for example, MAY be an IANA enterprise
number, a (partial) name space URI, or an organization name
abbreviation.
So the model must let SACM components and humans reason with 4. Structure of Information Elements
uncertainty. There are no facts, only assertions.
SACM components must be able to cross check observations and There are two basic types of IEs:
inferences against each other. They should be able to give weight if
an observation or inference is corroborated by more than one method.
Although SACM will probably not prescribe *how* to do this cross
checking, SACM should provide the components with information that
can be used to determine provenance.
SACM components must be able to consider the reputation of the o Attributes: an instance of an attribute type is the simplest IE
observer or inferrer. That reputation should account for the method structure comprised of a unique attribute name and an attribute
of observing or inferring, the implementer of the SACM component that value.
made the observation or inference, and the compliance status of the
endpoint on which the observation or inference was made. For
example, if some observers are found to be vulnerable to a Day 1
exploit, observations from those observers deserve less weight. The
details of reputation technology may be out of scope for SACM.
However, again, SACM should provide components with information that
enables them to make this determination.
2. Conventions used in this document o Subjects: a subject is a richer structure that has a unique
subject name and one or more attributes or subjects. In essence,
instances of a subject type are defined (and differentiated) by
the attribute values and subjects associated with it.
2.1. Requirements Language hostname = "arbutus"
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", coordinates = (
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this latitude = N27.99619,
document are to be interpreted as described in RFC 2119 [RFC2119]. longitude = E86.92761
)
3. Information Model Framework Figure 1: Example instance of an attribute and subject.
The SACM information model is structured around a core framework that In general, every piece of information that enables security posture
can be easily extended to support the modeling needs for endpoint assessment or further enriches the quality of the assessment process
posture assessment. This section describes the key concepts that can be associated with metadata. In the SACM IM, metadata is
make up this framework as well as the IP Information Flow Export represented by specific subjects and is bundled with other attributes
(IPFIX) Information Model [RFC7012] syntax used to model the or subjects to provide additional information about them. The IM
different information model concepts. explicitly defines two kinds of metadata:
3.1. Attributes o Metadata focusing on the data origin (the SACM component that
provides the information to the SACM domain)
Attributes are used to model specific endpoint information. At a o Metadata focusing on the data source (the target endpoint that is
minimum, an attribute must have a name and a value. Additional assessed)
information about attributes can be modeled using metadata as
described in Section 3.3.
3.1.1. Syntax Metadata can also include relationships that refer to other
associated IEs (or SACM content in general) by using referencing
labels that have to be included in the metadata of the associated IE.
Subjects can be nested and the SACM IM allows for circular or
recursive nesting. The association of IEs via nesting results in a
tree-like structure wherein subjects compose the root and
intermediary nodes and attributes the leaves of the tree. This
semantic structure does not impose a specific structure on SACM data
models regarding data in motion or data repository schemata for data
at rest.
The SACM IM provides two top-level subjects that are used to ensure a
homogeneous structure for SACM content and its associated metadata:
SACM statements and SACM content-elements. Every set of IEs that is
provided by a SACM component in order to be consumed by another SACM
component uses these top-level subjects.
The notation the SACM IM is defined in is based on the IP Information
Flow Export (IPFIX) Information Model syntax described in [RFC7012].
The customized syntax used by the SACM IM is defined below in
Section 4.1 and Section 4.2.
4.1. Attribute Syntax
Attributes must be defined using the IPFIX Information Element Attributes must be defined using the IPFIX Information Element
Specification Template as described in Section 2.1 of [RFC7012]. The Specification Template as described in Section 2.1 of [RFC7012]. The
following is a modified version of the template for Information following is a modified version of the template for Information
Elements provided in Section 9.1 of [RFC7013]. Elements provided in Section 9.1 of [RFC7013].
elementId: Element identifier goes here if known, or elementId: Element identifier goes here
"TBD" if it will be assigned by IANA and if known, or "TBD" if it will
filled in at publication time.; obligatory be assigned by IANA and filled
in at publication time.;
name: Name goes here.; obligatory obligatory
dataType: Data type goes here; obligatory
status: Status goes here; obligatory name: Name goes here.; obligatory
description: Description goes here.; obligatory dataType: Data type goes here;
obligatory
For Information Elements that status: Status goes here; obligatory
represent flags, please include a
table that lists each flag value
(hexadecimal) and description.
The following is a template for that
table.
+-------+----------------------------------+ description: Description goes here.;
| Value | Description | obligatory
+-------+----------------------------------+
| | |
+-------+----------------------------------+
dataTypeSemantics: Data type semantics, if any, go here; optional 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.
units: Units, if any, go here; optional +-------+----------------------------------+
| Value | Description |
+-------+----------------------------------+
| | |
+-------+----------------------------------+
range: Range, if not implied by the data type, goes dataTypeSemantics: Data type semantics, if any,
here; optional go here; optional
references: References to other RFCs or documents outside units: Units, if any, go here;
the IETF, in which additional information is optional
given, or which are referenced by the
description, go here; optional
Figure 1 range: Range, if not implied by the
data type, goes here; optional
3.2. Objects 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
Objects are the mechanism by which attributes (Section 3.1) and/or Figure 2: Attribute Information Element Specification Template
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 4.2. Subject Syntax
Objects are complex Information Elements that can be created using Subjects are complex Information Elements that can be created using
one of the following IPFIX constructs that are defined in Section 3.1 one of the following IPFIX constructs that are defined in Section 3.1
of [RFC7012]. of [RFC7012]. ***TODO: UPDATE WITH REVISED IPFIX-LIKE CONSTRUCTS***
o basicList: a list of zero or more instances of any Information o basicList: a list of zero or more instances of any Information
Element Element
o subTemplateList: a list of zero or more instances of a single, o subTemplateList: a list of zero or more instances of a single,
specific Template specific Template
o subTemplateMultiList: a list of zero or more instances of any o subTemplateMultiList: a list of zero or more instances of any
Template Template
The following is a modified version of the template for Information The following is a modified version of the template for Information
Elements provided in Section 9.1 of [RFC7013] that can be used to Elements provided in Section 9.1 of [RFC7013] that can be used to
model objects. model subjects.
elementId: Element identifier goes here if known, or elementId: Element identifier goes here
"TBD" if it will be assigned by IANA and if known, or "TBD" if it
filled in at publication time.; obligatory will be assigned by IANA and
filled in at publication
time.; obligatory
name: Name goes here.; obligatory name: Name goes here.; obligatory
dataType: Data type goes here; obligatory dataType: Data type goes here;
obligatory
status: Status goes here; obligatory status: Status goes here; obligatory
description: Description goes here.; obligatory description: Description goes here.;
obligatory
Please include a high-level model diagram that uses Please include a high-level
the following format which is a simplified version model diagram that uses
of a high-level diagram format used in [RFC6313]. the following format which
is a simplified version
of a high-level diagram
format used in [RFC6313].
<IE-Name> = (<IE-DataType>, <IE-DataTypeSemantic>, <IE-Name> =
<IE-1>, (<IE-DataType>,
<IE-2>, <IE-DataTypeSemantic>,
<IE-3>, <IE-1>,
... <IE-2>,
) <IE-3>,
...
)
dataTypeSemantics: Data type semantics, if any, go here; optional dataTypeSemantics: Data type semantics, if any,
go here; optional
units: Units, if any, go here; optional units: Units, if any, go here;
optional
range: Range, if not implied by the data type, goes range: Range, if not implied by
here; optional the data type, goes
here; optional
references: References to other RFCs or documents outside references: References to other RFCs or
the IETF, in which additional information is documents outside the IETF,
given, or which are referenced by the in which additional
description, go here; optional information is given, or
which are referenced by the
description, go here;
optional
Figure 2 Figure 3: Subject Information Element Specification Template
3.3. Metadata 4.3. SACM Content Elements
Metadata allows components to annotate objects and attributes with Every piece of information that is provided by a SACM component is
additional information that will allow other components to make a always associated with a set of metadata, for example, the timestamp
determination about the provenance of the objects and attributes at which this set of information was produced (e.g. by a collection
during exchanges and evaluations. A proposal outlining various task) or what target endpoint this set of information is about (e.g.
options for representing metadata attributes/objects in the IPFIX the data-source or a target endpoint identifier, respectively). The
syntax is being discussed on the mailing list. TODO: See IM issue subject that associates content IE with content-metadata IE is called
#39 at https://github.com/sacmwg/draft-ietf-sacm-information-model/ a content-element. Content metadata can also include relationships
issues/39 for more information. that express associations with other content-elements.
3.4. Relationships content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
hostname = "arbutus",
coordinates = (
latitude = N27.99619,
longitude = E86.92761
)
)
TODO: Define what a relationship is. At the end of the day, we want Figure 4: Example set of IEs associated with a timestamp and a target
to be able to describe the relationships between assets, endpoints, endpoint label.
and attributes. QUESTION: Are relationships just metadata? Lisa's
notes have some information on relationships:
https://mailarchive.ietf.org/arch/msg/sacm/
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 4.4. SACM Statements
One or more SACM content elements are bundled in a SACM statement.
In contrast to content-metadata, statement-metatdata focuses on the
providing SACM component instead of the target endpoint that the
content is about. The only content-specific metadata included in the
SACM statement is the content-type IE. Therefore, multiple content-
elements that share the same statement metadata and are of the same
content-type can be included in a single SACM statement. A SACM
statement functions similar to an envelope or a header. Its purpose
is to enable the tracking of the origin of data inside a SACM domain
and more importantly to enable the mitigation of conflicting
information that my originate from different SACM components. How a
consuming SACM component actually deals with conflicting information
is out-of-scope of the SACM IM. Semantically, the term statement
implies that the SACM content provided by a SACM component might not
be correct in every context, but rather is the result of an best-
effort to produce correct information.
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2,
content-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
hostname = "arbutus"
)
)
Figure 5: Example of a simple SACM statement including a single
content-element.
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2
content-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
coordinates = (
latitude = N27.99619,
longitude = E86.92761
)
)
)
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934744,
data-origin = e42885a1-0270-44e9-bb5c-865cf6bd4800,
content-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193821,
te-label = fb02e551-7101-4e68-8dec-1fde6bd10981
),
coordinates = (
latitude = N16.67622,
longitude = E141.55321
)
)
)
Figure 6: Example of conflicting information originating from
different SACM components.
4.5. Relationships
An IE can be associated with another IE, e.g. a user-name attribute
can be associated with a content-authorization subject. These
references are expressed via the relationships subject, which can be
included in a corresponding content-metadata subject. The
relationships subject includes a list of one or more references. The
SACM IM does not enforce a SACM domain to use unique identifiers as
references. Therefore, there are at least two ways to reference
another content-element:
o The value of a reference represents a specific content-label that
is unique in a SACM domain (and has to be included in the
corresponding content-element metadata in order to be referenced),
or
o The reference is a subject that includes an appropriate number of
IEs in order to identify the referenced content-element by its
actual content.
It is recommended to provide unique identifiers in a SACM domain and
the SACM IM provides a corresponding naming-convention as a reference
in section FIXME. The alternative highlighted above summarizes a
valid approach that does not require unique identifiers and is
similar to the approach of referencing target endpoints via
identifying attributes included in a characterization record (FIXME
REF arch).
content-element = (
content-metadata = (
collection-timestamp = 1461934031,
te-label =
fb02e551-7101-4e68-8dec-1fde6bd10981
relationships = (
associated-with-user-account =
f3d70ef4-7e18-42af-a894-8955ba87c95d
)
),
hostname = "arbutus"
)
content-element = (
content-metadata = (
content-label = f3d70ef4-7e18-42af-a894-8955ba87c95d
),
user-account = (
username = romeo
authentication = local
)
)
Figure 7: Example instance of a content-element subject associated
with another subject via its content metadata.
4.6. Event
Event subjects provide a structure to represent the change of IE
values that was detected by a collection task at a specific point of
time. It is mandatory to include the new values and the collection
timestamp in an event subject and it is recommended to include the
past values and a collection timestamp that were replaced by the new
IE values. Every event can also be associated with a subject-
specific event-timestamp and a lastseen-timestamp that might differ
from the corresponding collection-timestamps. If these are omitted
the collection-timestamp that is included in the content-metadata
subject is used instead.
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2,
content-type = event
),
event = (
event-attributes = (
event-name = "host-name change",
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source =
fb02e551-7101-4e68-8dec-1fde6bd10981,
event-component = past-state
),
hostname = "arbutus"
),
content-element = (
content-metadata = (
collection-timestamp = 146195723,
data-source =
fb02e551-7101-4e68-8dec-1fde6bd10981,
event-component = current-state
),
hostname = "lilac"
)
)
)
Figure 8: Example of a SACM statement containing an event.
4.7. Categories
Categories are special IEs that enable to refer to multiple types of
IE via just one name. Therefore, they are similar to a type-choice.
A prominent example of a category is network-address. Network-
address is a category that every kind of network address is
associated with, e.g. mac-address, ipv4-address, ipv6-address, or
typed-network-address. If a subject includes network-address as one
of its components, any of the category members are valid to be used
in its place.
Another prominent example is EndpointIdentifier. Some IEs can be
used to identify (and over time re-recognize) target endpoints -
those are associated with the category endpoint-identifier.
4.8. 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. A proposal outlining Privacy Considerations sections respectively. A proposal outlining
various options for representing designation attributes/objects in various options for representing designation attributes/objects in
the IPFIX syntax is being discussed on the mailing list. See IM the IPFIX syntax is being discussed on the mailing list. See IM
issue #39 at https://github.com/sacmwg/draft-ietf-sacm-information- issue #39 at https://github.com/sacmwg/draft-ietf-sacm-information-
model/issues/39 for more information. model/issues/39 for more information.
3.6. Privacy 4.9. Privacy
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, it was proposed that endpoint identity and monitoring. As a result, it was proposed that
a privacy property be included to denote when a information element a privacy property be included to denote when a information element
represents a privacy concern. A proposal outlining various options represents a privacy concern. A proposal outlining various options
for representing privacy attributes/objects in the IPFIX syntax is for representing privacy attributes/objects in the IPFIX syntax is
being discussed on the mailing list. See IM issue #39 at being discussed on the mailing list. See IM issue #39 at
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39 https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39
for more information. for more information.
3.7. Type Space 4.10. Type Space
This section describes the abstract data types that can be used for This section describes the abstract data types that can be used for
the specification of the SACM Information Elements in Section 5. the specification of the SACM Information Elements in Section 6.
Section 3.7.1 describes the set of abstract data types. This section Section 4.10.1 describes the set of abstract data types. This
used Section 3 of [RFC7012] as a starting point and was modified to section used Section 3 of [RFC7012] as a starting point and was
address the needs of SACM. modified to address the needs of SACM.
3.7.1. Abstract Data Types 4.10.1. Abstract Data Types
This section describes the set of valid abstract data types of the This section describes the set of valid abstract data types of the
SACM information model, independent of how they are implemented in a SACM information model, independent of how they are implemented in a
data model. Note that further abstract data types may be specified data model. Note that further abstract data types may be specified
by future extensions of the SACM information model. by future extensions of the SACM information model.
3.7.1.1. unsigned8 4.10.1.1. unsigned8
The type "unsigned8" represents a non-negative integer value in the The type "unsigned8" represents a non-negative integer value in the
range of 0 to 255. range of 0 to 255.
3.7.1.2. unsigned16 4.10.1.2. unsigned16
The type "unsigned16" represents a non-negative integer value in the The type "unsigned16" represents a non-negative integer value in the
range of 0 to 65535. range of 0 to 65535.
3.7.1.3. unsigned32 4.10.1.3. unsigned32
The type "unsigned32" represents a non-negative integer value in the The type "unsigned32" represents a non-negative integer value in the
range of 0 to 4294967295. range of 0 to 4294967295.
3.7.1.4. unsigned64 4.10.1.4. unsigned64
The type "unsigned64" represents a non-negative integer value in the The type "unsigned64" represents a non-negative integer value in the
range of 0 to 18446744073709551615. range of 0 to 18446744073709551615.
3.7.1.5. signed8 4.10.1.5. signed8
The type "signed8" represents an integer value in the range of -128 The type "signed8" represents an integer value in the range of -128
to 127. to 127.
3.7.1.6. signed16 4.10.1.6. signed16
The type "signed16" represents an integer value in the range of The type "signed16" represents an integer value in the range of
-32768 to 32767. -32768 to 32767.
3.7.1.7. signed32 4.10.1.7. signed32
The type "signed32" represents an integer value in the range of The type "signed32" represents an integer value in the range of
-2147483648 to 2147483647. -2147483648 to 2147483647.
3.7.1.8. signed64 4.10.1.8. signed64
The type "signed64" represents an integer value in the range of The type "signed64" represents an integer value in the range of
-9223372036854775808 to 9223372036854775807. -9223372036854775808 to 9223372036854775807.
3.7.1.9. float32 4.10.1.9. float32
The type "float32" corresponds to an IEEE single-precision 32-bit The type "float32" corresponds to an IEEE single-precision 32-bit
floating point type as defined in [IEEE.754.1985]. floating point type as defined in [IEEE.754.1985].
3.7.1.10. float64 4.10.1.10. float64
The type "float64" corresponds to an IEEE double-precision 64-bit The type "float64" corresponds to an IEEE double-precision 64-bit
floating point type as defined in [IEEE.754.1985]. floating point type as defined in [IEEE.754.1985].
3.7.1.11. boolean 4.10.1.11. boolean
The type "boolean" represents a binary value. The only allowed The type "boolean" represents a binary value. The only allowed
values are "true" and "false". values are "true" and "false".
3.7.1.12. macAddress 4.10.1.12. macAddress
The type "macAddress" represents a MAC-48 address as defined in The type "macAddress" represents a MAC-48 address as defined in
[IEEE.802-3.2012]. [IEEE.802-3.2012].
3.7.1.13. string 4.10.1.13. octetArray
The type "octetArray" represents a finite-length string of octets.
4.10.1.14. string
The type "string" represents a finite-length string of valid The type "string" represents a finite-length string of valid
characters from the Unicode coded character set [ISO.10646]. Unicode characters from the Unicode coded character set [ISO.10646]. Unicode
incorporates ASCII [RFC20] and the characters of many other incorporates ASCII [RFC20] and the characters of many other
international character sets. international character sets.
3.7.1.14. dateTimeSeconds 4.10.1.15. dateTimeSeconds
The type "dateTimeSeconds" represents a time value expressed with The type "dateTimeSeconds" represents a time value expressed with
second-level precision. second-level precision.
3.7.1.15. dateTimeMilliseconds 4.10.1.16. dateTimeMilliseconds
The type "dateTimeMilliseconds" represents a time value expressed The type "dateTimeMilliseconds" represents a time value expressed
with millisecond-level precision. with millisecond-level precision.
3.7.1.16. dateTimeMicroseconds 4.10.1.17. dateTimeMicroseconds
The type "dateTimeMicroseconds" represents a time value expressed The type "dateTimeMicroseconds" represents a time value expressed
with microsecond-level precision. with microsecond-level precision.
3.7.1.17. dateTimeNanoseconds 4.10.1.18. dateTimeNanoseconds
The type "dateTimeNanoseconds" represents a time value expressed with The type "dateTimeNanoseconds" represents a time value expressed with
nanosecond-level precision. nanosecond-level precision.
3.7.1.18. ipv4Address 4.10.1.19. ipv4Address
The type "ipv4Address" represents an IPv4 address as defined in The type "ipv4Address" represents an IPv4 address as defined in
[RFC0791]. [RFC0791].
3.7.1.19. ipv6Address 4.10.1.20. ipv6Address
The type "ipv6Address" represents an IPv6 address as defined in The type "ipv6Address" represents an IPv6 address as defined in
[RFC3587]. [RFC3587].
3.7.1.20. basicList 4.10.1.21. ciscoTrainSoftwareVersion
The type "ciscoTrainSoftwareVersion" represents a software version
that conforms to the Cisco IOS Train string format.
4.10.1.22. rpmSoftwareVersion
The type "rpmSoftwareVersion" represents a software version that
conforms to the EPOCH:VERSION-RELEASE format.
4.10.1.23. simpleSoftwareVersion
The type "simpleSoftwareVersion" represents a software version that
is a hierarchical list of non-negative integers separated by a single
character delimiter.
4.10.1.24. basicList
The type "basicList" represents a list of zero or more instances of The type "basicList" represents a list of zero or more instances of
any Information Element as defined in [RFC6313]. any Information Element as defined in [RFC6313].
3.7.1.21. subTemplateList 4.10.1.25. subTemplateList
The type "subTemplateList" represents a list of zero or more The type "subTemplateList" represents a list of zero or more
instances of a structured data type, where the data type of each list 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 element is the same and corresponds with a single Template Record as
defined in [RFC6313]. defined in [RFC6313].
3.7.1.22. subTemplateMultiList 4.10.1.26. subTemplateMultiList
The type "subTemplateMultiList" represents a list of zero or more The type "subTemplateMultiList" represents a list of zero or more
instances of a structured data type, where the data type of each list instances of a structured data type, where the data type of each list
element can be different and corresponds with different Template element can be different and corresponds with different Template
definitions as defined in [RFC6313]. definitions as defined in [RFC6313].
3.7.2. Data Type Semantics 4.10.2. Data Type Semantics
This section describes the set of valid data type semantics of the This section describes the set of valid data type semantics of the
IPFIX information model. IPFIX information model.
Further data type semantics may be specified by future updates to Further data type semantics may be specified by future updates to
this document. Changes to the associated "IPFIX Information Element this document. Changes to the associated "IPFIX Information Element
Semantics" subregistry [IANA-IPFIX] require a Standards Action Semantics" subregistry [IANA-IPFIX] require a Standards Action
[RFC5226]. [RFC5226].
3.7.3. quantity 4.10.3. quantity
"quantity" is a numeric (integral or floating point) value "quantity" is a numeric (integral or floating point) value
representing a measured value pertaining to the record. This is representing a measured value pertaining to the record. This is
distinguished from counters that represent an ongoing measured value distinguished from counters that represent an ongoing measured value
whose "odometer" reading is captured as part of a given record. This whose "odometer" reading is captured as part of a given record. This
is the default semantic type of all numeric data types. is the default semantic type of all numeric data types.
3.7.4. totalCounter 4.10.4. totalCounter
"totalCounter" is an integral value reporting the value of a counter. "totalCounter" is an integral value reporting the value of a counter.
Counters are unsigned and wrap back to zero after reaching the limit Counters are unsigned and wrap back to zero after reaching the limit
of the type. For example, an unsigned64 with counter semantics will of the type. For example, an unsigned64 with counter semantics will
continue to increment until reaching the value of 2**64 - 1. At this 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 point, the next increment will wrap its value to zero and continue
counting from zero. The semantics of a total counter is similar to counting from zero. The semantics of a total counter is similar to
the semantics of counters used in the Simple Network Management the semantics of counters used in the Simple Network Management
Protocol (SNMP), such as Counter32 as defined in [RFC2578]. The only Protocol (SNMP), such as Counter32 as defined in [RFC2578]. The only
difference between total counters and counters used in SNMP is that difference between total counters and counters used in SNMP is that
the total counters have an initial value of 0. A total counter the total counters have an initial value of 0. A total counter
counts independently of the export of its value. counts independently of the export of its value.
3.7.5. deltaCounter 4.10.5. deltaCounter
"deltaCounter" is an integral value reporting the value of a counter. "deltaCounter" is an integral value reporting the value of a counter.
Counters are unsigned and wrap back to zero after reaching the limit Counters are unsigned and wrap back to zero after reaching the limit
of the type. For example, an unsigned64 with counter semantics will of the type. For example, an unsigned64 with counter semantics will
continue to increment until reaching the value of 2**64 - 1. At this 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 point, the next increment will wrap its value to zero and continue
counting from zero. The semantics of a delta counter is similar to counting from zero. The semantics of a delta counter is similar to
the semantics of counters used in SNMP, such as Counter32 as defined the semantics of counters used in SNMP, such as Counter32 as defined
in [RFC2578]. The only difference between delta counters and in [RFC2578]. The only difference between delta counters and
counters used in SNMP is that the delta counters have an initial 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 value of 0. A delta counter is reset to 0 each time it is exported
and/or expires without export. and/or expires without export.
3.7.6. identifier 4.10.6. identifier
"identifier" is an integral value that serves as an identifier. "identifier" is an integral value that serves as an identifier.
Specifically, mathematical operations on two identifiers (aside from Specifically, mathematical operations on two identifiers (aside from
the equality operation) are meaningless. Identifiers MUST be one of the equality operation) are meaningless. Identifiers MUST be one of
the signed or unsigned data types. the signed or unsigned data types.
3.7.7. flags 4.10.7. flags
"flags" is an integral value that represents a set of bit fields. "flags" is an integral value that represents a set of bit fields.
Logical operations are appropriate on such values, but other Logical operations are appropriate on such values, but other
mathematical operations are not. Flags MUST always be of an unsigned mathematical operations are not. Flags MUST always be of an unsigned
data type. data type.
3.7.8. list 4.10.8. list
A list represents an arbitrary-length sequence of zero or more A list represents an arbitrary-length sequence of zero or more
Information Elements, either composed of regular Information Elements Information Elements, either composed of regular Information Elements
or composed of data conforming to a Template Record. See [RFC6313]. or composed of data conforming to a Template Record. See [RFC6313].
4. Information Model Assets 5. 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
also explain the types of assets below rather than just referencing also explain the types of assets below rather than just referencing
out to the Terminology draft. out to the Terminology draft.
skipping to change at page 21, line 27 skipping to change at page 25, line 27
|Instance |__________________|! !| |Instance |__________________|! !|
+---------+* in> 1|! !| +---------+* in> 1|! !|
|! !| |! !|
|! !|____ |! !|____
|! !|0..1| |! !|0..1|
+-----+ | +-----+ |
|* | |* |
|_______| |_______|
in> in>
Figure 3: Model of an Endpoint Figure 9: Model of an Endpoint
4.1. Asset 5.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 [I-D.ietf-sacm-terminology] defines an asset as: Defined in
{{RFC4949}} as "a system resource that is (a) required to be {{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". In the scope of SACM, an asset can be composed of other mission". In the scope of SACM, an asset can be composed of other
assets. Examples of Assets include: Endpoints, Software, Guidance, assets. Examples of Assets include: Endpoints, Software, Guidance,
or X.509 public key certificates. An asset is not necessarily owned or X.509 public key certificates. An asset is not necessarily owned
by an organization. by an organization.
4.2. Endpoint 5.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. components, SW components, asset identity, etc.
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 5.3. Hardware Component
TODO: Define a Hardware Component asset. Explain how it is things TODO: Define a Hardware Component asset. Explain how it is things
like motherboards, network cards, etc. like motherboards, network cards, etc.
Hardware components may also be assets and/or harmful. For example, Hardware components may also be assets and/or harmful. For example,
a USB port on a system may be disabled to prevent information flow a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional into our out of a particular system; this provides an additional
layer of protection that can complement software based protections. layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm. that can be compromised in some way to do harm.
A data model MAY designate a hardware component by its manufacturer A data model MAY designate a hardware component by its manufacturer
and a part number. and a part number.
4.3.1. Hardware Instance 5.3.1. Hardware Instance
A hardware instance is just an instance of a particular component. A hardware instance is just an instance of a particular component.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o A hardware instance is an "instance of" a hardware component. o A hardware instance is an "instance of" a hardware component.
o A hardware instance is "in" an endpoint. o A hardware instance is "in" an endpoint.
Hardware instances may need to be modeled because (a) an endpoint may Hardware instances may need to be modeled because (a) an endpoint may
have multiple instances of a hardware component, (b) a hardware have multiple instances of a hardware component, (b) a hardware
instance may be compromised, whereas other instances may remain instance may be compromised, whereas other instances may remain
intact. intact.
A data model MAY designate a hardware instance by its component and a A data model MAY designate a hardware instance by its component and a
unique serial number. unique serial number.
4.4. Software Component 5.4. Software Component
TODO: Define a Software Component asset. Explain how it is the TODO: Define a Software Component asset. Explain how it is the
software installed on the endpoint including the operating system. software installed on the endpoint including the operating system.
An endpoint contains and runs software components. An endpoint contains and runs software components.
Relationship: Relationship:
o If an endpoint has an instance of a software component, we say o If an endpoint has an instance of a software component, we say
that the software component is "in" the endpoint. This is a that the software component is "in" the endpoint. This is a
skipping to change at page 24, line 12 skipping to change at page 28, line 12
different components. Software versioning is not built into the different components. Software versioning is not built into the
information model. information model.
Each separately installable piece of software SHOULD be modeled as a Each separately installable piece of software SHOULD be modeled as a
component. Sometimes it may be better to divide more finely: what an component. Sometimes it may be better to divide more finely: what an
installer installs MAY be modeled as several components. installer installs MAY be modeled as several components.
A data model MAY identify a software component by parts of an ISO A data model MAY identify a software component by parts of an ISO
SWID tag. SWID tag.
4.4.1. Software Instance 5.4.1. Software Instance
Each copy of a piece of software is called a software instance. The Each copy of a piece of software is called a software instance. The
configuration of a software instance is regarded as part of the configuration of a software instance is regarded as part of the
software instance. Configuration can strongly affect security software instance. Configuration can strongly affect security
posture. posture.
A data model MUST support the following relationships: A data model MUST support the following relationships:
o A software instance is an "instance of" a software component. o A software instance is an "instance of" a software component.
o A software instance is "in" an endpoint. o A software instance is "in" an endpoint.
A data model MAY use ISO SWID tags to describe software instances. A data model MAY use ISO SWID tags to describe software instances.
4.5. Asset Identity 5.5. Asset Identity
TODO: Define an Asset Identity asset. Explain how it is things like TODO: Define an Asset Identity asset. Explain how it is things like
user, device, etc. where certificates, usernames, etc. come into user, device, etc. where certificates, usernames, etc. come into
place since they are not really hardware or software. NOTE: Make place since they are not really hardware or software. NOTE: Make
sure it is clear that this is not identity in the sense of what we sure it is clear that this is not identity in the sense of what we
have been saying endpoint identity (now designation). have been saying endpoint identity (now designation).
4.6. Relationships 5.6. Asset Relationships
TODO: Define the relationships between assets (endpoints, hardware, TODO: Define the relationships between assets (endpoints, hardware,
software, etc.). These will depicted in the overview diagram. software, etc.). These will depicted in the overview diagram.
5. Information Model Elements 6. Information Model Elements
TODO: Define specific containers, attributes, and metadata. We may TODO: Define specific subjects, attributes, and metadata. We may
want to consider adding small diagrams showing the relationships want to consider adding small diagrams showing the relationships
between each (see Lisa's notes: between each (see Lisa's notes:
https://mailarchive.ietf.org/arch/msg/sacm/ https://mailarchive.ietf.org/arch/msg/sacm/
kWxlnboHAXD87cned9WavwPZy5w). This may be too much work, but, not kWxlnboHAXD87cned9WavwPZy5w). This may be too much work, but, not
sure yet. sure yet.
The SACM Information Model contains several elements of the The SACM Information Model contains several elements of the
architecture, including: architecture, including:
o SACM Components, which may be Collectors, Evaluators, etc. o SACM Components, which may be Collectors, Evaluators, etc.
skipping to change at page 25, line 25 skipping to change at page 29, 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 4 introduces the endpoint attributes and their relationships. Figure 10 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 25, line 49 skipping to change at page 29, 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 4: Model of an Endpoint Figure 10: 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 5 is the core of the information model. It represents the Figure 11 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 5: Information Elements Figure 11: Information Elements
Figure 6 is a potential alternative structure for assertions. It is Figure 12 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 6: Information Elements, Take 2 Figure 12: 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 6.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"
term. term.
Identifying attributes let a consumer identify an endpoint, for two Identifying attributes let a consumer identify an endpoint, for two
purposes: purposes:
o To tell whether two endpoint attribute assertions concern the same o To tell whether two endpoint attribute assertions concern the same
endpoint (This is not simple, as Section 1.1.1 explains.) endpoint
o To respond to compliance measurements, for example by reporting, o To respond to compliance measurements, for example by reporting,
remediating, and quarantining (SACM does not specify these remediating, and quarantining (SACM does not specify these
responses, but SACM exists to enable them.) responses, but SACM exists to enable them.)
Out of scope of this section: *classifying* an endpoint so as to Out of scope of this section: *classifying* an endpoint so as to
apply appropriate collection guidance to it. We don't call this apply appropriate collection guidance to it. We don't call this
"identification". "identification".
5.1.1. How Known 6.1.1. How Known
Each attribute-value pair or triple MUST be marked with how the Each attribute-value pair or triple MUST be marked with how the
provider knows. There MUST be at least one marking. The possible provider knows. There MUST be at least one marking. The possible
markings follow. markings follow.
"Self" means that the endpoint furnished the information: it is "Self" means that the endpoint furnished the information: it is
self-reported. "Self" does not (necessarily) mean that the self-reported. "Self" does not (necessarily) mean that the
provider runs on the the monitored endpoint. Self-reported provider runs on the the monitored endpoint. Self-reported
information is generally subject to the Lying Endpoint Problem. information is generally subject to the Lying Endpoint Problem.
(TODO: citation) (TODO: citation)
skipping to change at page 28, line 20 skipping to change at page 32, line 20
* The provider makes an SSH connection to the endpoint and knows * The provider makes an SSH connection to the endpoint and knows
the endpoint's public key by virtue of authenticating it. the endpoint's public key by virtue of authenticating it.
* The monitored endpoint is a virtual machine and the provider * The monitored endpoint is a virtual machine and the provider
knows by peeking into it. knows by peeking into it.
TODO: Explain security considerations and how consumers are meant to TODO: Explain security considerations and how consumers are meant to
use these markings. use these markings.
5.1.2. Whether to Include 6.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. Certificate 6.1.3. Certificate
5.1.3.1. Range of values 6.1.3.1. Range of values
MUST be X.509 certificate, per [RFC5280]. MUST be X.509 certificate, per [RFC5280].
5.1.3.2. Meaning 6.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.3.3. Multiplicity 6.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.3.4. Stability 6.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.3.5. Accuracy 6.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.3.6. Data model requirements 6.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.4. Public Key 6.1.4. Public Key
TODO TODO
5.1.5. Username? 6.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.6. Tool-Specific Identifier 6.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.7. Identification of Endpoints where SACM Components Reside 6.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.8. Security Considerations 6.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. Identity 6.2. 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 31, line 5 skipping to change at page 35, 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.3. Location 6.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 32, line 5 skipping to change at page 36, 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.4. Endpoint Attribute Assertion 6.4. Endpoint Attribute Assertion
TODO: Integrate into the Section 3 as appropriate. TODO: Integrate into the Section 4 as appropriate.
5.4.1. Form and Precise Meaning 6.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 32, line 42 skipping to change at page 36, 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.4.2. Asserter 6.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.4.3. Example 6.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.4.4. A Use Case 6.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.4.5. Event 6.4.5. Difference between Attribute and Event
An event is represented as a Posture Attribute Assertion whose time
interval has length zero.
Some potential kinds of events are:
o A structured syslog message [RFC5424]
o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA]
o A NetFlow message [RFC3954]
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 34, line 24 skipping to change at page 38, line 11
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.5. Attribute-Value Pair 6.5. Attribute-Value Pair
TODO: Integrate into the Section 3 as appropriate. TODO: Integrate into the Section 4 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 4: more than one) for each box in Figure 10:
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 35, line 14 skipping to change at page 39, line 4
o Endpoint: The value is a unique endpoint identifier. o Endpoint: The value is a unique endpoint identifier.
o Location o Location
o Identity: The value is the non-secret part of a credential. For o Identity: The value is the non-secret part of a credential. For
example, it may be a certificate, or just a subject Distinguished example, it may be a certificate, or just a subject Distinguished
Name extracted from a certificate. It may be a username. Name extracted from a certificate. It may be a username.
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.5.1. Unique Endpoint Identifier 6.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.5.2. Posture Attribute 6.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.6. Evaluation Result 6.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 4 does not show Attribute Assertions from which it derives. (Figure 10 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.7. SACM Component 6.7. Organization?
Although SACM components are mainly covered by the SACM architecture,
we have some remarks. TODO: Move them to the architecture document?
ISSUE (CEK): Why do we need information elements that model SACM
compoments?
5.7.1. External Attribute Collector
An external collector is a collector that observes endpoints from
outside. [kkw-many of these [collectors] are actually configured and
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
matter if the [collector] isn't intended to support posture
assessment, but happens to have information that can be used by
posture assessment collection consumers? do we lump them together
with collectors that are intended to support posture assessment but
run external to the endpoint?] [jmf: ditto. The exampled below are
of things that would perform external collection].
[cek-to kkw's comment, I think the purpose here is to capture their
contribution to continuous monitoring. I don't see the need to
separate things whose primary job is monitoring from things whose
primary job is something else. Is there a need?]
[cek-to jmf's comment, that is what they are examples of; is a text
change needed?]
Examples:
o A RADIUS server [RFC3580] whereby an endpoint has logged onto the
network
o A network profiling system, which discovers and classifies network
nodes
o A Network Intrusion Detection System (NIDS) sensor
o A vulnerability scanner
o A hypervisor that peeks into the endpoint, the endpoint being a
virtual machine
o A management system that configures and installs software on the
endpoint
5.7.2. Evaluator
An evaluator can consume endpoint attribute assertions, previous
evaluations of posture attributes, or previous reports of evaluation
results. [kkw-i don't think this conflicts with the definition in the
terminology doc re: that evaluation tasks evaluate posture
attributes.]
[cek-I like the change. I think it *does* require a change in the
terminology doc, though.]
Example: a NEA posture validator [RFC5209]
[jmf- a NEA posture validator is not an example of this definition.
A NEA posture assessment is, maybe?]
[cek-Why isn't a NEA posture validator an example?]
5.8. 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.9. Guidance 6.8. 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.9.1. Internal Collection Guidance 6.8.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.9.2. External Collection Guidance 6.8.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.9.3. Evaluation Guidance 6.8.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.9.4. Retention Guidance 6.8.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.10. Endpoint 6.9. 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 39, line 27 skipping to change at page 41, line 45
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.10.1. Endpoint Identity 6.9.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.10.2. Software Component 6.9.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 40, line 27 skipping to change at page 42, line 44
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.10.2.1. Unique Software Identifier 6.9.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.11. User 6.10. User
5.11.1. User Identity 6.10.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 6.11. hardwareSerialNumber
elementId: TBD elementId: TBD
name: hardwareSerialNumber name: hardwareSerialNumber
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: A globally unique identifier for a particular description: A globally unique identifier for a particular
piece of hardware assigned by the vendor. piece of hardware assigned by the vendor.
5.13. interfaceName 6.12. interfaceName
elementId: TBD elementId: TBD
name: interfaceName name: interfaceName
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: A short name uniquely describing an interface, description: A short name uniquely describing an interface,
eg "Eth1/0". See [RFC2863] for the definition eg "Eth1/0". See [RFC2863] for the definition
of the ifName object. of the ifName object.
5.14. interfaceIndex 6.13. interfaceIndex
elementId: TBD elementId: TBD
name: interfaceIndex name: interfaceIndex
dataType: unsigned32 dataType: unsigned32
dataTypeSemantics: identifier dataTypeSemantics: identifier
status: current status: current
description: The index of an interface installed on an endpoint. description: The index of an interface installed on an endpoint.
The value matches the value of managed object The value matches the value of managed object
'ifIndex' as defined in [RFC2863]. Note that ifIndex 'ifIndex' as defined in [RFC2863]. Note that ifIndex
values are not assigned statically to an interface values are not assigned statically to an interface
and that the interfaces may be renumbered every time and that the interfaces may be renumbered every time
the device's management system is re-initialized, the device's management system is re-initialized,
as specified in [RFC2863]. as specified in [RFC2863].
5.15. interfaceMacAddress 6.14. interfaceMacAddress
elementId: TBD elementId: TBD
name: interfaceMacAddress name: interfaceMacAddress
dataType: macAddress dataType: macAddress
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The IEEE 802 MAC address associated with a network description: The IEEE 802 MAC address associated with a network
interface on an endpoint. interface on an endpoint.
5.16. interfaceType 6.15. interfaceType
elementId: TBD elementId: TBD
name: interfaceType name: interfaceType
dataType: unsigned32 dataType: unsigned32
dataTypeSemantics: identifier dataTypeSemantics: identifier
status: current status: current
description: The type of a network interface. The value matches description: The type of a network interface. The value matches
the value of managed object 'ifType' as defined in the value of managed object 'ifType' as defined in
[IANA registry ianaiftype-mib]. [IANA registry ianaiftype-mib].
5.17. interfaceFlags 6.16. interfaceFlags
elementId: TBD elementId: TBD
name: interfaceFlags name: interfaceFlags
dataType: unsigned16 dataType: unsigned16
dataTypeSemantics: flags dataTypeSemantics: flags
status: current status: current
description: This information element specifies the flags description: This information element specifies the flags
associated with a network interface. Possible associated with a network interface. Possible
values include: values include:
skipping to change at page 42, line 41 skipping to change at page 45, line 19
| 0x2 | broadcast address valid | | 0x2 | broadcast address valid |
| 0x4 | turn on debugging | | 0x4 | turn on debugging |
| 0x8 | is a loopback net | | 0x8 | is a loopback net |
| 0x10 | interface is point-to-point link | | 0x10 | interface is point-to-point link |
| 0x20 | avoid use of trailers | | 0x20 | avoid use of trailers |
| 0x40 | resources allocated | | 0x40 | resources allocated |
| 0x80 | no address resolution protocol | | 0x80 | no address resolution protocol |
| 0x100 | receive all packets | | 0x100 | receive all packets |
+-------+----------------------------------+ +-------+----------------------------------+
5.18. networkInterface 6.17. networkInterface
elementId: TBD elementId: TBD
name: networkInterface name: networkInterface
dataType: basicList dataType: basicList
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: Information about a network interface description: Information about a network interface
installed on an endpoint. The installed on an endpoint. The
following high-level digram following high-level digram
describes the structure of describes the structure of
networkInterface information networkInterface information
element. element.
networkInterface = (basicList, allof, networkInterface = (basicList, allof,
interfaceName, interfaceName,
interfaceIndex, interfaceIndex,
macAddress, macAddress,
ifType, ifType,
flags flags
) )
5.19. softwareIdentifier 6.18. softwareIdentifier
elementId: TBD elementId: TBD
name: softwareIdentifier name: softwareIdentifier
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: A globally unique identifier for a particular description: A globally unique identifier for a particular
software application. software application.
5.20. softwareTitle 6.19. softwareTitle
elementId: TBD elementId: TBD
name: softwareTitle name: softwareTitle
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The title of the software application. description: The title of the software application.
5.21. softwareCreator 6.20. softwareCreator
elementId: TBD elementId: TBD
name: softwareCreator name: softwareCreator
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The software developer (e.g., vendor or author). description: The software developer (e.g., vendor or author).
5.22. simpleVersion 6.21. simpleSoftwareVersion
elementId: TBD elementId: TBD
name: simpleVersion name: simpleSoftwareVersion
dataType: simpleVersionType dataType: simpleVersion
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The version string for a software application that description: The version string for a software application that
follows the simple versioning scheme. follows the simple versioning scheme.
5.23. rpmVersion 6.22. rpmSoftwareVersion
elementId: TBD elementId: TBD
name: rpmVersion name: rpmSoftwareVersion
dataType: rpmVersionType dataType: rpmVersion
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The version string for a software application that description: The version string for a software application that
follows the RPM versioning scheme. follows the RPM versioning scheme.
5.24. ciscoTrainVersion 6.23. ciscoTrainSoftwareVersion
elementId: TBD elementId: TBD
name: ciscoTrainVersion name: ciscoTrainSoftwareVersion
dataType: ciscoTrainVersionType dataType: ciscoTrainVersion
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The version string for a software application that description: The version string for a software application that
follows the Cisco Train Release versioning scheme. follows the Cisco Train Release versioning scheme.
5.25. softwareVersion 6.24. softwareVersion
elementId: TBD elementId: TBD
name: softwareVerison name: softwareVerison
dataType: basicList dataType: basicList
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The version of the software application. Software description: The version of the software application. Software
applications may be versioned using a number of applications may be versioned using a number of
schemas. The following high-level digram describes schemas. The following high-level digram describes
the structure of the softwareVersion information the structure of the softwareVersion information
element. element.
softwareVersion(basicList, exactlyOneOf, softwareVersion(basicList, exactlyOneOf,
simpleVersion, simpleSoftwareVersion,
rpmVersion, rpmSoftwareVersion,
ciscoTrainVersion, ciscoTrainSoftwareVersion,
... ...
) )
5.26. lastUpdated 6.25. lastUpdated
elementId: TBD elementId: TBD
name: lastUpdated name: lastUpdated
dataType: dateTimeSeconds dataType: dateTimeSeconds
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The date and time when the software instance description: The date and time when the software instance
was last updated on the system (e.g., new was last updated on the system (e.g., new
version instlalled or patch applied) version instlalled or patch applied)
5.27. softwareInstance 6.26. softwareInstance
elementId: TBD elementId: TBD
name: softwareInstance name: softwareInstance
dataType: subTemplateMultiList dataType: subTemplateMultiList
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: Information about an instance of software description: Information about an instance of software
installed on an endpoint. The following installed on an endpoint. The following
high-level digram describes the structure of high-level digram describes the structure of
softwareInstance information element. softwareInstance information element.
softwareInstance = (subTemplateMultiList, allof, softwareInstance = (subTemplateMultiList, allof,
softwareIdentifier, softwareIdentifier,
title, title,
creator, creator,
softwareVersion, softwareVersion,
lastUpdated lastUpdated
) )
5.28. globallyUniqueIdentifier 6.27. globallyUniqueIdentifier
elementId: TBD elementId: TBD
name: globallyUniqueIdentifier name: globallyUniqueIdentifier
dataType: unsigned8 dataType: unsigned8
dataTypeSemantics: identifier dataTypeSemantics: identifier
status: current status: current
metadata: true metadata: true
description: TODO. description: TODO.
5.29. dataOrigin 6.28. dataOrigin
elementId: TBD elementId: TBD
name: dataOrigin name: dataOrigin
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
metadata: true metadata: true
description: The origin of the data. TODO make a better description: The origin of the data. TODO make a better
description. description.
5.30. dataSource 6.29. dataSource
elementId: TBD elementId: TBD
name: dataSource name: dataSource
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
metadata: true metadata: true
description: The source of the data. TODO make a better description: The source of the data. TODO make a better
description. description.
5.31. creationTimestamp 6.30. creationTimestamp
elementId: TBD elementId: TBD
name: creationTimestamp name: creationTimestamp
dataType: dateTimeSeconds dataType: dateTimeSeconds
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
metadata: true metadata: true
description: The date and time when the posture description: The date and time when the posture
information was created by a SACM Component. information was created by a SACM Component.
5.32. collectionTimestamp 6.31. collectionTimestamp
elementId: TBD elementId: TBD
name: collectionTimestamp name: collectionTimestamp
dataType: dateTimeSeconds dataType: dateTimeSeconds
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
metadata: true metadata: true
description: The date and time when the posture description: The date and time when the posture
information was collected or observed by a SACM information was collected or observed by a SACM
Component. Component.
5.33. publicationTimestamp 6.32. publicationTimestamp
elementId: TBD elementId: TBD
name: publicationTimestamp name: publicationTimestamp
dataType: dateTimeSeconds dataType: dateTimeSeconds
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
metadata: true metadata: true
description: The date and time when the posture description: The date and time when the posture
information was published. information was published.
5.34. relayTimestamp 6.33. relayTimestamp
elementId: TBD elementId: TBD
name: relayTimestamp name: relayTimestamp
dataType: dateTimeSeconds dataType: dateTimeSeconds
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
metadata: true metadata: true
description: The date and time when the posture description: The date and time when the posture
information was relayed to another SACM Component. information was relayed to another SACM Component.
5.35. storageTimestamp 6.34. storageTimestamp
elementId: TBD elementId: TBD
name: storageTimestamp name: storageTimestamp
dataType: dateTimeSeconds dataType: dateTimeSeconds
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
metadata: true metadata: true
description: The date and time when the posture description: The date and time when the posture
information was stored in a Repository. information was stored in a Repository.
5.36. type 6.35. type
elementId: TBD elementId: TBD
name: type name: type
dataType: unsigned16 dataType: unsigned16
dataTypeSemantics: flags dataTypeSemantics: flags
status: current status: current
metadata: true metadata: true
description: The type of data model use to represent description: The type of data model use to represent
some set of endpoint information. The following table some set of endpoint information. The following
lists the set of data models supported by SACM. table lists the set of data models supported by SACM.
+-------+----------------------------------+ +-------+----------------------------------+
| Value | Description | | Value | Description |
+-------+----------------------------------+ +-------+----------------------------------+
| 0x00 | Data Model 1 | | 0x00 | Data Model 1 |
+-------+----------------------------------+ +-------+----------------------------------+
| 0x01 | Data Model 2 | | 0x01 | Data Model 2 |
+-------+----------------------------------+ +-------+----------------------------------+
| 0x02 | Data Model 3 | | 0x02 | Data Model 3 |
+-------+----------------------------------+ +-------+----------------------------------+
|... | ... | |... | ... |
+-------+----------------------------------+ +-------+----------------------------------+
5.37. protocolIdentifier 6.36. protocolIdentifier
elementId: TBD elementId: TBD
name: protocolIdentifier name: protocolIdentifier
dataType: unsigned8 dataType: unsigned8
dataTypeSemantics: identifier dataTypeSemantics: identifier
status: current status: current
description: The value of the protocol number in the IP packet header. description: The value of the protocol number in the IP packet
The protocol number identifies the IP packet payload type. header. The protocol number identifies the IP packet
Protocol numbers are defined in the IANA Protocol Numbers payload type. Protocol numbers are defined in the
registry. IANA Protocol Numbers registry.
In Internet Protocol version 4 (IPv4), this is carried in the In Internet Protocol version 4 (IPv4), this is
Protocol field. In Internet Protocol version 6 (IPv6), this carried in the Protocol field. In Internet Protocol
is carried in the Next Header field in the last extension version 6 (IPv6), this is carried in the Next Header
header of the packet. field in the last extension header of the packet.
5.38. sourceTransportPort 6.37. 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: 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.
6.38. sourceIPv4PrefixLength
elementId: TBD elementId: TBD
name: sourceIPv4PrefixLength name: sourceIPv4PrefixLength
dataType: unsigned8 dataType: unsigned8
dataTypeSemantics: dataTypeSemantics:
status: current status: current
description: The number of contiguous bits that are relevant in the description: The number of contiguous bits that are relevant in
sourceIPv4Prefix Information Element. the sourceIPv4Prefix Information Element.
5.40. ingressInterface
elementId: TBD 6.39. ingressInterface
name: ingressInterface elementId: TBD
dataType: unsigned32 name: ingressInterface
dataTypeSemantics: identifier dataType: unsigned32
status: current dataTypeSemantics: identifier
description: The index of the IP interface where packets of this Flow status: current
are being received. The value matches the value of managed description: The index of the IP interface where packets of this
object 'ifIndex' as defined in [RFC2863]. Flow are being received. The value matches the
Note that ifIndex values are not assigned statically to an value of managed object 'ifIndex' as defined in
interface and that the interfaces may be renumbered every [RFC2863]. Note that ifIndex values are not assigned
time the device's management system is re-initialized, as statically to an interface and that the interfaces
specified in [RFC2863]. may be renumbered every time the device's management
system is re-initialized, as specified in [RFC2863].
5.41. destinationTransportPort 6.40. destinationTransportPort
elementId: TBD elementId: TBD
name: destinationTransportPort name: destinationTransportPort
dataType: unsigned16 dataType: unsigned16
dataTypeSemantics: identifier dataTypeSemantics: identifier
status: current status: current
description: The destination port identifier in the transport header. description: The destination port identifier in the transport
For the transport protocols UDP, TCP, and SCTP, this is the header. For the transport protocols UDP, TCP, and
destination port number given in the respective header. SCTP, this is the destination port number given in
This field MAY also be used for future transport protocols the respective header. This field MAY also be used
that have 16-bit destination port identifiers. for future transport protocols that have 16-bit
destination port identifiers.
5.42. sourceIPv6PrefixLength 6.41. sourceIPv6PrefixLength
elementId: TBD elementId: TBD
name: sourceIPv6PrefixLength name: sourceIPv6PrefixLength
dataType: unsigned8 dataType: unsigned8
dataTypeSemantics: dataTypeSemantics:
status: current status: current
description: The number of contiguous bits that are relevant in the description: The number of contiguous bits that are relevant in
sourceIPv6Prefix Information Element. the sourceIPv6Prefix Information Element.
5.43. sourceIPv4Prefix 6.42. sourceIPv4Prefix
elementId: TBD elementId: TBD
name: sourceIPv4Prefix name: sourceIPv4Prefix
dataType: ipv4Address dataType: ipv4Address
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: IPv4 source address prefix. description: IPv4 source address prefix.
5.44. destinationIPv4Prefix 6.43. destinationIPv4Prefix
elementId: TBD elementId: TBD
name: destinationIPv4Prefix name: destinationIPv4Prefix
dataType: ipv4Address dataType: ipv4Address
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: IPv4 destination address prefix. description: IPv4 destination address prefix.
5.45. sourceMacAddress 6.44. sourceMacAddress
elementId: TBD elementId: TBD
name: sourceMacAddress name: sourceMacAddress
dataType: macAddress dataType: macAddress
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The IEEE 802 source MAC address field. description: The IEEE 802 source MAC address field.
5.46. ipVersion 6.45. ipVersion
elementId: TBD elementId: TBD
name: ipVersion name: ipVersion
dataType: unsigned8 dataType: unsigned8
dataTypeSemantics: identifier dataTypeSemantics: identifier
status: current status: current
description: The IP version field in the IP packet header. description: The IP version field in the IP packet header.
5.47. interfaceName 6.46. interfaceDescription
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 elementId: TBD
name: interfaceDescription name: interfaceDescription
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The description of an interface, eg "FastEthernet 1/0" or "ISP description: The description of an interface, eg "FastEthernet
connection". 1/0" or "ISP
connection".
5.49. applicationDescription 6.47. applicationDescription
elementId: TBD elementId: TBD
name: applicationDescription name: applicationDescription
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: Specifies the description of an application. description: Specifies the description of an application.
5.50. applicationId 6.48. applicationId
elementId: TBD elementId: TBD
name: applicationId name: applicationId
dataType: octetArray dataType: octetArray
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: Specifies an Application ID per [RFC6759]. description: Specifies an Application ID per [RFC6759].
5.51. applicationName 6.49. applicationName
elementId: TBD elementId: TBD
name: applicationName name: applicationName
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: Specifies the name of an application. description: Specifies the name of an application.
5.52. exporterIPv4Address 6.50. 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: 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.
elementId: TBD 6.51. exporterIPv6Address
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: 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.
6.52. portId
elementId: TBD elementId: TBD
name: portId name: portId
dataType: unsigned32 dataType: unsigned32
dataTypeSemantics: identifier dataTypeSemantics: identifier
status: current status: current
description: An identifier of a line port that is unique per IPFIX description: An identifier of a line port that is unique per
Device hosting an Observation Point. Typically, this IPFIX Device hosting an Observation Point.
Information Element is used for limiting the scope Typically, this Information Element is used for
of other Information Elements. 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 6.53. templateId
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: 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.
elementId: TBD Template IDs 0-255 are reserved for Template Sets,
name: informationElementIndex Options Template Sets, and other reserved Sets yet
dataType: unsigned16 to be created. Template IDs of Data Sets are
dataTypeSemantics: identifier numbered from 256 to 65535.
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 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.
elementId: TBD 6.54. collectorIPv4Address
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: collectorIPv4Address
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: An IPv4 address to which the Exporting Process sends
Flow information.
elementId: TBD 6.55. collectorIPv6Address
name: subTemplateList elementId: TBD
dataType: subTemplateList name: collectorIPv6Address
dataTypeSemantics: list dataType: ipv6Address
status: current dataTypeSemantics: default
description: Specifies a generic Information Element with a subTemplateList status: current
abstract data type. description: An IPv6 address to which the Exporting Process sends
Flow information.
5.61. subTemplateMultiList 6.56. informationElementIndex
elementId: TBD elementId: TBD
name: subTemplateMultiList name: informationElementIndex
dataType: subTemplateMultiList dataType: unsigned16
dataTypeSemantics: list dataTypeSemantics: identifier
status: current status: current
description: Specifies a generic Information Element with a description: A zero-based index of an Information Element
subTemplateMultiList abstract data type. referenced by informationElementId within a Template
referenced by templateId; used to disambiguate
5.62. informationElementId scope for templates containing multiple identical
Information Elements.
elementId: TBD 6.57. informationElementId
name: informationElementId
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: This Information Element contains the ID of another Information
Element.
5.63. informationElementDataType elementId: TBD
elementId: TBD name: informationElementId
name: informationElementDataType dataType: unsigned16
dataType: unsigned8 dataTypeSemantics: identifier
dataTypeSemantics: status: current
status: current description: This Information Element contains the ID of another
description: A description of the abstract data type of an IPFIX Information Element.
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 6.58. informationElementDataType
Data Type subregistry. This subregistry is intended to assign elementId: TBD
numbers for type names, not to provide a mechanism for adding data name: informationElementDataType
types to the IPFIX Protocol, and as such requires a Standards dataType: unsigned8
Action [RFC5226] to modify. 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.
5.64. informationElementDescription 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.
elementId: TBD 6.59. informationElementDescription
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: 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.
elementId: TBD 6.60. informationElementName
name: informationElementName elementId: TBD
dataType: string name: informationElementName
dataTypeSemantics: default dataType: string
status: current dataTypeSemantics: default
description: A UTF-8 [RFC3629] encoded Unicode string containing status: current
the name of an Information Element, intended as a simple description: A UTF-8 [RFC3629] encoded Unicode string containing
identifier. See the Security Considerations section for notes on the name of an Information Element, intended as a
string handling for Information Element type records. simple identifier. See the Security Considerations
section for notes on string handling for Information
Element type records.
5.66. informationElementRangeBegin 6.61. informationElementRangeBegin
elementId: TBD elementId: TBD
name: informationElementRangeBegin name: informationElementRangeBegin
dataType: unsigned64 dataType: unsigned64
dataTypeSemantics: quantity dataTypeSemantics: quantity
status: current status: current
description: Contains the inclusive low end of the range of description: Contains the inclusive low end of the range of
acceptable values for an Information Element. acceptable values for an Information Element.
5.67. informationElementRangeEnd 6.62. informationElementRangeEnd
elementId: TBD elementId: TBD
name: informationElementRangeEnd name: informationElementRangeEnd
dataType: unsigned64 dataType: unsigned64
dataTypeSemantics: quantity dataTypeSemantics: quantity
status: current status: current
description: Contains the inclusive high end of the range of description: Contains the inclusive high end of the range of
acceptable values for an Information Element. acceptable values for an Information Element.
5.68. informationElementSemantics 6.63. informationElementSemantics
elementId: TBD
elementId: TBD name: informationElementSemantics
name: informationElementSemantics dataType: unsigned8
dataType: unsigned8 dataTypeSemantics:
dataTypeSemantics: status: current
status: current description: A description of the semantics of an IPFIX
description: A description of the semantics of an IPFIX Information Element. These are taken from the data
Information Element. These are taken from the data type type semantics defined in section 3.2 of the IPFIX
semantics defined in section 3.2 of the IPFIX Information Information Model [RFC5102]; see that section for
Model [RFC5102]; see that section for more information more information on the types defined in the
on the types defined in the informationElementSemantics informationElementSemantics sub-registry. This
sub-registry. This field may take the values in Table ; field may take the values in Table ; the special
the special value 0x00 (default) is used to note that value 0x00 (default) is used to note that no
no semantics apply to the field; it cannot be manipulated semantics apply to the field; it cannot be
by a Collecting Process or File Reader that does not manipulated by a Collecting Process or File Reader
understand it a priori. that does not understand it a priori.
These semantics are registered in the IANA IPFIX These semantics are registered in the IANA IPFIX
Information Element Semantics subregistry. This subregistry Information Element Semantics subregistry. This
is intended to assign numbers for semantics names, not subregistry is intended to assign numbers for
to provide a mechanism for adding semantics to the semantics names, not to provide a mechanism for
IPFIX Protocol, and as such requires a Standards adding semantics to the IPFIX Protocol, and as such
Action [RFC5226] to modify. requires a Standards Action [RFC5226] to modify.
5.69. informationElementUnits 6.64. informationElementUnits
elementId: TBD elementId: TBD
name: informationElementUnits name: informationElementUnits
dataType: unsigned16 dataType: unsigned16
dataTypeSemantics: dataTypeSemantics:
status: current status: current
description: A description of the units of an IPFIX Information description: A description of the units of an IPFIX Information
Element. These correspond to the units implicitly defined in the Element. These correspond to the units implicitly
Information Element definitions in section 5 of the IPFIX defined in the Information Element definitions in
Information Model [RFC5102]; see that section for more information section 5 of the IPFIX Information Model [RFC5102];
on the types described in the informationElementsUnits sub-registry. see that section for more information on the types
This field may take the values in Table 3 below; the special value described in the informationElementsUnits
0x00 (none) is used to note that the field is unitless. 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 These types are registered in the IANA IPFIX
Units subregistry; new types may be added on a First Come First Information Element Units subregistry; new types
Served [RFC5226] basis. may be added on a First Come First Served [RFC5226]
basis.
5.70. userName 6.65. userName
elementId: TBD elementId: TBD
name: userName name: userName
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: User name associated with the flow. description: User name associated with the flow.
5.71. applicationCategoryName 6.66. 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: applicationCategoryName
dataType: string
dataTypeSemantics: default
status: current
description: An attribute that provides a first level
categorization for each Application ID.
elementId: TBD 6.67. mibObjectValueInteger
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: 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.
elementId: TBD 6.68. mibObjectValueOctetString
name: mibObjectValueIPAddress elementId: TBD
dataType: ipv4Address name: mibObjectValueOctetString
dataTypeSemantics: default dataType: octetArray
status: current dataTypeSemantics: default
description: An IPFIX Information Element which denotes that the status: current
IPv4 Address of a MIB object will be exported. The MIB Object description: An IPFIX Information Element which denotes that an
Identifier ("mibObjectIdentifier") for this field MUST be exported Octet String or Opaque value of a MIB object will
in a MIB Field Option or via another means. This Information be exported. The MIB Object Identifier
Element is used for MIB objects with the Base Syntax of IPaddress. ("mibObjectIdentifier") for this field MUST be
The value is encoded as per the standard IPFIX Abstract Data Type exported in a MIB Field Option or via another means.
of ipv4Address. 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.77. mibObjectValueCounter 6.69. mibObjectValueOID
elementId: TBD elementId: TBD
name: mibObjectValueCounter name: mibObjectValueOID
dataType: unsigned64 dataType: octetArray
dataTypeSemantics: snmpCounter dataTypeSemantics: default
status: current status: current
description: An IPFIX Information Element which denotes that the description: An IPFIX Information Element which denotes that an
counter value of a MIB object will be exported. The MIB Object Object Identifier or OID value of a MIB object will
Identifier ("mibObjectIdentifier") for this field MUST be exported be exported. The MIB Object Identifier
in a MIB Field Option or via another means. This Information ("mibObjectIdentifier") for this field MUST be
Element is used for MIB objects with the Base Syntax of Counter32 exported in a MIB Field Option or via another means.
or Counter64 with IPFIX Reduced Size Encoding used as required. This Information Element is used for MIB objects
The value is encoded as per the standard IPFIX Abstract Data Type with the Base Syntax of OBJECT IDENTIFIER. Note -
of unsigned64. 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.78. mibObjectValueGauge 6.70. 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.
elementId: TBD 6.71. mibObjectValueIPAddress
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: 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.
elementId: TBD 6.72. mibObjectValueCounter
name: mibObjectValueTimeTicks elementId: TBD
dataType: unsigned32 name: mibObjectValueCounter
dataTypeSemantics: default dataType: unsigned64
status: current dataTypeSemantics: snmpCounter
description: An IPFIX Information Element which denotes that the status: current
TimeTicks value of a MIB object will be exported. The MIB Object description: An IPFIX Information Element which denotes that the
Identifier ("mibObjectIdentifier") for this field MUST be exported counter value of a MIB object will be exported.
in a MIB Field Option or via another means. This Information The MIB Object Identifier ("mibObjectIdentifier")
Element is used for MIB objects with the Base Syntax of TimeTicks. for this field MUST be exported in a MIB Field
The value is encoded as per the standard IPFIX Abstract Data Type Option or via another means. This Information
of unsigned32. 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.80. mibObjectValueUnsigned 6.73. mibObjectValueGauge
elementId: TBD elementId: TBD
name: mibObjectValueUnsigned name: mibObjectValueGauge
dataType: unsigned64 dataType: unsigned32
dataTypeSemantics: identifier dataTypeSemantics: snmpGauge
status: current status: current
description: An IPFIX Information Element which denotes that an description: An IPFIX Information Element which denotes that the
unsigned integer value of a MIB object will be exported. The MIB Gauge value of a MIB object will be exported. The
Object Identifier ("mibObjectIdentifier") for this field MUST be MIB Object Identifier ("mibObjectIdentifier") for
exported in a MIB Field Option or via another means. This this field MUST be exported in a MIB Field Option
Information Element is used for MIB objects with the Base Syntax or via another means. This Information Element is
of unsigned64 with IPFIX Reduced Size Encoding used as required. used for MIB objects with the Base Syntax of Gauge32.
The value is encoded as per the standard IPFIX Abstract Data Type The value is encoded as per the standard IPFIX
of unsigned64. 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.81. mibObjectValueTable 6.74. 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.
elementId: TBD 6.75. mibObjectValueUnsigned
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: 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.
elementId: TBD 6.76. mibObjectValueTable
name: mibObjectValueRow elementId: TBD
dataType: subTemplateList name: mibObjectValueTable
dataTypeSemantics: list dataType: subTemplateList
status: current dataTypeSemantics: list
description: An IPFIX Information Element which denotes that a status: current
single row of a conceptual table will be exported. The MIB Object description: An IPFIX Information Element which denotes that a
Identifier ("mibObjectIdentifier") for this field MUST be exported complete or partial conceptual table will be
in a MIB Field Option or via another means. This Information exported. The MIB Object Identifier
Element is used for MIB objects with a SYNTAX of SEQUENCE. This ("mibObjectIdentifier") for this field MUST be
is encoded as a subTemplateList of mibObjectValue Information exported in a MIB Field Option or via another means.
Elements. The subTemplateList exported MUST contain exactly one This Information Element is used for MIB objects
row (i.e., one instance of the subtemplate). The template with a SYNTAX of SEQUENCE. This is encoded as a
specified in the subTemplateList MUST be an Options Template and subTemplateList of mibObjectValue Information
MUST include all the Objects listed in the INDEX clause as Scope Elements. The template specified in the
Fields. subTemplateList MUST be an Options Template and
MUST include all the Objects listed in the INDEX
clause as Scope Fields.
5.83. mibObjectIdentifier 6.77. mibObjectValueRow
elementId: TBD elementId: TBD
name: mibObjectIdentifier name: mibObjectValueRow
dataType: octetArray dataType: subTemplateList
dataTypeSemantics: default dataTypeSemantics: list
status: current status: current
description: An IPFIX Information Element which denotes that a MIB description: An IPFIX Information Element which denotes that a
Object Identifier (MIB OID) is exported in the (Options) Template single row of a conceptual table will be exported.
Record. The mibObjectIdentifier Information Element contains the The MIB Object Identifier ("mibObjectIdentifier")
OID assigned to the MIB Object Type Definition encoded as ASN.1/ for this field MUST be exported in a MIB Field
BER [BER]. 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.84. mibSubIdentifier 6.78. 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].
elementId: TBD 6.79. mibSubIdentifier
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: mibSubIdentifier
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: A non-negative sub-identifier of an Object
Identifier (OID).
elementId: TBD 6.80. mibIndexIndicator
name: mibIndexIndicator elementId: TBD
dataType: unsigned64 name: mibIndexIndicator
dataTypeSemantics: flags dataType: unsigned64
status: current dataTypeSemantics: flags
description: This set of bit fields is used for marking the status: current
Information Elements of a Data Record that serve as INDEX MIB description: This set of bit fields is used for marking the
objects for an indexed Columnar MIB object. Each bit represents Information Elements of a Data Record that serve as
an Information Element in the Data Record with the n-th bit INDEX MIB objects for an indexed Columnar MIB
representing the n-th Information Element. A bit set to value 1 object. Each bit represents an Information Element
indicates that the corresponding Information Element is an index in the Data Record with the n-th bit representing
of the Columnar Object represented by the mibFieldValue. A bit the n-th Information Element. A bit set to value 1
set to value 0 indicates that this is not the case. 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 If the Data Record contains more than 64
corresponding Template SHOULD be designed such that all INDEX Information Elements, the corresponding Template
Fields are among the first 64 Information Elements, because the SHOULD be designed such that all INDEX
mibIndexIndicator only contains 64 bits. If the Data Record Fields are among the first 64 Information Elements,
contains less than 64 Information Elements, then the extra bits in because the mibIndexIndicator only contains 64 bits.
the mibIndexIndicator for which no corresponding Information If the Data Record contains less than 64
Element exists MUST have the value 0, and must be disregarded by Information Elements, then the extra bits in the
the Collector. This Information Element may be exported with mibIndexIndicator for which no corresponding
IPFIX Reduced Size Encoding. 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 6.81. mibCaptureTimeSemantics
elementId: TBD elementId: TBD
name: mibCaptureTimeSemantics name: mibCaptureTimeSemantics
dataType: unsigned8 dataType: unsigned8
dataTypeSemantics: identifier dataTypeSemantics: identifier
status: current status: current
description: Indicates when in the lifetime of the flow the MIB description: Indicates when in the lifetime of the flow the MIB
value was retrieved from the MIB for a mibObjectIdentifier. This value was retrieved from the MIB for a
is used to indicate if the value exported was collected from the mibObjectIdentifier. This is used to indicate if
MIB closer to flow creation or flow export time and will refer to the value exported was collected from the MIB
the Timestamp fields included in the same record. This field closer to flow creation or flow export time and
SHOULD be used when exporting a mibObjectValue that specifies will refer to the Timestamp fields included in the
counters or statistics. 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 If the MIB value was sampled by SNMP prior to the
Process or Exporting Process retrieving the value (i.e., the data IPFIX Metering Process or Exporting Process
is already stale) and it's important to know the exact sampling retrieving the value (i.e., the data is already
time, then an additional observationTime* element should be paired stale) and it's important to know the exact sampling
with the OID using structured data. Similarly, if different time, then an additional observationTime* element
mibCaptureTimeSemantics apply to different mibObject elements should be paired with the OID using structured data.
within the Data Record, then individual mibCaptureTimeSemantics Similarly, if different mibCaptureTimeSemantics
should be paired with each OID using structured data. apply to different mibObject elements within the
Data Record, then individual mibCaptureTimeSemantics
should be paired with each OID using structured data.
Values: Values:
0. undefined 0. undefined
1. begin - The value for the MIB object is captured from the 1. begin - The value for the MIB object is captured
MIB when the Flow is first observed from the MIB when the Flow is first observed
2. end - The value for the MIB object is captured from the MIB 2. end - The value for the MIB object is captured
when the Flow ends from the MIB when the Flow ends
3. export - The value for the MIB object is captured from the 3. export - The value for the MIB object is
MIB at export time captured from the MIB at export time
4. average - The value for the MIB object is an average of 4. average - The value for the MIB object is an
multiple captures from the MIB over the observed life of the average of multiple captures from the MIB over the
Flow observed life of the Flow
5.87. mibContextEngineID 6.82. mibContextEngineID
elementId: TBD elementId: TBD
name: mibContextEngineID name: mibContextEngineID
dataType: octetArray dataType: octetArray
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: A mibContextEngineID that specifies the SNMP engine description: A mibContextEngineID that specifies the SNMP engine
ID for a MIB field being exported over IPFIX. Definition as per ID for a MIB field being exported over IPFIX.
[RFC3411] section 3.3. Definition as per [RFC3411] section 3.3.
5.88. mibContextName 6.83. mibContextName
elementId: TBD elementId: TBD
name: mibContextName name: mibContextName
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: This Information Element denotes that a MIB Context description: This Information Element denotes that a MIB Context
Name is specified for a MIB field being exported over IPFIX. Name is specified for a MIB field being exported
Reference [RFC3411] section 3.3. over IPFIX. Reference [RFC3411] section 3.3.
5.89. mibObjectName 6.84. mibObjectName
elementId: TBD elementId: TBD
name: mibObjectName name: mibObjectName
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The name (called a descriptor in [RFC2578] description: The name (called a descriptor in [RFC2578]
of an object type definition. of an object type definition.
5.90. mibObjectDescription 6.85. mibObjectDescription
elementId: TBD elementId: TBD
name: mibObjectDescription name: mibObjectDescription
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The value of the DESCRIPTION clause of an MIB object description: The value of the DESCRIPTION clause of an MIB object
type definition. type definition.
5.91. mibObjectSyntax 6.86. mibObjectSyntax
elementId: TBD elementId: TBD
name: mibObjectSyntax name: mibObjectSyntax
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The value of the SYNTAX clause of an MIB object type description: The value of the SYNTAX clause of an MIB object type
definition, which may include a Textual Convention or Subtyping. definition, which may include a Textual Convention
See [RFC2578]. or Subtyping. See [RFC2578].
5.92. mibModuleName 6.87. mibModuleName
elementId: TBD elementId: TBD
name: mibModuleName name: mibModuleName
dataType: string dataType: string
dataTypeSemantics: default dataTypeSemantics: default
status: current status: current
description: The textual name of the MIB module that defines a MIB description: The textual name of the MIB module that defines a MIB
Object. Object.
6. SACM Usage Scenario Example 7. 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 4 illustrates those elements along with their major Figure 10 illustrates those elements along with their major
communication paths. communication paths.
6.1. Graph Model for Detection of Posture Deviation 7.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.
6.1.1. Components 7.1.1. Components
The proposed SACM Information Model contains three components, as The proposed SACM Information Model contains three components, as
defined in the SACM Architecture [I-D.ietf-sacm-architecture]: defined in the SACM Architecture [I-D.ietf-sacm-architecture]:
Posture Attribute Information Provider, Posture Attribute Information Posture Attribute Information Provider, Posture Attribute Information
Consumer, and Control Plane. Consumer, and Control Plane.
In this example, the components are instantiated as follows: In this example, the components are instantiated as follows:
o The Posture Attribute Information Provider is an endpoint security o The Posture Attribute Information Provider is an endpoint security
service which monitors the compliance state of the endpoint and service which monitors the compliance state of the endpoint and
skipping to change at page 66, line 15 skipping to change at page 71, line 15
o The Posture Attribute Information Consumer is an analytics engine o The Posture Attribute Information Consumer is an analytics engine
which absorbs information from around the network and generates a which absorbs information from around the network and generates a
"heat map" of which areas in the network are seeing unusually high "heat map" of which areas in the network are seeing unusually high
rates of posture deviations. rates of posture deviations.
o The Control Plane is a security automation broker which receives o The Control Plane is a security automation broker which receives
subscription requests from the analytics engine and authorizes subscription requests from the analytics engine and authorizes
access to appropriate information from the endpoint security access to appropriate information from the endpoint security
service. service.
6.1.2. Identifiers 7.1.2. Identifiers
To represent the elements listed above, the set of identifiers might To represent the elements listed above, the set of identifiers might
include (but is not limited to): include (but is not limited to):
o Identity - a device itself, or a user operating a device, o Identity - a device itself, or a user operating a device,
categorized by type of identity (e.g. username or X.509 categorized by type of identity (e.g. username or X.509
certificate [RFC5280]) certificate [RFC5280])
o Software asset o Software asset
skipping to change at page 66, line 40 skipping to change at page 71, line 40
[RFC5201], etc.) [RFC5201], etc.)
o Task - categorized by type of task (e.g. internal collector, o Task - categorized by type of task (e.g. internal collector,
external collector, evaluator, or reporting task) external collector, evaluator, or reporting task)
o Result - categorized by type of result (e.g. evaluation result or o Result - categorized by type of result (e.g. evaluation result or
report) report)
o Guidance o Guidance
6.1.3. Metadata 7.1.3. Metadata
To characterize the elements listed above, the set of metadata types To characterize the elements listed above, the set of metadata types
might include (but is not limited to): might include (but is not limited to):
o Authorization metadata attached to an identity identifier, or to a o Authorization metadata attached to an identity identifier, or to a
link between a network session identifier and an identity link between a network session identifier and an identity
identifier, or to a link between a network session identifier and identifier, or to a link between a network session identifier and
an address identifier. an address identifier.
o Location metadata attached to a link between a network session o Location metadata attached to a link between a network session
skipping to change at page 67, line 21 skipping to change at page 72, line 21
attached to the identity identifier of the endpoint, to notify attached to the identity identifier of the endpoint, to notify
consumers of the change in endpoint state. consumers of the change in endpoint state.
o Posture attribute metadata attached to an identity identifier of o Posture attribute metadata attached to an identity identifier of
an endpoint. For example, when required security software is not an endpoint. For example, when required security software is not
running, an internal collector associated with an endpoint running, an internal collector associated with an endpoint
security service might publish posture attribute metadata attached security service might publish posture attribute metadata attached
to the identity identifier of the endpoint, to notify consumers of to the identity identifier of the endpoint, to notify consumers of
the current state of the endpoint. the current state of the endpoint.
6.1.4. Relationships between Identifiers and Metadata 7.1.4. Relationships between Identifiers and Metadata
Interaction between multiple sets of identifiers and metadata lead to Interaction between multiple sets of identifiers and metadata lead to
some fairly common patterns, or "constellations", of metadata. For some fairly common patterns, or "constellations", of metadata. For
example, an authenticated-session metadata constellation might example, an authenticated-session metadata constellation might
include a central network session with authorizations and location include a central network session with authorizations and location
attached, and links to a user identity, an endpoint identity, a MAC attached, and links to a user identity, an endpoint identity, a MAC
address, an IP address, and the identity of the policy server that address, an IP address, and the identity of the policy server that
authorized the session, for the duration of the network session. authorized the session, for the duration of the network session.
These constellations may be independent of each other, or one These constellations may be independent of each other, or one
skipping to change at page 67, line 43 skipping to change at page 72, line 43
authenticated-session metadata constellation may be created when a authenticated-session metadata constellation may be created when a
user connects an endpoint to the network; separately, an endpoint- user connects an endpoint to the network; separately, an endpoint-
posture metadata constellation may be created when an endpoint posture metadata constellation may be created when an endpoint
security system and other collectors gather and publish posture security system and other collectors gather and publish posture
information related to an endpoint. These two constellations are not information related to an endpoint. These two constellations are not
necessarily connected to each other, but may be joined if the necessarily connected to each other, but may be joined if the
component publishing the authenticated-session metadata constellation component publishing the authenticated-session metadata constellation
is able to link the network session identifier to the identity is able to link the network session identifier to the identity
identifier of the endpoint. identifier of the endpoint.
6.2. Workflow 7.2. Workflow
The workflow for exchange of information supporting detection of The workflow for exchange of information supporting detection of
posture deviation, using a standard publish/subscribe/query transport posture deviation, using a standard publish/subscribe/query transport
model such as available with IF-MAP [TNC-IF-MAP-SOAP-Binding] or model such as available with IF-MAP [TNC-IF-MAP-SOAP-Binding] or
XMPP-Grid [I-D.salowey-sacm-xmpp-grid], is as follows: XMPP-Grid [I-D.salowey-sacm-xmpp-grid], is as follows:
1. The analytics engine (Posture Assessment Information Consumer) 1. The analytics engine (Posture Assessment Information Consumer)
establishes connectivity and authorization with the transport establishes connectivity and authorization with the transport
fabric, and subscribes to updates on posture deviations. fabric, and subscribes to updates on posture deviations.
skipping to change at page 68, line 23 skipping to change at page 73, line 23
posture deviation, and publishes information on the posture posture deviation, and publishes information on the posture
deviation. deviation.
5. The transport fabric notifies the analytics engine, based on its 5. The transport fabric notifies the analytics engine, based on its
subscription of the new posture deviation information. subscription of the new posture deviation information.
Other components, such as access control policy servers or Other components, such as access control policy servers or
remediation systems, may also consume the posture deviation remediation systems, may also consume the posture deviation
information provided by the endpoint security service. information provided by the endpoint security service.
7. Acknowledgements 8. Acknowledgements
Many of the specifications in this document have been developed in a Many of the specifications in this document have been developed in a
public-private partnership with vendors and end-users. The hard work public-private partnership with vendors and end-users. The hard work
of the SCAP community is appreciated in advancing these efforts to of the SCAP community is appreciated in advancing these efforts to
their current level of adoption. their current level of adoption.
Over the course of developing the initial draft, Brant Cheikes, Matt Over the course of developing the initial draft, Brant Cheikes, Matt
Hansbury, Daniel Haynes, Scott Pope, Charles Schmidt, and Steve Hansbury, Daniel Haynes, Scott Pope, Charles Schmidt, and Steve
Venema have contributed text to many sections of this document. Venema have contributed text to many sections of this document.
7.1. Contributors 8.1. Contributors
The RFC guidelines no longer allow RFCs to be published with a large The RFC guidelines no longer allow RFCs to be published with a large
number of authors. Some additional authors contributed to specific number of authors. Some additional authors contributed to specific
sections of this document; their names are listed in the individual sections of this document; their names are listed in the individual
section headings as well as alphabetically listed with their section headings as well as alphabetically listed with their
affiliations below. affiliations below.
+---------------+----------------+---------------------------------+ +---------------+----------------+---------------------------------+
| Name | Affiliation | Contact | | Name | Affiliation | Contact |
+---------------+----------------+---------------------------------+ +---------------+----------------+---------------------------------+
| Henk Birkholz | Fraunhofer SIT | henk.birkholz@sit.fraunhofer.de | | Henk Birkholz | Fraunhofer SIT | henk.birkholz@sit.fraunhofer.de |
+---------------+----------------+---------------------------------+ +---------------+----------------+---------------------------------+
8. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Operational Considerations 10. Operational Considerations
TODO: Need to include various operational considerations here. TODO: Need to include various operational considerations here.
Proposed sections include timestamp accuracy and which attributes Proposed sections include timestamp accuracy and which attributes
attributes designate an endpoint. attributes designate an endpoint.
10. Privacy Considerations 11. Privacy Considerations
TODO: Need to include various privacy considerations here. TODO: Need to include various privacy considerations here.
11. Security Considerations 12. Security Considerations
Posture Assessments need to be performed in a safe and secure manner. Posture Assessments need to be performed in a safe and secure manner.
In that regard, there are multiple aspects of security that apply to In that regard, there are multiple aspects of security that apply to
the communications between components as well as the capabilities the communications between components as well as the capabilities
themselves. Due to time constraints, this information model only themselves. Due to time constraints, this information model only
contains an initial listing of items that need to be considered with contains an initial listing of items that need to be considered with
respect to security. This list is not exhaustive, and will need to respect to security. This list is not exhaustive, and will need to
be augmented as the model continues to be developed/refined. be augmented as the model continues to be developed/refined.
Initial list of security considerations include: Initial list of security considerations include:
skipping to change at page 70, line 5 skipping to change at page 75, line 5
Restricted Access: Access to the information collected, evaluated, Restricted Access: Access to the information collected, evaluated,
reported, and stored should only be viewable/consumable to reported, and stored should only be viewable/consumable to
authenticated and authorized entities. authenticated and authorized entities.
The TNC IF-MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] and TNC IF- The TNC IF-MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] and TNC IF-
MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA] MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA]
document security considerations for sharing information via security document security considerations for sharing information via security
automation. Most, and possibly all, of these considerations also automation. Most, and possibly all, of these considerations also
apply to information shared via this proposed information model. apply to information shared via this proposed information model.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 70, line 33 skipping to change at page 75, line 33
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, [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information Export "Export of Structured Data in IP Flow Information Export
(IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011,
<http://www.rfc-editor.org/info/rfc6313>. <http://www.rfc-editor.org/info/rfc6313>.
12.2. Informative References 13.2. Informative References
[CCE] The National Institute of Standards and Technology, [CCE] The National Institute of Standards and Technology,
"Common Configuration Enumeration", 2014, "Common Configuration Enumeration", 2014,
<http://nvd.nist.gov/CCE/>. <http://nvd.nist.gov/CCE/>.
[CCI] United States Department of Defense Defense Information [CCI] United States Department of Defense Defense Information
Systems Agency, "Control Correlation Identifier", 2014, Systems Agency, "Control Correlation Identifier", 2014,
<http://iase.disa.mil/cci/>. <http://iase.disa.mil/cci/>.
[CPE-WEBSITE] [CPE-WEBSITE]
skipping to change at page 73, line 26 skipping to change at page 78, line 26
[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)", for the Simple Network Management Protocol (SNMP)",
STD 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
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, (RADIUS) Usage Guidelines", RFC 3580,
DOI 10.17487/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
Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
<http://www.rfc-editor.org/info/rfc3954>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, 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", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 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, Henderson, "Host Identity Protocol", RFC 5201,
DOI 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 10.17487/RFC5424, March 2009,
<http://www.rfc-editor.org/info/rfc5424>.
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
(PA) Protocol Compatible with Trusted Network Connect (PA) Protocol Compatible with Trusted Network Connect
(TNC)", RFC 5792, 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,
March 2010, <http://www.rfc-editor.org/info/rfc5793>. March 2010, <http://www.rfc-editor.org/info/rfc5793>.
skipping to change at page 77, line 15 skipping to change at page 82, line 7
endpoint knows the identity it used to gain network access. The PDP endpoint knows the identity it used to gain network access. The PDP
also knows that. But they probably do not know the account. also knows that. But they probably do not know the account.
Added relationship between Network Interface and Identity. The Added relationship between Network Interface and Identity. The
endpoint and the PDP will typically know the identity. endpoint and the PDP will typically know the identity.
Made identity-to-account a many-to-one relationship. Made identity-to-account a many-to-one relationship.
A.2. Changes in Revision 02 A.2. Changes in Revision 02
Added Section 5.1, Identifying Attributes. Added Section 6.1, Identifying Attributes.
Split the figure into Figure 4 and Figure 5. Split the figure into Figure 10 and Figure 11.
Added Figure 6, proposing a triple-store model. Added Figure 12, 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 4 section. Provided notes for the type of
information we need to add in this section. information we need to add in this section.
Added the Section 4 section. Moved sections on Endpoint, Hardware Added the Section 5 section. Moved sections on Endpoint, Hardware
Component, Software Component, Hardware Instance, and Software Component, Software Component, Hardware Instance, and Software
Instance there. Provided notes for the type of information we need Instance there. Provided notes for the type of information we need
to add in this section. to add in this section.
Removed the Provenance of Information Section. SACM is not going to Removed the Provenance of Information Section. SACM is not going to
solve provenance rather give organizations enough information to solve provenance rather give organizations enough information to
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 A.4. Changes in Revision 04
Integrated the IPFIX [RFC7012] syntax into Section 3. Integrated the IPFIX [RFC7012] syntax into Section 4.
Converted many of the existing SACM Information Elements to the IPFIX Converted many of the existing SACM Information Elements to the IPFIX
syntax. syntax.
Included existing IPFIX Information Elements and datatypes that could Included existing IPFIX Information Elements and datatypes that could
likely be reused for SACM in Section 5 and Section 3 respectively. likely be reused for SACM in Section 6 and Section 4 respectively.
Removed the sections related to reports as described in Removed the sections related to reports as described in
https://github.com/sacmwg/draft-ietf-sacm-information-model/ https://github.com/sacmwg/draft-ietf-sacm-information-model/
issues/30. issues/30.
Cleaned up other text throughout the document. Cleaned up other text throughout the document.
A.5. Changes in Revision 05
Merged proposed changes from the I-D IM into the WG IM
(https://github.com/sacmwg/draft-ietf-sacm-information-model/
issues/41).
Fixed some formatting warnings.
Removed a duplicate IE and added a few IE datatypes that were
missing.
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 84, line 20 skipping to change at page 89, line 11
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 7, Consumers In the most trivial example, illustrated in Figure 13, 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 7: Example Producer/Consumer Interactions Figure 13: Example Producer/Consumer Interactions
As illustrated in Figure 8, writing and querying from data As illustrated in Figure 14, 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 8: Producer/Consumer Repository Interaction Figure 14: 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 86, line 48 skipping to change at page 91, line 48
+-----v--------+ +----+------+ +-----v--------+ +----+------+
|Evaluation | |Reporting | |Evaluation | |Reporting |
|Results | |Guidance | |Results | |Guidance |
|Consumer | |Repository | |Consumer | |Repository |
+---+----------+ +-----------+ +-------------+ +---+----------+ +-----------+ +-------------+
| | Results | | | Results |
+-----------------------------> Repository | +-----------------------------> Repository |
| | | |
+-------------+ +-------------+
Figure 9: Producer/Consumer Complex Example Figure 15: Producer/Consumer Complex Example
This illustrative example in Figure 9 provides a set of information This illustrative example in Figure 15 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 92, line 14 skipping to change at page 97, 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 10), providing for extension at any asset types/classes (see Figure 16), 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 92, line 37 skipping to change at page 97, line 37
| +-database | +-database
| +-network | +-network
| +-service | +-service
| +-software | +-software
| +-system | +-system
| +-website | +-website
+-data +-data
+-organization +-organization
+-person +-person
Figure 10: Asset Identification Class Hierarchy Figure 16: 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 100, line 31 skipping to change at page 105, 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 11: The OVAL Data Model Figure 17: The OVAL Data Model
The OVAL data model [OVAL-LANGUAGE], visualized in Figure 11, is The OVAL data model [OVAL-LANGUAGE], visualized in Figure 17, 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 119, line 12 skipping to change at page 124, 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 12: Knowledge represented by a graph Figure 18: 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
 End of changes. 340 change blocks. 
1306 lines changed or deleted 1433 lines changed or added

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