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

Benjamin Kaduk <kaduk@mit.edu> Fri, 27 March 2020 23:15 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB373A0BEB for <secdispatch@ietfa.amsl.com>; Fri, 27 Mar 2020 16:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHV5ZDsdloiQ for <secdispatch@ietfa.amsl.com>; Fri, 27 Mar 2020 16:15:33 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A56A3A0A3A for <secdispatch@ietf.org>; Fri, 27 Mar 2020 16:15:33 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02RNFRiJ018643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Mar 2020 19:15:30 -0400
Date: Fri, 27 Mar 2020 16:15:26 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Kirsty P <Kirsty.p=40ncsc.gov.uk@dmarc.ietf.org>
Cc: "secdispatch@ietf.org" <secdispatch@ietf.org>
Message-ID: <20200327231526.GU50174@kduck.mit.edu>
References: <158349344094.2274.4065518603647811950@ietfa.amsl.com> <LNXP123MB23300837148D795BB004451DD7E30@LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM> <LNXP123MB2330E7D239FABA31AA1B93C7D7FF0@LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <LNXP123MB2330E7D239FABA31AA1B93C7D7FF0@LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/Z79rFMyDsuzVYR8poBcKjF_6ZK0>
Subject: Re: [Secdispatch] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2020 23:15:35 -0000

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

On Tue, Mar 10, 2020 at 05:00:43PM +0000, Kirsty P wrote:
> 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 ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright ©

> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch