OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Question on indicator patterns


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.”

 

 

Question:

 

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.

 

 

[

 {

   "type": "indicator",

   "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

   "created": "2016-04-06T20:03:48Z",

   "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",

   "title": "Poison Ivy ClamAV Sig Example",

   "description": "Backdoor.PoisonIvy.DX",

   "pattern":"Find.ClamAV.StartAt.300;Engine:81255,Target:0;3;616c696e;62773238;636564;300:0&1&2/clamav/r",

   "pattern_lang": "ClamAV",

   "valid_from": "2016-01-01T00:00:00Z"

 },

 {

   "type": "relationship",

   "id": "relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad",

   "created": "2016-04-06T20:06:37Z",

   "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",

   "source_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

   "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",

   "kind_of_relationship": "indicates"

 },

 {

   "type": "malware",

   "id": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",

   "created": "2016-04-06T20:07:09Z",

   "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",

   "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.

 

 

Summary:

 

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. 

 

 

Patrick Maroney

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]