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

From: Kirsty P <[email-masked]>
Date: Tue, 10 Mar 2020 17:00:43 +0000

Hi,

I'd like to request a slot at secdispatch for IETF 107 to present the draft below.
Additionally, comments/feedback on the draft from interested parties are very welcome.

Kirsty

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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-paine-smart-indicators-of-compromise-00.txt&data=02%7C01%7Ckirsty.p%40ncsc.gov.uk%7C3283447022044502363808d7c1c9fb79%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637190945558787055&sdata=HE08SVSSndeW8w3%2BLhIuPIN6UHQgS12CyJyzkU6Pbb4%3D&reserved=0>
Status:         https://datatracker.ietf.org/doc/draft-paine-smart-indicators-of-compromise/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-paine-smart-indicators-of-compromise%2F&data=02%7C01%7Ckirsty.p%40ncsc.gov.uk%7C3283447022044502363808d7c1c9fb79%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637190945558787055&sdata=HIi8VC1pjpoVEiRKxGCTYC6Uh3AU9Rnw%2FBZlMM6aYaQ%3D&reserved=0>
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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-paine-smart-indicators-of-compromise&data=02%7C01%7Ckirsty.p%40ncsc.gov.uk%7C3283447022044502363808d7c1c9fb79%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637190945558787055&sdata=71V38VD17LA01QwaLsf3GR7gHKhscVYVsI9dyomCXgs%3D&reserved=0>

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: Michael Richardson <[email-masked]>
Date: Tue, 10 Mar 2020 13:38:56 -0400

Hi, thank you for this interesting document.
It uses terminology which I did not know existed before.

The document does not specify a protocol of any kind, although MISP-project
is referenced.   It does not seem to be about any kind of directly
implementable Best Current Practice, but seems like background for something
bigger.

I'm not sure how publishing this as an RFC would be helpful.
Are you considering ways to represent the Indicators such that they can be
more easily exchanged?  I believe that the IETF has done a bunch of work in
that area (INCH, MILE, IODEF come to mind), but perhaps not exactly in this
direction.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 27 Mar 2020 16:15:26 -0700

Hi Kirsty,

While reading the draft to prepare for the session, I had something occur
to me that was not really relevant for the dispatch question, so I didn't
mention it live, but still seems worth mentioning:

Different IoCs can, of course, have different properties, and I think it's
important to have some mention of how this can apply both to the level of
confidence that the presence of any given IoC indicates true compromise,
and for how long a given IoC remains an IoC.  To consider IP addresses as
a familiar example that I know how to reason about, if I'm a security
researcher taking notes on my investigations, the fact that an IP address
known to be a botnet C&C appears in my notes does not indicate that my
machine is compromised!  Likewise, with IP(v4) addresses growing scarce,
they will be getting reallocated and/or reassigned to different entities;
we see this already in the form of spam reputation scores, with IP
addresses remaining on blacklists even after they have been reassigned.

-Ben

> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch