From the Information Assurance Implementation Considerations document currently being drafted for OpenC2:
"One of the cornerstone ideals from the Information Systems Security Engineering process is to separate the problem space from the solution space. The problem space defines what the system will do, while the solution space defines how the system will solve
2 1/2 of the three tenets lie squarely within the problem domain, and I believe are entirely appropriate as aspirational statements motivating CTI efforts. The second half of tenet three (system hardening) encroaches on the solution domain and may not be appropriate
as a tenet.
I agree with Bret's other point that baby steps (verifying protocol interoperability) are most appropriate at this technology readiness level. Once STIX has the same market penetration and universal interoperability as, say, TLS :-), then ISSE, risk management,
profiles, conformance levels, and certification efforts may come into play.
NSA, Secure Mission Architecture Engineering
From: firstname.lastname@example.org [mailto:email@example.com
] On Behalf Of Jerome Athias
Sent: Monday, July 18, 2016 10:30 PM
To: Jordan, Bret
Cc: Patrick Maroney; Terry MacDonald; firstname.lastname@example.org; John A. Wunder; Allan Thomson; John-Mark Gurney
Subject: Re: [cti] Question on indicator patterns
As a CISSP, I would have to point you to the (ISC)2 Code of Ethics.
While I can understand that Pat points could be more appropriate in the context of guidelines around CTI, or in another Top Level Standard for CTI implementation (a la PCI DSS i.e.), neglecting the 'CTI Threat Model', imho, would not help preserving and so
for promoting public trust and confidence in the CTI infrastructure.
Examples of such, at this point, are encryption or non-repudiation.
On Tuesday, 19 July 2016, Jordan, Bret <email@example.com> wrote:
STIX and CybOX are language specifications, not products. As such they can not do or require any type of implementation details. About the only place we can do some of that is in TAXII.... And even then, it will be limited. It is really up to vendor
to produce good products and users to implement and deploy those products in a sound way.
So no, I do not agree with those core tenets. They are unachievable.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Perhaps we can achieve consensus on the following and move forward from there:
(1) The nature of systems producing, transporting, consuming, and operationalizing CTI represent a special class in terms of risks and impacts of compromise.
(2) Our Adversaries will agressively target these systems as the effectiveness of same impede their ability and/or increase efforts/costs to execute "Actions on ObjectIves".
(3) Attack Surface Reduction (ASR) should be a core tenet of the CTI TC Standards. A majority of the diverse sets of systems operationally participating in a global CTI Ecosystem require system hardening.
Therefore, CTI TC Standards should only require implementation of the specific functional elements (e.g., Ports, Protocols, Services, Application interfaces) required to deliver a conformant instantiation of that feature/function.
If we concur on these core tenets, then we need a mechanism to manage the resultant variability in conformant systems. One way is to establish "Profiles".
The OASIS KMIP TC provides a reference implementation of the practical application of "Profiles" to Confomance Clauses and Interoperability Testing . KMIP Profiles in turn link to associated KMIP Test Cases. Any Interested parties seeking representative
examples of the principles advocated here can start with the Key Management Interoperability Protocol  Profiles and  Test-Cases.
 [ KMIP-Profiles] Key Management Interoperability Protocol Profiles Version 1.2. Edited by Tim Hudson and Robert Lockhart. 19 May 2015. OASIS Standard.
. Latest version:
 [KMIP-testcases-v1.2] Key Management Interoperability Protocol Test Cases Version 1.2. Edited by Tim Hudson and Faisal Faruqui. 11 November 2014. OASIS Committee Note 01.
