By
Your organization’s policies—or lack of policies—regarding trusted root CA certificates are exposing you to unnecessary risk. Because certificates serve as credentials for so many mission-critical transactions, attackers are constantly trying to obtain trusted certificates that can be used in targeted attacks. Systems, for their part, refer to their store of trusted root certificates to determine which certificates to trust. If a certificate is signed by a trusted CA, the system trusts the certificate. To compromise a system, therefore, an attacker simply needs to obtain a certificate that is signed by a trusted root CA—whether by tricking the CA into issuing a fraudulent certificate or by compromising the CA. Every CA that your systems trust represents a potential entry point for attackers.
Many organizations expose themselves to unnecessary risk by allowing far too many of these entry points. They retain the default trust stores distributed with most operating systems and application servers, which include far more certificates than are necessary. According to a University Hannover Germany study, common trust stores for various platforms and operating systems—such as Windows, Linux, MacOS, Firefox, iOS and Android—contained more than 400 trusted root certificates. However, only 66% of these certificates were used to sign HTTPS certificates, leaving the other 34% of trusted root certificates susceptible to use in certificate-based attacks.
We are seeing more and more evidence of malware signed with a legitimate CA because an attacker stole a private key or obtained a fake certificate. Consider the following scenario: Your organization is currently trusting AcmeCA on many of your systems simply because AcmeCA is approved by the vendor providing the software for your systems. If a malicious attacker gains access to a fraudulent certificate from AcmeCA, that attacker can use it to attack multiple systems within your organization.
Your organization has outward-facing systems, such as those focused on customer interaction or users’ desktops, that must trust a particular CA in order to perform day-to-day business. However, your organization also includes systems that don’t need to trust a particular CA but are, in fact, trusting it. For example, internal systems that communicate only with other internal systems don’t need to trust any CAs but the internal CA(s). In addition, partner-focused systems that communicate with a limited number of partners require just a handful of CAs.
Most organizations have no visibility into which root certificates they are trusting and where those root certificates are deployed; consequently, they cannot limit their exposure to certificate-based attacks. As a critical first step, organizations must gain visibility into which root certificates are being trusted within their environment. They must compile an inventory of their root certificates so they can reduce the risks caused by unnecessary trust. In the AcmeCA scenario, for example, you would see that AcmeCA is installed on multiple systems within your organization, determine that these systems don’t need to trust AcmeCA, and remove it. Thus, an attacker would be unable to use a fraudulent certificate from AcmeCA to successfully attack your organization.
By identifying CAs that should not be trusted on mission-critical systems, organizations have the intelligence and risk awareness to prevent attacks that leverage certificates from those CAs. One way to take action is through certificate whitelisting, which ensures that whitelisted certificates are included in trust stores and blacklisted certificates are excluded from trust stores. Certificate whitelisting limits the number of CAs that are trusted, allowing organizations to secure and protect the CAs they trust while flagging or disallowing untrusted SSL/TLS sessions. As a result, the attack surface is dramatically reduced.
Organizations can eliminate unnecessary risk from digital certificates signed by untrusted CAs by establishing and enforcing certificate whitelists and updating which CAs are trusted within the enterprise. They can enforce baseline requirements for which CAs should be trusted (whitelist) and not trusted (blacklist) on mission-critical systems and ensure whitelisted certificates are included in trust stores and blacklisted certificates are excluded, preventing attacks that leverage certificates from blacklisted CAs.
Lorem ipsum dolor sit amet, consectetur elit.
Thank you for subscription
Scroll to the bottom to accept
VENAFI CLOUD SERVICE
*** IMPORTANT ***
PLEASE READ CAREFULLY BEFORE CONTINUING WITH REGISTRATION AND/OR ACTIVATION OF THE VENAFI CLOUD SERVICE (“SERVICE”).
This is a legal agreement between the end user (“You”) and Venafi, Inc. ("Venafi" or “our”). BY ACCEPTING THIS AGREEMENT, EITHER BY CLICKING A BOX INDICATING YOUR ACCEPTANCE AND/OR ACTIVATING AND USING THE VENAFI CLOUD SERVICE FOR WHICH YOU HAVE REGISTERED, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY AND ITS AFFILIATES TO THESE TERMS AND CONDITIONS, IN WHICH CASE THE TERMS "YOU" OR "YOUR" SHALL REFER TO SUCH ENTITY AND ITS AFFILIATES. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS, YOU MUST NOT ACCEPT THIS AGREEMENT AND MAY NOT USE THE SERVICE.
You shall not access the Service if You are Our competitor or if you are acting as a representative or agent of a competitor, except with Our prior written consent. In addition, You shall not access the Service for purposes of monitoring its availability, performance or functionality, or for any other benchmarking or competitive purposes, and you shall not perform security vulnerability assessments or penetration tests without the express written consent of Venafi.
This Agreement was last updated on April 12, 2017. It is effective between You and Venafi as of the date of Your accepting this Agreement.
The Venafi Cloud Service includes two separate services that are operated by Venafi as software as a service, each of which is separately licensed pursuant to the terms and conditions of this Agreement and each of which is considered a Service under this Agreement: the Venafi Cloud Risk Assessment Service or the Venafi Cloud for DevOps Service. Your right to use either Service is dependent on the Service for which You have registered with Venafi to use.
This License is effective until terminated as set forth herein or the License Term expires and is not otherwise renewed by the parties. Venafi may terminate this Agreement and/or the License at any time with or without written notice to You if You fail to comply with any term or condition of this Agreement or if Venafi ceases to make the Service available to end users. You may terminate this Agreement at any time on written notice to Venafi. Upon any termination or expiration of this Agreement or the License, You agree to cease all use of the Service if the License is not otherwise renewed or reinstated. Upon termination, Venafi may also enforce any rights provided by law. The provisions of this Agreement that protect the proprietary rights of Venafi will continue in force after termination.
This Agreement shall be governed by, and any arbitration hereunder shall apply, the laws of the State of Utah, excluding (a) its conflicts of laws principles; (b) the United Nations Convention on Contracts for the International Sale of Goods; (c) the 1974 Convention on the Limitation Period in the International Sale of Goods; and (d) the Protocol amending the 1974 Convention, done at Vienna April 11, 1980.
In the meantime, please explore more of our solutions
In the meantime, please explore more of our solutions
This site uses cookies to offer you a better experience. If you do not want us to use cookies, please update your browser settings accordingly. Find out more on how we use cookies.