Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add filter generator #31

Open
jmgnc opened this issue May 3, 2017 · 4 comments
Open

Add filter generator #31

jmgnc opened this issue May 3, 2017 · 4 comments

Comments

@jmgnc
Copy link

jmgnc commented May 3, 2017

Figure out how, given a pattern to generate a corse filter for the pattern. Like only observables w/ a cyber object that has type file.

This would let us pre filter the observable data before being passed to the matcher to help make it faster.

@gtback
Copy link
Contributor

gtback commented May 4, 2017

We've (and by "we" I really mean @chisholm) started working on something like this in the "pattern-validator" repo, which is quickly turning into a more general purpose library for STIX 2 patterns.

https://github.com/oasis-open/cti-pattern-validator/blob/master/stix2patterns/inspector.py

We haven't yet integrated the pattern-validator into this repo, though, so we'll probably want to do that as well.

@gtback
Copy link
Contributor

gtback commented May 23, 2017

@jmgnc : Now that stix2-patterns is a dependency of this library, can you talk more about what types of filters you'd want to support? Or maybe this issue is better handled in the other repo.

@jmgnc
Copy link
Author

jmgnc commented May 31, 2017

We can handle it here, or maybe move the issue to the other repo.

The main ones I can think of are the requirement for specific types. This won't help us out too much as most of our observed-data will be network-traffic, then the next one would be what extensions are required.

I did realize that this does cause problems for != checks, as that can match any non-specific types. Hope this is a good start.

@gtback
Copy link
Contributor

gtback commented Jun 12, 2018

@jmgnc, I'm trying to figure out what the next step is for this issue. The matcher does now depend on the stix2patterns library, so we can make use of the inspector. But I don't know what a "filter" should look like. We also need to define how patterns contain "!=", or an "OR" combining known and unknown object types, should behave. We probably also need to figure out what the correct "status" is for observations that cannot be evaluated are.

I'd like to specify some of these things before we get too far into an implementation. That said, if this is no longer a need, we can probably just close this.

@gtback gtback self-assigned this Jun 12, 2018
@gtback gtback removed their assignment Jul 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants