Subject: [sacm] Use Case Discussion: Suspicious Endpoint Behavior

From: Adam Montville <[email-masked]>
Date: Mon, 15 Jul 2013 20:56:47 +0000

So, the Use Case discussion has been ongoing.  David Harrington submitted a 05 draft (thank you!), so we have a lot to talk about.  Steve Hanna was going to craft some additional use cases, and I offered to help.  Here's what I've come up with after Steve asked for the assist.

It's detailed, and there's another one coming after this one...  But, I think the detail might be useful.  When I think "use case" and that we want to get down to brass tacks, then this is the level of detail I think about.  At the very least, if it is found to be too detailed, then we have established some boundaries where we have examples of what may not be detailed enough (the pre 05 versions of the use case draft) and this (and following) example for what may be too detailed.

Nevertheless, I think it's probably easier to summarize from the detail than it is to derive details from the summary...

Use Case Name: Suspicious Endpoint Behavior

Description: 
This Use Case describes the collaboration between specific participants in an information security system specific to detecting a connection attempt to a known-bad Internet host by a botnet zombie that has made its way onto an organization's Information Technology systems.  The primary human actor is the Security Operations Center Analyst, and the primary software actor is the configuration assessment tool.  Note, however, the dependencies on other tools, such as asset management, intrusion detection, and messaging.

Actors: 

   * Security Operations Center (SOC) Analyst, 
   * Information Security Officer, 
   * System Owner
   * Organizational Unit Leader

Preconditions:

   * Organizational Security Policy Exists
   * Security Policy specifies appropriate asset management capabilities (i.e. categorization of endpoints)
   * Security Policy specifies endpoint configuration baseline for asset categorization
   * The Organization keeps a list of known-bad Internet hosts
   * The Organization associates owners who are individuals with endpoints
   * The Organization associates organizational units with endpoints

Postconditions:

   * Endpoint configuration has been assessed [1]
   * Results have been conveyed to scan requester

Primary Path:

  1. At 03:46 UTC an organization's Network Intrusion Detection System (NIDS) sees an IP packet with a destination IPv6 address existing on a blacklist of known botnet command and control (C2) servers.

  2. The NIDS sends an alert to the SOC Analyst.

  3. The SOC Analyst uses the information captured in the alert (IP packet and reason for the flag) to look up the endpoint in the organization's asset inventory system and discovers that the endpoint is a Windows Server 2008 R2 Member Server playing the role of a File Server

  4. The SOC Analyst also verifies that the IPv6 address cited by the NIDS is, in fact, on the blacklist for known C2 servers.

  5. At this point, the SOC Analyst switches over to the organization's configuration assessment tool

  6. The SOC Analyst locates the offending endpoint in the configuration assessment tool's endpoint catalog [2]

  7. The SOC Analyst then initiates an immediate and complete endpoint assessment to determine if the endpoint has experienced any configuration drift [3].

  8. The configuration assessment tool:

  9. 
    a. Performs a preliminary asset inventory scan on the offending endpoint, which results in a list of installed software [4][5]
    b. Performs a comparison between the last known asset inventory and the present asset inventory and notes any differences
    c. Searches it's local content repository for appropriate configuration baselines for the operating system of the offending endpoint and for each installed piece of software
    d. Upon aggregating the set of applicable configuration baselines, the configuration assessment tool then connects to and queries the organization's configuration content repository for newer baselines that may exist.
    e. If a new baseline exists, then it is returned by the configuration content repository.

  10. The configuration management tool, having the set of updated baselines, initiates a scan against the offending host, which yields a result set.

  11. The configuration management tool displays scan results to the SOC Analyst, which show that three new pieces of software have been installed on the offending endpoint where one piece of software is not on the authorized software list, and that several configuration items were out of compliance with the organization's established baselines.

  12. The SOC Analyst reviews the information for accuracy and to plan next steps before sending the report to the responsible Information Security Officer, accountable System Owner, and the Organizational Unit Leader.

