OASIS Cyber Threat Intelligence (CTI) TC

Back to discussions
Expand all | Collapse all

CTI TC Adoption and Interoperability SCs

  • 1.  CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 14:21
    All,   Building on Carol’s email from last week (attached), I wanted to restart the discussion relating to a couple of additional subcommittees within the CTI TC.  There has been a lot of great discussion around outreach/engagement/adoption and, to a lesser extent, interoperability.  I thought it might make sense to take a step back and look at all of these issues so that we might best allocate our scarce resources to the most pressing tasks at hand.  In addition, I want to make sure that we take full advantage of the services and resources that the professional staff of OASIS provides – one of the many benefits of having a full-time team in support of our activities.   On the outreach/engagement/adoption front, I believe the principal goal should be the empowerment of all TC members to be effective communicators of the work being done by the CTI TC without necessarily straying over the line into speaking on behalf of the CTI TC as a whole.  That can be accomplished in a number of ways including the development of whitepapers, briefing slides, “slick sheets” and other materials that, once approved by the CTI TC can be used by any organization that wants to convey the who, what, when, where and why of STIX/TAXII/CybOX.  Another valuable service of such a group would be to identify engagement opportunities such as conferences, other standards activities, workshops, etc. and bring these to the attention of the CTI TC to maximize the likelihood that our message is being conveyed wherever and whenever it is appropriate.  Finally, I could imagine that this group might identify real and/or perceived barriers to adoption (both technical and non-technical) and propose specific strategies to the TC to help overcome these barriers.  All of these activities would need to be coordinated with Carol and the OASIS marketing team to ensure consistency of message.  As Carol mentioned in her email, these activities could be accomplished in either a formal subcommittee of CTI TC members or a group that could include non-CTI TC members.   While adoption is critically important, it is moot unless we have an ecosystem of interoperable solutions.  This is a significant undertaking in its own right and should be separate and distinct from any adoption group or subcommittee in my opinion.  Carol gave us some great pointers to other TC’s within OASIS and I encourage everyone to peruse those.  I think that there is strong consensus in the community that a robust mechanism to determine, report and promote interoperability is urgently needed.  As such, an interoperability subcommittee might focus on defining what interoperability means for both data – STIX and CybOX and protocols – TAXII, both at the technical and at the process level.  The subcommittee would need to work closely with the STIX, TAXII and CybOX subcommittees to ensure that each of those efforts is delivering specifications that support and advance interoperability.  Additional activities that an interoperability subcommittee might take on in support of this include the creation of interoperability testing plans, the creation of test data sets, the use of STIX profiles to aid interoperability, the organizing of interop events and the definition of standardized approaches to documenting interoperability claims.  One big question I have is would the interoperability subcommittee actually verify claims of interoperability or would it simply provide the benchmarks that other organizations could employ to conduct such interoperability tests?    This TC has a lot of new members that undoubtedly have experiences both within and outside OASIS that would be valuable to add to the discussion – please pipe up!   I’m looking forward to hearing everyone’s thoughts on these important topics.   Regards, Rich     Richard J. Struse   Chief Advanced Technology Officer National Cybersecurity and Communications Integration Center (NCCIC) and Stakeholder Engagement and Cyber Infrastructure Resiliency (SECIR) Cyber Security & Communications U.S. Department of Homeland Security e-mail:  Richard.Struse@dhs.gov Phone:  202-527-2361   ---  Begin Message  --- From : "Carol Geyer" <carol.geyer@oasis-open.org> To : <cti@lists.oasis-open.org> Date : Tue, 30 Jun 2015 14:30:20 -0400 As you discuss the possible creation of a CTI Outreach Subcommittee, let me offer a few insights into your options and what other TCs have done along these lines. First, note that members of a SC must also be members of the main TC. If your SC is focused on interoperability, compliance, and adoption issues, then it's safe to assume the SC members will be technical and engaged in the TC. If the SC also wants to be involved in promoting adoption (via creating educational materials, planning events, coordinating conference presentations, etc.), then you may need to involve people with marketing responsibilities (and budgets); those people would not likely find value in being part of the main TC. Other TCs have addressed outreach in a variety of ways: The KMIP TC has an Interoperability SC that focuses on testing and verification activities including Interop demos and plugfests. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip-interop The DITA TC has a separate Adoption TC that produces white papers, webinars, instructional videos, and a community web site. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita-adoption The CMIS TC has an associated Marketing Group (not a SC) that engages in communications and marketing activities to promote adoption. The Marketing Group brings together people who have direct responsibility for their organization's outreach activities including press and/or analyst relations, social media engagement, conference and expo participation, branding, training, etc. I work closely with this group, under the OASIS Media Relations Guidelines, as does Jane Harnad, the OASIS Events Manager. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis-marketing Looking over the CTI Outreach thread, it seems you may be trying to accomplish too many things in one group. Your goals might be better served by a SC for Interoperability/Compliance and a separate marketing group that focuses on promotion, education, events, etc. The two groups could work closely with one another, with the main TC, and with OASIS support staff. Work produced (slide decks, white papers, etc.) could be submitted to the main TC for approval before publication. My recommendation: draft bullets for the activities you intend to tackle in "Outreach" and what type of expertise is needed for each. A review of that list may clarify how and who should accomplish what. I'm happy to help. -Carol -- Carol Geyer Senior Director, OASIS www.oasis-open.org +1.941.284.0403 ---  End Message  --- Attachment: smime.p7s Description: S/MIME cryptographic signature


  • 2.  Re: CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 18:01
    All, (in response to Rich's post below) I agree with everything Rich is stating here and also support Carol's suggestions on separate Outreach & Interoperability SCs. Regarding outreach and general engagement we need most, if not all, TC members acting as individual evangelists to continue driving standards adoption vs. empowering one or a small group of individuals to act as spokespersons. Rich had very solid specific suggestions on this SC. In that same regard to interoperability, to answer Rich's question, I'd suggest that an "Interoperability" SC develop a step-by-step benchmark verification approach that could be performed by any TC member. That approach would not overly burden any particular SC member(s) nor put any particular member(s) in an entitled position. It would require a certainly level of open accountability, but I believe it could just as easily be managed. In reference to my last post and the work we currently perform to validate standards implementation, I have more specific ideas on how a benchmark approach could be done, but will save until after the SCs are formed (unless the group is interested in hearing them now). Dave From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Struse, Richard <Richard.Struse@HQ.DHS.GOV> Sent: Monday, July 6, 2015 7:20 AM To: cti@lists.oasis-open.org Subject: [cti] CTI TC Adoption and Interoperability SCs   All,   Building on Carol’s email from last week (attached), I wanted to restart the discussion relating to a couple of additional subcommittees within the CTI TC.  There has been a lot of great discussion around outreach/engagement/adoption and, to a lesser extent, interoperability.  I thought it might make sense to take a step back and look at all of these issues so that we might best allocate our scarce resources to the most pressing tasks at hand.  In addition, I want to make sure that we take full advantage of the services and resources that the professional staff of OASIS provides – one of the many benefits of having a full-time team in support of our activities.   On the outreach/engagement/adoption front, I believe the principal goal should be the empowerment of all TC members to be effective communicators of the work being done by the CTI TC without necessarily straying over the line into speaking on behalf of the CTI TC as a whole.  That can be accomplished in a number of ways including the development of whitepapers, briefing slides, “slick sheets” and other materials that, once approved by the CTI TC can be used by any organization that wants to convey the who, what, when, where and why of STIX/TAXII/CybOX.  Another valuable service of such a group would be to identify engagement opportunities such as conferences, other standards activities, workshops, etc. and bring these to the attention of the CTI TC to maximize the likelihood that our message is being conveyed wherever and whenever it is appropriate.  Finally, I could imagine that this group might identify real and/or perceived barriers to adoption (both technical and non-technical) and propose specific strategies to the TC to help overcome these barriers.  All of these activities would need to be coordinated with Carol and the OASIS marketing team to ensure consistency of message.  As Carol mentioned in her email, these activities could be accomplished in either a formal subcommittee of CTI TC members or a group that could include non-CTI TC members.   While adoption is critically important, it is moot unless we have an ecosystem of interoperable solutions.  This is a significant undertaking in its own right and should be separate and distinct from any adoption group or subcommittee in my opinion.  Carol gave us some great pointers to other TC’s within OASIS and I encourage everyone to peruse those.  I think that there is strong consensus in the community that a robust mechanism to determine, report and promote interoperability is urgently needed.  As such, an interoperability subcommittee might focus on defining what interoperability means for both data – STIX and CybOX and protocols – TAXII, both at the technical and at the process level.  The subcommittee would need to work closely with the STIX, TAXII and CybOX subcommittees to ensure that each of those efforts is delivering specifications that support and advance interoperability.  Additional activities that an interoperability subcommittee might take on in support of this include the creation of interoperability testing plans, the creation of test data sets, the use of STIX profiles to aid interoperability, the organizing of interop events and the definition of standardized approaches to documenting interoperability claims.  One big question I have is would the interoperability subcommittee actually verify claims of interoperability or would it simply provide the benchmarks that other organizations could employ to conduct such interoperability tests?    This TC has a lot of new members that undoubtedly have experiences both within and outside OASIS that would be valuable to add to the discussion – please pipe up!   I’m looking forward to hearing everyone’s thoughts on these important topics.   Regards, Rich     Richard J. Struse   Chief Advanced Technology Officer National Cybersecurity and Communications Integration Center (NCCIC) and Stakeholder Engagement and Cyber Infrastructure Resiliency (SECIR) Cyber Security & Communications U.S. Department of Homeland Security e-mail:  Richard.Struse@dhs.gov Phone:  202-527-2361  


  • 3.  Re: CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 18:32
    It would be useful if CTI maintained the equivalent of the MILE Implementation Report ID just announced below. Additionally, in a world of dramatic scaling of cloud data center virtualization, especially NFV, instantiating a CTI dedicated focus on the subject is important. --tony --------------- https://tools.ietf.org/html/draft-ietf-mile-implementreport-05 MILE C. Inacio Internet-Draft CMU Intended status: Informational D. Miyamoto Expires: January 6, 2016 UTokyo July 5, 2015 MILE Implementation Report draft-ietf-mile-implementreport-05 Abstract This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups.


  • 4.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 19:18
    When I was Chair of the SPEECHSC IETF Work Group (speech server control), we setup a self-reported interoperability matrix: http://standardstrack.com/ietf/speechsc/MRCPv2-Plans.html Same for LEMONADE (mobile messaging): http://standardstrack.com/ietf/lemonade/Lemonade-Plans.html The idea is OASIS will *not* become the protocol police. That is too expensive and carries unlimited liability. What a self-reporting resource does do is (1) advertise who is running with the standards and (2) who has tested against whom. That is not a guarantee of interoperability, but it is lightyears ahead of publishing and praying. > On Jul 6, 2015, at 2:31 PM, Tony Rutkowski <tony@yaanatech.com> wrote: > > It would be useful if CTI maintained the equivalent of > the MILE Implementation Report ID just announced below. > > Additionally, in a world of dramatic scaling of cloud data > center virtualization, especially NFV, instantiating a CTI > dedicated focus on the subject is important. > > --tony > > --------------- > > https://tools.ietf.org/html/draft-ietf-mile-implementreport-05 > > MILE C. Inacio > Internet-Draft CMU > Intended status: Informational D. Miyamoto > Expires: January 6, 2016 UTokyo > July 5, 2015 > > > MILE Implementation Report > draft-ietf-mile-implementreport-05 > > > Abstract > > This document is a collection of implementation reports from vendors, > consortiums, and researchers who have implemented one or more of the > standards published from the IETF INCident Handling (INCH) and > Management Incident Lightweight Exchange (MILE) working groups. > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > Attachment: smime.p7s Description: S/MIME cryptographic signature


  • 5.  RE: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 19:39
    Makes sense. If we (the CTI TC) focus on defining what interoperability means for STIX/TAXII/CybOX and how to measure/verify it, that leaves the door open for third-party organizations such as testing labs to conduct interoperability tests using the CTI TC-defined benchmarks.
    Original Message


  • 6.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 19:48
    Believe it or not, I would shy away from any measurements short of what we say someone needs to do to meet a profile, which is the profile definition itself. Likewise, I would shy away from test or verification suites. The industry’s experience with standards with elaborate verification suites has been the protocols fail because it takes ages to build the verification suites, they are obsolete when published, which ossifies the underlying specification. In a decade after everyone is using STIX and TAXII, we can think about formal acceptance suites. If the specifications are so obfuscated we need specifications to specify what the specifications specify, we have failed. > On Jul 6, 2015, at 3:39 PM, Struse, Richard <Richard.Struse@hq.dhs.gov> wrote: > > Makes sense. > > If we (the CTI TC) focus on defining what interoperability means for > STIX/TAXII/CybOX and how to measure/verify it, that leaves the door open for > third-party organizations such as testing labs to conduct interoperability > tests using the CTI TC-defined benchmarks. > >
    Original Message


  • 7.  RE: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 20:10
    I think we are actually in agreement. I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable. Definitely a question that the SC would need to tackle.
    Original Message


  • 8.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 20:50
    Yes, and I would love to see a SC setup to address this.  We need people that can focus on this and drive it to completion, if it stays at the TC level, it will get lost just like before.   I am not a fan of massive unit tests, for all the reasons Eric points out, and I do not think we need a formal testing body like the WiFi Alliance (maybe in 10 years).  But I would like to know things like:  Say for TAXII 1) Support Inbox Services? 2) Support Query? 3) Support Delete Requests? 4) Support Push Services? 5) Support Data Feeds? 6) Support Data Collections? 7) Support Subscriptions? 8) Support Authentication and if so what kinds? etc etc For STIX 1) It would be things like how much of each Idiom do they support?   2) Do they support data handling / data marking? 3) Do they support source integrity?  4) Support profiles? etc etc In my mind, the SC would come up with a list of things that people would do to self certify their implementations / products.  They would also come up with a way to track / publish who is doing what.  Kind of like what Interworks has done on their meta-server about taxii servers. 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 Jul 6, 2015, at 14:09, Struse, Richard < Richard.Struse@HQ.DHS.GOV > wrote: I think we are actually in agreement.  I'm not advocating heavyweight suites of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 9.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 20:51
    Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Struse, Richard <Richard.Struse@HQ.DHS.GOV> Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement. I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable. Definitely a question that the SC would need to tackle.
    Original Message


  • 10.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-06-2015 20:56
    The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, how much of STIX / TAXII do I need to implement to do XYZ? 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more qualitative aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight suites of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 11.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-07-2015 23:27
    I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 12.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-08-2015 12:36
    Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 13.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-08-2015 14:05
    I understand what you are saying, but that is way too complex...  Think about this from a Product Manager standpoint, not an academic stand point, further the whole point of doing this is for product managers and consumers.   Product Managers are going to ask how much of this do I need to implement to be compliant and do what my customers are asking for .  Customers want some level of assurance that a vendor has actually implemented some level of support so they can make buying decisions and interoperability decisions.  Just like Common Criteria, vendors will start using their level of support as a stick to say they are better than some other vendor, which is good for us.  This means, that more and more vendors will support more and more of STIX. <soapbox> Yes I know we are also talking about CyboX and that CybOX can stand on its own and can be used by other things.  However, in the real world when we get across the chasm and gain of mass adoption, people will not care, and it will referred to as just STIX.  Because from the outside, assuming you did not know anything about it or its development, you would ask yourself WHY is it called two different things when it is just the same thing.   </soapbox> We need a very simple set of line in the sand markers of support.  When you look at the list of products that claim they support STIX, right now we have NO idea what that means.  Nor does any consumer or user have any idea what that means.  Linksys for example, could add the ability in their interface for their home router to see the configuration of the admin page in STIX XML and they could then claim, legally, on all of their documentation that they are STIX compliant.   Building a simple set of line in the sand markers will also drive adoption, especially if the first level is relatively easy to get to. This will be something that a product manager can safely commit to his/her board of directors.   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 Jul 8, 2015, at 06:35, Kirillov, Ivan A. < ikirillov@mitre.org > wrote: Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, how much of STIX / TAXII do I need to implement to do XYZ? 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more qualitative aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight suites of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 14.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-08-2015 14:16
    +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading. sean From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 15.  RE: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-08-2015 14:53
    I think there’s a middle ground here.   I agree completely with what Bret is saying: I think vendors will want a single dimension (or small set of dimensions) to compete on, because this is all most markets can handle (yes, I expect this statement to be contentious). If, in order to compete on STIX/TAXII functionality, the market needs to understand a complex matrix (nominally, product category x use case x capability level), general customers will not be able to evaluate their options (largely due to time constraints) and the market will instead compete on some other easier to understand dimension (ease of use) or something along the lines of brand recognition and golf outings (ugh).   I also think Ivan and Sean are completely right: The way STIX/CybOX are today, there is not only a single competitive dimension that makes sense – there are many dimensions. You have to break it up to make sense of it, and once you’ve broken it out you can begin to think about maturity levels. I will note that I see this as a natural outcome of the cyber security tool space: There are precious few product categories that vendor products neatly fall into, and many of these products do not compete on the same dimensions.   What I think we need to do, and what I think is the middle ground, is that as we move forward and mature we need to work toward clear, linear dimensions for vendors to compete on and for customers to evaluate. (This is far easier said than done.) I think Ivan’s listing could be a starting point for identifying what those dimensions are. This will be a huge challenge, as it will require pushing the needle in terms of better defining product categories. For instance, if we invented a “host based indicator sharing” dimension to compete on, that’s only valuable if the market knows what product category(ies) should be competing on that dimension.   Thank you. -Mark     From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Barnum, Sean D. Sent: Wednesday, July 08, 2015 10:16 AM To: Kirillov, Ivan A.; Terry MacDonald; Jordan, Bret Cc: David Eilken; Richard Struse; Eric Burger; cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading.   sean   From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).    Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g.,   ·          Indicator Characterization/Sharing o     Host-based Indicator Sharing §   STIX §   Level 1: Basic Context §   Level 2: Level 1 + Supports Sightings §   CybOX §   Level 1: Supports File Object §   File_Path field §   Hashes field §   Level 2: Level 1 + Supports Windows Registry Key Object o     Network Indicator Sharing ·          TTP/Malware Characterization Sharing o     Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: ·          Level 1: minimal support – very basic, incomplete support ·          Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) ·          Level 3: full support – fully supports the use case, in all facets   Regards, Ivan   From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   I agree. I like the way this is headed.    I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently.   Cheers Terry MacDonald STIX, TAXII, CybOX Consultant   M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com     Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.   On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.     I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?"   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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote:   Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 16.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-08-2015 16:46
    I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus] as a method to help manage complexity, interoperability, different world views, use cases, etc.,  We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles. Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase: (1)  The CTI language should be precise both in terms of how one expresses any  given "thing"  and similarly precise in how one interprets "things" expressed in this manner.   (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways. I have always agreed with these objectives.   However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).   Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains will be established.  So from these perspectives there is never any intent to forge "One Ring to Rule Them All".  Understand there are also  those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately seeking similar unification  ;-). Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing, (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:  You only describe what you need and nothing more. Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration : Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove the Training Wheels. I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability, maturity levels, impediments, to adoption, etc. Patrick Maroney Office:  (856)983-0001 Cell::     (609)841-5104 Email:   pmaroney@specere.org From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, July 8, 2015 at 10:15 AM To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading. sean From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 17.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-08-2015 17:14
    +1  Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, July 8, 2015 at 12:45 PM To: "Barnum, Sean D." < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus] as a method to help manage complexity, interoperability, different world views, use cases, etc.,  We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles. Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase: (1)  The CTI language should be precise both in terms of how one expresses any  given "thing"  and similarly precise in how one interprets "things" expressed in this manner.   (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways. I have always agreed with these objectives.   However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).   Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains will be established.  So from these perspectives there is never any intent to forge "One Ring to Rule Them All".  Understand there are also  those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately seeking similar unification  ;-). Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing, (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:  You only describe what you need and nothing more. Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration : Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove the Training Wheels. I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability, maturity levels, impediments, to adoption, etc. Patrick Maroney Office:  (856)983-0001 Cell::     (609)841-5104 Email:   pmaroney@specere.org From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, July 8, 2015 at 10:15 AM To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading. sean From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 18.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-08-2015 17:46
    I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product more attractive to customers. We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build. So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the CTI suite a product needs to have to meaningfully address the use case. On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: +1  Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, July 8, 2015 at 12:45 PM To: Barnum, Sean D. < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Struse, Richard < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus] as a method to help manage complexity, interoperability, different world views, use cases, etc.,  We've had almost identical conversations when defining the two initial Standard STIX Profiles (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community driven Standard STIX Profiles and then use these and iterate over them to revise or create new Community Standard STIX Profiles. Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase: (1)  The CTI language should be precise both in terms of how one expresses any  given thing  and similarly precise in how one interprets things expressed in this manner.   (2) The language should (must?) limit the ability to represent a given thing in multiple ways. I have always agreed with these objectives.   However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).   Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains will be established.  So from these perspectives there is never any intent to forge One Ring to Rule Them All .  Understand there are also  those quite legitimately seeking a unified STIX package (a lthough I might quip that Einstein was quite legitimately seeking similar unification  ;-). Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing, (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:  You only describe what you need and nothing more. Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration : Before sending our Little CTI out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove the Training Wheels. I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability, maturity levels, impediments, to adoption, etc. Patrick Maroney Office:  (856)983-0001 Cell::     (609)841-5104 Email:   pmaroney@specere.org From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, July 8, 2015 at 10:15 AM To: Kirillov, Ivan A. < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading. sean From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Struse, Richard < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, how much of STIX / TAXII do I need to implement to do XYZ? 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more qualitative aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight suites of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 19.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 00:27
    Yes, well stated Pat. I especially like the notion of describing what you need and nothing more. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 9 July 2015 at 03:45, Eric Burger < Eric.Burger@georgetown.edu > wrote: I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product more attractive to customers. We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build. So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the CTI suite a product needs to have to meaningfully address the use case. On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: +1  Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, July 8, 2015 at 12:45 PM To: "Barnum, Sean D." < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus] as a method to help manage complexity, interoperability, different world views, use cases, etc.,  We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles. Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase: (1)  The CTI language should be precise both in terms of how one expresses any  given "thing"  and similarly precise in how one interprets "things" expressed in this manner.   (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways. I have always agreed with these objectives.   However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).   Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains will be established.  So from these perspectives there is never any intent to forge "One Ring to Rule Them All".  Understand there are also  those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately seeking similar unification  ;-). Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing, (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:  You only describe what you need and nothing more. Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration : Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove the Training Wheels. I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability, maturity levels, impediments, to adoption, etc. Patrick Maroney Office:  (856)983-0001 Cell::     (609)841-5104 Email:   pmaroney@specere.org From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, July 8, 2015 at 10:15 AM To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading. sean From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 20.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 06:25
    I'll just leave this [0] here. It's apropos, a good read, and _short_. [0]:  https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 Cheers, Trey -- Trey Darley Senior Security Engineer Soltra An FS-ISAC & DTCC Company www.soltra.com From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@threatloop.com> Sent: Thursday, July 9, 2015 02:26 To: Eric Burger Cc: cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   Yes, well stated Pat. I especially like the notion of describing what you need and nothing more. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 9 July 2015 at 03:45, Eric Burger < Eric.Burger@georgetown.edu > wrote: I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product more attractive to customers. We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build. So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the CTI suite a product needs to have to meaningfully address the use case. On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: +1  Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, July 8, 2015 at 12:45 PM To: "Barnum, Sean D." < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus] as a method to help manage complexity, interoperability, different world views, use cases, etc.,  We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles. Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase: (1)  The CTI language should be precise both in terms of how one expresses any  given "thing"  and similarly precise in how one interprets "things" expressed in this manner.   (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways. I have always agreed with these objectives.   However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).   Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains will be established.  So from these perspectives there is never any intent to forge "One Ring to Rule Them All".  Understand there are also  those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately seeking similar unification  ;-). Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing, (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:  You only describe what you need and nothing more. Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration : Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove the Training Wheels. I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability, maturity levels, impediments, to adoption, etc. Patrick Maroney Office:  (856)983-0001 Cell::     (609)841-5104 Email:   pmaroney@specere.org From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, July 8, 2015 at 10:15 AM To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading. sean From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 21.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 07:45
    That was the era of the NREN Internet. Nonetheless the far more interesting read is RFC 1122, especially the full sec 1.2.2 assumptions. On Jul 9, 2015 7:24 AM, Trey Darley <trey@soltra.com> wrote:






    I'll just leave this [0] here. It's apropos, a good read, and _short_.


    [0]:  https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00





    Cheers,
    Trey
    --
    Trey Darley

    Senior Security Engineer
    Soltra An FS-ISAC & DTCC Company
    www.soltra.com








    From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@threatloop.com>
    Sent: Thursday, July 9, 2015 02:26
    To: Eric Burger
    Cc: cti@lists.oasis-open.org
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
     


    Yes, well stated Pat. I especially like the notion of describing what you need and nothing more.








    Cheers

    Terry MacDonald STIX, TAXII, CybOX Consultant



    M: +61-407-203-026
    E:  terry.macdonald@threatloop.com
    W:  www.threatloop.com






    Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those
    of my employers.








    On 9 July 2015 at 03:45, Eric Burger < Eric.Burger@georgetown.edu > wrote:

    I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter
    how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product
    more attractive to customers.


    We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build.


    So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the
    CTI suite a product needs to have to meaningfully address the use case.





    On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote:



    +1  Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues.


    sean




    From: Patrick Maroney < Pmaroney@Specere.org >
    Date: Wednesday, July 8, 2015 at 12:45 PM
    To: "Barnum, Sean D." < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >,
    "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs






    I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus]
    as a method to help manage complexity, interoperability, different world views, use cases, etc., 


    We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community
    driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles.


    Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase:



    (1)  The CTI language should be precise both in terms of how one expresses any  given "thing"  and similarly precise in how one interprets "things" expressed in this manner. 


     (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways.




    I have always agreed with these objectives.  


    However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish
    and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).  


    Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains
    will be established.  So from these perspectives there is never any intent to forge "One Ring to Rule Them All".  Understand there are also  those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately
    seeking similar unification  ;-).


    Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate
    what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing,
    (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:
     You only describe what you need and nothing more.




    Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration :



    Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove
    the Training Wheels.





    I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability,
    maturity levels, impediments, to adoption, etc.


    Patrick Maroney
    Office:  (856)983-0001
    Cell::     (609)841-5104
    Email:  
    pmaroney@specere.org






    From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
    Date: Wednesday, July 8, 2015 at 10:15 AM
    To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >,
    "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    +!
    I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading.


    sean




    From: <Kirillov>, Steve Cell < ikirillov@mitre.org >
    Date: Wednesday, July 8, 2015 at 8:35 AM
    To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold
    with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object?
    Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File). 


    Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or
    CybOX as appropriate ). I could envision this as a taxonomy, e.g.,


    Indicator Characterization/Sharing
    Host-based Indicator Sharing
    STIX
    Level 1: Basic Context Level 2: Level 1 + Supports Sightings
    CybOX
    Level 1: Supports File Object
    File_Path field Hashes field
    Level 2: Level 1 + Supports Windows Registry Key Object

    Network Indicator Sharing
    TTP/Malware Characterization Sharing
    Basic TTP/Malware Characterization

    Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting
    the number of levels to 3 to keep things sane:
    Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets


    Regards,
    Ivan




    From: Terry MacDonald < terry.macdonald@threatloop.com >
    Date: Tuesday, July 7, 2015 at 7:26 PM
    To: Bret Jordan < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    I agree. I like the way this is headed. 


    I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible
    with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support
    all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently.










    Cheers

    Terry MacDonald STIX, TAXII, CybOX Consultant



    M: +61-407-203-026
    E:  terry.macdonald@threatloop.com
    W:  www.threatloop.com






    Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those
    of my employers.








    On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote:

    The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.  


    I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?"










    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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote:

    Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing.


    More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example)
    as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to.

    Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables)
    Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc.
    Level 3: In addition to level 2, adds support for Sightings
    Level 4: In addition to level 3, adds all STIX and CybOx object types.
    Level 5: In addition to level 4, adds support for STIX object updates and Revocation


    Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity.



    Dave


    ________________________________________
    From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV >
    Sent: Monday, July 6, 2015 1:09 PM
    To: Eric Burger; cti@lists.oasis-open.org
    Subject: RE: [cti] CTI TC Adoption and Interoperability SCs

    I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would
    need to tackle.


    Original Message


  • 22.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 08:05
    Um, Tony, did you take the time to read the RFC draft I posted? It's dated March 9, 2015. I realize that things do move quickly but I would hardly qualify that as an artifact from a bygone era. On the contrary, I would say that it deprecates RFC1122, § 1.2.2. Cheers, Trey -- Trey Darley Senior Security Engineer Soltra An FS-ISAC & DTCC Company www.soltra.com From: Tony Rutkowski <tony@yaanatech.com> Sent: Thursday, July 9, 2015 09:44 To: Trey Darley Cc: cti@lists.oasis-open.org; Terry MacDonald; Eric Burger Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   That was the era of the NREN Internet. Nonetheless the far more interesting read is RFC 1122, especially the full sec 1.2.2 assumptions. On Jul 9, 2015 7:24 AM, Trey Darley <trey@soltra.com> wrote: I'll just leave this [0] here. It's apropos, a good read, and _short_. [0]:  https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 Cheers, Trey -- Trey Darley Senior Security Engineer Soltra An FS-ISAC & DTCC Company www.soltra.com From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@threatloop.com> Sent: Thursday, July 9, 2015 02:26 To: Eric Burger Cc: cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   Yes, well stated Pat. I especially like the notion of describing what you need and nothing more. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 9 July 2015 at 03:45, Eric Burger < Eric.Burger@georgetown.edu > wrote: I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product more attractive to customers. We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build. So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the CTI suite a product needs to have to meaningfully address the use case. On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: +1  Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, July 8, 2015 at 12:45 PM To: "Barnum, Sean D." < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus] as a method to help manage complexity, interoperability, different world views, use cases, etc.,  We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles. Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase: (1)  The CTI language should be precise both in terms of how one expresses any  given "thing"  and similarly precise in how one interprets "things" expressed in this manner.   (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways. I have always agreed with these objectives.   However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).   Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains will be established.  So from these perspectives there is never any intent to forge "One Ring to Rule Them All".  Understand there are also  those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately seeking similar unification  ;-). Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing, (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:  You only describe what you need and nothing more. Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration : Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove the Training Wheels. I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability, maturity levels, impediments, to adoption, etc. Patrick Maroney Office:  (856)983-0001 Cell::     (609)841-5104 Email:   pmaroney@specere.org From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, July 8, 2015 at 10:15 AM To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading. sean From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).  Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.  I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E:  terry.macdonald@threatloop.com W:  www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.   I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would need to tackle.
    Original Message


  • 23.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 08:35
    Hi Trey, I'm not sure this dialogue is relevant to this list. Something is getting lost in translation here. It seems unfair to be excising a quote from a 1989 RFC about much of anything concerning the DARPA Internet when the design purpose was to support the NREN, not large-scale public infrastructure - which was being attempted over in the OSI Internet venues. I have otherwise no quibble with Thompson's contemporary draft. With that said, Jon's observations in Sec. 1.2.2 apart from the quote -about assuming all code is flawed - is rather interesting if not prescient, e.g., In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, The statement could well be a CTI mantra. -tony On 2015-07-09 09:05 AM, Trey Darley wrote: Um, Tony, did you take the time to read the RFC draft I posted? It's dated March 9, 2015. I realize that things do move quickly but I would hardly qualify that as an artifact from a bygone era. On the contrary, I would say that it deprecates RFC1122, § 1.2.2.


  • 24.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 16:13
    Tony - What I initially posted was entirely relevant to this list. I agree with you that our ensuing dialogue has not been. All - tl;dr: Both from an interoperability perspective and a security perspective, complexity is the enemy. In days of old when knights were bold and ARPANET was a thing, Postel's principal of being conservative in what you send and liberal in what you accept made sense. That is no longer the case. Longer discussion, for those who care... The point vis-a-vis interoperability and security is that as the complexity of a specification increases (whether that be in the form of an on-disk data format or a network protocol) the likelihood of two independent implementations parsing each other's output correctly approaches zero. It is easy to generate STIX and CybOX that are schema-valid. It is orders of magnitude more difficult to verifiably _parse_ any random bit of schema-valid input thrown at you and actually do something with it. As the standards evolve, no doubt there will be lots of voices clamoring to add things but we would be wise to also make strategic cuts so as to push the standards towards a (for lack of a better term) Pythonic notion of there being one intuitively correct way of expressing a thing. From the security angle, when you have multiple independent implementations interpreting the same data in overlapping but not identical ways, this is called a parsing differential and introduces an entire metaclass of vulnerabilities. XML is no more a silver bullet for secure coding than Java was. For more information, I refer you to the Language-Theoretic Security group [0]. Dan Geer's keynote address [1] from the 2015 IEEE Security & Privacy Symposium is an excellent starting point. 'Beyond Planted Bugs in “Trusting Trust" - The Input-Processing Frontier' [2] from the January 2014 edition of IEEE Security & Privacy is another good one. [0]: http://langsec.org/ [1]: http://spw15.langsec.org/geer.langsec.21v15.txt [2]: http://langsec.org/papers/beyond-bugs-input-frontier.pdf Cheers, Trey -- Trey Darley Senior Security Engineer Soltra An FS-ISAC & DTCC Company www.soltra.com ________________________________________ From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Tony Rutkowski <tony@yaanatech.com> Sent: Thursday, July 9, 2015 10:34 To: Trey Darley Cc: cti@lists.oasis-open.org; Terry MacDonald; Eric Burger Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Hi Trey, I'm not sure this dialogue is relevant to this list. Something is getting lost in translation here. It seems unfair to be excising a quote from a 1989 RFC about much of anything concerning the DARPA Internet when the design purpose was to support the NREN, not large-scale public infrastructure - which was being attempted over in the OSI Internet venues. I have otherwise no quibble with Thompson's contemporary draft. With that said, Jon's observations in Sec. 1.2.2 apart from the quote -about assuming all code is flawed - is rather interesting if not prescient, e.g., In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, The statement could well be a CTI mantra. -tony On 2015-07-09 09:05 AM, Trey Darley wrote: > > Um, Tony, did you take the time to read the RFC draft I posted? It's > dated March 9, 2015. I realize that things do move quickly but I would > hardly qualify that as an artifact from a bygone era. On the contrary, > I would say that it deprecates RFC1122, § 1.2.2. > > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


  • 25.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 16:38




    Maybe the context that would be helpful to add is what does the thing implementing TAXIISTIXCybox actually do?
    Does it consume specific   data, does it publish specific data, or does it aggregate/link all data ?
     
    The STIX profile attempted to address this with kind of saying. “Hey this is what I actually support”. If I am a CTI producer focusing on one thing like say DDoS attacks that
    narrow subset of Stix and Cybox objects defined in the profile may well be the maximum content I would every produce anyway so having a maturity of "X" is the max that I could ever be and similarly if I was a defensive tool that re-directed access to evil
    web sites support cybox object with Windows Registry keys are fairly irrelevant.  On the other hand if I am sharing hub/aggregation portal or a SIEM those same levels of support in the STIX profile are way below what a customer of that platform would expect.
     Those should not get treated in the same way on a maturity curve. 
     
    The downside of a "maturity scale" is that it can be viewed as penalizing specialty services/tools that don't need every widget to have maximum effectiveness for what they
    do where as you kind of want to point out that another platform is less mature as it left a lot of capability on the table with their implementation and therefore have sub-optimal effectiveness given what it could be doing to feel that pressure.
     
    So what the heck should we do?
     
    We need to put life into the STIX profiles.
    We need to figure out a way to differentiate STIX profiles where the maximum needed to do the purpose has been achieved and where things are left on the table.

     
     For the buyer of a solution this is the critical difference and if we can’t express that difference some how that in my experience tend to lay blame (in the mind of
    the buyer) with the standards not the implementation by their suppliers.
     

    -Mark





    Mark Clancy
    Chief Executive Officer
    SOLTRA

    An FS-ISAC and DTCC Company
    +1.813.470.2400
    office

    +1.610.659.6671  US  mobile

    ?    +44 7823 626 535   UK  mobile
    mclancy@soltra.com
    soltra.com
     
    One organization's incident becomes everyone's defense.
     
    ?







    From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@threatloop.com>
    Sent: Wednesday, July 8, 2015 8:26 PM
    To: Eric Burger
    Cc: cti@lists.oasis-open.org
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
     


    Yes, well stated Pat. I especially like the notion of describing what you need and nothing more.








    Cheers

    Terry MacDonald STIX, TAXII, CybOX Consultant



    M: +61-407-203-026
    E:  terry.macdonald@threatloop.com
    W:  www.threatloop.com






    Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those
    of my employers.








    On 9 July 2015 at 03:45, Eric Burger < Eric.Burger@georgetown.edu > wrote:

    I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter
    how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product
    more attractive to customers.


    We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build.


    So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the
    CTI suite a product needs to have to meaningfully address the use case.





    On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote:



    +1  Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues.


    sean




    From: Patrick Maroney < Pmaroney@Specere.org >
    Date: Wednesday, July 8, 2015 at 12:45 PM
    To: "Barnum, Sean D." < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >,
    "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs






    I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus]
    as a method to help manage complexity, interoperability, different world views, use cases, etc., 


    We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community
    driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles.


    Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase:



    (1)  The CTI language should be precise both in terms of how one expresses any  given "thing"  and similarly precise in how one interprets "things" expressed in this manner. 


     (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways.




    I have always agreed with these objectives.  


    However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish
    and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).  


    Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains
    will be established.  So from these perspectives there is never any intent to forge "One Ring to Rule Them All".  Understand there are also  those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately
    seeking similar unification  ;-).


    Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate
    what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing,
    (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:
     You only describe what you need and nothing more.




    Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration :



    Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove
    the Training Wheels.





    I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability,
    maturity levels, impediments, to adoption, etc.


    Patrick Maroney
    Office:  (856)983-0001
    Cell::     (609)841-5104
    Email:  
    pmaroney@specere.org






    From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
    Date: Wednesday, July 8, 2015 at 10:15 AM
    To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >,
    "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    +!
    I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading.


    sean




    From: <Kirillov>, Steve Cell < ikirillov@mitre.org >
    Date: Wednesday, July 8, 2015 at 8:35 AM
    To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold
    with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object?
    Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File). 


    Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or
    CybOX as appropriate ). I could envision this as a taxonomy, e.g.,



    Indicator Characterization/Sharing

    Host-based Indicator Sharing

    STIX

    Level 1: Basic Context Level 2: Level 1 + Supports Sightings
    CybOX

    Level 1: Supports File Object

    File_Path field Hashes field
    Level 2: Level 1 + Supports Windows Registry Key Object

    Network Indicator Sharing
    TTP/Malware Characterization Sharing

    Basic TTP/Malware Characterization

    Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting
    the number of levels to 3 to keep things sane:

    Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets


    Regards,
    Ivan




    From: Terry MacDonald < terry.macdonald@threatloop.com >
    Date: Tuesday, July 7, 2015 at 7:26 PM
    To: Bret Jordan < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    I agree. I like the way this is headed. 


    I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible
    with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support
    all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently.










    Cheers

    Terry MacDonald STIX, TAXII, CybOX Consultant



    M: +61-407-203-026
    E:  terry.macdonald@threatloop.com
    W:  www.threatloop.com






    Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those
    of my employers.








    On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote:

    The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.  


    I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?"










    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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote:

    Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing.


    More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example)
    as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to.

    Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables)
    Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc.
    Level 3: In addition to level 2, adds support for Sightings
    Level 4: In addition to level 3, adds all STIX and CybOx object types.
    Level 5: In addition to level 4, adds support for STIX object updates and Revocation


    Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity.



    Dave


    ________________________________________
    From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV >
    Sent: Monday, July 6, 2015 1:09 PM
    To: Eric Burger; cti@lists.oasis-open.org
    Subject: RE: [cti] CTI TC Adoption and Interoperability SCs

    I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would
    need to tackle.


    Original Message


  • 26.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 16:54




    It might make sense for the CTI to develop STIX profiles that are aligned with specific use cases and say, for a hypothetical DDoS mitigation tool to claim STIX support, "Must be this tall to ride."





    Cheers,
    Trey
    --
    Trey Darley

    Senior Security Engineer
    Soltra An FS-ISAC & DTCC Company
    www.soltra.com








    From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Mark Clancy <mclancy@soltra.com>
    Sent: Thursday, July 9, 2015 18:38
    To: Terry MacDonald; Eric Burger
    Cc: cti@lists.oasis-open.org
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
     



    Maybe the context that would be helpful to add is what does the thing implementing TAXIISTIXCybox actually do?
    Does it consume specific   data, does it publish specific data, or does it aggregate/link all data ?
     
    The STIX profile attempted to address this with kind of saying. “Hey this is what I actually support”. If I am a CTI producer focusing on one thing like say DDoS attacks that narrow
    subset of Stix and Cybox objects defined in the profile may well be the maximum content I would every produce anyway so having a maturity of "X" is the max that I could ever be and similarly if I was a defensive tool that re-directed access to evil web sites
    support cybox object with Windows Registry keys are fairly irrelevant.  On the other hand if I am sharing hub/aggregation portal or a SIEM those same levels of support in the STIX profile are way below what a customer of that platform would expect.  Those
    should not get treated in the same way on a maturity curve. 
     
    The downside of a "maturity scale" is that it can be viewed as penalizing specialty services/tools that don't need every widget to have maximum effectiveness for what they do where
    as you kind of want to point out that another platform is less mature as it left a lot of capability on the table with their implementation and therefore have sub-optimal effectiveness given what it could be doing to feel that pressure.
     
    So what the heck should we do?
     
    We need to put life into the STIX profiles.
    We need to figure out a way to differentiate STIX profiles where the maximum needed to do the purpose has been achieved and where things are left on the table.

     
     For the buyer of a solution this is the critical difference and if we can’t express that difference some how that in my experience tend to lay blame (in the mind of the
    buyer) with the standards not the implementation by their suppliers.
     

    -Mark





    Mark Clancy
    Chief Executive Officer
    SOLTRA

    An FS-ISAC and DTCC Company
    +1.813.470.2400
    office

    +1.610.659.6671  US  mobile

    ?    +44 7823 626 535   UK  mobile
    mclancy@soltra.com
    soltra.com
     
    One organization's incident becomes everyone's defense.
     
    ?







    From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@threatloop.com>
    Sent: Wednesday, July 8, 2015 8:26 PM
    To: Eric Burger
    Cc: cti@lists.oasis-open.org
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
     


    Yes, well stated Pat. I especially like the notion of describing what you need and nothing more.








    Cheers

    Terry MacDonald STIX, TAXII, CybOX Consultant



    M: +61-407-203-026
    E:  terry.macdonald@threatloop.com
    W:  www.threatloop.com






    Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those
    of my employers.








    On 9 July 2015 at 03:45, Eric Burger < Eric.Burger@georgetown.edu > wrote:

    I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter
    how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product
    more attractive to customers.


    We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build.


    So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the
    CTI suite a product needs to have to meaningfully address the use case.





    On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote:



    +1  Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues.


    sean




    From: Patrick Maroney < Pmaroney@Specere.org >
    Date: Wednesday, July 8, 2015 at 12:45 PM
    To: "Barnum, Sean D." < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >,
    "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs






    I may be missing something here and have been hesitating throwing in my usual advocacy for   STIX Profiles [Plus]
    as a method to help manage complexity, interoperability, different world views, use cases, etc., 


    We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex.  The objective of this exercise was to establish consensus for two initial Community
    driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles.


    Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase:



    (1)  The CTI language should be precise both in terms of how one expresses any  given "thing"  and similarly precise in how one interprets "things" expressed in this manner. 


     (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways.




    I have always agreed with these objectives.  


    However, I still see extended STIX Profiles (Human and Machine  readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish
    and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).  


    Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains.  Many variations of these CTIX Communities/Operational Domains
    will be established.  So from these perspectives there is never any intent to forge "One Ring to Rule Them All".  Understand there are also  those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately
    seeking similar unification  ;-).


    Also note that I've argued for the addition of a very explicit form of STIX Profile:   I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand.  this proposed form of STIX Profile can be extremely simple and only needs to enumerate
    what I can (1) Convey and (2) Consume.   This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing,
    (4) Reject Entire Package, (5) Hold and Contact Source.  However, Key take-away here is:
     You only describe what you need and nothing more.




    Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration :



    Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels.  As she explores, try's new things,  makes mistakes, learns,  and continue to expand her horizons, we can eventually remove
    the Training Wheels.





    I was planning to wait for the CTI TC re-organization dust to settle  before re-engaging the community in discourse on extending STIX Profiles.  However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability,
    maturity levels, impediments, to adoption, etc.


    Patrick Maroney
    Office:  (856)983-0001
    Cell::     (609)841-5104
    Email:  
    pmaroney@specere.org






    From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
    Date: Wednesday, July 8, 2015 at 10:15 AM
    To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >,
    "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    +!
    I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading.


    sean




    From: <Kirillov>, Steve Cell < ikirillov@mitre.org >
    Date: Wednesday, July 8, 2015 at 8:35 AM
    To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold
    with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object?
    Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File). 


    Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or
    CybOX as appropriate ). I could envision this as a taxonomy, e.g.,



    Indicator Characterization/Sharing

    Host-based Indicator Sharing

    STIX

    Level 1: Basic Context Level 2: Level 1 + Supports Sightings
    CybOX

    Level 1: Supports File Object

    File_Path field Hashes field
    Level 2: Level 1 + Supports Windows Registry Key Object

    Network Indicator Sharing
    TTP/Malware Characterization Sharing

    Basic TTP/Malware Characterization

    Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting
    the number of levels to 3 to keep things sane:

    Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets


    Regards,
    Ivan




    From: Terry MacDonald < terry.macdonald@threatloop.com >
    Date: Tuesday, July 7, 2015 at 7:26 PM
    To: Bret Jordan < bret.jordan@bluecoat.com >
    Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CTI TC Adoption and Interoperability SCs





    I agree. I like the way this is headed. 


    I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible
    with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support
    all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently.










    Cheers

    Terry MacDonald STIX, TAXII, CybOX Consultant



    M: +61-407-203-026
    E:  terry.macdonald@threatloop.com
    W:  www.threatloop.com






    Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those
    of my employers.








    On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote:

    The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.  


    I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?"










    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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote:

    Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing.


    More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example)
    as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to.

    Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables)
    Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc.
    Level 3: In addition to level 2, adds support for Sightings
    Level 4: In addition to level 3, adds all STIX and CybOx object types.
    Level 5: In addition to level 4, adds support for STIX object updates and Revocation


    Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity.



    Dave


    ________________________________________
    From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV >
    Sent: Monday, July 6, 2015 1:09 PM
    To: Eric Burger; cti@lists.oasis-open.org
    Subject: RE: [cti] CTI TC Adoption and Interoperability SCs

    I think we are actually in agreement.  I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable.  Definitely a question that the SC would
    need to tackle.


    Original Message


  • 27.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 16:56
    I feel like the profile conversation does not get well served by trying to use it to discuss it as a "maturity scale" - they are not really the same thing. CybOX*, STIX and TAXII are very robust protocols that have *a lot* of optional information, and not all of that information is relevant to all consumers or producers of STIX. Just because a product only supports a given profile does not mean that product is not mature... the information in other profiles may not be in any way relevant to that product class, and the product class will likely never support any more as a result. This is why profiles are so important, because in order for products to inter-operate using these protocols, people using them need to "know what to expect" when they connect the products. * As well, trying to call out the importance of CybOX in the profile conversation, simply because I don't see it mentioned much in these emails... the CybOX objects supported is a critical component of any profile in my opinion. I foresee a lot of consumer products not being able to support the full set of all possible CybOX objects and their operators. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Mark Clancy ---2015/07/09 01:38:42 PM---Maybe the context that would be helpful to add is what does the thing implementing TAXIISTIXCybox From: Mark Clancy <mclancy@soltra.com> To: Terry MacDonald <terry.macdonald@threatloop.com>, Eric Burger <Eric.Burger@georgetown.edu> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date: 2015/07/09 01:38 PM Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Sent by: <cti@lists.oasis-open.org> Maybe the context that would be helpful to add is what does the thing implementing TAXIISTIXCybox actually do? Does it consume specific data, does it publish specific data, or does it aggregate/link all data ? The STIX profile attempted to address this with kind of saying. “Hey this is what I actually support”. If I am a CTI producer focusing on one thing like say DDoS attacks that narrow subset of Stix and Cybox objects defined in the profile may well be the maximum content I would every produce anyway so having a maturity of "X" is the max that I could ever be and similarly if I was a defensive tool that re-directed access to evil web sites support cybox object with Windows Registry keys are fairly irrelevant. On the other hand if I am sharing hub/aggregation portal or a SIEM those same levels of support in the STIX profile are way below what a customer of that platform would expect. Those should not get treated in the same way on a maturity curve. The downside of a "maturity scale" is that it can be viewed as penalizing specialty services/tools that don't need every widget to have maximum effectiveness for what they do where as you kind of want to point out that another platform is less mature as it left a lot of capability on the table with their implementation and therefore have sub-optimal effectiveness given what it could be doing to feel that pressure. So what the heck should we do? We need to put life into the STIX profiles. We need to figure out a way to differentiate STIX profiles where the maximum needed to do the purpose has been achieved and where things are left on the table. For the buyer of a solution this is the critical difference and if we can’t express that difference some how that in my experience tend to lay blame (in the mind of the buyer) with the standards not the implementation by their suppliers. -Mark Mark Clancy Chief Executive Officer SOLTRA An FS-ISAC and DTCC Company +1.813.470.2400 office +1.610.659.6671 US mobile ? +44 7823 626 535 UK mobile mclancy@soltra.com soltra.com One organization's incident becomes everyone's defense. ? From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@threatloop.com> Sent: Wednesday, July 8, 2015 8:26 PM To: Eric Burger Cc: cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Yes, well stated Pat. I especially like the notion of describing what you need and nothing more. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E: terry.macdonald@threatloop.com W: www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 9 July 2015 at 03:45, Eric Burger < Eric.Burger@georgetown.edu > wrote: I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product more attractive to customers. We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build. So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the CTI suite a product needs to have to meaningfully address the use case. On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: +1 Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, July 8, 2015 at 12:45 PM To: "Barnum, Sean D." < sbarnum@mitre.org >, Steve Cell < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I may be missing something here and have been hesitating throwing in my usual advocacy for STIX Profiles [Plus] as a method to help manage complexity, interoperability, different world views, use cases, etc., We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex. The objective of this exercise was to establish consensus for two initial Community driven "Standard" STIX Profiles and then use these and iterate over them to revise or create new Community "Standard" STIX Profiles. Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase: (1) The CTI language should be precise both in terms of how one expresses any given "thing" and similarly precise in how one interprets "things" expressed in this manner. (2) The language should (must?) limit the ability to represent a given "thing" in multiple ways. I have always agreed with these objectives. However, I still see extended STIX Profiles (Human and Machine readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA). Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains. Many variations of these CTIX Communities/Operational Domains will be established. So from these perspectives there is never any intent to forge "One Ring to Rule Them All". Understand there are also those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately seeking similar unification ;-). Also note that I've argued for the addition of a very explicit form of STIX Profile: I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand. this proposed form of STIX Profile can be extremely simple and only needs to enumerate what I can (1) Convey and (2) Consume. This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing, (4) Reject Entire Package, (5) Hold and Contact Source. However, Key take-away here is: You only describe what you need and nothing more. Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration : Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels. As she explores, try's new things, makes mistakes, learns, and continue to expand her horizons, we can eventually remove the Training Wheels. I was planning to wait for the CTI TC re-organization dust to settle before re-engaging the community in discourse on extending STIX Profiles. However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability, maturity levels, impediments, to adoption, etc. Patrick Maroney Office: (856)983-0001 Cell:: (609)841-5104 Email: pmaroney@specere.org From: < cti@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, July 8, 2015 at 10:15 AM To: "Kirillov, Ivan A." < ikirillov@mitre.org >, Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs +! I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading. sean From: <Kirillov>, Steve Cell < ikirillov@mitre.org > Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald < terry.macdonald@threatloop.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, "Struse, Richard" < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object? Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File). Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or CybOX as appropriate ). I could envision this as a taxonomy, e.g., Indicator Characterization/Sharing Host-based Indicator Sharing STIX Level 1: Basic Context Level 2: Level 1 + Supports Sightings CybOX Level 1: Supports File Object File_Path field Hashes field Level 2: Level 1 + Supports Windows Registry Key Object Network Indicator Sharing TTP/Malware Characterization Sharing Basic TTP/Malware Characterization Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane: Level 1: minimal support – very basic, incomplete support Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case) Level 3: full support – fully supports the use case, in all facets Regards, Ivan From: Terry MacDonald < terry.macdonald@threatloop.com > Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: David Eilken < deilken@fsisac.us >, Richard Struse < Richard.Struse@HQ.DHS.GOV >, Eric Burger < Eric.Burger@georgetown.edu >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed. I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E: terry.macdonald@threatloop.com W: www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 7 July 2015 at 06:55, Jordan, Bret < bret.jordan@bluecoat.com > wrote: The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for. I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?" 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 Jul 6, 2015, at 14:50, David Eilken < deilken@fsisac.us > wrote: Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing. More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example) as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to. Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables) Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc. Level 3: In addition to level 2, adds support for Sightings Level 4: In addition to level 3, adds all STIX and CybOx object types. Level 5: In addition to level 4, adds support for STIX object updates and Revocation Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity. Dave ________________________________________ From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Struse, Richard < Richard.Struse@HQ.DHS.GOV > Sent: Monday, July 6, 2015 1:09 PM To: Eric Burger; cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs I think we are actually in agreement. I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable. Definitely a question that the SC would need to tackle.
    Original Message


  • 28.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 15:51
    Richard: After reading through the various threads/conversations that this question stimulated...it appears that there is general consensus forming around the idea of two additional Sub-Committees: 1) Engagement/Outreach/Adoption, (EOA) and 2) Interoperability/Implementation (II). Carol had suggested a possible 3rd 'Marketing' Sub-Committee...but that idea did not seem to resonate with this group, so I'd like to suggest that we include that function within an EOA Sub-Committee, working closely with OASIS staff. We also received some excellent considerations on how the database design considerations should be folded into the overall Sub-Committee structure. Sean's argument for subsuming this topic within the existing Charter Sub-Committee structure appears to have gained acceptance with the provisos that Cory & Eric brought up regarding the need to handle these considerations at a level of abstraction that would facilitate multiple implementations and not lock anyone into a single notion of what might work. The issue of how the CybOX & STIX Sub-Committees can sort this out should probably be handled by the respective Co-chairs of those Sub-Committees...and managed using the non-Standards track documentation method of OASIS. There was an initial flurry of posts regarding potential Co-Chairs for the Engagement/Outreach/ Adoption Sub-Committee... but none that I can recall regarding an Interoperability Sub-Committee (although there was for a DB Sub-Committee). As I recall, some of the candidates for an Engagement/Outreach/ Adoption SC were: Joep Gommers, Patrick MacDonald, Tony Rutkowski, and David Eilken. Considering this...and previous discussions on a DB Sub-Committee that morphed into an Interoperability/Implementation Sub-Committee... I'd like to ask Jerome Athias and David Eilken if either one, or both, of you would be willing and ready to act as Co-Chairs for a Interoperability/Implementation Sub-Committee... should we decide to form one. Further, I'd like to inquire of Joep, Tony, and Patrick if you all are still willing and able to serve as Co-Chairs of an Engagement/Outreach /Adoption Sub-Committee? (Did I leave anyone out?) Finally, here is a question for Chet and/or Carol.... Would it be unheard-of for a Sub-Committee to have 3 Co-Chairman.... especially one that will be using more of a non-Standards documentation track? I'm thinking here about the size of this CTI-TC, the importance of the topic, and the workload for the proposed individuals. Jane Ginn, MSIA, MRP Cyber Threat Intelligence Network, Inc. jg@ctin.us
    Original Message


  • 29.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 16:13
    Hi Jane,  Regarding " Finally, here is a question for Chet and/or Carol.... Would it be unheard-of for a Sub-Committee to have 3 Co-Chairman.... especially one that will be using more of a non-Standards documentation track? I'm thinking here about the size of this CTI-TC, the importance of the topic, and the workload for the proposed individuals." The OASIS rules allow for only 2 co-chairs so we can't support having 3. However, as with the TC at large, the SCs can elect Secretaries. The Secretaries are listed along with the Chairs on the home page and can support the same tasks as chairs. So that would be the way to go - 2 co-chairs and one or more secretaries.  Great summary by the way. You kept far better track of it all than I did!  /chet On Thu, Jul 9, 2015 at 11:51 AM, Jane Ginn - jg@ctin.us < jg@ctin.us > wrote: Richard: After reading through the various threads/conversations that this question stimulated...it appears that there is general consensus forming around the idea of two additional Sub-Committees: 1) Engagement/Outreach/Adoption, (EOA) and 2) Interoperability/Implementation (II). Carol had suggested a possible 3rd 'Marketing' Sub-Committee...but that idea did not seem to resonate with this group, so I'd like to suggest that we include that function within an EOA Sub-Committee, working closely with OASIS staff. We also received some excellent considerations on how the database design considerations should be folded into the overall Sub-Committee structure. Sean's argument for subsuming this topic within the existing Charter Sub-Committee structure appears to have gained acceptance with the provisos that Cory & Eric brought up regarding the need to handle these considerations at a level of abstraction that would facilitate multiple implementations and not lock anyone into a single notion of what might work. The issue of how the CybOX & STIX Sub-Committees can sort this out should probably be handled by the respective Co-chairs of those Sub-Committees...and managed using the non-Standards track documentation method of OASIS. There was an initial flurry of posts regarding potential Co-Chairs for the Engagement/Outreach/ Adoption Sub-Committee... but none that I can recall regarding an Interoperability Sub-Committee (although there was for a DB Sub-Committee). As I recall, some of the candidates for an Engagement/Outreach/ Adoption SC were: Joep Gommers, Patrick MacDonald, Tony Rutkowski, and David Eilken. Considering this...and previous discussions on a DB Sub-Committee that morphed into an Interoperability/Implementation Sub-Committee... I'd like to ask Jerome Athias and David Eilken if either one, or both, of you would be willing and ready to act as Co-Chairs for a Interoperability/Implementation Sub-Committee... should we decide to form one. Further, I'd like to inquire of Joep, Tony, and Patrick if you all are still willing and able to serve as Co-Chairs of an Engagement/Outreach /Adoption Sub-Committee? (Did I leave anyone out?) Finally, here is a question for Chet and/or Carol.... Would it be unheard-of for a Sub-Committee to have 3 Co-Chairman.... especially one that will be using more of a non-Standards documentation track? I'm thinking here about the size of this CTI-TC, the importance of the topic, and the workload for the proposed individuals. Jane Ginn, MSIA, MRP Cyber Threat Intelligence Network, Inc. jg@ctin.us
    Original Message


  • 30.  Re: [cti] CTI TC Adoption and Interoperability SCs

    Posted 07-09-2015 17:22
    Although Mr. MacSonald proposed, we have not set a date yet.  So for now, you may refer to me by my "maiden" name, and yes I'm still interested in serving as co-chair for the EOA SC    [+1] on the title/acronym. Also please note that I am [+~] on completion/evolution of the models and derivation of all other representation forms from same.  There may be an argument for splitting out a forward looking CTI Ontology related initiative into a separate CTI TC WG or CTI TC SC.   However, [+1] that current efforts to define/align the conceptual models for the initial baseline OASIS Committee Specifications need to remain closely aligned with the respective SCs. Patrick Maroney Office: (856)983-0001 Cell: (609)841-5104 pmaroney@specere.org From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jane Ginn - jg@ctin.us <jg@ctin.us> Sent: Thursday, July 9, 2015 11:51:03 AM To: Richard.Struse@HQ.DHS.GOV; cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   Richard: After reading through the various threads/conversations that this question stimulated...it appears that there is general consensus forming around the idea of two additional Sub-Committees: 1) Engagement/Outreach/Adoption, (EOA) and 2) Interoperability/Implementation (II). Carol had suggested a possible 3rd 'Marketing' Sub-Committee...but that idea did not seem to resonate with this group, so I'd like to suggest that we include that function within an EOA Sub-Committee, working closely with OASIS staff. We also received some excellent considerations on how the database design considerations should be folded into the overall Sub-Committee structure. Sean's argument for subsuming this topic within the existing Charter Sub-Committee structure appears to have gained acceptance with the provisos that Cory & Eric brought up regarding the need to handle these considerations at a level of abstraction that would facilitate multiple implementations and not lock anyone into a single notion of what might work. The issue of how the CybOX & STIX Sub-Committees can sort this out should probably be handled by the respective Co-chairs of those Sub-Committees...and managed using the non-Standards track documentation method of OASIS. There was an initial flurry of posts regarding potential Co-Chairs for the Engagement/Outreach/ Adoption Sub-Committee... but none that I can recall regarding an Interoperability Sub-Committee (although there was for a DB Sub-Committee). As I recall, some of the candidates for an Engagement/Outreach/ Adoption SC were: Joep Gommers, Patrick MacDonald, Tony Rutkowski, and David Eilken. Considering this...and previous discussions on a DB Sub-Committee that morphed into an Interoperability/Implementation Sub-Committee... I'd like to ask Jerome Athias and David Eilken if either one, or both, of you would be willing and ready to act as Co-Chairs for a Interoperability/Implementation Sub-Committee... should we decide to form one. Further, I'd like to inquire of Joep, Tony, and Patrick if you all are still willing and able to serve as Co-Chairs of an Engagement/Outreach /Adoption Sub-Committee? (Did I leave anyone out?) Finally, here is a question for Chet and/or Carol.... Would it be unheard-of for a Sub-Committee to have 3 Co-Chairman.... especially one that will be using more of a non-Standards documentation track? I'm thinking here about the size of this CTI-TC, the importance of the topic, and the workload for the proposed individuals. Jane Ginn, MSIA, MRP Cyber Threat Intelligence Network, Inc. jg@ctin.us
    Original Message


  • 31.  Re: [cti] CTI TC Adoption and Interoperability SCs - PROPOSAL

    Posted 07-11-2015 00:08
    In response to Jane's note to Rich, I would like to focus my efforts toward an Interoperability/ Implementation SC vs. Outreach/ Engagement. I'm not sure if Jane's list made an official proposal, but just to make sure we're moving forward, may I suggest a basic premise below and we get it rolling? The Interoperability SC will help guide adherence to CTI standards and interoperability between CTI standards-based implementations, while encouraging standards maturity throughout the industry. The SC will develop parameters and processes to allow CTI TC members to test/ validate, and where possible measure the maturity of another organization’s implementation. Testing parameters and processes should be straight-forward and objective to provide clear confirmation that minimum standards' requirements have been achieved. Initially, in regard to maturity measurement efforts, the SC will develop guidelines to support a more qualitative review of an implementation. I assume there is enough interest/ backing that we can formalize the group, setup regular meetings, and provide a more refined mission as required afterwards. Regards, Dave Soltra/ FS-ISAC From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Patrick Maroney <Pmaroney@Specere.org> Sent: Thursday, July 9, 2015 10:21 AM To: Jane Ginn - jg@ctin.us; Richard.Struse@HQ.DHS.GOV; cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   Although Mr. MacSonald proposed, we have not set a date yet.  So for now, you may refer to me by my "maiden" name, and yes I'm still interested in serving as co-chair for the EOA SC    [+1] on the title/acronym. Also please note that I am [+~] on completion/evolution of the models and derivation of all other representation forms from same.  There may be an argument for splitting out a forward looking CTI Ontology related initiative into a separate CTI TC WG or CTI TC SC.   However, [+1] that current efforts to define/align the conceptual models for the initial baseline OASIS Committee Specifications need to remain closely aligned with the respective SCs. Patrick Maroney Office: (856)983-0001 Cell: (609)841-5104 pmaroney@specere.org From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jane Ginn - jg@ctin.us <jg@ctin.us> Sent: Thursday, July 9, 2015 11:51:03 AM To: Richard.Struse@HQ.DHS.GOV; cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs   Richard: After reading through the various threads/conversations that this question stimulated...it appears that there is general consensus forming around the idea of two additional Sub-Committees: 1) Engagement/Outreach/Adoption, (EOA) and 2) Interoperability/Implementation (II). Carol had suggested a possible 3rd 'Marketing' Sub-Committee...but that idea did not seem to resonate with this group, so I'd like to suggest that we include that function within an EOA Sub-Committee, working closely with OASIS staff. We also received some excellent considerations on how the database design considerations should be folded into the overall Sub-Committee structure. Sean's argument for subsuming this topic within the existing Charter Sub-Committee structure appears to have gained acceptance with the provisos that Cory & Eric brought up regarding the need to handle these considerations at a level of abstraction that would facilitate multiple implementations and not lock anyone into a single notion of what might work. The issue of how the CybOX & STIX Sub-Committees can sort this out should probably be handled by the respective Co-chairs of those Sub-Committees...and managed using the non-Standards track documentation method of OASIS. There was an initial flurry of posts regarding potential Co-Chairs for the Engagement/Outreach/ Adoption Sub-Committee... but none that I can recall regarding an Interoperability Sub-Committee (although there was for a DB Sub-Committee). As I recall, some of the candidates for an Engagement/Outreach/ Adoption SC were: Joep Gommers, Patrick MacDonald, Tony Rutkowski, and David Eilken. Considering this...and previous discussions on a DB Sub-Committee that morphed into an Interoperability/Implementation Sub-Committee... I'd like to ask Jerome Athias and David Eilken if either one, or both, of you would be willing and ready to act as Co-Chairs for a Interoperability/Implementation Sub-Committee... should we decide to form one. Further, I'd like to inquire of Joep, Tony, and Patrick if you all are still willing and able to serve as Co-Chairs of an Engagement/Outreach /Adoption Sub-Committee? (Did I leave anyone out?) Finally, here is a question for Chet and/or Carol.... Would it be unheard-of for a Sub-Committee to have 3 Co-Chairman.... especially one that will be using more of a non-Standards documentation track? I'm thinking here about the size of this CTI-TC, the importance of the topic, and the workload for the proposed individuals. Jane Ginn, MSIA, MRP Cyber Threat Intelligence Network, Inc. jg@ctin.us
    Original Message


Related Content