Proposal to extend indicator composition to include a "sequence" operator in OperatorTypeEnum

[JasonKeirstead]

Currently indicators can be composed in two ways, "AND" and "OR". There is a need to have a third type of composition of indicators to indicate a sequence, where a matching indicator pattern is only true if "Indicator A" is followed by "Indicator B" within a time window.

I believe the simplest and cleanest way to do this would be to extend OperatorTypeEnum to include a value called "SEQUENCE". This, in combination with an extension to the Valid_Time_Position parameter for the composed indicator to not only allow a fixed start and end time but also a time window, will allow one to do these types of use cases of "A followed by B within 1 hour", which you can not do today.

[sbarnum]

This is strongly related to CybOXProject/schemas#316

[JasonKeirstead]

Suggestion, leave Valid_Time_Position alone and add a new attribute of Valid_Time_range that lets you specify a time range for the lifetime of the indicator such as X seconds/hours/minutes/days/months/years

[jmgnc]

We will probably want more than just a period of time after, but also, like at least one 1 minute after, and occurring in the minute that follows. i.e. event a at T+0, then event b between T+60 and T+120. So maybe Valid_Time_offset too?

[JasonKeirstead]

Thinking deeper on this, I think that the notion of
"Valid_Time_Position" and "Valid_Time_*" is too restrictive for the context. I think there should be a whole object you can give to an indicator composition to define the conditions when it is valid, that can contain any combination of CybOX tests. A composition of indicators can also only be valid if all the indicators have something in common, like an origination IP, or if they match some analytic.

Should I open a separate enhancement for this and tie it to this one?

[ikiril01]

@JasonKeirstead I think Valid_Time_Position is separate from patterning, and is simply meant to indicate a relative time window for which an Indicator may be useful (and thereby "expires" afterwards). That said, I definitely agree that the only real way to specify more complex patterning would be via a separate object, one that supports any number of pattern "modifiers", relating to sequencing, time offsets, etc. IMO, the best way to do this would be to separate patterning out from the current Observable structure, as this would give us a great deal of flexibility, necessary for creating what essentially amounts to a domain-specific patterning language.

E.g., as a strawman, something like:

<Observable id="obs-1">
  <Object>
    <Properties xsi:type="AddressObj:AddressObjectType">
      <Address_Value id="value-1">1.2.3.4</Address_Value>
    </Properties>
  </Object>
</Observable>

<Observable id="obs-2">
  <Object>
    <Properties xsi:type="AddressObj:AddressObjectType">
      <Address_Value id="value-2">2.3.4.5</Address_Value>
    </Properties>
  </Object>
</Observable>

<Indicator>
  <Pattern operator="AND">
    <Observable_Property condition="equals" idref="value-1"/>
    <Observable_Property condition="equals" idref="value-2"/>
    <Modifiers>
      <Sequence>
        <Ordinality>
          <Ordinal_Position value="1" idref="value-1"/>
          <Ordinal_Position value="2" idref="value-2"/>
        </Ordinality>
        <Time_Window units="minutes">60</Time_Window>
      </Sequence>
    </Modifiers>
  </Pattern>
</Indicator>

This would obviously be a huge change from the current structure and require CybOX v2.0/STIX v2.0 :)

Oh - and to answer your previous question, I think this is probably worth discussing further as a separate issue.

[jmgnc]

I do like @ikiril01 suggestion. We should probably use xs:duration ( http://www.w3schools.com/schema/schema_dtypes_date.asp ) for this instead of inventing a new way.

[JasonKeirstead]

I think @ikiril01 suggestion would cover everything i had envisioned for this, if we can make it happen.

I would really like to see this gap closed in STIX 2.0 via some means. Its the one thing left to being able to leverage STIX as a common base for creating complex rules.