A Note On Alternative Paths, Preconditions, and Postconditions:
There are likely to be many points of optimization and optional paths.  For example, a configuration assessment tool might provide a "quick glance" look at the most recent scan history for the offending endpoint.  A SOC Analyst might then elect not to run a new scan (i.e. the offending endpoint is known to be out of compliance, so why run a new scan?).  Another point might be that the offending endpoint is, at present, not authorized to be on the network, in which case it is very likely not to exist in the configuration assessment tool's endpoint catalog.

As with alternative paths, pre-/post-conditions can vary widely.  Consider that this description likely represents an organization on the mature side of managing information security.  Many organizations do not have a Security Operations Center, nor do they necessarily monitor their network.  It may be the case that a log management process has detected the blacklisted connection attempt  through audit trail monitoring.  Or, it may be the case that a shared indicator of compromise has been used to detect the offending endpoint.

-------------------
[1] I am assuming at this point that "configuration assessment" has been defined and will be understood by the reader.  What I consider to be "assessment" is that the baseline has been obtained, send to the scanning implementation, endpoint configuration item values have been harvested, endpoint configuration item values have been compared against baseline, and results stored/forwarded as appropriate for the use case.

[2] An "endpoint catalog" is intended to convey nothing more than the notion that configuration assessment tools are likely to have some method of listing, enumerating, or aggregating endpoints under configuration management. 

[3] It may not be necessary to specify what we mean by "complete" or the order in which scanning operations take place.  In this particular scenario, I thought it might be useful to illustrate that "scan levels" exist on a continuum.  

[4] Remember that the configuration assessment tool has knowledge of the offending endpoint so running a preliminary inventory scan is reasonable at this point.

[5] The mechanism of scan could be agent-based or remote, so details of how a scan happens are omitted here.  A more granular partition of the process is required for further details.

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 23 Jul 2013 18:28:27 +0000

Comments inline. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adam Montville
> Sent: Monday, July 15, 2013 4:57 PM
> To: [email-masked]
> Subject: [sacm] Use Case Discussion: Suspicious Endpoint Behavior
> 
> So, the Use Case discussion has been ongoing.  David Harrington submitted a
> 05 draft (thank you!), so we have a lot to talk about.  Steve Hanna was going
> to craft some additional use cases, and I offered to help.  Here's what I've
> come up with after Steve asked for the assist.
> 
> It's detailed, and there's another one coming after this one...  But, I think the
> detail might be useful.  When I think "use case" and that we want to get
> down to brass tacks, then this is the level of detail I think about.  At the very
> least, if it is found to be too detailed, then we have established some
> boundaries where we have examples of what may not be detailed enough
> (the pre 05 versions of the use case draft) and this (and following) example
> for what may be too detailed.
> 
> This Use Case describes the collaboration between specific participants in an
> information security system specific to detecting a connection attempt to a
> known-bad Internet host by a botnet zombie that has made its way onto an
> organization's Information Technology systems.  The primary human actor is
> the Security Operations Center Analyst, and the primary software actor is the
> configuration assessment tool.  Note, however, the dependencies on other
> tools, such as asset management, intrusion detection, and messaging.
> 
> 
> Actors:
> 
>   1. At 03:46 UTC an organization's Network Intrusion Detection System
> (NIDS) sees an IP packet with a destination IPv6 address existing on a blacklist
> of known botnet command and control (C2) servers.
> 
>   3. The SOC Analyst uses the information captured in the alert (IP packet and
> reason for the flag) to look up the endpoint in the organization's asset
> inventory system and discovers that the endpoint is a Windows Server 2008
> R2 Member Server playing the role of a File Server
> 
>   4. The SOC Analyst also verifies that the IPv6 address cited by the NIDS is, in
> fact, on the blacklist for known C2 servers.
> 
>   7. The SOC Analyst then initiates an immediate and complete endpoint
> assessment to determine if the endpoint has experienced any configuration
> drift [3].

