The CloudShark Threat Assessment addon is installed with an initial set of the Emerging Threats Open rules. By default these rules are never updated after the initial installation of the addon. Customers with the Threat Assessment addon may have rules that they have developed or purchased themselves that can be used with CloudShark.

Configuration files

CloudShark uses the configuration files in /usr/cloudshark/etc/suricata/ to determine the rules and variable settings used during a threat assessment. Suricata is used behind the scenes to generate threats based on the traffic in the capture file.

Rule variables

The file suricata-vars.yaml can be modified to configure the variables which are used in rules. Here is a link describing the Suricata configuration for this:

Suricata Rule-vars

Rule files

The file suricata-rules.yaml can be modified to point Suricata to files containing the rules. Here is a link describing the Suricata configuration for rule files:

Suricata Rule-files

The default-rule-path: setting should not be changed and must be set to /usr/cloudshark/etc/suricata/rules/ for threat assessment to work properly.

Suricata-Update

Suricata-Update is a tool bundled with Suricata that may be used to download new rules for threat assessment. The command to download and update the Emerging Threats Open rules that were initially installed with CloudShark is:

/usr/cloudshark/bin/suricata-update --no-test

Additional Rules

Suricata-Update can download rules from additional sources such as the ET Pro Ruleset. To view what sources can be used for new rules run the commands:

/usr/cloudshark/bin/suricata-update update-sources
/usr/cloudshark/bin/suricata-update list-sources

Additional sources can be enabled by running:

/usr/cloudshark/bin/suricata-update enable-source <source>

Some rulesets such as the ET Pro Ruleset mentioned above may require a subscription and this command will prompt for an access code.

Reloading

After changing either of these configurations Suricata will have to be reloaded to use the new variables and rules files. Here is a command that can be run as the cloudshark user to reload Suricata:

cd /var/www/cloudshark/current && bin/run "sc = SuricataConnection.new;sc.send_reload_command"

Caching

CloudShark runs the capture through Suricata once and then caches the result which gets returned on subsequent requests without rerunning the capture through Suricata. The cache can be invalidated by updating the last modified date of the file /usr/cloudshark/etc/suricata/RULES-VERSION. This can be done using the command touch /usr/cloudshark/etc/suricata/RULES-VERSION. Then when a users requests a threat assessment the capture will be rerun using any new rules or configuration changes to Suricata.