An experimental python library implementing the STIX 2.0 spec as python objects (NOT an official library, just having a go!) Not complete by a long stretch, just getting something together so I can easily create sample objects for experimentation.
| Spec: | http://stixproject.github.io/stix2.0/ |
|---|
- Major Update with commit: 7639f77151a13a26cfb151c54adcaede544f18d9
- Starting to update towards RC4 spec, primarily SDO parent and Indicator objects (main targets of below updates too...other objects tfo)
- Validation checking on initialisation for spec requirements (eg: labels mandatory on certain objects, patterns on Indicators, etc)
- So now you shouldn't be able to initialise an Indicator variable without specifying the required fields. Interesting user-experience debate to be had around that, but I think it's valid for the implementation
- Bundles fixed to RC4 spec ('objects' attribute rather than specific object type arrays...THANK YOU OASIS CTI TC!!!)
- Added a config.ini as I was getting too many global vars. Obviously I'm referencing a local ELK VM for testing purposes - feel free to add your knowledge base (kb) of choice!
- enrich.py is a local enrichment function which I haven't included here...sorry, that might break things! Delete lines 89-99 (of grizzlysteppe.py) to avoid issues
- test.py is just a muck about with some simple examples of object creation
- grizzlysteppe.py uses JAR-16-20296A.csv (from US-CERT publication) to re-interpret in a stix2 format using the library. It's pretty basic, but shows how to improve on linearly structured cyber threat intelligence using stix2
Lots more updates to follow! Will be working through RC4 and updating other classes to improve compliance and validation on initialisation.
- Follow-up commit: c057c9ad2b0d7345daf4dcae01f78e8459984971
- New objects added such as Vulnerability and STUB'd ones should be complete now
- Abstracted attribute setting to a generic 'set_attribute' handler which allows for centralised validation. This does mean that optional attributes are a bit trickier for the user to set now (ie: can't really do object.attribute = 'value'). I'm not sure how I feel about this...it definitely makes the library easier to build/change, but the focus of the user experience becomes making sure that everything is set on initialisation. Those that are optional can then be set with specific set_specific_attribute functions for each object type (that will reference the generic setter). I think that's fine, but will need to go through and write the optional setters
- TODO:
- Write a full test harness to test valid object creation (pass), missing required fields (fail) and incorrect vocab usage where required (fail)
- Re-write data marking (set_tlp) to handle any types of data marking
- Start to investigate 'add' functionality and other functions which might cause object version changes...not sure how best to do that at the moment