Last month I co-presented a webinar with ISIGHT Partners, a leader in cyber-threat intelligence, to discuss a white paper that exposes how keys and certificates can be used for nefarious intentions. Our purpose was to highlight some of the tactics malicious actors use and outline their profiles in relation to keys and certificates. Due to time constraints, we did not cover how most organizations expose themselves to cryptographic vulnerabilities simply because keys and certificates are viewed as an operational problem and not as a security issue that needs to be addressed immediately!
For example, for most organizations today, the most critical element of certificate management is monitoring the validity period—that is, the certificate’s expiration date. The reason is simple: if a certificate expires, it will result in a service outage. Most organizations track validity periods either in a spreadsheet or a portal such as SharePoint. Disappointingly, there are many public examples of failure to manage even the expiration date of certificates—such as the Microsoft Azure outage earlier this year—let alone the actual security configuration of a certificate.
Secure Shell (SSH) keys, on the other hand, do not have expiration dates that organizations must track. Instead organizations need to have a clear understanding of where SSH private keys are stored and control the systems to which certain individuals have access. In most organizations, it is up to the application administrator or SSH administrator to track this information. Unfortunately, in most organizations, numerous individuals manage the keys, using disparate management practices, and no one can determine how SSH keys are being used in the network. Take for example how Edward Snowden breached the National Security Agency (NSA) as an illustration of the SSH key management shortfall at the NSA.
Encryption keys and digital certificates provide the backbone of trust across corporate networks and the Internet. In planning for future expansion, organizations need to understand and appreciate that the digital universe is expanding at an alarming rate. If organizations can’t perform rudimentary key management today, how will they cope with both the volume of keys and certificates as more are consumed, and how will they manage and protect them?
This is exactly why malicious actors are increasingly taking advantage of keys and certificates as an attack vector, making them the perfect trust threat. For example, malicious actors can:
Organizations need to stop viewing keys and certificates as a basic operational issue and start understanding that they can be a serious threat to their business if they are not secured and protected.
The question is, what do organizations do about the fact that they require keys and certificates to establish trust, but malicious actors are exploiting that trust and using it against them? There is light at the end of tunnel; organizations can still use keys and certificates to establish the trust they need in the digital world, but they don’t need to accept that keys and certificates will be used against them. That’s not to say it will never happen because chances are most organizations have already been compromised, but there are ways to limit key and certificate threat exposure and respond and remediate quickly if an organization is compromised.
When it comes to key and certificate security, organizations must know their key and certificate inventory. They must also understand key and certificate attributes and make sure they are configured to meet recommended security guidelines while not impeding business goals. To do this, organizations need to scan their enterprise networks on a regular basis to address key areas:
When organizations configure cryptographic keys and digital certificates, they should follow best practice guidelines that factor in known exploits and improvements in technology. Organizations can consult standards bodies such as the National Institute of Standards and Technology (NIST), which provide recommendations for cryptographic resources. For example, NIST has established a minimum key size of 2048 bits, stating that 1024-bit keys should no longer be used after December 31, 2013. The hashing algorithm SHA-1 has suffered the same fate<.
By enforcing standards that meet minimum security requirements, organizations can protect their network resources against potential exploits such as the BEAST exploit. However, organizations should keep in mind that evaluating singular attributes on their own will not adequately protect their network resources against breaches. As an example, when evaluating an IT infrastructure’s weakness against the BEAST exploit, organizations need to take into consideration the version of Transport Layer Security (TLS), the cypher suite, and the configuration used. Evaluating each of these factors individually would not bring to light the vulnerability.
Simply identifying the key and certificate inventory will not help organizations detect rogue usage of an SSH key or malware that is using a self-signed certificate to encrypt command and control (C2) traffic. To detect these issues, organizations need to understand the key and certificate inventory and the policies being enforced—all of which were addressed in the first step. Organizations must then frequently scan the environment so that they can detect any rogue keys or certificates that may have been maliciously placed in the network. If a rogue key or certificate is detected, organizations can investigate how it is being used and take action.
As the use of keys and certificate as an attack vector continues to rise, organizations need to take responsibility in securing and protecting the very trust that is established by keys and certificates. Treating them as an operational issue will only result in opportunity for malicious actors to compromise networks. Regularly evaluating the network to detect key and certificate vulnerabilities is the only way to mitigate key and certificate based attacks.
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.