diff --git a/draft-ietf-sacm-information-model-02.xml b/draft-ietf-sacm-information-model-02.xml
index 471814e..581943d 100644
--- a/draft-ietf-sacm-information-model-02.xml
+++ b/draft-ietf-sacm-information-model-02.xml
@@ -5,12 +5,15 @@
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
+
+
+
@@ -204,7 +207,7 @@
- Renamed "credential" to "identity", following industry usage. A credential includes
+ Renamed "credential" to "identity", following industry usage. A credential includes
proof, such as a key or password. A username or a distinguished name is called an
"identity".
@@ -224,9 +227,16 @@
Made identity-to-account a many-to-one relationship.
+
-
-
+
+ Added , Identifying Attributes.
+ Split the figure into and .
+ Added , proposing a triple-store model.
+ Some editorial cleanup
+
+
+
@@ -300,7 +310,7 @@
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.
-
+
@@ -314,16 +324,16 @@
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 provenance information.
+
-
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.
+
-
@@ -343,7 +353,7 @@
of a software component, endpoint identity, user identity, address,
location, and authorization constraining the endpoint
-
+
The SACM Information Model does not (in this draft) specify
how long information is retained. Historical information is
@@ -351,14 +361,14 @@
may be represented
differently in an implementation, but that difference would be in data models,
not in the information model.
-
-
+
- the
- the information model.
+
+ introduces the endpoint attributes
+ and their relationships.
-
+ _______*+-----+
|Hardware | |! !|
@@ -378,39 +388,71 @@
|! !|____ |Interface|
- | in>
- .......|..............................................................
- | |0..1
- | |
- | |*
- | +-----+ +---------+___________________
- | | AVP |____________|Endpoint |* | SACM |__________________________|
+ |* | |___|
+ |_______| in>
+ in>
+ ]]>
+
+
+
+ is the core of the information model. It represents
+ the information elements and their relationships.
+
+
+
-
+
+
+
+ is a potential alternative to .
+ It is inspired by triple stores.
+ See http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/.
+
+
+ 1+---------+
+ +-----+1
+
+
Note: UML 2 is specified by .
+
TODO: update text to match new figure:
- Need to be clear in the description that - of some of
+ Need to be clear in the description that ???
+ For some of
the relationships, will need some language and guidance to
the interfaces and relationships we expect to have happen,
MUSTs and SHOULDs, as well as explaining the extensibility
@@ -418,17 +460,245 @@ hosted-by| *| |Assertion|* | |
that can happen. Others that we haven't thought of yet, might
be added by another RFC or in another way
- CEK: >>> I suddenly wonder whether all of the relationships in the upper right corner of the diagram are needed. At present, AVPs mostly mention instances of the classes in the upper half. The only relationship an endpoint attribute assertion expresses is that a set of AVPs are all true of some endpoint. We don’t have a way to say that an address is bound to a particular interface. Such structures *can* be modeled, using YANG, for example. But do we require that? If we do, why? I do think we need to be able to relate a software instance to the software component, and a hardware instance to the hardware component.
-
- The following subsections discuss .
+
+
+ Identifying attributes let a consumer identify an endpoint,
+ for two purposes:
+ To tell whether two endpoint
+ attribute assertions concern the same endpoint
+ (TODO: Why this is not simple)
+ To respond to compliance measurements, for example
+ by reporting, remediating, and quarantining
+ (SACM does not specify these responses,
+ but SACM exists to enable them.)
+
+
+ Out of scope of this section: *characterizing* an endpoint
+ so as to apply appropriate collection guidance to it.
+ We don't call this "identification".
+
+
+ Each attribute-value pair or triple
+ MUST be marked with how the provider knows.
+ There MUST be at least one marking.
+ The possible markings follow.
+
+ "Self" means that the endpoint furnished the information:
+ it is self-reported. "Self" does not (necessarily) mean that the
+ provider runs on the the monitored endpoint.
+ "Authority" means that the provider got the information,
+ directly or indirectly, from an authority that assigned it.
+ For example, the producer got an IP-MAC association
+ from a DHCP server
+ (or was itself the DHCP server).
+ "Observation" means that the provider got the information
+ from observations of network traffic.
+ For example, the producer saw the endpoint provide the
+ certificate in a successful TLS exchange. (TODO: Cite RFC)
+ "Verification" means that the provider has verified
+ the information by interacting with the endpoint.
+ For example, the provider does IP communication with the endpoint
+ and it knows the IP address with which it communicates.
+ Or, the provider makes an SSH connection to the endpoint
+ and knows the endpoint's public key by virtue of authenticating it.
+
+
+
+
+
+
+
+
+
+ MUST be an IPv4 or IPv6 address,
+ and optionally a scope string.
+ MUST NOT be a broadcast, unicast, or loopback address.
+ An IPv4 address MUST conform to ,
+ section 3.2.
+ An IPv6 address MUST conform to .
+ SHOULD NOT be a link-local address.
+ Scope string: an administratively assigned string
+ denoting the IP routing domain.
+ Implementations MUST support this.
+ Administrators may use it to avoid ambiguity,
+ for example if network address translation (NAT) is in use.
+ ISSUE (Jim Schaad): Scope strings are interesting.
+ However does this imply a potential need to create a new DHCP item so that
+ it can be sent out to a device for reporting back?
+ Is there such a string already?
+ (Cliff): Scope strings are like administrative-domain in IF-MAP.
+ It would solve many problems if DHCP servers could provide this
+ string to endpoints and to observers.
+ I am not sure whether there is a standard DHCP option that
+ fills the bill or not.
+ I am not sure how easily application software can get
+ the DHCP options from the underlying OS.
+ But this is worth exploring.
+
+
+
+ At the time of observation
+ the endpoint had the right to use,
+ or was communicating using, each specified IP address.
+
+
+
+ An endpoint attribute assertion MAY contain
+ one or more IP addresses.
+ In practice, an IP address can be used by only one
+ endpoint in an IP routing domain at a time.
+
+
+
+ All SACM data models MUST support this entire subsection.
+
+
+
+
+
+
+ TODO
+
+
+
+
+
+ MUST be a vendor ID string and a serial number string string.
+ The vendor ID string MAY be empty, a URI, or a vendor number.
+
+
+
+ At the time of observation the endpoint had a hardware component by
+ the indicated manufacturer and having the specified serial number.
+
+
+
+ An endpoint may have any number of hardware components,
+ each with a different serial number.
+ Accordingly, an endpoint attribute
+ assertion MAY contain one or more serial numbers.
+
+ A vendor SHOULD ensure that each serial number goes to
+ only one hardware instance.
+
+
+
+
+ All SACM data models MUST support this entire subsection.
+
+
+
+
+
+
+ MUST be X.509 certificate, per https://tools.ietf.org/html/rfc5280.
+
+
+
+ At the time of observation the endpoint had the right to use,
+ or was using, the specified certificate.
+
+
+
+ An endpoint may use, or have the right to use, one or more
+ certificates.
+
+ Some certificates may be used on more than one endpoint.
+ Other certificates are (by intent) bound to a single endpoint.
+ ISSUE: Is there a standard way to distinguish the two?
+
+
+
+ All SACM data models MUST support this entire subsection.
+
+
+
+
+
+
+ TODO
+
+
+
+
+ TODO
+
+ TODO: "Tool-specific identifier" suggests that two tools could
+ never agree on a tool-specific identifier.
+ But a community may agree on an identifier notation,
+ and might even create a formal standard.
+ All that's important is that each of these attributes has a type
+ and meaning *not* specified by the SACM internet drafts.
+ "Vendor-specific identifier?" "Custom identifier?"
+
+
+
+
+
+
+ TODO: Apply these properties to each identifying attribute.
+
+
+ Stability: scale is volatile to persistent to immutable
+
+ Multiplicity:
+ Does the value generally refer to only one
+ endpoint, or to multiple?
+ Does an endpoint generally have multiple values
+ of the attribute, or only one?
+
+
+ Accuracy: How often is the value true vs false?
+ What can make a false value happen? (Lying endpoint? etc)
+
+ Commonness: Do many endpoints have the attribute?
+
+
+
+
+
+ Every information element needs identifying attributes
+ of its producer's endpoint.
+ (TODO: Provide normative language. SHOULD? MUST?)
+
+ Specifically, in an endpoint attribute assertion,
+ we need identifying attributes of the asserter's endpoint.
+ If the asserter is external, the assertion will contain
+ identifying attributes of two endpoints.
+ (TODO: Discuss what this information is for.)
+
+
+
+
+ Effects of misidentification
+ Things that can cause misidentification
+ How minimize misidentification
+
+
+
+
An endpoint contains and runs software components.Relationship:
- If an endpoint has an instance of a software component, we say that the software component is “in” the endpoint. This is a shorthand.
-
+ If an endpoint has an instance of a software component, we say that the software component is "in" the endpoint. This is a shorthand.
+ Some software components are assets.
"Asset" is defined in RFC4949 as "a system
@@ -466,19 +736,23 @@ hosted-by| *| |Assertion|* | |
different components. Software versioning is not built into the
information model.
- Each separately installable piece of software SHOULD be modeled as a
-component. Sometimes it may be better to divide more finely: what an installer installs MAY be modeled as several components.
+ Each separately installable piece of software SHOULD be modeled as a
+ component. Sometimes it may be better to divide more finely:
+ what an installer installs MAY be modeled as several components.A data model MAY identify a software component by parts of an ISO SWID tag.
- Each copy of a piece of software is called a software instance. The configuration of a software instance is regarded as part of the software instance. Configuration can strongly affect security posture.
+ Each copy of a piece of software is called a software instance.
+ The configuration of a software instance is regarded
+ as part of the software instance.
+ Configuration can strongly affect security posture.A data model MUST support the following relationships:
- A software instance is an “instance of” a software component.
- A software instance is “in” an endpoint.
+ A software instance is an "instance of" a software component.
+ A software instance is "in" an endpoint.A data model MAY use ISO SWID tags to describe software instances.
@@ -503,8 +777,9 @@ component. Sometimes it may be better to divide more finely: what an installer i
component.
A data model MUST support the following relationships:
- A hardware instance is an “instance of” a hardware component.
- A hardware instance is “in” an endpoint.
+ A hardware instance is an "instance of" a hardware component.
+ A hardware instance is "in" an endpoint.
+ Hardware instances may need to be modeled because (a) an endpoint may have multiple instances of a hardware component, (b) a hardware instance may be compromised, whereas other instances may remain intact.
@@ -514,26 +789,30 @@ component. Sometimes it may be better to divide more finely: what an installer i
- CEK: >>> I am not sure how to use network interfaces for endpoint identification. As for compliance, is this too advanced for SACM at this time?
+ CEK: >>> I am not sure how to use network interfaces for endpoint identification. As for compliance, is this too advanced for SACM at this time?
- An endpoint generally has at least one network interface.
+ An endpoint generally has at least one network interface.
- Interfaces nest. A virtual interface can nest in a physical interface.
+ Interfaces nest. A virtual interface can nest in a physical interface.
- A data model MUST support the following relationships:
- A network interface is “in” an endpoint.
- A network interface is “in” another network interface; this
- is for a nested interface. CEK: >>> And this allows representing
- compliance policies that are worthwhile. But is this too advanced
- for the initial set of SACM RFCs?
- A network interface “acts for” an identity. This occurs, for example, when the network interface is online because of successful 802.1X. An internal
-collector may be aware of the identity. An external collector (such as a RADIUS server) will be aware of the identity.
-
+ A data model MUST support the following relationships:
+ A network interface is "in" an endpoint.
+ A network interface is "in" another network interface; this
+ is for a nested interface. CEK: And this allows representing
+ compliance policies that are worthwhile. But is this too advanced
+ for the initial set of SACM RFCs?
+ A network interface "acts for" an identity.
+ This occurs, for example, when the network interface is online
+ because of successful 802.1X.
+ An internal collector may be aware of the identity.
+ An external collector (such as a RADIUS server) will be aware of the identity.
+
-
+ IS THIS SECTION DEFUNCT?
+
An address SHALL BE any of:A layer 2 address; a data model MUST support MAC addresses,
and MAY support others
@@ -546,19 +825,21 @@ collector may be aware of the identity. An external collector (such as a RADIUS
Addresses from other layers may be added in the future.
- These addresses are not necessarily globally unique. Therefore, a data model SHOULD allow an address to be qualified with a scope.
+ These addresses are not necessarily globally unique.
+ Therefore, a data model SHOULD allow an address to be qualified with a scope.A data model SHOULD allow qualifying a MAC address with its
layer-2 broadcast domain. This MAY take the form of a VLAN ID
and an administratively assigned string denoting the LAN.A data model SHOULD allow qualifying an IP address with an
administratively assigned string denoting the IP routing domain.
+ A data model MUST support the following relationships:
- An address is “bound to” a network interface.
- An address is considered “bound to” an endpoint just if the
- address is “bound to” an interface that is “in” the endpoint.
- An address may be “in” one or more locations.
+ An address is "bound to" a network interface.
+ An address is considered "bound to" an endpoint just if the
+ address is "bound to" an interface that is "in" the endpoint.
+ An address may be "in" one or more locations.
@@ -570,9 +851,20 @@ collector may be aware of the identity. An external collector (such as a RADIUS
A data model MUST support the following relationships:
- An endpoint may “act for” an identity. This SHALL mean that the endpoint claims or proves that it has this identity. For example, if the endpoint is part of an Active Directory domain and Alice logs into the endpoint with her AD username (alice) and password, the endpoint "acts for” alice. An endpoint MAY "act for” more than one identity, such as a machine identity and a user identity.
-
- A identity may “belong to” an account. For example, an enterprise may have a database that maps identities to accounts. CEK: >>> Is this relevant? I don’t see how we’d use the notion of an account in identifying an endpoint or in specifying compliance measurements to be taken.
+ An endpoint may "act for" an identity.
+ This SHALL mean that the endpoint claims or proves that it has this
+ identity. For example, if the endpoint is part of an
+ Active Directory domain and Alice logs into the endpoint with her
+ AD username (alice) and password, the endpoint "acts for" alice.
+ An endpoint MAY "act for" more than one identity,
+ such as a machine identity and a user identity.
+
+ A identity may "belong to" an account.
+ For example, an enterprise may have a database
+ that maps identities to accounts.
+ CEK: Is this relevant? I don't see how we'd use the notion
+ of an account in identifying an endpoint or in specifying
+ compliance measurements to be taken.
@@ -582,12 +874,12 @@ collector may be aware of the identity. An external collector (such as a RADIUS
Location can be a clue to an endpoint's identity.
A data model MUST support the following relationships:
- One or more endpoints may be “in” a location
- A location may be “in” one or more locations
- A network address may be “in” a location
- An account may be “in” a location; this would happen
+ One or more endpoints may be "in" a location
+ A location may be "in" one or more locations
+ A network address may be "in" a location
+ An account may be "in" a location; this would happen
if the account represents a user, and a physical access
- control system reports on the user’s location
+ control system reports on the user's locationExamples of location:
@@ -608,7 +900,7 @@ collector may be aware of the identity. An external collector (such as a RADIUS
- CEK: >>> The last three examples seem too advanced for the first set of SACM RFCs.
+ CEK: The last three examples seem too advanced for the first set of SACM RFCs.
I do not know a notation that would be interoperable and
useful for endpoint identification. Should we drop them?
@@ -627,102 +919,102 @@ collector may be aware of the identity. An external collector (such as a RADIUS
- An endpoint is the hollow center of the model. An endpoint is an abstract ideal. Any endpoint attribute assertion that mentions an endpoint mentions it by specifying identifying attributes. Even if there is one preferred endpoint identity, that is modeled as an identity. We do not anticipate any AVP whose attribute type is “endpoint”.
+ An endpoint is the hollow center of the model. An endpoint is an abstract ideal. Any endpoint attribute assertion that mentions an endpoint mentions it by specifying identifying attributes. Even if there is one preferred endpoint identity, that is modeled as an identity. We do not anticipate any AVP whose attribute type is "endpoint".
-
- An endpoint attribute assertion has:
-
- One or more attribute-value pairs (AVPs)
- A time interval over which the assertion holds
- Endpoint uniquely identified? True or false
- Provenance, including:
-
- The SACM component that made the assertion
- The endpoint attribute assertions (if any)
- on which this assertion is based
- Information about the method used to derive the assertion
-
-
-
-
- It means that over the specified time interval, there was an endpoint for which all of the listed attribute-value pairs were true.
- If the "Endpoint uniquely identified" is true, the set of attributes-value
- pairs together make this assertion apply to only one endpoint.
- The attributes can include posture attributes and
- identification attributes. The model does not make a
- rigid distinction between the two uses of attributes.
- Some of the attributes may be multi-valued.
-
- One of the AVPs may be a unique endpoint identifier.
- Not every endpoint will have one. If there is one, the SACM component that produces
- the Endpoint Attribute Assertion will not necessarily know what it is.
-
-
-
- An Endpoint Attribute Assertion may come from an
- attribute collector or an evaluator. It may come from a SACM component that derives
- it from out-of-band sources, such as
- a physical inventory system. A SACM component may derive it
- from other Endpoint Attribute Assertions.
-
-
-
- For example, an attribute assertion might have these attribute-value pairs:
- mac-address = 01:23:45:67:89:ab
- os = OS X
- os-version = 10.6.8
-
- This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran OS X 10.6.8 throughout the specified time interval. A profiler might have provided this assertion.
-
-
-
- For example, Endpoint Attribute Assertions should help SACM components to track an endpoint as it roams or stays stationary. They must track endpoints because they must track endpoints' postures over time. Tracking of an endpoint can employ many clues, such as:
- The endpoint's MAC address
- The authenticated identity (even if it identifies a user)
- The location of the endpoint and the user
+
+ An endpoint attribute assertion has:
+
+ One or more attribute-value pairs (AVPs)
+ A time interval over which the assertion holds
+ Endpoint uniquely identified? True or false
+ Provenance, including:
+
+ The SACM component that made the assertion
+ The endpoint attribute assertions (if any)
+ on which this assertion is based
+ Information about the method used to derive the assertion
+
+
+
+
+ It means that over the specified time interval, there was an endpoint for which all of the listed attribute-value pairs were true.
+ If the "Endpoint uniquely identified" is true, the set of attributes-value
+ pairs together make this assertion apply to only one endpoint.
+ The attributes can include posture attributes and
+ identification attributes. The model does not make a
+ rigid distinction between the two uses of attributes.
+ Some of the attributes may be multi-valued.
+
+ One of the AVPs may be a unique endpoint identifier.
+ Not every endpoint will have one. If there is one, the SACM component that produces
+ the Endpoint Attribute Assertion will not necessarily know what it is.
+
+
+
+ An Endpoint Attribute Assertion may come from an
+ attribute collector or an evaluator. It may come from a SACM component that derives
+ it from out-of-band sources, such as
+ a physical inventory system. A SACM component may derive it
+ from other Endpoint Attribute Assertions.
+
+
+
+ For example, an attribute assertion might have these attribute-value pairs:
+ mac-address = 01:23:45:67:89:ab
+ os = OS X
+ os-version = 10.6.8
-
+ This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran OS X 10.6.8 throughout the specified time interval. A profiler might have provided this assertion.
+
-
+
+ For example, Endpoint Attribute Assertions should help SACM components to track an endpoint as it roams or stays stationary. They must track endpoints because they must track endpoints' postures over time. Tracking of an endpoint can employ many clues, such as:
+ The endpoint's MAC address
+ The authenticated identity (even if it identifies a user)
+ The location of the endpoint and the user
+
+
+
+
- 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
-
-
+ 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
+ Author: Henk Birkholz
- "Attribute" and "event" are often used fairly interchangeably. A
- clear distinction makes the words more useful.
- An *attribute* tends not to change until something causes a change. In
- contrast, an *event* occurs at a moment in time.
- For a nontechnical example, let us consider "openness" as an attribute of a door, with two values, "open" and "closed". A
- closed door tends to stay closed until something opens it (a breeze,
- a person, or a dog).
- The door's opening or closing is an event.
- Similarly, "Host firewall enabled" may be modeled as a true/false attribute of an endpoint.
- Enabling or disabling the host firewall may be modeled as
- an event. An endpoint's crashing also may be modeled as an
- event.
-
- Although events are not attributes,
- we use one kind of information element,
- the "Endpoint Attribute Assertion",
- to describe both attributes and events.
-
-
-
+ "Attribute" and "event" are often used fairly interchangeably. A
+ clear distinction makes the words more useful.
+ An *attribute* tends not to change until something causes a change. In
+ contrast, an *event* occurs at a moment in time.
+ For a nontechnical example, let us consider "openness" as an attribute of a door, with two values, "open" and "closed". A
+ closed door tends to stay closed until something opens it (a breeze,
+ a person, or a dog).
+ The door's opening or closing is an event.
+ Similarly, "Host firewall enabled" may be modeled as a true/false attribute of an endpoint.
+ Enabling or disabling the host firewall may be modeled as
+ an event. An endpoint's crashing also may be modeled as an
+ event.
+
+ Although events are not attributes,
+ we use one kind of information element,
+ the "Endpoint Attribute Assertion",
+ to describe both attributes and events.
+
+
+
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.
@@ -730,7 +1022,7 @@ collector may be aware of the identity. An external collector (such as a RADIUS
The value may be structured. For example, it may something like XML.The information model requires a standard attribute type (or possibly more than one) for each box in
-the upper half of :
+ :
Hardware Component: the value identifies the hardware type. For example, it may consist of the make and model number.Hardware Instance: the value, together with the Hardware Component value, uniquely identifies the hardware instance. For example, it may be a manufacturer-assigned
@@ -749,193 +1041,192 @@ the upper half of :
will need know that it's the same user?]Address: The value is an IP, MAC, or other network address,
possibly qualified with its scope.
-
+
- An organization should try to uniquely identify and label an endpoint, whether the endpoint is enrolled or is discovered in the operational environment. The identifier should be assigned by or used in the enrollment process.
- Here "unique" means one-to-one. In practice, uniqueness is not always attainable. Even if an endpoint has a unique identifier, an attribute collector may not always know it.
+ An organization should try to uniquely identify and label an endpoint, whether the endpoint is enrolled or is discovered in the operational environment. The identifier should be assigned by or used in the enrollment process.
+ Here "unique" means one-to-one. In practice, uniqueness is not always attainable. Even if an endpoint has a unique identifier, an attribute collector may not always know it.
- If the attribute type of an AVP is "endpoint", the value
- is a unique identifier of the endpoint.
-
+ If the attribute type of an AVP is "endpoint", the value
+ is a unique identifier of the endpoint.
+
- Some AVPs will be posture attributes.
+ Some AVPs will be posture attributes.
- See the definition in the SACM Terminology for Security Assessment
- .
+ See the definition in the SACM Terminology for Security Assessment
+ .
- Some potential kinds of posture attributes are:
- A NEA posture attribute (PA)
- A YANG model
- An IF-MAP device-characteristics metadata item
-
+ Some potential kinds of posture attributes are:
+ A NEA posture attribute (PA)
+ A YANG model
+ An IF-MAP device-characteristics metadata item
+
+
-
+
- Evaluation Results (see ) are modeled as Endpoint Attribute Assertions.
+ Evaluation Results (see ) are modeled as Endpoint Attribute Assertions.
- An Evaluation
- Result derives from one or more other Endpoint Attribute Assertions.
+ An Evaluation
+ Result derives from one or more other Endpoint Attribute Assertions.
- An example is: a NEA access recommendation
+ An example is: a NEA access recommendation
- An evaluator may be able to evaluate better if history is
- available. This is a use case for retaining Endpoint Attribute Assertions for a time.
+ An evaluator may be able to evaluate better if history is
+ available. This is a use case for retaining Endpoint Attribute Assertions for a time.
- An Evaluation Result may be retained longer than the Endpoint Attribute Assertions from which it derives. ( does not show this.) In the
- limiting case, Endpoint Attribute Assertions are not retained. When
- as an Endpoint Attribute Assertion arrives, an evaluator produces
- an Evaluation Result. These mechanics are out of the scope of the Information Model.
+ An Evaluation Result may be retained longer than the Endpoint Attribute Assertions from which it derives. ( does not show this.) In the
+ limiting case, Endpoint Attribute Assertions are not retained. When
+ as an Endpoint Attribute Assertion arrives, an evaluator produces
+ an Evaluation Result. These mechanics are out of the scope of the Information Model.
-
-
- An Endpoint Attribute Assertion concerns a single endpoint.
- Assertions about a set of endpoints are also needed -- for example, for trend analysis and for reports read by humans. These assertions are termed "reports". SACM components will consume Endpoint Attribute Assertions
+ An Endpoint Attribute Assertion concerns a single endpoint.
+ Assertions about a set of endpoints are also needed -- for example, for trend analysis and for reports read by humans. These assertions are termed "reports". SACM components will consume Endpoint Attribute Assertions
and generate reports.
- A report contains its provenance, with the same form and meaning
- as the provenance of an Endpoint Attribute Assertion.
-
- A Report summarizes:
- Endpoint Attribute Assertions, which may include Evaluation Results
- Other Reports
-
-
- A Report may routine or ad hoc.
- Some reports may be machine readable. Machine readable reports may be
- consumable by SACM components and by automatic response systems (not specified by SACM).
-
-
-
- Although SACM components are mainly covered by the SACM architecture, we have some remarks. TODO: Move them?
-
-
-
- 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?]
-
-
-
- A report generator makes reports based on:
- Endpoint Attribute Assertions, including Evaluation Results
- Other Reports (a weekly report may be created from daily
- reports)
-
- It may summarize data continually, as the data arrives. It also may
- summarize data in response to an ad hoc query.
-
-
-
-
- [kkw-from a reporting standpoint there needs to be
- some concept like organization or system. without this, there is no
- way to produce result reports that can be acted upon to provide the
- insight or accountability that almost all continuous monitoring
- instances are trying to achieve. from a scoring or grading
- standpoint, an endpoint needs to be associated with exactly one
- organization or system. it can have a many to many relationship
- with other types of results reporting "bins". is this important
- to include here? we had organization as a core asset type for this
- reason, so i think it is a key information element. but i also
- know that i do not want to define all the different reporting
- types, so i am unsure.]
-
- [cek-I had not thought of this at all. Would it make sense to treat the organization and the bins
- as part of the guidance for creating reports? Maybe not. We should discuss.]
-
-
-
- [jmf- the guidance sections need more detail. . .]
- [cek - What is missing? We would welcome a critique or text.]
- Guidance is generally configurable by human administrators.
-
-
- An internal collector may need guidance to govern what it
- collects and when.
-
-
- An external collector may need guidance to govern what it
- collects and when.
-
-
- An evaluator typically needs Evaluation Guidance to govern
- what it considers to be a good or bad security posture.
-
-
- A SACM deployment may retain posture attributes, events, or
- evaluation results for some time. Retention supports ad hoc
- reporting and other use cases.
- If information is retained, retention guidance controls what is
- retained and for how long.
- If two or more pieces of retention guidance apply to a piece of information,
- the guidance calling for the longest retention should take
- precedence.
-
-
- A Report Generator typically needs Reporting Guidance to govern the
- reports it generates.
-
-
-
-
- Each Endpoint Attribute Assertion and Report needs to be
- labeled with its provenance.
-
+ A report contains its provenance, with the same form and meaning
+ as the provenance of an Endpoint Attribute Assertion.
+
+ A Report summarizes:
+ Endpoint Attribute Assertions, which may include Evaluation Results
+ Other Reports
+
+
+ A Report may routine or ad hoc.
+ Some reports may be machine readable. Machine readable reports may be
+ consumable by SACM components and by automatic response systems (not specified by SACM).
+
+
+
+ Although SACM components are mainly covered by the SACM architecture, we have some remarks. TODO: Move them?
+
+
+
+ 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?]
+
+
+
+ A report generator makes reports based on:
+ Endpoint Attribute Assertions, including Evaluation Results
+ Other Reports (a weekly report may be created from daily
+ reports)
+
+ It may summarize data continually, as the data arrives. It also may
+ summarize data in response to an ad hoc query.
+
+
+
+
+ [kkw-from a reporting standpoint there needs to be
+ some concept like organization or system. without this, there is no
+ way to produce result reports that can be acted upon to provide the
+ insight or accountability that almost all continuous monitoring
+ instances are trying to achieve. from a scoring or grading
+ standpoint, an endpoint needs to be associated with exactly one
+ organization or system. it can have a many to many relationship
+ with other types of results reporting "bins". is this important
+ to include here? we had organization as a core asset type for this
+ reason, so i think it is a key information element. but i also
+ know that i do not want to define all the different reporting
+ types, so i am unsure.]
+
+ [cek-I had not thought of this at all. Would it make sense to treat the organization and the bins
+ as part of the guidance for creating reports? Maybe not. We should discuss.]
+
+
+
+ [jmf- the guidance sections need more detail. . .]
+ [cek - What is missing? We would welcome a critique or text.]
+ Guidance is generally configurable by human administrators.
+
+
+ An internal collector may need guidance to govern what it
+ collects and when.
+
+
+ An external collector may need guidance to govern what it
+ collects and when.
+
+
+ An evaluator typically needs Evaluation Guidance to govern
+ what it considers to be a good or bad security posture.
+
+
+ A SACM deployment may retain posture attributes, events, or
+ evaluation results for some time. Retention supports ad hoc
+ reporting and other use cases.
+ If information is retained, retention guidance controls what is
+ retained and for how long.
+ If two or more pieces of retention guidance apply to a piece of information,
+ the guidance calling for the longest retention should take
+ precedence.
+
+
+ A Report Generator typically needs Reporting Guidance to govern the
+ reports it generates.
+
+
+
+
+ Each Endpoint Attribute Assertion and Report needs to be
+ labeled with its provenance.
+
-
+ See the definition in the SACM Terminology for Security Assessment .
@@ -955,7 +1246,7 @@ part of a redundancy group is replaced, the redundancy group can remain
the same.
-
+ An endpoint identity provides both identification and
authentication of the endpoint. For example, an identity may be an
@@ -965,9 +1256,9 @@ the same.
Not all kinds of identities are guaranteed to be unique.
-
-
-
+
+
+ An endpoint contains and runs software components.
@@ -1004,36 +1295,30 @@ the same.
A business application that shipped with a virus
-
-
-
+
+ Organizations need to be able to uniquely identify and label software installed or run on an endpoint. Specifically, they need to know the name, publisher, unique ID, and version; and any related patches. In some cases the software's identity might be known a priori by the organization; in other cases, a software identity might be first detected by an organization when the software is first inventoried in an operational environment. Due to this, it is important that an organization have a stable and consistent means to identify software found during collection.A piece of software may have a unique identifier, such as a SWID tag
(ISO/IEC 19770).
-
-
+
+
-
+
-
+
-
+ An endpoint is often - but not always - associated with one or more
users.A user's identity provides both identification and authentication
of the user. @@@ Eh?
-
-
-
-
-
-
-
-
+
+
+
@@ -1048,7 +1333,7 @@ the same.
required to support the Detection of Posture Deviations scenario.
The Detection of Posture Deviations scenario involves multiple elements
- interacting to accomplish the goals of the scenario. illustrates those elements along with their major communication paths.
+ interacting to accomplish the goals of the scenario. illustrates those elements along with their major communication paths.
The following subsections contain examples of identifiers and metadata which
@@ -1254,7 +1539,7 @@ the same.
- &RFC2119;
+ &RFC0791; &RFC2119; &RFC3587;
&RFC3411; &RFC3416;