draft-ietf-sacm-information-model-00.txt   draft-ietf-sacm-information-model-01.txt 
SACM D. Waltermire, Ed. SACM D. Waltermire, Ed.
Internet-Draft NIST Internet-Draft NIST
Intended status: Informational K. Watson Intended status: Informational K. Watson
Expires: April 27, 2015 DHS Expires: August 24, 2015 DHS
C. Kahn C. Kahn
L. Lorenzin L. Lorenzin
Pulse Secure, LLC Pulse Secure, LLC
October 24, 2014 February 20, 2015
SACM Information Model SACM Information Model
draft-ietf-sacm-information-model-00 draft-ietf-sacm-information-model-01
Abstract Abstract
TODO: reconcile This document proposes an information model for SACM.
(TNC)This document proposes an information model for endpoint posture
assessment. It describes the information needed to perform certain
assessment activities and to communicate and respond to the
assessments.(/TNC)
(wandw)This document defines an information model for aggregated
configuration and operational data, so that the data can be evaluated
to determine an organization's security posture.(/wandw)
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 April 27, 2015. This Internet-Draft will expire on August 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Changes in Revision 01 . . . . . . . . . . . . . . . . . 5
2.1. Mapping to SACM Use Cases . . . . . . . . . . . . . . . . 6 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Referring to an Endpoint . . . . . . . . . . . . . . . . 7 2.1. Mapping to SACM Use Cases . . . . . . . . . . . . . . . . 7
2.2. Referring to an Endpoint . . . . . . . . . . . . . . . . 8
2.3. Dealing with Uncertainty . . . . . . . . . . . . . . . . 8 2.3. Dealing with Uncertainty . . . . . . . . . . . . . . . . 8
3. Conventions used in this document . . . . . . . . . . . . . . 8 3. Conventions used in this document . . . . . . . . . . . . . . 9
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 8 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 9
4. Elements of the SACM Information Model . . . . . . . . . . . 8 4. Elements of the SACM Information Model . . . . . . . . . . . 9
4.1. Endpoint Attribute Assertion . . . . . . . . . . . . . . 11 4.1. Software Component . . . . . . . . . . . . . . . . . . . 12
4.1.1. Form and Precise Meaning . . . . . . . . . . . . . . 11 4.2. Software Instance . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Asserter . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Hardware Component . . . . . . . . . . . . . . . . . . . 14
4.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Hardware Instance . . . . . . . . . . . . . . . . . . . . 14
4.1.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 12 4.5. Network Interface . . . . . . . . . . . . . . . . . . . . 14
4.1.5. Event . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.6. Difference between Attribute and Event . . . . . . . 13 4.7. Identity . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 13 4.8. Location . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Unique Endpoint Identifier . . . . . . . . . . . . . 14 4.9. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Posture Attribute . . . . . . . . . . . . . . . . . . 14 4.10. Endpoint Attribute Assertion . . . . . . . . . . . . . . 17
4.2.3. Evaluation Result . . . . . . . . . . . . . . . . . . 15 4.10.1. Form and Precise Meaning . . . . . . . . . . . . . . 17
4.3. Report . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.11. Attribute-Value Pair . . . . . . . . . . . . . . . . . . 18
4.4. SACM Component . . . . . . . . . . . . . . . . . . . . . 16 4.11.1. Posture Attribute . . . . . . . . . . . . . . . . . 19
4.4.1. External Attribute Collector . . . . . . . . . . . . 16 4.11.2. Identifying Attributes . . . . . . . . . . . . . . . 19
4.4.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . 17 4.11.3. Evaluation Result . . . . . . . . . . . . . . . . . 21
4.4.3. Report Generator . . . . . . . . . . . . . . . . . . 17 4.12. Report . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Organization? . . . . . . . . . . . . . . . . . . . . . . 17 4.13. SACM Component . . . . . . . . . . . . . . . . . . . . . 22
4.6. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 18 4.13.1. External Attribute Collector . . . . . . . . . . . . 22
4.6.1. Internal Collection Guidance . . . . . . . . . . . . 18 4.13.2. Evaluator . . . . . . . . . . . . . . . . . . . . . 22
4.6.2. External Collection Guidance . . . . . . . . . . . . 18 4.13.3. Report Generator . . . . . . . . . . . . . . . . . . 23
4.6.3. Evaluation Guidance . . . . . . . . . . . . . . . . . 18 4.14. Organization? . . . . . . . . . . . . . . . . . . . . . . 23
4.6.4. Retention Guidance . . . . . . . . . . . . . . . . . 18 4.15. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6.5. Reporting Guidance . . . . . . . . . . . . . . . . . 18 4.15.1. Internal Collection Guidance . . . . . . . . . . . . 24
4.7. Provenance of Information . . . . . . . . . . . . . . . . 18 4.15.2. External Collection Guidance . . . . . . . . . . . . 24
4.8. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 19 4.15.3. Evaluation Guidance . . . . . . . . . . . . . . . . 24
4.8.1. Endpoint Credential . . . . . . . . . . . . . . . . . 19 4.15.4. Retention Guidance . . . . . . . . . . . . . . . . . 24
4.8.2. Software Component . . . . . . . . . . . . . . . . . 19 4.15.5. Reporting Guidance . . . . . . . . . . . . . . . . . 24
4.8.2.1. Unique Software Identifier . . . . . . . . . . . 20 4.16. Provenance of Information . . . . . . . . . . . . . . . . 24
4.17. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8.3. Software Instance . . . . . . . . . . . . . . . . . . 20 4.17.1. Endpoint Identity . . . . . . . . . . . . . . . . . 25
4.8.4. Hardware Component . . . . . . . . . . . . . . . . . 21 4.17.2. Software Component . . . . . . . . . . . . . . . . . 25
4.8.5. Hardware Instance . . . . . . . . . . . . . . . . . . 21 4.17.2.1. Unique Software Identifier . . . . . . . . . . . 26
4.9. User . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.18. User . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.9.1. User Credential . . . . . . . . . . . . . . . . . . . 21 4.18.1. User Identity . . . . . . . . . . . . . . . . . . . 26
4.10. Network Session / Network Interface . . . . . . . . . . . 21 5. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 26
4.10.1. Address . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Graph Model for Detection of Posture Deviation . . . . . 27
4.10.2. Authorizations . . . . . . . . . . . . . . . . . . . 22 5.1.1. Components . . . . . . . . . . . . . . . . . . . . . 27
4.11. Location . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 27
5. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 22 5.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Graph Model for Detection of Posture Deviation . . . . . 23 5.1.4. Relationships between Identifiers and Metadata . . . 29
5.1.1. Components . . . . . . . . . . . . . . . . . . . . . 23 5.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
5.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 30
5.1.4. Relationships between Identifiers and Metadata . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
5.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 Appendix A. Security Automation with TNC IF-MAP . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.1. What is Trusted Network Connect? . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 27 A.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 27 A.3. What is the TNC Information Model? . . . . . . . . . . . 38
Appendix A. Security Automation with TNC IF-MAP . . . . . . . . 33 Appendix B. Text for Possible Inclusion in the Terminology Draft 39
A.1. What is Trusted Network Connect? . . . . . . . . . . . . 33 B.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 39
A.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 33 B.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 39
A.3. What is the TNC Information Model? . . . . . . . . . . . 34 B.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 39
Appendix B. Text for Possible Inclusion in the Terminology Draft 35
B.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 35
B.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 35
B.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Text for Possible Inclusion in the Architecture or Appendix C. Text for Possible Inclusion in the Architecture or
Use Cases . . . . . . . . . . . . . . . . . . . . . 36 Use Cases . . . . . . . . . . . . . . . . . . . . . 40
C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36 C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 40
C.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 37 C.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 41
C.3. Architecture Assumptions . . . . . . . . . . . . . . . . 37 C.3. Architecture Assumptions . . . . . . . . . . . . . . . . 41
Appendix D. Text for Possible Inclusion in the Requirements Appendix D. Text for Possible Inclusion in the Requirements
Draft . . . . . . . . . . . . . . . . . . . . . . . 41 Draft . . . . . . . . . . . . . . . . . . . . . . . 45
D.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 41 D.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 45
D.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 41 D.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 45
Appendix E. Text With No Clear Home Yet . . . . . . . . . . . . 42 Appendix E. Text With No Clear Home Yet . . . . . . . . . . . . 46
E.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 42 E.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 46
E.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 42 E.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 46
E.2. From Information Needs to Information Elements . . . . . 43 E.2. From Information Needs to Information Elements . . . . . 47
E.3. Information Model Elements . . . . . . . . . . . . . . . 43 E.3. Information Model Elements . . . . . . . . . . . . . . . 47
E.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 45 E.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 49
E.3.1.2. Endpoint Identification . . . . . . . . . . . . . 47 E.3.1.2. Endpoint Identification . . . . . . . . . . . . . 51
E.3.1.3. Software Identification . . . . . . . . . . . . . 48 E.3.1.3. Software Identification . . . . . . . . . . . . . 52
E.3.1.4. Hardware Identification . . . . . . . . . . . . . 51 E.3.1.4. Hardware Identification . . . . . . . . . . . . . 55
E.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 51 E.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 55
E.3.2.1. Platform Configuration Item Identifier . . . . . 51 E.3.2.1. Platform Configuration Item Identifier . . . . . 55
E.3.2.2. Configuration Item Identifier . . . . . . . . . . 57 E.3.2.2. Configuration Item Identifier . . . . . . . . . . 61
E.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 59 E.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 63
E.3.3. Endpoint characterization . . . . . . . . . . . . . . 59 E.3.3. Endpoint characterization . . . . . . . . . . . . . . 63
E.3.4. Posture Attribute Expression . . . . . . . . . . . . 63 E.3.4. Posture Attribute Expression . . . . . . . . . . . . 67
E.3.4.2. Platform Configuration Attributes . . . . . . . . 63 E.3.4.2. Platform Configuration Attributes . . . . . . . . 67
E.3.5. Actual Value Representation . . . . . . . . . . . . . 65 E.3.5. Actual Value Representation . . . . . . . . . . . . . 69
E.3.5.1. Software Inventory . . . . . . . . . . . . . . . 65 E.3.5.1. Software Inventory . . . . . . . . . . . . . . . 69
E.3.5.2. Collected Platform Configuration Posture E.3.5.2. Collected Platform Configuration Posture
Attributes . . . . . . . . . . . . . . . . . . . 66 Attributes . . . . . . . . . . . . . . . . . . . 70
E.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 67
E.3.6.1. Configuration Evaluation Guidance . . . . . . . . 67 E.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 71
E.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 69 E.3.6.1. Configuration Evaluation Guidance . . . . . . . . 71
E.3.7.1. Configuration Evaluation Results . . . . . . . . 69 E.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 73
E.3.7.2. Software Inventory Evaluation Results . . . . . . 71 E.3.7.1. Configuration Evaluation Results . . . . . . . . 73
Appendix F. Graph Model . . . . . . . . . . . . . . . . . . . . 71 E.3.7.2. Software Inventory Evaluation Results . . . . . . 75
F.1. Background: Graph Models . . . . . . . . . . . . . . . . 72 Appendix F. Graph Model . . . . . . . . . . . . . . . . . . . . 75
F.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 73 F.1. Background: Graph Models . . . . . . . . . . . . . . . . 76
F.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 73 F.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 77
F.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 74 F.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 77
F.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 74 F.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 78
F.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 75 F.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 78
F.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 75 F.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 79
F.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 75 F.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 F.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
This document defines a notional information model for endpoint This document defines a notional information model for endpoint
posture assessment. It describes the information needed to perform posture assessment. It describes the information needed to perform
certain assessment activities. The scope of the information model is certain assessment activities. The scope of the information model is
to describe the structure of the information carried to realize the to describe the structure of the information carried to realize the
assessment. It is meant to be a basis for the development of assessment. It is meant to be a basis for the development of
specific data models. The terms information model and data model specific data models. The terms information model and data model
loosely align with the definitions in RFC3444 [RFC3444]. loosely align with the definitions in RFC3444 [RFC3444].
skipping to change at page 5, line 43 skipping to change at page 5, line 32
exactly which provider generated a piece of information, or by what exactly which provider generated a piece of information, or by what
method. method.
At the same time, a consumer *can* know these things, if necessary. At the same time, a consumer *can* know these things, if necessary.
As things evolve, a provider can relay supplemental information. As things evolve, a provider can relay supplemental information.
Some consumers will understand and benefit from the supplemental Some consumers will understand and benefit from the supplemental
information; other consumers will not understand and will disregard information; other consumers will not understand and will disregard
it. it.
1.1. Changes in Revision 01
Added some proposed normative text.
For provenance:
o Added a class "Method"
o Added the produced-using relationship between an AVP and a method
o Added the produced-by relationship between a Guidance and a SACM
Component
o Added the hosted-by relationship between a SACM Component and an
Endpoint
asserted-by and summarized-by have been renamed to produced-by.
"User" is now "Account". If a user has different credentials, SACM
cannot know that they belong to the same user. But, per Kim W, many
organizations do have accounts that associate credentials.
The multiplicity of the based-on relationships has been corrected.
More relationships now have labels, per UML convention.
The diagram no longer has causal arrows. They had become redundant
and were nonstandard and clutter.
Renamed "credential" to "identity", following industry usage. A
credential includes proof, such as a key or password. A username or
a distinguished name is called an "identity".
Removed Session, because an endpoint's network activity is not SACM's
initial focus
Removed Authorization, for the same reason
Added many-to-many relationship between Hardware Component and
Endpoint, for clarity
Added many-to-many relationship between Software Component and
Endpoint, for clarity
Added "contains" relationship between Network Interface and Network
Interface
Removed relationship between Network Interface and Account. The
endpoint knows the identity it used to gain network access. The PDP
also knows that. But they probably do not know the account.
Added relationship between Network Interface and Identity. The
endpoint and the PDP will typically know the identity.
Made identity-to-account a many-to-one relationship.
2. Problem Statement 2. Problem Statement
TODO: revise TODO: revise
(wandw)SACM requires a large and broad set of mission and business (wandw)SACM requires a large and broad set of mission and business
processes, and to make the most effective of use of technology, the processes, and to make the most effective of use of technology, the
same data must support multiple processes. The activities and same data must support multiple processes. The activities and
processes described within this document tend to build off of each processes described within this document tend to build off of each
other to enable more complex characterization and assessment. In an other to enable more complex characterization and assessment. In an
effort to create an information model that serves a common set of effort to create an information model that serves a common set of
skipping to change at page 9, line 20 skipping to change at page 10, line 11
representation of a software component, endpoint identity, user representation of a software component, endpoint identity, user
identity, address, location, and authorization constraining the identity, address, location, and authorization constraining the
endpoint endpoint
The SACM Information Model does not (in this draft) specify how long The SACM Information Model does not (in this draft) specify how long
information is retained. Historical information is modeled the same information is retained. Historical information is modeled the same
way as current information. Historical information may be way as current information. Historical information may be
represented differently in an implementation, but that difference represented differently in an implementation, but that difference
would be in data models, not in the information model. would be in data models, not in the information model.
Figure 1 depicts the world that the SACM information elements must Figure 1 the the information model.
describe.
+---------+ +---------+ +--------+___________________
|Hardware | |Software | __________|Location|*______________ |
|Component| |Component| | *+--------+* | |
+---------+ +---------+ | | |
|1 |1 | +----------+ | |
|* |* | ______|Credential|___________ | |
+---------+ +--------+ | | *+----------+* |* |* |
|Hardware | |Software| | | +---------+ +----+ |
|Instance | |Instance| | | |Network |________|User| |
+---------+ +--------+ | | |Session |* 0..1+----+ |
|* |* *| *| |- - - - -| *|
| |___1+----------+1______*|Network |_________+-------+
|____________| Endpoint |_____ |Interface|* 1..*|Address|
1| |0..1 | +---------+ +-------+
+----------+ | 1|
|* | |_____+-------------+
|______| *|Authorization|
part-of> +-------------+
Figure 1: A Simplified Model of the World
Figure 2 depicts an instance of the information model.
+---------+ +---------+ +--------+____________________ +---------+*______in>_______*+-----+
|Hardware | |Software | __________|Location|*_______________ | |Hardware | |! !|
|Component| |Component| | *+--------+* | | |Component| +---------+ |! !| +--------+*________________
+---------+ +---------+ | | | +---------+ |Software |in> |! !|*_____*|Location|___________ <in|
|1 |1 | +----------+ | | 1| |Component|____|! !| in> +--------+* <in *| |
|* |* | ______|Credential|____________ | | | +---------+* *|! !| +-------+ |
+---------+ +--------+ | | *+----------+* |* |* | | 1| |! !| |Account| |
|Hardware | |Software| | | +---------+ +----+ | | *| | | +----------+ +-------+ |
|Instance | |Instance| | | |Network |_________|User| | | +---------+ |End- |*_____*| Identity |_________|0..1 |
+---------+ +--------+ | | |Session |* 0..1+----+ | *| |Software |in> |point| acts +----------+* belongs |
|* |* *| *| |- - - - -| *| +---------+ |Instance |____| | for> 0..1|^ to> |
| |___1+-----------+1______*|Network |__________+-------+ |Hardware | +---------+* 1|! !| |acts |
|____________| Endpoint |_____ |Interface|* 1..*|Address| |Instance |__________________|! !| *|for |*
1| |0..1 | +---------+ +-------+ +---------+* in> 1|! !|_______+---------+ +-------+
+-----------+ | 1| |! !|1 <in *|Network |1_______*|Address|
|* | |_____+-------------+ |! !|____ |Interface| <bound +-------+
|______| *|Authorization| |! !|0..1| +---------+ to
part-of> +-------------+ +-----+ | *| |0..1
...................................................................... 1| |* | |___|
|0..1 ____________________| |_______| in>
| | in>
|* .......|..............................................................
+---+ +---------+______>______+-------+ | |0..1
|AVP|________|Endpoint |* 1|Summary| | |
+---+1..* 1|Attribute|_______ +-------+ | |*
|Assertion|0..1 | *| | +-----+ +---------+___________________
+---------+ | | | | AVP |____________|Endpoint |* <based-on |
|* |* | | ^| +-----+1..* 1|Attribute|________ |
|^ |____>____| ^| hosted-by| *| |Assertion|* | |
asserted-by| <based-on |summarized-by | | +---------+ | |
|1 | | |produced-using |* |* | *|
------------ +---------+ | | 1|V | |__________| +-------+
| |__>__|SACM |_________________| | +--------+ | <based-on |Summary|
|Guidance |1 *|Component|1 | | Method | | +-------+
------------ +---------+ | +--------+ |produced-by *|
|____________________ |V |
|* 1| |
+--------+1____________*+-----------+ |
| | guides> | SACM |__________________________|
|Guidance| | Component |1 <produced-by
+--------+*____________1+-----------+
<produced-by
------------------------------------------------------------- -------------------------------------------------------------
1 Multiplicity symbols > < Direction of causation. For ..... Above this line is the monitorable world
0..1 found in UML 2 v ^ example, guidance affects
* class diagrams affects a SACM component.
1..*
..... Above this line is the
monitorable world
------------------------------------------------------------- -------------------------------------------------------------
Figure 2: Elements and Multiplicity Figure 1: The Information Model
Note: UML 2 is specified by [UML]. Note: UML 2 is specified by [UML].
TODO: update text to match new figure: TODO: update text to match new figure:
Need to be clear in the description that - of some of the Need to be clear in the description that - of some of the
relationships, will need some language and guidance to the interfaces relationships, will need some language and guidance to the interfaces
and relationships we expect to have happen, MUSTs and SHOULDs, as and relationships we expect to have happen, MUSTs and SHOULDs, as
well as explaining the extensibility that other relationships can well as explaining the extensibility that other relationships can
exist, show examples of how that can happen. Others that we haven't exist, show examples of how that can happen. Others that we haven't
thought of yet, might be added by another RFC or in another way thought of yet, might be added by another RFC or in another way
The following subsections discuss Figure 2 and then Figure 1. CEK: I suddenly wonder whether all of the relationships in the upper
right corner of the diagram are needed. At present, AVPs mostly
mention instances of the classes in the upper half. The only
relationship an endpoint attribute assertion expresses is that a set
of AVPs are all true of some endpoint. We don't have a way to say
that an address is bound to a particular interface. Such structures
*can* be modeled, using YANG, for example. But do we require that?
If we do, why? I do think we need to be able to relate a software
instance to the software component, and a hardware instance to the
hardware component.
4.1. Endpoint Attribute Assertion The following subsections discuss the elements and relationships
found in Figure 1.
4.1.1. Form and Precise Meaning 4.1. Software Component
An endpoint attribute assertion has: An endpoint contains and runs software components.
o One or more attribute-value pairs (AVPs) Relationship:
o A time interval over which the assertion holds o If an endpoint has an instance of a software component, we say
that the software component is "in" the endpoint. This is a
shorthand.
o Endpoint uniquely identified? True or false Some software components are assets. "Asset" is defined in RFC4949
[RFC4949] as "a system resource that is (a) required to be protected
by an information system's security policy, (b) intended to be
protected by a countermeasure, or (c) required for a system's
mission."
o Provenance, including: An examination of software needs to consider both (a) software assets
and (b) software that may do harm. A posture attribute collector may
not know (a) from (b). It is useful to define Software Component as
the union of (a) and (b).
* The SACM component that made the assertion Examples of Software Assets:
* The endpoint attribute assertions (if any) on which this o An application
assertion is based
* Information about the method used to derive the assertion o A patch
It means that over the specified time interval, there was an endpoint o The operating system kernel
for which all of the listed attribute-value pairs were true.
If the "Endpoint uniquely identified" is true, the set of attributes- o A boot loader
value pairs together make this assertion apply to only one endpoint.
The attributes can include posture attributes and identification o Firmware that controls a disk drive
attributes. The model does not make a rigid distinction between the
two uses of attributes.
Some of the attributes may be multi-valued. o A piece of JavaScript found in a web page the user visits
One of the AVPs may be a unique endpoint identifier. Not every Examples of harmful software components:
endpoint will have one. If there is one, the SACM component that
produces the Endpoint Attribute Assertion will not necessarily know
what it is.
4.1.2. Asserter o A malicious entertainment app
An Endpoint Attribute Assertion may come from an attribute collector o A malicious executable
or an evaluator. It may come from a SACM component that derives it
from out-of-band sources, such as a physical inventory system. A
SACM component may derive it from other Endpoint Attribute
Assertions.
4.1.3. Example o A web page that contains malicious JavaScript
For example, an attribute assertion might have these attribute-value o A business application that shipped with a virus
pairs:
mac-address = 01:23:45:67:89:ab Software components SHOULD be disjoint from each other. In other
words, software componenns SHOULD be so defined that a given byte of
software on an endpoint belongs to only one software component.
os = OS X Different versions of the same piece of software MUST be modeled as
different components. Software versioning is not built into the
information model.
os-version = 10.6.8 Each separately installable piece of software SHOULD be modeled as a
component. Sometimes it may be better to divide more finely: what an
installer installs MAY be modeled as several components.
This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran A data model MAY identify a software component by parts of an ISO
OS X 10.6.8 throughout the specified time interval. A profiler might SWID tag.
have provided this assertion.
4.1.4. A Use Case 4.2. Software Instance
For example, Endpoint Attribute Assertions should help SACM Each copy of a piece of software is called a software instance. The
components to track an endpoint as it roams or stays stationary. configuration of a software instance is regarded as part of the
They must track endpoints because they must track endpoints' postures software instance. Configuration can strongly affect security
over time. Tracking of an endpoint can employ many clues, such as: posture.
The endpoint's MAC address A data model MUST support the following relationships:
The authenticated identity (even if it identifies a user) o A software instance is an "instance of" a software component.
The location of the endpoint and the user o A software instance is "in" an endpoint.
4.1.5. Event A data model MAY use ISO SWID tags to identify software instances.
An event is represented as a Posture Attribute Assertion whose time 4.3. Hardware Component
interval has length zero.
Some potential kinds of events are: Hardware components may also be assets and/or harmful. For example,
a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional
layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm.
o A structured syslog message [RFC5424] A data model MAY designate a hardware component by its manufacturer
and a part number.
o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA] 4.4. Hardware Instance
o A NetFlow message [RFC3954] A hardware instance is just an instance of a particular component.
4.1.6. Difference between Attribute and Event A data model MUST support the following relationships:
Author: Henk Birkholz o A hardware instance is an "instance of" a hardware component.
"Attribute" and "event" are often used fairly interchangeably. A o A hardware instance is "in" an endpoint.
clear distinction makes the words more useful.
An *attribute* tends not to change until something causes a change. Hardware instances may need to be modeled because (a) an endpoint may
In contrast, an *event* occurs at a moment in time. have multiple instances of a hardware component, (b) a hardware
instance may be compromised, whereas other instances may remain
intact.
For a nontechnical example, let us consider "openness" as an A data model MAY designate a hardware instance by its component and a
attribute of a door, with two values, "open" and "closed". A closed unique serial number.
door tends to stay closed until something opens it (a breeze, a
person, or a dog).
The door's opening or closing is an event. 4.5. Network Interface
Similarly, "Host firewall enabled" may be modeled as a true/false CEK: I am not sure how to use network interfaces for endpoint
attribute of an endpoint. Enabling or disabling the host firewall identification. As for compliance, is this too advanced for SACM at
may be modeled as an event. An endpoint's crashing also may be this time?
modeled as an event.
Although events are not attributes, we use one kind of information An endpoint generally has at least one network interface.
element, the "Endpoint Attribute Assertion", to describe both
attributes and events.
4.2. Attribute-Value Pair Interfaces nest. A virtual interface can nest in a physical
interface.
The set of attribute types must be extensible, by other IETF A data model MUST support the following relationships:
o A network interface is "in" an endpoint.
o A network interface is "in" another network interface; this is for
a nested interface. CEK: And this allows representing compliance
policies that are worthwhile. But is this too advanced for the
initial set of SACM RFCs?
o A network interface "acts for" an identity. This occurs, for
example, when the network interface is online because of
successful 802.1X. An internal collector may be aware of the
identity. An external collector (such as a RADIUS server) will be
aware of the identity.
4.6. Address
As used in this document, an address is any of:
o A layer 2 address; a data model MUST support MAC addresses, and
MAY support others
o A layer 3 address; a data model MUST support IPv4 and IPv6
addresses, and MAY support others
o A layer 4 address; a data model MUST support an IP-address-
protocol-port combination, where protocol is TCP or UDP. It MAY
support others
Addresses from other layers may be added in the future.
These addresses are not necessarily globally unique. Therefore, a
data model SHOULD allow an address to be qualified with a scope.
o A data model SHOULD allow qualifying a MAC address with its
layer-2 broadcast domain. This MAY take the form of a VLAN ID and
an administratively assigned string denoting the LAN.
o A data model SHOULD allow qualifying an IP address with an
administratively assigned string denoting the IP routing domain.
A data model MUST support the following relationships:
o An address is "bound to" a network interface.
o An address is considered "bound to" an endpoint just if the
address is "bound to" an interface that is "in" the endpoint.
o An address may be "in" one or more locations.
4.7. Identity
An identity is the non-secret part of a credential. Examples are a
username, an X.500 distinguished name, and a public key. Passwords,
private keys, and other secrets are not considered part of an
identity.
A data model MUST support the following relationships:
o An endpoint may "act for" an identity. This SHALL mean that the
endpoint claims or proves that it has this identity. For example,
if the endpoint is part of an Active Directory domain and Alice
logs into the endpoint with her AD username (alice) and password,
the endpoint "acts for" alice. An endpoint MAY "act for" more
than one identity at once, such as a machine identity and a user
identity.
o A identity may "belong to" an account. For example, an enterprise
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
in identifying an endpoint or in specifying compliance
measurements to be taken.
4.8. Location
Location can be logical or physical. Location can be a clue to an
endpoint's identity.
A data model MUST support the following relationships:
o An endpoint may be "in" a location
o A location may be "in" one or more locations
o A network address may be "in" a location
o An account may be "in" a location; this would happen if the
account represents a user, and a physical access control system
reports on the user's location
Examples of location:
o The switch, access point, VPN gateway, or cell tower to which the
endpoint is linked
o The switch port where the endpoint is plugged in
o The location of the endpoint's IP address in the network topology
o The geographic location of the endpoint (which is often self-
reported)
o A user location (may be reported by a physical access control
system)
CEK: The last three examples seem too advanced for the first set of
SACM RFCs. I do not know a notation that would be interoperable and
useful for endpoint identification. Should we drop them?
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
that as a kind of address.
A data model MUST support switch + port number, access point, and VPN
gateway as locations. The other examples are optional.
More than one of kind of location may pertain to an endpoint.
Endpoint has a many-to-many relationship with Location.
4.9. Endpoint
An endpoint is the hollow center of the model. An endpoint is an
abstract ideal. Any endpoint attribute assertion that mentions an
endpoint mentions it by specifying identifying attributes. Even if
there is one preferred endpoint identity, that is modeled as an
identity. We do not anticipate any AVP whose attribute type is
"endpoint".
4.10. Endpoint Attribute Assertion
Represents a direct observation by an attribute collector, or a
conclusion drawn by an evaluator. It asserts that specified posture
attribute-value pairs were true of an identified endpoint, at a
specific time or throughout a specified time interval.
CEK: I think it asserts that there exists an endpoint for which all
of the AVPs are true. The times and time intervals are features of
the AVPs, not of the endpoint attribute assertion.
4.10.1. Form and Precise Meaning
An endpoint attribute assertion MUST have:
o One or more attribute-value pairs (AVPs) (see section XXX)
o Provenance information, including: (see section XXX)
Asserted attributes and their associated values are used to both
identify the target endpoint and to communicate aspects of the
endpoint's posture. This distinction is further explained in section
XXX(AVPs).
4.11. Attribute-Value Pair
DW: Pair is not a good word for this information since more than two
data points are required. We should consider a better term.
An attribute-value pair (AVP) is a tuple of information asserting an
observed aspect of endpoint posture and/or identity.
Each AVP MUST include the following data:
o Identification of a posture or identification attribute (see
section [Posture Attribute])
o The value(s) associated with the posture or identification
attribute at the time the observation was made.
* The value MAY be structured. For example, it may something
like XML.
* Some attributes will be multi-valued. Data models implementing
this information model MUST support multiple values.
o Temporal information bounding the observation. Temporal
information MUST consist of one of the following:
* A timestamp indicating the point-in-time the observation was
made, or
* An interval establishing the duration for which the value(s)
have existed.
* Information about the method used to derive the assertion. (see
section [method])
If posture assertions are generated by monitoring a system for
changes, describing the interval for which a given state was found to
be consistent enables additional information to be expressed over a
point-in-time observation. Since values may drift over time,
expressing this additional information provides important context to
downstream consumers of a posture assertion about the rate and time
of change.
4.11.1. Posture Attribute
Posture Attribute is defined in [RFC5209] as "attribute describing
the configuration or status (posture) of a feature of the endpoint.
A Posture Attribute represents a single property of an observed
state."
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 to
address.
The value may be structured. For example, it may something like XML. Example posture attributes: [ This needs to be updated ]
The information model requires a standard attribute type (or possibly o TBD
more than one) for each box in Figure 1:
o Hardware Component: the value identifies the hardware type. For 4.11.2. Identifying Attributes
example, it may consist of the make and model number.
o Hardware Instance: the value, together with the Hardware Component An identifying attribute is observation made at a specific point in
value, uniquely identifies the hardware instance. For example, it time that can be used standalone or in combination with other
may be a manufacturer-assigned serial number. This notion might observations to identify an endpoint. While all endpoint posture
not apply to all virtual hardware components. attributes can be used to establish an endpoint's identity, not all
attributes are equally suited. Primary identifying attributes are a
subset of posture attributes that have the following desirable
characteristics for use in identifying an endpoint:
o Software Component: the value identifies a unit of software. Each o Available - Present on most platforms allowing for a breadth of
installable piece of software should be separately identifiable. interoperability between platforms.
For example, this might be a Software Identifier (SWID).
Therefore, a software inventory for an endpoint should be o Stable - Change infrequently (e.g., assist with identifying an
expressed as an Endpoint Attribute Assertion. endpoint across network sessions)
o Software Instance: the value describes how the software component o Authentic - High level of assurance, attributes can be
is installed and configured. authenticated
o Endpoint: The value is a unique endpoint identifier. Other posture attributes that do not possess these characteristics
are considered secondary identifying attributes. They can often be
used to check an identity assertion or to further define the
endpoint's identity (e.g. configuration, software inventory,
capability). Examples of primary identifying attributes:
o Location o Certificates (e.g., device, user, drive, other hardware)
o Credential: The value is the non-secret part of a credential. For MUST be provided if available on device; favored by consumers
example, it may be a certificate, or just a subject Distinguished of the assertion
Name extracted from a certificate. It may be a username.
o Network Interface: TBD Others if available as associated with the session
ISSUE: Use whole cert or some aspect (e.g., public key)
o User: [cek: Do we want this? If one user uses different o Hostname(s) - configured on the device; may be multiple and
credentials at different times, do we think SACM components will possibly of different kinds
need know that it's the same user?]
o Address: The value is an IP, MAC, or other network address, Consider how to specify type: multiple attributes for each type
possibly qualified with its scope. or type qualifier
o Authorization o FQDN(s) (if available); some hosts may have multiple; also list
DNS aliases
4.2.1. Unique Endpoint Identifier Sourced from the DNS infrastructure
An organization should try to uniquely identify and label an ISSUE: Think about the security considerations of insecure DNS
endpoint, whether the endpoint is enrolled or is discovered in the deployments
operational environment. The identifier should be assigned by or
used in the enrollment process.
Here "unique" means one-to-one. In practice, uniqueness is not o Network Interface(s) (comprehensive, if possible)
always attainable. Even if an endpoint has a unique identifier, an
attribute collector may not always know it.
If the attribute type of an AVP is "endpoint", the value is a unique MAC and IP address(es)
identifier of the endpoint.
4.2.2. Posture Attribute Including additional IPs assigned to the interface
Some AVPs will be posture attributes. Interfaces may be nested (e.g., overlay networks - VLANs)
See the definition in the SACM Terminology for Security Assessment NOTE: Need to verify that standardized methods are available to
[I-D.ietf-sacm-terminology]. do this.
Some potential kinds of posture attributes are: o Tool-specific Identifier - provided by the software making the
assertion
o A NEA posture attribute (PA) [RFC5209] SHOULD be provided if available
o A YANG model [RFC6020] May be session scoped if the tool is not able to distinguish an
endpoint across sessions
o An IF-MAP device-characteristics metadata item May be omitted if the tool is unable to distinguish the
[TNC-IF-MAP-NETSEC-METADATA] endpoint across multiple assertions
4.2.3. Evaluation Result o Identification information from bios/firmware (e.g., serial
numbers, asset tags, VM id) that can be queried on the device
using software. NOTE: Need to discuss more.
Assets are compositional. Some components may have specific
identifiers. It would be useful to indicate which component
has a specific identifying attribute.
Information should be made available by all manufacturers
If available should be provided as an attribute
o Other cryptographic information
4.11.3. Evaluation Result
Evaluation Results (see [I-D.ietf-sacm-terminology]) are modeled as Evaluation Results (see [I-D.ietf-sacm-terminology]) are modeled as
Endpoint Attribute Assertions. Endpoint Attribute Assertions.
An Evaluation Result derives from one or more other Endpoint An Evaluation Result derives from one or more other Endpoint
Attribute Assertions. Attribute Assertions.
An example is: a NEA access recommendation [RFC5793] An example is: a NEA access recommendation [RFC5793]
An evaluator may be able to evaluate better if history is available. An evaluator may be able to evaluate better if history is available.
This is a use case for retaining Endpoint Attribute Assertions for a This is a use case for retaining Endpoint Attribute Assertions for a
time. time.
An Evaluation Result may be retained longer than the Endpoint An Evaluation Result may be retained longer than the Endpoint
Attribute Assertions from which it derives. (Figure 2 does not show Attribute Assertions from which it derives. (Figure 1 does not show
this.) In the limiting case, Endpoint Attribute Assertions are not this.) In the limiting case, Endpoint Attribute Assertions are not
retained. When as an Endpoint Attribute Assertion arrives, an retained. When as an Endpoint Attribute Assertion arrives, an
evaluator produces an Evaluation Result. These mechanics are out of evaluator produces an Evaluation Result. These mechanics are out of
the scope of the Information Model. the scope of the Information Model.
4.3. Report 4.12. Report
An Endpoint Attribute Assertion concerns a single endpoint. An Endpoint Attribute Assertion concerns a single endpoint.
Assertions about a set of endpoints are also needed -- for example, Assertions about a set of endpoints are also needed -- for example,
for trend analysis and for reports read by humans. These assertions for trend analysis and for reports read by humans. These assertions
are termed "reports". SACM components will consume Endpoint are termed "reports". SACM components will consume Endpoint
Attribute Assertions and generate reports. Attribute Assertions and generate reports.
A report contains its provenance, with the same form and meaning as A report contains its provenance, with the same form and meaning as
the provenance of an Endpoint Attribute Assertion. the provenance of an Endpoint Attribute Assertion.
skipping to change at page 16, line 9 skipping to change at page 22, line 5
Results Results
o Other Reports o Other Reports
A Report may routine or ad hoc. A Report may routine or ad hoc.
Some reports may be machine readable. Machine readable reports may Some reports may be machine readable. Machine readable reports may
be consumable by SACM components and by automatic response systems be consumable by SACM components and by automatic response systems
(not specified by SACM). (not specified by SACM).
4.4. SACM Component 4.13. SACM Component
Although SACM components are mainly covered by the SACM architecture, Although SACM components are mainly covered by the SACM architecture,
we have some remarks. TODO: Move them? we have some remarks. TODO: Move them?
4.4.1. External Attribute Collector 4.13.1. External Attribute Collector
An external collector is a collector that observes endpoints from An external collector is a collector that observes endpoints from
outside. [kkw-many of these [collectors] are actually configured and outside. [kkw-many of these [collectors] are actually configured and
operated to manage assets for reasons other than posture assessments. operated to manage assets for reasons other than posture assessments.
it is critical to bring them into this, so i like it...but does it it is critical to bring them into this, so i like it...but does it
matter if the [collector] isn't intended to support posture matter if the [collector] isn't intended to support posture
assessment, but happens to have information that can be used by assessment, but happens to have information that can be used by
posture assessment collection consumers? do we lump them together posture assessment collection consumers? do we lump them together
with collectors that are intended to support posture assessment but with collectors that are intended to support posture assessment but
run external to the endpoint?] [jmf: ditto. The exampled below are run external to the endpoint?] [jmf: ditto. The exampled below are
skipping to change at page 17, line 5 skipping to change at page 22, line 48
o A Network Intrusion Detection System (NIDS) sensor o A Network Intrusion Detection System (NIDS) sensor
o A vulnerability scanner o A vulnerability scanner
o A hypervisor that peeks into the endpoint, the endpoint being a o A hypervisor that peeks into the endpoint, the endpoint being a
virtual machine virtual machine
o A management system that configures and installs software on the o A management system that configures and installs software on the
endpoint endpoint
4.4.2. Evaluator 4.13.2. Evaluator
An evaluator can consume endpoint attribute assertions, previous An evaluator can consume endpoint attribute assertions, previous
evaluations of posture attributes, or previous reports of evaluation evaluations of posture attributes, or previous reports of evaluation
results. [kkw-i don't think this conflicts with the definition in the results. [kkw-i don't think this conflicts with the definition in the
terminology doc re: that evaluation tasks evaluate posture terminology doc re: that evaluation tasks evaluate posture
attributes.] attributes.]
[cek-I like the change. I think it *does* require a change in the [cek-I like the change. I think it *does* require a change in the
terminology doc, though.] terminology doc, though.]
Example: a NEA posture validator [RFC5209] Example: a NEA posture validator [RFC5209]
[jmf- a NEA posture validator is not an example of this definition. [jmf- a NEA posture validator is not an example of this definition.
A NEA posture assessment is, maybe?] A NEA posture assessment is, maybe?]
[cek-Why isn't a NEA posture validator an example?] [cek-Why isn't a NEA posture validator an example?]
4.4.3. Report Generator 4.13.3. Report Generator
A report generator makes reports based on: A report generator makes reports based on:
o Endpoint Attribute Assertions, including Evaluation Results o Endpoint Attribute Assertions, including Evaluation Results
o Other Reports (a weekly report may be created from daily reports) o Other Reports (a weekly report may be created from daily reports)
It may summarize data continually, as the data arrives. It also may It may summarize data continually, as the data arrives. It also may
summarize data in response to an ad hoc query. summarize data in response to an ad hoc query.
4.5. Organization? 4.14. Organization?
[kkw-from a reporting standpoint there needs to be some concept like [kkw-from a reporting standpoint there needs to be some concept like
organization or system. without this, there is no way to produce organization or system. without this, there is no way to produce
result reports that can be acted upon to provide the insight or result reports that can be acted upon to provide the insight or
accountability that almost all continuous monitoring instances are accountability that almost all continuous monitoring instances are
trying to achieve. from a scoring or grading standpoint, an endpoint trying to achieve. from a scoring or grading standpoint, an endpoint
needs to be associated with exactly one organization or system. it needs to be associated with exactly one organization or system. it
can have a many to many relationship with other types of results can have a many to many relationship with other types of results
reporting "bins". is this important to include here? we had reporting "bins". is this important to include here? we had
organization as a core asset type for this reason, so i think it is a organization as a core asset type for this reason, so i think it is a
key information element. but i also know that i do not want to define key information element. but i also know that i do not want to define
all the different reporting types, so i am unsure.] all the different reporting types, so i am unsure.]
[cek-I had not thought of this at all. Would it make sense to treat [cek-I had not thought of this at all. Would it make sense to treat
the organization and the bins as part of the guidance for creating the organization and the bins as part of the guidance for creating
reports? Maybe not. We should discuss.] reports? Maybe not. We should discuss.]
4.6. Guidance 4.15. Guidance
[jmf- the guidance sections need more detail. . .] [jmf- the guidance sections need more detail. . .]
[cek - What is missing? We would welcome a critique or text.] [cek - What is missing? We would welcome a critique or text.]
Guidance is generally configurable by human administrators. Guidance is generally configurable by human administrators.
4.6.1. Internal Collection Guidance 4.15.1. Internal Collection Guidance
An internal collector may need guidance to govern what it collects An internal collector may need guidance to govern what it collects
and when. and when.
4.6.2. External Collection Guidance 4.15.2. External Collection Guidance
An external collector may need guidance to govern what it collects An external collector may need guidance to govern what it collects
and when. and when.
4.6.3. Evaluation Guidance 4.15.3. Evaluation Guidance
An evaluator typically needs Evaluation Guidance to govern what it An evaluator typically needs Evaluation Guidance to govern what it
considers to be a good or bad security posture. considers to be a good or bad security posture.
4.6.4. Retention Guidance 4.15.4. Retention Guidance
A SACM deployment may retain posture attributes, events, or A SACM deployment may retain posture attributes, events, or
evaluation results for some time. Retention supports ad hoc evaluation results for some time. Retention supports ad hoc
reporting and other use cases. reporting and other use cases.
If information is retained, retention guidance controls what is If information is retained, retention guidance controls what is
retained and for how long. retained and for how long.
If two or more pieces of retention guidance apply to a piece of If two or more pieces of retention guidance apply to a piece of
information, the guidance calling for the longest retention should information, the guidance calling for the longest retention should
take precedence. take precedence.
4.6.5. Reporting Guidance 4.15.5. Reporting Guidance
A Report Generator typically needs Reporting Guidance to govern the A Report Generator typically needs Reporting Guidance to govern the
reports it generates. reports it generates.
4.7. Provenance of Information 4.16. Provenance of Information
Each Endpoint Attribute Assertion and Report needs to be labeled with Each Endpoint Attribute Assertion and Report needs to be labeled with
its provenance. its provenance.
4.8. Endpoint 4.17. Endpoint
See the definition in the SACM Terminology for Security Assessment See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
In the model, an endpoint can be part of another endpoint. This In the model, an endpoint can be part of another endpoint. This
covers cases where multiple physical endpoints act as one endpoint. covers cases where multiple physical endpoints act as one endpoint.
The constituent endpoints may not be distinguishable by external The constituent endpoints may not be distinguishable by external
observation of network behavior. observation of network behavior.
For example, a hosting center may maintain a redundant set For example, a hosting center may maintain a redundant set
(redundancy group) of multi-chassis setups to provide active (redundancy group) of multi-chassis setups to provide active
redundancy and load distribution on network paths to WAN gateways. redundancy and load distribution on network paths to WAN gateways.
Multi-chassis link aggregation groups make the chassis appear as one Multi-chassis link aggregation groups make the chassis appear as one
endpoint. Traditional security controls must be applied either to endpoint. Traditional security controls must be applied either to
physical endpoints or the redundancy groups they compose (and physical endpoints or the redundancy groups they compose (and
occasionally both). Loss of redundancy is difficult to detect or occasionally both). Loss of redundancy is difficult to detect or
skipping to change at page 19, line 27 skipping to change at page 25, line 20
redundancy and load distribution on network paths to WAN gateways. redundancy and load distribution on network paths to WAN gateways.
Multi-chassis link aggregation groups make the chassis appear as one Multi-chassis link aggregation groups make the chassis appear as one
endpoint. Traditional security controls must be applied either to endpoint. Traditional security controls must be applied either to
physical endpoints or the redundancy groups they compose (and physical endpoints or the redundancy groups they compose (and
occasionally both). Loss of redundancy is difficult to detect or occasionally both). Loss of redundancy is difficult to detect or
mitigate without specific posture information about the current state mitigate without specific posture information about the current state
of redundancy groups. Even if a physical endpoint (e.g. router) that of redundancy groups. Even if a physical endpoint (e.g. router) that
is part of a redundancy group is replaced, the redundancy group can is part of a redundancy group is replaced, the redundancy group can
remain the same. remain the same.
4.8.1. Endpoint Credential 4.17.1. Endpoint Identity
An endpoint credential provides both identification and An endpoint identity provides both identification and authentication
authentication of the endpoint. For example, a credential may be an of the endpoint. For example, an identity may be an X.509
X.509 certificate [RFC5280] and corresponding private key. [jmf- certificate [RFC5280] and corresponding private key. [jmf- this
this example should be formatted like the other examples in this example should be formatted like the other examples in this section]
section]
Not all kinds of credentials are guaranteed to be unique. Not all kinds of identities are guaranteed to be unique.
4.8.2. Software Component 4.17.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 20, line 27 skipping to change at page 26, line 18
Examples of harmful software components: Examples of harmful software components:
o A malicious entertainment app o A malicious entertainment app
o A malicious executable o A malicious executable
o A web page that contains malicious JavaScript o A web page that contains malicious JavaScript
o A business application that shipped with a virus o A business application that shipped with a virus
4.8.2.1. Unique Software Identifier 4.17.2.1. Unique Software Identifier
Organizations need to be able to uniquely identify and label software Organizations need to be able to uniquely identify and label software
installed or run on an endpoint. Specifically, they need to know the installed or run on an endpoint. Specifically, they need to know the
name, publisher, unique ID, and version; and any related patches. In name, publisher, unique ID, and version; and any related patches. In
some cases the software's identity might be known a priori by the some cases the software's identity might be known a priori by the
organization; in other cases, a software identity might be first organization; in other cases, a software identity might be first
detected by an organization when the software is first inventoried in detected by an organization when the software is first inventoried in
an operational environment. Due to this, it is important that an an operational environment. Due to this, it is important that an
organization have a stable and consistent means to identify software organization have a stable and consistent means to identify software
found during collection. found during collection.
A piece of software may have a unique identifier, such as a SWID tag A piece of software may have a unique identifier, such as a SWID tag
(ISO/IEC 19770). (ISO/IEC 19770).
4.8.3. Software Instance 4.18. User
Each copy of a piece of software is called a software instance. The
configuration of a software instance is regarded as part of the
software instance. Configuration can strongly affect security
posture.
4.8.4. Hardware Component
Hardware components may also be assets and or harmful. For example,
a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional
layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm.
A hardware component is often designated by a manufacturer and a part
number.
4.8.5. Hardware Instance
A hardware instance is just an instance of a particular component. A
hardware instance often has a unique serial number.
Hardware instances may need to be modeled because (a) an endpoint may
have multiple instances of a hardware component, (b) a hardware
instance may be compromised, whereas other instances may remain
intact.
4.9. User
4.9.1. User Credential 4.18.1. User Identity
An endpoint is often - but not always - associated with one or more An endpoint is often - but not always - associated with one or more
users. users.
A user's credential provides both identification and authentication A user's identity provides both identification and authentication of
of the user. the user. @@@ Eh?
4.10. Network Session / Network Interface
An endpoint generally has at least one interface. Each interface
generally has a connection to a network, referred to here as a
network session.
4.10.1. Address
A network interface generally is associated with addresses, such as
MAC and IP addresses.
These addresses are not necessarily globally unique. Therefore, an
address may be qualified with a scope. For example:
o A MAC address may be qualified with its layer-2 broadcast domain.
o An IP address may be qualified with its IP routing domain.
Other kinds of addresses may find application.
4.10.2. Authorizations
Authorizations limit what the endpoint can do from a given network
interface. Examples include:
o A RADIUS VLAN assignment [RFC3580]
o A router or firewall access control list (ACL)
o An IF-MAP access-request constellation
[TNC-IF-MAP-NETSEC-METADATA], which may determine how a firewall
treats network sessions originating at the interface
4.11. Location
Location can be logical or physical, and may be pertinent to security
posture. For example, some endpoints may need to stay in protected
areas for their own protection.
Examples of location:
o The switch or access point to which the endpoint has authenticated
o The switch port where the endpoint is plugged in
o The location of the endpoint's IP address in the network topology
o The geographic location of the endpoint (which is often self-
reported)
o A user location (may be reported by a physical access control
system)
More than one of these may pertain to an endpoint. Endpoint has a
many-to-many relationship with Location.
5. SACM Usage Scenario Example 5. SACM Usage Scenario Example
TODO: this section needs to refer out to wherever the operations / TODO: this section needs to refer out to wherever the operations /
generalized workflow content ends up generalized workflow content ends up
TODO: revise to eliminate graph references TODO: revise to eliminate graph references
This section illustrates the proposed SACM Information Model as This section illustrates the proposed SACM Information Model as
applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations
[I-D.ietf-sacm-use-cases]. The following subsections describe the [I-D.ietf-sacm-use-cases]. The following subsections describe the
elements (components and elements), graph model, and operations elements (components and elements), graph model, and operations
(sample workflow) required to support the Detection of Posture (sample workflow) required to support the Detection of Posture
Deviations scenario. Deviations scenario.
The Detection of Posture Deviations scenario involves multiple The Detection of Posture Deviations scenario involves multiple
elements interacting to accomplish the goals of the scenario. elements interacting to accomplish the goals of the scenario.
Figure 2 illustrates those elements along with their major Figure 1 illustrates those elements along with their major
communication paths. communication paths.
5.1. Graph Model for Detection of Posture Deviation 5.1. Graph Model for Detection of Posture Deviation
The following subsections contain examples of identifiers and The following subsections contain examples of identifiers and
metadata which would enable detection of posture deviation. These metadata which would enable detection of posture deviation. These
lists are by no means exhaustive - many other types of metadata would lists are by no means exhaustive - many other types of metadata would
be enumerated in a data model that fully addressed this usage be enumerated in a data model that fully addressed this usage
scenario. scenario.
skipping to change at page 24, line 6 skipping to change at page 28, line 6
subscription requests from the analytics engine and authorizes subscription requests from the analytics engine and authorizes
access to appropriate information from the endpoint security access to appropriate information from the endpoint security
service. service.
5.1.2. Identifiers 5.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 credential (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
o Network Session o Network Session
o Address - categorized by type of address (e.g. MAC address, IP o Address - categorized by type of address (e.g. MAC address, IP
address, Host Identity Protocol (HIP) Host Identity Tag (HIT) address, Host Identity Protocol (HIP) Host Identity Tag (HIT)
[RFC5201], etc.) [RFC5201], etc.)
skipping to change at page 38, line 35 skipping to change at page 42, line 35
o Repositories (e.g., Enterprise Repository) store information items o Repositories (e.g., Enterprise Repository) store information items
that are input to or output from Capabilities, Producers, and that are input to or output from Capabilities, Producers, and
Consumers. For this model we refer to generic Enterprise and Consumers. For this model we refer to generic Enterprise and
Guidance Repositories. Guidance Repositories.
Information that needs to be communicated by or made available to any Information that needs to be communicated by or made available to any
of these components will be specified in each of the business process of these components will be specified in each of the business process
areas. areas.
In the most trivial example, illustrated in Figure 3, Consumers In the most trivial example, illustrated in Figure 2, 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 3: Example Producer/Consumer Interactions Figure 2: Example Producer/Consumer Interactions
As illustrated in Figure 4, writing and querying from data As illustrated in Figure 3, 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 4: Producer/Consumer Repository Interaction Figure 3: 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 40, line 48 skipping to change at page 44, line 48
+-----v--------+ +----+------+ +-----v--------+ +----+------+
|Evaluation | |Reporting | |Evaluation | |Reporting |
|Results | |Guidance | |Results | |Guidance |
|Consumer | |Repository | |Consumer | |Repository |
+---+----------+ +-----------+ +-------------+ +---+----------+ +-----------+ +-------------+
| | Results | | | Results |
+-----------------------------> Repository | +-----------------------------> Repository |
| | | |
+-------------+ +-------------+
Figure 5: Producer/Consumer Complex Example Figure 4: Producer/Consumer Complex Example
This illustrative example in Figure 5 provides a set of information This illustrative example in Figure 4 provides a set of information
exchanges that need to occur to perform a posture assessment. The exchanges that need to occur to perform a posture assessment. The
rest of this information model is using this set of exchanges based rest of this information model is using this set of exchanges based
on these core architectural components as the basis for determining on these core architectural components as the basis for determining
information elements. information elements.
Appendix D. Text for Possible Inclusion in the Requirements Draft Appendix D. Text for Possible Inclusion in the Requirements Draft
D.1. Problem Statement D.1. Problem Statement
Scalable and sustainable collection, expression, and evaluation of Scalable and sustainable collection, expression, and evaluation of
skipping to change at page 46, line 19 skipping to change at page 50, line 19
about the assets." Asset identification plays an important role in about the assets." Asset identification plays an important role in
an organization's ability to quickly correlate different sets of an organization's ability to quickly correlate different sets of
information about assets. The Asset Identification specification information about assets. The Asset Identification specification
provides the necessary constructs to uniquely identify assets based provides the necessary constructs to uniquely identify assets based
on known identifiers and/or known information about the assets. on known identifiers and/or known information about the assets.
Asset Identification provides a relatively flat and extensible model Asset Identification provides a relatively flat and extensible model
for capturing the identifying information about a one or more assets, for capturing the identifying information about a one or more assets,
and also provides a way to represent relationships between assets. and also provides a way to represent relationships between assets.
The model is organized using an inheritance hierarchy of specialized The model is organized using an inheritance hierarchy of specialized
asset types/classes (see Figure 6), providing for extension at any asset types/classes (see Figure 5), 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 46, line 42 skipping to change at page 50, line 42
| +-database | +-database
| +-network | +-network
| +-service | +-service
| +-software | +-software
| +-system | +-system
| +-website | +-website
+-data +-data
+-organization +-organization
+-person +-person
Figure 6: Asset Identification Class Hierarchy Figure 5: 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 54, line 31 skipping to change at page 58, 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 7: The OVAL Data Model Figure 6: The OVAL Data Model
The OVAL data model [OVAL-LANGUAGE], visualized in Figure 7, is The OVAL data model [OVAL-LANGUAGE], visualized in Figure 6, 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 73, line 12 skipping to change at page 77, 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 8: Knowledge represented by a graph Figure 7: Knowledge represented by a graph
A pair of vertices connected by an edge is commonly referred to as a A pair of vertices connected by an edge is commonly referred to as a
triple that comprises subject, predicate and object. For example, triple that comprises subject, predicate and object. For example,
subject = Sue Wong, predicate = is-parent-of, object = Ann Wong. A subject = Sue Wong, predicate = is-parent-of, object = Ann Wong. A
common language that uses this representation is the Resource common language that uses this representation is the Resource
Description Framework (RDF) [W3C.REC-rdf11-concepts-20140225]. Description Framework (RDF) [W3C.REC-rdf11-concepts-20140225].
F.2. Graph Model Overview F.2. Graph Model Overview
The proposed model, influenced by IF-MAP, is a labeled graph: each The proposed model, influenced by IF-MAP, is a labeled graph: each
 End of changes. 128 change blocks. 
442 lines changed or deleted 608 lines changed or added

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