Subject: [Smart] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt

From: Kirsty P <[email-masked]>
Date: Fri, 6 Mar 2020 12:28:56 +0000

A new version of I-D, draft-paine-smart-indicators-of-compromise-00.txt
has been successfully submitted by Kirsty Paine and posted to the
IETF repository.

Name:           draft-paine-smart-indicators-of-compromise
Revision:       00
Title:          Indicators of Compromise (IoCs) and Their Role in Attack Defence
Document date:  2020-03-06
Group:          Individual Submission
Pages:          15
URL:            https://www.ietf.org/id/draft-paine-smart-indicators-of-compromise-00.txt
Status:         https://datatracker.ietf.org/doc/draft-paine-smart-indicators-of-compromise/
Htmlized:       https://tools.ietf.org/html/draft-paine-smart-indicators-of-compromise-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-paine-smart-indicators-of-compromise

Abstract:
   Indicators of Compromise (IoCs) are an important technique in attack
   defence (often called cyber defence).  This document outlines the
   different types of IoC, their associated benefits and limitations,
   and discusses their effective use.  It also contextualises the role
   of IoCs in defending against attacks through describing a recent case
   study.  This draft does not pre-suppose where IoCs can be found or
   should be detected - as they can be discovered and deployed in
   networks, endpoints or elsewhere - rather, engineers should be aware
   that they need to be detectable (either by endpoint security
   appliances or network-based defences, or ideally both) to be
   effective.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Mar 2020 06:06:42 -0700

Document: draft-paine-smart-indicators-of-compromise-00.txt

Kirsty,

Thanks for sending this. I have attached some review comments
below.

To the SECDISPATCH questions, it's not clear to me that this fits that
well into any particular present venue. I agree it's useful to have
this information out there, but I guess my question would be: what do
you think the benefit of publishing this as an RFC is? Perhaps the
answer to that question would help us illuminate the best venue.

-Ekr

S 2.
   o  IP addresses

   o  domain names

   o  TLS Server Name Indicator values

"server name indication"

   o  certificate information

   o  signatures such as binary code patterns and strings

   o  hashes of malicious binaries or scripts

   o  attack tools, such as mimikatz [Mimikatz]

   o  attack techniques, such as Kerberos golden tickets [GoldenTicket]

This list seems like it would be clearer if it described where
things are found. Some of them (SNI) would be clear in context
but when you say "domain names" that's less clear. And I guess
"hashes of..." is on the device

S 3.2.

   The correspondence is one-to-many: simply blocking one IoC may
   protect thousands of users within an organisation.  Discovering one
   IoC can be intensive, but sharing IoCs via well-established routes
   such as the Malware Information Sharing Platform (MISP) [MISP] will
   protect thousands of organisations and end users.  The shareability
   and reproducibility of IoCs is a huge advantage; it allows a threat
   defender to look for things consistently and automate the process of
   defending their networks.  It doesn't require intensive training (as
   needed to, for example, manually analyse tipped machine learning
   events), nor does it require time-intensive resource to deploy IoCs.

This text seems kind of confusing, as it seems to conflate two
activities that might be termed "discovery" namely discovering new
IoCs and discovering that they are in play in a given network. For
instance, it's one thing to discover that attacker.com is run by an
attacker and thus that connections to it are probably an IoC and
another to discover that your users are connecting to attacker.com. I
think what might help here would be to have some kind of overview of
an IoC lifecycle. This isn't my area of expertise, but this might look
something like:

- Discovering that a given feature is an IoC
- Sharing that IoC to other entities via MISP or the like
- Deploying detection for that IoC
- Detecting IoCs on user computers
- Investigation, etc.

S 3.7.
   As an example, open source malware can be deployed by many different
   actors, each with their own "Tactics, Techniques and Procedures"
   (TTPs) and infrastructure.  However, if the same executable is used,
   the hash remains the same - and this IoC can be deployed in endpoints

