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
Added rrname_{ip,domain}, rdata_{ip,domain} fields #314
Conversation
text only into MISP objects. Why? Because otherwise we can't use MISP's correlation engine to correlate attributes (rrname, rdata) inside these MISP objects with other events. Because "text" would not correlate with other "ip-src" or "domain" types in other objects/attributes. Kind of sucks to duplicate the rrname and rdata entries, but that's the only solution we came up with. The COF2MISP module will populate both the rrname,rdata as well as the rrname_{domain,ip} and rdata_{domain,ip} attributes. Checked with jq_all_the_things.sh. Thanks for your consideration.
But the approach is to create a second object (ip/domain) and add a relationship. @Rafiot not sure I understand the issue. |
I’ll try to explain from my phone but I’ll be reachable later today via signal or mail.
So the background problem is this:
Rrname rrtype rdata
Can be either of type:
Ip PTR domain
Or
Domain CNAME/DName domain
Or
Domain A/AAAA/A6 IP
Or
Domain something text
Or
Domain SOA …
Etc. you get the idea :)
Now if we want to have the fields of the MISP object fields „rrname“ or „rdata“ correlated with the same fields in other MISP events which include these fields… then the types must match.
Only having „text“ as type won’t allow for the correlation, right?
So I see two solutions:
1) extend the passive-DNS cof MISP object as I did. in the PR or
2) create all kinds of combination MISP objects for every possible combination.
Any better ideas? Did I miss something?
Best,
A.
…---
Mobile
On 02.05.2021, at 20:07, Alexandre Dulaunoy ***@***.***> wrote:
But the approach is to create a second object (ip/domain) and add a relationship. @Rafiot not sure I understand the issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
The issue is that the attribute type (on MISP) for |
Correlation works on the value. The type is disregarded. |
Right. I thought it didn't. Never mind then, no need to change the template. |
On 02.05.2021, at 22:39, Raphaël Vinot ***@***.***> wrote:
Right. I thought it didn't. Never mind then, no need to change the template.
Oh man, okay. 3h of code rewriting goes down the drain :)
|
it doesn't go down the drain, finding the type can simply be done on the consumer side: the MISP objects are created with the currently existing template, and when you want to use the data from MISP, you figure out the type. Advantage: you can also use the objects created by other people. When we discussed that, I understood that the correlation wasn't possible across different types on MISP, but correlation works. and as the passive DNS reference format doesn't enforce a type for rrname or rrdata, it is just plain confusing to add all the possible types in the template, especially since there are many different other types. And I didn't realize, but the format gives the type: https://github.com/MISP/misp-modules/pull/491/files#diff-fd991138ae0c6034d46face71f07a15e814015d7fa8cd0ec5da32a40cff0a730R84 |
On 02.05.2021, at 23:01, Raphaël Vinot ***@***.***> wrote:
it doesn't go down the drain, finding the type can simply be done on the module side.
I see. So, then I suggest we do one single change: bailiwick is *always* a domain.
So that would be the right type for it. And we leave the other fields in definition.json as text.
|
See the discussion in MISP/misp-objects#314
MISP#314 Removing *_ip and *_domain Keeping bailiwick a domain type
Okay, so that's adapted to NOT need the rrname_ip, rrname_domain and rdata_ip, rdata_domain fields. please review, @adulau and @Rafiot if that fits you now. Thx!! PS: no idea why validate.sh fails. Since jq_all_the_things.sh works. |
Thanks a lot for the update! |
... as discussed with @Rafiot this is unfortuantely needed for allowing correlation with other ip addresses or domains in other objects. See the detailed comment in the previous commit please for an explanation.
@adulau, I'd appreciate a quick merge so that I can proceed. Thx :)
BTW: no idea why validate.sh complains in
git status --porcelain
. I did ajq_all_the_things.sh
before, and that works. It's valid JSON.