Subject: [sacm] Regarding SACM Terminology (was: sacm Digest, Vol 25, Issue 17)

From: "Brian Ford (brford)" <[email-masked]>
Date: Mon, 31 Mar 2014 17:56:20 +0000

SACM Team;

I have observations and questions regarding the definitions used to describe posture or posture attributes in Terminology for Security Assessment  (draft-ietf-sacm-terminology-03) and whether these definitions fit well into the security automation and continuous monitoring operations.  This message is regarding some of the 'Pre-defined Terms'.

Regarding 'Posture':

"Posture - Defined in [RFC5209] as "configuration and/or status of hardware or software on an endpoint as it pertains to an organization's  security policy." This term is used within the scope of this document to represent the state information that is collected from an endpoint (e.g. software/hardware inventory, configuration settings)."

Is posture the configuration of a device or what the security policy of an organization that use the device suggests that the device configuration should be ("as it pertains to the organization's security policy")?  Reading RFC 5209 one could come to the conclusion that an endpoint's posture is either right or wrong, or acceptable or unacceptable given an organizational security policy at the time of assessment.

Regarding 'Posture Attribute':

Posture Attributes -"Defined in [RFC5209] as "attributes describing the configuration or status (posture) of a feature of the endpoint.  For example, a Posture Attribute might describe the version of the operating system installed on the system."  Within this document this term represents a specific assertion about endpoint state (e.g. configuration setting, installed software, hardware).  The phrase "features of the endpoint" refers to installed software or software components."

Using the word 'attribute' I think that posture attributes should be variables that were derived by examining an endpoint.  In the STIX language I think of 'observables'.  On a computer running the Windows operating system an observable might be a specific registry variable setting or the physical address of the Ethernet adapter connected to Network 3.  I would suggest that posture attribute capture a variable setting without interpretation.

RFC 5209 defines 5 different types of attributes (assertion, posture, request, result, and remediation) based on different usage scenarios.

Regarding 'Misconfiguration':

misconfiguration -" A misconfiguration is a configuration setting that violates organizational security policies, introduces a possible security weakness in a system, or permits or causes unintended behavior that may impact the security posture of a system. (from NIST IR       7670) The misalignment of a unit of endpoint configuration posture relative to organizational expectations that is subject to exploitation or misuse."

I don't see how this 'misconfiguration' can be part of 'posture', or an attribute or an observable of a system.  A misconfiguration is something that is the result of some analysis performed by a program or an analyst and has to reference a specific policy that the configuration violates.  Is a misconfiguration a diff between what the policy should be and what it was discovered to be?

Regarding 'remediation':

"A remediation is defined as a security-related set of actions that results in a change to a computer's state and may consist of changes motivated by the need to enforce organizational security policies, address discovered vulnerabilities, or correct misconfigurations. (from NIST IR 7670)."

I'm concerned that this definition of remediation is too broad.  From what is written it would seem that remediation spans 'actions' that could include adding or removing hardware or software to or changing the configuration of a 'computer'.  I associate remediation with addressing vulnerabilities and correcting misconfigurations.  I don't view a remediation as being the word I'd use to describe changes made to enforce organizational policies.  Do you have to remediate all the computers that are your network if a decision is made to change software providers?  Clearly that could be an automation issue but is it a security automation issue?

I'd suggest that a remediation should be a specific action or set of actions that changes configuration to acceptable within organization' policy.

In general I think we all see the linkage between SACM and NEA.  I think there needs to be more review and discussion about the linkage between SACM and MILE and other security operations and incident response initiatives such as STIX and OpenIOC.

Liberty,

Brian

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, March 23, 2014 3:01 PM
To: [email-masked]
Subject: sacm Digest, Vol 25, Issue 17

Send sacm mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/sacm
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of sacm digest..."

---

From: Adam Montville <[email-masked]>
Date: Mon, 31 Mar 2014 14:37:24 -0500

Hi Brian, thanks for your questions.  I’ll provide some responses inline.  Others may also provide their perspectives, but hopefully I do well enough.

> Is posture the configuration of a device or what the security policy of an organization that use the device suggests that the device configuration should be ("as it pertains to the organization's s…

Posture is being used as a noun and can reference the actual state of the subject - in this case the endpoint.  Posture should not be construed as the configuration state of an endpoint as it should be, but rather as it is.  

Policy is a tricky term that has many meanings and, most important, very specific meanings in other areas of the IETF.  If you dig back into SACM’s BoF history you’ll find a presentation that shows a four-layered model with a vertical column adjacent to and straddling each layer.  The four layers are, from top to bottom: Operational Risk Management, IT Risk Management, Control Frameworks, and Controls.  The vertical column is labeled “Policy, Process, and Procedure” (or something similar).  This depiction can be viewed as a contextual guideline for SACM.  Then, when we use the term “policy” we are often using it to refer to that set of organizational mandates that are derived from the four risk management layers.  This distinction is important in the SACM context.

> RFC 5209 defines 5 different types of attributes (assertion, posture, request, result, and remediation) based on different usage scenarios.

Generically, an attribute is simply a characteristic - it’s some thing that is regarded as a quality or feature of another thing.  In the STIX language, an observable can be considered an attribute of the thing on which the observable was observed.  To me, these terms (observable and attribute) can be considered synonymous.  

> I don't see how this 'misconfiguration' can be part of 'posture', or an attribute or an observable of a system.  A misconfiguration is something that is the result of some analysis performed by a p…

Generally, the endpoint attributes we look at are posture attributes and these are “configuration items” (to load another term on the pile).  A misconfiguration is simply an attribute set to an organizationally-impermissible value (i.e. set against policy - see comment above regarding policy in the SACM context).  

> I'd suggest that a remediation should be a specific action or set of actions that changes configuration to acceptable within organization' policy.

This might be a good suggestion.  We could get into a semantic discussion about whether a mitigation is a form of remediation, but for SACM’s immediate purposes remediation is out of scope.  This will be important later in life.  For what it’s worth, I think the term “remediation” probably has origins in the IT audit domain where we talk about “findings” and such.  An auditor would probably provide a list of findings and each finding would need to be “remediated” in a general sense, which is just another way of saying that the finding needs to be addressed in some way.  But, as I said before, remediation is out of scope for our present charter.

> In general I think we all see the linkage between SACM and NEA.  I think there needs to be more review and discussion about the linkage between SACM and MILE and other security operations and incid…

The links between SACM and MILE and STIX and OpenIOC and NEA and others are very important.  Each provides at least one part of a “whole” set of automated information security tools.  Ideally, each should inform the others - you raise a great point.  In an ideal world, we’d all have a common vocabulary from which we operate, but that’s not the case.  

What sort of review/discussion would you envision taking place and to what end?

> _______________________________________________
> sacm mailing list
> [email-masked]