Subject: [sacm] Use Case Discussion: Vulnerable Endpoint Identification

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

And another...

Use Case Name: Vulnerable Endpoint Identification

Description: 
In this use case a zero-day exploit has been discovered in the wild, which is followed by a vulnerability identification entry and indicators of compromise.  A security engineer is responsible for that portion of a situational response process that determines how exposed an organization is given the new state of the world.

Actors: 

   * System Administrator
   * Vulnerability Engineer
   * Security Engineer
   * System Owner
   * Information Owner

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
   * Security Policy specifies configuration history retention requirements
   * The Organization associates owners who are individuals with endpoints
   * The Organization associates organizational units with endpoints

Postconditions:

   * Appropriate individuals in the organization have a clear understanding of the organization's exposure to and potential impact of the identified 0-day
   * Appropriate individuals are taking action to further assess or mitigate the organization's posture regarding this 0-day

Primary Path: 

  1. [External] 0-day exploit discovery [1]

  2. Vulnerability Identification (Vulnerability ID) issued and associated information published to an accessible content repository [2]

  3. Indicators of Compromise (IoC) are identified and published to an accessible content repository [3]

  4. Security engineer provides the Vulnerability ID to the Asset Management System

  5. The Asset Management System queries a configured Vulnerability Database to obtain a list of affected endpoint classes [4]

  6. The Asset Management System returns a list of specific endpoints that can be classified according to the endpoint class list obtained in Step 5, which either:

  7. 
    a. Presently have affected software installed, or
    b. Have had affected software installed.

  8. The Security Engineer exports the list of potentially affected endpoints

  9. The Security Engineer initiates a vulnerability scan based on IoCs, published vulnerability information, and the potentially affected endpoint list.

  10. The Vulnerability Scanner derives a set of vulnerability checks (i.e. assessments) to perform on each listed endpoint based on information associated with the provided Vulnerability ID and IoCs.

  11. The Vulnerability Scanner executes the check on each of the potentially affected hosts which will return results effectively equivalent to "is vulnerable," "is not vulnerable," "not checked," or "error" [5].

  12. The Security Engineer reviews the report then generates three additional reports:

  13. 
    a. The first report provides summary information for the Information Security Manager and/or higher levels of organizational management as appropriate (i.e. Chief Information Security Officer)
    b. The second report is a list of all potentially effected endpoints for which no definitive answer could be obtained by the Vulnerability Scanner (i.e. those endpoints for which neither an "is vulnerable" nor "is not vulnerable" result is available)
    c. The third report is a list of all effected endpoints (i.e. those endpoints for which the checks resulted in "is vulnerable").

  14. The Security Engineer sends the first report to responsible Information Security Manager(s) using relationships tracked by the Asset Management System

  15. The Security Engineer sends the second report to responsible Vulnerability Engineer(s) using relationships tracked by the Asset Management System

  16. The Security Engineer sends the third report to responsible System Administrator(s) using relationships tracked by the Asset Management System

  17. The Security Engineer issues an alert to affected System Owners, Information Owners, and System Administrators using relationships tracked by the Asset Management System

A Note On Alternative Paths, Preconditions, and Postconditions:
There are likely to be many points of optimization and optional paths pertaining to this Use Case.  For example, there may be greater degrees of interoperability between tools in a given organization, which would advance the state of automation in the "primary path" description herein provided.  

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.  Most organizations are unlikely to have separate roles for Security Engineer and Vulnerability Engineer, for example.  

--------------
[1] The "[External]" notation is used to indicate that, while this step is included in the primary path, it is out of the organization's locus of control (i.e. the step is provided for additional context in the path through the use case rather than being placed in the pre-conditions).

[2] An "accessible" content repository may be internal or external.  An internal content repository may be a replication of an external content repository.

[3] Often, an indicator of compromise involves assessing the state of some observable object on the endpoint.  For example, an indicator of compromise might be that a particular file path exists, a particular setting is configured in a specific manner, a set of settings are configured in a specific manner, and/or specific log entries exist.

[4] The Vulnerability Database may be combined with the content repository, but is being called out separately here to assure that the reader knows which type of data is being queried.

[5] It is likely that additional result types will be required to convey different reasons a result may not be available.

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:08:28 +0000

Adam,

A few comments.

In general... if our current focus is on endpoint assessment, it seems like much of this goes way beyond our initial scope of focus. Things like knowing what organizational units have endpoints and who owns these endpoints is important in the broader scope, but is not significant to our constrained area of focus.

This raises the questions... should our use cases be scoped to only the current area of focus for the working group, or should the use cases identify the broader end goal for which our work will play a part?

Other comments are inline.

