Security review
One review of every saved connection: databases, Kubernetes and Elasticsearch clusters, Prometheus (anonymous access and TLS) and Splunk (TLS only). Each control passes, fails or is marked not checked, with the evidence, a suggested fix, and the framework references, ready to hand to an auditor.
Run it
- In the app: Extensions… › Security review › Run Review. Save Evidence Report writes an HTML document you can print to PDF; Export CSV writes a spreadsheet.
- In Ask: attach
/security all(or/security mssql) and ask how secure is our estate? Verbiqo runs the review and explains the failures. - From a terminal:
verbiqo security review
verbiqo security review --system mssql --all
verbiqo security review --connection sales
verbiqo security review --format html --output security-review.html
verbiqo security review --format csv --output security-review.csv
verbiqo security review --format json --output security-review.json --fail-on-findings| Option | Does |
|---|---|
--system pg|mysql|mssql|redis|es|k8s|prom|splunk | One system’s connections only. |
--connection NAME | The connection saved under that name only (in every system that has one, or with --system in that one). |
--format text|json|csv|html | Text for a terminal (--all lists passes too), JSON for a pipeline or your own report, CSV for a spreadsheet, HTML for a document you can print to PDF. |
--output FILE | Writes the report to a file readable by you alone, and prints the counts. |
--fail-on-findings | Exits with status 2 when a control fails, whether the report went to the screen or to --output. |
What it checks
| System | Controls |
|---|---|
| SQL Server | sa disabled; SQL logins enforce the password policy; few sysadmins; xp_cmdshell, Ad Hoc Distributed Queries, CLR, cross-database ownership chaining, Database Mail, OLE Automation, remote access, remote admin connections and startup procedures off; no TRUSTWORTHY user database; connections encrypted; a SQL Server Audit running; full backups within 7 days; a supported version. |
| PostgreSQL | TLS on; remote sessions encrypted; no trust or clear-text password rules in pg_hba.conf; SCRAM, not MD5; few superusers; PUBLIC cannot create objects; a supported version. |
| MySQL | Encrypted connections required and used; root not used remotely; mysql_native_password not in use; password validation; an audit log; local_infile off; secure_file_priv set; a supported version. |
| Redis | A password required (checked by connecting without one); not open on every interface without protected mode; TLS offered; DEBUG and MODULE disabled; a primary with replicas saves to disk. |
| Elasticsearch, OpenSearch | Security on; HTTPS; anonymous requests refused (checked with a request without credentials). |
| Prometheus | Credentials required (checked with a request without them). |
| Kubernetes | A supported version; anonymous requests refused; no application pod that can take over its node; Pod Security enforced and a NetworkPolicy in every application namespace; no service account with cluster-admin; no wildcard roles; no credentials in manifests; workloads off the default service account; Verbiqo’s own account without Secrets. |
| Every system, Splunk included | The certificate controls below. |
Certificates and TLS
For each connection Verbiqo makes a TLS handshake the way a client would, sending no credentials, and checks the certificate the server presents:
- signed by a CA your computers trust (the system’s CAs, the CA in Settings, or the connection’s own);
- more than 30 days left before it expires;
- names the host clients use;
- an RSA key of 2048 bits or more, or an EC key;
- not signed with SHA-1 or MD5;
- TLS 1.2 or later, with TLS 1.0 and 1.1 refused (tried where this computer can still offer them).
PostgreSQL and MySQL are read after their own TLS request; Redis on its tls-port; Elasticsearch, Prometheus and Splunk over HTTPS. SQL Server wraps TLS in its own protocol, so its certificate is read only for connections set to Encrypt: Strict; otherwise these controls show as not checked, with that reason.
Supported version uses the vendors’ published end of security fixes: Microsoft’s end of extended support, the PostgreSQL community’s five-year policy, Oracle’s MySQL support dates, and for Kubernetes the end of upstream patch releases, with a note on EKS, GKE, AKS and OpenShift that the service publishes its own date, which may be later. MariaDB, Aurora and Percona Server are not judged, and neither is any version without a published date: not checked rather than guessed.
Pass, fail and not checked
- Pass and fail come with the evidence that decided them, such as sa (the sa login) is enabled.
- Not checked means Verbiqo could not read what decides the control with the access it was given: a permission not granted (pg_hba.conf rules, msdb history), or a managed service that hides it. It is never counted as a pass.
- A connection that cannot be reached is listed with the reason.
Framework references
Each control is mapped to CIS Controls v8 safeguards, ISO/IEC 27001:2022 Annex A controls and SOC 2 Trust Services Criteria, and, where one exists, the matching recommendation of the CIS product benchmark, named by its title (benchmark numbering changes between versions). The evidence report counts passes and failures per reference.
The mapping helps you prepare evidence; it is not a certification. Your auditor decides what a control requires.
Safe to run
The review reads through the same read-only accounts, guards and limits as any question, one connection at a time, and every read is on the access record. Your organization’s policy decides which systems it may read.