Definition of Posture

[henkbirkholz]

The definition of Posture in the current terminology draft references RFC 5209, which includes “configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy”. In contrast, the rest of the definition redefines it as a more elementary “state information that is collected from an endpoint”.

There might be issues with the current way this definition is worded:

1.) The term Posture – in the context of security automation, especially due to its existing definition in RFC 5209 – might always imply that it is about a quite elaborate assertion regarding security policies. If the goal of the definition is to describe bundles of “state information that is collected from an endpoint” maybe using another term helps to better distinguish this raw assertion (“this state information is about this endpoint”) from more complex assertions (e.g. “this state information is in conflict with security policies”).

2.) In the Endpoint ID DT, a general categorization of Endpoint Attributes is currently discussed. Basically there are four categories of Endpoint Attributes that depend on their provenance/origin:

• collected via a SACM Component located on a Endpoint that has the role of a Target Endpoint
• collected via a SACM Component located on an Endpoint different from the Target Endpoint using remote acquisition methods with “native” interfaces, such as SNMP, NETCONF, etc. and the network.
• collected via a SACM Component located on an Endpoint different from the Target Endpoint able to observe, interpret or even correlate its corresponding behavior on the network.
• collected via a SACM Component on a Data Store/Repository (e.g. configuration baseline repository or CMDB) that contains the expected state of Endpoint Attributes (the “should”-state, in contrast to the “is”-state).

These “variants of collection” will potentially exceed the current definition of Posture, which is limited to “originates from this endpoint”.

3.) While the original definition of Posture from RFC 5209 encompasses (and differentiates) configuration and state, the new definition does not. If there are no good reasons speaking against it, the differentiation of configuration and state could be reintroduced in the definition.

Potential changes to this definition might propagate corresponding changes to the definition of Posture Attributes (and might lead to additional definitions, such as Configuration, State, Native Interface (remote API), Raw Assertion/Collection Result, Identity Assertion, Security Posture Assertion, etc.).

[llorenzin]

WRT sub-issue 1) - I believe that the current definition of posture meets your first example of a raw assertion ("information about this endpoint"). For your second example of a complex assertion ("this state information is in conflict with a security policy"), I believe that's a posture attribute ("current state = out of compliance") generated by an evaluation result. I don't think this requires a change in the definition of the term posture. I do think it requires an additional posture attribute for in compliance / out of compliance to be defined in the information model.

WRT 2) - I agree, and I believe that the second paragraph introduces an unnecessary and harmful conflict with the NEA definition of posture. The wording of the second sentence of the second paragraph is also unclear. I propose that we change the second paragraph from:

This term is used within the scope of SACM to represent the configuration and state information that is collected from an endpoint (e.g. software/hardware inventory, configuration settings, dynamically assigned addresses). This information may constitute one to many Posture Attributes.

To (changes highlighted with **):

This term is used within the scope of SACM to represent the configuration and state information that is collected about an endpoint (e.g. software/hardware inventory, configuration settings, dynamically assigned addresses). This information may be composed of one to many Posture Attributes.

This aligns our usage with the NEA definition and clarifies the composition of posture.

3) I agree with the reintroduction of "configuration and status" to the second paragraph done in -07.

[adammontville]

Aside: it seems like this could be several distinct issues to make it easier to respond.

WRT 1) I would expect evaluation results to clearly indicate compliance, so I wouldn't necessarily want to another attribute to indicate compliance or lack thereof.

[henkbirkholz]

1.) closed & might be revisited later

2.) variants of collection

• collected via a SACM Component located on a Endpoint that has the role of a Target Endpoint
  • addressed in Collection Task "Self-Reporting"
• collected via a SACM Component located on an Endpoint different from the Target Endpoint using remote acquisition methods with “native” interfaces, such as SNMP, NETCONF, etc. and the network.
  • addressed in Collection Task "Remote" (todo: relabel to "Remote-Acquisition")
• collected via a SACM Component located on an Endpoint different from the Target Endpoint able to observe, interpret or even correlate its corresponding behavior on the network.
  • addressed in Collection Task "Observed" (todo: relabel to "Behavior-Observation"

3.) Posture - configuration / state addressed in the definition of Posture.

Remaining Issue:

• collected via a SACM Component on a Data Store/Repository (e.g. configuration baseline repository or CMDB) that contains the expected state of Endpoint Attributes (the “should”-state, in contrast to the “is”-state).
  • this could become a part of "Asset Characterization" (which should be relabeled to "Endpoint Characterization" or "Target Endpoint Characterization" and produces various "Target Endpoint Profiles").
  • will be aligned with "(Target) Endpoint Classification" (the assessment of a collected Endpoint Attributes via "Target Endpoint Profiles").

[henkbirkholz]

Addressed in the draft, including the definitions of configuration & state themselves.