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

[Eric Rescorla <[e-mail]>]

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=
[e-mail]> wrote:

>
> 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
> <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 [e-mail]. All material is UK Crown
> Copyright ©
> --
> Smart mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/smart
>