Run Your Application on a STIG-Hardened SQL Server

Your SQL Server-based product runs fine on a default SQL Server. Then a government customer installs it on a STIG-hardened one, and their security team files findings against your product. We review your product against the SQL Server STIGs and redesign it for least privilege, so it installs and runs without sysadmin or db_owner, with documentation your customers’ security teams can work with.

What typically breaks on a STIG-hardened SQL Server

Reliance on broad privilegesThe application or its installer relies on sysadmin, db_owner or other broad permissions, or even checks for sysadmin and refuses to run without it.
Restricted featuresThe product relies on features or settings that a hardened instance disables or restricts.
Shared SQL loginsAll users and services connect through one SQL login, so actions can’t be traced to a person.
Server changes at runtimeThe application changes instance or database settings on its own, which the customer’s baseline doesn’t allow.
Unclear audit trailWith auditing on, the product’s own activity can’t be told apart from that of users and administrators.
Missing documentationThe customer’s security team has no explanation of what the product needs and why.

What we do

  • Product review: your installer, runtime and database design, checked against the SQL Server instance and database STIGs.
  • Least-privilege redesign: no sysadmin or db_owner at runtime, separate installation and runtime privileges, and module signing for the few operations that need more, with an ownership design that doesn’t open new escalation paths.
  • Fix guidance with your developers: for each finding, what to change in the product and how to test it.
  • Documentation for your customers: what your product needs and why, and the reasoning for any requirement it can’t meet as written.
  • Re-checks: after the quarterly STIG updates or your next major release.

What you receive

  • A findings report for your product, with the affected requirement, the evidence and the recommended fix for each finding.
  • A permission design for installation and runtime that your developers can implement.
  • Customer-ready documentation your sales and support teams can hand to a customer’s security team.

Build it into every release

DISA updates the STIGs quarterly, and your product changes with every release. A one-time fix doesn’t stay fixed. We help you make STIG compatibility part of your release process, so new findings show up in your own testing, not at your customer.

Your own SQL Servers, too

This service is about your product. If you also need your own SQL Servers checked against the STIG, our SQL Server Security Assessment can include that, along with the privilege escalation paths and attack paths no baseline lists.

Why Sarpedon Quality Lab

Least privilege in SQL Server is our core expertise. Sarpedon Quality Lab was founded by Andreas Wolter, a former Microsoft Senior Program Manager for SQL Server security and one of only seven Microsoft Certified Solutions Masters (MCSM): Data Platform. Our team includes a co-author of the Azure SQL Database STIG. Meet the team.

How we work

  1. Scoping call: your product, your SQL Server versions and what your government customers require.
  2. Review: on your development or test systems, with a STIG-hardened SQL Server where needed.
  3. Redesign and fixes: together with your developers, tested against the hardened configuration.
  4. Documentation and handover: findings, permission design and customer documentation.

Frequently asked questions

Which SQL Server STIGs do you cover?

The DISA STIGs for SQL Server, which come as separate instance and database STIGs for SQL Server 2016 and SQL Server 2022, and the Azure SQL Database STIG. We check which ones your customers apply before we start.

Does our product have to pass a STIG assessment?

It depends on the contract. Some customers assess the vendor’s product itself; more often, your product simply has to run on the customer’s STIG-hardened SQL Server without causing new findings. We help you find out what your customers expect and prepare for it.

Can our application run without sysadmin or db_owner?

Usually, yes. Installation often needs more privileges than daily operation, so we separate the two. For the few operations that really need more, module signing grants the extra permission only inside the signed procedure.

What if a requirement can’t be met?

Some requirements depend on design or operations. Where your product can’t meet one as written, we document the technical reasoning and the compensating controls, so your customer’s security team can make an informed decision.

Do you certify our product or guarantee STIG compliance?

No. We are not a certifying body, and no one can guarantee compliance up front. Our work happens on your development and test systems, not on your customers’ production systems, and authorization decisions stay with your customer’s assessor or agency. Our findings and documentation help you get through their review.

How often do SQL Server STIGs change?

DISA updates the STIGs quarterly. Each release can bring new or changed requirements, which is why we recommend a re-check with each STIG update or major product release.

Selling a SQL Server-based product to government customers?

Tell us about your product and what your customers require. We’ll tell you where it is likely to break on a STIG-hardened SQL Server.

Request a STIG Product ReviewBook a 20-Minute Call