diff --git a/draft-ietf-sacm-information-model.xml b/draft-ietf-sacm-information-model.xml index ce54f8d..c0ff07c 100644 --- a/draft-ietf-sacm-information-model.xml +++ b/draft-ietf-sacm-information-model.xml @@ -9,17 +9,14 @@ - - - @@ -63,7 +60,7 @@ - + - This document defines the information model - for SACM. - + This document defines the information elements that are transported between SACM + components and their interconnected relationships. The primary purpose of the + Secure Automation and Continuous Monitoring (SACM) Information Model is to ensure + the interoperability of corresponding SACM data models and addresses the use cases + defined by SACM. The information elements and corresponding types are maintained + as the IANA "SACM Information Elements" registry. @@ -197,372 +197,541 @@
- - This document defines an information model for endpoint - posture assessment. The scope of the information model - is to describe the mandatory-to-implement information - needs required to realize the assessment of an endpoint - in a scalable and extensible way. The information model - aims to inform the development of specific data models - that support the endpoint posture assessment process. - The terms "information model" and "data model" align with - the definitions in . - - The five primary activities to support this information model are: - Endpoint Identification - Endpoint Characterization - Endpoint Attribute Expression - Guidance Expression - Endpoint Evaluation Result Expression - - - These activities are aimed at the level of the technology that performs operations to - support the collection, communication, and evaluation of endpoint information. - Review of the SACM Use Case usage scenarios - show a common set of business process areas that are critical to understanding - endpoint posture such that appropriate policies, security capabilities, and - decisions can be developed and implemented. - For this information model we have chosen to focus on the following business process - areas: - Endpoint Management - Software Inventory Management - Hardware Inventory Management - Configuration Management - Vulnerability Management - - These management process areas are a way to connect the SACM use cases and building - blocks to the organizational needs such - that the definition of information requirements has a clearly understood - context. For more information, see which maps the SACM information model to the SACM use cases. - - The SACM information model offers a loose coupling between providers and - consumers of security information. A provider can relay what it observes or infers, - without knowing which consumers will use the information, or how they will use it. A - consumer need not know exactly which provider generated a piece of information, or - by what method. - At the same time, a consumer *can* know these things, if necessary. - - As things evolve, a provider can relay supplemental information. Some consumers will - understand and benefit from the supplemental information; other consumers will not - understand and will disregard it. - -
- - SACM requires a large and broad set of mission and business processes, and to make - the most effective use of technology, the same data must support multiple - processes. The activities and processes described within this document tend to build off - of each other to enable more complex characterization and assessment. In an effort - to create an information model that serves a common set of management processes - represented by the usage scenarios in the SACM Use Cases , we have narrowed - down the scope of this model to focus on the - information needs required for endpoint - identification, endpoint characterization, endpoint - attribute expression, guidance expression, and - endpoint evaluation result expression. - - Administrators can't get technology from disparate - sources to work together; they need information to make decisions, but the information - is not available. Everyone is collecting the same data, but storing it as different - information. Administrators therefore need to collect data and craft their own information, - which may not be accurate or interoperable because it's customized by each administrator, not - shared. A standard information model enables - flexibility in collecting, storing, and exchanging - information despite platform differences. - - A way is needed to exchange - information that (a) has breadth, meaning the pieces - of the notation are useful for a - variety of endpoint information, and (b) has longevity, meaning that the - pieces of the notation will stay useful over time. - - When creating standards, it's not sufficient to go - from the requirements directly to the protocol; - the standards must eliminate ambiguity in the information transported. This is - the purpose of information models generally. The SACM problem space is about integrating - many information sources. This information model addresses the need to integrate security - components, support multiple data models, and provide interoperability in a way that is - platform agnostic, scales, and works over time. - - -
- - How to refer to an endpoint is problematic. Ideally, an endpoint would have a - unique identifier. These identifiers would have a one-to-one relationship with - endpoints. Every observation of an endpoint, or inference about an endpoint - would be labeled with its identifier. - - However: - - An external posture attribute collector typically cannot observe the unique - identifier directly. An external posture attribute collector should be able to - report exactly what it has observed, unembellished. It should not have to - *infer* which endpoint it has observed; that inference should be left to - other SACM components. So, SACM cannot require that every observation include - the unique endpoint identifier. - - Internal posture attribute collectors are not present on all endpoints. - They are not present on "dumb" devices such as Internet of Things (IoT) devices, - or on Bring Your Own Device (BYOD) devices. In these cases, *no* observers have - direct access to the unique endpoint identifier. - - An endpoint identifier is generally subject to cloning, when a system image - is cloned. Then, it is no longer unique. - - Suppose the endpoint identifier is highly - clone resistant -- such as a unique certificate within a hardware cryptographic - module. Even so, it is possible to replace all of the software -- for example, - changing a Windows machine to a Linux machine. Is it still the same endpoint? - For SACM purposes, it isn't really the same endpoint. - - - - So SACM components must be able to put disparate observations together and form a - picture of an endpoint -- somewhat like a detective. The SACM information model must - facilitate this. -
- -
- - With many information models, the information is considered certain. - In SACM, information is not certain. - Attackers may develop countermeasures to fool some SACM components. - Attackers may compromise some SACM components. - - So the model must let SACM components and humans reason with - uncertainty. There are no facts, only assertions. - - SACM components must be able to cross check - observations and inferences against each other. - They should be able to give weight if an - observation or inference is corroborated by more - than one method. Although SACM will probably not - prescribe *how* to do this cross checking, SACM - should provide the components with information - that can be used to determine provenance. - - SACM components must be able to consider the - reputation of the observer or inferrer. That - reputation should account for the method of - observing or inferring, the implementer of the - SACM component that made the observation or - inference, and the compliance status of the - endpoint on which the observation or inference - was made. For example, if some observers are - found to be vulnerable to a Day 1 exploit, - observations from those observers deserve less - weight. The details of reputation technology may - be out of scope for SACM. However, again, SACM - should provide components with information that - enables them to make this determination. -
-
+ The SACM Information Model (IM) serves multiple purposes: + + to ensure interoperability between SACM data models that are used as transport + encodings, + to provide a standardized set of information elements - the SACM Vocabulary - + to enable the exchange of content vital to automated security posture assessment, + and + to enable secure information sharing in a scalable and extensible fashion in + order to support the tasks conducted by SACM components. + + + + A complete set of requirements imposed on the IM can be + found in . The + SACM IM is intended to be used for standardized data exchange between SACM components + (data in motion). Nevertheless, the information elements (IE) and their relationships + defined in this document can be leveraged to create and align corresponding data models + for data at rest. + + The information model expresses, for example, target + endpoint (TE) attributes, guidance, + and evaluation results. The corresponding information elements are consumed and + produced by SACM components as they carry out tasks. + + The primary tasks that this information model supports (on data, control, and management + plane) are: + + TE Discovery + TE Characterization + TE Classification + Collection + Evaluation + Information Sharing + SACM Component Discovery + SACM Component Authentication + SACM Component Authorization + SACM Component Registration + + + These tasks are defined in .
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", - "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be - interpreted as described in RFC 2119. -
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be + interpreted as described in RFC 2119. +
+
+ The notation used to define the SACM Information + Elements (IEs) is based on a customized version of + the IPFIX information model syntax which is described in and . However, there are + several examples presented throughout the document that use a simplified + pseudo-code to illustrate the basic structure. It should be noted that while + they include actual names of subjects and attributes as well as values, they + are not intended to influence how corresponding SACM IEs should be defined + in . The examples are provided for + demonstration purposes only.
+ + +
+ The IEs defined in this document comprise the building blocks by which all SACM + content is composed. They are consumed and provided by SACM components on the data + plane. Every information element has a unique label: its name. Every type of IE + defined by the SACM IM is registered as a type at the IANA registry. The Integer + Index of the IANA SMI number tables can be used by SACM data models. +
+ The IEs in this information model represent information related to the following + areas (based on the use cases described in ): + + Endpoint Management + Software Inventory Management + Hardware Inventory Management + Configuration Management + Vulnerability Management + + +
+
+ A SACM data model based on this information model MAY include additional information + elements that are not defined here. The labels of additional information elements + included in different SACM data models MUST NOT conflict with the labels of the + information elements defined by this information model, and the names of additional + information elements MUST NOT conflict with each other or across multiple data models. + In order to avoid naming conflicts, the labels of additional IEs SHOULD be prefixed + to avoid collisions across extensions. The prefix MUST include an organizational + identifier and therefore, for example, MAY be an IANA enterprise number, a (partial) + name space URI, or an organization name abbreviation. + +
+
-
- The SACM information model is structured around a core - framework that can be easily extended to support the - modeling needs for endpoint posture assessment. This - section describes the key concepts that make up this - framework as well as the IP Information Flow Export - (IPFIX) Information Model - syntax used to model the different information model - concepts. +
+ There are two basic types of IEs: + + Attributes: an instance of an attribute type is the simplest IE structure comprised + of a unique attribute name and an attribute value. + Subjects: a subject is a richer structure that has a unique subject name and one + or more attributes or subjects. In essence, instances of a subject type are defined + (and differentiated) by the attribute values and subjects associated with it. + + + +
+ + hostname = "arbutus" + + coordinates = ( + latitude = N27.99619, + longitude = E86.92761 + ) + +
+ + In general, every piece of information that enables security posture assessment or + further enriches the quality of the assessment process can be associated with metadata. + In the SACM IM, metadata is represented by specific subjects and is bundled with other + attributes or subjects to provide additional information about them. The IM explicitly + defines two kinds of metadata: + + Metadata focusing on the data origin (the SACM component that provides the + information to the SACM domain) + Metadata focusing on the data source (the target endpoint that is assessed) + + Metadata can also include relationships that refer to other associated IEs (or SACM + content in general) by using referencing labels that have to be included in the metadata + of the associated IE. + + Subjects can be nested and the SACM IM allows for circular or recursive nesting. The + association of IEs via nesting results in a tree-like structure wherein subjects compose + the root and intermediary nodes and attributes the leaves of the tree. This semantic + structure does not impose a specific structure on SACM data models regarding data in + motion or data repository schemata for data at rest. + + The SACM IM provides two top-level subjects that are used to ensure a homogeneous + structure for SACM content and its associated metadata: SACM statements and SACM + content-elements. Every set of IEs that is provided by a SACM component in order to be + consumed by another SACM component uses these top-level + subjects. -
- Attributes are used to model specific endpoint - information. At a minimum, an attribute must have a name - and a value. Additional information about attributes can - be modeled using metadata as described in . -
- Attributes must be defined using the IPFIX Information - Element Specification Template as described in Section - 2.1 of . The following is a - modified version of the template for Information - Elements provided in Section 9.1 of . + The notation the SACM IM is defined in is based on the IP Information Flow Export + (IPFIX) Information Model syntax described in . The customized syntax used by the + SACM IM is defined below in and . + +
+ Attributes must be defined using the IPFIX Information + Element Specification Template as described in Section + 2.1 of . The following is a + modified version of the template for Information + Elements provided in Section 9.1 of . +
+ + elementId: Element identifier goes here + if known, or "TBD" if it will + be assigned by IANA and filled + in at publication time.; + obligatory + + name: Name goes here.; obligatory + + dataType: Data type goes here; + obligatory + + status: Status goes here; obligatory + + description: Description goes here.; + obligatory + + For Information Elements that + represent flags, please + include a table that lists + each flag value (hexadecimal) + and description. The following + is a template for that table. + + +-------+----------------------------------+ + | Value | Description | + +-------+----------------------------------+ + | | | + +-------+----------------------------------+ + + dataTypeSemantics: Data type semantics, if any, + go here; optional + + units: Units, if any, go here; + optional + + range: Range, if not implied by the + data type, goes here; optional + + references: References to other RFCs or + documents outside the IETF, + in which additional + information is given, or which + are referenced by the + description, go here; optional + +
+
+ +
+ Subjects are complex Information Elements that can + be created using one of the following IPFIX constructs + that are defined in Section 3.1 of . ***TODO: UPDATE WITH REVISED + IPFIX-LIKE CONSTRUCTS*** + + basicList: a list of zero or more instances of + any Information Element + subTemplateList: a list of zero or more + instances of a single, specific Template + subTemplateMultiList: a list of zero or more + instances of any Template + + The following is a modified version of the template + for Information Elements provided in Section 9.1 of + that can be used to model + subjects.
+ title="Subject Information Element Specification Template" + anchor="Subject-Information-Element-Specification-Template"> -elementId: Element identifier goes here if known, or - "TBD" if it will be assigned by IANA and - filled in at publication time.; obligatory - -name: Name goes here.; obligatory - -dataType: Data type goes here; obligatory - -status: Status goes here; obligatory - -description: Description goes here.; obligatory - - For Information Elements that - represent flags, please include a - table that lists each flag value - (hexadecimal) and description. - The following is a template for that - table. - - +-------+----------------------------------+ - | Value | Description | - +-------+----------------------------------+ - | | | - +-------+----------------------------------+ - -dataTypeSemantics: Data type semantics, if any, go here; optional - -units: Units, if any, go here; optional - -range: Range, if not implied by the data type, goes - here; optional - -references: References to other RFCs or documents outside - the IETF, in which additional information is - given, or which are referenced by the - description, go here; optional + elementId: Element identifier goes here + if known, or "TBD" if it + will be assigned by IANA and + filled in at publication + time.; obligatory + + name: Name goes here.; obligatory + + dataType: Data type goes here; + obligatory + + status: Status goes here; obligatory + + description: Description goes here.; + obligatory + + Please include a high-level + model diagram that uses + the following format which + is a simplified version + of a high-level diagram + format used in [RFC6313]. + + <IE-Name> = + (<IE-DataType>, + <IE-DataTypeSemantic>, + <IE-1>, + <IE-2>, + <IE-3>, + ... + ) + + dataTypeSemantics: Data type semantics, if any, + go here; optional + + units: Units, if any, go here; + optional + + range: Range, if not implied by + the data type, goes + here; optional + + references: References to other RFCs or + documents outside the IETF, + in which additional + information is given, or + which are referenced by the + description, go here; + optional
-
+
-
- Objects are the mechanism by which attributes - () and/or other objects - can be logically grouped together to create more - complex models. Additional information about objects - can be modeled using metadata as described in - . -
- Objects are complex Information Elements that can - be created using one of the following IPFIX constructs - that are defined in Section 3.1 of . - - basicList: a list of zero or more instances of - any Information Element - subTemplateList: a list of zero or more - instances of a single, specific Template - subTemplateMultiList: a list of zero or more - instances of any Template - - The following is a modified version of the template - for Information Elements provided in Section 9.1 of - that can be used to model - objects. -
- -elementId: Element identifier goes here if known, or - "TBD" if it will be assigned by IANA and - filled in at publication time.; obligatory - -name: Name goes here.; obligatory - -dataType: Data type goes here; obligatory - -status: Status goes here; obligatory - -description: Description goes here.; obligatory - - Please include a high-level model diagram that uses - the following format which is a simplified version - of a high-level diagram format used in [RFC6313]. - - <IE-Name> = (<IE-DataType>, <IE-DataTypeSemantic>, - <IE-1>, - <IE-2>, - <IE-3>, - ... - ) - - dataTypeSemantics: Data type semantics, if any, go here; optional - - units: Units, if any, go here; optional - - range: Range, if not implied by the data type, goes - here; optional - - references: References to other RFCs or documents outside - the IETF, in which additional information is - given, or which are referenced by the - description, go here; optional - -
- -
+
+ Every piece of information that is provided by a SACM component is always associated + with a set of metadata, for example, the timestamp at which this set of information + was produced (e.g. by a collection task) or what target endpoint this set of + information is about (e.g. the data-source or a target endpoint identifier, respectively). + The subject that associates content IE with content-metadata IE is called a + content-element. Content metadata can also include relationships that express associations + with other content-elements. + +
+ + content-element = ( + content-metadata = ( + collection-timestamp = 146193322, + data-source = fb02e551-7101-4e68-8dec-1fde6bd10981 + ), + hostname = "arbutus", + coordinates = ( + latitude = N27.99619, + longitude = E86.92761 + ) + ) + +
-
- Metadata allows components to annotate objects and - attributes with additional information that will allow - other components to make a determination about the provenance - of the objects and attributes during exchanges and - evaluations. - +
+ One or more SACM content elements are bundled in a SACM statement. In contrast to + content-metadata, statement-metatdata focuses on the providing SACM component instead of the + target endpoint that the content is about. The only content-specific metadata included in + the SACM statement is the content-type IE. Therefore, multiple content-elements that share + the same statement metadata and are of the same content-type can be included in a single + SACM statement. A SACM statement functions similar to an envelope or a header. Its purpose + is to enable the tracking of the origin of data inside a SACM domain and more importantly + to enable the mitigation of conflicting information that my originate from different SACM + components. How a consuming SACM component actually deals with conflicting information is + out-of-scope of the SACM IM. Semantically, the term statement implies that the SACM content + provided by a SACM component might not be correct in every context, but rather is the result + of an best-effort to produce correct information. + +
+ + sacm-statement = ( + statement-metadata = ( + publish-timestamp = 1461934031, + data-origin = 24e67957-3d31-4878-8892-da2b35e121c2, + content-type = observation + ), + content-element = ( + content-metadata = ( + collection-timestamp = 146193322, + data-source = fb02e551-7101-4e68-8dec-1fde6bd10981 + ), + hostname = "arbutus" + ) + ) + +
+ +
+ + sacm-statement = ( + statement-metadata = ( + publish-timestamp = 1461934031, + data-origin = 24e67957-3d31-4878-8892-da2b35e121c2 + content-type = observation + ), + content-element = ( + content-metadata = ( + collection-timestamp = 146193322, + data-source = fb02e551-7101-4e68-8dec-1fde6bd10981 + ), + coordinates = ( + latitude = N27.99619, + longitude = E86.92761 + ) + ) + ) + + sacm-statement = ( + statement-metadata = ( + publish-timestamp = 1461934744, + data-origin = e42885a1-0270-44e9-bb5c-865cf6bd4800, + content-type = observation + ), + content-element = ( + content-metadata = ( + collection-timestamp = 146193821, + te-label = fb02e551-7101-4e68-8dec-1fde6bd10981 + ), + coordinates = ( + latitude = N16.67622, + longitude = E141.55321 + ) + ) + ) + +
+
+ +
+ An IE can be associated with another IE, e.g. a user-name attribute + can be associated with a content-authorization subject. These + references are expressed via the relationships subject, which can be + included in a corresponding content-metadata subject. The + relationships subject includes a list of one or more references. The + SACM IM does not enforce a SACM domain to use unique identifiers as + references. Therefore, there are at least two ways to reference another + content-element: + + The value of a reference represents a specific content-label that + is unique in a SACM domain (and has to be included in the + corresponding content-element metadata in order to be referenced), + or + The reference is a subject that includes an appropriate number + of IEs in order to identify the referenced content-element by its + actual content. + + + It is recommended to provide unique identifiers in a SACM domain and + the SACM IM provides a corresponding naming-convention as a reference + in section FIXME. The alternative highlighted above summarizes a valid + approach that does not require unique identifiers and is similar to the + approach of referencing target endpoints via identifying attributes + included in a characterization record (FIXME REF arch). + +
+ + content-element = ( + content-metadata = ( + collection-timestamp = 1461934031, + te-label = + fb02e551-7101-4e68-8dec-1fde6bd10981 + relationships = ( + associated-with-user-account = + f3d70ef4-7e18-42af-a894-8955ba87c95d + ) + ), + hostname = "arbutus" + ) + + content-element = ( + content-metadata = ( + content-label = f3d70ef4-7e18-42af-a894-8955ba87c95d + ), + user-account = ( + username = romeo + authentication = local + ) + ) + +
+
+ +
+ Event subjects provide a structure to represent the change + of IE values that was detected by a collection task at a + specific point of time. It is mandatory to include the new + values and the collection timestamp in an event subject and it is recommended to include + the past values and a collection timestamp that were replaced by the new IE values. + Every event can also be associated with a subject-specific + event-timestamp and a lastseen-timestamp that might differ + from the corresponding collection-timestamps. If these are + omitted the collection-timestamp that is included in the + content-metadata subject is used instead. + +
+ + sacm-statement = ( + statement-metadata = ( + publish-timestamp = 1461934031, + data-origin = 24e67957-3d31-4878-8892-da2b35e121c2, + content-type = event + ), + event = ( + event-attributes = ( + event-name = "host-name change", + content-element = ( + content-metadata = ( + collection-timestamp = 146193322, + data-source = + fb02e551-7101-4e68-8dec-1fde6bd10981, + event-component = past-state + ), + hostname = "arbutus" + ), + content-element = ( + content-metadata = ( + collection-timestamp = 146195723, + data-source = + fb02e551-7101-4e68-8dec-1fde6bd10981, + event-component = current-state + ), + hostname = "lilac" + ) + ) + ) + +
+
+ +
+ Categories are special IEs that enable to refer to multiple + types of IE via just one name. Therefore, they are similar + to a type-choice. A prominent example of a category is + network-address. Network-address is a category that every + kind of network address is associated with, e.g. mac-address, + ipv4-address, ipv6-address, or typed-network-address. If a + subject includes network-address as one of its components, + any of the category members are valid to be used in its place. + + Another prominent example is EndpointIdentifier. Some IEs + can be used to identify (and over time re-recognize) target + endpoints - those are associated with the category endpoint-identifier. + +
+ +
+ TODO: In the IETF, there are privacy concerns with respect to endpoint identity and monitoring. As a result, the + Endpoint ID Design Team proposes that "endpoint identity" be changed to "endpoint designation". Designation + attributes can be used to correlate endpoints, information about endpoints, events, etc. NOTE: Designation + attributes are just those that are mandatory-to-implement. In practice, organizations may need to select additional + attributes beyond the mandatory-to-implement attributes to successfully identify an endpoint on their network. Operational + and privacy concerns will be covered in Operational Considerations and Privacy Considerations sections respectively. + + A proposal outlining various options for + representing designation attributes/objects in the IPFIX syntax is being + discussed on the mailing list. See IM issue #39 at + https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39 + for more information. + +
+ +
+ TODO: In the IETF, there are privacy concerns with respect to endpoint identity and monitoring. As a result, it was proposed that a + privacy property be included to denote when a information element represents a privacy concern. + A proposal outlining various options for - representing metadata attributes/objects in the IPFIX syntax is being - discussed on the mailing list. TODO: See IM issue #39 at + representing privacy attributes/objects in the IPFIX syntax is being + discussed on the mailing list. See IM issue #39 at https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39 for more information.
- -
- TODO: Define what a relationship is. At the end of the day, we want to be able to describe the - relationships between assets, endpoints, and attributes. QUESTION: Are relationships just metadata? - Lisa's notes have some information on relationships: https://mailarchive.ietf.org/arch/msg/sacm/kWxlnboHAXD87cned9WavwPZy5w. - We also want to consider the relationships proposed by Nancy and Henk in - https://www.ietf.org/proceedings/94/slides/slides-94-sacm-7.pdf. - Nancy and Henk expect to provide additional information related to their Information Model work - that can be merged into this document at some point. - The information is expected to be ready in advance of - IETF 95. Please see issue #39 at - https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39 - for more information. -
- -
- TODO: In the IETF, there are privacy concerns with respect to endpoint identity and monitoring. As a result, the - Endpoint ID Design Team proposes that "endpoint identity" be changed to "endpoint designation". Designation - attributes can be used to correlate endpoints, information about endpoints, events, etc. NOTE: Designation - attributes are just those that are mandatory-to-implement. In practice, organizations may need to select additional - attributes beyond the mandatory-to-implement attributes to successfully identify an endpoint on their network. Operational - and privacy concerns will be covered in Operational Considerations and Privacy Considerations sections respectively. - - A proposal outlining various options for - representing designation attributes/objects in the IPFIX syntax is being - discussed on the mailing list. See IM issue #39 at - https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39 - for more information. - -
- -
- TODO: In the IETF, there are privacy concerns with respect to endpoint identity and monitoring. As a result, it was proposed that a - privacy property be included to denote when a information element represents a privacy concern. - A proposal outlining various options for - representing privacy attributes/objects in the IPFIX syntax is being - discussed on the mailing list. See IM issue #39 at - https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39 - for more information. - -
-
This section describes the abstract data types that can be used for the specification of the SACM @@ -931,14 +1100,14 @@ description: Description goes here.; obligatory of what we have been saying endpoint identity (now designation).
-
+
TODO: Define the relationships between assets (endpoints, hardware, software, etc.). These will depicted in the overview diagram.
- TODO: Define specific containers, attributes, and metadata. We may want to consider + TODO: Define specific subjects, attributes, and metadata. We may want to consider adding small diagrams showing the relationships between each (see Lisa's notes: https://mailarchive.ietf.org/arch/msg/sacm/kWxlnboHAXD87cned9WavwPZy5w). This may be too much work, but, not sure yet. @@ -1066,8 +1235,10 @@ description: Description goes here.; obligatory for two purposes: To tell whether two endpoint attribute assertions concern the same endpoint - (This is not simple, - as explains.) + To respond to compliance measurements, for example by reporting, remediating, and quarantining (SACM does not specify these responses, @@ -1482,7 +1653,7 @@ description: Description goes here.; obligatory
- TODO: Integrate into the as appropriate. + TODO: Integrate into the as appropriate.
An endpoint attribute assertion has: @@ -1535,19 +1706,7 @@ description: Description goes here.; obligatory
-
- - An event is represented as a Posture Attribute Assertion - whose time interval has length zero. - - Some potential kinds of events are: - A structured syslog message - IF-MAP event metadata - A NetFlow message - -
- +
Author: Henk Birkholz @@ -1574,7 +1733,7 @@ description: Description goes here.; obligatory
- TODO: Integrate into the as appropriate. + TODO: Integrate into the as appropriate. The set of attribute types must be extensible, by other IETF standards, by other standards groups, and by vendors. How to express attribute types is not defined here, but is left to data models. The value may be structured. For example, it may something like XML. @@ -1645,62 +1804,6 @@ description: Description goes here.; obligatory an Evaluation Result. These mechanics are out of the scope of the Information Model.
-
- Although SACM components are mainly covered by the SACM architecture, we have some remarks. TODO: Move them to the architecture document? - - ISSUE (CEK): Why do we need information elements that model SACM compoments? - -
- - An external collector is a collector - that observes endpoints from - outside. [kkw-many of these [collectors] are - actually configured and operated to manage assets for reasons other - than posture assessments. it is critical to bring them into this, so - i like it...but does it matter if the [collector] isn't intended to support - posture assessment, but happens to have information that can be - used by posture assessment collection consumers? do we lump them - together with collectors that are intended to support posture - assessment but run external to the endpoint?] - [jmf: ditto. The exampled below are of things that would perform external collection]. - - - [cek-to kkw's comment, I think the purpose here is to capture their - contribution to continuous monitoring. I don't see the need to separate - things whose primary job is monitoring from things whose primary job is - something else. Is there a need?] - [cek-to jmf's comment, that is what they are examples of; is a text - change needed?] - - Examples: - - A RADIUS server whereby an endpoint has logged onto the - network - A network profiling system, which discovers and classifies - network nodes - A Network Intrusion Detection System (NIDS) sensor - A vulnerability scanner - A hypervisor that peeks into the endpoint, the endpoint being a - virtual machine - A management system that configures and installs software on the - endpoint - -
- -
- An evaluator can consume - endpoint attribute assertions, previous evaluations of posture attributes, - or previous reports of evaluation results. [kkw-i don't think this - conflicts with the definition in the terminology doc re: that - evaluation tasks evaluate posture attributes.] - [cek-I like the change. I think it *does* require a change in the terminology doc, though.] - - Example: a NEA posture validator - [jmf- a NEA posture validator is not an example of this definition. A NEA posture assessment is, maybe?] - [cek-Why isn't a NEA posture validator an example?] -
-
-
[kkw-from a reporting standpoint there needs to be some concept like organization or system. without this, there is no @@ -1844,11 +1947,11 @@ the same.
elementId: TBD -name: hardwareSerialNumber +name: hardwareSerialNumber dataType: string dataTypeSemantics: default status: current -description: A globally unique identifier for a particular +description: A globally unique identifier for a particular piece of hardware assigned by the vendor.
@@ -1857,12 +1960,12 @@ description: A globally unique identifier for a particular
elementId: TBD -name: interfaceName +name: interfaceName dataType: string dataTypeSemantics: default status: current -description: A short name uniquely describing an interface, - eg "Eth1/0". See [RFC2863] for the definition +description: A short name uniquely describing an interface, + eg "Eth1/0". See [RFC2863] for the definition of the ifName object.
@@ -1874,13 +1977,13 @@ elementId: TBD name: interfaceIndex dataType: unsigned32 dataTypeSemantics: identifier -status: current -description: The index of an interface installed on an endpoint. - The value matches the value of managed object - 'ifIndex' as defined in [RFC2863]. Note that ifIndex - values are not assigned statically to an interface - and that the interfaces may be renumbered every time - the device's management system is re-initialized, +status: current +description: The index of an interface installed on an endpoint. + The value matches the value of managed object + 'ifIndex' as defined in [RFC2863]. Note that ifIndex + values are not assigned statically to an interface + and that the interfaces may be renumbered every time + the device's management system is re-initialized, as specified in [RFC2863]. @@ -1893,7 +1996,7 @@ name: interfaceMacAddress dataType: macAddress dataTypeSemantics: default status: current -description: The IEEE 802 MAC address associated with a network +description: The IEEE 802 MAC address associated with a network interface on an endpoint. @@ -1980,7 +2083,7 @@ description: Information about a network interface
elementId: TBD -name: softwareIdentifier +name: softwareIdentifier dataType: string dataTypeSemantics: default status: current @@ -2118,7 +2221,7 @@ description: Information about an instance of software
elementId: TBD -name: globallyUniqueIdentifier +name: globallyUniqueIdentifier dataType: unsigned8 dataTypeSemantics: identifier status: current @@ -2131,7 +2234,7 @@ description: TODO.
elementId: TBD -name: dataOrigin +name: dataOrigin dataType: string dataTypeSemantics: default status: current @@ -2146,7 +2249,7 @@ description: The origin of the data. TODO make a better
elementId: TBD -name: dataSource +name: dataSource dataType: string dataTypeSemantics: default status: current @@ -2161,7 +2264,7 @@ description: The source of the data. TODO make a better
elementId: TBD -name: creationTimestamp +name: creationTimestamp dataType: dateTimeSeconds dataTypeSemantics: default status: current @@ -2175,7 +2278,7 @@ description: The date and time when the posture
elementId: TBD -name: collectionTimestamp +name: collectionTimestamp dataType: dateTimeSeconds dataTypeSemantics: default status: current @@ -2190,7 +2293,7 @@ description: The date and time when the posture
elementId: TBD -name: publicationTimestamp +name: publicationTimestamp dataType: dateTimeSeconds dataTypeSemantics: default status: current @@ -2204,7 +2307,7 @@ description: The date and time when the posture
elementId: TBD -name: relayTimestamp +name: relayTimestamp dataType: dateTimeSeconds dataTypeSemantics: default status: current @@ -2218,7 +2321,7 @@ description: The date and time when the posture
elementId: TBD -name: storageTimestamp +name: storageTimestamp dataType: dateTimeSeconds dataTypeSemantics: default status: current @@ -2232,14 +2335,14 @@ description: The date and time when the posture
elementId: TBD -name: type +name: type dataType: unsigned16 dataTypeSemantics: flags status: current metadata: true description: The type of data model use to represent - some set of endpoint information. The following table - lists the set of data models supported by SACM. + some set of endpoint information. The following + table lists the set of data models supported by SACM. +-------+----------------------------------+ | Value | Description | @@ -2259,97 +2362,99 @@ description: The type of data model use to represent
elementId: TBD -name: protocolIdentifier +name: protocolIdentifier dataType: unsigned8 dataTypeSemantics: identifier status: current -description: The value of the protocol number in the IP packet header. - The protocol number identifies the IP packet payload type. - Protocol numbers are defined in the IANA Protocol Numbers - registry. +description: The value of the protocol number in the IP packet + header. The protocol number identifies the IP packet + payload type. Protocol numbers are defined in the + IANA Protocol Numbers registry. - In Internet Protocol version 4 (IPv4), this is carried in the - Protocol field. In Internet Protocol version 6 (IPv6), this - is carried in the Next Header field in the last extension - header of the packet. + In Internet Protocol version 4 (IPv4), this is + carried in the Protocol field. In Internet Protocol + version 6 (IPv6), this is carried in the Next Header + field in the last extension header of the packet.
elementId: TBD -name: sourceTransportPort +name: sourceTransportPort dataType: unsigned16 dataTypeSemantics: identifier status: current description: The source port identifier in the transport header. - For the transport protocols UDP, TCP, and SCTP, this is the - source port number given in the respective header. This - field MAY also be used for future transport protocols that - have 16-bit source port identifiers. + For the transport protocols UDP, TCP, and SCTP, this + is the source port number given in the respective + header. This field MAY also be used for future + transport protocols that have 16-bit source port + identifiers.
elementId: TBD -name: sourceIPv4PrefixLength +name: sourceIPv4PrefixLength dataType: unsigned8 dataTypeSemantics: status: current -description: The number of contiguous bits that are relevant in the - sourceIPv4Prefix Information Element. +description: The number of contiguous bits that are relevant in + the sourceIPv4Prefix Information Element.
elementId: TBD -name: ingressInterface +name: ingressInterface dataType: unsigned32 dataTypeSemantics: identifier status: current -description: The index of the IP interface where packets of this Flow - are being received. The value matches the value of managed - object 'ifIndex' as defined in [RFC2863]. - Note that ifIndex values are not assigned statically to an - interface and that the interfaces may be renumbered every - time the device's management system is re-initialized, as - specified in [RFC2863]. +description: The index of the IP interface where packets of this + Flow are being received. The value matches the + value of managed object 'ifIndex' as defined in + [RFC2863]. Note that ifIndex values are not assigned + statically to an interface and that the interfaces + may be renumbered every time the device's management + system is re-initialized, as specified in [RFC2863].
elementId: TBD -name: destinationTransportPort +name: destinationTransportPort dataType: unsigned16 dataTypeSemantics: identifier status: current -description: The destination port identifier in the transport header. - For the transport protocols UDP, TCP, and SCTP, this is the - destination port number given in the respective header. - This field MAY also be used for future transport protocols - that have 16-bit destination port identifiers. +description: The destination port identifier in the transport + header. For the transport protocols UDP, TCP, and + SCTP, this is the destination port number given in + the respective header. This field MAY also be used + for future transport protocols that have 16-bit + destination port identifiers.
elementId: TBD -name: sourceIPv6PrefixLength +name: sourceIPv6PrefixLength dataType: unsigned8 dataTypeSemantics: status: current -description: The number of contiguous bits that are relevant in the - sourceIPv6Prefix Information Element. +description: The number of contiguous bits that are relevant in + the sourceIPv6Prefix Information Element.
elementId: TBD -name: sourceIPv4Prefix +name: sourceIPv4Prefix dataType: ipv4Address dataTypeSemantics: default status: current @@ -2360,7 +2465,7 @@ description: IPv4 source address prefix.
elementId: TBD -name: destinationIPv4Prefix +name: destinationIPv4Prefix dataType: ipv4Address dataTypeSemantics: default status: current @@ -2371,7 +2476,7 @@ description: IPv4 destination address prefix.
elementId: TBD -name: sourceMacAddress +name: sourceMacAddress dataType: macAddress dataTypeSemantics: default status: current @@ -2382,7 +2487,7 @@ description: The IEEE 802 source MAC address field.
elementId: TBD -name: ipVersion +name: ipVersion dataType: unsigned8 dataTypeSemantics: identifier status: current @@ -2393,22 +2498,24 @@ description: The IP version field in the IP packet header.
elementId: TBD -name: interfaceName +name: interfaceName dataType: string dataTypeSemantics: default status: current -description: A short name uniquely describing an interface, eg "Eth1/0". +description: A short name uniquely describing an interface, + eg "Eth1/0".
elementId: TBD -name: interfaceDescription +name: interfaceDescription dataType: string dataTypeSemantics: default status: current -description: The description of an interface, eg "FastEthernet 1/0" or "ISP +description: The description of an interface, eg "FastEthernet + 1/0" or "ISP connection".
@@ -2416,7 +2523,7 @@ connection".
elementId: TBD -name: applicationDescription +name: applicationDescription dataType: string dataTypeSemantics: default status: current @@ -2427,7 +2534,7 @@ description: Specifies the description of an application.
elementId: TBD -name: applicationId +name: applicationId dataType: octetArray dataTypeSemantics: default status: current @@ -2438,7 +2545,7 @@ description: Specifies an Application ID per [RFC6759].
elementId: TBD -name: applicationName +name: applicationName dataType: string dataTypeSemantics: default status: current @@ -2449,133 +2556,137 @@ description: Specifies the name of an application.
elementId: TBD -name: exporterIPv4Address +name: exporterIPv4Address dataType: ipv4Address dataTypeSemantics: default status: current -description: The IPv4 address used by the Exporting Process. This is used - by the Collector to identify the Exporter in cases where the - identity of the Exporter may have been obscured by the use of - a proxy. +description: The IPv4 address used by the Exporting Process. + This is used by the Collector to identify the + Exporter in cases where the identity of the Exporter + may have been obscured by the use of a proxy.
elementId: TBD -name: exporterIPv6Address +name: exporterIPv6Address dataType: ipv6Address dataTypeSemantics: default status: current -description: The IPv6 address used by the Exporting Process. This is used - by the Collector to identify the Exporter in cases where the - identity of the Exporter may have been obscured by the use of - a proxy. +description: The IPv6 address used by the Exporting Process. + This is used by the Collector to identify the + Exporter in cases where the identity of the + Exporter may have been obscured by the use of a + proxy.
elementId: TBD -name: portId +name: portId dataType: unsigned32 dataTypeSemantics: identifier status: current -description: An identifier of a line port that is unique per IPFIX - Device hosting an Observation Point. Typically, this - Information Element is used for limiting the scope - of other Information Elements. +description: An identifier of a line port that is unique per + IPFIX Device hosting an Observation Point. + Typically, this Information Element is used for + limiting the scope of other Information Elements.
elementId: TBD -name: templateId +name: templateId dataType: unsigned16 dataTypeSemantics: identifier status: current -description: An identifier of a Template that is locally unique within a - combination of a Transport session and an Observation Domain. +description: An identifier of a Template that is locally unique + within a combination of a Transport session and an + Observation Domain. - Template IDs 0-255 are reserved for Template Sets, Options - Template Sets, and other reserved Sets yet to be created. - Template IDs of Data Sets are numbered from 256 to 65535. + Template IDs 0-255 are reserved for Template Sets, + Options Template Sets, and other reserved Sets yet + to be created. Template IDs of Data Sets are + numbered from 256 to 65535. - Typically, this Information Element is used for limiting - the scope of other Information Elements. - Note that after a re-start of the Exporting Process Template - identifiers may be re-assigned. + Typically, this Information Element is used for + limiting the scope of other Information Elements. + Note that after a re-start of the Exporting Process + Template identifiers may be re-assigned.
elementId: TBD -name: collectorIPv4Address +name: collectorIPv4Address dataType: ipv4Address dataTypeSemantics: default status: current -description: An IPv4 address to which the Exporting Process sends Flow - information. +description: An IPv4 address to which the Exporting Process sends + Flow information.
elementId: TBD -name: collectorIPv6Address +name: collectorIPv6Address dataType: ipv6Address dataTypeSemantics: default status: current -description: An IPv6 address to which the Exporting Process sends Flow - information. +description: An IPv6 address to which the Exporting Process sends + Flow information.
elementId: TBD -name: informationElementIndex +name: informationElementIndex dataType: unsigned16 dataTypeSemantics: identifier status: current description: A zero-based index of an Information Element - referenced by informationElementId within a Template referenced by - templateId; used to disambiguate scope for templates containing - multiple identical Information Elements. + referenced by informationElementId within a Template + referenced by templateId; used to disambiguate + scope for templates containing multiple identical + Information Elements.
elementId: TBD -name: basicList +name: basicList dataType: basicList dataTypeSemantics: list status: current -description: Specifies a generic Information Element with a basicList abstract - data type. For example, a list of port numbers, a list of - interface indexes, etc. +description: Specifies a generic Information Element with a + basicList abstract data type. For example, a list + of port numbers, a list of interface indexes, etc.
elementId: TBD -name: subTemplateList +name: subTemplateList dataType: subTemplateList dataTypeSemantics: list status: current -description: Specifies a generic Information Element with a subTemplateList - abstract data type. +description: Specifies a generic Information Element with a + subTemplateList abstract data type.
elementId: TBD -name: subTemplateMultiList +name: subTemplateMultiList dataType: subTemplateMultiList dataTypeSemantics: list status: current @@ -2587,76 +2698,82 @@ description: Specifies a generic Information Element with a
elementId: TBD -name: informationElementId +name: informationElementId dataType: unsigned16 dataTypeSemantics: identifier status: current -description: This Information Element contains the ID of another Information - Element. +description: This Information Element contains the ID of another + Information Element.
elementId: TBD -name: informationElementDataType +name: informationElementDataType dataType: unsigned8 dataTypeSemantics: status: current description: A description of the abstract data type of an IPFIX - information element.These are taken from the abstract data types - defined in section 3.1 of the IPFIX Information Model [RFC5102]; - see that section for more information on the types described - in the informationElementDataType sub-registry. + information element.These are taken from the + abstract data types defined in section 3.1 of the + IPFIX Information Model [RFC5102]; see that section + for more information on the types described in the + informationElementDataType sub-registry. - These types are registered in the IANA IPFIX Information Element - Data Type subregistry. This subregistry is intended to assign - numbers for type names, not to provide a mechanism for adding data - types to the IPFIX Protocol, and as such requires a Standards - Action [RFC5226] to modify. + These types are registered in the IANA IPFIX + Information Element Data Type subregistry. This + subregistry is intended to assign numbers for type + names, not to provide a mechanism for adding data + types to the IPFIX Protocol, and as such requires a + Standards Action [RFC5226] to modify.
elementId: TBD -name: informationElementDescription +name: informationElementDescription dataType: string dataTypeSemantics: default status: current -description: A UTF-8 [RFC3629] encoded Unicode string containing a - human-readable description of an Information Element. The content - of the informationElementDescription MAY be annotated with one or - more language tags [RFC4646], encoded in-line [RFC2482] within the - UTF-8 string, in order to specify the language in which the - description is written. Description text in multiple languages - MAY tag each section with its own language tag; in this case, the - description information in each language SHOULD have equivalent - meaning. In the absence of any language tag, the "i-default" - [RFC2277] language SHOULD be assumed. See the Security - Considerations section for notes on string handling for - Information Element type records. +description: A UTF-8 [RFC3629] encoded Unicode string containing + a human-readable description of an Information + Element. The content of the + informationElementDescription MAY be annotated with + one or more language tags [RFC4646], encoded + in-line [RFC2482] within the UTF-8 string, in order + to specify the language in which the description is + written. Description text in multiple languages MAY + tag each section with its own language tag; in this + case, the description information in each language + SHOULD have equivalent meaning. In the absence of + any language tag, the "i-default" [RFC2277] language + SHOULD be assumed. See the Security Considerations + section for notes on string handling for Information + Element type records.
elementId: TBD -name: informationElementName +name: informationElementName dataType: string dataTypeSemantics: default status: current description: A UTF-8 [RFC3629] encoded Unicode string containing - the name of an Information Element, intended as a simple - identifier. See the Security Considerations section for notes on - string handling for Information Element type records. + the name of an Information Element, intended as a + simple identifier. See the Security Considerations + section for notes on string handling for Information + Element type records.
elementId: TBD -name: informationElementRangeBegin +name: informationElementRangeBegin dataType: unsigned64 dataTypeSemantics: quantity status: current @@ -2668,7 +2785,7 @@ description: Contains the inclusive low end of the range of
elementId: TBD -name: informationElementRangeEnd +name: informationElementRangeEnd dataType: unsigned64 dataTypeSemantics: quantity status: current @@ -2680,55 +2797,59 @@ description: Contains the inclusive high end of the range of
elementId: TBD -name: informationElementSemantics +name: informationElementSemantics dataType: unsigned8 dataTypeSemantics: status: current description: A description of the semantics of an IPFIX - Information Element. These are taken from the data type - semantics defined in section 3.2 of the IPFIX Information - Model [RFC5102]; see that section for more information - on the types defined in the informationElementSemantics - sub-registry. This field may take the values in Table ; - the special value 0x00 (default) is used to note that - no semantics apply to the field; it cannot be manipulated - by a Collecting Process or File Reader that does not - understand it a priori. + Information Element. These are taken from the data + type semantics defined in section 3.2 of the IPFIX + Information Model [RFC5102]; see that section for + more information on the types defined in the + informationElementSemantics sub-registry. This + field may take the values in Table ; the special + value 0x00 (default) is used to note that no + semantics apply to the field; it cannot be + manipulated by a Collecting Process or File Reader + that does not understand it a priori. These semantics are registered in the IANA IPFIX - Information Element Semantics subregistry. This subregistry - is intended to assign numbers for semantics names, not - to provide a mechanism for adding semantics to the - IPFIX Protocol, and as such requires a Standards - Action [RFC5226] to modify. + Information Element Semantics subregistry. This + subregistry is intended to assign numbers for + semantics names, not to provide a mechanism for + adding semantics to the IPFIX Protocol, and as such + requires a Standards Action [RFC5226] to modify.
elementId: TBD -name: informationElementUnits +name: informationElementUnits dataType: unsigned16 dataTypeSemantics: status: current description: A description of the units of an IPFIX Information - Element. These correspond to the units implicitly defined in the - Information Element definitions in section 5 of the IPFIX - Information Model [RFC5102]; see that section for more information - on the types described in the informationElementsUnits sub-registry. - This field may take the values in Table 3 below; the special value - 0x00 (none) is used to note that the field is unitless. + Element. These correspond to the units implicitly + defined in the Information Element definitions in + section 5 of the IPFIX Information Model [RFC5102]; + see that section for more information on the types + described in the informationElementsUnits + sub-registry. This field may take the values in + Table 3 below; the special value 0x00 (none) is + used to note that the field is unitless. - These types are registered in the IANA IPFIX Information Element - Units subregistry; new types may be added on a First Come First - Served [RFC5226] basis. + These types are registered in the IANA IPFIX + Information Element Units subregistry; new types + may be added on a First Come First Served [RFC5226] + basis.
elementId: TBD -name: userName +name: userName dataType: string dataTypeSemantics: default status: current @@ -2739,29 +2860,31 @@ description: User name associated with the flow.
elementId: TBD -name: applicationCategoryName +name: applicationCategoryName dataType: string dataTypeSemantics: default status: current -description: An attribute that provides a first level categorization for - each Application ID. +description: An attribute that provides a first level + categorization for each Application ID.
elementId: TBD -name: mibObjectValueInteger +name: mibObjectValueInteger dataType: signed64 dataTypeSemantics: identifier status: current description: An IPFIX Information Element which denotes that the - integer value of a MIB object will be exported. The MIB Object - Identifier ("mibObjectIdentifier") for this field MUST be exported - in a MIB Field Option or via another means. This Information - Element is used for MIB objects with the Base Syntax of Integer32 - and INTEGER with IPFIX Reduced Size Encoding used as required. - The value is encoded as per the standard IPFIX Abstract Data Type + integer value of a MIB object will be exported. + The MIB Object Identifier ("mibObjectIdentifier") + for this field MUST be exported in a MIB Field + Option or via another means. This Information + Element is used for MIB objects with the Base + Syntax of Integer32 and INTEGER with IPFIX Reduced + Size Encoding used as required. The value is + encoded as per the standard IPFIX Abstract Data Type of signed64.
@@ -2769,91 +2892,102 @@ description: An IPFIX Information Element which denotes that the
elementId: TBD -name: mibObjectValueOctetString +name: mibObjectValueOctetString dataType: octetArray dataTypeSemantics: default status: current description: An IPFIX Information Element which denotes that an - Octet String or Opaque value of a MIB object will be exported. - The MIB Object Identifier ("mibObjectIdentifier") for this field - MUST be exported in a MIB Field Option or via another means. This - Information Element is used for MIB objects with the Base Syntax - of OCTET STRING and Opaque. The value is encoded as per the - standard IPFIX Abstract Data Type of octetArray. + Octet String or Opaque value of a MIB object will + be exported. The MIB Object Identifier + ("mibObjectIdentifier") for this field MUST be + exported in a MIB Field Option or via another means. + This Information Element is used for MIB objects + with the Base Syntax of OCTET STRING and Opaque. The + value is encoded as per the standard IPFIX Abstract + Data Type of octetArray.
elementId: TBD -name: mibObjectValueOID +name: mibObjectValueOID dataType: octetArray dataTypeSemantics: default status: current description: An IPFIX Information Element which denotes that an - Object Identifier or OID value of a MIB object will be exported. - The MIB Object Identifier ("mibObjectIdentifier") for this field - MUST be exported in a MIB Field Option or via another means. This - Information Element is used for MIB objects with the Base Syntax - of OBJECT IDENTIFIER. Note - In this case the - "mibObjectIdentifier" will define which MIB object is being - exported while the value contained in this Information Element - will be an OID as a value. The mibObjectValueOID Information - Element is encoded as ASN.1/BER [BER] in an octetArray. + Object Identifier or OID value of a MIB object will + be exported. The MIB Object Identifier + ("mibObjectIdentifier") for this field MUST be + exported in a MIB Field Option or via another means. + This Information Element is used for MIB objects + with the Base Syntax of OBJECT IDENTIFIER. Note - + In this case the "mibObjectIdentifier" will define + which MIB object is being exported while the value + contained in this Information Element will be an + OID as a value. The mibObjectValueOID Information + Element is encoded as ASN.1/BER [BER] in an + octetArray.
elementId: TBD -name: mibObjectValueBits +name: mibObjectValueBits dataType: octetArray dataTypeSemantics: flags status: current -description: An IPFIX Information Element which denotes that a set - of Enumerated flags or bits from a MIB object will be exported. - The MIB Object Identifier ("mibObjectIdentifier") for this field - MUST be exported in a MIB Field Option or via another means. This - Information Element is used for MIB objects with the Base Syntax - of BITS. The flags or bits are encoded as per the standard IPFIX - Abstract Data Type of octetArray, with sufficient length to - accommodate the required number of bits. If the number of bits is - not an integer multiple of octets then the most significant bits - at end of the octetArray MUST be set to zero. +description: An IPFIX Information Element which denotes that a + set of Enumerated flags or bits from a MIB object + will be exported. The MIB Object Identifier + ("mibObjectIdentifier") for this field MUST be + exported in a MIB Field Option or via another means. + This Information Element is used for MIB objects + with the Base Syntax of BITS. The flags or bits are + encoded as per the standard IPFIX Abstract Data Type + of octetArray, with sufficient length to accommodate + the required number of bits. If the number of bits + is not an integer multiple of octets then the most + significant bits at end of the octetArray MUST be + set to zero.
elementId: TBD -name: mibObjectValueIPAddress +name: mibObjectValueIPAddress dataType: ipv4Address dataTypeSemantics: default status: current description: An IPFIX Information Element which denotes that the - IPv4 Address of a MIB object will be exported. The MIB Object - Identifier ("mibObjectIdentifier") for this field MUST be exported - in a MIB Field Option or via another means. This Information - Element is used for MIB objects with the Base Syntax of IPaddress. - The value is encoded as per the standard IPFIX Abstract Data Type - of ipv4Address. + IPv4 Address of a MIB object will be exported. The + MIB Object Identifier ("mibObjectIdentifier") for + this field MUST be exported in a MIB Field Option + or via another means. This Information Element is + used for MIB objects with the Base Syntax of + IPaddress. The value is encoded as per the standard + IPFIX Abstract Data Type of ipv4Address.
elementId: TBD -name: mibObjectValueCounter +name: mibObjectValueCounter dataType: unsigned64 dataTypeSemantics: snmpCounter status: current description: An IPFIX Information Element which denotes that the - counter value of a MIB object will be exported. The MIB Object - Identifier ("mibObjectIdentifier") for this field MUST be exported - in a MIB Field Option or via another means. This Information - Element is used for MIB objects with the Base Syntax of Counter32 - or Counter64 with IPFIX Reduced Size Encoding used as required. - The value is encoded as per the standard IPFIX Abstract Data Type + counter value of a MIB object will be exported. + The MIB Object Identifier ("mibObjectIdentifier") + for this field MUST be exported in a MIB Field + Option or via another means. This Information + Element is used for MIB objects with the Base + Syntax of Counter32 or Counter64 with IPFIX Reduced + Size Encoding used as required. The value is encoded + as per the standard IPFIX Abstract Data Type of unsigned64.
@@ -2861,18 +2995,20 @@ description: An IPFIX Information Element which denotes that the
elementId: TBD -name: mibObjectValueGauge +name: mibObjectValueGauge dataType: unsigned32 dataTypeSemantics: snmpGauge status: current description: An IPFIX Information Element which denotes that the - Gauge value of a MIB object will be exported. The MIB Object - Identifier ("mibObjectIdentifier") for this field MUST be exported - in a MIB Field Option or via another means. This Information - Element is used for MIB objects with the Base Syntax of Gauge32. - The value is encoded as per the standard IPFIX Abstract Data Type - of unsigned64. This value will represent a non-negative integer, - which may increase or decrease, but shall never exceed a maximum + Gauge value of a MIB object will be exported. The + MIB Object Identifier ("mibObjectIdentifier") for + this field MUST be exported in a MIB Field Option + or via another means. This Information Element is + used for MIB objects with the Base Syntax of Gauge32. + The value is encoded as per the standard IPFIX + Abstract Data Type of unsigned64. This value will + represent a non-negative integer, which may increase + or decrease, but shall never exceed a maximum value, nor fall below a minimum value.
@@ -2880,34 +3016,37 @@ description: An IPFIX Information Element which denotes that the
elementId: TBD -name: mibObjectValueTimeTicks +name: mibObjectValueTimeTicks dataType: unsigned32 dataTypeSemantics: default status: current description: An IPFIX Information Element which denotes that the - TimeTicks value of a MIB object will be exported. The MIB Object - Identifier ("mibObjectIdentifier") for this field MUST be exported - in a MIB Field Option or via another means. This Information - Element is used for MIB objects with the Base Syntax of TimeTicks. - The value is encoded as per the standard IPFIX Abstract Data Type - of unsigned32. + TimeTicks value of a MIB object will be exported. + The MIB Object Identifier ("mibObjectIdentifier") + for this field MUST be exported in a MIB Field + Option or via another means. This Information + Element is used for MIB objects with the Base + Syntax of TimeTicks. The value is encoded as per + the standard IPFIX Abstract Data Type of unsigned32.
elementId: TBD -name: mibObjectValueUnsigned +name: mibObjectValueUnsigned dataType: unsigned64 dataTypeSemantics: identifier status: current description: An IPFIX Information Element which denotes that an - unsigned integer value of a MIB object will be exported. The MIB - Object Identifier ("mibObjectIdentifier") for this field MUST be - exported in a MIB Field Option or via another means. This - Information Element is used for MIB objects with the Base Syntax - of unsigned64 with IPFIX Reduced Size Encoding used as required. - The value is encoded as per the standard IPFIX Abstract Data Type + unsigned integer value of a MIB object will be + exported. The MIB Object Identifier + ("mibObjectIdentifier") for this field MUST be + exported in a MIB Field Option or via another means. + This Information Element is used for MIB objects + with the Base Syntax of unsigned64 with IPFIX + Reduced Size Encoding used as required. The value is + encoded as per the standard IPFIX Abstract Data Type of unsigned64.
@@ -2915,93 +3054,105 @@ description: An IPFIX Information Element which denotes that an
elementId: TBD -name: mibObjectValueTable +name: mibObjectValueTable dataType: subTemplateList dataTypeSemantics: list status: current -description: An IPFIX Information Element which denotes that a - complete or partial conceptual table will be exported. The MIB - Object Identifier ("mibObjectIdentifier") for this field MUST be - exported in a MIB Field Option or via another means. This - Information Element is used for MIB objects with a SYNTAX of - SEQUENCE. This is encoded as a subTemplateList of mibObjectValue - Information Elements. The template specified in the - subTemplateList MUST be an Options Template and MUST include all - the Objects listed in the INDEX clause as Scope Fields. +description: An IPFIX Information Element which denotes that a + complete or partial conceptual table will be + exported. The MIB Object Identifier + ("mibObjectIdentifier") for this field MUST be + exported in a MIB Field Option or via another means. + This Information Element is used for MIB objects + with a SYNTAX of SEQUENCE. This is encoded as a + subTemplateList of mibObjectValue Information + Elements. The template specified in the + subTemplateList MUST be an Options Template and + MUST include all the Objects listed in the INDEX + clause as Scope Fields.
elementId: TBD -name: mibObjectValueRow +name: mibObjectValueRow dataType: subTemplateList dataTypeSemantics: list status: current -description: An IPFIX Information Element which denotes that a - single row of a conceptual table will be exported. The MIB Object - Identifier ("mibObjectIdentifier") for this field MUST be exported - in a MIB Field Option or via another means. This Information - Element is used for MIB objects with a SYNTAX of SEQUENCE. This - is encoded as a subTemplateList of mibObjectValue Information - Elements. The subTemplateList exported MUST contain exactly one - row (i.e., one instance of the subtemplate). The template - specified in the subTemplateList MUST be an Options Template and - MUST include all the Objects listed in the INDEX clause as Scope - Fields. +description: An IPFIX Information Element which denotes that a + single row of a conceptual table will be exported. + The MIB Object Identifier ("mibObjectIdentifier") + for this field MUST be exported in a MIB Field + Option or via another means. This Information + Element is used for MIB objects with a SYNTAX of + SEQUENCE. This is encoded as a subTemplateList of + mibObjectValue Information Elements. The + subTemplateList exported MUST contain exactly one + row (i.e., one instance of the subtemplate). The + template specified in the subTemplateList MUST be + an Options Template and MUST include all the + Objects listed in the INDEX clause as Scope Fields.
elementId: TBD -name: mibObjectIdentifier +name: mibObjectIdentifier dataType: octetArray dataTypeSemantics: default status: current -description: An IPFIX Information Element which denotes that a MIB - Object Identifier (MIB OID) is exported in the (Options) Template - Record. The mibObjectIdentifier Information Element contains the - OID assigned to the MIB Object Type Definition encoded as ASN.1/ - BER [BER]. +description: An IPFIX Information Element which denotes that a + MIB Object Identifier (MIB OID) is exported in the + (Options) Template Record. The mibObjectIdentifier + Information Element contains the OID assigned to + the MIB Object Type Definition encoded as + ASN.1/BER [BER].
elementId: TBD -name: mibSubIdentifier +name: mibSubIdentifier dataType: unsigned32 dataTypeSemantics: identifier status: current -description: A non-negative sub-identifier of an Object Identifier (OID). +description: A non-negative sub-identifier of an Object + Identifier (OID).
elementId: TBD -name: mibIndexIndicator +name: mibIndexIndicator dataType: unsigned64 dataTypeSemantics: flags status: current description: This set of bit fields is used for marking the - Information Elements of a Data Record that serve as INDEX MIB - objects for an indexed Columnar MIB object. Each bit represents - an Information Element in the Data Record with the n-th bit - representing the n-th Information Element. A bit set to value 1 - indicates that the corresponding Information Element is an index - of the Columnar Object represented by the mibFieldValue. A bit - set to value 0 indicates that this is not the case. + Information Elements of a Data Record that serve as + INDEX MIB objects for an indexed Columnar MIB + object. Each bit represents an Information Element + in the Data Record with the n-th bit representing + the n-th Information Element. A bit set to value 1 + indicates that the corresponding Information Element + is an index of the Columnar Object represented by + the mibFieldValue. A bit set to value 0 indicates + that this is not the case. - If the Data Record contains more than 64 Information Elements, the - corresponding Template SHOULD be designed such that all INDEX - Fields are among the first 64 Information Elements, because the - mibIndexIndicator only contains 64 bits. If the Data Record - contains less than 64 Information Elements, then the extra bits in - the mibIndexIndicator for which no corresponding Information - Element exists MUST have the value 0, and must be disregarded by - the Collector. This Information Element may be exported with + If the Data Record contains more than 64 + Information Elements, the corresponding Template + SHOULD be designed such that all INDEX + Fields are among the first 64 Information Elements, + because the mibIndexIndicator only contains 64 bits. + If the Data Record contains less than 64 + Information Elements, then the extra bits in the + mibIndexIndicator for which no corresponding + Information Element exists MUST have the value 0, + and must be disregarded by the Collector. This + Information Element may be exported with IPFIX Reduced Size Encoding.
@@ -3009,71 +3160,75 @@ description: This set of bit fields is used for marking the
elementId: TBD -name: mibCaptureTimeSemantics +name: mibCaptureTimeSemantics dataType: unsigned8 dataTypeSemantics: identifier status: current description: Indicates when in the lifetime of the flow the MIB - value was retrieved from the MIB for a mibObjectIdentifier. This - is used to indicate if the value exported was collected from the - MIB closer to flow creation or flow export time and will refer to - the Timestamp fields included in the same record. This field - SHOULD be used when exporting a mibObjectValue that specifies - counters or statistics. + value was retrieved from the MIB for a + mibObjectIdentifier. This is used to indicate if + the value exported was collected from the MIB + closer to flow creation or flow export time and + will refer to the Timestamp fields included in the + same record. This field SHOULD be used when + exporting a mibObjectValue that specifies counters + or statistics. - If the MIB value was sampled by SNMP prior to the IPFIX Metering - Process or Exporting Process retrieving the value (i.e., the data - is already stale) and it's important to know the exact sampling - time, then an additional observationTime* element should be paired - with the OID using structured data. Similarly, if different - mibCaptureTimeSemantics apply to different mibObject elements - within the Data Record, then individual mibCaptureTimeSemantics + If the MIB value was sampled by SNMP prior to the + IPFIX Metering Process or Exporting Process + retrieving the value (i.e., the data is already + stale) and it's important to know the exact sampling + time, then an additional observationTime* element + should be paired with the OID using structured data. + Similarly, if different mibCaptureTimeSemantics + apply to different mibObject elements within the + Data Record, then individual mibCaptureTimeSemantics should be paired with each OID using structured data. Values: 0. undefined - 1. begin - The value for the MIB object is captured from the - MIB when the Flow is first observed - 2. end - The value for the MIB object is captured from the MIB - when the Flow ends - 3. export - The value for the MIB object is captured from the - MIB at export time - 4. average - The value for the MIB object is an average of - multiple captures from the MIB over the observed life of the - Flow + 1. begin - The value for the MIB object is captured + from the MIB when the Flow is first observed + 2. end - The value for the MIB object is captured + from the MIB when the Flow ends + 3. export - The value for the MIB object is + captured from the MIB at export time + 4. average - The value for the MIB object is an + average of multiple captures from the MIB over the + observed life of the Flow
elementId: TBD -name: mibContextEngineID +name: mibContextEngineID dataType: octetArray dataTypeSemantics: default status: current description: A mibContextEngineID that specifies the SNMP engine - ID for a MIB field being exported over IPFIX. Definition as per - [RFC3411] section 3.3. + ID for a MIB field being exported over IPFIX. + Definition as per [RFC3411] section 3.3.
elementId: TBD -name: mibContextName +name: mibContextName dataType: string dataTypeSemantics: default status: current description: This Information Element denotes that a MIB Context - Name is specified for a MIB field being exported over IPFIX. - Reference [RFC3411] section 3.3. + Name is specified for a MIB field being exported + over IPFIX. Reference [RFC3411] section 3.3.
elementId: TBD -name: mibObjectName +name: mibObjectName dataType: string dataTypeSemantics: default status: current @@ -3085,7 +3240,7 @@ description: The name (called a descriptor in [RFC2578]
elementId: TBD -name: mibObjectDescription +name: mibObjectDescription dataType: string dataTypeSemantics: default status: current @@ -3097,20 +3252,20 @@ description: The value of the DESCRIPTION clause of an MIB object
elementId: TBD -name: mibObjectSyntax +name: mibObjectSyntax dataType: string dataTypeSemantics: default status: current description: The value of the SYNTAX clause of an MIB object type - definition, which may include a Textual Convention or Subtyping. - See [RFC2578]. + definition, which may include a Textual Convention + or Subtyping. See [RFC2578].
elementId: TBD -name: mibModuleName +name: mibModuleName dataType: string dataTypeSemantics: default status: current @@ -3124,7 +3279,8 @@ description: The textual name of the MIB module that defines a MIB
- TODO: this section needs to refer out to wherever the operations / generalized workflow + TODO: this section needs to refer out to wherever + the operations / generalized workflow content ends up TODO: revise to eliminate graph references @@ -3354,8 +3510,8 @@ description: The textual name of the MIB module that defines a MIB &RFC3411; &RFC3416; - &RFC3418; &RFC3444; &RFC3580; &RFC3954; &RFC4287; &RFC4949; &RFC5201; &RFC5209; - &RFC5424; &RFC5792; &RFC5793; &RFC6020; &RFC6241; + &RFC3418; &RFC3580; &RFC4287; &RFC4949; &RFC5201; &RFC5209; + &RFC5792; &RFC5793; &RFC6020; &RFC6241; &RFC6876; &RFC7012; &RFC7013; &RFC7171; &RFC7632; &I-D.ietf-sacm-requirements; &I-D.ietf-sacm-terminology; @@ -3690,7 +3846,7 @@ description: The textual name of the MIB module that defines a MIB
Moved , , and into the Appendix. Added a reference to it in - Added the section. Provided notes for the type of information we need to add in this section. + Added the section. Provided notes for the type of information we need to add in this section. Added the section. Moved sections on Endpoint, Hardware Component, Software Component, Hardware Instance, and Software Instance there. Provided notes for the type of information we need to add in this section. Removed the Provenance of Information Section. SACM is not going to solve provenance rather give organizations enough information to figure it out. Updated references to the Endpoint Security Posture Assessment: Enterprise Use Cases document to reflect that it was published as an RFC. @@ -3700,13 +3856,13 @@ description: The textual name of the MIB module that defines a MIB
Integrated the IPFIX syntax - into . + into . Converted many of the existing SACM Information Elements to the IPFIX syntax. Included existing IPFIX Information Elements and datatypes that could likely be reused for SACM in and + target="structure-of-information-elements"/> respectively. Removed the sections related to reports as described in https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/30.