Go to file
clenk 0a2cda00cc Add object factory docstring 2017-07-17 15:23:20 -04:00
docs Add information on API layers 2017-06-29 12:51:17 +00:00
examples Fix import order 2017-06-01 17:17:03 -04:00
stix2 Add object factory docstring 2017-07-17 15:23:20 -04:00
.gitignore Merge branch 'master' into parsing 2017-04-11 15:05:22 -04:00
.isort.cfg Fix import order 2017-06-01 17:17:03 -04:00
.pre-commit-config.yaml Switch to isort for checking import order 2017-05-09 15:10:53 -04:00
.travis.yml Move codecov invocation from Tox to Travis 2017-06-01 17:00:22 -04:00
CHANGELOG Bump version: 0.0.1 → 0.1.0 2017-05-22 10:18:49 -05:00
CONTRIBUTING.md Update CONTRIBUTING.md 2017-02-10 11:59:09 -06:00
LICENSE Create boilerplate LICENSE text 2017-02-10 12:01:03 -06:00
README.md Change remaining 'fields' to 'properties' 2017-05-19 12:51:59 -05:00
requirements.txt Add missing dependency 2017-04-07 15:20:32 -05:00
setup.cfg Bump version: 0.1.0 → 0.2.0 2017-05-31 10:03:50 -05:00
setup.py Add stix2.__version__ 2017-07-06 09:41:50 -04:00
tox.ini Fix import order 2017-06-01 17:17:03 -04:00

README.md

Build Status codecov

cti-python-stix2

This is an OASIS Open Repository. See the Governance section for more information.

This repository provides Python APIs for serializing and de-serializing STIX 2 JSON content, along with higher-level APIs for common tasks, including data markings, versioning, and for resolving STIX IDs across multiple data sources.

Installation

Install with pip:

pip install stix2

Usage

Creating STIX Domain Objects

To create a STIX object, provide keyword arguments to the type's constructor:

from stix2 import Indicator

indicator = Indicator(name="File hash for malware variant",
                      labels=['malicious-activity'],
                      pattern='file:hashes.md5 = "d41d8cd98f00b204e9800998ecf8427e"')

Certain required attributes of all objects will be set automatically if not provided as keyword arguments:

  • If not provided, type will be set automatically to the correct type. You can also provide the type explicitly, but this is not necessary:

    indicator = Indicator(type='indicator', ...)
    

    Passing a value for type that does not match the class being constructed will cause an error:

    >>> indicator = Indicator(type='xxx', ...)
    stix2.exceptions.InvalidValueError: Invalid value for Indicator 'type': must equal 'indicator'.
    
  • If not provided, id will be generated randomly. If you provide an id argument, it must begin with the correct prefix:

    >>> indicator = Indicator(id="campaign--63ce9068-b5ab-47fa-a2cf-a602ea01f21a")
    stix2.exceptions.InvalidValueError: Invalid value for Indicator 'id': must start with 'indicator--'.
    
  • If not provided, created and modified will be set to the (same) current time.

For indicators, labels and pattern are required and cannot be set automatically. Trying to create an indicator that is missing one of these properties will result in an error:

>>> indicator = Indicator()
stix2.exceptions.MissingPropertiesError: No values for required properties for Indicator: (labels, pattern).

However, the required valid_from attribute on Indicators will be set to the current time if not provided as a keyword argument.

Once created, the object acts like a frozen dictionary. Properties can be accessed using the standard Python dictionary syntax:

>>> indicator['name']
'File hash for malware variant'

TBD: Should we allow property access using the standard Python attribute syntax?

>>> indicator.name
'File hash for malware variant'

Attempting to modify any attributes will raise an error:

>>> indicator['name'] = "This is a revised name"
TypeError: 'Indicator' object does not support item assignment
>>> indicator.name = "This is a revised name"
stix2.exceptions.ImmutableError: Cannot modify properties after creation.

To update the properties of an object, see Versioning below.

Creating a Malware object follows the same pattern:

from stix2 import Malware

malware = Malware(name="Poison Ivy",
                  labels=['remote-access-trojan'])

As with indicators, the type, id, created, and modified properties will be set automatically if not provided. For Malware objects, the labels and name properties must be provided.

Creating Relationships

STIX 2 Relationships are separate objects, not properties of the object on either side of the relationship. They are constructed similarly to other STIX objects. The type, id, created, and modified properties are added automatically if not provided. Callers must provide the relationship_type, source_ref, and target_ref properties.

from stix2 import Relationship

relationship = Relationship(relationship_type='indicates',
                            source_ref=indicator.id,
                            target_ref=malware.id)

The source_ref and target_ref properties can be either the ID's of other STIX objects, or the STIX objects themselves. For readability, Relationship objects can also be constructed with the source_ref, relationship_type, and target_ref as positional (non-keyword) arguments:

relationship = Relationship(indicator, 'indicates', malware)

Creating Bundles

STIX Bundles can be created by passing objects as arguments to the Bundle constructor. All required properties (type, id, and spec_version) will be set automatically if not provided, or can be provided as keyword arguments:

from stix2 import bundle

bundle = Bundle(indicator, malware, relationship)

Serializing STIX objects

The string representation of all STIX classes is a valid STIX JSON object.

indicator = Indicator(...)

print(str(indicator))

Versioning

TBD

Governance

This GitHub public repository ( https://github.com/oasis-open/cti-python-stix2 ) was proposed and approved

[bis](https://issues.oasis-open.org/browse/TCADMIN-2549)

TC](https://www.oasis-open.org/committees/cti/) as an OASIS Open Repository to support development of open source resources related to Technical Committee work.

While this Open Repository remains associated with the sponsor TC, its development priorities, leadership, intellectual property terms, participation rules, and other matters of governance are separate and distinct from the OASIS TC Process and related policies.

All contributions made to this Open Repository are subject to open source license terms expressed in the BSD-3-Clause License. That license was selected as the declared "Applicable License" when the Open Repository was created.

As documented in "Public Participation Invited", contributions to this OASIS Open Repository are invited from all parties, whether affiliated with OASIS or not. Participants must have a GitHub account, but no fees or OASIS membership obligations are required. Participation is expected to be consistent with the OASIS Open Repository Guidelines and Procedures, the open source LICENSE designated for this particular repository, and the requirement for an Individual Contributor License Agreement that governs intellectual property.

Maintainers

Open Repository Maintainers are responsible for oversight of this project's community development activities, including evaluation of GitHub pull requests and preserving open source principles of openness and fairness. Maintainers are recognized and trusted experts who serve to implement community goals and consensus design preferences.

Initially, the associated TC members have designated one or more persons to serve as Maintainer(s); subsequently, participating community members may select additional or substitute Maintainers, per consensus agreements.

Current Maintainers of this Open Repository

About OASIS Open Repositories

Feedback

Questions or comments about this Open Repository's activities should be composed as GitHub issues or comments. If use of an issue/comment is not possible or appropriate, questions may be directed by email to the Maintainer(s) listed above. Please send general questions about Open Repository participation to OASIS Staff at repository-admin@oasis-open.org and any specific CLA-related questions to repository-cla@oasis-open.org.