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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] Patterning Slides from TC Call


Greg – thanks for sharing the deck. I wasn’t able to attend the calls this week but I noticed the conformance slides at the back of the deck and wanted to comment on that particular feature.

1) The current slides (and proposal?) suggests a network inspection device is different from a host inspection device. As many know, there are plenty examples of products in the marketplace that inspect traffic, reconstruct attachments and inspect them in sandboxes….etc to determine if the payload is malicious. There’s even a whole market segment defined for such devices. This is not a TIP and not a SIEM.
2) I suggest conformance is based on use cases and feature support that is at a much more granular level than broad product categories that is being suggested on the slides.

Therefore, it would be feature based. I believe conformance statements have been added at the spec-level that already address some of my concerns so not sure if we really need a specific pattern conformance statement or not.

Here are examples of what I would suggest:

a) If your product supports TI consumption that is able to understand payload inspection then you must be able to ‘consume’  patterns that define
a. Files (any file extension or do we define a subset as MVP?)
b. Minimum Packet regex (up to 5 tuple minimally)
c. Optionally packet regex (full stack layer 7 inclusive)
d. Timestamps associated with payloads and packet regex
e. No state-machine required (i.e single evaluation (no recursion) of TI to payload/packet matching)
f. Optionally ability to support state-machine inspection (i.e. if this X matches and then Y matches then match Z)

b) If your product supports TI production of payload related capability then it must support:
a. Minimum packet regex including timestamps
b. Optional file payload TI
c. Optional state-machine patterning (ie. Recursion)

I *strongly* suggest we steer away from broad product category based conformance and rather stick to feature-based conformance.

On 10/20/16, 8:44 AM, "cti@lists.oasis-open.org on behalf of Back, Greg" <cti@lists.oasis-open.org on behalf of gback@mitre.org> wrote:

    For people having trouble viewing the slides, I attached them to this email.

    Greg




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