Organizations—from service providers, banks, and retailers to government agencies—were recently blindsided by the Heartbleed bug, a critical vulnerability in the OpenSSL cryptographic software library, which underlies trust for secure transactions worldwide. Attackers wasted no time exploiting the vulnerability, which allows them to extract private Secure Socket Layer (SSL) keys with absolute ease. They can read any of the sensitive information that customers have entrusted to the organization’s now-compromised security. To protect their data and their customers, organizations had to respond even more quickly than attackers. They had to assess their vulnerability, determine which systems were using OpenSSL certificates, and then take the steps necessary to re-establish trust, including updating OpenSSL, replacing certificates, and generating new keys.
Unfortunately, most organizations are ill-equipped to respond to trust-based vulnerabilities and threats—especially in such an abbreviated timeframe. As noted in a study by the Ponemon Institute, most enterprises have as many as 17,000 certificates but few control and secure those certificates, making it difficult for their IT security teams to find and replace vulnerable certificates. As a Chief Information Security Officer (CISO) with over 25 years’ experience in IT security, compliance and identity management; with many of those years as an executive leader, I have spent a lot of time analyzing why companies aren’t protecting their precious cryptographic assets and how they can improve their security practices.
The oversight, I think, stems mainly from lack of awareness. Most organizations simply do not realize the extreme danger trust-based attacks pose. For many years, organizations have focused almost entirely on defense in-depth as a way of ensuring confidentiality, integrity, and availability (CIA). They rely heavily on Intrusion Detection System (IDS)/Intrusions Protection System (IPS) solutions to protect their systems and data from attacks. As effective as IDS/IPS solutions can be in mitigating attacks, many of these solutions cannot see into encrypted traffic, making it difficult, if not impossible, for them to detect attacks that exploit certificates and keys.
Many organizations also fail to understand the importance of protecting their SSH keys—leaving them open to the same type of abuse Edward Snowden used to breach security at the U.S. National Security Agency (NSA). SSH keys are a particularly easy target because SSH keys don’t expire and most enterprises don’t rotate their SSH keys. Further compounding their vulnerability, many organizations fail to track who has access to SSH keys. When administrators leave the company, they all too often take SSH keys with them, giving them ongoing privileged access to the organization’s systems.
With the sharp increase in trust-based attacks, organizations must modify their traditional CIA security models to include securing their certificates and keys. After all, certificates and keys are used to ensure confidentiality, permitting only authorized recipients to view protected data. If an attacker compromises a certificate or key, that confidentiality is no longer assured. And any IT security professional charged with ensuring availability must understand: controlling the keys and certificates on which systems rely prevents costly outages.
Organizations must take into account the critical role cryptographic assets play in ensuring confidentiality and availability because they can no longer afford to be blindsided by trust-based attacks. In my years as an IT security professional, I have assembled best practices for securing certificates and keys--practices that ensure that the trust organizations and their customers place in these vital assets is well-founded. Organizations must inventory their certificates and keys so that when a vulnerability is discovered, they can accurately assess their risk exposure. They must have policies and automated solutions for rotating keys so that they can quickly close the vulnerability. They must also be able to monitor the use of SSL and SSH keys so that they can detect suspicious behavior that flies under the radar of traditional IDS/IPS solutions.
In future blogs, I'll give you in-depth insight into each of these practices, keep you up-to-date on the latest trust-based exploits, and help you discover the best ways to protect yourself. In addition, I will throw in some blogs on leadership, competency focus areas and ideas on staffing security roles—which I know is always a challenge!
I am looking forward to having you join me each month!
Cheers!
Tammy Moskites, Venafi CISO
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.