Wouldn't it be better if instead of requesting a batch assessment, that the endpoint published configuration changes as they happened?  This may detect compromise and may avoid the endpoint eventually lying about its configuration when the scan occurs. In this case the SOC Analyst can query a CMDB containing the current and historically related reported configurations for the endpoint skipping to step 11. Extending this, if the system had a mechanism to determine what changes are authorized, unauthorized changes can be routed to the SOC Analyst as a potential security event starting step 1.

Performing scans in a periodic way is not continuous or very effective.  For scanning to be effective here, the scanning rate needs to be twice as frequent as the rate of change to have a chance of detecting a sophisticated attacker. Anything happening between samples/scans can compromise the endpoints ability to give truthful answers. This is a good case for event-driven data reporting where the changes is reported as soon as it happens. This type of reporting has a chance of occurring before the attacker can compromise the collector.

>     a. Performs a preliminary asset inventory scan on the offending endpoint,
> which results in a list of installed software [4][5]
>     b. Performs a comparison between the last known asset inventory and the
> present asset inventory and notes any differences
>     c. Searches it's local content repository for appropriate configuration
> baselines for the operating system of the offending endpoint and for each
> installed piece of software
>     d. Upon aggregating the set of applicable configuration baselines, the
> configuration assessment tool then connects to and queries the
> organization's configuration content repository for newer baselines that may
> exist.
>   10. The configuration management tool, having the set of updated
> baselines, initiates a scan against the offending host, which yields a result set.
> 
>   11. The configuration management tool displays scan results to the SOC
> Analyst, which show that three new pieces of software have been installed
> on the offending endpoint where one piece of software is not on the
> authorized software list, and that several configuration items were out of
> compliance with the organization's established baselines.
> 
>   12. The SOC Analyst reviews the information for accuracy and to plan next
> steps before sending the report to the responsible Information Security
> Officer, accountable System Owner, and the Organizational Unit Leader.
> 
> 
> There are likely to be many points of optimization and optional paths.  For
> example, a configuration assessment tool might provide a "quick glance" look
> at the most recent scan history for the offending endpoint.  A SOC Analyst
> might then elect not to run a new scan (i.e. the offending endpoint is known
> to be out of compliance, so why run a new scan?).  Another point might be
> that the offending endpoint is, at present, not authorized to be on the
> network, in which case it is very likely not to exist in the configuration
> assessment tool's endpoint catalog.

If the endpoint is joining the network for the first time, this may be the case.  In the future, historic info might be available.

> As with alternative paths, pre-/post-conditions can vary widely.  Consider
> that this description likely represents an organization on the mature side of
> managing information security.  Many organizations do not have a Security
> Operations Center, nor do they necessarily monitor their network.  It may be
> the case that a log management process has detected the blacklisted
> connection attempt  through audit trail monitoring.  Or, it may be the case
> that a shared indicator of compromise has been used to detect the offending
> endpoint.
> 
> 
> -------------------
> [1] I am assuming at this point that "configuration assessment" has been
> defined and will be understood by the reader.  What I consider to be
> "assessment" is that the baseline has been obtained, send to the scanning
> implementation, endpoint configuration item values have been harvested,
> endpoint configuration item values have been compared against baseline,
> and results stored/forwarded as appropriate for the use case.
> 
> 
> [2] An "endpoint catalog" is intended to convey nothing more than the
> notion that configuration assessment tools are likely to have some method
> of listing, enumerating, or aggregating endpoints under configuration
> management.
> 
> 
> [3] It may not be necessary to specify what we mean by "complete" or the
> order in which scanning operations take place.  In this particular scenario, I
> thought it might be useful to illustrate that "scan levels" exist on a
> continuum.
> 
> 
> [4] Remember that the configuration assessment tool has knowledge of the
> offending endpoint so running a preliminary inventory scan is reasonable at
> this point.
> 
> 
> [5] The mechanism of scan could be agent-based or remote, so details of
> how a scan happens are omitted here.  A more granular partition of the
> process is required for further details.
> 
> This message and attachments may contain confidential information.  If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited.  Please notify the sender immediately and permanently
> delete the message and any attachments.
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 23 Jul 2013 15:22:48 -0400

