Subject: [sacm] Three More SACM Use Cases

From: Stephen Hanna <[email-masked]>
Date: Tue, 15 Oct 2013 23:21:36 +0000

Here are the additional SACM use cases that I promised.
Comments are most welcome!

After some thought, I suspect that the Remediation and
Mitigation use case is out of scope for this phase of
SACM. If others agree, we can drop that use case for
now. However, I hope that we design our architecture
and protocols to be sufficiently extensible that future
extensions can add support for that use case.

Thanks,

Steve

------

2.5. Search for Signs of Infection

The Example Corporation carefully manages endpoint security
with tools that implement the SACM standards. One day, the
endpoint security team at Example Corporation learns about
a stealthy malware package. This malware has just been
discovered but has already spread widely around the world.
Certain signs of infection have been identified (e.g. the
presence of certain files). The security team would like
to know which endpoints owned by the Example Corporation
have been infected with this malware. They use their tools
to search for the signs of infection and generate a list of
infected endpoints.

The search for infected endpoints may be performed by
gathering new endpoint posture information regarding
the presence of the signs of infection. However, this
might miss finding endpoints that were previously
infected but where the infection has now erased itself.
Such previously infected endpoints may be detected
by searching a database of posture information
previously gathered for the signs of infection.
However, this will not work if the malware hides
its presence carefully or if the signs of infection
were not included in previous posture assessments.
In those cases, the database may be used to at least
detect which endpoints previously had software
vulnerable to infection by the malware.

2.6. Remediation and Mitigation

When Example Corporation discovers that one of its
endpoints is vulnerable to infection, a process of
mitigation and remediation is triggered. The first
step is mitigating the impact of the vulnerability,
perhaps by placing the endpoint into a safe network
or blocking network traffic that could infect the
endpoint. The second step is remediation: fixing
the vulnerability. In some cases, these steps may
happen automatically and rapidly. In other cases,
they may require human intervention either to
decide what response is most appropriate or to
complete the steps, which are sometimes complex.

These same steps of mitigation and remediation may
be used when Example Corporation discovers that one
of its endpoints has become infected with some malware.
Alternatively, the infected endpoint may simply be
monitored or even placed into a honeynet or similar
environment to observe the malware's behavior and
lead the attackers astray.

2.7. Endpoint Information Analysis and Reporting

Freed from the drudgery of manual endpoint compliance
monitoring, one of the security administrators at
Example Corporation notices (not using SACM standards)
that five endpoints have been uploading lots of data
to a suspicious server on the Internet. The administrator
queries the SACM database of endpoint posture to see
what software is installed on those endpoints and
finds that they all have a particular program installed.
She then searches the database to see which other
endpoints have that program installed. All these
endpoints are monitored carefully (not using SACM
standards), which allows the administrator to detect
that the other endpoints are also infected.

This is just one example of the useful analysis
that a skilled analyst can do using the database
of endpoint posture that SACM can provide.

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 15 Oct 2013 20:59:14 -0400

Steve,

You're right, the remediation use case is one of the ones that was 
dropped a while back.  I don't think that means completely ignoring 2.6, 
however.  Even if SACM isn't currently covering remediation, other 
software can monitor (or receive notification) a SACM system and take 
mitigation steps based on that.  Just like 2.8, it shows using the SACM 
system for purposes not covered by SACM.

I will also repost this use case I wrote a while back:

         -------------===========================-------------
2.8 Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra

A university team receives a grant to do research at a government
facility in the arctic.  The only network communications will be via an
intermittent low-speed high-latency high-cost satellite link.  During
their extended expedition they will need to show continue compliance
with the security policies of the university, the government, and the
provider of the satellite network as well as keep current on
vulnerability testing.  Interactive assessments are therefore not
reliable, and since the researchers have very limited funding they need
to minimize how much money they spend on network data.

Prior to departure they register all equipment with an asset management
system owned by the university, which will also initiate and track
assessments.

On a periodic basis -- either after a maximum time delta or when the
content repository has received a threshold level of new vulnerability
definitions -- the university uses the information in the asset
management system to put together a collection request for all of the
deployed assets that encompasses the minimal set of artifacts necessary
to evaluate all three security policies as well as vulnerability testing.

In the case of new critical vulnerabilities this collection request
consists only of the artifacts necessary for those vulnerabilities and
collection is only initiated for those assets that could potentially
have a new vulnerability.

[Optional] Asset artifacts are cached in a local CMDB.  When new
vulnerabilities are reported to the content repository, a request to the
live asset is only done if the artifacts in the CMDB are incomplete
and/or not current enough.

The collection request is queued for the next window of connectivity.
The deployed assets eventually receive the request, fulfill it, and
queue the results for the next return opportunity.

The collected artifacts eventually make it back to the university where
the level of compliance and vulnerability expose is calculated and asset
characteristics are compared to what is in the asset management system
for accuracy and completeness.

On 10/15/2013 7:21 PM, Stephen Hanna wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sun, 20 Oct 2013 03:25:44 +0000

Hi Steve,

Thanks for putting these together, I like the general notion of these use
cases but have some questions/comments
Further below:

>vulnerable to infection by the malware.
[NCW] Its not clear what this paragraph is trying to convey.  That is, the
example based on the first paragraph leads me to believe that this use
case is about an application requesting information of endpoint's current
assessments to enumerate the list of endpoints infected.  I think the 2nd
paragraph is further conveying that the request of an evaluator or
assessment repository is to get not just current assessments but also
historical ones?

>lead the attackers astray.
[NCW] I think there was consensus in the group that the
mitigation/remediation process was out of scope for the charter. However,
perhaps this use case can be narrowed to a continuous monitoring of the
infected endpoint's assessment vs. the actual remediation action?