Security Threat Tool (STT) is the new Percona Monitoring and Management (PMM) feature. It provides the ability to run automated security checks across all of your databases and detect potential security problems. For example: empty or default passwords, weak security settings, outdated database versions, misconfiguration, but also more complex and tricky issues.
Security checks developed independently from PMM releases, therefore PMM server downloads, via HTTPS, a list of available security checks from Percona servers each time before starting the STT cycle. Downloaded data is a single, signed YAML file. We use minisign – libsodium based tool for singing and verification. PMM server contains embedded public Percona keys for signature verification.
STT check itself is a database dependent query and a script that processes the query result.
1 2 3 4 5 6 7 8 9 10 11 12 | --- checks: - version: 1 name: mongodb_version type: MONGODB_BUILDINFO script: <script text> - version: 1 name: mysql_empty_password type: MYSQL_SELECT query: '* FROM mysql.user' script: <script text> |
The check type field describes the target database type and query statement. For example: MYSQL_SHOW, POSTGRESQL_SELECT, MONGODB_GETPARAMETER, etc. Some checks have an empty query field. In that case, PMM server uses a hardcoded query, which typically returns a wide range of rows. For checks that require specific data to be selected, the query field contains an incomplete query. For security reasons, it doesn’t contain statements, such as SELECT, SHOW, etc. PMM concatenates these statements to the content of the query field. For instance, for type MYSQL_SELECT, a query field can contain:
* FROM mysql.user.
And after concatenation the resulting query will be like:
SELECT * FROM mysql.user.
This approach prevents the execution of queries that could harm the user’s data. STT uses only queries that don’t modify or somehow affect any data and this restriction is made on the PMM side.
Relevant PMM agents execute the resulting query on connected databases and return a serialized set of rows to the PMM server. After that, the server processes the response with the script that detects security threats.
The script takes a set of rows as a single parameter and returns alerts in case it detects any problem. We use Starlark as a scripting language, which was originally designed by Google for its build system Basel. Technically Starlark is a Python dialect and it has great integration with Go, the main language of the PMM server. The server provides some prepared functions for different check versions. For example, the first version of the STT environment provides a function for parsing semantic version, that is used for detecting outdated database versions. STT scripts can’t do any input/output, can’t access the host machine, and can’t do any interaction with the environment. They can operate only on a query result.
As a final step, alerts are published to Prometheus Alertmanager, one of the PMM server components. PMM UI uses that data to show the number of problems and detailed information about each of them. For now, any configuration or integration with that built-in alertmanager is not supported. However, we have big plans for alerting, and some features already in our roadmap.