> Comments inline.

<snip>

>
> Wouldn't it be better if instead of requesting a batch assessment, that the endpoint published configuration changes as they happened?  This may detect compromise and may avoid the endpoint eventually lying about its configuration when the scan occurs.

Yes, it would be better, but I think that's a different use case.  It's 
the one I think we want to push for, but we have to first support the 
traditional periodic full and incremental assessments as a path to that.

>> In this case the SOC Analyst can query a CMDB containing the current and historically related reported configurations for the endpoint skipping to step 11. Extending this, if the system had a mechanism to determine what changes are authorized, unauthorized changes can be routed to the SOC Analyst as a potential security event starting step 1.

The data in the CMDB is only going to be as reliable as the collection 
method.  The endpoint can still lie about a change (or fail to report a 
change).  Further, the data in the CMDB is only as current as the last 
collection and might not represent the actual state of the endpoint.

I definitely think leveraging a CMDB when available is a net positive 
and should be supported, but it also creates other problems and should 
not be *required*.

> Performing scans in a periodic way is not continuous or very effective.  For scanning to be effective here, the scanning rate needs to be twice as frequent as the rate of change to have a chance of…

Just to be clear, Dave, the rule you refer to here works for things like 
determining the sample rate for audio, but does not apply here.

What we want to minimize is the window of opportunity to exploit an 
exposure, which is the amount of time between when a configuration item 
changed (or the announcement of a new vulnerability) and when it is 
detected and remediated.  The *average* time between when an item 
changed and when it is detected would be 1/2 the sampling rate.

If your "rate of change" is, for example, monthly, and you therefore set 
your periodic rescan for every two weeks, you still have an average time 
of exposure of a week and a worst case of two weeks.

Which only supports further your focus on bottom-up change detection 
from the endpoints.

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 23 Jul 2013 21:20:46 +0000

Comments inline.

> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2013 3:23 PM
> To: Waltermire, David A.
> Cc: Adam Montville; [email-masked]
> Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior
> 
> > Wouldn't it be better if instead of requesting a batch assessment, that the
> endpoint published configuration changes as they happened?  This may
> detect compromise and may avoid the endpoint eventually lying about its
> configuration when the scan occurs.
> 
> 
> Yes, it would be better, but I think that's a different use case.  It's the one I
> think we want to push for, but we have to first support the traditional
> periodic full and incremental assessments as a path to that.

I disagree with this being a different use case.  It is most certainly a different technique for achieving/implementing the use case, but the use case "detecting suspicious endpoint behavior" is the same as are the desired outcomes.

I am not advocating that we drop support for periodic scanning.  If fact, I believe strongly that support for it is important for a variety of reasons. My concern is that we rely too much on periodic scanning to detect things that it is not well suited to address. Event-driven detection of changes, both software and configuration, is critical for responding in a timely fashion to security relevant events such as those that relate to unauthorized or malicious changes. We need to simultaneously support periodic and event-driven approaches in the standards we produce. For this to work right, we can't bolt event-driven capabilities on after the fact.  This needs to be considered as part of our architectural design and protocol adoption/design. 

> >> In this case the SOC Analyst can query a CMDB containing the current and
> historically related reported configurations for the endpoint skipping to step
> 11. Extending this, if the system had a mechanism to determine what
> changes are authorized, unauthorized changes can be routed to the SOC
> Analyst as a potential security event starting step 1.
> 
> The data in the CMDB is only going to be as reliable as the collection method.
> The endpoint can still lie about a change (or fail to report a change).  Further,
> the data in the CMDB is only as current as the last collection and might not
> represent the actual state of the endpoint.

This is all true for both event-driven and periodic techniques. ;-) Many organizations are going to want a historic perspective regardless of the how the data is collected. This does bring up the need to capture the context of collection, but that is a different discussion.

