Actions Proposal

Support for Object Actions

In some data models, such as CAR, the concept of an action can be attached to an object. For example, a process may produce two objects, one for its creation, and one for its termination. The actions would be create and and terminate respectively. We propose that STIX add the ability to specify object actions to its patterning and data model. There are a few possibilites to discuss. The following is an example of a use case using the CAR data model and pseudocode:

process = search Process:Create
cmd = filter process where (exe == "cmd.exe")
output cmd

Action Types

In addition to the syntax, the action types applicable to each object type must be defined. Here are some proposed actions, largely taken directly from CAR.

Object	Actions
file	create, delete, modify-metadata, read, write
directory	create, delete, modify-metadata
process	create, terminate
windows-registry-key	create, delete, modify
software	install, uninstall, modify
user-account	login, delete, create, logoff

There are a few things to consider when adding actions. Some objects may not have actions. Other objects already have some features which built in which make actions redundant. For example, network-flow can already express the above-listed actions with its start, end, and encapsulates_refs properties. Additionally, for compatibility, objects should be allowed to have no actions specified, even if they may have actions in general.

Implementation Options

In the stix-pattern-translator, we have gone ahead and implemented Option 1 with the actions listed in the table above. We have also incorporated some ideas from Option 3. For example, we have omitted actions from some STIX Objects such as network-traffic.

Option 1

The method which best fits the current STIX objects and patterns would be to simply add a standard property called action to STIX objects. This would require no changes to the grammar of STIX patterns. The user would then query for such an object as follows:

[process:name = 'cmd.exe' AND process:action = 'create']

Option 2

Another possible method would be to prefix the action outside of the observable expression:

create:[process:name = 'cmd.exe']

or

process:create:[process:name = 'cmd.exe']

A problem with this method is that there could be some ambiguity in adding actions to expressions with multiple object types such as the following:

[process:name = 'cmd.exe' OR file:name = 'cmd.exe]

One possibility would be to eliminate such expressions from the grammar and force them to broken up as follows:

[process:name = 'cmd.exe'] OR [file:name = 'cmd.exe']

Then, actions could be added to the expressions unambiguously:

terminate:[process:name = 'cmd.exe'] OR delete:[file:name = 'cmd.exe']

Outside of the scope of this proposal, but something else to consider in the future would be a syntax like the following:

process:terminate:[name = 'cmd.exe'] OR file:delete:[name = 'cmd.exe']

Option 3

Another option would be to simply add the desired properties to each object type as needed, rather than creating a new generalized concept. For example, process and file objects already have a created timestamp property. Under this option, we could simply create optional timestamp properties terminated and deleted, respectively. For files, we could also have an array for modified and other similar fields if we want to be able to track the history of the file. direcory would be treated similarly to files. Alternatively, file could remain unchanged, and actions can be inferred by tracking multiple objects with the same name and hashes or something similar. network-traffic objects already have start and end fields, and messages could be tracked using encapsulates_refs. A windows-registry-key object could be tracked similarly to a file.