Thanks,
Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adam Montville
> Sent: Monday, July 15, 2013 4:59 PM
> To: [email-masked]
> Subject: [sacm] Use Case Discussion: Vulnerable Endpoint Identification
> 
> And another...
> 
> 
> In this use case a zero-day exploit has been discovered in the wild, which is
> followed by a vulnerability identification entry and indicators of compromise.
> A security engineer is responsible for that portion of a situational response
> process that determines how exposed an organization is given the new state
> of the world.

This seems like two use cases in one.

Vulnerable Endpoint Identification: Typically vulnerability reports identify an executable or library that is vulnerable, or worst case the software that is vulnerable. This information is used to determine if an organization has one or more endpoints that have exposure to a vulnerability (i.e., what endpoints are vulnerable?). It is often necessary to know where you are running vulnerable code and what configurations are in place on the endpoint and upstream devices (e.g., IDS, firewall) that may limit the exposure. All of this information, along with details on the severity and impact of a vulnerability, is necessary to prioritize remedies.

Compromised Endpoint Identification: Along with knowing if one or more endpoints are vulnerable, it is also important to know if you have been compromised. Indicators of compromise provide details that can be used to identify malware (e.g., file hashes), identify malicious activity (e.g. command and control traffic), presence of unauthorized/malicious configuration items, and other indicators. While important, this goes beyond determining organizational exposure.

>    * Appropriate individuals in the organization have a clear understanding of
> the organization's exposure to and potential impact of the identified 0-day
>    * Appropriate individuals are taking action to further assess or mitigate the
> organization's posture regarding this 0-day
> 
> 
> Primary Path:
> 
> 
>   2. Vulnerability Identification (Vulnerability ID) issued and associated
> information published to an accessible content repository [2]

This applies to Vulnerable Endpoint Identification.

> accessible content repository [3]

This applies to Compromised Endpoint Identification.

>   5. The Asset Management System queries a configured Vulnerability
> Database to obtain a list of affected endpoint classes [4]
> 
>   6. The Asset Management System returns a list of specific endpoints that
> can be classified according to the endpoint class list obtained in Step 5, which
> either:
>
>   7.

This supports both. Potentially compromised endpoints are those that are vulnerable or may have been vulnerable historically.

>   9. The Security Engineer initiates a vulnerability scan based on IoCs,
> published vulnerability information, and the potentially affected endpoint
> list.

Is a scan necessary for identification of vulnerable endpoints? If there is datastore that contains the current software inventory of endpoint devices, wouldn't it be possible to check the vulnerability information against that data?  Use of a data store seems to be the only effective way of doing this for historically vulnerable software.

Vulnerability scanning has had mixed success in the past.  There has been little consensus in what is the best methodology for detecting vulnerable software using scans.  Is the software vulnerable if the software is installed?  Is the endpoint vulnerable if the software is uninstalled and a vulnerable library or other component is still present?

>   10. The Vulnerability Scanner derives a set of vulnerability checks (i.e.
> assessments) to perform on each listed endpoint based on information
> associated with the provided Vulnerability ID and IoCs.

Again, I am not sure vulnerability checks are the best approach to identify vulnerable endpoints.  This is getting into architecture and implementation details. It might be better for the endpoint to send file lists with hashes which get stored is a data store.  Deltas can be used to reduce the overall volume.  We need some discussion around the different approaches that can be used here.  Do we support one approach? Multiple?

File lists with hashes can be used to identify compromised endpoints for file indicators. Checks or configuration setting publication are probably the best way to deal with some indicator types that relate to configuration items.

>   11. The Vulnerability Scanner executes the check on each of the potentially
> affected hosts which will return results effectively equivalent to "is
> vulnerable," "is not vulnerable," "not checked," or "error" [5].

What about "compromised" or "is not compromised"?

>   12. The Security Engineer reviews the report then generates three

I thought we are striving for automation.  Why not automate the additional report generation?

>   13.
>     a. The first report provides summary information for the Information
> Security Manager and/or higher levels of organizational management as
> appropriate (i.e. Chief Information Security Officer)
>     b. The second report is a list of all potentially effected endpoints for which
> no definitive answer could be obtained by the Vulnerability Scanner (i.e.
> those endpoints for which neither an "is vulnerable" nor "is not vulnerable"
> result is available)

s/effected/affected/

See above about alternate methods vs. using a vulnerability scanner. What about unreachable endpoints?

>     c. The third report is a list of all effected endpoints (i.e. those endpoints for
> which the checks resulted in "is vulnerable").

s/effected/affected/