Event-driven collection is better for things that the attacker cannot silence, at least not initially until they achieve an appropriate level of privilege. For example, they may be able to write to configurations using application flaws, but they might not be able to prevent notifications of change events. Another example might be detecting signs of malware persistency (e.g., configuring it to load on boot) prior to a reboot.

> I definitely think leveraging a CMDB when available is a net positive and
> should be supported, but it also creates other problems and should not be
> *required*.

None of what we do will be required; it will all be voluntary. They key is to enable the endpoint to publish changes based on events. How that published data gets processed and persisted is a downstream concern. The architecture should allow for a variety of solutions that handle the info in various ways providing organizations and vendors with some flexibility in deployed architectures. What we want is a reasonable degree of interoperability with regards to the individual components.

> > Performing scans in a periodic way is not continuous or very effective.  For
> scanning to be effective here, the scanning rate needs to be twice as
> frequent as the rate of change to have a chance of detecting a sophisticated
> attacker. Anything happening between samples/scans can compromise the
> endpoints ability to give truthful answers. This is a good case for event-driven
> data reporting where the changes is reported as soon as it happens. This
> type of reporting has a chance of occurring before the attacker can
> compromise the collector.
> 
> If your "rate of change" is, for example, monthly, and you therefore set your
> periodic rescan for every two weeks, you still have an average time of
> exposure of a week and a worst case of two weeks.

It doesn't apply if you define the window as the organizational change window.  It does apply if you think about it as the attack window. Most attacks will go unnoticed if the scanning occurs hourly.  In this scenario the attacker can get in, make changes, exfiltrate information, and then cleanup restoring things to the previous state within the hour period.

> Which only supports further your focus on bottom-up change detection from
> the endpoints.

Yes. I want to make sure that the standards we produce don't expose organizations unnecessarily if there is a more effective way. ;-) I am pushing to expand the scanning mindset to think about how we can approach this problem space in a way that enables a variety of techniques. The legacy work that has been done in this space gets us a good way there.  We have a variety of mechanisms that enable classes of configurations that are security relevant to be identified and described.  These can be used to identify relevant change events. What is missing are the standards that describe how you implement protocols that enable endpoint data exchange that support both scanning tasks and event driven publication. There are existing protocols such as NEA that can enable both techniques if we do the work to identify the specifics of messaging. I would expect a similar approach would also enable incremental scan results as well.

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 23 Jul 2013 18:49:00 -0400

Alrighty, some semantic quibbles, but I think we're both on the same page.

1) Endpoint-originated event-driven assessments are the necessary end 
state.  The solution needs to be designed for that up front.

2) CMDB's are good but not essential.

3) The standards describe a minimal set of data exchanges and 
operations, which can be organized into basic logical entities (such as 
Sensor or Evaluator), but in actual usage these can be mixed and matched 
to meet the actual needs.

Does anybody have an appreciable difference from that?

---

From: Rainer Enders <[email-masked]>
Date: Wed, 24 Jul 2013 18:46:18 +0200

IMHO it is important to have a self-contained endpoint approach in which
the endpoint is capable of maintaining its own security. A part of this is
that the endpoint should be able to collect and present security posture
related information and ensure the integrity of such information. A
remotely performed assessment/scanning process has significant issues such
as availability of the endpoint. If I can assert that a certain endpoint
is potentially vulnerable I can act on this information quickly once the
endpoint is trying to get on the network again without any extensive
scanning efforts during network admission. Off course one should argue
that this kind of scanning/assessment is necessary to t0 when the
endpoint joins the network for the very first time. However I see this as
complementary to the endpoint self-contained approach. Also the
methodology of the scan/assessment must be considered. How do you ensure
the reliability and integrity of the information that is collected? NEA
has been mentioned before. However NEA does not deal with detection and/or
prevention of lying endpoints. Likewise it does not perform detection of
malware that could report false endpoint information. So in that sense I
disagree with point 2 that CMDBs are non-essential. Additionally in the
spirit of minimal interactions between endpoints and network it appears
that the endpoint itself knows best when and how things are changing. It
is almost like you say the doctor should tell the patient when to visit
the doctor office versus the patient seeing the doctor when the patient
feels sick ;)

