[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion
I think that any kind of maturity/compliance assessment/declaration (should it be just self assessment) would have to be based on some kind of criterias or requirements. Those would have to be listed/defined in order to be measured for providing relevant -to be defined- key indicators (such as list of supported 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 <bret.jordan@bluecoat.com>: > Understanding what Idioms are supported or what elements of an Idiom are > support is valuable, yes. But think of certification in regards to bigger > level items. > > 1) Does the systems support data making / handling? And if so, can you > appropriately handle something that is like a TLP RED. > > 2) Does the system actually support delete requests > > 3) 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 a > STIX package, does the system support that and the ability to re-issue the > package 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 with > certification. We have talked about this a lot over the past year and I > think a lot of really good ideas have been brought up... Imagine that the > first few levels are self asserting. Then the final few levels, will have > an 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 certification > process. > > 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 06:25, Mark Clancy <mclancy@soltra.com> 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 need > different levels of ‘completeness’ in how they handled Cybox/STIX. So if I > am trying to consume STIX data for say a Snort based IDS system there are a > lot of Cybox objects (like Win Reg key), STIX object types (like say > Campaigns) that don’t make any sense for a Snort based sensor to consume or > produce. Where as we also have STIX implementations for devices/sensors > like say a SIEM that can/should handle mode Cybox/STIX object types, but > don’t do so at present. It is kind of hard to describe the difference > between those two levels of implementation. I could have everything > implemented for a Snort type IDS that the device is able to do and have the > same number of STIX/Cybox objects supports in same a SEIM tool which should > be 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 quite > different. > > > I would really like to see the concept of an implementation maturity model > worked 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 Cybox > objects and only STIX Observables. Technically that is STIX ‘support’ and if > that is what is in your STIX profile you are legit. The reality is the STIX > profile is the way to ‘transact’ the objects supports vs. not when being > shared, but we need a simpler summary of this so when customers of these > products make choices informed of what “we support STIX/TAXII” actually > means. If consumers experience “STIX support” at this level of > maturity/completeness and they expected much more it is going to reflect > poorly on our standards. So say supporting one Cybox object and one Stix > object is Level 1 maturity in a single direction , but supporting all Cybox > and STIX objects, bi-directionally, linked to each other is a much higher > level. > > I suggest we add this to the outreach workstream as a way of keeping track > of what "adoption" really means. > > -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 > Jerome Athias <athiasjerome@gmail.com> > Sent: Friday, June 26, 2015 2:00 AM > To: Joep Gommers > Cc: Peter Allor; Rich Struse; cti@lists.oasis-open.org > Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion > > Adoption Program? > e.g. https://oval.mitre.org/adoption/ > > > 2015-06-26 8:46 GMT+03:00 Joep Gommers <joep@intelworks.com>: >> >> Hi Peter, >> >> Let me put some context around my proposal for certification, which >> perhaps means rewording. >> >> First, I am completely aligned with you on the “voluntary” part and on the >> fact that mandatory certification would severely hinder adoption. Yet, what >> I think it hindering adoption more is – and perhaps this speaks to your >> concerns about STIX/TAXII too – that it is ensure for producers how their >> intelligence value is retained when received by other consumers. In a world >> where I send you a PDF, I know how you will consume the PDF. It is >> predictable and the value I bring as an intelligence producer is surely >> retained. Additionally, I as a producer am in full control. >> >> Now in STIX this isn’t necessarily the case. Since STIX is transport, it >> does not guarantee to any extent that the intelligence value is retained all >> the way to its human consumer – not as that the intent. STIX 1.1.1 >> compliancy usually means, for both CSIRT communities and vendors (and many >> other communities I might add that this is relevant for), a partial >> implementation of parts of the standard – that are processed by a machine >> and/or readable by a human in different ways. >> >> For TAXII, a similar challenge exists where there is no easy automated way >> of determining for machines what the TAXII implementors supports. Think; >> authentication, authorization, different services (depending on discovery >> service on/off, hooked on/off), polling subscription models, etc. >> >> For me, certification and compliancy effort would be to ensure that it is >> publicly known and easily measurable what implementors actually support from >> the standard and where value is retained and where it isn’t. For TAXII, this >> means simple tools that make transparant the pattern of functionality >> implemented by a CSIRT community, vendor, etc. so they can say “guys I’m >> level A TAXII” - which will mean I support features A, B and C. For STIX >> similarly, a certain level of certification might mean that an >> producer/consumer implements the indicator/observable idioms, but does not >> retain much of the intelligence value of threat actor or exploit target >> information. This is relevant for the public to know, for producers to >> understand and to make transparant as to drive the community towards the >> right priorities and compatibility efforts. Right now, the conversational >> line of “STIX/TAXII compatible” has no value and requires significant effort >> to undercover what REALLY is implemented and what intelligence value is >> REALLY retained. >> >> So perhaps, certification is a bad word. Thoughts? >> >> Best regards, >> Joep >> >> From: Peter Allor <pallor@us.ibm.com> >> Date: Wednesday, June 24, 2015 at 7:11 PM >> To: Joep Gommers <joep@intelworks.com> >> Cc: Rich Struse <richard.struse@dhs.gov>, "cti@lists.oasis-open.org" >> <cti@lists.oasis-open.org> >> >> Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion >> >> Joep, >> 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 real >> adoption and use for CTI is in two communities, which by their nature are >> international. >> >> They are the CSIRT Community, specifically National CSIRTs but also >> Critical Infrastructure CSIRTs and Enterprise CSIRTs (I will not delve into >> the Big, Medium, Small discussion). There is a whole lot going on in CSIRT >> Services Framework and Education Development where this can be included and >> is updating materials from CERT/CC-SEI that are now 20 years old. >> >> Then there is the 'vendor' community, which has not been really engaged >> here. I know some will say they are part of that community, but then also >> tout how they are international. So we need the large IT Vendors and we >> need the broad IT Security Vendors as part of this process. That would be >> for all FOUR Sub-Committee's. Much of the indicators and expressions will >> need their input and adoption to actually gain traction for many and to >> enable the CSIRT Community (yes, the vendors are part of that community as >> well). 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 security >> venues globally it is a check box with little use. Now I know that >> vendors are looking to be part of this, but the sentiment here in the >> discussions does not reflect that. I say that from a vendor and incident >> response community perspective. >> >> So lets focus on how we get their perspectives to be included, as I know >> as vendors, we see that STIX/TAXII in their current incarnation do NOT work >> very 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 means >> we as designers need to have the implementers involved and participating, >> not corralled and shamed. If you take CVRF as an example, you can see that >> vendors 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 just >> another checkbox. >> >> </rant> >> >> Sincerely, >> Pete >> >> Peter Allor >> Senior Security Strategist, Project Manager, Disclosures >> Product Management and Strategy >> IBM Security >> 6303 Barfield Rd NE >> Atlanta, GA 30328-4233 >> Mobile: +1-404-643-9638 >> Fax: +1-845-491-4204 >> pallor@us.ibm.com >> >> Joep Gommers ---06/24/2015 11:15:54 AM---Hi Patrick, Great point. I think >> part would be an effort of mapping the landscape on >> >> From: Joep Gommers <joep@intelworks.com> >> To: Patrick Maroney <Pmaroney@Specere.org>, Mark Clancy >> <mclancy@soltra.com>, Peter F Brown <peter@peterfbrown.com>, >> "tony@yaanatech.com" <tony@yaanatech.com>, Rich Struse >> <richard.struse@dhs.gov> >> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> >> Date: 06/24/2015 11:15 AM >> Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion >> Sent by: <cti@lists.oasis-open.org> >> ________________________________ >> >> >> >> Hi Patrick, >> >> Great point. I think part would be an effort of mapping the landscape on >> the one side, ensuring the tooling required to enable people to be >> compatible (in addition to the standards and corresponding libraries) and >> part certification to solidify and ensure compliancy. Especially the >> latter option combined with hall of fame/shame (in a nice way :)) could >> drive some tangible KPIs.. ? >> >> Best regards, >> Joep >> >> >> >> On 6/24/15, 4:29 PM, "Patrick Maroney" <Pmaroney@Specere.org> 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 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 >> >Mark Clancy <mclancy@soltra.com> >> >Sent: Wednesday, June 24, 2015 10:17:23 AM >> >To: Peter F Brown; tony@yaanatech.com; Rich Struse >> >Cc: cti@lists.oasis-open.org >> >Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion >> > >> >All, >> >I agree with need this SC and am happy to help. I have been doing a lot >> >this as part of my role as DTCC's CISO in addition to my Soltra role. I >> >have been presenting/meeting in the US, Europe and Asia. I spend a lot of >> >time with legislators, policy makers, and global financial regulators on >> >information sharing and why automation is a key part of capablity needs. >> >By the same token most of the challenges in the global context are not >> >purely technical but national and regualtory impediments. Not to say the >> >technical things we are doing in CTI commitee in Oasis isn't also >> >critical as it certianly is, but that if we only address the technical >> >side of this problem we won't achieve the risk mitigation benefits we all >> >desire. >> > >> >So at some level what do we think "engagement" means vs. "outreach"? >> > >> >-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 >> >Peter F Brown <peter@peterfbrown.com> >> >Sent: Tuesday, June 23, 2015 6:37 PM >> >To: tony@yaanatech.com; Rich Struse >> >Cc: cti@lists.oasis-open.org >> >Subject: RE: [cti] CTI-Outreach Sub-Committee Nominations/Discussion >> > >> >+1 >> >Also agree with comment in an earlier thread that this SC ought to have >> >engagement as a core focus rather than outreach - and that ought to be >> >reflected in the name of any proposed SC. >> >Regards, >> >Peter >> > >> > >> >-----Original Message----- >> >From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On >> >Behalf Of Tony Rutkowski >> >Sent: 22 June, 2015 13:08 >> >To: Rich Struse >> >Cc: cti@lists.oasis-open.org >> >Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion >> > >> >Hi Rich, >> > >> >There is a great symmetry occurring here on a global scale. >> > >> >The first day of the annual cybersecurity workshop was held this >> >afternoon here in Sophia Antipolis in France's approximation of Silicon >> >Valley in the hills of Valbonne, France. There are people here from >> >around the world, but this afternoon was somewhat Euro centric with key >> >officials describing what was essential to regional and national >> >cybersecurity. Perhaps not by coincidence, cyber threat intelligence >> >sharing 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 some >> >responsibilities at the Directorate level similar to Rich Struse's as the >> >execution arm of the EU cybersecurity strategy - the analog of the White >> >House's framework initiatives. >> > >> >o Chris Ensor who heads up cybersecurity work in the UK's CESG >> >organization - also similar to Rich's responsibilities. >> > >> >o Marc Henauer of Switzerland's MELANI organization that is similar the >> >principal Swiss threat intelligence sharing body. >> > >> >o Edri an Belmonte, who plays the lead role in this area in ENISA >> > >> >All of the presentations except Cris Ensor's are available at: >> >> > >http://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/SECURITYWS/S01_SE >> >TTINGTHESCENE/ >> > >> >In the discussion session following the presentations, speaking at the >> >ETSI TC CYBER threat intelligence sharing rapporteur, I had the >> >opportunity to explain the creation of the new TC CTI committee and how >> >the platforms being pursued in CTI were proven best-of-breed models and >> >structured information sharing specifications that provided an ideal >> >match to each of their objectives. >> > >> >It was quite amazing how each of the parties - even in Europe - was >> >rather independently pursuing similar objectives. >> > >> >We also discussed how the work of TC CYBER was to survey the global >> >cybersecurity ecosystem and make use of the most successful existing >> >standards and not pursue duplicative work. Everyone seemed in agreement, >> >and going forward, there seems like an excellent basis for convergence >> >with the CTI work now getting underway. >> > >> >There will be further discussion at the workshop over the next two days >> >as well as definitive actions at the TC CYBER meeting on Thursday and >> >Friday. It was a good beginning that was continued usefully over local >> >provence wine and hors d'oeuves this evening (and setting a useful >> >precedent for future TC CTI physical gatherings). >> > >> >--tony >> > >> > >> > >> > >> >--------------------------------------------------------------------- >> >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 >> > >> > >> >--------------------------------------------------------------------- >> >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 "CTI Standards Adoption.docx" deleted by Peter >> Allor/Atlanta/IBM] >> --------------------------------------------------------------------- >> 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 >> >> >> >> --------------------------------------------------------------------- >> 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]