>   14. The Security Engineer sends the first report to responsible Information
> Security Manager(s) using relationships tracked by the Asset Management
> System
> 
>   15. The Security Engineer sends the second report to responsible
> Vulnerability Engineer(s) using relationships tracked by the Asset
> Management System
> 
>   16. The Security Engineer sends the third report to responsible System
> Administrator(s) using relationships tracked by the Asset Management
> System
> 
>   17. The Security Engineer issues an alert to affected System Owners,
> Information Owners, and System Administrators using relationships tracked
> by the Asset Management System

Why can't 14-17 be automated alerts sent by the system implementing SACM specifications?

> There are likely to be many points of optimization and optional paths
> pertaining to this Use Case.  For example, there may be greater degrees of
> interoperability between tools in a given organization, which would advance
> the state of automation in the "primary path" description herein provided.
> 
> 
> 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.  Most organizations are unlikely to have
> separate roles for Security Engineer and Vulnerability Engineer, for example.
> 
> 
> --------------
> [1] The "[External]" notation is used to indicate that, while this step is
> included in the primary path, it is out of the organization's locus of control
> (i.e. the step is provided for additional context in the path through the use
> case rather than being placed in the pre-conditions).
> 
> 
> [2] An "accessible" content repository may be internal or external.  An
> internal content repository may be a replication of an external content
> repository.
> 
> 
> [3] Often, an indicator of compromise involves assessing the state of some
> observable object on the endpoint.  For example, an indicator of
> compromise might be that a particular file path exists, a particular setting is
> configured in a specific manner, a set of settings are configured in a specific
> manner, and/or specific log entries exist.
> 
> [4] The Vulnerability Database may be combined with the content repository,
> but is being called out separately here to assure that the reader knows which
> type of data is being queried.
> 
> 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: Adam Montville <[email-masked]>
Date: Thu, 25 Jul 2013 14:37:39 +0000

> From: Waltermire, David A. [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2013 11:09 AM
> To: Adam Montville; [email-masked]
> Subject: RE: Use Case Discussion: Vulnerable Endpoint Identification
> 
> Adam,
> 
> A few comments.
> 
> In general... if our current focus is on endpoint assessment, it seems like
> much of this goes way beyond our initial scope of focus. Things like knowing
> what organizational units have endpoints and who owns these endpoints is
> important in the broader scope, but is not significant to our constrained area
> of focus.

There was a similar comment with respect to my inclusion of something as detailed as an event's time of occurrence.  Strictly speaking, we don't care what time something happened, but what we should care about is that time of change is important, so it's something we need to capture.  It's my perspective, and we need not take this perspective as a WG, that these details are important to consider when crafting the right architecture.  Some of these elements are "out of scope" in the sense that we are not solving a problem related to them, but they are not necessarily "out of scope" when considering how we want to craft an architecture.

> 
> This raises the questions... should our use cases be scoped to only the
> current area of focus for the working group, or should the use cases identify
> the broader end goal for which our work will play a part?

This, to me, will necessarily be a balancing act.  We run some risk of missing the boat if we constrain too much, and some risk of running aground if we broaden too much.  

In general, I like the use cases we have so far, though some of them seem to need fleshing out.  I also believe that, if we're going to be harvesting information from the variety of sources represented in the 05 use case document, we ought to be considering what properties such sources should have, if any.  For example, the MIB sources are relatively new to me, and I know little about their reliability, but getting information from registries and server configuration files is well-known in this space.

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Adam Montville
> > In this use case a zero-day exploit has been discovered in the wild,
> > which is followed by a vulnerability identification entry and indicators of
> compromise.
> > A security engineer is responsible for that portion of a situational
> > response process that determines how exposed an organization is given
> > the new state of the world.
> 
> Vulnerable Endpoint Identification: Typically vulnerability reports identify an
> executable or library that is vulnerable, or worst case the software that is
> vulnerable. This information is used to determine if an organization has one
> or more endpoints that have exposure to a vulnerability (i.e., what endpoints
> are vulnerable?). It is often necessary to know where you are running
> vulnerable code and what configurations are in place on the endpoint and
> upstream devices (e.g., IDS, firewall) that may limit the exposure. All of this
> information, along with details on the severity and impact of a vulnerability, is
> necessary to prioritize remedies.
> 
> Compromised Endpoint Identification: Along with knowing if one or more
> endpoints are vulnerable, it is also important to know if you have been
> compromised. Indicators of compromise provide details that can be used to
> identify malware (e.g., file hashes), identify malicious activity (e.g. command
> and control traffic), presence of unauthorized/malicious configuration items,
> and other indicators. While important, this goes beyond determining
> organizational exposure.
> 
> >
> >
> > Actors:
> >
> >    * System Administrator
> >    * Vulnerability Engineer
> >    * Security Engineer
> >    * System Owner
> >    * Information Owner
> >
> >
> > Preconditions:
> >
> >    * Appropriate individuals in the organization have a clear
> > understanding of the organization's exposure to and potential impact of
> the identified 0-day
> >    * Appropriate individuals are taking action to further assess or
> > mitigate the organization's posture regarding this 0-day
> >
> >
> > Primary Path:
> >
> >
> >   2. Vulnerability Identification (Vulnerability ID) issued and
> > associated information published to an accessible content repository
> > [2]
> 
> >   6. The Asset Management System returns a list of specific endpoints
> > that can be classified according to the endpoint class list obtained
> > in Step 5, which
> > either:
> >
> >   7.
> This supports both. Potentially compromised endpoints are those that are
> vulnerable or may have been vulnerable historically.
> 
> >
> >   9. The Security Engineer initiates a vulnerability scan based on
> > IoCs, published vulnerability information, and the potentially
> > affected endpoint list.
> 
> Is a scan necessary for identification of vulnerable endpoints? If there is
> datastore that contains the current software inventory of endpoint devices,
> wouldn't it be possible to check the vulnerability information against that
> data?  Use of a data store seems to be the only effective way of doing this
> for historically vulnerable software.
> 
> Vulnerability scanning has had mixed success in the past.  There has been
> little consensus in what is the best methodology for detecting vulnerable
> software using scans.  Is the software vulnerable if the software is installed?
> Is the endpoint vulnerable if the software is uninstalled and a vulnerable
> library or other component is still present?
> 
> Again, I am not sure vulnerability checks are the best approach to identify
> vulnerable endpoints.  This is getting into architecture and implementation
> details. It might be better for the endpoint to send file lists with hashes
> which get stored is a data store.  Deltas can be used to reduce the overall
> volume.  We need some discussion around the different approaches that can
> be used here.  Do we support one approach? Multiple?
> 
> File lists with hashes can be used to identify compromised endpoints for file
> indicators. Checks or configuration setting publication are probably the best
> way to deal with some indicator types that relate to configuration items.
> 
> >   11. The Vulnerability Scanner executes the check on each of the
> > potentially affected hosts which will return results effectively
> > equivalent to "is vulnerable," "is not vulnerable," "not checked," or "error"
> [5].
> 
> >     a. The first report provides summary information for the
> > Information Security Manager and/or higher levels of organizational
> > management as appropriate (i.e. Chief Information Security Officer)
> >     b. The second report is a list of all potentially effected
> > endpoints for which no definitive answer could be obtained by the
> Vulnerability Scanner (i.e.
> >     c. The third report is a list of all effected endpoints (i.e.
> > those endpoints for which the checks resulted in "is vulnerable").
> 
> s/effected/affected/
> 
> >   14. The Security Engineer sends the first report to responsible
> > Information Security Manager(s) using relationships tracked by the
> > Asset Management System
> >
> > Information Owners, and System Administrators using relationships
> > tracked by the Asset Management System
> 
> > pertaining to this Use Case.  For example, there may be greater
> > degrees of interoperability between tools in a given organization,
> > which would advance the state of automation in the "primary path"
> description herein provided.
> >
> >
> > 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.  Most organizations
> > are unlikely to have separate roles for Security Engineer and Vulnerability
> Engineer, for example.
> >
> >
> > --------------
> > [1] The "[External]" notation is used to indicate that, while this
> > step is included in the primary path, it is out of the organization's
> > locus of control (i.e. the step is provided for additional context in
> > the path through the use case rather than being placed in the pre-
> conditions).
> >
> >
> > [2] An "accessible" content repository may be internal or external.
> > An internal content repository may be a replication of an external
> > content repository.
> >
> >
> > [3] Often, an indicator of compromise involves assessing the state of
> > some observable object on the endpoint.  For example, an indicator of
> > compromise might be that a particular file path exists, a particular
> > setting is configured in a specific manner, a set of settings are
> > configured in a specific manner, and/or specific log entries exist.
> >
> > [4] The Vulnerability Database may be combined with the content
> > repository, but is being called out separately here to assure that the
> > reader knows which type of data is being queried.
> >
> > [5] It is likely that additional result types will be required to
> > convey different reasons a result may not be available.
> >
> > 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: Gunnar Engelbach <[email-masked]>
Date: Thu, 25 Jul 2013 12:18:38 -0400

> There was a similar comment with respect to my inclusion of something as detailed as an event's time of occurrence.  Strictly speaking, we don't care what time something happened, but what we shoul…

+1

The inclusion of that level of detail isn't necessary to understand the 
picture being painted by the use case, but it does point out information 
that needs to be captured that might not otherwise be apparent.