From nobody Fri Mar 6 04:29:07 2020 Return-Path: X-Original-To: smart@ietfa.amsl.com Delivered-To: smart@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DF63A0E4D for ; Fri, 6 Mar 2020 04:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk 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 O3dQ5qQqgXdA for ; Fri, 6 Mar 2020 04:29:00 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100130.outbound.protection.outlook.com [40.107.10.130]) (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 DAC413A0E4B for ; Fri, 6 Mar 2020 04:28:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DIMXyEtG43zMipAGi9Jo2AV9WvSA74DULkzO6KVUfFC6Odo6JMjGe8fn4M3seo0YcrMo+uCZpju1GHf5t6VTrjdavECDlb2gNlpJXP7DT4eG3apF8Mp5uZfKTg7q3zG1QW8W0BmfEhLAMo73C4Z1y7hgWutDezScXkgDQLmuBGChjQxd6Yr8x5UFSHMSymfdkjRCbCIJFqankqI0IpslARBIwk2fgl2gyXCLYztBUO1hBn4dAod9I013rlB7ni9pusH4AjA9NLJc+CLeyjwTMiDrs2j56KtB4jQPagXFLckudrQcp+LI82AC/8ay+70hd0+vh3F1+mWuecvGDGnOKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RRCcooxaUn49Y5RFYJS3Tb7UkTK8Z8DjWOZICGyvy/0=; b=YFQgMDQ2HMV2RBjyW2x5gZm+GNTD1h5mRJyvmCPPK5GyoHa8i+azWItL8pTxZkTdTxyEdZpv+fyr0YnBEMSnkpHMVaIvIhSKkIgWBHwnu9DK2RYFcgrkbP5ZOvILmP7N7HeZkh4Wxcj+sH7MPklGbX7konpbuj8GubUl+Et9/VGPBOi6D5hXzoVSssd5KAFgpgNMd7VlnWTrqsJArtnwmV+TAYy6ioY6765zgE1aS8gjwY7IRR7JxHMYujPnXKxpJMm4OIKcl9ZXW7s3DzzxM+otu2kaP/V/qJVTR6juiklkGiFSumiD741J+31Ka/Vw2haZWBegFyykpRnQ7GXZEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RRCcooxaUn49Y5RFYJS3Tb7UkTK8Z8DjWOZICGyvy/0=; b=ra3u9H48uJVI4t8TikdmHhewU0j5/SMVuXW35zsoKqOmFbJOKKB0n2+20guYfgFvRHN4dK5BymGlYtEdTJsp95OyMCv93Jzl77VPR4o1kWFG+z1CjpmSqUiiNsJuRoQUmN5ofOEPE0DJD6SZqAlCUz5vqsFEmorHhfyjHkhqTrw= Received: from LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM (20.179.131.80) by LNXP123MB2396.GBRP123.PROD.OUTLOOK.COM (20.179.130.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 6 Mar 2020 12:28:56 +0000 Received: from LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM ([fe80::dc7a:97bb:102a:9c1c]) by LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM ([fe80::dc7a:97bb:102a:9c1c%6]) with mapi id 15.20.2793.013; Fri, 6 Mar 2020 12:28:56 +0000 From: Kirsty P To: "smart@irtf.org" Thread-Topic: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt Thread-Index: AQHV86jPt3WqYZHQGkS6Pyj9v0KtrKg7fH1M Date: Fri, 6 Mar 2020 12:28:56 +0000 Message-ID: References: <158349344094.2274.4065518603647811950@ietfa.amsl.com> In-Reply-To: <158349344094.2274.4065518603647811950@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kirsty.p@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93422c1e-2590-4dd9-c956-08d7c1c9f0cc x-ms-traffictypediagnostic: LNXP123MB2396: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0334223192 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39850400004)(366004)(346002)(376002)(136003)(189003)(199004)(9686003)(8676002)(26005)(186003)(55016002)(81166006)(8936002)(55236004)(86362001)(478600001)(81156014)(966005)(6916009)(52536014)(33656002)(66556008)(316002)(5660300002)(71200400001)(2906002)(66446008)(15650500001)(6506007)(66476007)(66946007)(76116006)(64756008)(7696005)(19627405001); DIR:OUT; SFP:1102; SCL:1; SRVR:LNXP123MB2396; H:LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xInR/1LV1hgZ8kSsRe6BAIpMq/rcU90f+37r8cWaNz6cODEyhnFPLuC3xFgcAJKZNzQiBZeCz3dWxYmGOUdDWyxxts/PAkoB2H9tuo+NqxN6/GOd+UT+Dc0x2hTi9edVlnXssuPabchYMSs9vjByCxtnl9aZnmXtaanZWdCSzlmd90EpH5YLAYtcB/tE5PWo+cdiro+x0KJ2BtUBhFkRwNJs6i1bmKDsW2sBglWP+06E5kQGcwloAuXy3+oqgA+fux/KJR6ckZ+kdPpgy72xsez3m0FzhoSKc/sZ7m5LSx/gvlzF8+QthBMkdxGBYECdyXgY07UMr4OQGQueGMqXqIUW84D6HNixAYGZZs/C9BZIDj0fiOiDNdgKRLzLYUz43Hq9HvFhoVIUn+iH2d7Qx79FQtpLTnkKT3docs5nb1TjruGVi6Llibt+dn/YaBjrX86eU4zZxCcgSqqORxtH0ou2fvWKL4GpApVz2a4eGYR38nTf+18fm7orf28Xb9XK+x6ikMTTWniw338x1WLKSQ== x-ms-exchange-antispam-messagedata: GHzDyw+k4AwYFav8lEaU46cxMepNruXlh33XS/ZcIILU9+Uj7OmbOXWQgtRuBFK7UGAXRuli1WHAt5hpYYsVvNUplwcPNZTCwCzX9Z8tHyG4F/gkscYlnSoiFgzR6aZ+mdnKKYgyX9eQ2SSJwZO5Kg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LNXP123MB23300837148D795BB004451DD7E30LNXP123MB2330GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 93422c1e-2590-4dd9-c956-08d7c1c9f0cc X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 12:28:56.7605 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vTq13b4XyUMPT8VX4NlIO93qOuAri210EP3bGtSthzaNjCtaTQEj6YYuLB2HG021rPblqpTZefDj57rg9kJehQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2396 Archived-At: Subject: [Smart] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt X-BeenThere: smart@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Stopping Malware And Researching Threats List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 12:29:05 -0000 --_000_LNXP123MB23300837148D795BB004451DD7E30LNXP123MB2330GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 De= fence Document date: 2020-03-06 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/id/draft-paine-smart-indicators-of-com= promise-00.txt Status: https://datatracker.ietf.org/doc/draft-paine-smart-indicato= rs-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-ind= icators-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 submissio= n 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 q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LNXP123MB23300837148D795BB004451DD7E30LNXP123MB2330GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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-pai= ne-smart-indicators-of-compromise
Revision:       00
Title:          Indicators of = Compromise (IoCs) and Their Role in Attack Defence
Document date:  2020-03-06
Group:          Individual Sub= mission
Pages:          15
URL:            https://www.ietf.org/id/draft-paine-smart-indicators-of-compromise-00.txt
Status:       &= nbsp; 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-compr= omise


Abstract:
   Indicators of Compromise (IoCs) are an important technique in = attack
   defence (often called cyber defence).  This document outl= ines the
   different types of IoC, their associated benefits and limitati= ons,
   and discusses their effective use.  It also contextualise= s the role
   of IoCs in defending against attacks through describing a rece= nt 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 submissio= n
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 q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LNXP123MB23300837148D795BB004451DD7E30LNXP123MB2330GBRP_-- From nobody Fri Mar 6 13:34:56 2020 Return-Path: X-Original-To: smart@ietfa.amsl.com Delivered-To: smart@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18DA3A0B13 for ; Fri, 6 Mar 2020 13:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=internetpolicyadvisors.com 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 3XF72te7-kml for ; Fri, 6 Mar 2020 13:34:53 -0800 (PST) Received: from cheetah.elm.relay.mailchannels.net (cheetah.elm.relay.mailchannels.net [23.83.212.34]) (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 C2DB83A0B11 for ; Fri, 6 Mar 2020 13:34:52 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|mark@internetpolicyadvisors.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id F2E3C600DE7 for ; Fri, 6 Mar 2020 21:34:48 +0000 (UTC) Received: from pdx1-sub0-mail-a97.g.dreamhost.com (100-96-217-41.trex.outbound.svc.cluster.local [100.96.217.41]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 42D64600AFA for ; Fri, 6 Mar 2020 21:34:48 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|mark@internetpolicyadvisors.com Received: from pdx1-sub0-mail-a97.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Fri, 06 Mar 2020 21:34:48 +0000 X-MC-Relay: Good X-MailChannels-SenderId: dreamhost|x-authsender|mark@internetpolicyadvisors.com X-MailChannels-Auth-Id: dreamhost X-White-Shade: 6d7914a3245cba70_1583530488671_3121667739 X-MC-Loop-Signature: 1583530488671:3437990072 X-MC-Ingress-Time: 1583530488671 Received: from pdx1-sub0-mail-a97.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a97.g.dreamhost.com (Postfix) with ESMTP id 0956080C37 for ; Fri, 6 Mar 2020 13:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d= internetpolicyadvisors.com; h=reply-to:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=internetpolicyadvisors.com; bh=BlB 5hsOd6PeoWNRG1eszFAYzGAg=; b=UP9n47JEbUAxOLEXSwDM5yYLuX7G7m3SFaN uzwor5N0tq7EMWrSIh1UqkXBC5EFOtTkH2yToqmNqiUrvZICfggMqZpgt23uOHJq hLl1nzQ1m574PtQI1NlRL1+3b7Hyzk6qderC+sNyDX1/BzFBlr9lfdWhIBg9MTMG CFYnkb0c= Received: from Kahlo (unknown [47.34.59.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mark@internetpolicyadvisors.com) by pdx1-sub0-mail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 96CAB80C35 for ; Fri, 6 Mar 2020 13:34:41 -0800 (PST) Reply-To: X-DH-BACKEND: pdx1-sub0-mail-a97 From: To: References: <158352872769.2262.9600391745824919737@ietfa.amsl.com> In-Reply-To: <158352872769.2262.9600391745824919737@ietfa.amsl.com> Date: Fri, 6 Mar 2020 15:34:40 -0600 Organization: internet policy advisors Message-ID: <001501d5f3ff$0c41da30$24c58e90$@internetpolicyadvisors.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMTeV+cVU1KqAva0/dA6LTr2iCA/qXBBsKA Content-Language: en-us X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudduvddgudehfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurheprhfhvfhfjgfuffhokfggtgfgofhtsehtqhhgtddvtdejnecuhfhrohhmpeeomhgrrhhksehinhhtvghrnhgvthhpohhlihgthigrughvihhsohhrshdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepgeejrdefgedrheelrdduieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopefmrghhlhhopdhinhgvthepgeejrdefgedrheelrdduiedprhgvthhurhhnqdhprghthhepoehmrghrkhesihhnthgvrhhnvghtphholhhitgihrgguvhhishhorhhsrdgtohhmqedpmhgrihhlfhhrohhmpehmrghrkhesihhnthgvrhhnvghtphholhhitgihrgguvhhishhorhhsrdgtohhmpdhnrhgtphhtthhopehsmhgrrhhtsehirhhtfhdrohhrgh Archived-At: Subject: [Smart] New Version Notification for draft-mcfadden-smart-rfc3552-textual-research-00.txt X-BeenThere: smart@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Stopping Malware And Researching Threats List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 21:34:55 -0000 A new version of I-D, = draft-mcfadden-smart-rfc3552-textual-research-00.txt has been successfully submitted by Mark McFadden and posted to the IETF = repository. Name: draft-mcfadden-smart-rfc3552-textual-research Revision: 00 Title: Textual Analysis Methodology for Security Considerations = Sections Document date: 2020-03-06 Group: Individual Submission Pages: 16 URL: = https://www.ietf.org/internet-drafts/draft-mcfadden-smart-rfc3552-textual= -research-00.txt Status: = https://datatracker.ietf.org/doc/draft-mcfadden-smart-rfc3552-textual-res= earch/ Htmlized: = https://tools.ietf.org/html/draft-mcfadden-smart-rfc3552-textual-research= -00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-mcfadden-smart-rfc3552-textua= l-research Abstract: [RFC3552] provides guidance to authors in crafting RFC text on Security Considerations. The RFC is more than fifteen years old. With the threat landscape and security ecosystem significantly changed since the RFC was published, RFC3552 is a candidate for update. This draft proposes that, prior to drafting an update to RFC3552, an examination of recent, published Security Considerations sections be carried out as a baseline for how to improve RFC3552. It suggests a methodology for examining Security Considerations sections in published RFCs and the extraction of both quantitative and qualitative information that could inform a revision of the older guidance. It also reports on a recent experiment on textual analysis of sixteen years of RFC Security Consideration sections. From nobody Fri Mar 27 06:07:25 2020 Return-Path: X-Original-To: smart@ietfa.amsl.com Delivered-To: smart@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA5E3A0883 for ; Fri, 27 Mar 2020 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 pEsGv2ErCQCd for ; Fri, 27 Mar 2020 06:07:21 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608DE3A083F for ; Fri, 27 Mar 2020 06:07:21 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id p10so9890489ljn.1 for ; Fri, 27 Mar 2020 06:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ah3FSXec4BT70r8LlONezvqRPvSHL1L6biFGr5POt+c=; b=1nP5nBHhh16NopK++q9vUxuqgZNUlFOi4IyaO2oP2HW7qdTAlGSe8CZ3gv40Z2SkEI LWKNgCgqZ4s9yS5qIkzQH+AzxPSG8fDtJGRYL9Az0DH59m8rb2vmqJ7pPdhsDV7xu8Aw zBaHeEqwjPaKOwi+yc0tyavyh4Yb36nI+UOZjfSuY4MgIBdvPmqNRkW4IhCOWZwULjum oHvcboMgk5fN6BPFa1aAKrn2jKuzrxp1+seBPFav2xxOuxpvuwmjNc/BI55/0j+4G1y+ OODVbzh7+tSZkCZ2CuXUEGbOlgKpw5FIzEzlIvL4JtTUNtUOZNXeSMRhqPbhE5UafYH3 tFYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ah3FSXec4BT70r8LlONezvqRPvSHL1L6biFGr5POt+c=; b=KD2VSMVbovIFnw8LtWWs/5k6FNfHKJHHf9ffqHx+/xEcZGF42XNASr5CnOwAjnonVQ ObBRQwRRYECUBumxhSGplokl6jGZ1AZP8kALSwcVkMstJowoyNWfr1MM2XgdS9DiFjtW GQNSiYtyo8OI8Ao3N0mm5h+CirrKMBZxte8ONUgPOeXoeExhK5RQL9wqBrg0hcL1gNQ/ e9u4d39AfS0LwdsaMiO4J3f98T95w1Ov6QFXMYneD1otg9aqBhJ4NPLHu2N+5RUZh+/J cSmZporsUKg0nJLGCfB+JEGZ3mrVGIfPkJqdt/5C0dTscvy3hju9epngVWGGLVqR3zyU PUcw== X-Gm-Message-State: AGi0PuYb9FwHPNWwjEJywga61sJrOpZDWtzx9jAdvf2l3q060VvF/c/d sU3Em6vpaGFlk0lV2Gwy+ig/FCLg+03wApTQiOsJYTQ/Ud2Upg== X-Google-Smtp-Source: APiQypIsNkgFBtevmQoKf14PyRJUlB/Dl52jaWpx7WC2HqVV1CC8mKy61ca2yf0JUqFq0ePz9RNscuwpAJh2liXJ+wE= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr7141132ljl.35.1585314439253; Fri, 27 Mar 2020 06:07:19 -0700 (PDT) MIME-Version: 1.0 References: <158349344094.2274.4065518603647811950@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Fri, 27 Mar 2020 06:06:42 -0700 Message-ID: To: Kirsty P Cc: "smart@irtf.org" Content-Type: multipart/alternative; boundary="0000000000000276eb05a1d5c876" Archived-At: Subject: Re: [Smart] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt X-BeenThere: smart@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Stopping Malware And Researching Threats List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 13:07:24 -0000 --0000000000000276eb05a1d5c876 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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-compromi= se/ > 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-com= promise > > > 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 an= y > FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown > Copyright =C2=A9 > -- > Smart mailing list > Smart@irtf.org > https://www.irtf.org/mailman/listinfo/smart > --0000000000000276eb05a1d5c876 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-paine-smart-indicators-of-compromise-00.tx= t

Kirsty,

Thanks for sending this. I have attached some revie= w comments
below.

To the SECDISPATCH questions, it's not clea= r to me that this fits that
well into any particular present venue. I ag= ree it's useful to have
this information out there, but I guess my q= uestion 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 th= e best venue.

-Ekr

S 2.
=C2=A0 =C2=A0o =C2=A0IP addresses<= br>
=C2=A0 =C2=A0o =C2=A0domain names


=C2=A0 =C2=A0o =C2=A0TL= S Server Name Indicator values

"server name indication"
=C2=A0 =C2=A0o =C2=A0certificate information

=C2=A0 =C2=A0o =C2= =A0signatures such as binary code patterns and strings

=C2=A0 =C2=A0= o =C2=A0hashes of malicious binaries or scripts

=C2=A0 =C2=A0o =C2= =A0attack tools, such as mimikatz [Mimikatz]

=C2=A0 =C2=A0o =C2=A0at= tack techniques, such as Kerberos golden tickets [GoldenTicket]


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


S 3.2.

=C2=A0 =C2=A0The corr= espondence is one-to-many: simply blocking one IoC may
=C2=A0 =C2=A0prot= ect thousands of users within an organisation.=C2=A0 Discovering one
=C2= =A0 =C2=A0IoC can be intensive, but sharing IoCs via well-established route= s
=C2=A0 =C2=A0such as the Malware Information Sharing Platform (MISP) [= MISP] will
=C2=A0 =C2=A0protect thousands of organisations and end users= .=C2=A0 The shareability
=C2=A0 =C2=A0and reproducibility of IoCs is a h= uge advantage; it allows a threat
=C2=A0 =C2=A0defender to look for thin= gs consistently and automate the process of
=C2=A0 =C2=A0defending their= networks.=C2=A0 It doesn't require intensive training (as
=C2=A0 = =C2=A0needed to, for example, manually analyse tipped machine learning
= =C2=A0 =C2=A0events), nor does it require time-intensive resource to deploy= IoCs.

This text seems kind of confusing, as it seems to conflate tw= o
activities that might be termed "discovery" namely discoveri= ng new
IoCs and discovering that they are in play in a given network. Fo= r
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 c= onnecting to attacker.com. I
think w= hat might help here would be to have some kind of overview of
an IoC lif= ecycle. This isn't my area of expertise, but this might look
somethi= ng like:

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

S 3.7.
=C2=A0 =C2=A0As an example, open source malware can be d= eployed by many different
=C2=A0 =C2=A0actors, each with their own "= ;Tactics, Techniques and Procedures"
=C2=A0 =C2=A0(TTPs) and infras= tructure.=C2=A0 However, if the same executable is used,
=C2=A0 =C2=A0th= e hash remains the same - and this IoC can be deployed in endpoints
=C2= =A0 =C2=A0
Is there a reason you specify "open source"? Can= 9;t closed source malware
also be deployed by many different actors? May= be you're connecting this
to the idea that you could recompile it wi= th a different hash, but
one can actually quite easily change binaries t= o have the same function
but with different contents, which obviously ch= anges the hash.


S 4.1.
=C2=A0 =C2=A0IoCs form a "Pyramid= of Pain" [PoP] that can be used for prevention,
=C2=A0 =C2=A0detec= tion and mitigation.=C2=A0 This represents how much pain it is: to an
= =C2=A0 =C2=A0adversary to change and for the defender to gather.=C2=A0 The = layers of
=C2=A0 =C2=A0the PoP range from hashes to TTPs and the pain ra= nges from
=C2=A0 =C2=A0recompiling code to creating a new attack strateg= y.

This seems to claim that there is a correspondence between howeasy it is for an adversary to change an IoC and a defender to
gather t= hat 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 seem= s much easier than gathering
hash values, though I agree with you that i= t's easier to
change hash values. It does seem like the fragility/pr= ecision
axis is more likely to align, but I haven't thought about th= at
too hard. In any case, if you think this is a deep connection,
I w= ould encourage you to make that argument more explicit
rather than just = providing examples.

S 4.4.
=C2=A0 =C2=A0contexts where ensuring e= ndpoint security isn't possible such as
=C2=A0 =C2=A0"Bring You= r Own Device" (BYOD), IoT and legacy environments.=C2=A0 Using
=C2= =A0 =C2=A0these network level IoCs can also protect against a compromised=C2=A0 =C2=A0endpoint as, even if the compromise passes unnoticed, the Io= Cs can
=C2=A0 =C2=A0still be checked against network traffic, allowing d= etection of the
=C2=A0 =C2=A0attack.=C2=A0 For example, in a BYOD enviro= nment, enforcing security
=C2=A0 =C2=A0policies on the device can be dif= ficult, so non-endpoint IoCs and
=C2=A0 =C2=A0solutions are needed to al= low detection of compromise even with no
=C2=A0 =C2=A0endpoint 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 browse= rs have some sort of safe browsing type
technology.

S 5.
=C2= =A0 =C2=A0queries) for the organisations signed up to the service [ACD2019]= . 28
=C2=A0 =C2=A0million of them were for domain generation algorithms = (DGAs),
=C2=A0 =C2=A0including 15 known DGAs.=C2=A0 IoCs such as malicio= us domains can be put

This seems to be the first time you mention DG= As, 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=3D40ncsc.gov.uk@dmarc.ietf.org> wrote:

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

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


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




Please note that it may take a couple of minutes from the time of submissio= n
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 q= ueries to ncsc= infoleg@ncsc.gov.uk. All material is UK Crown Copyright =C2=A9
--
Smart mailing list
Smart@irtf.org
https://www.irtf.org/mailman/listinfo/smart
--0000000000000276eb05a1d5c876-- From nobody Fri Mar 27 06:23:48 2020 Return-Path: X-Original-To: smart@ietfa.amsl.com Delivered-To: smart@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1743A05A4 for ; Fri, 27 Mar 2020 06:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZsF3m27Bfhxr for ; Fri, 27 Mar 2020 06:23:42 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB84F3A03EE for ; Fri, 27 Mar 2020 06:23:42 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id z5so9383267oth.9 for ; Fri, 27 Mar 2020 06:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bhgc9ahJqm1Z3AEX+nd0PCexDXLbBOhA+PqB6WHHUHM=; b=BJNWaESI082H1FlAtZM8LTxm6wbTUUggyiYn3cdauTQSfEN6CbbVaptUM5FuR8U60i RrKfGZdUlQ+TeCdkHolzzxyqZm8ueT6jOF6AOSkhGGcFkfNox0cr+YiJ1pGioIGEKpGp EKfarYEupiLRuTaPWg3BUAjoB9T9nT3+lGw7Qj4bAMDynlRgtl7UjZPniBCGG6s7qPOi 7es62O1AKsQTLLLL5NqmpboaYMFmH1xqIFEPyCR4nurg9F6rI5ObHaOpw/VUFxXKz0/2 gmoTXSZGJxeqMroMjQ+3T7soaWv5iuZoGfHgfBUIWTrBUxJwVdyPf/4sl4mLC6E4Bavt eY1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bhgc9ahJqm1Z3AEX+nd0PCexDXLbBOhA+PqB6WHHUHM=; b=o6FmmTpof2fdnwc2lG4ZBm9R+8gfvZz/9oOmN02crs1R8wFFpF6RNQJFedDdvA182p clpcsEWjHw5kdqDsDsm4Cy5UEqD7nkbKZwJ2eWhgLDgGmrXaIXD8y2GM+HxakICE5PdF DnVhlEf+6DShUEF4Y4ya4lWXdcs6Qn6JSsAqdSgGOgxOaJy1QhzSCG2S8xTIle/4hs3z 32AdUqkyJCWAQ0+4+4DGc3H15YFDKlK9JV8LreiWF3uCWsyT+hMGdhwLdRlWWn6rwp8q Q4LunNDYtW76oxhkGogBrYAwfwh4dbeRd48IUX7Sepvc1QIdhZ0VFpTMoztOZ9J+l5p4 efDw== X-Gm-Message-State: ANhLgQ2V7feaGR4p3GWzNnRv25lI7u0Aa4M3ZYezmJ9jLkjApXsKNzv9 DEy4qUcg5JqncP7yLEPAIxfr02h5C41emDGsJ2OGCPmU X-Google-Smtp-Source: ADFU+vt5bMaXp5qY4Y4VbNiK8k3MHnqpjOrtRL0T03VFGFEUZYGKdvZ6gCRLOJ6fkcKbzvaNA4Oj1NnqAbpLEAV7y2I= X-Received: by 2002:a9d:694a:: with SMTP id p10mr10817848oto.151.1585315421900; Fri, 27 Mar 2020 06:23:41 -0700 (PDT) MIME-Version: 1.0 References: <158349344094.2274.4065518603647811950@ietfa.amsl.com> In-Reply-To: From: Kathleen Moriarty Date: Fri, 27 Mar 2020 09:23:05 -0400 Message-ID: To: Kirsty P Cc: "smart@irtf.org" Content-Type: multipart/alternative; boundary="0000000000009453e105a1d602c2" Archived-At: Subject: Re: [Smart] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt X-BeenThere: smart@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Stopping Malware And Researching Threats List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 13:23:47 -0000 --0000000000009453e105a1d602c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ROLI= E (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 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 40ncsc.gov.uk@dmarc.ietf.org <40ncsc.gov..uk@dmarc.ietf.org>> 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.tx= t >> Status: >> https://datatracker.ietf.org/doc/draft-paine-smart-indicators-of-comprom= ise/ >> Htmlized: >> https://tools.ietf.org/html/draft-paine-smart-indicators-of-compromise-0= 0 >> >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-paine-smart-indicators-of-co= mpromise >> >> >> 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 a= ny >> FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown >> Copyright =C2=A9 >> -- >> Smart mailing list >> Smart@irtf.org >> https://www.irtf.org/mailman/listinfo/smart >> > -- > Smart mailing list > Smart@irtf.org > https://www.irtf.org/mailman/listinfo/smart > --=20 Best regards, Kathleen --0000000000009453e105a1d602c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your draft, Kirsty.=C2=A0 This provides a ni= ce summary of the current state for IoCs.=C2=A0 In your presentation this e= vening, 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?=C2=A0 It may even then reference=C2=A0some of the work of MILE, = such as ROLIE (adopted into SCAP 2.0).
  2. Will the draft evolve to sta= te applicability to IETF protocols with new thoughts on how IoCs may be use= d?=C2=A0 If so, what are some initial seed ideas as I think that will great= ly aid the conversation and lead to a potential direction (1 or 2).
    3. Thanks for your work and congratulations on submitting your first dr= aft.=C2=A0

I look forward to hearing more.

Best regards,
Kathleen

On Fri, Mar 2= 7, 2020 at 9:07 AM Eric Rescorla <ekr@rt= fm.com> 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 no= t 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 gues= s 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 illumin= ate the best venue.

-Ekr

S 2.
=C2=A0 =C2=A0o =C2=A0IP addr= esses

=C2=A0 =C2=A0o =C2=A0domain names


=C2=A0 =C2=A0o = =C2=A0TLS Server Name Indicator values

"server name indication&= quot;

=C2=A0 =C2=A0o =C2=A0certificate information

=C2=A0 =C2= =A0o =C2=A0signatures such as binary code patterns and strings

=C2= =A0 =C2=A0o =C2=A0hashes of malicious binaries or scripts

=C2=A0 =C2= =A0o =C2=A0attack tools, such as mimikatz [Mimikatz]

=C2=A0 =C2=A0o = =C2=A0attack techniques, such as Kerberos golden tickets [GoldenTicket]
=

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


S 3.2.

=C2=A0 =C2=A0= The correspondence is one-to-many: simply blocking one IoC may
=C2=A0 = =C2=A0protect thousands of users within an organisation.=C2=A0 Discovering = one
=C2=A0 =C2=A0IoC can be intensive, but sharing IoCs via well-establi= shed routes
=C2=A0 =C2=A0such as the Malware Information Sharing Platfor= m (MISP) [MISP] will
=C2=A0 =C2=A0protect thousands of organisations and= end users..=C2=A0 The shareability
=C2=A0 =C2=A0and reproducibility of = IoCs is a huge advantage; it allows a threat
=C2=A0 =C2=A0defender to lo= ok for things consistently and automate the process of
=C2=A0 =C2=A0defe= nding their networks.=C2=A0 It doesn't require intensive training (as=C2=A0 =C2=A0needed to, for example, manually analyse tipped machine lear= ning
=C2=A0 =C2=A0events), nor does it require time-intensive resource t= o deploy IoCs.

This text seems kind of confusing, as it seems to con= flate two
activities that might be termed "discovery" namely d= iscovering new
IoCs and discovering that they are in play in a given net= work. 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 disc= over 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 t= hat a given feature is an IoC
- Sharing that IoC to other entities via M= ISP or the like
- Deploying detection for that IoC
- Detecting IoCs o= n user computers
- Investigation, etc.


S 3.7.
=C2=A0 =C2= =A0As an example, open source malware can be deployed by many different
= =C2=A0 =C2=A0actors, each with their own "Tactics, Techniques and Proc= edures"
=C2=A0 =C2=A0(TTPs) and infrastructure.=C2=A0 However, if t= he same executable is used,
=C2=A0 =C2=A0the hash remains the same - and= this IoC can be deployed in endpoints
=C2=A0 =C2=A0
Is there a reaso= n you specify "open source"? Can't closed source malware
a= lso be deployed by many different actors? Maybe you're connecting this<= br>to the idea that you could recompile it with a different hash, but
on= e can actually quite easily change binaries to have the same function
bu= t with different contents, which obviously changes the hash.


S 4= .1.
=C2=A0 =C2=A0IoCs form a "Pyramid of Pain" [PoP] that can = be used for prevention,
=C2=A0 =C2=A0detection and mitigation.=C2=A0 Thi= s represents how much pain it is: to an
=C2=A0 =C2=A0adversary to change= and for the defender to gather.=C2=A0 The layers of
=C2=A0 =C2=A0the Po= P range from hashes to TTPs and the pain ranges from
=C2=A0 =C2=A0recomp= iling code to creating a new attack strategy.

This seems to claim th= at 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 concr= ete 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 t= o 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= .
=C2=A0 =C2=A0contexts where ensuring endpoint security isn't possi= ble such as
=C2=A0 =C2=A0"Bring Your Own Device" (BYOD), IoT a= nd legacy environments.=C2=A0 Using
=C2=A0 =C2=A0these network level IoC= s can also protect against a compromised
=C2=A0 =C2=A0endpoint as, even = if the compromise passes unnoticed, the IoCs can
=C2=A0 =C2=A0still be c= hecked against network traffic, allowing detection of the
=C2=A0 =C2=A0a= ttack.=C2=A0 For example, in a BYOD environment, enforcing security
=C2= =A0 =C2=A0policies on the device can be difficult, so non-endpoint IoCs and=
=C2=A0 =C2=A0solutions are needed to allow detection of compromise even= with no
=C2=A0 =C2=A0endpoint coverage.

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

S 5.
=C2=A0 =C2=A0queries) for the organis= ations signed up to the service [ACD2019].. 28
=C2=A0 =C2=A0million of t= hem were for domain generation algorithms (DGAs),
=C2=A0 =C2=A0including= 15 known DGAs.=C2=A0 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 &= lt;Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> wrote:

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

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


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




Please note that it may take a couple of minutes from the time of submissio= n
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 q= ueries to ncsc= infoleg@ncsc.gov.uk. All material is UK Crown Copyright =C2=A9
--
Smart mailing list
Smart@irtf.org
https://www.irtf.org/mailman/listinfo/smart
--
Smart mailing list
Smart@irtf.org
https://www.irtf.org/mailman/listinfo/smart


--

Best regards,
Kathleen
--0000000000009453e105a1d602c2--