Is there a reason you specify "open source"? Can't closed source malware
also be deployed by many different actors? Maybe you're connecting this
to the idea that you could recompile it with a different hash, but
one can actually quite easily change binaries to have the same function
but with different contents, which obviously changes the hash.

S 4.1.
   IoCs form a "Pyramid of Pain" [PoP] that can be used for prevention,
   detection and mitigation.  This represents how much pain it is: to an
   adversary to change and for the defender to gather.  The layers of
   the PoP range from hashes to TTPs and the pain ranges from
   recompiling code to creating a new attack strategy.

This seems to claim that there is a correspondence between how
easy it is for an adversary to change an IoC and a defender to
gather that IoC. That might be true, but it's not immediately
clear that it is in fact true. To take a concrete example,
gathering domain names seems much easier than gathering
hash values, though I agree with you that it's easier to
change hash values. It does seem like the fragility/precision
axis is more likely to align, but I haven't thought about that
too hard. In any case, if you think this is a deep connection,
I would encourage you to make that argument more explicit
rather than just providing examples.

S 4.4.
   contexts where ensuring endpoint security isn't possible such as
   "Bring Your Own Device" (BYOD), IoT and legacy environments.  Using
   these network level IoCs can also protect against a compromised
   endpoint as, even if the compromise passes unnoticed, the IoCs can
   still be checked against network traffic, allowing detection of the
   attack.  For example, in a BYOD environment, enforcing security
   policies on the device can be difficult, so non-endpoint IoCs and
   solutions are needed to allow detection of compromise even with no
   endpoint coverage.

It might be helpful here to note that a lot of those BYOD endpoints
already have their own mechanisms for processing and blocking IoCs
(this goes back to my point above about the various activities
one might have). For instance, Windows defender ships with
Windows and most browsers have some sort of safe browsing type
technology.

S 5.
   queries) for the organisations signed up to the service [ACD2019]. 28
   million of them were for domain generation algorithms (DGAs),
   including 15 known DGAs.  IoCs such as malicious domains can be put

This seems to be the first time you mention DGAs, which don't appear
in your pyramid of pain. i think it would be helpful to place them
there.

On Fri, Mar 6, 2020 at 4:29 AM Kirsty P <Kirsty.p=
[email-masked]> wrote:

> URL:
> https://www.ietf.org/id/draft-paine-smart-indicators-of-compromise-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-paine-smart-indicators-of-compromise/
> Htmlized:
> https://tools.ietf.org/html/draft-paine-smart-indicators-of-compromise-00
> <https://tools.ietf..org/html/draft-paine-smart-indicators-of-compromise-00>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-paine-smart-indicators-of-compromise
>
>
> Abstract:
> This information is exempt under the Freedom of Information Act 2000
> (FOIA) and may be exempt under other UK information legislation. Refer any
> FOIA queries to [email-masked]. All material is UK Crown
> Copyright ©
> --
> Smart mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/smart
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 27 Mar 2020 09:23:05 -0400

Thank you for your draft, Kirsty.  This provides a nice summary of the
current state for IoCs.  In your presentation this evening, I am hoping to
learn your thoughts on how this draft will evolve.

   1. Will the draft remain a summary draft, and if so, does this fit into
   MILE?  It may even then reference some of the work of MILE, such as ROLIE
   (adopted into SCAP 2.0).
   2. Will the draft evolve to state applicability to IETF protocols with
   new thoughts on how IoCs may be used?  If so, what are some initial seed
   ideas as I think that will greatly aid the conversation and lead to a
   potential direction (1 or 2).

Thanks for your work and congratulations on submitting your first draft.

I look forward to hearing more.

Best regards,
Kathleen

On Fri, Mar 27, 2020 at 9:07 AM Eric Rescorla <[email-masked]> wrote:

>    protect thousands of organisations and end users..  The shareability
>    queries) for the organisations signed up to the service [ACD2019].. 28
> [email-masked] <[email-masked]>> wrote:
>
>>
>> <https://tools.ietf...org/html/draft-paine-smart-indicators-of-compromise-00>
>> Htmlized:

-- 

Best regards,
Kathleen