Preventing certificate related violations in cybersecurity frameworks:  A guide to certificate monitoring across NIST, PCI, and MITRE ATT&CK frameworks

TLS is one of the most widely adopted security protocols in the world allowing for unprecedented levels of commerce across the internet. 

At the core of the TLS protocol is TLS certificates. Organizations must deploy TLS certificates and corresponding private keys to their systems to provide them with unique identities that can be reliably authenticated. As a result, monitoring TLS certificates plays a crucial role in uptime, maintaining trust and preventing fraud. 

But for organizations aligning to popular cybersecurity frameworks by choice through NIST or MITRE ATT&CK or industry requirements like PCI DSS for payment services or HIPAA for healthcare information, certificate monitoring is no longer optional. 

Certificates can be the bane of our existence because they expire and can be misconfigured, but don’t let that overshadow the key role they play in compliance.

This blog explores the requirements of these frameworks for effective certificate monitoring and offers guidance to help security experts enhance their compliance efforts.

Understanding certificate monitoring

Certificate monitoring involves observing a certificate in stages of the lifecycle. This includes at issuance, following deployment, and ahead of revocation or expiration. It is important to note that certificate monitoring is different from certificate lifecyle management.

Without diligent monitoring, expired or compromised certificates can lead to significant security vulnerabilities. As renewal cycles for certificates accelerate and the threat of post-quantum cryptography looms, the need for comprehensive certificate monitoring increases.

🤔Confused about certificate monitoring? Check out our webinar.

Certificate monitoring requirements by framework

NIST (National Institute of Standards and Technology)

NIST’s guidelines on certificate management are encapsulated in several publications, with NIST SP 800-57 Part 1 providing specific recommendations for key management, including the lifecycle of digital certificates. NIST emphasizes the importance of regular audits, secure certificate storage, and timely renewal and revocation.

More recently, NIST Special Publication 1800-16 was dedicated to “Securing Web Transactions: TLS Server Certificate Management.” In this publication, organizations are advised on the risks and organizational challenges related to TLS certificates. Further, NIST provides guidance to ensure that certificates are a security asset instead of a liability including establishing a formal TLS certificate management program with executive leadership, guidance, and support. 

MITRE ATT&CK

Although MITRE ATT&CK does not directly set compliance requirements, it provides a comprehensive matrix of tactics and techniques used by adversaries, including those related to certificate misuse. This framework highlights two specific exploits used by bad actors: 

  • Stealing or Forging Authentication Certificates (Technique T1649). Certificate-related misconfigurations create opportunities for Privilege Escalation, allowing users to impersonate privileged accounts or permissions via the identities associated with a certificate.
  • Certificate Registration (T1588.004). Consider use of services that may aid in the tracking of newly issued certificates and/or certificates in use on sites across the Internet.

Security teams can use MITRE’s framework to anticipate and defend against attacks that exploit certificate vulnerabilities, such as man-in-the-middle (MITM) attacks or the use of fraudulent certificates.

PCI DSS (Payment Card Industry Data Security Standard)

PCI DSS requirements 6.6 mandate the use of SSL/TLS certificates issued by a trusted Certificate Authority (CA). This standard requires that certificates be properly configured and managed to protect cardholder data during transmission. Compliance includes regular scans to detect and rectify unauthorized changes to the configurations and secure certificate renewal processes.

As the world looks towards PCI DSS 4.0, more stringent requirements are being put forth. The new requirement in 4.2.1.1 requires: 

  • An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.
  • All keys and certificates used to protect PAN during transmission are identified and confirmed as trusted.

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Best practices for certificate monitoring

Implementing best practices in certificate monitoring involves a proactive approach. Teams today should be asking themselves three key questions to assess readiness: 

  1. Do I have a complete and current inventory of all of my TLS certificates? This should include new certificates, expired certificates and revoked certificates. If the inventory is constantly changing (which is especially true for teams using multiple CAs), how do you plan to keep this inventory up to date. Doing so requires removing most of the noise so that you can focus on interesting cases. 
  2. Do I have complete issuance history? Issuance history is needed to make sure that ownership is clear. 
  3. Are my certificates configured correctly? Certificates are chained together to establish trust. And connect a leaf certificate to the root certificate. All the individual certificates can be valid but if the chain is misconfigured, trust isn’t established. 

Where do I go from here?

By adhering to the guidelines set forth by NIST, PCI DSS, and utilizing the tactics and techniques outlined in MITRE ATT&CK, organizations can protect themselves against a range of security threats.

We are obviously biased but Red Sift Certificates provides the most comprehensive view of an organization’s certificate estate to make sure compliance requirements are met. If you are interested in learning more about how Red Sift Certificates can help your team discover and monitor all of your certificates, you can request a demo here.

PUBLISHED BY

Rebecca Warren

30 Apr. 2024

SHARE ARTICLE:

Categories

Recent Posts

VIEW ALL
DMARC

Navigating G-Cloud 14 for DMARC solutions: A guide for former NCSC Mail…

Francesca Rünger-Field

Navigating G-Cloud 14 for DMARC solutions: A guide for former NCSC Mail Check users With the NCSC discontinuing key features of its Mail Check service, including DMARC aggregate and TLS reporting, after March 2025, UK public sector organisations must prepare for this change by transitioning to alternative email security solutions. To support this shift,…

Read more
DMARC

Mail Check is changing: What UK public sector organisations must know about…

Jack Lilley

The National Cyber Security Centre (NCSC) has suggested a change to Mail Check services starting on 24 March 2025. This change mainly involves ending DMARC aggregate reporting. This change comes as a measure to expand the services provided by Mail Check to any UK based organisation, while also limiting the cost and complexity of…

Read more
DMARC

Beyond DMARC: How Red Sift OnDMARC supports comprehensive DNS hygiene

Red Sift

Registrable domains and DNS play a crucial role in establishing online identity and trust, but their importance is often taken for granted. During new service setups, record updates are often overlooked, accumulating outdated entries. As infrastructure teams become increasingly overstretched,  services may be incorrectly shut down without proper cleanup, leaving behind a sprawl of…

Read more
DKIM

First look at DKIM2: The next generation of DKIM

Red Sift

In 2011, the original DomainKeys Identified Mail (DKIM1) standard was published. It outlined a method allowing a domain to sign emails, enabling recipients to verify that the email originated from an entity holding a private key that matches the public key published in the domain’s DNS records. Now in 2024, DKIM is ready for…

Read more