Regards,
Rainer

On 7/23/13 3:49 PM, "Gunnar Engelbach" <[email-masked]>
wrote:

>> I disagree with this being a different use case.  It is most certainly
>>a different technique for achieving/implementing the use case, but the
>>use case "detecting suspicious endpoint behavior" is the same as are the
>>desired outcomes.
>>
>> I am not advocating that we drop support for periodic scanning.  If
>>fact, I believe strongly that support for it is important for a variety
>>of reasons. My concern is that we rely too much on periodic scanning to
>>detect things that it is not well suited to address. Event-driven
>>detection of changes, both software and configuration, is critical for
>>responding in a timely fashion to security relevant events such as those
>>that relate to unauthorized or malicious changes. We need to
>>simultaneously support periodic and event-driven approaches in the
>>standards we produce. For this to work right, we can't bolt event-driven
>>capabilities on after the fact.  This needs to be considered as part of
>>our architectural design and protocol adoption/design.
>>
>>>method.
>> This is all true for both event-driven and periodic techniques. ;-)
>>Many organizations are going to want a historic perspective regardless
>>of the how the data is collected. This does bring up the need to capture
>>the context of collection, but that is a different discussion.
>>
>> Event-driven collection is better for things that the attacker cannot
>>silence, at least not initially until they achieve an appropriate level
>>of privilege. For example, they may be able to write to configurations
>>using application flaws, but they might not be able to prevent
>>notifications of change events. Another example might be detecting signs
>>of malware persistency (e.g., configuring it to load on boot) prior to a
>>reboot.
>>
>>>and
>> None of what we do will be required; it will all be voluntary. They key
>>is to enable the endpoint to publish changes based on events. How that
>>published data gets processed and persisted is a downstream concern. The
>>architecture should allow for a variety of solutions that handle the
>>info in various ways providing organizations and vendors with some
>>flexibility in deployed architectures. What we want is a reasonable
>>degree of interoperability with regards to the individual components.
>>
>> It doesn't apply if you define the window as the organizational change
>>window.  It does apply if you think about it as the attack window. Most
>>attacks will go unnoticed if the scanning occurs hourly.  In this
>>scenario the attacker can get in, make changes, exfiltrate information,
>>and then cleanup restoring things to the previous state within the hour
>>period.
>>
>>>from
>> Yes. I want to make sure that the standards we produce don't expose
>>organizations unnecessarily if there is a more effective way. ;-) I am
>>pushing to expand the scanning mindset to think about how we can
>>approach this problem space in a way that enables a variety of
>>techniques. The legacy work that has been done in this space gets us a
>>good way there.  We have a variety of mechanisms that enable classes of
>>configurations that are security relevant to be identified and
>>described.  These can be used to identify relevant change events. What
>>is missing are the standards that describe how you implement protocols
>>that enable endpoint data exchange that support both scanning tasks and
>>event driven publication. There are existing protocols such as NEA that
>>can enable both techniques if we do the work to identify the specifics
>>of messaging. I would expect a similar approach would also enable
>>incremental scan results as well.
>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 24 Jul 2013 13:30:49 -0400

A) Self-contained endpoints
Absolutely.  The third diagram I sent has just such a thing, which can 
both self-evaluate and participate in the enterprise system.  This isn't 
just a nifty application of the proposed standards, but a necessity that 
we have encountered at several customer engagements.

B) The essential CMDB
Whether it's for direct consumption or intermediate consumption via a 
CMDB there is always some sort of collection process needed to reap 
endpoint artifacts.  Use of a CMDB does not eliminate the lying endpoint 
problem.  And even if endpoint isn't lying, perhaps the CMDB is, so it's 
an additional link in that trust chain.  There will also be some degree 
of lag between a change made on the endpoint and when that is reflected 
in the CMDB, so you just can't beat being able to directly query an 
endpoint.

OTOH, a CMDB also has many benefits.  I want to see them supported, I 
just don't think they should be required.

