Hi, I also volunteered to review the draft-paine-smart-indicators-of-compromise draft and my comments follow:
I think the document is relevant and in scope for opec as it highlights another swath of the cybersecurity discipline that should be raised in this community. I would add though, the document should provide more details on the common IoC instantiations and communications used today especially the more common ones (detailing what would be the best practice). Nits —— Section 3: Still has a “TODO” that should get resolved….my suggestion is that it would be good to describe what an IoC lifecycle means, and why these stages are needed/required. How are IoCs expressed and communicated today? That would also be useful to include. 4.1: As this is the first reference, “C2” should be expanded (Command and Control, I presume) The document would flow better if Section 5 followed Section 3 5.2 more elaboration or data to substantiate the “ease” of deployment and use of IoCs are needed. I think you take a “leap” in stating that “….if deployed quickly via a mechanism such as a protective DNS filtering service”, as I think it would depend on the IoC? And relates back to “common practice today” which I think is missing in the document. 5.3 Subjectively, STIX could be viewed as either “easy” or “not” easy to share. This section perhaps should be better suited as “IoC commonly used formats” of which STIX is one; but given this is targeted as a best practice, mention of other commonly used ones like OpenIOC unless you are prescribing that STIX is more superior (but then, I’d expect rationale to substantiate that stance too). 5.4 The title of this section suggests the section would be on how IoC’s map to specific threat actors but the prose is more about orgs choosing which IoCs to use based on the info? Can you provide more description in this section on how IoC’s could be categorized to then allow that categorization to be mapped to a threat actor? Sections 5.2-5.4 don’t read like a use case to me. 5.5 can you describe how they are shared today? And can that be used as a best practice? Section 8: can be construed as both Security and Privacy considerations. * There are security considerations to the IoC “exchange” as well. How trusted/reliable the IoC information is…especially over time? IoC source/provenance? Section 9: I’m not sure I understand and would disagree on IoCs not needing protection? Depending on the communication channel, how does the recipient know that the IoC information is authentic? While I may argue that it doesn’t need to be confidential, considerations from tampering are required. Questions to consider —————————— * Is there a well understood semantic format(s) for IoCs? What is more commonly used, what is the “best practice” to date? * Is there one or more “standardized” IoC exchange data and communication format? Some discussion on this topic would be good. Best, Nancy
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
