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

[Kathleen Moriarty <[e-mail]>]

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

> 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] <[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
>>
> --
> Smart mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/smart
>


-- 

Best regards,
Kathleen