DoD STIGs – V-32475

Overview:

Title: The DBMS, when utilizing PKI-based authentication, must validate certificates by constructing a certification path with status information to an accepted trust anchor.

Vulnerability ID: V-32475

STIG ID:

IA Controls: None

Severity: medium

Description: A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.

When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be for example a Certification Authority (CA). A certification path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA.

Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted.

Status information for certification paths includes certificate revocation lists or online certificate status protocol responses.

Database Management Systems that do not validate certificates to a trust anchor are in danger of accepting certificates that are invalid and or counterfeit. This could allow unauthorized access to the database.

Check Text: Review DBMS configuration to verify the certificates, being accepted by the DBMS, have a valid certification path with status information to an accepted trust anchor. If certification paths are not being validated back to a trust anchor, this is a finding.

Fix Text: Configure the DBMS to validate certificates by constructing a certification path with status information to an accepted trust anchor.

[divider]

Interpreting V-32475:

A trust anchor (or trust “point”) is a public cryptographic key for a signed zone. Trust anchors must be configured on every non-authoritative DNS server that will attempt to validate DNS data. When SQL Server is configured to use certificates for SSL and other encryption only properly trusted certificates should be used. If a non-trusted certificate is used, SQL Server raises warnings that the certificate is not trusted. For example, if using an un-trusted (self signed perhaps) certificate for SSL connectivity to SQL Server, you must configure the connection strings to use non-trusted server certificates, or you will not be able to connect and work in SQL as expected.

More information about Trust Anchors can be found here.

Return to the DoD STIGs – Database Security Requirements Guide

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.