[OPSEC] Review of draft-paine-smart-indicators-of-compromise

Fernando Gont <fgont@si6networks.com> Thu, 11 February 2021 00:21 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4B4403A09EA; Wed, 10 Feb 2021 16:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mjGQsuzwZmJz; Wed, 10 Feb 2021 16:21:31 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB87F3A0AB5; Wed, 10 Feb 2021 16:21:23 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:8956:4518:7147:354b] (unknown [IPv6:2800:810:464:2b9:8956:4518:7147:354b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 34B54283B44; Thu, 11 Feb 2021 00:21:19 +0000 (UTC)
From: Fernando Gont <fgont@si6networks.com>
To: draft-paine-smart-indicators-of-compromise@ietf.org
Cc: "opsec@ietf.org" <OpSec@ietf.org>, Kirsty P <Kirsty.p@ncsc.gov.uk>, Ollie Whitehouse <ollie.whitehouse@nccgroup.com>
Message-ID: <46e4e492-045a-4a02-9f19-8063680a0ad1@si6networks.com>
Date: Wed, 10 Feb 2021 21:20:06 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/SaYRmSReCz4t9Ai1czgMVn8FZ98>
Subject: [OPSEC] Review of draft-paine-smart-indicators-of-compromise
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2021 00:21:36 -0000


As promised, I've reviewed the aforementioned document. These are my 
comments (fwiw, there's an implicit "IMHO" in each comment, of course):

**** Meta ****

The document was an interesting read. Upon a first read it would seem to 
me that:

* Section 5 might come right before Section 8 (security considerations) 
instead -. at the end of the day, it reads like the conclusions of your 
work.. however the reader probably needs the other material first to 
make sense of the conclusions.

* Any reason why "Case Study: Cobalt Strike" and "Appendix A.  Case 
Study: APT33" are not together (e.g. silbing sections, whether in the 
document body or in the appendix)?

* Somewhere in Section 3 I'd provide pointers to the case studies, 
noting that they provide examples of IoCs.

* After reading the document, I was wondering if it was within the scope 
of the charter, so I've re-read the charter and it seems there's room 
for this kind of documents.  I make this note because IIRC opsec has 
generally produced more specific low-level technical documents, more 
closely linked with specific protocols and technologies. But I believe 
it is always a good thing to try to do more, particularly when it's 
useful stuff!

* Regarding the case studies, could you provide more info such as the 
usefulness of the IoC, and their practical effectiveness and fragility 
for these case studies?

**** Some detailed comments *****

* Abstract

Please shorten it to < 5 lines.

* Section 1:

Not sure I'd use the term "open source" as it's employed in Section 1.

* Section 1.1.

This should be:
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "OPTIONAL" in this document are to be interpreted as described in BCP
    14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here.

However, after reading this document it seems you don't use any RFC2119 
terms, so you can simply remove this para/section.

* Section 3.:

     help to identify an occurrence of an
    intrusion or associated activity to a known intrusion set.

maybe s/identify/associate/ ?

* Section 3:

    IoC without context is not much
    use for network defence

s/much/of much/ ?

* Section 3:

Either provide more detail on the lifecycle, or provide a suitable 

* Section 3:

    confidence level, fragility and
    precision of the IoC

Please elaborate on what you mean by each of these.

* Section 4:

You may want to provide a reference to "domain fronting", or simply add 
it to the terminology section.

* Section 4.2:
       IP addresses of the command and control servers

       domain names used

Probably list them as bullets.

* Section 5.1:

s/resource/resources/ ?

* Section 7:

* Section 7:

I'm not a fan myself of things like DoH. However, maybe something should 
be mentioned about the possible impact?

* Appendix A:

I haven't gone in detail through the referenced report. However, let's 
just say that I'm usually rather skeptical much of the "attribution" 
that one finds on many reports and, to the extent that is possible, try 
to stay away from it as much as necessary. :-) (if anything, I'm more in 
the camp of "assumed to", "allegedly...", etc., so to speak).  It's good 
that you cite the sources -- although the title "Insights into Iranian 
Cyber Espionage" might have some negative connotation to some -- but, at 
the end of the day, if anything, it's simply an adversary (many 
governments do the same kind of thing, one way or another).

* Note:
Appendix A says "..such a sophisticated and powerful adversary"  but 
then Section A.1 says: "The techniques employed by this actor exhibit a 
relatively low level of sophistication". So there would seem to be 
something missing in between.


Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492