Subject: [sacm] Ongoing Scope Discussion

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 25 Mar 2015 14:12:35 -0500

During yesterday’s first side meeting we were talking about how to increase focus and prioritize work.  

Part of that discussion revealed an unshared understanding of what “posture” is within the context of this working group.  On one side, some considered configuration items to be part of posture, and on the other side, some considered operationally-related state information to be included.

We plan to continue this discussion during our side meeting tomorrow, but I wanted to shoot this out to the list to get more opinions about the discussion and start driving it to some conclusion.

An example (from yesterday’s meeting).  Endpoint protection software is installed and configured to scan daily.  We all agreed that we would like to standardize mechanisms allowing us to check that the endpoint protection software is properly configured (i.e. the configuration item “scan frequency” is set to “daily”).   We all did not agree that validating such scanning has occurred would be in scope of our standardization work.  This could be done easily (provided the endpoint protection software is configured to log and logging is working as we expect) by checking for the presence of a specific log entry with a timestamp not older than X, but it’s not really assessing the configuration item - it’s validating the effect setting the configuration appropriately has.

I believe the question is really this: Is validation of configuration effect in scope for SACM?

To help this discussion, let’s consider two other validation examples.  Security configuration guides often include recommendations related to file permissions: Ensure “foo.conf" permissions are set to “700” (or at least ensure "go-rwx").  We check for configuration correctness by looking at the permissions.  Do we want to validate the configuration is effecting expected behavior by adding a user to foo.conf’s group and trying to read the file?  Do we then attempt to write?  To execute?  Do we do the same as “world”?

Another example.  Consider transport security recommendations present in many security configuration guides.  For example, there is a CIS recommendation to “Restrict Weak SSL Ciphers” in Apache HTTP Server 2.4.  The remediation for this recommendation says to set “SSLHonorCipherOrder" to “On” and to set “SSLCipherSuite" to “ALL:!EXP:!NULL:!ADH:!LOW:!SSLv2:!MD5:!RC4”.  These are text file configuration items, which are easy enough to check and would reasonably be considered in scope.  As part of determining endpoint posture, do we also want to validate that these restrictions are in place? (Or, do we want to connect to the server and try to negotiate one or more out-of-spec cipher suites?)  

In some cases, validating the effect of configuration may be achievable at least by inference (i.e. determine the presence of a particular line in a log file).  In other cases, validating the effect of configuration would require interacting with the system on a functional/behavioral level and seems better suited for the domain of penetration testing - also an arguably important facet of a security program.

Are we using the right language for this discussion?  Instead of talking about “configuration items” and “validation” for a scope discussion, should we instead be classifying the mechanisms we expect to address when collecting attributes?  How could use of the term “state” help (or not) this discussion?

Adam

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 25 Mar 2015 19:09:25 -0400

If it's a capability used to evaluate the security posture of an 
endpoint, then yes, it's in scope for SACM.

Seems like a non-issue though.

If SACM is going to defer to a check process, like SCAP, then SACM is 
stuck with whatever capabilities SCAP provides.

If and when SACM is in the position to define its own checking system 
(or enhancing an existing one), then it shouldn't be a matter of trying 
to define which security-related capabilities are in scope or not.  It 
should be a matter of prioritizing which capabilities provide enough 
value to warrant defining and implementing.

There's also another topic in here:  types of actions.  The one you 
describe of creating a user means that the SACM component has the 
ability to make changes on the endpoint, and that's something that's 
just asking to be abused.  That's not to say that that kind of testing 
should be avoided, just that actions that require making changes to the 
endpoint or that have the possibility of disrupting an endpoint need to 
be identified as such so users can choose to not use them.

--gun

On 3/25/2015 3:12 PM, Adam W. Montville wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Ron Colvin <[email-masked]>
Date: Wed, 25 Mar 2015 20:56:58 -0400

My priority is always visibility rather than a capability to push 
configurations and "manage" devices. I certainly understand a wariness 
of the often misused "push first, and ask questions later" school of 
security. There is certainly a growing use of partner and personal 
devices where a configuration change could be a nightmare. For devices 
where the infrastructure or service provider is doing the provisioning 
the devices belong to them rather than the users and the ability to 
validate controls even by modifying a device is highly desirable.

On 3/25/15 7:09 PM, Gunnar Engelbach wrote:
> should be avoided, just that actions that require making changes to 
> the endpoint or that have the possibility of disrupting an endpoint 
> need to be identified as such so users can choose to not use them. 

-- 

********************************************************
Ron Colvin CISSP, CAP, CEH
Certified Security Analyst
NASA - Goddard Space Flight Center
<[email-masked]>
Direct phone 301-286-2451
NASA Jabber ([email-masked]) AIM rcolvin13
NASA LCS ([email-masked])
********************************************************

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 25 Mar 2015 21:01:21 -0500

> On Mar 25, 2015, at 6:09 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> If it's a capability used to evaluate the security posture of an endpoint, then yes, it's in scope for SACM.
> 
> If SACM is going to defer to a check process, like SCAP, then SACM is stuck with whatever capabilities SCAP provides.
> 
> If and when SACM is in the position to define its own checking system (or enhancing an existing one), then it shouldn't be a matter of trying to define which security-related capabilities are in scope or not.  It should be a matter of prioritizing which capabilities provide enough value to warrant defining and implementing.

Would another way to say this be to prioritize based on mechanisms of collection rather than type of device?

> 
> 
> There's also another topic in here:  types of actions.  The one you describe of creating a user means that the SACM component has the ability to make changes on the endpoint, and that's something that's just asking to be abused.  That's not to say that that kind of testing should be avoided, just that actions that require making changes to the endpoint or that have the possibility of disrupting an endpoint need to be identified as such so users can choose to not use them.

To be clear, creating a user to validate that permissions in fact work as configured was an example of validation versus configuration in an effort to help us determine to what degree of validation we feel should be in scope for this effort.  I was, perhaps poorly, trying to demonstrate that the concept of validation is a continuum more than it is binary.  It was not a suggestion that SACM should require that a SACM component have the ability to take action in this phase (we hope to eventually get there with remediation, but that’s well down the line at this point).

If, however, we were specifying actions, we we would certainly need to provide some sort an “opt out” mechanism.

---

From: "Lorenzin, Lisa" <[email-masked]>
Date: Thu, 26 Mar 2015 12:27:33 +0000

Hi Adam,

As one of the people with the unshared understanding (which I think is a great way to describe the situation!), I have a couple of thoughts here.

My personal impression was that I didn't hear anyone arguing that either software inventory or software configuration were not part of posture - the question was around endpoint operational state.  Sounded to me like there was one group of people who felt that endpoint state should not be included in posture, and another group of people (including myself) who feel that posture is inseparable from endpoint state.

Terminology is critical here.  Someone[1] mentioned yesterday that NEA defines posture as endpoint configuration and/or status, which sent me digging in RFC 5209.  The terminology definitions in section 2 explicitly include "status" (which I think is a more clear term than "state") in Posture, Posture Attribute, and Attribute[2].   In addition, section 5.3.1 gives an example of a posture attribute sent by a NEA client, the status of a host-based firewall, that includes if-running, as well as vendor and version)[3].

I think that "validating" is not what's happening here.  When gathering configuration information from an endpoint, we don't call that "validating" the configuration, we call it "collecting" endpoint configuration information.  By the same token, I believe that checking scan status doesn't mean checking to see whether the endpoint has been scanned in accordance with its configuration - it means checking when was the last time the endpoint was scanned. That's not "validating" the endpoint status, it's just "collecting" endpoint status information.

I think the distinction is key because "validating" endpoint status implies enough intelligence to compare status to configuration, whereas "collecting" endpoint status (to me) just implies gathering additional information about the endpoint which can be provided to an evaluator.

In your scanning example below, I would expect the collector to collect three posture attributes (among whatever others) - software inventory information (what scanning software is installed), software configuration information (how the scanning software is configured), and status information (when the endpoint was last scanned).  I would _not_ expect the collector to compare the endpoint status information to the configuration information and return any kind of validation - that work belongs at the evaluator.  So the collector is just gathering status information in the same way that it gathers configuration or inventory information, and making it all available to the evaluator for validation / evaluation.

I believe that simplifies the problem, because status is just another posture attribute.  We've never claimed to be trying to standardize every possible posture attribute!  We're giving examples of posture attributes, and hopefully standardizing a base set to ensure a common interoperability base, but we assume the requirement for extensibility so that people can use SACM to collect, communicate, and verify attributes we never imagined.  Status should be no different - there is probably a base set that is of broad enough interest that it's useful to standardize (things like status of anti-virus software - running or not, real-time protection enabled, signatures up to date; status of scanning software - date of last scan, scan results; status of host-based firewall software - running or not, etc.)

My background from both my customer interactions (I'm a solution architect for a vendor whose NAC and SSL VPN products offer endpoint compliance checking) and my standards-group interactions so far (I've been an active contributor to the TNC WG, which contributed the core endpoint compliance interfaces that were the starting point for the NEA protocols, and actively followed the NEA process as a lurker) is that endpoint operational status is a fundamental aspect of endpoint posture.  If we put out a set of standards that don't address endpoint status as part of posture, we will be in conflict with the prior IETF standards in this space (NEA) and - more importantly - I believe that the problem we're solving will be so far from the real-world problem that commercial end users _want_ to solve, that our work here will be out of step with the needs of a significant portion of the community intended to benefit from it, which will reduce motivation to adopt these standards.

							Regards,

								Lisa

1: Sorry I can't attribute correctly - couldn't distinguish voices for the people in the room.

2: Attribute - Data element including any requisite meta-data describing
      an observed, expected, or the operational status of an endpoint
      feature (e.g., anti-virus software is currently in use).
      Attributes are exchanged as part of the NEA protocols (see section
      5.2).  NEA recognizes a variety of usage scenarios where the use
      of an attribute in a particular type of message could indicate:
         o previously assessed status (Assertion Attributes),
         o observed configuration or property (Posture Attributes),
         o request for configuration or property information (Request
           Attributes),
         o assessment decision (Result Attributes), or
         o repair instructions (Remediation Attributes).
      The NEA WG will standardize a subset of the attribute namespace
      known as standard attributes.  Those attributes not standardized
      are referred to in this specification as vendor-specific.

Posture - Configuration and/or status of hardware or software on an
      endpoint as it pertains to an organization's security policy.

   Posture Attributes - 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.

3: 5.3.1. Attributes Normally Sent by NEA Client:
      o Posture Attributes - Attributes and values sent to report
        information about a particular aspect (based on semantic of the
        attribute) of the system.  These attributes are typically sent
        in response to Request Attributes from the NEA Server.  For
        example, a set of Posture Attributes might describe the status
        of the host-based firewall (e.g., if running, vendor, version).
        The NEA Server would base its decision on comparing this type o
        attribute against policy.

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Adam W. Montville
Sent: Wednesday, March 25, 2015 3:13 PM
To: [email-masked]
Subject: [sacm] Ongoing Scope Discussion

Adam

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 26 Mar 2015 14:07:44 +0100

Hi,

this is a derived topic on a tiny detail taken from the scope discussion 
that does not impact the scope discussion at all, I think :)

State and Configuration is differentiated in YANG. My personal 
impression is that--outside of NEA and SACM--"configuration & state" is 
the more common differentiation than "configuration & status".

On one hand, for more detail on operational state, please look at 
https://tools.ietf.org/html/draft-openconfig-netmod-model-structure-00 
or https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00, 
for instance.

On the other hand, RFC 7223 describes "state data" as "status information".

In essence (to keep it short), state is a result of "active" 
configuration. Configuration can be distinguished in... "stored" and 
"active" configuration (which might differ). An active (running) 
configuration therefore might be "in the middle of" stored configuration 
and state. Although it can be volatile, active configuration is not 
state in my opinion.

In general, configuration is more persistent then state. If state is 
made persistent (e.g. saving the state of a running VM instead of 
shutting it down) it tends to out-date quite fast. Typically, this is 
not true for configuration.

Best,

Henk

On 03/26/2015 01:27 PM, Lorenzin, Lisa wrote:
> Someone[1] mentioned yesterday that NEA defines posture as endpoint configuration and/or status, which sent me digging in RFC 5209.  The terminology definitions in section 2 explicitly include "status" (which I think is a more clear term than "state") in Posture, Posture Attribute, and Attribute[2].

---

From: "Lorenzin, Lisa" <[email-masked]>
Date: Thu, 26 Mar 2015 17:25:24 +0000

Adam's suggestion to prioritize by methods of collection rather than type of device not only makes sense to me, I thought it was what we had already agreed upon.  We were going to prioritize internal local collectors (software running on the endpoint gathering data about the endpoint - e.g. a NEA Client) and remote collectors (software running remotely to the endpoint, but connecting to a management interface on the endpoint to gather data about the endpoint - e.g. an SNMP walker) for this phase and then look at external remote collectors (IPS, profiler, etc.) in the next phase.

If we're focusing on the type of collector rather than the type of device, then I don't see any reason to explicitly exclude mobile devices from our immediate focus.  If a device runs an internal local collector, that collector can send us data whether it's on a mobile or desktop/laptop OS.  From a collection perspective, I don't see how a mobile device managed by an MDM is any different from a network infrastructure device (like a switch) managed by a network management system that gathers data from the switch via SNMP and syslog.

Regards,
Lisa

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 26 Mar 2015 13:30:40 -0400

> Would another way to say this be to prioritize based on mechanisms of collection rather than type of device?

That's a thought, but not the one I was going for.  It could also be 
useful for each collection action to include it's own categorization 
information.

But as far as prioritization goes I would think the goal would be to be 
able to do a thorough security evaluation using methods that have the 
least chance of having a negative operational impact and requiring the 
fewest number of collector implementations.

Since it only takes a single vulnerability to compromise a system, being 
thorough is of highest priority, but we must also be realistic in that 
this is not going to be achieved.

Going back to your user permission example, being able to collect file 
permissions is a safe action, requires little resources on the endpoint, 
and has utility beyond your example[1].  The behavioral test of creating 
a user and checking for file access is more invasive to the system, 
harder to develop, and doesn't significantly increase the quality of 
collected data[2].  It would be a higher priority to focus on endpoint 
attributes not currently being collected, with an emphasis on those that 
have the potential of a significant security impact.

But this is a rather academic topic.  Right now SACM doesn't have 
authority over any methodology for performing the actual collection and 
application of endpoint attributes.  When it gets to the point of doing 
that kind of governance, then this becomes a consideration.

[1] And is likely a subset of data collected by a single more general 
operation, such as "file attributes".

[2] What this particular example is actually doing is testing the 
ability of the operating system to (a) correctly report file permissions 
when queried and (b) properly enforce file permissions. I would expect 
that kind of testing to be done prior to a product release (or a 
validation process such as FIPS) and not against all installed copies of 
that product.

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 26 Mar 2015 13:01:46 -0500

Lisa, thank you for your thoughtful and detailed response.  I believe we are in agreement nearly everywhere.  I do prefer the term “state” over “status”, which is my opinion as a contributor not a chair. 

> On Mar 26, 2015, at 7:27 AM, Lorenzin, Lisa <[email-masked]> wrote:
> 
> Hi Adam,
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 26 Mar 2015 15:01:29 -0400

I see what you are saying, and I agree to a certain point, but not 
completely.  For the simple reason that defining what attribute to 
collect and how to interpret that in determining the security posture of 
an endpoint are not homogeneous actions.  I'll try to explain what I mean.

Take a simple example of writing a test to verify that enforcement of 
the minimum password length is compliant to the local security policy.  
Directing collection for this piece of data is not the same for SNMP, 
NEA, native API, etc., and interpreting the collected value is not the 
same for Windows, Unix, etc.

At some point I need to actually *do* something with SACM.  Namely, 
decide if my endpoints are compliant with security policy or not. So I 
need to write that policy out in a format that can be automated.  But if 
you look at the cross product of endpoint types (Windows, OSX, JunOS, 
etc) versus collection methods (SNMP, NEA, native API, WMI, CMDB query, 
etc) that's a lot of variations that have to be written for every policy 
item, and it expands every time a new collection method and endpoint 
type needs to be added.

So, let's imagine that there's a standardized "language" used to express 
determination of the security state for an endpoint:  what to collect 
for any particular item and how to use the collected value to make a 
determination of the state against security policy. In this model there 
would be a boundary for each collection type where the standardized 
policy expression is translated into a format that can be used by that 
collection method, and then the result then translated back into the 
generic format so that policy compliance can be determined.  As note of 
caution, though, the further down this translation occurs, the greater 
the impact in deploying updates.

That creates a degree of homogeneity and means that any networked device 
can be a SACM participant as long as (a) there is some mechanism to 
collect attributes from that device type and (b) a translator is 
implemented that can bridge between the policy expression language and 
the method of collection.

But determination of state is also not a generic operation.  For 
example, determining which users are not administrators is not the same 
for Windows and MPE/iX, let alone determining if non-administrators have 
access to critical system files, nor is the list of policy items 
consistent between all endpoint types.  Thus, the language used to 
codify policy needs to have specific support for each endpoint type to 
be evaluated.

So, if SACM goes the route where it needs to concern itself with the 
collection methodology, that's an approach that will cause it to 
collapse under its own weight.  If, instead, SACM focuses on a 
standardized policy expression language, then collection method becomes 
a non-issue:  support for any method of collection/endpoint type is 
merely a matter of somebody being willing to build that piece of software.

So, yeah, SACM in general excludes no device types.  There's some very 
real work that needs to get done before any particular endpoint type can 
be supported.  But once the policy expression language exists for that 
endpoint type, any number of collection methods can be implemented 
relatively easily.

---

From: "Lorenzin, Lisa" <[email-masked]>
Date: Thu, 26 Mar 2015 19:50:18 +0000

Thanks, Adam!

I don't feel strongly about "state" vs "status".  I do think we should clearly define it in the terminology doc either way. :) And if we do go with "state" we might also want to note that we intend equivalent meaning to the NEA term "operational status".

Regards,
Lisa

---

From: Michael Hammer <[email-masked]>
Date: Thu, 26 Mar 2015 23:17:58 +0000

Just lurking  but...
Would the following be the intent:

State:  boots and brass not polished, haircut non-regulation
Status:  not fit for duty

That is, one is pure observables, the other is an assessment.

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Lorenzin, Lisa
Sent: Thursday, March 26, 2015 3:50 PM
To: Adam W. Montville
Cc: [email-masked]
Subject: Re: [sacm] Ongoing Scope Discussion

Thanks, Adam!

Regards,
Lisa