Also, I am coming at this from the SCAP world, where it's not just a 
matter of collecting endpoint artifacts, but doing that collection in a 
manner that is verifiably correct (which is where OVAL comes in -- 
codifying vendor recommendations and/or best practices), and this is a 
very important factor.

So there's two trust factors to deal with:  is the endpoint lying, and 
was the artifact properly collected.

There's nothing about the current architecture that says the only way to 
collect artifacts is directly from each endpoint, but I do think we need 
to include the full provenance as metadata to accompany artifacts.

---

From: Rainer Enders <[email-masked]>
Date: Wed, 24 Jul 2013 20:10:05 +0200

This is an important discussion and I thought - in my mind at least - that
Trusted Computing plays a relevant role here but let me explain in more
detail what I am referring to. You are making good and relevant points see
some more comments below in context.

>we have encountered at several customer engagements.

Good.
>endpoint artifacts.  Use of a CMDB does not eliminate the lying endpoint

That is exactly the point. I did not imply CMDB is in any way linked to
lying endpoints. What I am thinking is that emphasis must be put on
securing the endpoint - and I am particularly thinking about mobile
endpoints in that context. (mobile) Endpoints must be put into a position
to protect themselves. This entails that the endpoint should be able to
monitor and report on its identity and state in a trusted way. The
elements of Root of Trust come into play here and my vision is that the
endpoint would ideally monitor and measure its own integrity from birth to
death. When in a network-linked relationship the endpoint should be able
to report on itself and maybe even seek remediation assistance on its own.
So very much endpoint driven vs. network driven.

>problem.  And even if endpoint isn't lying, perhaps the CMDB is, so it's

I agree with this statement. However I think the infrastructure components
can be protected much easier as it will reside in a protected/controlled
environment and hopefully the operating instance where this function is
residing is mostly stable and controlled. As I pointed out above my
foremost concern is around mobile endpoints vs. infrastructure endpoints.

>in the CMDB, so you just can't beat being able to directly query an

This is exactly my point and goes back to David's comment about scanning
interval. There is just no right or wrong scanning interval and even with
"event-triggered" on-demand scanning you would need to establish event
categories/classification and when and how what kind of event would
trigger a query action. So I think it is much simpler to let the endpoint
establish what is changing and report on that event. With that strategy
you could hopefully have some assurance that your configuration database
reflects actual endpoint state. This does not mean you could use on-demand
query as a complementary action.

>codifying vendor recommendations and/or best practices), and this is a

I must admit that I am not an SCAP expert however I think what you state
sounds interesting to include some sort of baseline parameters - if I
understand this correctly. I agree this can be an important factor.

>was the artifact properly collected.

I think this is an important problem to solve! Either way you do it if
endpoint identity and state cannot be asserted all bets are off no matter
what you do.

>>>>>>> In this case the SOC Analyst can query a CMDB containing the
>>>>>>>current
>>>>>>> and
>>>>> historically related reported configurations for the endpoint
>>>>>skipping
>>>>> to step
>>>>> should be supported, but it also creates other problems and should
>>>>>not
>>>>> be
>>>>> *required*.
>>>>

---

From: David Harrington <[email-masked]>
Date: Sat, 27 Jul 2013 22:51:01 -0400

On 7/23/13 5:20 PM, "Waltermire, David A." <[email-masked]>
wrote:

>architecture should allow for a variety of solutions that handle the info
>in various ways providing organizations and vendors with some flexibility
>in deployed architectures. What we want is a reasonable degree of
>interoperability with regards to the individual components.

See RFC 3365 "Strong Security Requirements for Internet Engineering Task
Force Standard Protocols"
To claim compliance to the standards, implementers MUST implement the
"required" aspects of the standard.
But it is up to the deployer/user/operator whether to use each feature.
So a significant portion of what we do should be "required to implement",
otherwise it isn't really a standard, and implementations will likely not
interoperate.

>--
>David Harrington
>[email-masked]
>+1-603-828-1401