--- 1/draft-ietf-sacm-terminology-12.txt 2017-07-03 17:13:07.330880182 -0700 +++ 2/draft-ietf-sacm-terminology-13.txt 2017-07-03 17:13:07.390881620 -0700 @@ -1,23 +1,23 @@ SACM Working Group H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Informational J. Lu -Expires: September 14, 2017 Oracle Corporation +Expires: January 5, 2018 Oracle Corporation J. Strassner Huawei Technologies N. Cam-Winget Cisco Systems - March 13, 2017 + July 04, 2017 Security Automation and Continuous Monitoring (SACM) Terminology - draft-ietf-sacm-terminology-12 + draft-ietf-sacm-terminology-13 Abstract This memo documents terminology used in the documents produced by SACM (Security Automation and Continuous Monitoring). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -25,49 +25,51 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 14, 2017. + This Internet-Draft will expire on January 5, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 - 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 - 8. Informative References . . . . . . . . . . . . . . . . . . . 25 - Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 8.2. Informative References . . . . . . . . . . . . . . . . . 28 + Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Our goal with this document is to improve our agreement on the terminology used in documents produced by the IETF Working Group for Security Automation and Continuous Monitoring. Agreeing on terminology should help reach consensus on which problems we're trying to solve, and propose solutions and decide which ones to use. 2. Terms and Definitions @@ -76,33 +78,32 @@ and defines new ones. The predefined terms will reference the RFC and where appropriate will be annotated with the specific context by which the term is used in SACM. Assertion: Defined by the ITU in [X.1252] as "a statement made by an entity without accompanying evidence of its validity". In the context of SACM, an assertion is the output of a SACM component in the form of a statement (including metadata about the data source and data origin, e.g. time stamps). While the validity of an assertion cannot be verified without, for example, an additional - attestation protocol, an assertion (and therfore a statement, - respectivly) can be accompanied by evidence of the validity of its - metadata provided by a SACM component. + attestation protocol, an assertion (and therefore a statement, + respectively) can be accompanied by evidence of the validity of + its metadata provided by a SACM component. Assessment: Defined in [RFC5209] as "the process of collecting posture for a set of capabilities on the endpoint (e.g., host- based firewall) such that the appropriate validators may evaluate the posture against compliance policy." - - An assessment is a specifc workflow that incorporates the SACM + An assessment is a specific workflow that incorporates the SACM tasks discovery, collection and evaluation. A prominent instance of the assessment workflow is illustrated in the Vulnerability - Assessement Scenario [I-D.ietf-sacm-vuln-scenario]. + Assessment Scenario [I-D.ietf-sacm-vuln-scenario]. Asset: Defined in [RFC4949] as "a system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protected by a countermeasure, or (c) required for a system's mission". In the scope of SACM, an asset can be composed of other assets. Examples of Assets include: Endpoints, Software, Guidance, or X.509 public key certificates. An asset is not necessarily owned by an organization. Asset Management: The process by which assets are provisioned, @@ -121,56 +122,65 @@ Authorization: Defined in [RFC4949] as "an approval that is granted to a system entity to access a system resource." Broker: A broker is a specific controller type that contains control plane functions to provide and/or connect services on behalf of other SACM components via interfaces on the control plane. A broker may provide, for example, authorization services and find, upon request, SACM components providing requested services. - Capability: In [I-D.ietf-i2nsf-terminology] a capability "defines a - set of features that are available from a managed entity. - Examples of "managed entities" are NSFs and Controllers, where NSF - Capabilities and Controller Capabilities define functionality of - an NSF and a Controller that may, but do not have to, be used, - respectively. All Capabilities are announced through the - Registration Interface." + Capability: In [I-D.ietf-i2nsf-terminology] a capability is "a set + of features that are available from an I2NSF Component. These + functions may, but do not have to, be used. All Capabilities are + announced through the I2NSF Registration Interface. Examples are + Capabilities that are available from an NSF Server." In the context of SACM, the extent of a SACM component's ability is enabled by the functions it is composed of. Capabilities are - announced by a SACM component via the SACM component registration - task and can be discovered by or negotiated with other SACM - components. For example, the capability of a SACM Provider may be - to provide endpoint management data, or only a subset of that - data. + registered at a SACM broker (potentially also at a proxy or a + repository component if it includes broker functions) by a SACM + component via the SACM component registration task and can be + discovered by or negotiated with other SACM components via the + corresponding tasks. For example, the capability of a SACM + provider may be to provide target endpoint records (declarative + guidance about well-known or potential target endpoints), or only + a subset of that data. + + A capability's description is in itself imperative guidance on + what functions are exposed to other SACM components in a SACM + domain and how to use them in workflows. The SACM Vulnerability Assessment Scenario [I-D.ietf-sacm-vuln-scenario] defines the terms Endpoint Management Capabilities, Vulnerability Management Capabilities, and Vulnerability Assessment Capabilities, which illustrate - specific sets of SACM capabilities, which are required to conduct - workflows illustrated by the scenario definition. + specific sets of SACM capabilities on an enterprise IT + department's point of view and therefore compose sets of + declarative guidance. Collection Result: Information about a target endpoint that is produced by a collector conducting a collection task. A collection result is composed as one or more content-elements. Collection Task: The task by which endpoint attributes and/or corresponding attribute values about a target endpoint are collected. The collection tasks are targeted at specific target endpoints and therefore are targeted tasks. - There are three types of frequency collection tasks can be + There are four types of frequency collection tasks can be conducted with: - ad-hoc, e.g. triggered by a specific event or a query + ad-hoc, e.g. triggered by a unsolicited query + + conditional, e.g. triggered in accordance with policies included + in the compositions of workflows scheduled, e.g. in regular intervals, such as every minute or weekly continuously, e.g. a network behavior observation There are three types of collection methods, each requiring an appropriate set of functions to be included in the SACM component conducting the collection task: @@ -195,61 +205,61 @@ A collector can be distributed across multiple endpoints, e.g. across a target endpoint and a SACM component. The separate parts of the collector can communicate with a specialized protocol, such as PA-TNC [RFC5792]. At least one part of a distributed collector has to take on the role of a provider of information by providing SACM interfaces to propagate capabilities and to provide SACM content in the form of collection results. Configuration: A non-volatile subset of the endpoint attributes of a - (target) endpoint that is intended to be uneffected by a normal - reboot-cylce. Configuration is a type of imperative guidance that + (target) endpoint that is intended to be unaffected by a normal + reboot-cycle. Configuration is a type of imperative guidance that is stored in files (files dedicated to contain configuration and/ or files that are software components), directly on block devices, or on specific hardware components that can be accessed via corresponding software components. Modification of configuration can be conducted manually or automatically via management (plane) interfaces that support management protocols, such as SNMP or WMI. A change of configuration can occur during both run-time and down- - time of an endpoint. It is common practive to scheduled a change + time of an endpoint. It is common practice to scheduled a change of configuration during or directly after the completion of a boot-cycle via corresponding software components located on the target endpoint itself. - Exmaples: The static association of an IP address and a MAC + Examples: The static association of an IP address and a MAC address in a DHCP server configuration, a directory-path that identifies a log-file directory, a registry entry. Configuration Drift: The discrepancy of a target endpoint's endpoint attributes representing the actual composition of a target endpoint (is-state) and its intended composition (should-state) in the scope of a valid target endpoint composition (could-state) due to continuous alteration of a target endpoint's composition over time. Configuration drift exists for both hardware components and software components. Typically, the frequency and scale of configuration drift of software components is significantly higher than the configuration drift of hardware components. Consumer: A consumer is a SACM role that is assigned to a SACM component that contains functions to receive information from other SACM components. Content Element: Content elements constitute the payload data (SACM - content) transfered via statement Subjects emitted by providers of - information. Every content element Subject includes a specific + content) transferred via statement Subjects emitted by providers + of information. Every content element Subject includes a specific content Subject and a corresponding content metadata Subject. Content Metadata: Data about content Subjects. Every content- element includes a content metadata Subject. The Subject can include any information element that can annotate the content - transefered. Examples include time stamps or data provenance + transeferred. Examples include time stamps or data provenance Subjects. Control Plane: Typically used as a term in the context of routing, e.g. [RFC6192]. In the context of SACM, the control plane is an architectural component providing common control functions to all SACM components, including authentication, authorization, (capability) discovery or negotiation, registration and subscription. The control plane orchestrates the flow on the data plane according to imperative guidance (i.e. configuration) received via the management plane. SACM components with @@ -294,33 +304,34 @@ scope. Data Integrity: Defined in [RFC4949] as "the property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner." Data Origin: One or more properties (i.e. endpoint attributes) that enable a SACM component to identify the SACM component that initially acquired or produced data about a (target) endpoint (e.g. via collection from a data source) and made it available to - a SACM domaini via a SACM statement. Data Origin can be expressed + a SACM domain via a SACM statement. Data Origin can be expressed by an endpoint label information element (e.g. to be used as metadata in statement). Data Plane (fix statement): Typically used as a term in the context of routing (and used as a synonym for forwarding plane, e.g. [RFC6192]). In the context of SACM, the data plane is an architectural component providing operational functions to enable a SACM component to provide and consume SACM statements and - therefore SACM content (the "payload"). The data plane is used to - conduct distributed SACM tasks by transporting SACM content using - transporting encodings and corresponding operations defined by - SACM data models. + therefore SACM content, which composes the actual SACM content. + The data plane in a SACM domain is used to conduct distributed + SACM tasks by transporting SACM content via specific transport + encodings and corresponding operations defined by SACM data + models. Data Provenance: A historical record of the sources, origins and evolution of data that is influenced by inputs, entities, functions and processes. In the context of SACM, data provenance is expressed as metadata that identifies SACM statements and corresponding content elements a new statement is created from. In a downstream process, this references can cascade, creating a data provenance tree that enables SACM components to trace back the original data sources involved in the creation of SACM statements and take into account their characteristics and @@ -360,23 +371,24 @@ Based on the definition of an asset, an endpoint is a type of asset. Endpoint Attribute: In the context of SACM, endpoint attributes are information elements that describe an endpoint characteristic of a target endpoint. Endpoint Attributes typically constitute Attributes that can be bundled into Subject (e.g. information about a specific network interface can be represented via a set of multiple AVP). - Endpoint Characteristic: The state, configuration and composition an - endpoint is in, including observerable behavior, e.g. sys-calls, - log-files, or PDU emission on a network. + Endpoint Characteristics: The state, configuration and composition + of the software components and (virtual) hardware components a + target endpoint is composed of, including observable behavior, + e.g. sys-calls, log-files, or PDU emission on a network. Endpoint Characterization: The task by which a profile is composed out of endpoint attributes that describe the desired or expected posture of a type or class of target endpoints or even an individual target endpoint. The result of this task is an endpoint profile that is required as declarative guidance for the tasks of endpoint classification or posture assessment. Endpoint Classification: The task by which a discovered target endpoint is classified. Endpoint classification requires @@ -411,21 +423,21 @@ Evaluation Result: The resulting value from having evaluated a set of posture attributes. Event: The change of a target endpoint characteristics at a specific point in time. In the context of SACM, an event is a statement (and therefore data in motion) that includes the new target endpoint characteristics and optional also the past ones, annotated with corresponding metedata (most prominently, the collection time of the data that constitutes the observation of - the event regarding te target endpoint). + the event regarding the target endpoint). Excluded Endpoint: A specific designation, which is assigned to an endpoint that is not supposed to be the subject of a collection task (and therefore is not a target endpoint). Typically but not necessarily, endpoints that contain a SACM component (and are therefore part of the SACM domain) are designated as excluded endpoints. Target endpoints that contain a SACM component cannot be designated as excluded endpoints and are part of the SACM domain. @@ -467,36 +479,47 @@ include a targeted Collection Task or the IP-Address of a SACM Component that provides a registration function. Hardware Component: Hardware components are the distinguishable physical components that compose an endpoint. The composition of an endpoint can be changed over time by adding or removing hardware components. In essence, every physical endpoint is potentially a composite of multiple hardware components, typically resulting in a hierarchical composition of hardware components. The composition of hardware components is based on interconnects - provided by specific hardware types (e.g. mainboard is a hardware - type that provides local busses as an interconnect). In general, - a hardware component can be distinguished by its serial number. + provided by specific hardware types (e.g. a mainboard is a + hardware type that provides local busses as an interconnect or an + FRU is a hardware type that is itself connected via an + interconnect to a chassis and can provide further interconnects + for additional hardware components, such as interfaces modules). + In general, a hardware component can be distinguished by its + serial number. Occasionally, hardware components are referred to + as power sucking aliens. - Occasionally, hardware components are refered to as power sucking - aliens. + The Entity MIB version 4 [RFC6933] and the YANG Data Model for + Hardware Management [I-D.ietf-netmod-entity] provide common + examples of target endpoint characteristics about hardware + components. Hardware Inventory: The list of hardware components that compose a specific endpoint representing its hardware configuration. Hardware Type: Hardware types define specific and distinguishable categories of hardware components that can be part of endpoints, e.g. CPU or 802.11p interface. Typically, hardware types can be distinguished by their vendor assigned names, names of standards used, or a model name. + The IANAPhysicalClass [RFC6933] and corresponding iana-entity YANG + module [I-D.ietf-netmod-entity] provide the standard references + for physical hardware types. + Information Element: A representation of information about physical and virtual "objects of interests". Information elements are the building blocks that constitute the SACM information model. In the context of SACM, an information element that expresses a single value with a specific name is referred to as an Attribute (analogous to an attribute-value-pair). A set of attributes that is bundled into a more complex composite information element is referred to as a Subject. Every information element in the SACM information model has a unique name. Endpoint attributes or time stamps, for example, are represented as information elements in @@ -667,21 +690,21 @@ possible dependencies to SACM architecture) SACM Interface: An interface is defined in [I-D.ietf-i2nsf-terminology] as "A set of operations one object knows it can invoke on, and expose to, another object. This decouples the implementation of the operation from its specification. An interface is a subset of all operations that a given object implements. The same object may have multiple types of interfaces to serve different purposes." - In the context of SACM, SACM Funktions provide SACM Interfaces on + In the context of SACM, SACM Functions provide SACM Interfaces on the management, control, or data plane. Operations a SACM Interface provides are based on corresponding data model defined by SACM. SACM Interfaces are used for communication between SACM components. SACM Role: A role is defined in [I-D.ietf-i2nsf-terminology] as "an abstraction of a Component that models context-specific views and responsibilities of an object as separate role objects that can be statically or dynamically attached to (and removed from) the object that the role object describes. This provides three @@ -694,23 +717,28 @@ that use that Component." In the context of SACM, SACM roles are associated with SACM components and are defined by the set of functions and interfaces a SACM component includes. There are three SACM roles: provider, consumer, and controller. The roles associated with a SACM component are determined by the purpose of the SACM functions and corresponding SACM interfaces the SACM component is composed of. Security Automation: The process of which security alerts can be - automated through the use of different tools to monitor, evaluate - and analyze endpoint and network traffic for the purposes of - detecting misconfigurations, misbehaviors or threats. + automated through the use of different components to monitor, + analyze and assess endpoints and network traffic for the purposes + of detecting miss-configurations, miss-behaviors or threats. + Security Automation is intended to identify target endpoints that + cannot be trusted (see "trusted" in [RFC4949]. This goal is + achieved by creating and processing evidence (assessment + statements) that a target endpoint is not a trusted system + [RFC4949]. Software Package: A generic software package (e.g. a text editor). Software Component: A software package installed on an endpoint, including a unique serial number if present (e.g. a text editor associated with a unique license key). Software Instance: A running instance of the software component (e.g. on a multi-user system, one logged-in user has one instance of a text editor running and another logged-in user has another @@ -723,57 +751,77 @@ interaction of components with other components via the control plane, via processing data plane payload, or via the functional properties of local hardware and software components. Dynamic configuration (e.g. IP address distributed dynamically via an address distribution and management services, such as DHCP) is considered state that is the result of the interaction with another component that provides configuration via the control plane (e.g. provided by a DHCP server with a specific configuration). - Exmaples: The static association of an IP address and a MAC + Examples: The static association of an IP address and a MAC address in a DHCP server configuration, a directory-path that identifies a log-file directory, a registry entry. Statement: A statement is a subject defined in the SACM information model. When a statement is used to provide content to a SACM domain, it is a top-level subject that bundles Content Elements into one subject and includes metadata about the data origin. Subject: A composite information element. Like Attributes, subjects have a name and are composed of attributes and/or other subjects. Every IE that is part of a subject can have a quantitiy associated with it (e.g. zero-one, none-unbounded). The content IE of a subject can be an unordered or an ordered list. + In contrast to the definitions of subject provided by [RFC4949], a + subject in the scope of SACM is neither "a system entity that + causes information to flow among objects or changes the system + state" nor "a name of a system entity that is bound to the data + items in a digital certificate". + + In the context of SACM, a subject is a semantic composite of + information elements about a system entity that is a target + endpoint. Every acquirable subject--as defined in the scope of + SACM--about a target endpoint represents and therefore identifies + every subject--as defined by [RFC4949]--that is a component of + that target endpoint. The semantic difference between both + definitions can be subtle in practice and is in consequence + important to highlight. + Supplicant: A SACM component seeking to be authenticated via the control plane for the purpose of participating in a SACM domain. System Resource: Defined in [RFC4949] as "data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication bandwidth; or an item of system equipment (i.e., hardware, firmware, software, or documentation); or a facility that houses system operations and equipment. Target Endpoint: A target endpoint is an "endpoint under assessment" (even if it is not actively under assessment at all times) or "endpoint of interest". Every endpoint that is not specifically designated as an excluded endpoint is a target endpoint. A target endpoint is not part of a SACM domain unless it contains a SACM component (e.g. a SACM component that publishes collection results coming from an internal collector). A target endpoint is similar to a device that is a Target of - Evaluation (TOE) as defined in Common Criteria. + Evaluation (TOE) as defined in Common Criteria and as referenced + by {{RFC4949}. + + In respect to [RFC4949] a target endpoint is an information system + and therefore a composite that is a system entity composed of + system components or system entities, respectively. Target Endpoint Characterization Record: A set of endpoint attributes about a target endpoint that was encountered in a SACM domain, which are associated with a target endpoint by being included in the corresponding record. A characterization record is intended to be a representation of an endpoint. It cannot be assured that a record distinctly represents a single target endpoint unless a set of one or more endpoint attributes that compose a unique set of identifying endpoint attributes are included in the record. Otherwise, the set of identifying @@ -849,29 +897,35 @@ identifying attributes, this reference can be ambiguous and is a "best-effort" mechanism. Every distinct set of identifying endpoint attributes can be associated with a target endpoint label that is unique in a SACM domain. Target Endpoint Label: A specific endpoint label that refers to a target endpoint identifier used to identify a specific target endpoint (also referred to as TE label). In content-metadata, this label is called data source. - Target Endpoint Profile: A bundle of expected or desired - configurations and states (typically a composition of endpoint - attribute value pairs) that can be associated with a target - endpoint. The corresponding task by which the association with a - target endpoint takes places is the endpoint classification. The + Target Endpoint Profile: A bundle of expected or desired component + composition, configurations and states--therefore a composition of + information elements that constitute declarative guidance-- + associated with a target endpoint. + + The corresponding task by which the association with a target + endpoint takes places is the endpoint classification task. The task by which an endpoint profile is created is the endpoint - characterization. A type or class of target endpoints is defined - within a target endpoint profile, e.g. printer, smartphone, or an - office PC. + characterization task. A type or class of target endpoints can be + defined via a target endpoint profile. Examples include: + printers, smartphones, or an office PC. + + In respect to [RFC4949], a target endpoint profile is a protection + profile as defined by Common Criteria (analogous to the target + endpoint being the target of evaluation). SACM Task: A SACM task is conducted by one or more SACM functions that reside on a SACM component (e.g. a collection task or endpoint characterization). A SACM task can be triggered by other operations or functions (e.g. a query from another SACM component or an unsolicited push on the data plane due to an ongoing subscription). A task is part of a SACM process chain. A task starts at a given point in time and ends in a deterministic state. With the exception of a collection task, a SACM task consumes SACM statements provided by other SACM components. The output of a @@ -900,30 +954,39 @@ Timestamps : Defined in [RFC4949] as "with respect to a data object, a label or marking in which is recorded the time (time of day or other instant of elapsed time) at which the label or marking was affixed to the data object" and as "with respect to a recorded network event, a data field in which is recorded the time (time of day or other instant of elapsed time) at which the event took place.". This term is used in SACM to describe a recorded point in time at - which, for example, an endpoint attribute is created or updated by - a target endpoint and observed, transmitted or processed by a SACM - component. Timestamps can be created by target endpoints or SACM - components and are associated with endpoint attributes provided or - consumed by SACM components. Outside of the domain of SACM + which, for example, an information element is created or updated + on a target endpoint, and observed, transmitted or processed by a + SACM component. Timestamps can be created by target endpoints or + SACM components and are associated with SACM statements provided + or consumed by SACM components. Outside of the domain of SACM components the assurance of correctness of time stamps is typically significantly lower than inside a SACM domain. In general, it cannot be simply assumed that the source of time a target endpoint uses is synchronized or trustworthy. + Virtual Component: A target endpoint can be composed entirely of + logical system entities (see [RFC4949]. The most common example + is a virtual machine/host running on a target endpoint. + + Effectively, target endpoints can be nested and at the time of + this writing the most common example of target endpoint + characteristics about virtual components is the EntLogicalEntry in + [RFC6933]. + Vulnerability Assessment: The process of determining whether a set of endpoints is vulnerable according to the information contained in the vulnerability description information. Vulnerability Description Information: Information pertaining to the existence of a flaw or flaws in software, hardware, and/or firmware, which could potentially have an adverse impact on enterprise IT functionality and/or security. Vulnerability description information should contain enough information to support vulnerability detection. @@ -939,25 +1002,24 @@ ability to manage endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing vulnerability assessments. Vulnerability assessment capabilities: An enterprise IT department's ability to determine whether a set of endpoints is vulnerable according to the information contained in the vulnerability description information. - Workflow: - - A workflow is a modular composiion of tasks. A workflow can contain - loops, conditionals, multiple starting points and multiple endpoints. - The most promiminant workflow in SACM is the assessment workflow. + Workflow: A workflow is a modular composition of tasks. A workflow + can contain loops, conditionals, multiple starting points and + multiple endpoints. The most prominant workflow in SACM is the + assessment workflow. 3. IANA Considerations This memo includes no request to IANA. 4. Security Considerations This memo documents terminology for security automation. While it is about security, it does not affect security. @@ -1113,32 +1175,42 @@ Capabilities, Vulnerability Detection Data, Vulnerability Assessment Capabilities. o Minor updates to Collection Result, Control Plane, Data in Motion, Data at Rest, Data Origin, Network Interface, Statement, Target Endpoint Label. o Relabeled Endpoint Management Capability, Vulnerability Management Capability, Vulnerability Assessment. - Changes from verion 11 to version 12: + Changes from version 11 to version 12: o Added Configuration, Endpoint Characteristic, Event, SACM Content, State, Subject. - o Major Updates to Asserition, Data in Motion, Data Provenance, Data + o Major Updates to Assertion, Data in Motion, Data Provenance, Data Source, Interaction Model. o Minor Updates to Attribute, Control Plane, Data Origin, Data Provenance, Expected Endpoint State, Guidance, Target Endpoint Classification Task, Vulnerability Detection Data. + Changes from version 12 to version 13: + + o Added Virtual Component. + + o Major Updates to Capability, Collection Task, Hardware Component, + Hardware Type, Security Automation, Subject, Target Endpoint, + Target Endpoint Profile. + + o Minor Updates to Assertion, Data Plane, Endpoint Characteristics. + 7. Contributors David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20877 USA Email: david.waltermire@nist.gov Adam W. Montville @@ -1166,53 +1238,66 @@ Email: bford@lancope.com Merike Kaeo Double Shot Security 3518 Fremont Avenue North, Suite 363 Seattle, WA 98103 USA Email: merike@doubleshotsecurity.com -8. Informative References +8. References +8.1. Normative References + + [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute + (PA) Protocol Compatible with Trusted Network Connect + (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, + . + + [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. + Chandramouli, "Entity MIB (Version 4)", RFC 6933, + DOI 10.17487/RFC6933, May 2013, + . + +8.2. Informative References [I-D.ietf-i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-03 (work in progress), March 2017. + [I-D.ietf-netmod-entity] + Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A + YANG Data Model for Hardware Management", draft-ietf- + netmod-entity-03 (work in progress), March 2017. + [I-D.ietf-sacm-vuln-scenario] Coffin, C., Cheikes, B., Schmidt, C., Haynes, D., Fitzgerald-McKay, J., and D. Waltermire, "SACM Vulnerability Assessment Scenario", draft-ietf-sacm-vuln- scenario-02 (work in progress), September 2016. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, . - [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute - (PA) Protocol Compatible with Trusted Network Connect - (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, - . - [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, . [X.1252] "ITU-T X.1252 (04/2010)", n.d.. Appendix A. The Attic The following terms are stashed for now and will be updated later: