Folks,
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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
reference.
* 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:
s/endpoitn/endpoint/
* 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.
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
