Trust Is a Necessity, Not a Luxury
Blog Article Published: 10/13/2014
By Tammy Moskites, Chief Information Security Officer, Venafi Mapping Certificate and Key Security to Critical Security Controls I travel all over the world to meet with CIOs and CISOs and discuss their top-of-mind concerns. Our discussions inevitably return to the unrelenting barrage of trust-based attacks. Vulnerabilities like Heartbleed and successfully executed trust-based attacks have demonstrated just how devastating these attacks can be: if an organization’s web servers, cloud systems, and network systems cannot be trusted, that organization cannot run its business. Given the current threat landscape, securing an organization’s infrastructure can seem a bit daunting, but CISOs aren’t alone in their efforts to protect their critical systems. Critical controls are designed to help organizations mitigate risks to their most important systems and confidential data. For example, the SANS 20 Critical Security Controls provides a comprehensive framework of security controls for protecting systems and data against cyber threats. These controls are based on the recommendations of experts worldwide—from both private industries and government agencies. These experts have realized what I’ve maintained for years—just how critical an organization’s keys and certificates are to its security posture. What can be more critical than the foundation of trust for all critical systems? As a result, the SANS 20 Critical Security Controls have been updated to include measures for protecting keys and certificates. Organizations need to go through their internal controls and processes—like I’ve done as a CISO—and ensure that their processes for handling keys and certificates map to recommended security controls. For example, most organizations know that best practices include implementing Secure Socket Layer (SSL) and Secure Shell (SSH), but they may not realize that they must go beyond simply using these security protocols to using them correctly. Otherwise, they have no protection against attacks that exploit misconfigured, mismanaged, or unprotected keys. SANS Control 12 points out two such common attacks for exploiting administrative privileges: the first attack dupes the administrative user into opening a malicious email attachment, but the second attack is arguably more insidious, allowing attackers to guess or crack passwords and then elevate their privileges—Edward Snowden used this type of attack to gain access to information he was not authorized to access. SANS Control 17, which focuses on data protection, emphasizes the importance of securing keys and certificates using “proven processes” defined in standards such as the National Institute of Standards and Technology (NIST) SP 800-57. NIST 800-57 outlines best practices for managing and securing cryptographic keys and certificates from the initial certificate request to revocation or deletion of the certificate. SANS Control 17 suggests several ways to get the most benefit from these NIST best practices. I’m going to highlight just a couple:
- Only allow approved Certificate Authorities (CAs) to issue certificates within the enterprise (CSC 17-10)
- Perform an annual review of algorithms and key lengths in use for protection of sensitive data (CSC 17-11)
- Do you have policies that specify which CAs are approved?
- Do you have an auditable process that validates that administrators must submit certificate requests to approved CAs?
- Do you have a timely process for replacing certificates signed by non-approved CAs with approved certificates?
- Do you have an inventory of all certificates in your environment, their issuing CAs, and their private key algorithms?
- Do you have an inventory of all SSH keys in your environment, their key algorithms, and key lengths?
- Do you have a system for validating that all certificates and SSH keys actually in use in your environment are listed in this inventory?