![Creating Certificate Policies for DevOps: Managing Machine Identities in Hybrid Clouds [Part 5] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F77193021-5abb-4099-9a3e-ca2a16b5df88%2Faid_field_img__fa32a06cb6e1a660517899bc426b9f6b.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_3EAuLccmwaq4KZ9GcZftJq5NbwLA){kind=small}
Why defining security policies isn't an option anymore
In my first few posts in this series, I discussed the growth of hybrid cloud in enterprises, the challenges of protecting machine identities ,the risks you’ll need to overcome in managing machine identities in hybrid clouds and why you should consider a cloud agnostic security strategy. And now let’s look at why it’s critical that you define and enforce security policies to ensure consistent certificate security across your hybrid cloud.
In order to address the challenges of building and maintaining a secure hybrid cloud environment, the strongest asset in an organization’s arsenal is one, consistent policy. This policy will allow any organization to manage both their infrastructure and their machine identities located on-premises as well as in the public cloud environment.
The problem is that only a small percentile of digitally transformed businesses has developed a consistent, enterprise-wide policy for their multi-cloud environment. Developing a consistent security policy should be part of an organization’s digital transformation strategy. The most important element is to identify security needs early enough and to implement a consistent security policy in advance to migrating to a hybrid cloud setup. The cloud computing security policy should consider aspects such as network security, unprotected APIs, risk assessments, regulatory compliance, data redundancy and proper authentication.
Tale of 3 Clouds eBook: How Venafi Creates Digital Transformation
What should the policy contain?
To effectively address the risks and challenges related to TLS server certificates and to ensure that they are a security asset instead of a liability, organizations should establish a formal TLS certificate management program with executive leadership, guidance, and support. This program should include clearly defined policies, processes, and roles and responsibilities for the certificate owners and the Certificate Services team, as well as a central Certificate Service. The program should be driven by the Certificate Services team but should include active participation by the certificate owners—whether the certificate owners are responsible for traditional servers, appliances, virtual machines, cloud-based applications or DevOps.
NIST SP 1800-16B recommends that an enterprise-wide certificate management policy should include the following requirements and best practices.
These requirements are bonded with recommended roles and responsibilities. NIST says that it isn’t necessary to implement all requirements. First, we need to identify the stakeholders who are needed to define and enforce the policies. Pick the policies we need, the ones that better address the most important risks to the organization and adapt them to the needs of the organization. Then, we need to review the tailored requirements with all stakeholders to determine whether they are achievable, and they address organizational risks. As a final step, we should define who is responsible to do what. Accountability is the factor that drives success.
In order to ensure policy implementation, we should make sure to gain sponsorship from executives so that they understand and support the requirements and responsibilities. Executive and leadership sponsorship can help enforce the policies, roles and responsibilities.
The recommended requirements and best practices can be mapped to the Visibility, Intelligence and Automation elements of our policy as the image below shows.
As discussed beforehand, not all requirements are applicable to all computing environments. The requirements that are applicable and of importance for a multi-cloud computing environment are the ones shown and discussed below.
Inventory
The requirement for establishing and maintaining an inventory in a hybrid cloud environment is justified by the need to have a clear visibility across all TLS server certificates in the environment to:
- detect potential vulnerabilities,
- identify certificates that are nearing expiration and replace them,
- respond to large-scale cryptographic incidents, such as a CA compromise, vulnerable algorithms, and cryptographic library bugs
- ensure compliance with regulatory guidelines and established organizational policy
In a hybrid cloud environment, where visibility is required across multiple computing platforms, it is recommended to maintain a single central inventory, as it minimizes the possibility of overlooking critical TLS server certificates.
Approved CAs
CAs are trusted issuers of certificates. Digitally transformed organizations, employing multiple computing platforms should control the CAs issuing certificates in their environments, to prevent potential risks such as:
- Increased costs
- Trust issues which can result in outages
- Fraudulent certificates due to CA misconfiguration
- Unexpected CA incidents, such as CA compromise or being untrusted by browser vendors
Controlling your approved CAs is of essence in a hybrid cloud environment to ensure CA agility and prevent CA related outages that can harm business continuity in urgent situations such as CA compromise or incident.
Security of private keys
Private keys corresponding to TLS certificates must be kept secret to prevent compromise. Instead of protecting private keys in FIPS 140 validated Hardware Security Modules (HSMs), often, these private keys are stored in plaintext files, or encrypted with passwords stored in plaintext configuration files. In a hybrid cloud environment, security “in the cloud” is the sole responsibility of the cloud services customer. Therefore, organizations operating in hybrid cloud environment should assess the criticality and risk of each TLS server and determine the appropriate level of protection required for private keys. Further, organizations should ensure that only authorized personnel have access to private keys and that the authorized personnel are trained in the processes necessary to keep the private keys secure.
Rekey upon termination or reassignment
When system administrators manage manually TLS server certificates and associated private keys, it is possible that they make copies of these private-key files. Consequently, if a system administrator is reassigned or terminated, then the private key and certificate should be renewed with a new key pair and certificate, and the previous certificate should be revoked, to prevent any malicious activities with the original private key and certificate. If automation is used for the management of certificates and private keys and if direct access by system administrators is limited (via access controls and audit logging on any access), then certificate owners can avoid replacing certificates when a system administrator is reassigned or terminated.
Crypto-Agility
There are several incidents that can require organizations to rapidly replace large numbers of certificates and private keys, including CA compromise or distrust, vulnerable algorithms, or bugs in cryptographic libraries. There have been multiple examples of these incidents in recent years, including the CA compromise of DigiNotar, the distrust of Symantec certificates by browser vendors, the deprecation of SHA-1 for signature generation, and cryptographic library bugs in Debian and Infineon. In addition, the industry is preparing for a transition to quantum-resistant algorithms, which will require organizations to replace large numbers of certificates and private keys. Organizations employing hybrid cloud environments should be able to transition between various CAs as a response to either an unexpected cryptographic incident or technological advances. What is more important in such a heterogeneous environment is the ability to track certificate replacement to be aware which systems are updated and which are not.
Continuous Monitoring
In a hybrid cloud environment, secure communications are of utterly importance. All mission critical communications require a broad number of TLS server certificates, hence operational or security failures related to TLS server certificates can significantly impact the business operations of organizations. TLS certificates should be continuously monitored to prevent outages and security vulnerabilities. The certificates should be monitored for impending expiration; for situations in which they are not operating, are not configured properly, or are vulnerable; and for situations in which they are not consistent with policy.
Logging TLS server certificate management operations
TLS server certificates serve as trusted credentials that authenticate servers for mission-critical applications. Just as logging data access is required for forensics and other purposes, logging all certificate and private-key management operations is critical. Organizations operating in a hybrid cloud environment have complete responsibility of machine identities and therefore they should ensure they have a complete chain of custody for private keys and certificates that includes a log of all operations, including key-pair generation, certificate requests, request approval, certificate and key installation, the copying of certificates and keys (e.g., for load-balanced applications), certificate and key replacement, and certificate revocation. In such a decentralized computing environment it is of essence for logs to be collected and stored in a central location so the complete chain of events for certificates and private keys can be reviewed when necessary.
TLS traffic monitoring
While providing authentication and confidentiality for legitimate communications and operations, TLS can also be used by attackers to hide their operations, such as scanning for vulnerabilities, leveraging vulnerabilities for privilege escalation, denial-of-service operations, and data exfiltration. Depending on organizational policy, in addition to monitoring the content of TLS communications for external-facing systems, organizations may monitor TLS communications between internal systems to retain the ability to detect attackers who are either attempting to move laterally between internal systems to gain access to critical data or exfiltrating compromised data. This monitoring may be accomplished in a variety of ways, including via proxy, end point software, or passive decryption. In a multi cloud environment, where applications and data cross multiple cloud platforms, TLS traffic monitoring can be of significant value.
Automation
The broadening use of and reliance on TLS server certificates to secure important applications is rendering manual certificate management impractical. Risks such as certificate-related outages are often the result of errors made while manually managing certificates. Organizations are unable to manually replace large numbers of certificates in response to large-scale cryptographic incidents, such as CA compromises, in a timely manner. Consequently, organizations should work to automate certificate management on as many systems and applications as possible to decrease security and operational risks. New automation tools (e.g., DevOps) and protocols have increased the methods and options by which automated certificate management can be successfully performed. Consequently, organizations should define clear guidelines and policies for automation and for when continued manual management is justified due to operational or organizational constraints.
How much certificate management do cloud services provide?
Once we have defined our policy requirements, it is useful to look at what cloud services providers offer. AWS, for instance, has a native certificate manager which “is a service that lets you easily provision, manage, and deploy public and private SSL/TLS certificates for use with AWS services and your internal connected resources. AWS Certificate Manager removes the time-consuming manual process of purchasing, uploading, and renewing SSL/TLS certificates,” reads the provider’s website. On the other hand, Azure Key Vault “enables Microsoft Azure applications and users to store and use several types of secret/key data” and “helps solve” the problems of key and certificate management and their secure storage.
All these seem quite promising, but the question that arises is “Can cloud services providers really meet our policy requirements?” If we compare the services offered by either AWS Certificate Manager or Azure Key Vault as opposed to the defined policy requirements, we would want to evaluate the following capabilities:
- Out-of-the-box integrations for multiple CAs
- Certificate inventory that’s consistent with on-premises CAs
- Certificate filtering tools
- Automated renewals for multiple CAs
- Certificate expiration reports
- Flexible renewal timeframes
- Short-lived certificates for containers
- Self-service permissions
- Centralized management across cloud, on-premises and mobile
While a number of these capabilities are supported by cloud services providers (CSPs), many have limited functionality beyond the cloud providers environment. Relying solely on native certificate management solutions offered by CSPs may introduce a wide array of inherent limitations.
That is one great reason why you should consider making sure that your certificate security policy and strategy is cloud agnostic so that your organization reaps the benefits of hybrid cloud computing without jeopardizing certificate and key security.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts