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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] 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]