[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Question on indicator patterns
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.On Jul 17, 2016, at 16:28, Patrick Maroney <Pmaroney@Specere.org> wrote: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.http://docs.oasis-open.org/kmip/profiles/v1.2/os/kmip-profiles-v1.2-os.html. Latest version: http://docs.oasis-open.org/kmip/profiles/v1.2/kmip-profiles-v1.2.html
 [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. http://docs.oasis-open.org/kmip/testcases/v1.2/cn01/kmip-testcases-v1.2-cn01.html. Latest version: http://docs.oasis-open.org/kmip/testcases/v1.2/kmip-testcases-v1.2.html.
Integrated Networking Technologies, Inc.
On Sun, Jul 17, 2016 at 4:50 PM -0400, "Terry MacDonald" <firstname.lastname@example.org> wrote:
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.
On 16/07/2016 6:10 PM, "Patrick Maroney" <Pmaroney@specere.org> wrote:
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.