Yes, I agree. Any self assessment would need to be spelled out and be super easy for implementors and consumers to understand. This would include things like certain sections of Idioms and certain features / functions. For example I can see a whole class of vendor network and client products that will either emit a STIX object or consume a STIX object but not both and it would be good for consumers to understand that they are at Level X or Level Y.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Jun 26, 2015, at 10:13, Jerome Athias <> wrote:
I think that any kind of maturity/compliance assessment/declaration(should it be just self assessment) would have to be based on somekind of criterias or requirements.Those would have to be listed/defined in order to be measured forproviding relevant -to be defined- key indicators (such as list ofsupported functionnalities, or % of CybOX observables supported...).This was, I think, what was done for OVAL.2015-06-26 18:50 GMT+03:00 Jordan, Bret <>:Understanding what Idioms are supported or what elements of an Idiom aresupport is valuable, yes. But think of certification in regards to biggerlevel items.1) Does the systems support data making / handling? And if so, can youappropriately handle something that is like a TLP RED.2) Does the system actually support delete requests3) Does the system support full fidelity on a STIX package's producer chain?Or does it strip all of that away. Further if we add an ability to sign aSTIX package, does the system support that and the ability to re-issue thepackage with the cert or include it some how.4) On the TAXII side, does the system support Data Feeds or just Data Sets..5) Does the TAXII system support inbox services or just poll services?6) What is the sustained rate that a system supports in tiers.etc etc.What I would like to see is a simple and easy to understand tier system withcertification. We have talked about this a lot over the past year and Ithink a lot of really good ideas have been brought up... Imagine that thefirst few levels are self asserting. Then the final few levels, will havean official certification process similar to the WiFi alliance. Initially,for the first few years say 3-5 years, we would only do self assessment.Then in say the 5 year time frame we would do an official certificationprocess.Thanks,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303"Without cryptography vihv vivc ce xhrnrw, however, the only thing that cannot be unscrambled is an egg."On Jun 26, 2015, at 06:25, Mark Clancy <> wrote:The adoption chart is part of the need and the OVAL example is a good one.Another side of this is the STIX profile(https://stix.mitre.org/about/documents/STIX_Profiles_Overview_White_Paper_v0.1.pdf).This is important as different parts of the ecosystem have and needdifferent levels of ‘completeness’ in how they handled Cybox/STIX. So if Iam trying to consume STIX data for say a Snort based IDS system there are alot of Cybox objects (like Win Reg key), STIX object types (like sayCampaigns) that don’t make any sense for a Snort based sensor to consume orproduce. Where as we also have STIX implementations for devices/sensorslike say a SIEM that can/should handle mode Cybox/STIX object types, butdon’t do so at present. It is kind of hard to describe the differencebetween those two levels of implementation. I could have everythingimplemented for a Snort type IDS that the device is able to do and have thesame number of STIX/Cybox objects supports in same a SEIM tool which shouldbe able to handle a lot more of these the STIX profiles would be the same,but the maximum possible maturity of the implementations IMHO are quitedifferent.I would really like to see the concept of an implementation maturity modelworked into the ‘adoption’ notions here. We see quite a difference between“like” products in the same categories as to their level of implementation.Today you could say you support STIX if you support say IPv4 address Cyboxobjects and only STIX Observables. Technically that is STIX ‘support’ and ifthat is what is in your STIX profile you are legit. The reality is the STIXprofile is the way to ‘transact’ the objects supports vs. not when beingshared, but we need a simpler summary of this so when customers of theseproducts make choices informed of what “we support STIX/TAXII” actuallymeans. If consumers experience “STIX support” at this level ofmaturity/completeness and they expected much more it is going to reflectpoorly on our standards. So say supporting one Cybox object and one Stixobject is Level 1 maturity in a single direction , but supporting all Cyboxand STIX objects, bi-directionally, linked to each other is a much higherlevel.I suggest we add this to the outreach workstream as a way of keeping trackof what "adoption" really means.-MarkMark ClancyChief Executive OfficerSOLTRA | An FS-ISAC and DTCC Company+1.813.470.2400 office | +1.610.659.6671 US mobile | +44 7823 626 535 | soltra.comOne organization's incident becomes everyone's defense.________________________________From: <> on behalf ofJerome Athias <>Sent: Friday, June 26, 2015 2:00 AMTo: Joep GommersCc: Peter Allor; Rich Struse; : Re: [cti] CTI-Outreach Sub-Committee Nominations/DiscussionAdoption Program?e.g. https://oval.mitre.org/adoption/2015-06-26 8:46 GMT+03:00 Joep Gommers <>:Hi Peter,Let me put some context around my proposal for certification, whichperhaps means rewording.First, I am completely aligned with you on the “voluntary” part and on thefact that mandatory certification would severely hinder adoption. Yet, whatI think it hindering adoption more is – and perhaps this speaks to yourconcerns about STIX/TAXII too – that it is ensure for producers how theirintelligence value is retained when received by other consumers. In a worldwhere I send you a PDF, I know how you will consume the PDF. It ispredictable and the value I bring as an intelligence producer is surelyretained. Additionally, I as a producer am in full control.Now in STIX this isn’t necessarily the case. Since STIX is transport, itdoes not guarantee to any extent that the intelligence value is retained allthe way to its human consumer – not as that the intent. STIX 1.1.1compliancy usually means, for both CSIRT communities and vendors (and manyother communities I might add that this is relevant for), a partialimplementation of parts of the standard – that are processed by a machineand/or readable by a human in different ways.For TAXII, a similar challenge exists where there is no easy automated wayof determining for machines what the TAXII implementors supports. Think;authentication, authorization, different services (depending on discoveryservice on/off, hooked on/off), polling subscription models, etc.For me, certification and compliancy effort would be to ensure that it ispublicly known and easily measurable what implementors actually support fromthe standard and where value is retained and where it isn’t. For TAXII, thismeans simple tools that make transparant the pattern of functionalityimplemented by a CSIRT community, vendor, etc. so they can say “guys I’mlevel A TAXII” - which will mean I support features A, B and C. For STIXsimilarly, a certain level of certification might mean that anproducer/consumer implements the indicator/observable idioms, but does notretain much of the intelligence value of threat actor or exploit targetinformation. This is relevant for the public to know, for producers tounderstand and to make transparant as to drive the community towards theright priorities and compatibility efforts. Right now, the conversationalline of “STIX/TAXII compatible” has no value and requires significant effortto undercover what REALLY is implemented and what intelligence value isREALLY retained.So perhaps, certification is a bad word. Thoughts?Best regards,JoepFrom: Peter Allor <>Date: Wednesday, June 24, 2015 at 7:11 PMTo: Joep Gommers <>Cc: Rich Struse <>, ""<>Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/DiscussionJoep,I think I will push back a bit here, especially on your 'certification'and 'compliance' aspects.<rant>We need to be "voluntarily" adopting this 'standard'.While I can see Tony's comments about talking with EC bodies, the realadoption and use for CTI is in two communities, which by their nature areinternational.They are the CSIRT Community, specifically National CSIRTs but alsoCritical Infrastructure CSIRTs and Enterprise CSIRTs (I will not delve intothe Big, Medium, Small discussion). There is a whole lot going on in CSIRTServices Framework and Education Development where this can be included andis updating materials from CERT/CC-SEI that are now 20 years old.Then there is the 'vendor' community, which has not been really engagedhere. I know some will say they are part of that community, but then alsotout how they are international. So we need the large IT Vendors and weneed the broad IT Security Vendors as part of this process. That would befor all FOUR Sub-Committee's. Much of the indicators and expressions willneed their input and adoption to actually gain traction for many and toenable the CSIRT Community (yes, the vendors are part of that community aswell). Just to be clear, I am talking about Intel/McAfee, Symantec,Microsoft, IBM, Cisco/SourceFire, FireEye/Mandiant, and a slew of others.Pushing mandatory compliance and certification does not work globally(think Common Criteria / NIAP, I could go on on that alone) and in securityvenues globally it is a check box with little use. Now I know thatvendors are looking to be part of this, but the sentiment here in thediscussions does not reflect that. I say that from a vendor and incidentresponse community perspective.So lets focus on how we get their perspectives to be included, as I knowas vendors, we see that STIX/TAXII in their current incarnation do NOT workvery well and that exchanging threat data today is severely challenged.The goal for CTI is to make that easier and simple for users and that meanswe as designers need to have the implementers involved and participating,not corralled and shamed. If you take CVRF as an example, you can see thatvendors do want a system and are willing to put it into operations and such,but the customer and the vendor need to have value out of it, not justanother checkbox.</rant>Sincerely,PetePeter AllorSenior Security Strategist, Project Manager, DisclosuresProduct Management and StrategyIBM Security6303 Barfield Rd NEAtlanta, GA 30328-4233Mobile: +1-404-643-9638Fax: + Gommers ---06/24/2015 11:15:54 AM---Hi Patrick, Great point. I thinkpart would be an effort of mapping the landscape onFrom: Joep Gommers <>To: Patrick Maroney <>, Mark Clancy<>, Peter F Brown <>,"" <>, Rich Struse<>Cc: "" <>Date: 06/24/2015 11:15 AMSubject: Re: [cti] CTI-Outreach Sub-Committee Nominations/DiscussionSent by: <>________________________________Hi Patrick,Great point. I think part would be an effort of mapping the landscape onthe one side, ensuring the tooling required to enable people to becompatible (in addition to the standards and corresponding libraries) andpart certification to solidify and ensure compliancy. Especially thelatter option combined with hall of fame/shame (in a nice way :)) coulddrive some tangible KPIs.. ?Best regards,JoepOn 6/24/15, 4:29 PM, "Patrick Maroney" <> wrote:I would agree with the position that Engagement subsumes Outreach.One open question is where Interoperability (as a tangible deliverable)fits into our stratgegy.Patrick MaroneyOffice: (856)983-0001Cell: (609)[email protected]________________________________________From: <> on behalf ofMark Clancy <>Sent: Wednesday, June 24, 2015 10:17:23 AMTo: Peter F Brown; ; Rich StruseCc: : Re: [cti] CTI-Outreach Sub-Committee Nominations/DiscussionAll,I agree with need this SC and am happy to help. I have been doing a lotthis as part of my role as DTCC's CISO in addition to my Soltra role. Ihave been presenting/meeting in the US, Europe and Asia. I spend a lot oftime with legislators, policy makers, and global financial regulators oninformation sharing and why automation is a key part of capablity needs.By the same token most of the challenges in the global context are notpurely technical but national and regualtory impediments. Not to say thetechnical things we are doing in CTI commitee in Oasis isn't alsocritical as it certianly is, but that if we only address the technicalside of this problem we won't achieve the risk mitigation benefits we alldesire.So at some level what do we think "engagement" means vs. "outreach"?-MarkMark ClancyChief Executive OfficerSOLTRA | An FS-ISAC and DTCC Company+1.813.470.2400 office | +1.610.659.6671 US mobile | +44 7823 626 535UK | soltra.comOne organization's incident becomes everyone's defense.________________________________________From: <> on behalf ofPeter F Brown <>Sent: Tuesday, June 23, 2015 6:37 PMTo: ; Rich StruseCc: : RE: [cti] CTI-Outreach Sub-Committee Nominations/Discussion+1Also agree with comment in an earlier thread that this SC ought to haveengagement as a core focus rather than outreach - and that ought to bereflected in the name of any proposed SC.Regards,Peter-----Original Message-----From: [mailto:] OnBehalf Of Tony RutkowskiSent: 22 June, 2015 13:08To: Rich StruseCc: : Re: [cti] CTI-Outreach Sub-Committee Nominations/DiscussionHi Rich,There is a great symmetry occurring here on a global scale.The first day of the annual cybersecurity workshop was held thisafternoon here in Sophia Antipolis in France's approximation of SiliconValley in the hills of Valbonne, France. There are people here fromaround the world, but this afternoon was somewhat Euro centric with keyofficials describing what was essential to regional and nationalcybersecurity. Perhaps not by coincidence, cyber threat intelligencesharing was at the top of their lists - along with security assurance.The four people who were engaged at this session were:o Florent Frederix who heads the key Network Information Security(NIS) initiative of the the European Commission and has someresponsibilities at the Directorate level similar to Rich Struse's as theexecution arm of the EU cybersecurity strategy - the analog of the WhiteHouse's framework initiatives.o Chris Ensor who heads up cybersecurity work in the UK's CESGorganization - also similar to Rich's responsibilities.o Marc Henauer of Switzerland's MELANI organization that is similar theprincipal Swiss threat intelligence sharing body.o Edri an Belmonte, who plays the lead role in this area in ENISAAll of the presentations except Cris Ensor's are available at:http://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/SECURITYWS/S01_SETTINGTHESCENE/In the discussion session following the presentations, speaking at theETSI TC CYBER threat intelligence sharing rapporteur, I had theopportunity to explain the creation of the new TC CTI committee and howthe platforms being pursued in CTI were proven best-of-breed models andstructured information sharing specifications that provided an idealmatch to each of their objectives.It was quite amazing how each of the parties - even in Europe - wasrather independently pursuing similar objectives.We also discussed how the work of TC CYBER was to survey the globalcybersecurity ecosystem and make use of the most successful existingstandards and not pursue duplicative work. Everyone seemed in agreement,and going forward, there seems like an excellent basis for convergencewith the CTI work now getting underway.There will be further discussion at the workshop over the next two daysas well as definitive actions at the TC CYBER meeting on Thursday andFriday. It was a good beginning that was continued usefully over localprovence wine and hors d'oeuves this evening (and setting a usefulprecedent for future TC CTI physical gatherings).--tony---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates 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 "CTI Standards Adoption.docx" deleted by PeterAllor/Atlanta/IBM]---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates 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:
signature.asc
Description: Message signed with OpenPGP using GPGMail
