CTI STIX Subcommittee

 View Only

Re: [cti-stix] TTP proposal

  • 1.  Re: [cti-stix] TTP proposal

    Posted 05-13-2016 21:09




    Agreed with Bret. I thought we proposed that on the previous call for such a TLO.
     
    I also agree with Kyle that we should focus on the core need for the use cases we have in mind and not keep any baggage from the past if its not required.
     
    Gary was going to take a stab at proposing something that we can review soon hopefully that might help in this regard.
     
    allan
     

    From:
    "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
    Date: Friday, May 13, 2016 at 2:01 PM
    To: "Maxwell, Kyle" <kmaxwell@verisign.com>
    Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: Re: [cti-stix] TTP proposal


     



    So we have a TLO called "Action" or "Attack" or "Foo" or "TP" or "Something".  And this TLO contains the "knowledge" gained by an analyst about the collection of tools, infrastructure, and processes that a Threat Actor may use against a
    Victim or in a Campaign???? 








     


    Thanks,


     


    Bret



     


     


     



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









     



    On May 13, 2016, at 14:18, Maxwell, Kyle < kmaxwell@verisign.com > wrote:

     

    I've written here before about TTPs, but other calls and conversations this week have helped crystallize some specific thoughts. Clearly, we've gotten stuck a bit on this because of different interpretations
    of the term, but this is causing problems. As Bret has noted, this general topic has become the "long pole in the tent" making it difficult for development of other TLOs to move ahead.

    Motivation

    Let's forget about STIX 1.2 "TTP" for a moment and instead just think about what we want to capture. When a Threat Actor carries out some sort of attack,   we want to be able to describe what they're actually doing   (phishing,
    DDoS, etc.) at some level of detail (spear phishing, UDP flood, etc.) They might use various tools and infrastructure as part of their attack, but they can change the tool (recompile to get a different hash) or the infrastructure (switch IP addresses) without
    changing their actual methodology.

    Now, we can get very granular in how we describe that, but I submit that that's not something we can capture in anything like a controlled vocabulary right now. We do, however, have a number of existing vocabularies that describe those types of attacks at an
    intermediate level of granularity -   CAPEC   is
    a good one, but I don't think we need to require it per se.   VERIS actions   are
    another.

    Proposal

    Shelve "TTP" as a TLO for now.   That term currently seems to create misunderstandings based
    on different interpretations, and in my experience as an analyst that is not restricted to our TC by any means. We can consider at a later date the possibility of creating this TLO at a fine-grained level (e.g. fields for Tactics, Techniques, and Procedures).  

    Instead,   create a TLO called "Action"   or "Attack" or similar.  "Action" TLOs MUST contain   either a "description" or an
    "attack pattern" . They may be linked to an Actor, an observable of some sort (CybOX container?), a Campaign, etc., as defaults. The fields mentioned above are as follows:





    description   - string - A free-text field
    that contains a concise description of the specific attack carried out by a Threat Actor.
    attack pattern   - tuple (reference-std,
    reference-id) - A 2-tuple of strings that references a specific standard ("CAPEC", "ATT&CK", or "VERIS") and the ID within that standard that describes the attack (e.g. "CAPEC-488: HTTP Flood"). Implementers MAY choose their own standard to reference here
    if not one of the three defaults.
    This likely covers the needs for MVP, though it clearly will require future iteration, and allows the development of other TLOs to proceed apace without missing key functionality required
    to adequately describe an attack. By allowing existing standards / vocabularies, we enable STIX consumers to take some automated action or map to their own internal standards, and this deconflicts with other potential but important TLOs such as target organizations,
    malware, and other indicators.

    --
    Kyle Maxwell [ kmaxwell@verisign.com ]
    iDefense Senior Analyst