. Latest version:
Integrated Networking Technologies, Inc.
Maybe this is where we need to separate the STIX certification into different categories to enable that differentiation to be recorded?
Full STIX compliance: full STIX including full CybOX objects and patterning.
Partial STIX compliance: STIX implementation of more than the specialized STIX compliance but not a full implementation of all parts of STIX.
Specialized STIX compliance: STIX and CybOX only focused on a specific subset of the language, and designed for a single purpose.
For a full STIX implementation I would expect the platform to implement the CybOX patterning. For a specialized STIX implementation I would expect it to only be implemented if it was required in that instance.
And as for allowing extensions to the list of signatures/patterns, I agree that's a good idea.
Since this thread got bifurcated, I’m inserting my earlier comments below. This is followed by a question and Use Case Example.
“1. Should implementing CybOX Patterning be required for tools that want to claim they processes STIX indicators?: No.
Suggest this "claims" aspect be part of "Profiles" (this term is intended in the sense of other standards: e.g. KMIP Profiles vs. the legacy STIX Profiles context).
2. Should we allow for pattern types to be used that are not explicitly listed in the specification?: Yes.
I think we should allow for extensibility. I don't want to go down the "rabbit-hole", but for example one might want to express analytic/statistical patterns. Allowing this would enable us to experiment and bring forth and demonstrate
practical applications for consideration in future versions of the standards.”
Since a STIX indicator can use multiple pattern_lang(s) in addition to CybOX, why should an implementation be required to implement CybOX Patterns to be compliant?
Use Case Example:
Analysts from the ACME ISAC member organizations crowd-source the development and inter-exchange of Yara and ClamAV signatures via the ACME ISAC collaboration portal. Over time these signatures provide increasingly high fidelity detections
of new variants of 0Day exploits in attachments, MIME multipart-message subtypes, embedded links, etc. Based on the proven success of these signatures, some ACME ISAC members collectively developed custom hardened external mail gateways to process all incoming
email messages and attachments. They used a combination of open source projects including Yara and ClamAV). An increasing percentage of ISAC member organizations are implementing similar in-house capabilities.
Although analysts and security operations staff receive immediate email notifications of new/modified Yara and ClamAV signatures, each organization has to login, review, manually download these signatures from the central ACME ISAC portal,
and then transfer them to their custom external mail gateways. Any delay in the download and operationalization of these new APT 0Day Yara and ClamAV signatures can result in completely missing the initial wave(s) of 0Day attacks. This scenario often results
in 100s to 1,000s of compromised systems, adversary entrenchment, etc., vs. stopping the attack at the perimeter early in the kill-chain. In the ACME sector, minutes can make the difference between a non-event and a multi-million-dollar incident.
ACME members want to use the CTI STIX andTAXII Standards via the ACME ISAC TAXII Central Gateways to automatically publish new high value, high priority, ClamAV and Yara signatures to their ISAC Membership via TAXII Feeds. They only
want to add the STIX and TAXII python code to their custom external mail gateways required to (1) subscribe to the ClamAV and Yara Feeds and (2) automatically deploy new/updated signatures.
"title": "Poison Ivy ClamAV Sig Example",
"title": "Poison Ivy"
By establishing Development TAXII Feeds, ACME ISAC can now also automatically publish and crowd-source testing of new signatures across a diverse set of ACME ISAC member environments. This greatly accelerates iterations through the
development lifecycle and the delivery of high quality, fully vetted signatures.
Since they’re using CTI STIX and TAXII Standards, those ACME ISAC members requiring an intermediary process before operationalizing the signatures can implement their own custom workflows/code to process the ACME ISAC TAXII Feeds. They
can then publish via TAXII to their external mail gateways when approved.
ACME ISAC manually shares select signatures with other external trusted entities. In some cases, they use trusted entities to strip attribution and re-publish signatures to other sectors or publicly. This manual sharing of signatures
consumes resources, delays dissemination, and complicates tracking, version control, etc. Most of these trusted entities have operational TAXII Gateways or can process STIX Packages sent via secure Email. ACME ISAC wants to use CTI STIX and TAXII Standards
to automatically publish these high value ClamAV and Yara signatures via TAXII Feeds to these trusted entities. By using the CTI STIX and TAXII Standards, all they need to do on their end is establish the Feeds.
The authors of current tools that analyze and convert artifacts into non-CybOX pattern_lang signatures (e.g., Yara, ClamAV) can provide CTI Standards compliant frameworks that enable everyone to automatically consume artifacts and publish
signatures via STIX and TAXII.
In this real-world Use Case, the ACME ISAC Central TAXII Gateways need to be “Full Service” implementations (including CybOX support). However, the end points (1) custom external mail gateways and (2) tools to create ClamAV and YARA
Signatures, do not.
Why should the stakeholders at the edges of this ArtifactèAnalsysisèSignatureèOperationalization Chain have to implement the extra code required to process CybOX objects and patterns?
From both a Reliability and Security perspective, we should allow, in fact encourage, agents to implement only those functions required to fulfill their specific role(s) in the CTI TC Standards Ecosystem.