Database and Web Server Configuration Review

The review covers the common engines and servers that have a published hardening baseline: SQL Server, Oracle, MySQL and PostgreSQL on the database side, and Apache, Nginx and IIS on the web side, each measured against its matching CIS Benchmark. Scoping is where the edge cases get settled. During the 30-45 minute scoping call we inventory the engines, versions and hosting locations you actually run, including the reverse proxies that are easy to forget, and we say plainly which of them have a published benchmark and which do not. Where an engine has none, we do not pretend otherwise: we review it against the vendor hardening guide and the relevant NIST SP 800-53 controls instead, and the report records which baseline was used for that instance. You receive a written scope naming the instances included, with a timeline and a fixed price, before work begins.

Five things drive the review: authentication, encryption in transit, access control, logging, and management interfaces that should not be reachable. On the database side that means default and shared accounts, weak SQL authentication modes, the object-level grants held by service logins, and whether audit logging captures privileged activity rather than only failed logins. On the web side it means TLS protocols and ciphers per endpoint, exposed configuration files, status and admin handlers left open, and modules loaded for no reason. What is left out: we read configuration, so we do not audit your key custody and rotation processes, and we do not read the data itself. Encryption at rest sits outside the scope of this review as well. Those questions belong in a compliance engagement rather than a hardening review, and we will say so at scoping.

Yes, and the reason is that the bulk of the work is read-only. One phase exists purely to collect evidence: parameters, startup settings, logins, roles, grants, configuration files and certificate details are exported as read-only evidence, which places no more load on an instance than a monitoring query does. Active checks are the narrow exception. Benchmark scanning, TLS grading and the read-only sqlmap validation run against the instances you nominated during scoping, at times you choose, and nothing in that set is destructive. Which instances allow safe active validation is agreed in the first phase, before anyone connects. Findings are reproduced by hand and carry proof of concept, so you are not chasing a scanner's guess during a maintenance window. The findings phase also separates the settings you can change live from those that need a restart, so remediation is sequenced around your maintenance windows rather than ours.

The artefact auditors ask for is the CIS benchmark scorecard per instance, and you receive one for each database and web server in scope. It names the instance, the baseline it was measured against, which checks passed and failed, and the CIS control number behind each failure. That is what makes it usable as evidence for a configuration-baseline control, rather than a screenshot somebody took once and filed. The same single pass is graded against the DISA STIGs and NIST SP 800-53 as well, so you are not funding the work again per framework. The re-check at the end matters as much as the first scan: a scorecard showing a failure closed and re-verified is stronger evidence than a remediation ticket marked done. If the wider control programme is what you are building, our ISO 27001 and PCI DSS services carry that side.

This review examines how the tiers are configured; application testing examines what your code does with them. The line is easiest to see through an example. If a web server exposes a directory listing, negotiates TLS 1.0, or a database service account holds write access to tables it only reads from, those are configuration findings and they belong here. If a search field concatenates user input into a query and returns another tenant's rows, that is an application flaw and it belongs in a penetration test, even though the damage lands in the same database. The read-only sqlmap checks in phase four sit deliberately on the configuration side of that line: they confirm exposure on endpoints you nominated, and they are not a substitute for testing the application. Our Web Application penetration testing service covers that, and the two pair well in one window.