OASIS Cyber Threat Intelligence (CTI) TC

Hi,   stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification.   So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board.   Here is the overview of the indicator entity/concept taken from page 13 of   https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf     Let me propose the following simplifications:   - version:   Keep.   - negate:   Remove -- the use case is mostly academic, but if the   flag is there, it completely changes the semantics of how   the indicator is to be handled and is a real pain for implementation,   even though it is hardly ever used     (Note: as shall be explained below, the 'negate' will not be needed anymore    for building logical expressions of indicators, because we shall throw those    out, too).   - Title:   Make the field mandatory, but it may be empty.   - Type:   Remove, if there isn't someone who can come up with a   convincing case in which the field is really useful and where   the intended semantics could not be communicated with   a reference to a COA.   - Alternative_ID:   Unsure, probably keep.   - Description:   - There should be exactly 1 description field (which may be empty).       Yes, this precludes fancy schemes of having different descriptions     for different audiences/access levels, but those should amount     to less than 0.1% of all indicator objects ever to be     produced and thus do not warrant substantial complication of     the standard.     - There should be exactly one text representation, and that should *NOT*     be html on account of security issues with rendering HTML in the     browser. Chose Markdown, RestructuredText or whatever.   - Short_Description:     Remove: I am tired of receiving indicator objects in which   two or three out of three of the fields "title",   "description", "short_description"   are empty -- one description field should be plenty.     (Besides: everybody keeps telling me that STIX is for   machine-2-machine rather than *-2-human communication, so   why the big fuss about description fields?)     - Valid_Time_Proposition:     Timing info for indicators is badly needed, but I have yet to encounter usage   of it. Can we come up with sensible guidelines of how to use the field?   It should only be kept if we can...   - IndicatorExpression     In the present specification, this field can either   contain what is essentially a logical formula (codified as a tree)   of indicators or an observable composition.     - Remove logical operations: allow only to reference a list     of indicators that constitute the present indicator.     - If you want to do complicated and/or/not-reasoning about     observable stuff: that is essentially a signature,     so find a signature-language of your choice (including     and/or/not-combinations of CybOX observables, if that     is what works best) and formulate the signature     as a test mechanism.     - For everything else: find a way to encode observable     patterns as simple key-value pairs and include/reference a list     of them here. Should work fine for the majority of     current use-cases. At most, allow a structured list that     groups basic observable patterns (key-value) pairs with     respect to a cybox observable to which they belong.      - Indicated_TTP:     Use yet-to-be-designed relationship mechanism.   - Kill_Chain_Phases:     Define *ONE* standard STIX kill chain and work with that.   Being able to include alternative models is nice, but   complicates tooling quite a bit ... and, remember, this   is an exchange format, so one common kill-chain model   understood in the same way by everybody will work best.   - Test Mechanisms     Make this a stand-alone entity/object rather than part   of the Indicator object. As mentioned above: use this also   to communicate more complicate observable patterns expressed in CybOX.   - Likely_Impact.     Remove: I have never encountered it being used and have   a hard time coming up with a convincing use case.   - Suggested_COAs:     Use yet-to-be-designed relationship mechanism.   - Handling:     Replace with some new mechanism for marking stuff with   handling information.   - Confidence     Keep: we need a simple way to distinguish high-confidence   from low-confidence indicators.   - Sightings:     Find some other way to do sightings (cf. the discussion on   the mailing list)   - Related_*: Use yet-to-be-designed relationship mechanism.   - Producer:     Either simplify drastically or better yet, leave away   and consider for the next but one major release.   Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think.   Kind regards,   Bernd   --------   Bernd Grobauer, Siemens CERT        

I really like it and your ideas are brilliant, this is where we should go..  The only other thing I would add to your list is getting rid of all of the namespace cruft.  I feel like STIX 1.x used inheritance models and thus namespaces to an academic nth degree.  I believe that just because you can, do not always mean you should.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Sep 21, 2015, at 08:04, Grobauer, Bernd < Bernd.Grobauer@siemens.com > wrote: Hi,   stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification.     So, as an experiment, below I will go through the 'Indicator'   entity and propose changes. Here I will try to take the side of   as simple as simple can be , be the simpleton's advocate, so   to speak, in the hope of getting some discussion going regarding   what is maybe too simplistic vs what kind of complexity we might   be able to throw over board.   Here is the overview of the indicator entity/concept taken from page 13 of   https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf   <Picture (Device Independent Bitmap) 1.jpg>   Let me propose the following simplifications:   - version:     Keep.   - negate:     Remove -- the use case is mostly academic, but if the     flag is there, it completely changes the semantics of how   the indicator is to be handled and is a real pain for implementation,   even though it is hardly ever used     (Note: as shall be explained below, the 'negate' will not be needed anymore      for building logical expressions of indicators, because we shall throw those    out, too).   - Title:     Make the field mandatory, but it may be empty.   - Type:   Remove, if there isn't someone who can come up with a     convincing case in which the field is really useful and where   the intended semantics could not be communicated with   a reference to a COA.   - Alternative_ID:   Unsure, probably keep.     - Description:   - There should be exactly 1 description field (which may be empty).       Yes, this precludes fancy schemes of having different descriptions     for different audiences/access levels, but those should amount     to less than 0.1% of all indicator objects ever to be       produced and thus do not warrant substantial complication of     the standard.     - There should be exactly one text representation, and that should *NOT*     be html on account of security issues with rendering HTML in the     browser. Chose Markdown, RestructuredText or whatever.   - Short_Description:     Remove: I am tired of receiving indicator objects in which   two or three out of three of the fields title ,     description , short_description   are empty -- one description field should be plenty.     (Besides: everybody keeps telling me that STIX is for     machine-2-machine rather than *-2-human communication, so   why the big fuss about description fields?)     - Valid_Time_Proposition:     Timing info for indicators is badly needed, but I have yet to encounter usage   of it. Can we come up with sensible guidelines of how to use the field?   It should only be kept if we can...   - IndicatorExpression     In the present specification, this field can either   contain what is essentially a logical formula (codified as a tree)   of indicators or an observable composition.     - Remove logical operations: allow only to reference a list     of indicators that constitute the present indicator.     - If you want to do complicated and/or/not-reasoning about     observable stuff: that is essentially a signature,     so find a signature-language of your choice (including     and/or/not-combinations of CybOX observables, if that     is what works best) and formulate the signature     as a test mechanism.       - For everything else: find a way to encode observable     patterns as simple key-value pairs and include/reference a list     of them here. Should work fine for the majority of     current use-cases. At most, allow a structured list that     groups basic observable patterns (key-value) pairs with     respect to a cybox observable to which they belong.        - Indicated_TTP:       Use yet-to-be-designed relationship mechanism.   - Kill_Chain_Phases:     Define *ONE* standard STIX kill chain and work with that.   Being able to include alternative models is nice, but   complicates tooling quite a bit ... and, remember, this   is an exchange format, so one common kill-chain model   understood in the same way by everybody will work best.   - Test Mechanisms     Make this a stand-alone entity/object rather than part   of the Indicator object. As mentioned above: use this also     to communicate more complicate observable patterns expressed in CybOX.   - Likely_Impact.     Remove: I have never encountered it being used and have   a hard time coming up with a convincing use case.   - Suggested_COAs:       Use yet-to-be-designed relationship mechanism.   - Handling:     Replace with some new mechanism for marking stuff with   handling information.   - Confidence     Keep: we need a simple way to distinguish high-confidence   from low-confidence indicators.   - Sightings:       Find some other way to do sightings (cf. the discussion on   the mailing list)   - Related_*: Use yet-to-be-designed relationship mechanism.   - Producer:       Either simplify drastically or better yet, leave away   and consider for the next but one major release.   Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think.   Kind regards,   Bernd   --------   Bernd Grobauer, Siemens CERT Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Hi, first for initiating this discussion. While I will comment inline below, (because everything was added, at some point, for a reason or another) without wanting to be the devil's advocate vs KISS; I wonder if we should consider an approach at an higher level. Putting some food on the table: - Should we provide guidance documents (e.g. The preferred Kill_Chain is LM, or It is highly recommended to use the LM Kill Chain, etc.)? or/and - Should we define what is mandatory or optional (in order to reach compliance/compatibility level A, B, C)? or/and - Should we have "2 versions": Minimum required fields (for compliance level A/STIX-basic), Additional advanced fields (for compliance level B/STIX-Gold) (with full support, level C/STIX-Platinum)? 2015-09-21 17:04 GMT+03:00 Grobauer, Bernd < Bernd.Grobauer@siemens.com > : - negate:   Remove -- the use case is mostly academic, but if the   flag is there, it completely changes the semantics of how   the indicator is to be handled and is a real pain for implementation,   even though it is hardly ever used     (Note: as shall be explained below, the 'negate' will not be needed anymore    for building logical expressions of indicators, because we shall throw those    out, too). JA>  I would agree   - Title:   Make the field mandatory, but it may be empty. JA>  +1    - Type:   Remove, if there isn't someone who can come up with a   convincing case in which the field is really useful and where   the intended semantics could not be communicated with   a reference to a COA. JA>  Disagree for now (until we review the Controlled Vocabularies)     - Alternative_ID:   Unsure, probably keep. JA>  keep (advanced) for mapping with internal/proprietary IDs (same as CVE - MS-KB link for VM)     - Description:   - There should be exactly 1 description field (which may be empty).       Yes, this precludes fancy schemes of having different descriptions     for different audiences/access levels, but those should amount     to less than 0.1% of all indicator objects ever to be     produced and thus do not warrant substantial complication of     the standard. JA>  Sensitive regarding internationalization (meantime now it's a 0..n or 1..n, that could be a 1..1 + another OtherDescriptions field for 0..n)       - There should be exactly one text representation, and that should *NOT*     be html on account of security issues with rendering HTML in the     browser. Chose Markdown, RestructuredText or whatever. JA>  not sure for now for the format, need to investigate further     - Short_Description:     Remove: I am tired of receiving indicator objects in which   two or three out of three of the fields "title",   "description", "short_description"   are empty -- one description field should be plenty.     (Besides: everybody keeps telling me that STIX is for   machine-2-machine rather than *-2-human communication, so   why the big fuss about description fields?) JA>  Not for remove, but Potentially could be replaced by Description (as 1..1) + DescriptionOthers as 0..n       - Valid_Time_Proposition:     Timing info for indicators is badly needed, but I have yet to encounter usage   of it. Can we come up with sensible guidelines of how to use the field?   It should only be kept if we can... JA>  Guidance documents... :-) Some could argue we just need that for an Exercise/Test, or/and I personally hate CTI feeds with tons of old/useless IOCs JA>  But could be just an Advanced Field     - IndicatorExpression     In the present specification, this field can either   contain what is essentially a logical formula (codified as a tree)   of indicators or an observable composition.     - Remove logical operations: allow only to reference a list     of indicators that constitute the present indicator.     - If you want to do complicated and/or/not-reasoning about     observable stuff: that is essentially a signature,     so find a signature-language of your choice (including     and/or/not-combinations of CybOX observables, if that     is what works best) and formulate the signature     as a test mechanism.     - For everything else: find a way to encode observable     patterns as simple key-value pairs and include/reference a list     of them here. Should work fine for the majority of     current use-cases. At most, allow a structured list that     groups basic observable patterns (key-value) pairs with     respect to a cybox observable to which they belong.    JA>  Investigate further     - Indicated_TTP:     Use yet-to-be-designed relationship mechanism.   - Kill_Chain_Phases:     Define *ONE* standard STIX kill chain and work with that.   Being able to include alternative models is nice, but   complicates tooling quite a bit ... and, remember, this   is an exchange format, so one common kill-chain model   understood in the same way by everybody will work best. JA>  Guidance (preferred one), Optional/Advanced     - Test Mechanisms     Make this a stand-alone entity/object rather than part   of the Indicator object. As mentioned above: use this also   to communicate more complicate observable patterns expressed in CybOX. JA>  potentially ok     - Likely_Impact.     Remove: I have never encountered it being used and have   a hard time coming up with a convincing use case. JA>  I see interest there for high level/strategy/business point of view (Risk Management: Impact * Likelihood)     - Suggested_COAs:     Use yet-to-be-designed relationship mechanism.   - Handling:     Replace with some new mechanism for marking stuff with   handling information.   - Confidence     Keep: we need a simple way to distinguish high-confidence   from low-confidence indicators.   - Sightings:     Find some other way to do sightings (cf. the discussion on   the mailing list) JA>  Still unresolved I agree     - Related_*: Use yet-to-be-designed relationship mechanism.   - Producer:     Either simplify drastically or better yet, leave away   and consider for the next but one major release. JA>  not sure for the moment  

I will (again) argue for: (1) STIX Profiles   (1.1) human and machine readable   (1.2) Adding declaritive 'simple' form: enumeration of       (1.2.1) these are the 'things' I can consume/produce      (1.2.3) these are the conventions for "types of things": e.g. Kill Chain (2) Community consensus on a core set of standard STIX Profiles (e.g: top 10 use cases) Note that this is not an arguement against things like elimination multiple description options, etc.   It is an argument however for avoiding endless debates on which "things" are important as I posit we will never reach consensus given the diverse set of world views and use cases CTI needs to embrace. Editorial Note: Although we do indeed argue for M2M inter-exchange as the core functional requirement, eventually the data is likely presented to a human where things like Description provide/context value in the end state models/databases/ticketing systems/etc. Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Mon, Sep 21, 2015 at 8:08 AM -0700, "Jerome Athias" < athiasjerome@gmail.com > wrote: Hi, first for initiating this discussion. While I will comment inline below, (because everything was added, at some point, for a reason or another) without wanting to be the devil's advocate vs KISS; I wonder if we should consider an approach at an higher level. Putting some food on the table: - Should we provide guidance documents (e.g. The preferred Kill_Chain is LM, or It is highly recommended to use the LM Kill Chain, etc.)? or/and - Should we define what is mandatory or optional (in order to reach compliance/compatibility level A, B, C)? or/and - Should we have "2 versions": Minimum required fields (for compliance level A/STIX-basic), Additional advanced fields (for compliance level B/STIX-Gold) (with full support, level C/STIX-Platinum)? 2015-09-21 17:04 GMT+03:00 Grobauer, Bernd < Bernd.Grobauer@siemens.com > : - negate:   Remove -- the use case is mostly academic, but if the   flag is there, it completely changes the semantics of how   the indicator is to be handled and is a real pain for implementation,   even though it is hardly ever used     (Note: as shall be explained below, the 'negate' will not be needed anymore    for building logical expressions of indicators, because we shall throw those    out, too). JA>  I would agree   - Title:   Make the field mandatory, but it may be empty. JA>  +1    - Type:   Remove, if there isn't someone who can come up with a   convincing case in which the field is really useful and where   the intended semantics could not be communicated with   a reference to a COA. JA>  Disagree for now (until we review the Controlled Vocabularies)     - Alternative_ID:   Unsure, probably keep. JA>  keep (advanced) for mapping with internal/proprietary IDs (same as CVE - MS-KB link for VM)     - Description:   - There should be exactly 1 description field (which may be empty).       Yes, this precludes fancy schemes of having different descriptions     for different audiences/access levels, but those should amount     to less than 0.1% of all indicator objects ever to be     produced and thus do not warrant substantial complication of     the standard. JA>  Sensitive regarding internationalization (meantime now it's a 0..n or 1..n, that could be a 1..1 + another OtherDescriptions field for 0..n)       - There should be exactly one text representation, and that should *NOT*     be html on account of security issues with rendering HTML in the     browser. Chose Markdown, RestructuredText or whatever. JA>  not sure for now for the format, need to investigate further     - Short_Description:     Remove: I am tired of receiving indicator objects in which   two or three out of three of the fields "title",   "description", "short_description"   are empty -- one description field should be plenty.     (Besides: everybody keeps telling me that STIX is for   machine-2-machine rather than *-2-human communication, so   why the big fuss about description fields?) JA>  Not for remove, but Potentially could be replaced by Description (as 1..1) + DescriptionOthers as 0..n       - Valid_Time_Proposition:     Timing info for indicators is badly needed, but I have yet to encounter usage   of it. Can we come up with sensible guidelines of how to use the field?   It should only be kept if we can... JA>  Guidance documents... :-) Some could argue we just need that for an Exercise/Test, or/and I personally hate CTI feeds with tons of old/useless IOCs JA>  But could be just an Advanced Field     - IndicatorExpression     In the present specification, this field can either   contain what is essentially a logical formula (codified as a tree)   of indicators or an observable composition.     - Remove logical operations: allow only to reference a list     of indicators that constitute the present indicator.     - If you want to do complicated and/or/not-reasoning about     observable stuff: that is essentially a signature,     so find a signature-language of your choice (including     and/or/not-combinations of CybOX observables, if that     is what works best) and formulate the signature     as a test mechanism.     - For everything else: find a way to encode observable     patterns as simple key-value pairs and include/reference a list     of them here. Should work fine for the majority of     current use-cases. At most, allow a structured list that     groups basic observable patterns (key-value) pairs with     respect to a cybox observable to which they belong.    JA>  Investigate further     - Indicated_TTP:     Use yet-to-be-designed relationship mechanism.   - Kill_Chain_Phases:     Define *ONE* standard STIX kill chain and work with that.   Being able to include alternative models is nice, but   complicates tooling quite a bit ... and, remember, this   is an exchange format, so one common kill-chain model   understood in the same way by everybody will work best. JA>  Guidance (preferred one), Optional/Advanced     - Test Mechanisms     Make this a stand-alone entity/object rather than part   of the Indicator object. As mentioned above: use this also   to communicate more complicate observable patterns expressed in CybOX. JA>  potentially ok     - Likely_Impact.     Remove: I have never encountered it being used and have   a hard time coming up with a convincing use case. JA>  I see interest there for high level/strategy/business point of view (Risk Management: Impact * Likelihood)     - Suggested_COAs:     Use yet-to-be-designed relationship mechanism.   - Handling:     Replace with some new mechanism for marking stuff with   handling information.   - Confidence     Keep: we need a simple way to distinguish high-confidence   from low-confidence indicators.   - Sightings:     Find some other way to do sightings (cf. the discussion on   the mailing list) JA>  Still unresolved I agree     - Related_*: Use yet-to-be-designed relationship mechanism.   - Producer:     Either simplify drastically or better yet, leave away   and consider for the next but one major release. JA>  not sure for the moment  

A great big +1 from me. :-) sean From: < cti@lists.oasis-open.org > on behalf of Patrick Maroney < Pmaroney@Specere.org > Date: Monday, September 21, 2015 at 11:41 AM To: Bernd Grobauer < Bernd.Grobauer@siemens.com >, Jerome Athias < athiasjerome@gmail.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? I will (again) argue for: (1) STIX Profiles   (1.1) human and machine readable   (1.2) Adding declaritive 'simple' form: enumeration of       (1.2.1) these are the 'things' I can consume/produce      (1.2.3) these are the conventions for "types of things": e.g. Kill Chain (2) Community consensus on a core set of standard STIX Profiles (e.g: top 10 use cases) Note that this is not an arguement against things like elimination multiple description options, etc.   It is an argument however for avoiding endless debates on which "things" are important as I posit we will never reach consensus given the diverse set of world views and use cases CTI needs to embrace. Editorial Note: Although we do indeed argue for M2M inter-exchange as the core functional requirement, eventually the data is likely presented to a human where things like Description provide/context value in the end state models/databases/ticketing systems/etc. Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Mon, Sep 21, 2015 at 8:08 AM -0700, "Jerome Athias" < athiasjerome@gmail.com > wrote: Hi, first for initiating this discussion. While I will comment inline below, (because everything was added, at some point, for a reason or another) without wanting to be the devil's advocate vs KISS; I wonder if we should consider an approach at an higher level. Putting some food on the table: - Should we provide guidance documents (e.g. The preferred Kill_Chain is LM, or It is highly recommended to use the LM Kill Chain, etc.)? or/and - Should we define what is mandatory or optional (in order to reach compliance/compatibility level A, B, C)? or/and - Should we have "2 versions": Minimum required fields (for compliance level A/STIX-basic), Additional advanced fields (for compliance level B/STIX-Gold) (with full support, level C/STIX-Platinum)? 2015-09-21 17:04 GMT+03:00 Grobauer, Bernd < Bernd.Grobauer@siemens.com > : - negate:   Remove -- the use case is mostly academic, but if the   flag is there, it completely changes the semantics of how   the indicator is to be handled and is a real pain for implementation,   even though it is hardly ever used     (Note: as shall be explained below, the 'negate' will not be needed anymore    for building logical expressions of indicators, because we shall throw those    out, too). JA>  I would agree   - Title:   Make the field mandatory, but it may be empty. JA>  +1    - Type:   Remove, if there isn't someone who can come up with a   convincing case in which the field is really useful and where   the intended semantics could not be communicated with   a reference to a COA. JA>  Disagree for now (until we review the Controlled Vocabularies)     - Alternative_ID:   Unsure, probably keep. JA>  keep (advanced) for mapping with internal/proprietary IDs (same as CVE - MS-KB link for VM)     - Description:   - There should be exactly 1 description field (which may be empty).       Yes, this precludes fancy schemes of having different descriptions     for different audiences/access levels, but those should amount     to less than 0.1% of all indicator objects ever to be     produced and thus do not warrant substantial complication of     the standard. JA>  Sensitive regarding internationalization (meantime now it's a 0..n or 1..n, that could be a 1..1 + another OtherDescriptions field for 0..n)       - There should be exactly one text representation, and that should *NOT*     be html on account of security issues with rendering HTML in the     browser. Chose Markdown, RestructuredText or whatever. JA>  not sure for now for the format, need to investigate further     - Short_Description:     Remove: I am tired of receiving indicator objects in which   two or three out of three of the fields "title",   "description", "short_description"   are empty -- one description field should be plenty.     (Besides: everybody keeps telling me that STIX is for   machine-2-machine rather than *-2-human communication, so   why the big fuss about description fields?) JA>  Not for remove, but Potentially could be replaced by Description (as 1..1) + DescriptionOthers as 0..n       - Valid_Time_Proposition:     Timing info for indicators is badly needed, but I have yet to encounter usage   of it. Can we come up with sensible guidelines of how to use the field?   It should only be kept if we can... JA>  Guidance documents... :-) Some could argue we just need that for an Exercise/Test, or/and I personally hate CTI feeds with tons of old/useless IOCs JA>  But could be just an Advanced Field     - IndicatorExpression     In the present specification, this field can either   contain what is essentially a logical formula (codified as a tree)   of indicators or an observable composition.     - Remove logical operations: allow only to reference a list     of indicators that constitute the present indicator.     - If you want to do complicated and/or/not-reasoning about     observable stuff: that is essentially a signature,     so find a signature-language of your choice (including     and/or/not-combinations of CybOX observables, if that     is what works best) and formulate the signature     as a test mechanism.     - For everything else: find a way to encode observable     patterns as simple key-value pairs and include/reference a list     of them here. Should work fine for the majority of     current use-cases. At most, allow a structured list that     groups basic observable patterns (key-value) pairs with     respect to a cybox observable to which they belong.    JA>  Investigate further     - Indicated_TTP:     Use yet-to-be-designed relationship mechanism.   - Kill_Chain_Phases:     Define *ONE* standard STIX kill chain and work with that.   Being able to include alternative models is nice, but   complicates tooling quite a bit ... and, remember, this   is an exchange format, so one common kill-chain model   understood in the same way by everybody will work best. JA>  Guidance (preferred one), Optional/Advanced     - Test Mechanisms     Make this a stand-alone entity/object rather than part   of the Indicator object. As mentioned above: use this also   to communicate more complicate observable patterns expressed in CybOX. JA>  potentially ok     - Likely_Impact.     Remove: I have never encountered it being used and have   a hard time coming up with a convincing use case. JA>  I see interest there for high level/strategy/business point of view (Risk Management: Impact * Likelihood)     - Suggested_COAs:     Use yet-to-be-designed relationship mechanism.   - Handling:     Replace with some new mechanism for marking stuff with   handling information.   - Confidence     Keep: we need a simple way to distinguish high-confidence   from low-confidence indicators.   - Sightings:     Find some other way to do sightings (cf. the discussion on   the mailing list) JA>  Still unresolved I agree     - Related_*: Use yet-to-be-designed relationship mechanism.   - Producer:     Either simplify drastically or better yet, leave away   and consider for the next but one major release. JA>  not sure for the moment  

STIX needs to become actionable in a M2M context.  Yes, at some point in the life cycle the CTI will be bubbled up to a Human, and each organization WILL have a different appetite for when that will take place.  Think of all the APPs I want written on the various APP stores... They will all interact with the data at some point.  However, each of the applications will need to do things with the data before it gets on the UI. In regards to Profiles, I can agree in the most general and high level concept.  However, the way profiles are done today, they are effectively un-useable and do not scale. To quote Aharon out of context as he was talking about discovery in TAXII land, it would be nice if profiles in a STIX state machine worked as simply as: EHLO   taxii.example.com VERSION 1.2 STARTTLS 1.2 READY TO STARTTLS We keep hearing profiles, profiles, profiles as the way to solve all the things that are broken.  But I am not sure the bandaid of profiles will hold.  And in fact, profiles will probably need to end up being YACS (yet-another-cit-standard) with its own markup.   I just do not see how profiles are going to really work in code.  I get how they should work in theory and the idea behind them is a great concept.  But they are not a good practical solution, at least not yet.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Sep 21, 2015, at 09:41, Patrick Maroney < Pmaroney@Specere.org > wrote: I will (again) argue for: (1) STIX Profiles   (1.1) human and machine readable   (1.2) Adding declaritive 'simple' form: enumeration of       (1.2.1) these are the 'things' I can consume/produce      (1.2.3) these are the conventions for types of things : e.g. Kill Chain (2) Community consensus on a core set of standard STIX Profiles (e.g: top 10 use cases) Note that this is not an arguement against things like elimination multiple description options, etc.   It is an argument however for avoiding endless debates on which things are important as I posit we will never reach consensus given the diverse set of world views and use cases CTI needs to embrace. Editorial Note: Although we do indeed argue for M2M inter-exchange as the core functional requirement, eventually the data is likely presented to a human where things like Description provide/context value in the end state models/databases/ticketing systems/etc. Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Mon, Sep 21, 2015 at 8:08 AM -0700, Jerome Athias < athiasjerome@gmail.com > wrote: Hi, first for initiating this discussion. While I will comment inline below, (because everything was added, at some point, for a reason or another) without wanting to be the devil's advocate vs KISS; I wonder if we should consider an approach at an higher level. Putting some food on the table: - Should we provide guidance documents (e.g. The preferred Kill_Chain is LM, or It is highly recommended to use the LM Kill Chain, etc.)? or/and - Should we define what is mandatory or optional (in order to reach compliance/compatibility level A, B, C)? or/and - Should we have 2 versions : Minimum required fields (for compliance level A/STIX-basic), Additional advanced fields (for compliance level B/STIX-Gold) (with full support, level C/STIX-Platinum)? 2015-09-21 17:04 GMT+03:00 Grobauer, Bernd < Bernd.Grobauer@siemens.com > : - negate:   Remove -- the use case is mostly academic, but if the   flag is there, it completely changes the semantics of how   the indicator is to be handled and is a real pain for implementation,   even though it is hardly ever used     (Note: as shall be explained below, the 'negate' will not be needed anymore    for building logical expressions of indicators, because we shall throw those    out, too). JA>  I would agree   - Title:   Make the field mandatory, but it may be empty. JA>  +1    - Type:   Remove, if there isn't someone who can come up with a   convincing case in which the field is really useful and where   the intended semantics could not be communicated with   a reference to a COA. JA>  Disagree for now (until we review the Controlled Vocabularies)     - Alternative_ID:   Unsure, probably keep. JA>  keep (advanced) for mapping with internal/proprietary IDs (same as CVE - MS-KB link for VM)     - Description:   - There should be exactly 1 description field (which may be empty).       Yes, this precludes fancy schemes of having different descriptions     for different audiences/access levels, but those should amount     to less than 0.1% of all indicator objects ever to be     produced and thus do not warrant substantial complication of     the standard. JA>  Sensitive regarding internationalization (meantime now it's a 0..n or 1..n, that could be a 1..1 + another OtherDescriptions field for 0..n)       - There should be exactly one text representation, and that should *NOT*     be html on account of security issues with rendering HTML in the     browser. Chose Markdown, RestructuredText or whatever. JA>  not sure for now for the format, need to investigate further     - Short_Description:     Remove: I am tired of receiving indicator objects in which   two or three out of three of the fields title ,   description , short_description   are empty -- one description field should be plenty.     (Besides: everybody keeps telling me that STIX is for   machine-2-machine rather than *-2-human communication, so   why the big fuss about description fields?) JA>  Not for remove, but Potentially could be replaced by Description (as 1..1) + DescriptionOthers as 0..n       - Valid_Time_Proposition:     Timing info for indicators is badly needed, but I have yet to encounter usage   of it. Can we come up with sensible guidelines of how to use the field?   It should only be kept if we can... JA>  Guidance documents... :-) Some could argue we just need that for an Exercise/Test, or/and I personally hate CTI feeds with tons of old/useless IOCs JA>  But could be just an Advanced Field     - IndicatorExpression     In the present specification, this field can either   contain what is essentially a logical formula (codified as a tree)   of indicators or an observable composition.     - Remove logical operations: allow only to reference a list     of indicators that constitute the present indicator.     - If you want to do complicated and/or/not-reasoning about     observable stuff: that is essentially a signature,     so find a signature-language of your choice (including     and/or/not-combinations of CybOX observables, if that     is what works best) and formulate the signature     as a test mechanism.     - For everything else: find a way to encode observable     patterns as simple key-value pairs and include/reference a list     of them here. Should work fine for the majority of     current use-cases. At most, allow a structured list that     groups basic observable patterns (key-value) pairs with     respect to a cybox observable to which they belong.    JA>  Investigate further     - Indicated_TTP:     Use yet-to-be-designed relationship mechanism.   - Kill_Chain_Phases:     Define *ONE* standard STIX kill chain and work with that.   Being able to include alternative models is nice, but   complicates tooling quite a bit ... and, remember, this   is an exchange format, so one common kill-chain model   understood in the same way by everybody will work best. JA>  Guidance (preferred one), Optional/Advanced     - Test Mechanisms     Make this a stand-alone entity/object rather than part   of the Indicator object. As mentioned above: use this also   to communicate more complicate observable patterns expressed in CybOX. JA>  potentially ok     - Likely_Impact.     Remove: I have never encountered it being used and have   a hard time coming up with a convincing use case. JA>  I see interest there for high level/strategy/business point of view (Risk Management: Impact * Likelihood)     - Suggested_COAs:     Use yet-to-be-designed relationship mechanism.   - Handling:     Replace with some new mechanism for marking stuff with   handling information.   - Confidence     Keep: we need a simple way to distinguish high-confidence   from low-confidence indicators.   - Sightings:     Find some other way to do sightings (cf. the discussion on   the mailing list) JA>  Still unresolved I agree     - Related_*: Use yet-to-be-designed relationship mechanism.   - Producer:     Either simplify drastically or better yet, leave away   and consider for the next but one major release. JA>  not sure for the moment   Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Hi, thanks to everybody who responded to my summation as "simpleton's advocate". The reactions have shown, I think, that STIX 2.0 is unlikely to shed much in terms of complexity in comparison to STIX 1.x. The reason is that STIX is made to cover every desirable use case: if an analyst X in an organization Y needs to describe an observable pattern consisting of temporal dependencies in conjunction with logical reasoning, must offer three different descriptions in various mark-up languages and add kill-chain information in his organization's own kill-chain model ... well, he should be able to do so with STIX. I understand that this is desirable, but we must be aware of the fact that it comes at a substantial cost for tooling: creating a tool that can sensibly ingest the *full* standard (an aside: will we actually be able to say what the *full* standard is, since it can be extended with custom vocabularies, embedding of various other standards such as CIQ, OpenIOC, ...) will be beyond any organization that is not in the business of carrying out professional software development. And even for such organizations, it will be a mouthful: after, all, we are creating the mother of all signature/pattern languages (encompassing the capabilities of OpenIOC, Yara, Snort, Arsight Rules, temporal reasoning, etc.) combined with contextual information that can be supplied in an astonishing level of variety. Now, let us take a look at the current level of exchange that is going on. It is likely that I am not privy to the most advanced exchange schemes that are currently operating, but it seems to me that what most organizations are currently after is to be able to associate a handful of indicator types (just lists, no logical let alone temporal reasoning) with useful context in a structured way. They are likely to embrace a technology that allows them to exchange information about relatively simple indicators with useful contextual information that comes always in the same form: one and the same kill-chain (because then they know exactly what to expect and can base automation upon the info), and a single description field rather than possibly several description fields, ...: only with this level of simplicity, they will be able to write tools that understand and interpret all information rather than ignoring or misinterpreting half of it. The argument that lists of indicators are not really CTI is beside the point: you have to support consumers at their current level of operations/capabilities and then extend, rather than present them with a language that is excellent at covering the most complicated use case but extremely cumbersome at doing what they (at least at the time being) really want/need to do. So our answer to this problem may be "profiles" ... we could specify a profile for a simplified STIX that realizes many of the simplifications I had written about in my mail from yesterday (and similar simplifications for the other STIX entities -- I fear the 'indicator' was a rather easy target for simplification) without preventing "full STIX" to support more sophisticated use-cases. Bret writes on the subject of profiles: > We keep hearing profiles, profiles, profiles as the way to solve all > the things that are broken. But I am not sure the bandaid of profiles > will hold. And in fact, profiles will probably need to end up being > YACS (yet-another-cit-standard) with its own markup. I just do not > see how profiles are going to really work in code. I get how they > "should" work in theory and the idea behind them is a great concept. > But they are not a good practical solution, at least not yet. I tend to agree ... I think profiles will only work if the profile can be specified such that it translates into a restricted binding definition, which can then be used as basis for implementations. Or, if such a translation cannot be found, the profile will have to be supported with a binding definition created by hand by modifying the definition of the full binding. Note that a profile will leave a certain level of verbosity: Even if I only allow a single definition in a certain profile, I still would have to say <Definitions> <Definition>foo</Definition> </Definitions> The alternative would be to turn the profile into a simplified binding ... and we are back to multiple bindings. To sum up: I fully understand that CTI is complicated and that a standard that wants to support all relevant use cases and ways of specifying CTI must necessarily also be complicated. At the same time, many organizations would be happy, I think, to receive a possibility to add a limited but very useful amount of contextual information to the rather limited set of indicators they are currently exchanging with other organizations. If all we are going to offer to them is STIX/CybOX of the current complexity with simplifications described in informal profile definitions, then there is a danger that STIX/CybOX will be overtaken and superseded by a standard that will be absolutely primitive in comparison to STIX/CybOX ... but will have met current demand. So, my conclusion, I think, is: since there will be no majority for drastically simplifying STIX/CybOX by throwing away lot's of what has been added over the time for the support of valid use cases: we have to start taking profiles in earnest and work towards the creation of a "simple STIX" profile. The ability to define profiles in a sensible way must therefore be considered when choosing the MTI binding. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT >
Original Message----- > From: Jordan, Bret [ mailto:bret.jordan@bluecoat.com ] > Sent: Montag, 21. September 2015 18:16 > To: Patrick Maroney > Cc: Grobauer, Bernd; Jerome Athias; cti@lists.oasis-open.org > Subject: Re: [cti] Playing the "simpleton's advocate": how much > complexity can we throw overboard? > > STIX needs to become actionable in a M2M context. Yes, at some point > in the life cycle the CTI will be bubbled up to a Human, and each > organization WILL have a different appetite for when that will take > place. Think of all the APPs I want written on the various APP > stores... They will all interact with the data at some point. However, > each of the applications will need to "do" things with the data before > it gets on the UI. > > In regards to Profiles, I can agree in the most general and high level > concept. However, the way profiles are done today, they are > effectively un-useable and do not scale. To quote Aharon out of context > as he was talking about discovery in TAXII land, it would be nice if > profiles in a STIX state machine worked as simply as: > > EHLO taxii.example.com > VERSION 1.2 > STARTTLS > 1.2 READY TO STARTTLS > > > We keep hearing profiles, profiles, profiles as the way to solve all > the things that are broken. But I am not sure the bandaid of profiles > will hold. And in fact, profiles will probably need to end up being > YACS (yet-another-cit-standard) with its own markup. I just do not > see how profiles are going to really work in code. I get how they > "should" work in theory and the idea behind them is a great concept. > But they are not a good practical solution, at least not yet. > > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > > On Sep 21, 2015, at 09:41, Patrick Maroney <Pmaroney@Specere.org> > wrote: > > I will (again) argue for: > > (1) STIX Profiles > > (1.1) human and machine readable > > (1.2) Adding declaritive 'simple' form: enumeration of > > (1.2.1) these are the 'things' I can consume/produce > > (1.2.3) these are the conventions for "types of things": > e.g. Kill Chain > > (2) Community consensus on a core set of standard STIX Profiles > (e.g: top 10 use cases) > > Note that this is not an arguement against things like > elimination multiple description options, etc. It is an argument > however for avoiding endless debates on which "things" are important as > I posit we will never reach consensus given the diverse set of world > views and use cases CTI needs to embrace. > > Editorial Note: Although we do indeed argue for M2M inter- > exchange as the core functional requirement, eventually the data is > likely presented to a human where things like Description > provide/context value in the end state models/databases/ticketing > systems/etc. > > Patrick Maroney > President > Integrated Networking Technologies, Inc. > Desk: (856)983-0001 > Cell: (609)841-5104 > Email: pmaroney@specere.org > > > > > On Mon, Sep 21, 2015 at 8:08 AM -0700, "Jerome Athias" > <athiasjerome@gmail.com> wrote: > > > Hi, > > first for initiating this discussion. > While I will comment inline below, (because everything was added, > at some point, for a reason or another) without wanting to be the > devil's advocate vs KISS; I wonder if we should consider an approach at > an higher level. > Putting some food on the table: > > - Should we provide guidance documents (e.g. The preferred > Kill_Chain is LM, or It is highly recommended to use the LM Kill Chain, > etc.)? > or/and > - Should we define what is mandatory or optional (in order to > reach compliance/compatibility level A, B, C)? > or/and > - Should we have "2 versions": Minimum required fields (for > compliance level A/STIX-basic), Additional advanced fields (for > compliance level B/STIX-Gold) (with full support, level C/STIX- > Platinum)? > > > 2015-09-21 17:04 GMT+03:00 Grobauer, Bernd > <Bernd.Grobauer@siemens.com>: > > > > > - negate: > Remove -- the use case is mostly academic, but if the > flag is there, it completely changes the semantics of how > the indicator is to be handled and is a real pain for > implementation, > even though it is hardly ever used > > (Note: as shall be explained below, the 'negate' will not > be needed anymore > for building logical expressions of indicators, because > we shall throw those > out, too). > > JA> I would agree > > > > - Title: > Make the field mandatory, but it may be empty. > > JA> +1 > > > > - Type: > Remove, if there isn't someone who can come up with a > convincing case in which the field is really useful and > where > the intended semantics could not be communicated with > a reference to a COA. > > JA> Disagree for now (until we review the Controlled > Vocabularies) > > > > > - Alternative_ID: > Unsure, probably keep. > > JA> keep (advanced) for mapping with internal/proprietary IDs > (same as CVE - MS-KB link for VM) > > > > > - Description: > - There should be exactly 1 description field (which may > be empty). > > Yes, this precludes fancy schemes of having different > descriptions > for different audiences/access levels, but those should > amount > to less than 0.1% of all indicator objects ever to be > produced and thus do not warrant substantial > complication of > the standard. > > JA> Sensitive regarding internationalization (meantime now it's > a 0..n or 1..n, that could be a 1..1 + another OtherDescriptions field > for 0..n) > > > > > - There should be exactly one text representation, and > that should *NOT* > be html on account of security issues with rendering > HTML in the > browser. Chose Markdown, RestructuredText or whatever. > > JA> not sure for now for the format, need to investigate further > > > > > > - Short_Description: > > Remove: I am tired of receiving indicator objects in > which > two or three out of three of the fields "title", > "description", "short_description" > are empty -- one description field should be plenty. > > (Besides: everybody keeps telling me that STIX is for > machine-2-machine rather than *-2-human communication, so > why the big fuss about description fields?) > > JA> Not for remove, but Potentially could be replaced by > Description (as 1..1) + DescriptionOthers as 0..n > > > > > > - Valid_Time_Proposition: > > Timing info for indicators is badly needed, but I have > yet to encounter usage > of it. Can we come up with sensible guidelines of how to > use the field? > It should only be kept if we can... > > JA> Guidance documents... :-) Some could argue we just need that > for an Exercise/Test, or/and I personally hate CTI feeds with tons of > old/useless IOCs > JA> But could be just an Advanced Field > > > > > > - IndicatorExpression > > In the present specification, this field can either > contain what is essentially a logical formula (codified > as a tree) > of indicators or an observable composition. > > - Remove logical operations: allow only to reference a > list > of indicators that constitute the present indicator. > > - If you want to do complicated and/or/not-reasoning > about > observable stuff: that is essentially a signature, > so find a signature-language of your choice (including > and/or/not-combinations of CybOX observables, if that > is what works best) and formulate the signature > as a test mechanism. > > - For everything else: find a way to encode observable > patterns as simple key-value pairs and > include/reference a list > of them here. Should work fine for the majority of > current use-cases. At most, allow a structured list > that > groups basic observable patterns (key-value) pairs with > respect to a cybox observable to which they belong. > > JA> Investigate further > > > > > - Indicated_TTP: > > Use yet-to-be-designed relationship mechanism. > > - Kill_Chain_Phases: > > Define *ONE* standard STIX kill chain and work with that. > Being able to include alternative models is nice, but > complicates tooling quite a bit ... and, remember, this > is an exchange format, so one common kill-chain model > understood in the same way by everybody will work best. > > JA> Guidance (preferred one), Optional/Advanced > > > > > - Test Mechanisms > > Make this a stand-alone entity/object rather than part > of the Indicator object. As mentioned above: use this > also > to communicate more complicate observable patterns > expressed in CybOX. > > JA> potentially ok > > > > > - Likely_Impact. > > Remove: I have never encountered it being used and have > a hard time coming up with a convincing use case. > > JA> I see interest there for high level/strategy/business point > of view (Risk Management: Impact * Likelihood) > > > > > - Suggested_COAs: > > Use yet-to-be-designed relationship mechanism. > > - Handling: > > Replace with some new mechanism for marking stuff with > handling information. > > - Confidence > > Keep: we need a simple way to distinguish high-confidence > from low-confidence indicators. > > - Sightings: > > Find some other way to do sightings (cf. the discussion > on > the mailing list) > > JA> Still unresolved I agree > > > > > - Related_*: Use yet-to-be-designed relationship mechanism. > > - Producer: > > Either simplify drastically or better yet, leave away > and consider for the next but one major release. > > JA> not sure for the moment > >

> The reactions have shown, I think, that STIX 2.0 is unlikely to shed much in terms of complexity in comparison to STIX 1.x. I am very much in favor of shedding complexity everywhere we can (though not at the expense of necessary features). I'll use STIX versioning [1] as an example - I think we need versioning, and I think we can probably simplify the current design. That said, I find myself wondering if there are some higher level topics to work through before we get down into the design of specific concepts and fields. Do we all agree on what the top level objects for STIX and the relationships between them should be moving forward? Is that the best question for us to be asking ourselves? Thank you. -Mark [1] http://stixproject.github.io/documentation/concepts/versioning/
Original Message----- From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of Grobauer, Bernd Sent: Tuesday, September 22, 2015 9:13 AM To: bret.jordan@bluecoat.com; Pmaroney@Specere.org Cc: athiasjerome@gmail.com; cti@lists.oasis-open.org Subject: RE: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Hi, thanks to everybody who responded to my summation as "simpleton's advocate". The reactions have shown, I think, that STIX 2.0 is unlikely to shed much in terms of complexity in comparison to STIX 1.x. The reason is that STIX is made to cover every desirable use case: if an analyst X in an organization Y needs to describe an observable pattern consisting of temporal dependencies in conjunction with logical reasoning, must offer three different descriptions in various mark-up languages and add kill-chain information in his organization's own kill-chain model ... well, he should be able to do so with STIX. I understand that this is desirable, but we must be aware of the fact that it comes at a substantial cost for tooling: creating a tool that can sensibly ingest the *full* standard (an aside: will we actually be able to say what the *full* standard is, since it can be extended with custom vocabularies, embedding of various other standards such as CIQ, OpenIOC, ...) will be beyond any organization that is not in the business of carrying out professional software development. And even for such organizations, it will be a mouthful: after, all, we are creating the mother of all signature/pattern languages (encompassing the capabilities of OpenIOC, Yara, Snort, Arsight Rules, temporal reasoning, etc.) combined with contextual information that can be supplied in an astonishing level of variety. Now, let us take a look at the current level of exchange that is going on. It is likely that I am not privy to the most advanced exchange schemes that are currently operating, but it seems to me that what most organizations are currently after is to be able to associate a handful of indicator types (just lists, no logical let alone temporal reasoning) with useful context in a structured way. They are likely to embrace a technology that allows them to exchange information about relatively simple indicators with useful contextual information that comes always in the same form: one and the same kill-chain (because then they know exactly what to expect and can base automation upon the info), and a single description field rather than possibly several description fields, ...: only with this level of simplicity, they will be able to write tools that understand and interpret all information rather than ignoring or misinterpreting half of it. The argument that lists of indicators are not really CTI is beside the point: you have to support consumers at their current level of operations/capabilities and then extend, rather than present them with a language that is excellent at covering the most complicated use case but extremely cumbersome at doing what they (at least at the time being) really want/need to do. So our answer to this problem may be "profiles" ... we could specify a profile for a simplified STIX that realizes many of the simplifications I had written about in my mail from yesterday (and similar simplifications for the other STIX entities -- I fear the 'indicator' was a rather easy target for simplification) without preventing "full STIX" to support more sophisticated use-cases. Bret writes on the subject of profiles: > We keep hearing profiles, profiles, profiles as the way to solve all > the things that are broken. But I am not sure the bandaid of profiles > will hold. And in fact, profiles will probably need to end up being > YACS (yet-another-cit-standard) with its own markup. I just do not > see how profiles are going to really work in code. I get how they > "should" work in theory and the idea behind them is a great concept. > But they are not a good practical solution, at least not yet. I tend to agree ... I think profiles will only work if the profile can be specified such that it translates into a restricted binding definition, which can then be used as basis for implementations. Or, if such a translation cannot be found, the profile will have to be supported with a binding definition created by hand by modifying the definition of the full binding. Note that a profile will leave a certain level of verbosity: Even if I only allow a single definition in a certain profile, I still would have to say <Definitions> <Definition>foo</Definition> </Definitions> The alternative would be to turn the profile into a simplified binding ... and we are back to multiple bindings. To sum up: I fully understand that CTI is complicated and that a standard that wants to support all relevant use cases and ways of specifying CTI must necessarily also be complicated. At the same time, many organizations would be happy, I think, to receive a possibility to add a limited but very useful amount of contextual information to the rather limited set of indicators they are currently exchanging with other organizations. If all we are going to offer to them is STIX/CybOX of the current complexity with simplifications described in informal profile definitions, then there is a danger that STIX/CybOX will be overtaken and superseded by a standard that will be absolutely primitive in comparison to STIX/CybOX ... but will have met current demand. So, my conclusion, I think, is: since there will be no majority for drastically simplifying STIX/CybOX by throwing away lot's of what has been added over the time for the support of valid use cases: we have to start taking profiles in earnest and work towards the creation of a "simple STIX" profile. The ability to define profiles in a sensible way must therefore be considered when choosing the MTI binding. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT

In product design you would ask, where do you think you will get the most traction or said another way, what do the vast majority of people need today and how can we make their lives easier..  Then you figure out how to do that really well and really easy.  Then you iterate over time and add more, little by little.   In the world as I see it, for the next 3-5 years we can expect the majority of organizations, products, tools, and solutions to share IOCs and some level of extra context around them.  Things like sightings, assertions on relationships, and maybe if we are lucky, some TTP level stuff.  There will always be groups that are more advanced, or as I call it, have a higher level of maturity.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Sep 22, 2015, at 08:10, Davidson II, Mark S < mdavidson@MITRE.ORG > wrote: The reactions have shown, I think, that STIX 2.0 is unlikely to shed much in terms of complexity in comparison to STIX 1.x. I am very much in favor of shedding complexity everywhere we can (though not at the expense of necessary features). I'll use STIX versioning [1] as an example - I think we need versioning, and I think we can probably simplify the current design. That said, I find myself wondering if there are some higher level topics to work through before we get down into the design of specific concepts and fields. Do we all agree on what the top level objects for STIX and the relationships between them should be moving forward? Is that the best question for us to be asking ourselves? Thank you. -Mark [1] http://stixproject.github.io/documentation/concepts/versioning/
Original Message----- From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of Grobauer, Bernd Sent: Tuesday, September 22, 2015 9:13 AM To: bret.jordan@bluecoat.com ; Pmaroney@Specere.org Cc: athiasjerome@gmail.com ; cti@lists.oasis-open.org Subject: RE: [cti] Playing the simpleton's advocate : how much complexity can we throw overboard? Hi, thanks to everybody who responded to my summation as simpleton's advocate . The reactions have shown, I think, that STIX 2.0 is unlikely to shed much in terms of complexity in comparison to STIX 1.x. The reason is that STIX is made to cover every desirable use case: if an analyst X in an organization Y needs to describe an observable pattern consisting of temporal dependencies in conjunction with logical reasoning, must offer three different descriptions in various mark-up languages and add kill-chain information in his organization's own kill-chain model ... well, he should be able to do so with STIX. I understand that this is desirable, but we must be aware of the fact that it comes at a substantial cost for tooling: creating a tool that can sensibly ingest the *full* standard (an aside: will we actually be able to say what the *full* standard is, since it can be extended with custom vocabularies, embedding of various other standards such as CIQ, OpenIOC, ...) will be beyond any organization that is not in the business of carrying out professional software development. And even for such organizations, it will be a mouthful: after, all, we are creating the mother of all signature/pattern languages (encompassing the capabilities of OpenIOC, Yara, Snort, Arsight Rules, temporal reasoning, etc.) combined with contextual information that can be supplied in an astonishing level of variety. Now, let us take a look at the current level of exchange that is going on. It is likely that I am not privy to the most advanced exchange schemes that are currently operating, but it seems to me that what most organizations are currently after is to be able to associate a handful of indicator types (just lists, no logical let alone temporal reasoning) with useful context in a structured way. They are likely to embrace a technology that allows them to exchange information about relatively simple indicators with useful contextual information that comes always in the same form: one and the same kill-chain (because then they know exactly what to expect and can base automation upon the info), and a single description field rather than possibly several description fields, ...: only with this level of simplicity, they will be able to write tools that understand and interpret all information rather than ignoring or misinterpreting half of it. The argument that lists of indicators are not really CTI is beside the point: you have to support consumers at their current level of operations/capabilities and then extend, rather than present them with a language that is excellent at covering the most complicated use case but extremely cumbersome at doing what they (at least at the time being) really want/need to do. So our answer to this problem may be profiles ...  we could specify a profile for a simplified STIX that realizes many of the simplifications I had written about in my mail from yesterday (and similar simplifications for the other STIX entities -- I fear the 'indicator' was a rather easy target for simplification) without preventing full STIX to support more sophisticated use-cases. Bret writes on the subject of profiles: We keep hearing profiles, profiles, profiles as the way to solve all the things that are broken.  But I am not sure the bandaid of profiles will hold.  And in fact, profiles will probably need to end up being YACS (yet-another-cit-standard) with its own markup.  I just do not see how profiles are going to really work in code.  I get how they should work in theory and the idea behind them is a great concept. But they are not a good practical solution, at least not yet. I tend to agree ... I think profiles will only work if the profile can be specified such that it translates into a restricted binding definition, which can then be used as basis for implementations. Or, if such a translation cannot be found, the profile will have to be supported with a binding definition created by hand by modifying the definition of the full binding. Note that a profile will leave a certain level of verbosity: Even if I only allow a single definition in a certain profile, I still would have to say  <Definitions>   <Definition>foo</Definition>  </Definitions> The alternative would be to turn the profile into a simplified binding ... and we are back to multiple bindings. To sum up: I fully understand that CTI is complicated and that a standard that wants to support all relevant use cases and ways of specifying CTI must necessarily also be complicated. At the same time, many organizations would be happy, I think, to receive a possibility to add a limited but very useful amount of contextual information to the rather limited set of indicators they are currently exchanging with other organizations. If all we are going to offer to them is STIX/CybOX of the current complexity with simplifications described in informal profile definitions, then there is a danger that STIX/CybOX will be overtaken and superseded by a standard that will be absolutely primitive in comparison to STIX/CybOX ... but will have met current demand. So, my conclusion, I think, is: since there will be no majority for drastically simplifying STIX/CybOX by throwing away lot's of what has been added over the time for the support of valid use cases: we have to start taking profiles in earnest and work towards the creation of a simple STIX profile. The ability to define profiles in a sensible way must therefore be considered when choosing the MTI binding. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Well said.  What some have asked for is a STIX-Lite.  And there is a few projects that are attempting to do that and one could argue that Facebook's ThreatExchange is an attempt at that.  Google is your friend to find the STIX-Lite projects.  The only way I really see profiles working is if their is a simple negotiation protocol, and maybe it is done in TAXII where you say. 1) I support STIX-Lite or  2) I support STIX-Medium or  3) I support STIX-Full If we did this we would need to make sure the APIs for STIX-Lite are robust enough that if someone sends them more than they can deal with, they can silently just throw it away.  This would also shift the cost or burden to the STIX-Full people to figure out what they can send and not send.  So the people that are most interested in sharing advanced CTI will have the most work to do in code.   The other problem I see with profiles is if there is an infinite number of possibilities.  Then the problem is now even harder to solve. In conclusion we have to be careful that we do not make STIX and CybOX so complex that it only works for the small minority of groups that want to share the most advanced forms of CTI.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Sep 22, 2015, at 07:13, Grobauer, Bernd < Bernd.Grobauer@siemens.com > wrote: Hi, thanks to everybody who responded to my summation as simpleton's advocate . The reactions have shown, I think, that STIX 2.0 is unlikely to shed much in terms of complexity in comparison to STIX 1.x. The reason is that STIX is made to cover every desirable use case: if an analyst X in an organization Y needs to describe an observable pattern consisting of temporal dependencies in conjunction with logical reasoning, must offer three different descriptions in various mark-up languages and add kill-chain information in his organization's own kill-chain model ... well, he should be able to do so with STIX. I understand that this is desirable, but we must be aware of the fact that it comes at a substantial cost for tooling: creating a tool that can sensibly ingest the *full* standard (an aside: will we actually be able to say what the *full* standard is, since it can be extended with custom vocabularies, embedding of various other standards such as CIQ, OpenIOC, ...) will be beyond any organization that is not in the business of carrying out professional software development. And even for such organizations, it will be a mouthful: after, all, we are creating the mother of all signature/pattern languages (encompassing the capabilities of OpenIOC, Yara, Snort, Arsight Rules, temporal reasoning, etc.) combined with contextual information that can be supplied in an astonishing level of variety. Now, let us take a look at the current level of exchange that is going on. It is likely that I am not privy to the most advanced exchange schemes that are currently operating, but it seems to me that what most organizations are currently after is to be able to associate a handful of indicator types (just lists, no logical let alone temporal reasoning) with useful context in a structured way. They are likely to embrace a technology that allows them to exchange information about relatively simple indicators with useful contextual information that comes always in the same form: one and the same kill-chain (because then they know exactly what to expect and can base automation upon the info), and a single description field rather than possibly several description fields, ...: only with this level of simplicity, they will be able to write tools that understand and interpret all information rather than ignoring or misinterpreting half of it. The argument that lists of indicators are not really CTI is beside the point: you have to support consumers at their current level of operations/capabilities and then extend, rather than present them with a language that is excellent at covering the most complicated use case but extremely cumbersome at doing what they (at least at the time being) really want/need to do. So our answer to this problem may be profiles ...  we could specify a profile for a simplified STIX that realizes many of the simplifications I had written about in my mail from yesterday (and similar simplifications for the other STIX entities -- I fear the 'indicator' was a rather easy target for simplification) without preventing full STIX to support more sophisticated use-cases. Bret writes on the subject of profiles: We keep hearing profiles, profiles, profiles as the way to solve all the things that are broken.  But I am not sure the bandaid of profiles will hold.  And in fact, profiles will probably need to end up being YACS (yet-another-cit-standard) with its own markup.  I just do not see how profiles are going to really work in code.  I get how they should work in theory and the idea behind them is a great concept. But they are not a good practical solution, at least not yet. I tend to agree ... I think profiles will only work if the profile can be specified such that it translates into a restricted binding definition, which can then be used as basis for implementations. Or, if such a translation cannot be found, the profile will have to be supported with a binding definition created by hand by modifying the definition of the full binding. Note that a profile will leave a certain level of verbosity: Even if I only allow a single definition in a certain profile, I still would have to say  <Definitions>   <Definition>foo</Definition>  </Definitions> The alternative would be to turn the profile into a simplified binding ... and we are back to multiple bindings. To sum up: I fully understand that CTI is complicated and that a standard that wants to support all relevant use cases and ways of specifying CTI must necessarily also be complicated. At the same time, many organizations would be happy, I think, to receive a possibility to add a limited but very useful amount of contextual information to the rather limited set of indicators they are currently exchanging with other organizations. If all we are going to offer to them is STIX/CybOX of the current complexity with simplifications described in informal profile definitions, then there is a danger that STIX/CybOX will be overtaken and superseded by a standard that will be absolutely primitive in comparison to STIX/CybOX ... but will have met current demand. So, my conclusion, I think, is: since there will be no majority for drastically simplifying STIX/CybOX by throwing away lot's of what has been added over the time for the support of valid use cases: we have to start taking profiles in earnest and work towards the creation of a simple STIX profile. The ability to define profiles in a sensible way must therefore be considered when choosing the MTI binding. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT
Original Message----- From: Jordan, Bret [ mailto:bret.jordan@bluecoat.com ] Sent: Montag, 21. September 2015 18:16 To: Patrick Maroney Cc: Grobauer, Bernd; Jerome Athias; cti@lists.oasis-open.org Subject: Re: [cti] Playing the simpleton's advocate : how much complexity can we throw overboard? STIX needs to become actionable in a M2M context.  Yes, at some point in the life cycle the CTI will be bubbled up to a Human, and each organization WILL have a different appetite for when that will take place.  Think of all the APPs I want written on the various APP stores... They will all interact with the data at some point.  However, each of the applications will need to do things with the data before it gets on the UI. In regards to Profiles, I can agree in the most general and high level concept.  However, the way profiles are done today, they are effectively un-useable and do not scale. To quote Aharon out of context as he was talking about discovery in TAXII land, it would be nice if profiles in a STIX state machine worked as simply as: EHLO taxii.example.com VERSION 1.2 STARTTLS 1.2 READY TO STARTTLS We keep hearing profiles, profiles, profiles as the way to solve all the things that are broken.  But I am not sure the bandaid of profiles will hold.  And in fact, profiles will probably need to end up being YACS (yet-another-cit-standard) with its own markup.   I just do not see how profiles are going to really work in code.  I get how they should work in theory and the idea behind them is a great concept. But they are not a good practical solution, at least not yet. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.      On Sep 21, 2015, at 09:41, Patrick Maroney < Pmaroney@Specere.org > wrote:      I will (again) argue for:      (1) STIX Profiles        (1.1) human and machine readable        (1.2) Adding declaritive 'simple' form: enumeration of           (1.2.1) these are the 'things' I can consume/produce           (1.2.3) these are the conventions for types of things : e.g. Kill Chain      (2) Community consensus on a core set of standard STIX Profiles (e.g: top 10 use cases)      Note that this is not an arguement against things like elimination multiple description options, etc.   It is an argument however for avoiding endless debates on which things are important as I posit we will never reach consensus given the diverse set of world views and use cases CTI needs to embrace.      Editorial Note: Although we do indeed argue for M2M inter- exchange as the core functional requirement, eventually the data is likely presented to a human where things like Description provide/context value in the end state models/databases/ticketing systems/etc.      Patrick Maroney      President      Integrated Networking Technologies, Inc.      Desk: (856)983-0001      Cell: (609)841-5104      Email: pmaroney@specere.org      On Mon, Sep 21, 2015 at 8:08 AM -0700, Jerome Athias < athiasjerome@gmail.com > wrote:      Hi,      first for initiating this discussion.      While I will comment inline below, (because everything was added, at some point, for a reason or another) without wanting to be the devil's advocate vs KISS; I wonder if we should consider an approach at an higher level.      Putting some food on the table:      - Should we provide guidance documents (e.g. The preferred Kill_Chain is LM, or It is highly recommended to use the LM Kill Chain, etc.)?      or/and      - Should we define what is mandatory or optional (in order to reach compliance/compatibility level A, B, C)?      or/and      - Should we have 2 versions : Minimum required fields (for compliance level A/STIX-basic), Additional advanced fields (for compliance level B/STIX-Gold) (with full support, level C/STIX- Platinum)?      2015-09-21 17:04 GMT+03:00 Grobauer, Bernd < Bernd.Grobauer@siemens.com >:              - negate:                Remove -- the use case is mostly academic, but if the                flag is there, it completely changes the semantics of how                the indicator is to be handled and is a real pain for implementation,                even though it is hardly ever used                (Note: as shall be explained below, the 'negate' will not be needed anymore                 for building logical expressions of indicators, because we shall throw those                 out, too).      JA>  I would agree              - Title:                Make the field mandatory, but it may be empty.      JA>  +1              - Type:                Remove, if there isn't someone who can come up with a                convincing case in which the field is really useful and where                the intended semantics could not be communicated with                a reference to a COA.      JA>  Disagree for now (until we review the Controlled Vocabularies)              - Alternative_ID:                Unsure, probably keep.      JA>  keep (advanced) for mapping with internal/proprietary IDs (same as CVE - MS-KB link for VM)              - Description:                - There should be exactly 1 description field (which may be empty).                  Yes, this precludes fancy schemes of having different descriptions                  for different audiences/access levels, but those should amount                  to less than 0.1% of all indicator objects ever to be                  produced and thus do not warrant substantial complication of                  the standard.      JA>  Sensitive regarding internationalization (meantime now it's a 0..n or 1..n, that could be a 1..1 + another OtherDescriptions field for 0..n)                - There should be exactly one text representation, and that should *NOT*                  be html on account of security issues with rendering HTML in the                  browser. Chose Markdown, RestructuredText or whatever.      JA>  not sure for now for the format, need to investigate further              - Short_Description:                Remove: I am tired of receiving indicator objects in which                two or three out of three of the fields title ,                 description , short_description                are empty -- one description field should be plenty.                (Besides: everybody keeps telling me that STIX is for                machine-2-machine rather than *-2-human communication, so                why the big fuss about description fields?)      JA>  Not for remove, but Potentially could be replaced by Description (as 1..1) + DescriptionOthers as 0..n              - Valid_Time_Proposition:                Timing info for indicators is badly needed, but I have yet to encounter usage                of it. Can we come up with sensible guidelines of how to use the field?                It should only be kept if we can...      JA>  Guidance documents... :-) Some could argue we just need that for an Exercise/Test, or/and I personally hate CTI feeds with tons of old/useless IOCs      JA>  But could be just an Advanced Field              - IndicatorExpression                In the present specification, this field can either                contain what is essentially a logical formula (codified as a tree)                of indicators or an observable composition.                - Remove logical operations: allow only to reference a list                  of indicators that constitute the present indicator.                - If you want to do complicated and/or/not-reasoning about                  observable stuff: that is essentially a signature,                  so find a signature-language of your choice (including                  and/or/not-combinations of CybOX observables, if that                  is what works best) and formulate the signature                  as a test mechanism.                - For everything else: find a way to encode observable                  patterns as simple key-value pairs and include/reference a list                  of them here. Should work fine for the majority of                  current use-cases. At most, allow a structured list that                  groups basic observable patterns (key-value) pairs with                  respect to a cybox observable to which they belong.      JA>  Investigate further              - Indicated_TTP:                Use yet-to-be-designed relationship mechanism.              - Kill_Chain_Phases:                Define *ONE* standard STIX kill chain and work with that.                Being able to include alternative models is nice, but                complicates tooling quite a bit ... and, remember, this                is an exchange format, so one common kill-chain model                understood in the same way by everybody will work best.      JA>  Guidance (preferred one), Optional/Advanced              - Test Mechanisms                Make this a stand-alone entity/object rather than part                of the Indicator object. As mentioned above: use this also                to communicate more complicate observable patterns expressed in CybOX.      JA>  potentially ok              - Likely_Impact.                Remove: I have never encountered it being used and have                a hard time coming up with a convincing use case.      JA>  I see interest there for high level/strategy/business point of view (Risk Management: Impact * Likelihood)              - Suggested_COAs:                Use yet-to-be-designed relationship mechanism.              - Handling:                Replace with some new mechanism for marking stuff with                handling information.              - Confidence                Keep: we need a simple way to distinguish high-confidence                from low-confidence indicators.              - Sightings:                Find some other way to do sightings (cf. the discussion on                the mailing list)      JA>  Still unresolved I agree              - Related_*: Use yet-to-be-designed relationship mechanism.              - Producer:                Either simplify drastically or better yet, leave away                and consider for the next but one major release.      JA>  not sure for the moment Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From: "Grobauer, Bernd" <Bernd.Grobauer@siemens.com> To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date: 09/21/2015 12:07 PM Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Sent by: <cti@lists.oasis-open.org> Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf Let me propose the following simplifications: - version: Keep. - negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw those out, too). - Title: Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep. - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields "title", "description", "short_description" are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism. - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs: Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings: Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer: Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT

On these two points. It hard to understate how often this kind of 'complexity' is required to describe things correctly.  I know in the early days of sharing CTI via CSV files it was very common to have data that while was correct lacked the conditions to be accurately used as CTI due to the lack of structure and sequence of events.  Here is a very simple example.   Lets say you are doing analysis on malware and find that the infection starts uses a dropper hosted at evil2015.com and when the malware successfully installs on a victim host its checks to see if it in Internet accessible location by reaching out to innocuous domain like say www.google.com  or download.microsoft.com. So if you loose the sequence here and just query all your proxy logs for all three of the domains you will get tons of results that are useless, but not wrong.  If the CTI data was instrumented to say evil2015.com and then one of these two from the same host shortly there after is a high probability of an infected machine.  You don't know that from just having a host reach the evil2015.com domain. Including these these the innocuous domains in the CTI data is useful for both the COA side but also developing TTPs of Threat Actors as some pick particular hosts to validate Internet access and it is more valid indicative data about who might be on the far end of the keyboard.  (Yes it is not any where enough, but bread crumb trails are that way...) 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 Jason Keirstead <Jason.Keirstead@ca.ibm.com> Sent: Monday, September 21, 2015 11:29 AM To: Grobauer, Bernd Cc: cti@lists.oasis-open.org Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard?   I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From: "Grobauer, Bernd" <Bernd.Grobauer@siemens.com> To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date: 09/21/2015 12:07 PM Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Sent by: <cti@lists.oasis-open.org> Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf Let me propose the following simplifications: - version: Keep. - negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw those out, too). - Title: Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep. - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields "title", "description", "short_description" are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism. - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs: Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings: Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer: Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT

You just need to add the time element in the sequence.  Something happened, then some defined time later this other thing happens, them some system or network checks were made, then some other thing happen within a defined time frame.   The act of downloading a PDF for example, is not always bad.  But a PDF downloaded to a machine, followed by the download of three EXE files within 45 seconds, and the opening of a new outbound encrypted session, usually means it is not going to be a good day. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Sep 21, 2015, at 09:44, Mark Clancy < mclancy@soltra.com > wrote: On these two points. It hard to understate how often this kind of 'complexity' is required to describe things correctly.  I know in the early days of sharing CTI via CSV files it was very common to have data that while was correct lacked the conditions to be accurately used as CTI due to the lack of structure and sequence of events.  Here is a very simple example.   Lets say you are doing analysis on malware and find that the infection starts uses a dropper hosted at  evil2015.com   and when the malware successfully installs on a victim host its checks to see if it in Internet accessible location by reaching out to innocuous domain like say   www.google.com  or   download.microsoft.com . So if you loose the sequence here and just query all your proxy logs for all three of the domains you will get tons of results that are useless, but not wrong.  If the CTI data was instrumented to say   evil2015.com   and then one of these two from the same host shortly there after is a high probability of an infected machine.  You don't know that from just having a host reach the   evil2015.com   domain. Including these these the innocuous domains in the CTI data is useful for both the COA side but also developing TTPs of Threat Actors as some pick particular hosts to validate Internet access and it is more valid indicative data about who might be on the far end of the keyboard.  (Yes it is not any where enough, but bread crumb trails are that way...) 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 Jason Keirstead < Jason.Keirstead@ca.ibm.com > Sent:   Monday, September 21, 2015 11:29 AM To:   Grobauer, Bernd Cc:   cti@lists.oasis-open.org Subject:   Re: [cti] Playing the simpleton's advocate : how much complexity can we throw overboard?   I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329   ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security     www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown   Grobauer, Bernd ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From:   Grobauer, Bernd < Bernd.Grobauer@siemens.com > To:   cti@lists.oasis-open.org < cti@lists.oasis-open.org > Date:   09/21/2015 12:07 PM Subject:   [cti] Playing the simpleton's advocate : how much complexity can we throw overboard? Sent by:   < cti@lists.oasis-open.org > Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification.   So, as an experiment, below I will go through the 'Indicator'   entity and propose changes. Here I will try to take the side of   as simple as simple can be , be the simpleton's advocate, so   to speak, in the hope of getting some discussion going regarding   what is maybe too simplistic vs what kind of complexity we might   be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf Let me propose the following simplifications: - version:   Keep. - negate:   Remove -- the use case is mostly academic, but if the   flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore   for building logical expressions of indicators, because we shall throw those out, too). - Title:   Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a   convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep.   - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be   produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields title ,   description , short_description are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for   machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism.   - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong.   - Indicated_TTP:   Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also   to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs:   Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings:   Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer:   Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Well said. I think people often see complexity and immediately assume that it is STIX that is introducing this complexity when in reality it is a property of the domain which STIX is supporting. The CTI domain, the use cases it involves and the sorts of information that must be represented are all quite complex beasts. Wishing it were more simple does not make it more simple. We need to remember that a vendor sending out a list of IP Address or domain Indicators, while a valid STIX use case, is a tiny fraction of the CTI domain use case space. Spending time talking with cyber threat analysts can be very enlightening to understand the real-world complexity of the CTI space. sean From: < cti@lists.oasis-open.org > on behalf of Mark Clancy < mclancy@soltra.com > Date: Monday, September 21, 2015 at 11:44 AM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Bernd Grobauer < Bernd.Grobauer@siemens.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? On these two points. It hard to understate how often this kind of 'complexity' is required to describe things correctly.  I know in the early days of sharing CTI via CSV files it was very common to have data that while was correct lacked the conditions to be accurately used as CTI due to the lack of structure and sequence of events.  Here is a very simple example.   Lets say you are doing analysis on malware and find that the infection starts uses a dropper hosted at evil2015.com and when the malware successfully installs on a victim host its checks to see if it in Internet accessible location by reaching out to innocuous domain like say www.google.com  or download.microsoft.com. So if you loose the sequence here and just query all your proxy logs for all three of the domains you will get tons of results that are useless, but not wrong.  If the CTI data was instrumented to say evil2015.com and then one of these two from the same host shortly there after is a high probability of an infected machine.  You don't know that from just having a host reach the evil2015.com domain. Including these these the innocuous domains in the CTI data is useful for both the COA side but also developing TTPs of Threat Actors as some pick particular hosts to validate Internet access and it is more valid indicative data about who might be on the far end of the keyboard.  (Yes it is not any where enough, but bread crumb trails are that way...) 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 Jason Keirstead < Jason.Keirstead@ca.ibm.com > Sent: Monday, September 21, 2015 11:29 AM To: Grobauer, Bernd Cc: cti@lists.oasis-open.org Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard?   I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com > To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Date: 09/21/2015 12:07 PM Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Sent by: < cti@lists.oasis-open.org > Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf Let me propose the following simplifications: - version: Keep. - negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw those out, too). - Title: Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep. - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields "title", "description", "short_description" are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism. - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs: Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings: Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer: Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT

Can we split this thread and relaunch the thread related to the sequence/timing of (events) Observables to tackle your two previous examples Also suggest to track this under a ticket # Example: Observable A 5 or more times     followed by  Observable B 1 or more times .. All Within 5 minutes We should maybe embed these Observables in a new class 'Observation' (basically a SIEM rule, or query for analysts) 2015-09-21 18:44 GMT+03:00 Mark Clancy < mclancy@soltra.com > : On these two points. It hard to understate how often this kind of 'complexity' is required to describe things correctly.  I know in the early days of sharing CTI via CSV files it was very common to have data that while was correct lacked the conditions to be accurately used as CTI due to the lack of structure and sequence of events.  Here is a very simple example.   Lets say you are doing analysis on malware and find that the infection starts uses a dropper hosted at  evil2015.com and when the malware successfully installs on a victim host its checks to see if it in Internet accessible location by reaching out to innocuous domain like say www.google.com  or download.microsoft.com . So if you loose the sequence here and just query all your proxy logs for all three of the domains you will get tons of results that are useless, but not wrong.  If the CTI data was instrumented to say evil2015.com and then one of these two from the same host shortly there after is a high probability of an infected machine.  You don't know that from just having a host reach the evil2015.com domain. Including these these the innocuous domains in the CTI data is useful for both the COA side but also developing TTPs of Threat Actors as some pick particular hosts to validate Internet access and it is more valid indicative data about who might be on the far end of the keyboard.  (Yes it is not any where enough, but bread crumb trails are that way...) 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 Jason Keirstead < Jason.Keirstead@ca.ibm.com > Sent: Monday, September 21, 2015 11:29 AM To: Grobauer, Bernd Cc: cti@lists.oasis-open.org Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard?   I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com > To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Date: 09/21/2015 12:07 PM Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Sent by: < cti@lists.oasis-open.org > Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf Let me propose the following simplifications: - version: Keep. - negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw those out, too). - Title: Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep. - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields "title", "description", "short_description" are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism. - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs: Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings: Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer: Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT

So Jason, how do we do those things in a more sane manner and give more expressiveness so you can meet your needs.  I would like to make sure it is simple to understand and easy to use but also allows for rich expressiveness.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Sep 21, 2015, at 09:29, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Grobauer, Bernd ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From: Grobauer, Bernd < Bernd.Grobauer@siemens.com > To: cti@lists.oasis-open.org < cti@lists.oasis-open.org > Date: 09/21/2015 12:07 PM Subject: [cti] Playing the simpleton's advocate : how much complexity can we throw overboard? Sent by: < cti@lists.oasis-open.org > Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of as simple as simple can be , be the simpleton's advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf <09226000.jpg> Let me propose the following simplifications: - version: Keep. - negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw those out, too). - Title: Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep. - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields title , description , short_description are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism. - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs: Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings: Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer: Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

So.. part of the reason it is so complex is that we are trying to re-implement what is essentially a rule language. If we actually *had* a real rule language, instead of all of these XML constructs, then we could simply use this language. Imagine how much simpler Observables would be if we could do something like this <observable> ( DestinationPort = 80 AND Protocol = "TCP" AND MD5Hash = 3453927402957 ) FollowedBy ( RegistryKey = "HKEY_CURRENT_USERlah...." ) FollowedBy (ProcessName = "Foobar.exe" ) </observable> Taking this and turning it into CybOX would result in likely 2 dozen lines of XML. IE... what makes the whole thing so complicated is we're trying to disil a rule language into XML tags. I don't know what an answer is that doesn't involve "reinvent CybOX from the ground up", but that is the problem. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Jordan, Bret" ---09/21/2015 01:37:50 PM---So Jason, how do we do those things in a more sane manner and give more expressiveness so you can me From: "Jordan, Bret" <bret.jordan@bluecoat.com> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Grobauer, Bernd" <Bernd.Grobauer@siemens.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date: 09/21/2015 01:37 PM Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? So Jason, how do we do those things in a more sane manner and give more expressiveness so you can meet your needs. I would like to make sure it is simple to understand and easy to use but also allows for rich expressiveness. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." On Sep 21, 2015, at 09:29, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> "Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com > To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Date: 09/21/2015 12:07 PM Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Sent by: < cti@lists.oasis-open.org > Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf <09226000.jpg> Let me propose the following simplifications: - version: Keep. - negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw those out, too). - Title: Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep. - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields "title", "description", "short_description" are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism. - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs: Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings: Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer: Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

from a semantic point of view, I would say that Observables should be used to describe an Observation (not embedding it) From an interoperability point of view, for sure that would be great to have a unique language for IDS/IPS and SIEM ('correlation') rules. Coming back to CybOX/STIX (ref. the new thread), the only missing part of your example is the " FollowedBy", if I trust my memory 2015-09-21 21:12 GMT+03:00 Jason Keirstead < Jason.Keirstead@ca.ibm.com > : So.. part of the reason it is so complex is that we are trying to re-implement what is essentially a rule language. If we actually *had* a real rule language, instead of all of these XML constructs, then we could simply use this language. Imagine how much simpler Observables would be if we could do something like this <observable> ( DestinationPort = 80 AND Protocol = "TCP" AND MD5Hash = 3453927402957 ) FollowedBy ( RegistryKey = "HKEY_CURRENT_USERlah...." ) FollowedBy (ProcessName = "Foobar.exe" ) </observable> Taking this and turning it into CybOX would result in likely 2 dozen lines of XML. IE... what makes the whole thing so complicated is we're trying to disil a rule language into XML tags. I don't know what an answer is that doesn't involve "reinvent CybOX from the ground up", but that is the problem. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Jordan, Bret" ---09/21/2015 01:37:50 PM---So Jason, how do we do those things in a more sane manner and give more expressiveness so you can me From: "Jordan, Bret" < bret.jordan@bluecoat.com > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Date: 09/21/2015 01:37 PM Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? So Jason, how do we do those things in a more sane manner and give more expressiveness so you can meet your needs. I would like to make sure it is simple to understand and easy to use but also allows for rich expressiveness. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." On Sep 21, 2015, at 09:29, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> "Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com > To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Date: 09/21/2015 12:07 PM Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Sent by: < cti@lists.oasis-open.org > Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf <09226000.jpg> Let me propose the following simplifications: - version: Keep. - negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw those out, too). - Title: Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep. - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields "title", "description", "short_description" are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism. - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs: Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings: Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer: Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

