# Technical Documentation: Security-Onion-Solutions/securityonion
> ℹ️ **Provenance:** Multi-Tier Ingestion · [CodeWiki Reference](https://codewiki.google/github.com/Security-Onion-Solutions/securityonion)
### Overview (`README.md`)
# Security Onion
Security Onion is a free and open Linux distribution for threat hunting, enterprise security monitoring, and log management. It includes a comprehensive suite of tools designed to work together to provide visibility into your network and host activity.
## ✨ Features
Security Onion includes everything you need to monitor your network and host systems:
* **Security Onion Console (SOC)**: A unified web interface for analyzing security events and managing your grid.
* **Elastic Stack**: Powerful search backed by Elasticsearch.
* **Intrusion Detection**: Network-based IDS with Suricata and host-based monitoring with Elastic Fleet.
* **Network Metadata**: Detailed network metadata generated by Zeek or Suricata.
* **Full Packet Capture**: Retain and analyze raw network traffic with Suricata PCAP.
## ⭐ Security Onion Pro
For organizations and enterprises requiring advanced capabilities, **Security Onion Pro** offers additional features designed for scale and efficiency:
* **Onion AI**: Leverage powerful AI-driven insights to accelerate your analysis and investigations.
* **Enterprise Features**: Enhanced tools and integrations tailored for enterprise-grade security operations.
For more information, visit the [Security Onion Pro](https://securityonionsolutions.com/pro) page.
## ☁️ Cloud Deployment
Security Onion is available and ready to deploy in the **AWS**, **Azure**, and **Google Cloud (GCP)** marketplaces.
## 🚀 Getting Started
| Goal | Resource |
| :--- | :--- |
| **Download** | [Security Onion ISO](https://securityonion.net/docs/download) |
| **Requirements** | [Hardware Guide](https://securityonion.net/docs/hardware) |
| **Install** | [Installation Instructions](https://securityonion.net/docs/installation) |
| **What's New** | [Release Notes](https://securityonion.net/docs/release-notes) |
## 📖 Documentation & Support
For more detailed information, please visit our [Documentation](https://docs.securityonion.net).
* **FAQ**: [Frequently Asked Questions](https://securityonion.net/docs/faq)
* **Community**: [Discussions & Support](https://securityonion.net/docs/community-support)
* **Training**: [Official Training](https://securityonion.net/training)
## 🤝 Contributing
We welcome contributions! Please see our [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines on how to get involved.
## 🛡️ License
Security Onion is licensed under the terms of the license found in the [LICENSE](LICENSE) file.
---
*Built with 🧅 by Security Onion Solutions.*
---
### Overview (`salt/sensoroni/files/analyzers/README.md`)
# Security Onion Analyzers
Security Onion provides a means for performing data analysis on varying inputs. This data can be any data of interest sourced from event logs. Examples include hostnames, IP addresses, file hashes, URLs, etc. The analysis is conducted by one or more analyzers that understand that type of input. Analyzers come with the default installation of Security Onion. However, it is also possible to add additional analyzers to extend the analysis across additional areas or data types.
## Supported Observable Types
The built-in analyzers support the following observable types:
| Name | Domain | EML | Hash | IP | Mail | Other | URI | URL | User Agent |
| ------------------------|--------|-------|-------|-------|-------|-------|-------|-------|-------|
| Alienvault OTX |✓ |✗|✓|✓|✗|✗|✗|✓|✗|
| EchoTrail |✗ |✗|✓|✗|✗|✓|✗|✗|✗|
| EmailRep |✗ |✗|✗|✗|✓|✗|✗|✗|✗|
| Elasticsearch |✓ |✓|✓|✓|✓|✓|✓|✓|✓|
| Greynoise |✗ |✗|✗|✓|✗|✗|✗|✗|✗|
| LocalFile |✓ |✗|✓|✓|✗|✓|✗|✓|✗|
| Malware Hash Registry |✗ |✗|✓|✗|✗|✗|✗|✓|✗|
| MalwareBazaar |✗ |✗|✓|✗|✗|✓|✗|✗|✗|
| Pulsedive |✓ |✗|✓|✓|✗|✗|✓|✓|✓|
| Spamhaus |✗ |✗|✗|✓|✗|✗|✗|✗|✗|
| Sublime Platform |✗ |✓|✗|✗|✗|✗|✗|✗|✗|
| ThreatFox |✓ |✗|✓|✓|✗|✗|✗|✗|✗|
| Urlhaus |✗ |✗|✗|✗|✗|✗|✗|✓|✗|
| Urlscan |✗ |✗|✗|✗|✗|✗|✗|✓|✗|
| Virustotal |✓ |✗|✓|✓|✗|✗|✗|✓|✗|
| WhoisLookup |✓ |✗|✗|✗|✗|✗|✓|✗|✗|
## Authentication
Many analyzers require authentication, via an API key or similar. The table below illustrates which analyzers require authentication.
| Name | Authn Req'd|
--------------------------|------------|
[AlienVault OTX](https://otx.alienvault.com/api) |✓|
[EchoTrail](https://www.echotrail.io/docs/quickstart) |✓|
[EmailRep](https://emailrep.io/key) |✓|
[Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/setting-up-authentication.html) |✓|
[GreyNoise (community)](https://www.greynoise.io/plans/community) |✗|
[LocalFile](https://github.com/Security-Onion-Solutions/securityonion/tree/fix/sublime_analyzer_documentation/salt/sensoroni/files/analyzers/localfile) |✗|
[Malware Hash Registry](https://hash.cymru.com/docs_whois) |✗|
[MalwareBazaar](https://bazaar.abuse.ch/) |✓|
[Pulsedive](https://pulsedive.com/api/) |✓|
[Spamhaus](https://www.spamhaus.org/dbl/) |✗|
[Sublime Platform](https://sublime.security) |✓|
[ThreatFox](https://threatfox.abuse.ch/) |✓|
[Urlhaus](https://urlhaus.abuse.ch/) |✓|
[Urlscan](https://urlscan.io/docs/api/) |✓|
[VirusTotal](https://developers.virustotal.com/reference/overview) |✓|
[WhoisLookup](https://github.com/meeb/whoisit) |✗|
## Developer Guide
### Python
Analyzers are Python modules, and can be made up of a single .py script, for simpler analyzers, or a complex set of scripts organized within nested directories.
The Python language was chosen because of it's wide adoption in the security industry, ease of development and testing, and the abundance of developers with Python skills.
Specifically, analyzers must be compatible with Python 3.10.
For more information about Python, see the [Python Documentation](https://docs.python.org).
### Development
Custom analyzers should be developed outside of the Security Onion cluster, in a proper software development environment, with version control or other backup mechanisms in place. The analyzer can be developed, unit tested, and integration tested without the need for a Security Onion installation. Once satisifed with the analyzer functionality the analyzer directory should be copied to the Security Onion manager node.
Developing an analyzer directly on a Security Onion manager node is strongly discouraged, as loss of source code (and time and effort) can occur, should the management node suffer a catastrophic failure with disk storage loss.
For best results, avoid long, complicated functions in favor of short, discrete functions. This has several benefits:
- Easier to troubleshoot
- Easier to maintain
- Easier to unit test
- Easier for other developers to review
### Linting
Source code should adhere to the [PEP 8 - Style Guide for Python Code](https://peps.python.org/pep-0008/). Developers can use the default configuration of `flake8` to validate conformance, or run the included `build.sh` inside the analyzers directory. Note that linting conformance is mandatory for analyzers that are contributed back to the Security Onion project.
### Testing
Python's [unitest](https://docs.python.org/3/library/unittest.html) library can be used for covering analyzer code with unit tests. Unit tests are encouraged for custom analyzers, and mandatory for public analyzers submitted back to the Security Onion project.
If you are new to unit testing, please see the included `urlhaus_test.py` as an example.
Unit tests should be named following the pattern `_test.py`.
### Analyzer Package Structure
Delpoyment of a custom analyzer entails copying the analyzer source directory and depenency wheel archives to the Security Onion manager node. The destination locations can be found inside the `securityonion` salt source directory tree. Using the [Saltstack](https://github.com/saltstack/salt) directory pattern allows Security Onion developers to add their own analyzers with minimal additional effort needed to upgrade to newer versions of Security Onion. When the _sensoroni_ salt state executes it will merge the default analyzers with any local analyzers, and copy the merged analyzers into the `/opt/so/conf/sensoroni` directory.
Do not modify files in the `/opt/so/conf/sensoroni` directory! This is a generated directory and changes made inside will be automatically erased on a frequent interval.
On a Security Onion manager, custom analyzers should be placed inside the `/opt/so/saltstack/local/salt/sensoroni` directory, as described in the next section.
#### Directory Tree
From within the default saltstack directory, the following files and directories exist:
```
salt
|- sensoroni
|- files
|- analyzers
|- urlhaus <- Example of an existing analyzer
| |- source-packages <- Contains wheel package bundles for this analyzer's dependencies
| |- site-packages <- Auto-generated site-packages directory (or used for custom dependencies)
| |- requirements.txt <- List of all dependencies needed for this analyzer
| |- urlhaus.py <- Source code for the analyzer
| |- urlhaus_test.py <- Unit tests for the analyzer source code
| |- urlhaus.json <- Metadata for the analyzer
| |- __init__.py <- Package initialization file, often empty
|
|- build.sh <- Simple CI tool for validating linting and unit tests
|- helpers.py <- Common functions shared by many analyzers
|- helpers_test.py <- Unit tests for the shared source code
|- pytest.ini <- Configuration options for the flake8 and pytest
|- README.md <- The file you are currently reading
```
Custom analyzers should conform to this same structure, but instead of being placed in the `/opt/so/saltstack/default` directory tree, they should be placed in the `/opt/so/saltstack/local` directory tree. This ensures future Security Onion upgrades will not overwrite customizations. Shared files like `build.sh` and `helpers.py` do not need to be duplicated. They can remain in the _default_ directory tree. Only new or modified files should exist in the _local_ directory tree.
#### Metadata
Each analyzer has certain metadata that helps describe the function of the analyzer, required inputs, artifact compatibility, optional configuration options, analyzer version, and other important details of the analyzer. This file is a static file and is not intended to be used for dynamic or custom configuration options. It should only be modified by the author of the analyzer.
The following example describes the urlhaus metadata content:
```
{
"name": "Urlhaus", <- Unique human-friendly name of this analyzer
"version": "0.1", <- The version of the analyzer
"author": "Security Onion Solutions", <- Author's name, and/or email or other contact information
"description": "This analyzer queries URLHaus...", <- A brief, concise description of the analyzer
"supportedTypes" : ["url"], <- List of types that must match the SOC observable types
"baseUrl": "https://urlhaus-api.abuse.ch/v1/url/" <- Optional hardcoded data used by the analyzer
}
```
The `supportedTypes` values should only contain the types that this analyzer can work with. In the case of the URLHaus analyzer, we know that it works with URLs. So adding "hash" to this list wouldn't make sense, since URLHaus doesn't provide information about file hashes. If an analyzer does not support a particular type then it will not show up in the analyzer results in SOC for that observable being analyzed. This is intentional, to eliminate unnecessary screen clutter in SOC. To find a list of available values for the `supportedTypes` field, login to SOC and inside of a Case, click the + button on the Observables tab. You will see a list of types and each of those can be used in this metadata field, when applicable to the analyzer.
#### Dependencies
Analyzers will often require the use of third-party packages. For example, if an analyzer needs to make a request to a remote server via HTTPS, then the `requests` package will likely be used. Each analyzer will container a `requirements.txt` file, in which all third-party dependencies can be specified, following the python [Requirements File Specification](https://pip.pypa.io/en/stable/reference/requirements-file-format/).
Additionally, to support airgapped users, the dependency packages themselves, and any transitive dependencies, should be placed inside the `source-packages` directory. To obtain the full hierarchy of dependencies, execute the following commands:
```bash
pip download -r /requirements.txt -d /source-packages
```
### Analyzer Architecture
The Sensoroni Docker container is responsible for executing analyzers. Only the manager's Sensoroni container will process analyzer jobs. Other nodes in the grid, such as sensors and search nodes, will not be assigned analyzer jobs.
When the Sensoroni Docker container starts, the `/opt/so/conf/sensoroni/analyzer` directory is mapped into the container. The initialization of the Sensoroni Analyze module will scan that directory for any subdirectories. Valid subdirectories will be added as an available analyzer.
The analyzer itself will only run when a user in SOC enqueues an analyzer job, such as via the Cases -> Observables tab. When the Sensoroni node is ready to run the job it will execute the python command interpretor separately for each loaded analyzer. The command line resembles the following:
```bash
python -m urlhaus '{"artifactType":"url","value":"https://bigbadbotnet.invalid",...}'
```
To manually test an analyzer outside of the Sensoroni Docker container, use a command similar to the following:
```bash
PYTHONPATH=. python urlhaus/urlhaus.py '{"artifactType":"url","value":"https://bigbadbotnet.invalid",...}'
```
It is up to each analyzer to determine whether the provided input is compatible with that analyzer. This is assisted by the analyzer metadata, as described earlier in this document, with the use of the `supportedTypes` list.
Once the analyzer completes its functionality, it must terminate promptly. See the following sections for more details on expected internal behavior of the analyzer.
#### Configuration
Analyzers may need dynamic configuration data, such as credentials or other secrets, in order to complete their function. Optional configuration files can provide this information, and are expected to reside in the analyzer's directory. Configuration files are typically written in YAML syntax for ease of modification.
Configuration files for analyzers included with Security Onion will be pillarized, meaning they derive their custom values from the Saltstack pillar data. For example, an analyzer that requires a user supplied credential might contain a config file resembling the following, where Jinja templating syntax is used to extra Salt pillar data:
```yaml
username: {{ salt['pillar.get']('sensoroni:analyzers:myanalyzer:username', '') }}
password: {{ salt['pillar.get']('sensoroni:analyzers:myanalyzer:password', '') }}
```
Sensoroni will not provide any inputs to the analyzer during execution, other than the artifact input in JSON format. However, developers will likely need to test the analyzer outside of Sensoroni and without Jinja templating, therefore an alternate config file should normally be supplied as the configuration argument during testing. Analyzers should allow for this additional command line argument, but by default should automatically read a configuration file stored in the analyzer's directory.
#### Exit Code
If an analyzer determines it cannot or should not operate on the input then the analyzer should return an exit code of `126`.
If an analyzer does attempt to operate against the input then the exit code should be 0, regardless of the outcome. The outcome, be it an error, a confirmed threat detection, or perhaps an unknown outcome, should be noted in the output of the analyzer.
#### Output
The outcome of the analyzer is reflected in the analyzer's output to `stdout`. The output must be JSON formatted, and should contain the following fields.
`summary`: A very short summarization of the outcome. This should be under 50 characters, otherwise it will be truncated when displayed on the Analyzer job list.
`status`: Can be one of the following status values, which most appropriately reflects the outcome:
- `ok`: The analyzer has concluded that the provided input is not a known threat.
- `info`: This analyzer provides informative data, but does not attempt to conclude the input is a threat.
- `caution`: The data provided is inconclusive. Analysts should review this information further. This can be used in error scenarios, such as if the analyzer fails to complete, perhaps due to a remote service being offline.
- `threat`: The analyzer has detected that the input is likely related to a threat.
`error`: [Optional] If the analyzer encounters an unrecoverable error, those details, useful for administrators to troubleshoot the problem, should be placed in this field.
Additional fields are allowed, and should contain data that is specific to the analyzer.
Below is an example of a _urlhaus_ analyzer output. Note that the urlhaus raw JSON is added to a custom field called "response".
```json
{
"response": {
"blacklists": {
"spamhaus_dbl": "not listed",
"surbl": "not listed"
},
"date_added": "2022-04-07 12:39:14 UTC",
"host": "abeibaba.com",
"id": "2135795",
"larted": "false",
"last_online": null,
"payloads": null,
"query_status": "ok",
"reporter": "switchcert",
"tags": [
"Flubot"
],
"takedown_time_seconds": null,
"threat": "malware_download",
"url": "https://abeibaba.com/ian/?redacted",
"url_status": "offline",
"urlhaus_reference": "https://urlhaus.abuse.ch/url/2135795/"
},
"status": "threat",
"summary": "malware_download"
}
```
Users in SOC will be able to view the entire JSON output, therefore it is important that sensitive information, such as credentials or other secrets, is excluded from the output.
#### Internationalization
Some of the built-in analyzers use snake_case summary values, instead of human friendly words or phrases. These are identifiers that the SOC UI will use to lookup a localized translation for the user. The use of these identifiers is not required for custom analyzers. In fact, in order for an identifier to be properly localized the translations must exist in the SOC product, which is out of scope of this development guide. That said, the following generic translations might be useful for custom analyzers:
| Identifier | English |
| ------------------ | -------------------------- |
| `malicious` | Malicious |
| `suspicious` | Suspicious |
| `harmless` | Harmless |
| `internal_failure` | Analyzer Internal Failure |
| `timeout` | Remote Host Timed Out |
#### Timeout
It is expected that analyzers will finish quickly, but there is a default timeout in place that will abort the analyzer if the timeout is exceeded. By default that timeout is 15 minutes (900000 milliseconds), but can be customized via the `sensoroni:analyze_timeout_ms` salt pillar.
## Contributing
Review the Security Onion project [contribution guidelines](https://github.com/Security-Onion-Solutions/securityonion/blob/master/CONTRIBUTING.md) if you are considering contributing an analyzer to the Security Onion project.
#### Procedure
In order to make a custom analyzer into a permanent Security Onion analyzer, the following steps need to be taken:
1. Fork the [securityonion GitHub repository](https://github.com/Security-Onion-Solutions/securityonion)
2. Copy your custom analyzer directory to the forked project, under the `securityonion/salt/sensoroni/files/analyzers` directory.
3. Ensure the contribution requirements in the following section are met.
4. Submit a [pull request](https://github.com/Security-Onion-Solutions/securityonion/pulls) to merge your GitHub fork back into the `securityonion` _dev_ branch.
#### Requirements
The following requirements must be satisfied in order for analyzer pull requests to be accepted into the Security Onion GitHub project:
- Analyzer contributions must not contain licensed dependencies or source code that is incompatible with the [GPLv2 licensing](https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html).
- All source code must pass the `flake8` lint check. This ensures source code conforms to the same style guides as the other analyzers. The Security Onion project will automatically run the linter after each push to a `securityonion` repository fork, and again when submitting a pull request. Failed lint checks will result in the submitter being sent an automated email message.
- All source code must include accompanying unit test coverage. The Security Onion project will automatically run the unit tests after each push to a `securityonion` repository fork, and again when submitting a pull request. Failed unit tests, or insufficient unit test coverage, will result in the submitter being sent an automated email message.
- Documentation of the analyzer, its input requirements, conditions for operation, and other relevant information must be clearly written in an accompanying analyzer metadata file. This file is described in more detail earlier in this document.
- Source code must be well-written and be free of security defects that can put users or their data at unnecessary risk.
---
### Overview (`salt/sensoroni/files/analyzers/elasticsearch/README.md`)
# Elasticsearch
Elasticsearch returns an informational breakdown of the queried observable.
## Overview
Elasticsearch facilitates queries within the user's database. User can use these observable type: hash, domain, file, filename, fqdn, gimphash, IP, mail, mail_subject, regexp, registry, telfhash, tlsh, uri_path, URL, and user-agent values.
## Description
Configure and submit the field you want to search for in your database. Ex: domain, hash, IP, or URL
## Requirement
An API key or User Credentials is necessary for utilizing Elasticsearch.
## Configuration Requirements
In SOC, navigate to `Administration`, toggle `Show all configurable settings, including advanced settings.`, and navigate to `sensoroni` -> `analyzers` -> `elasticsearch`.
The following configuration options are available for:
``api_key`` - API key used for communication with the Elasticsearch API (Optional if auth_user and auth_pwd are used)
``auth_user`` - Username used for communication with Elasticsearch
``auth_pwd`` - Password used for communication with Elasticsearch
``base_url`` - URL that connect to Elasticsearch VM on port 9200. Example format :"https://:9200
``index`` - The index of the data in Elasticsearch database. Default value is _all.
``num_results`` - The max number of results will be displayed. Default value is 10.
``time_delta_minutes`` - Range of time the users want the data in minutes. The value is in minutes and will be converted to days. Defaults value is is 1440.
``timestamp_field_name`` - The name of your timestamp field name. Default value is @timestamp.
``map`` - This is the dictionary of the field name in the user's Elasticsearch database. Example value {"hash":"userhashfieldname"}. This value will map the Security Onion hash field name to user hash field name.
``cert_path`` - This is the path to the certificate in the host for authentication purpose (Required)
This value should be set in the ``sensoroni`` pillar, like so:
```
sensoroni:
analyzers:
elasticsearch:
base_url:$yourbase_url
api_key: $yourapi_key
numResults:$yournum_results
auth_user:$yourauth_user
auth_pwd:$yourauth_pwd
index:$yourindex
timeDeltaMinutes:$yourtime_delta_minutes
timestampFieldName:$yourtimestamp_field_name
cert_path:$yourcert_path
map:$yourmap
```
---
### Overview (`salt/sensoroni/files/analyzers/emailrep/README.md`)
# EmailRep
## Description
Submit an email address to EmailRepIO for analysis.
## Configuration Requirements
``api_key`` - API key used for communication with the EmailRepIO API
This value should be set in the ``sensoroni`` pillar, like so:
```
sensoroni:
analyzers:
emailrep:
api_key: $yourapikey
```
---
### Overview (`salt/sensoroni/files/analyzers/greynoise/README.md`)
# Greynoise
## Description
Submit an IP address to Greynoise for analysis.
## Configuration Requirements
``api_key`` - API key used for communication with the Greynoise API
``api_version`` - Version of Greynoise API. Default is ``community``
This value should be set in the ``sensoroni`` pillar, like so:
```
sensoroni:
analyzers:
greynoise:
api_key: $yourapikey
```
---
### Overview (`salt/sensoroni/files/analyzers/localfile/README.md`)
# Localfile
## Description
Utilize a local CSV file (or multiple) for associating a value to contextual data.
## Configuration Requirements
``file_path`` - Path(s) used for CSV files containing associative data. CSV files can be dropped in the analyzer directory, with ``file_path`` specified like ``mycsv.csv``.
- The value in the first column is used for matching
- Header information should be supplied, as it is used for dynamically creating result sets
- Matches will be aggregated from the provided CSV files
The content of the CSV file(s) should be similar to the following:
Ex.
```
MatchValue,MatchDescription,MatchReference
abcd1234,ThisIsADescription,https://siteabouthings.abc
```
The ``file_path`` value(s) should be set in the ``sensoroni`` pillar, like so:
```
sensoroni:
analyzers:
localfile:
file_path:
- $file_path1
- $file_path2
```
---
### Overview (`salt/sensoroni/files/analyzers/malwarebazaar/README.md`)
# Malwarebazaar
## Description
Submit a gimphash, hash, tlsh, telfhash to Malwarebazaar for analysis.
---
### Overview (`salt/sensoroni/files/analyzers/malwarehashregistry/README.md`)
# Malware Hash Registry
## Description
Search Team Cymru's Malware Hash Registry for a file hash.
## Configuration Requirements
None.
**NOTE:** If you try to run the Malware Hash Registry analyzer but it results in a "Name or service not known" error, then it may be a DNS issue. Folks using 8.8.4.4 or 8.8.8.8 as their DNS resolver have reported this issue. A potential workaround is to switch to another DNS resolver like 1.1.1.1.
---
### Overview (`salt/sensoroni/files/analyzers/otx/README.md`)
# Alienvault OTX
## Description
Submit a domain, hash, IP, or URL to Alienvault OTX for analysis.
## Configuration Requirements
``api_key`` - API key used for communication with the Alienvault API
This value should be set in the ``sensoroni`` pillar, like so:
```
sensoroni:
analyzers:
otx:
api_key: $yourapikey
```
---
### Overview (`salt/sensoroni/files/analyzers/pulsedive/README.md`)
# Pulsedive
## Description
Search Pulsedive for a domain, hash, IP, URI, URL, or User Agent.
## Configuration Requirements
``api_key`` - API key used for communication with the Pulsedive API
This value should be set in the ``sensoroni`` pillar, like so:
```
sensoroni:
analyzers:
pulsedive:
api_key: $yourapikey
```
---
### Overview (`salt/sensoroni/files/analyzers/sublime/README.md`)
# Sublime
## Description
Submit a base64-encoded EML file to Sublime Platform for analysis.
## Configuration Requirements
In SOC, navigate to `Administration`, toggle `Show all configurable settings, including advanced settings.`, and navigate to `sensoroni` -> `analyzers` -> `sublime_platform`.
The following configuration options are available for:
``api_key`` - API key used for communication with the Sublime Platform API (Required)
``base_url`` - URL used for communication with Sublime Platform. If no value is supplied, the default of `https://api.platform.sublimesecurity.com` will be used.
The following options relate to [Live Flow](https://docs.sublimesecurity.com/reference/analyzerawmessageliveflow-1) analysis only:
``live_flow`` - Determines if live flow analysis should be used. Defaults to `False`.
``mailbox_email_address`` - The mailbox address to use for during live flow analysis. (Required for live flow analysis)
``message_source_id`` - The ID of the message source to use during live flow analysis. (Required for live flow analysis)
---
### Overview (`salt/sensoroni/files/analyzers/threatfox/README.md`)
# Threatfox
## Description
Submit a domain, hash, IP, or URL to Threatfox for analysis.
---
### Overview (`salt/sensoroni/files/analyzers/urlscan/README.md`)
# Urlscan
## Description
Submit a URL to Urlscan for analysis.
## Configuration Requirements
``api_key`` - API key used for communication with the urlscan API
``enabled`` - Determines whether or not the analyzer is enabled. Defaults to ``False``
``visibility`` - Determines whether or not scan results are visibile publicly. Defaults to ``public``
``timeout`` - Time to wait for scan results. Defaults to ``180``s
This value should be set in the ``sensoroni`` pillar, like so:
```
sensoroni:
analyzers:
urlscan:
api_key: $yourapikey
```
---
### Overview (`salt/sensoroni/files/analyzers/virustotal/README.md`)
# Virustotal
## Description
Submit a domain, hash, IP, or URL to Virustotal for analysis.
## Configuration Requirements
``api_key`` - API key used for communication with the Virustotal API
This value should be set in the ``sensoroni`` pillar, like so:
```
sensoroni:
analyzers:
virustotal:
api_key: $yourapikey
```
---
--- METRICS ---
- Files Extracted: 14
- Estimated Token Budget: ~7927 tokens
- Canonical Reference: https://codewiki.google/github.com/Security-Onion-Solutions/securityonion