Closed CyberDefCon8 closed 5 years ago
edent
commented
6 years ago Says that STIX and TAXII "are eligible for referencing in public procurement."
dwd
commented
6 years ago My recommendation would be unequivocally for STIX2, supported by TAXII2 as a minimal transport.
Well, until recently I was on the CTI TC at OASIS, so I'm pretty much bound to say STIX. aren't I?
However, STIX excels at analytic data, rather than incident reporting - you may wish to look at IODEF for the latter. Unfortunately they do not work very well together.
STIX (and TAXII) have undergone a major revision over the past few years, from the relatively widely deployed STIX v1.2 (which is moderate at analytic data and incident reporting), moving to the JSON-based STIX2, which is gradually gaining deployment. The entire design is radically different - STIX v1.2 can be seen as a simple interoperable object format, whereas STIX v2 is a graph format, hence lending itself very well to analytics and data science.
The NCSC includes a (small) mention of STIX and TAXII on their website, however STIX2 is a key part of their Active Cyber Defence toolset and strategy, and so is in effect the de-facto standard CTI standard already within HMG: https://www.ncsc.gov.uk/content/files/protected_files/article_files/ACD%20-%20one%20year%20on_0.pdf
This already interoperates with a number of external parties, including the UK ISP MISP instance operated by BT: https://www.globalservices.bt.com/en/aboutus/news-press/bt-steps-up-battle-against-cyber-crime
MISP, an open source federating CTI sharing tool, is also operated by NATO and multiple CERTs and CSIRTs globally - many of these would seem natural collaboration partners for HMG and MoD specifically. Supporting STIX2 clearly enables interoperability here.
TAXII2 is useful to support; however there are many ways of moving STIX2 data about once in that format, so I would see that as important as a Lowest Common Denominator rather than what should actually be deployed in all circumstances.
Finally... STIX2 includes the ability to incorporate access control labelling, both at an attribute level and at the top-level object (STIX Data Object, or SDO) level, but does not specify any particular syntax for these labels. It's not clear we have a data standard in HMG for labelling data either. It may be as well to explicitly note that security label interoperability should not be assumed.
Lawrence-G
commented
6 years ago Structured Threat Intelligence eXpression https://oasis-open.github.io/cti-documentation/stix/intro.html
Q. 1. Does it address and aid interoperability between public administrations?
A. Yes This has been demonstrated by the U.S. Department of Homeland Security (DHS) using STIX in a number of areas allowing the Office of Cybersecurity and Communications (CS&C) and its partners in both government and the private sector to exchange data elements and relationships defined by STIX joinup.ec.europa CAMMS 2018-05-16 Assessment of STIX
Q. 2. Does it address and aid the development of digital services in government?
A. Yes STIX (along with the related OASIS Standard TAXII) is intended to be used in the building of systems for the dissemination of Cyber Threat Intelligence [CTI] within and between organisations such as government departments. The National Cyber Security Centres Threat-o-Matic Active Cyber Defence hub uses STIX for threat data.
Q. 3. Are the functional and non-functional requirements for the use and implementation of the specification clearly defined?
A.Yes
Q. 4. Is it possible to implement the specification across different domains?
A. No STIX is a specific to the Cyber Threat Intelligence domain though it allows extension though custom objects to enable interoperability. (This ‘No’ answer should not be considered a negative assessment)
Q. 5. Is it largely independent from products of single providers, either open source or proprietary?
A.Yes Many companies supply products that use STIX.
Q. 6. Is it largely independent from specific platforms?
A. No Though STIX does not rely on any specific transport mechanism, STIX is a companion standard to TAXII. STIX is the language for describing cyber threat intelligence (CTI) and TAXII a standard for the exchange of CTI. The challenge owner suggests the adoption of both standards to meet the challenge.
Q. 7. Has the standard been written so that it can be delivered or used with more than one technology (for example XML and JSON)?
A. No In STIX version 2 objects are represented in JSON in version one XML is used
Q. 8. Has the specification been sufficiently developed and existed long enough to overcome most of its initial problems?
A. Yes The first version (0.3) of the standard was released in 6-2012. Development has been continuous since then. STIX 2 is a departure from the version 1.x development, employing JSON rather than XML to simplify implementation.
Q. 9. Are there existing or planned mechanisms to assess its conformity and implementation - for example conformity tests, certifications and plugfests?
A. Yes The OASIS STIX validators https://github.com/oasis-open/cti-pattern-validator https://github.com/oasis-open/cti-stix-validator and the STIX 2.0 Interoperability Test Document https://docs.google.com/document/d/1Bk3QsGqS84odU2iJtTZ8GokLZIOuz52iM7QKkRhJtQc/edit The OASIS TC organises plugfests https://www.oasis-open.org/news/pr/oasis-completes-second-successful-plugfest-for-stix-taxii-2-interoperability
Q. 10. Does it have sufficient detail, consistency and completeness for the use and development of products?
A. Yes Indicated by the number of products that have been built with the standard, examples are available here - https://wiki.oasis-open.org/cti/Products https://wiki.oasis-open.org/cti/Open%20Source%20Projects
Q. 11. Does it provide current implementation guidelines and documentation for the implementation of products?
A. Yes STIX guidelines and documents are available from the resources page of the STIC repository https://oasis-open.github.io/cti-documentation/resources#stix-20-specification
Q. 12. Does it provide a reference (or open source) implementation?
A. No None that we could find for STIX 2.
Q. 13. Does it address backwards compatibility with previous versions?
A.Yes There are tools to aid migration from version STIX 1 to version 2. For example https://github.com/oasis-open/cti-stix-elevator. Comparison between version 1 and 2 can be viewed at https://oasis-open.github.io/cti-documentation/stix/compare
Q. 14. Are the underlying technologies for implementing it proven, stable and clearly defined?
A. Yes STIX uses other standards such as JSON data interchange format, RFC3339 Timestamps, RFC3986 Uniform Resource Identifier (URI). A stated design principle of STIX is ‘Don’t reinvent the wheel - use other standards where possible’
Q. 15. Is information on the terms and policies for the establishment and operation of the standardisation organisation publicly available?
A. Yes OASIS terms and policies are available at https://www.oasis-open.org/policies-guidelines
Q. 16. Is participation in the creation process of the formal specification open to all relevant stakeholders (such as organisations, companies or individuals)?
A. Yes Access to the process by stakeholders is documented here https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#OASISstandard There is process for non members to comment on the TC’s work https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=cti https://oasis-open.github.io/cti-documentation/contribute
Q. 17. Is information on the standardisation process publicly available?
A. Yes https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#OASISstandard The TC process are available here. https://docs.google.com/document/d/1yvqWaPPnPW-2NiVCLqzRszcx91ffMowfT5MmE9Nsy_w/edit#heading=h.rnemfnrew1l4
Q. 18. Is information on the decision-making process for approving formal specifications is publicly available?
A.Yes https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#OASISstandard
Q. 19. Are the formal specifications approved in a decision-making process which aims at reaching consensus?
A. Yes OASIS works on a basis of consensus. https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#OScallForConsent
Q. 20. Are the formal specifications reviewed using a formal review process with all relevant external stakeholders (such as public consultation)?
A. Yes OASIS specifications are reviewed using a formal process which includes a mandatory public review of 60 days. https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess
Q. 21. Can all relevant stakeholders formally appeal or raise objections to the development and approval of formal specifications?
A. Yes OASIS: Objections can be raised throughout the development and approval process through various mailing lists. OASIS also has a formal appeals process to raise any objections to the process itself. https://www.oasis-open.org/policies-guidelines/tc-process#appeals If a stakeholder disagrees on technical matters they can express their concern with the Technical Committee. Appeals process are for procedural issues.
Q. 22. Is relevant documentation of the development and approval process of formal specifications publicly available (such as preliminary results and committee meeting notes)?
A. Yes Development can be followed on the GitHub issue tracker https://github.com/oasis-tcs/cti-stix2/issues. cti-stix-public mirror: is a read-only public mirror of the CTI STIX Subcommittee discussion list which can be subscribed to by anyone.
Q. 23. Is the documentation publicly available for implementation and use at zero or low cost?
A. Yes https://oasis-open.github.io/cti-documentation/resources#stix-20-specification
Q. 24. Is the documentation of the intellectual property rights publicly available (is there a clear and complete set of licence terms)?
A. Yes
OASIS IPR policy https://www.oasis-open.org/policies-guidelines/ipr
Q. 25. Is it licensed on a royalty-free basis?
A. Yes STIX is licensed under the DHS License No: DHS-NPPD-1-2015, which is a license developed by the US’ Department of Homeland Security (DHS) and which describes the copyright and trademark to three of its standard suites (STIX, TAXII and CybOX). This license is, by definition, a “perpetual, irrevocable, non-exclusive, royalty-free, worldwide copyright license https://www.oasis-open.org/committees/download.php/57069/ZDHS-OASIS-LICENSE-STIX-TAXII-CyBOX-final-signed.pdf
Q. 26. Has the formal specification been used for different implementations by different vendors/suppliers?
A.Yes See the list of projects employing STIX here - https://wiki.oasis-open.org/cti/Open%20Source%20Projects
Q. 27. Has the formal specification been used in different industries, business sectors or functions?
A. Yes The products that use the standard are not aimed at a particular industry or sector. See the range of products here https://wiki.oasis-open.org/cti/Products
Q. 28. Has interoperability been demonstrated across different implementations by different vendors/suppliers?
A. Yes As per question 26 See the list of projects employing STIX here - https://wiki.oasis-open.org/cti/Open%20Source%20Projects See DWD’s comment on this challenge “MISP, an open source federating CTI sharing tool, is also operated by NATO and multiple CERTs and CSIRTs globally - many of these would seem natural collaboration partners for HMG and MoD specifically. Supporting STIX2 clearly enables interoperability here”. STIX is to be used in the National Cyber Security Centres Threat-o-Matic and the BT MISP platform to exchange events
Q. 29. Do the products that implement it have a significant market share of adoption?
A. Yes It would seem so from the numbers of products that claim support https://wiki.oasis-open.org/cti/Products
Q. 30. Do the products that implement it target a broad spectrum of end-uses?
A. Yes
Q. 31. Does it have strong support from different interest groups?
A. Yes From both public and private sector organisations.
Q. 32. Is there evidence that the adoption of it supports improving efficiency and effectiveness of organisational process?
A. Yes As per the expected benefits of the challenge - A reduction in manual administration required to be performed by TI analysts by a system standardised on STIX
Q. 33. Is there evidence that the adoption of it makes it easier to migrate between different solutions from different providers?
A. Yes STIX ‘reports’ should be consumable by and transferred to different products from different providers that support the standard. One of the aims of the standard is to remove barrier to sharing CTI
Q. 34. Is there evidence that the adoption of it positively impacts the environment?
A. Yes There should be a reduction in the need for paper based reports.
Q. 35. Is there evidence that the adoption of it positively impacts financial costs?
A. Yes It is expected that CTI data will be made easy to analyse and save analysts time and therefore costs involved.
Q. 36. Is there evidence that the adoption of it positively impacts security?
A. Yes For example by speeding up the dissemination of CTI.
Q. 37. Is there evidence that the adoption of it can be implemented alongside enterprise security technologies?
A. Yes Examples of enterprise products that support STIX - https://www.mcafee.com/enterprise/en-us/products/advanced-threat-defense.html https://www.rsa.com/content/dam/en/data-sheet/rsa-netwitness-endpoint.pdf
Q. 38. Is there evidence that the adoption of it positively impacts privacy?
A. No/Not Applicable STIX does not impact privacy.
Q. 39. Is it largely compatible with related (not alternative) formal specifications in the same area of application?
A. Yes STIX is compatible with the TAXII CTI transport standard
Q. 40. Is there evidence that the adoption of it positively impacts accessibility and inclusion?
A. No Unlikely to affect accessibility and inclusion
Q. 41. Does it have a defined maintenance organisation?
A. Yes The STIX sub committee of OASIS Cyber Threat Intelligence (CTI) TC.
Q. 42. Does the maintenance organisation provide sufficient finance and resource to control short-to-medium-term threats?
A. Yes The organisation has a steady funding stream financed through membership fees to OASIS.
Q. 43. Does the maintenance organisation have a public statement on intention to transfer responsibility for maintenance of it, if the organisation were no longer able to continue?
A. No No public statement found by our research. It is assumed that none exists.
Q. 44. Does it have a defined maintenance and support process?
A. Yes Though the issues management process https://issues.oasis-open.org/projects/CTI/issues/CTI-1?filter=allopenissues
Q. 45. Does it have a defined policy for version management?
A. Yes Version management is in part described in FAQ https://docs.google.com/document/d/1V5tE78N10McUq1xUOHV1RTVsOoYmiq_xt2PY1YI8bsU/pub#h.ro152nqlb2jw Also see the OASIS policy http://docs.oasis-open.org/specGuidelines/namingGuidelines/metadata.html
Q. 46. Is this an existing European standard or an identified technical specification in Europe? (Note: CEN, CENELEC or ETSI are the European standards bodies. Technical specifications provided by organisations other than CEN, CENELEC or ETSI can be under consideration to become a European standard or an identified technical specification in Europe.)
A. No
Q. 47. Does this specification or standard cover an area different from those already identified or currently under consideration as an identified European standard or specification?
A. Yes There are no existing European standards that cover the same areas as STIX
Lawrence-G
commented
6 years ago Trusted Automated eXchange of Indicator Information https://oasis-open.github.io/cti-documentation/taxii/intro
Q. 1. Does it address and aid interoperability between public administrations?
A. Yes This has been demonstrated by the U.S. Department of Homeland Security (DHS) using TAXII. The Office of Cybersecurity and Communications (CS&C) and its partners exchange data elements and relationships defined by STIX through the use of TAXII, they seek to enable the rapid detection, prevention and mitigation of cyber threats.
joinup.ec.europa CAMMS 2018-05-16 Assessment of TAXII
Q. 2. Does it address and aid the development of digital services in government?
A. Yes TAXII (along with the related OASIS Standard STIX) is intended to be used in the building of systems for the dissemination of Cyber Threat Intelligence [CTI] within and between organisations such as government departments. TAXII is the application layer protocol designed for the transport of STIX CTI.
Q. 3. Are the functional and non-functional requirements for the use and implementation of the specification clearly defined?
A. Yes Requirements are listed in this document https://docs.google.com/document/d/1Jv9ICjUNZrOnwUXtenB1QcnBLO35RnjQcJLsa1mGSkI/edit#heading=h.4do73o99e2l7
Q. 4. Is it possible to implement the specification across different domains?
A. Yes TAXII transports threat intelligence across different domains.
Q. 5. Is it largely independent from products of single providers, either open source or proprietary?
A. Yes Many companies supply products built on the TAXII standard. Examples include: http://www.opentaxii.org/en/stable/ http://hailataxii.com/ https://www.alienvault.com/blogs/security-essentials/otx-is-now-a-free-stix-taxii-server
Q. 6. Is it largely independent from specific platforms?
A. Yes TAXII is a set of specifications for exchanging CTI, or other data types.
Q. 7. Has the standard been written so that it can be delivered or used with more than one technology (for example XML and JSON)?
A. No TAXII is used to exchange cyber threat intelligence (CTI) over HTTPS. HTTP is also used for content negotiation as per RFC7231.
Q. 8. Has the specification been sufficiently developed and existed long enough to overcome most of its initial problems?
A. Yes
Q. 9. Are there existing or planned mechanisms to assess its conformity and implementation - for example conformity tests, certifications and plugfests?
A. Yes See TAXII resources STIX/TAXII 2.0 Interoperability Test Document https://docs.google.com/document/d/1VY-uz3qnWpF8LMCWLgB_tY3uVLmw_lVcuXSwgdGEFHc/edit The most recent STIX/TAXII plugfest was in June 2018 Plugfesthttps://www.oasis-open.org/news/pr/oasis-completes-second-successful-plugfest-for-stix-taxii-2-interoperability
Q. 10. Does it have sufficient detail, consistency and completeness for the use and development of products?
A. Yes This has been demonstrated by a number of product and systems that employ TAXII
Q. 11. Does it provide current implementation guidelines and documentation for the implementation of products?
A. Yes See conformance section in the specification document https://docs.google.com/document/d/1Jv9ICjUNZrOnwUXtenB1QcnBLO35RnjQcJLsa1mGSkI/edit#
Q. 12. Does it provide a reference (or open source) implementation?
A. Yes There are client and server libraries available for TAXII 2 on GitHub https://github.com/oasis-open/cti-taxii-client https://github.com/oasis-open/cti-taxii-server
Q. 13. Does it address backwards compatibility with previous versions?
A. Yes In the TAXII property ‘versions’ “contains the list of TAXII versions that the API Root is compatible with. A value of taxii-2.0 MUST be included in this list to indicate conformance with the the latest version”.
Q. 14. Are the underlying technologies for implementing it proven, stable and clearly defined?
A. Yes Example HTTPS, DNS SRV,
Q. 15. Is information on the terms and policies for the establishment and operation of the standardisation organisation publicly available?
A. Yes OASIS terms and policies are available at https://www.oasis-open.org/policies-guidelines
Q. 16. Is participation in the creation process of the formal specification open to all relevant stakeholders (such as organisations, companies or individuals)?
A. Yes Access to the process by stakeholders is documented here https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#OASISstandard There is process for non members to comment on the TC’s work https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=cti https://oasis-open.github.io/cti-documentation/contribute
Q. 17. Is information on the standardisation process publicly available?
A. Yes Process information available online here -https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#OASISstandard
The TC processes are available here. https://docs.google.com/document/d/1yvqWaPPnPW-2NiVCLqzRszcx91ffMowfT5MmE9Nsy_w/edit#heading=h.rnemfnrew1l4
Q. 18. Is information on the decision-making process for approving formal specifications is publicly available?
A. Yes https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#OASISstandard
Q. 19. Are the formal specifications approved in a decision-making process which aims at reaching consensus?
A. Yes OASIS works on a basis of consensus. https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#OScallForConsent
Q. 20. Are the formal specifications reviewed using a formal review process with all relevant external stakeholders (such as public consultation)?
A. Yes OASIS specifications are reviewed using a formal process which includes a mandatory public review of 60 days. https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess
Q. 21. Can all relevant stakeholders formally appeal or raise objections to the development and approval of formal specifications?
A. Yes OASIS: Objections can be raised throughout the development and approval process through various mailing lists. OASIS also has a formal appeals process to raise any objections to the process itself. https://www.oasis-open.org/policies-guidelines/tc-process#appeals If a stakeholder disagrees on technical matters they can express their concern with the Technical Committee. Appeals process are for procedural issues.
Q. 22. Is relevant documentation of the development and approval process of formal specifications publicly available (such as preliminary results and committee meeting notes)?
A. Yes Development can be followed on the GitHub issue tracker https://github.com/oasis-tcs/cti-stix2/issues .
cti-stix-public mirror: is a read-only public mirror of the CTI STIX Subcommittee discussion list which can be subscribed to by anyone.
Q. 23. Is the documentation publicly available for implementation and use at zero or low cost?
A. Yes Available from - https://oasis-open.github.io/cti-documentation/taxii/intro
Q. 24. Is the documentation of the intellectual property rights publicly available (is there a clear and complete set of licence terms)?
A. Yes From the OASIS IPR policy https://www.oasis-open.org/policies-guidelines/ipr
Q. 25. Is it licensed on a royalty-free basis?
Q. 26. Has the formal specification been used for different implementations by different vendors/suppliers?
A. Yes See a list of projects employing TAXII here - https://wiki.oasis-open.org/cti/Open%20Source%20Projects
Q. 27 Has the formal specification been used in different industries, business sectors or functions?
A. Yes The products that use the standard are not aimed at a particular industry or sector. See the range of products here https://wiki.oasis-open.org/cti/Products
Q. 28. Has interoperability been demonstrated across different implementations by different vendors/suppliers?
A. Yes See the list of projects employing TAXII here - https://wiki.oasis-open.org/cti/Open%20Source%20Projects TAXII allows STIX CTI to be shared between different vendors products.
Q. 29. Do the products that implement it have a significant market share of adoption?
A. Yes It would seem so from the numbers of products that claim support https://wiki.oasis-open.org/cti/Products
Q. 30. Do the products that implement it target a broad spectrum of end-uses?
A. Yes Though these uses will be will tend to have a cyber security role
Q. 31. Does it have strong support from different interest groups?
A. Yes From both public and private sector organisations. See the list of partners and sponsors here - https://www.oasis-open.org/member-roster
Q. 32. Is there evidence that the adoption of it supports improving efficiency and effectiveness of organisational process?
A. Yes A reduction in manual administration required to be performed by TI analysts by a system standardised on TAXII and STIX
Q. 33. Is there evidence that the adoption of it makes it easier to migrate between different solutions from different providers?
A. Yes It should be easy to moves between different products from different providers that support the standard.
Q. 34. Is there evidence that the adoption of it positively impacts the environment?
A. Yes/Not applicable Though not a specific aim of the challenge, together with STIX the standard should reduce the need for the printing of reports.
Q. 35. Is there evidence that the adoption of it positively impacts financial costs?
A. Yes It is expected that CTI data will be made easy to analyse and save analysts time and therefore costs involved.
Q. 36. Is there evidence that the adoption of it positively impacts security?
A. Yes A more effective CTI system will improve overall security
Q. 37. Is there evidence that the adoption of it can be implemented alongside enterprise security technologies?
A. Yes Examples of enterprise products that support STIX - https://www.mcafee.com/enterprise/en-us/products/advanced-threat-defense.html
https://www.threatconnect.com/stix-taxii/
Q. 38. Is there evidence that the adoption of it positively impacts privacy?
A. Not Applicable TAXII does not impact privacy.
Q. 39. Is it largely compatible with related (not alternative) formal specifications in the same area of application?
A. Yes TAXII is designed as the data transport standard for the STIX CTI language and serialisation format
Q. 40. Is there evidence that the adoption of it positively impacts accessibility and inclusion?
A. Yes CTI reports will be available in accessible formats via TAXII clients rather than PDF documents for example.
Q. 41. Does it have a defined maintenance organisation?
A. Yes The TAXII sub committee of OASIS Cyber Threat Intelligence (CTI) TC.
Q. 42. Does the maintenance organisation provide sufficient finance and resource to control short-to-medium-term threats?
A. Yes The organisation has a steady funding stream financed through membership fees to OASIS.
Q. 43. Does the maintenance organisation have a public statement on intention to transfer responsibility for maintenance of it, if the organisation were no longer able to continue?
A. No No public statement found. If the There is a policy for maintenance which allows the specification to be continued by a different Technical Committee within OASIS https://www.oasis-open.org/policies-guidelines/tc-process#maintenanceActivity
Q. 44. Does it have a defined maintenance and support process?
A. Yes Though the issues management process https://issues.oasis-open.org/projects/CTI/issues/CTI-1?filter=allopenissues
Q. 45. Does it have a defined policy for version management?
A. Yes None found in the latest TAXII documentation but OASIS have the following policy http://docs.oasis-open.org/specGuidelines/namingGuidelines/metadata.html
Q. 46. Is this an existing European standard or an identified technical specification in Europe? (Note: CEN, CENELEC or ETSI are the European standards bodies. Technical specifications provided by organisations other than CEN, CENELEC or ETSI can be under consideration to become a European standard or an identified technical specification in Europe.)
A. No No standards from European SDOs. TAXII has been assessed by CAMSS and is eligible for referencing in public procurement.
Q. 47. Does this specification or standard cover an area different from those already identified or currently under consideration as an identified European standard or specification?
A. Yes
joelgsamuel
commented
6 years ago As per engagement with @edent on a cross-government Slack channel: I would also support STIX2 supported by TAXII2.
I have highlighted this github.com issue discussion to an NCSC contact working on their TI platform.
CyberDefCon8
commented
6 years ago @dwd - fully agree with your comments ref usage of STIX2/TAXII2 [over earlier versions], and this would be the intention for impending implementation. It would not be the intention to use STIX for incident handling/reporting [noting your comments regarding IODEF and lack of interoperability].
Yes am aware of MiSP and have kicked off discussions with a number of PAG around CTI sharing.
Interested in your comment ref classification labeling - do you have any further information on this?
CyberDefCon8
commented
6 years ago @joelsamuelmoj - I have had a number of discussions with NCSC on this topic, so would be good to see if we've been speaking to the same people?
@edent - are you able to put us in touch to have a conversation?
dwd
commented
6 years ago @CyberDefCon8 - Further info... Well, different HMG depts have different formats for machine-readable classification info. To take an example from another organisation, NATO is - in theory - all STANAG 4774 these days, for instance, but in practise there's also SDN.801(c)/ACP-145 floating about.
Within HMG, there are multiple policies in use (including transnational policies like NATO one assumes), and some departments have their own formats in use (JSON-based, for instance), and if there is a standard interoperable label format, it's passed me by completely.
CyberDefCon8
commented
6 years ago This proposal is to use a collection of open standards to facilitate creation, analysis and dissemination of Cyber Threat Intelligence [CTI].
The challenge owner suggested use of open standards STIX 2.0 and TAXII 2.0 be adopted.
This will allow CTI to be created and shared internally within organisations, and with the wider cyber community nationally and internationally, to detect and respond to malicious activity in a more timely and automated manner.
The outcome will be delivery of information in a visual representation for humans and a machine readable format to increase machine to machine automated exchange.
The proposal identified users of this standard will be Analysts in both the Threat Intelligence and Security Operations Centre fields, as well as operators and administrators of security enforcing technology.
STIX and TAXII are in use within other national government partners, and is now being adopted by many security technology vendors. A Commission Implementing Decision promoted the use of both STIX and TAXII as technical specifications suitable for referencing in public procurement.
Use of the common STIX format to describe Cyber Threat Intelligence [including Threat Actors, IOCs, TTPS, sightings etc] enables all stakeholders to describe information in a way that is repeatable and which can be understood by both humans and machines.
The ability to link multiple Indicators of Compromise [IOCs] against Tactics, Techniques and Procedures [TTPs], and to assert IOCs to certain campaigns or adversaries, enables a greater and more holistic view of the issue to be understood and for previously un-associated events to be linked.
Adoption of STIX and TAXII will increase interoperability within a federated organisation, between peer organisation and with national and international partners.
The STIX format provides the ability for the relevant intelligence to be delivered to the relevant user group into both a timely and standardised format. It also facilitates greater levels of automation using orchestration. This does not necessarily negate the need for human interaction, as full automation has a high level of potential self denial of service. However once the human in the loop has decided intelligence is valid, it needs to be delivered to the security enforcing functions in a timely and machine readable format.
Adoption of a STIX format would reduce the requirement for document based creation of Cyber Threat Intelligence in different formats. Email based distribution would also be mitigated by adoption of the TAXII application protocol. Both will reduce manual administration and single usage consumables.
For the functional needs identified in this proposal, STIX is to be used when Cyber Threat Intelligence is being generated and TAXII when exchanged between users or between different IT systems.
This should include at least one of the twelve defined STIX Domain Objects [Attack Pattern, Campaign, Course of Action, Identity, Indicator, Intrusion Set, Malware, Observed Data, Report, Threat Actor, Tool or Vulnerability] and either of the two STIX Relationship Objects [Relationship, Sighting].
TAXII services should be advertised as an application protocol over HTTPS via a RESTfull API supported by DNS services. This should be as either a Collection or Channel from which consumers can subscribe.
All existing data held within previous versions of STIX should, where possible, be converted to STIX 2.0 format using the STIX Elevator. Conversion toolsets are available for MISP, which should be used as an alternative to hosting multiple platforms.
Training must be provided to analysts on the function and structure of STIX in order that information is recorded correctly and the standard is used effectively.
garyga7
commented
5 years ago @CyberDefCon8 I work for part of MOD (Dstl) and would love to hear from you regarding your thoughts on the cross-over between the development of a CTI standard and adoption of Smart Contracts in a Distributed Ledgers Environment...if you are interested just reply below to my personal e mail account garyglennonalty@googlemail.com and I will forward on my Dstl account details
joelgsamuel
commented
5 years ago @CyberDefCon8 I work for part of MOD (Dstl) and would love to hear from you regarding your thoughts on the cross-over between the development of a CTI standard and adoption of Smart Contracts in a Distributed Ledgers Environment...if you are interested just reply below to my personal e mail account garyglennonalty@googlemail.com and I will forward on my Dstl account details
I'd be interested to follow this discussion (out of simple curiosity) given I am unable to imagine useful crossover between the two - particularly any that isn't immediately counter-balanced by remote code execution concerns.
Lawrence-G
commented
5 years ago The profile for STIX and TAXII has been published - Here
Create A Challenge
Title
Adoption of an open standard to facilitate creation, analysis and dissemination of Cyber Threat Intelligence [CTI].
Category
Challenge Owner
Principal Security Architect for the Cyber Security Operations Capability at the Ministry of Defence.
Short Description
Due to the industry wide shortage of qualified people within IT Security, coupled with the advance in automation and orchestration, there is a requirement to ingest and disseminate CTI in a more timely and structured format. Currently large amounts of time is spent performing manual processes such copying and pasting information from PDF reports or CSVs, into the relevant IT security enforcing toolsets to monitor and/or block malicious activity. The use of a common method and format for describing threat actors, their behaviours and associated indicators of compromise would greatly increase the timeliness and a defined method to share this would cut down on manual analyst activity. By using a defined format, Threat Intelligence sharing can be increased with the Department, across government and with industry.
User Need
• A common methodology for Threat Intelligence analysts across the Department, partners and industry to define Threat Actors, IOCs, sightings and other information associated with Threat Intelligence • The ability to link all aspects of TI together e.g. an IOC to a sighting, an IOC to a TTP, a TTP to a Campaign, a Campaign to a Threat Actor etc. • A defined format for creation of TI • A defined format for ingest/dissemination/sharing of TI [moving away from email based distribution of TI] to move TI in a timely manner • A method for pushing TI to security enforcing functions once deemed suitable for release • The ability to make planning decisions regarding potential threat or vulnerability to assets in a timely manner in support of the mission or to inform a mission commander
Expected Benefits
• Reduction in manual administration required to be performed by TI analysts • Reduction in time taken to analyse threats and release actionable intelligence • Removal of single points of failure in process by not using email based dissemination • Cost and environmental benefit, as there will be a dramatic reduction in the need to print large PDF reports, burn one time CDs for airgap transfer etc.
Functional Needs
• Ability to store data in a referenceable format • Store data in a suitable repository with appropriate authorisation controls • API access to data for query • Dissemination of data to other security enforcing functions • Ability to disseminate information over low bandwidth links [i.e. small data size]
It is expected that the following open standards will satisfy this challenge:
TI creation: Structured Threat Intelligence eXpression [STIX] https://oasis-open.github.io/cti-documentation/stix/intro.html
TI dissemination: Trusted Automated eXchange of Indicator Information [TAXII] https://oasis-open.github.io/cti-documentation/taxii/intro