Definitely agree on the fundamental needs for the composition capabilities based on input from CTI analysts. sean From: < cti@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Monday, September 21, 2015 at 11:29 AM To: Bernd Grobauer < Bernd.Grobauer@siemens.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? I agree with most parts of this, but not all. Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ). We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better. If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com > To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Date: 09/21/2015 12:07 PM Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Sent by: < cti@lists.oasis-open.org > Hi, stepping back from the choice of binding for a moment, I would like to explore a bit, how much the next major version of STIX might differ from what we have today in terms of simplification. So, as an experiment, below I will go through the 'Indicator' entity and propose changes. Here I will try to take the side of "as simple as simple can be", be the "simpleton's" advocate, so to speak, in the hope of getting some discussion going regarding what is maybe too simplistic vs what kind of complexity we might be able to throw over board. Here is the overview of the indicator entity/concept taken from page 13 of https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf Let me propose the following simplifications: - version: Keep. - negate: Remove -- the use case is mostly academic, but if the flag is there, it completely changes the semantics of how the indicator is to be handled and is a real pain for implementation, even though it is hardly ever used (Note: as shall be explained below, the 'negate' will not be needed anymore for building logical expressions of indicators, because we shall throw those out, too). - Title: Make the field mandatory, but it may be empty. - Type: Remove, if there isn't someone who can come up with a convincing case in which the field is really useful and where the intended semantics could not be communicated with a reference to a COA. - Alternative_ID: Unsure, probably keep. - Description: - There should be exactly 1 description field (which may be empty). Yes, this precludes fancy schemes of having different descriptions for different audiences/access levels, but those should amount to less than 0.1% of all indicator objects ever to be produced and thus do not warrant substantial complication of the standard. - There should be exactly one text representation, and that should *NOT* be html on account of security issues with rendering HTML in the browser. Chose Markdown, RestructuredText or whatever. - Short_Description: Remove: I am tired of receiving indicator objects in which two or three out of three of the fields "title", "description", "short_description" are empty -- one description field should be plenty. (Besides: everybody keeps telling me that STIX is for machine-2-machine rather than *-2-human communication, so why the big fuss about description fields?) - Valid_Time_Proposition: Timing info for indicators is badly needed, but I have yet to encounter usage of it. Can we come up with sensible guidelines of how to use the field? It should only be kept if we can... - IndicatorExpression In the present specification, this field can either contain what is essentially a logical formula (codified as a tree) of indicators or an observable composition. - Remove logical operations: allow only to reference a list of indicators that constitute the present indicator. - If you want to do complicated and/or/not-reasoning about observable stuff: that is essentially a signature, so find a signature-language of your choice (including and/or/not-combinations of CybOX observables, if that is what works best) and formulate the signature as a test mechanism. - For everything else: find a way to encode observable patterns as simple key-value pairs and include/reference a list of them here. Should work fine for the majority of current use-cases. At most, allow a structured list that groups basic observable patterns (key-value) pairs with respect to a cybox observable to which they belong. - Indicated_TTP: Use yet-to-be-designed relationship mechanism. - Kill_Chain_Phases: Define *ONE* standard STIX kill chain and work with that. Being able to include alternative models is nice, but complicates tooling quite a bit ... and, remember, this is an exchange format, so one common kill-chain model understood in the same way by everybody will work best. - Test Mechanisms Make this a stand-alone entity/object rather than part of the Indicator object. As mentioned above: use this also to communicate more complicate observable patterns expressed in CybOX. - Likely_Impact. Remove: I have never encountered it being used and have a hard time coming up with a convincing use case. - Suggested_COAs: Use yet-to-be-designed relationship mechanism. - Handling: Replace with some new mechanism for marking stuff with handling information. - Confidence Keep: we need a simple way to distinguish high-confidence from low-confidence indicators. - Sightings: Find some other way to do sightings (cf. the discussion on the mailing list) - Related_*: Use yet-to-be-designed relationship mechanism. - Producer: Either simplify drastically or better yet, leave away and consider for the next but one major release. Like I said above: this as an experiment of being very simple indeed (though my mind is probably too convoluted with all things CTI to come up with the super-simple thing). I am sure some of it is too simple, but with the current version of STIX we have already one extreme of complexity -- to map out our design space, we need to get a feeling for the other extreme as well, I think. Kind regards, Bernd -------- Bernd Grobauer, Siemens CERT