-
Notifications
You must be signed in to change notification settings - Fork 11
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 stix-extract tool #48
base: develop
Are you sure you want to change the base?
Conversation
205b2a0
to
65f6c34
Compare
65f6c34
to
62afafc
Compare
62afafc
to
5320414
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pointed out a few places for improvement, but this is nice work.
I think adding this script may warrant a bump of the patch portion of the version as well. |
Bumped in: 1654c50 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, but please make sure to create a release after merging. (I see that you removed that checkbox item from the PR description, but now that the version is bumped it is necessary.)
Also please note for the future that we generally add a co-author for commits created in response to reviewer suggestion by appending a line like this to the commit comment:
|
#!/usr/bin/env python3 | ||
|
||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be included in a file that is part of a package. The ioc_scanner.py
file is an unpleasant hacky thing that does not conform to our general Python package guidelines and I see no rationale for this module to be configured similarly.
#!/usr/bin/env python3 | |
""" | |
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mcdonnnj , Is the suggested change being made? I still notice in the file stix_extract.py the first line reads as #!/usr/bin/env python3.
|
||
if __name__ == "__main__": | ||
sys.exit(main()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same rationale as the shebang comment.
if __name__ == "__main__": | |
sys.exit(main()) |
print(f"\n{'#' * 20}\n# IP Addresses\n{'#' * 20}\n") | ||
for ip in ip_addresses: | ||
print(ip) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going to have four instances of the same logic I think we should DRY this out into a function. All four data sources are iterables and we're printing the headers with identical formatting.
best_priority = hash_priority[h.type_.value] | ||
if best_hash is not None: | ||
hashes.append(best_hash) | ||
elif object_type == "DomainNameObjectType": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor but would you adjust this elif
so that the elif
checks are alphabetical? I think that would improve maintainability since we're just checking a bunch of strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if you'd want to make those lists alphabetical or not considering we've done this before. LGTM tho
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if this file had typehints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With all of the mocking and patching there is no true end-to-end test of this module's functionality. I would almost prefer crafted STIX documents that would naturally be parsed to provide the expected results instead. Using so much intentionally crafted data runs the risk of missing breaking changes in the dependency package (especially since there is no version pin around the package). Additionally there is nothing to test providing the STIX document through stdin that I see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@felddy Are you planning to return to this PR any time soon? |
Add stix-extract tool
🗣 Description
This PR introduces a new tool,
stix-extract
, to theioc-scanner
project. This tool extracts indicators of compromise (IoCs) from STIX files and outputs them in a format that can be used by the existingioc-scan
tool. Additionally the tool can extract IPs, FQDNs, and URLs for use in other parts of the IoC scanning process.💭 Motivation and Context
The motivation for adding this tool is to allow for the use of STIX files as a source of IoCs. STIX files are a widely-adopted standard for threat intelligence sharing, and by adding the ability to directly process these files, we increase the utility and flexibility of the
ioc-scanner
project.🧪 Testing
Testing for this change included manual usage of the tool to verify its functionality. The tool was used with different STIX files and combined with
ioc-scan
in various ways to ensure compatibility and functionality. Further automated testing can be added in the future to verify the robustness of this addition.✅ Pre-approval Checklist