One of the most significant OpenSSL security vulnerabilities is the latest Heartbleed OpenSSL security flaw (CVE-2014-0160). This OpenSSL security vulnerability is again a re-affirmation that usage of C-based security modules by an enterprise company greatly increases its risk posture. You can be certain that IT security folks out there felt that they were making the right architectural decisions to secure the enterprise. The problem isn’t the intent, the problem is the premise. Applications, wrapped in security band-aids , is not a sound enterprise risk mitigation strategy. Sure, Apache and OpenSSL are widely available and have been around for a long time, but look where it has led us.
End-Mile SSL Security is Dead
The Heartbleed security flaw may represent the inflection point where the industry finally recognizes the need for enterprise-class security systems that provide SSL security processing separate from the application environment. The days of end-mile SSL security should be over after the dust settles from this debacle.
Why would you want to continue to manage keys in a distributed fashion, use technology that has not been industry hardened, and wait until the next exploit is published? Make no mistake, an unpublished exploit does not mean an undiscovered exploit. Using OpenSSL or other C-based libraries for security is an exposure, plain and simple. This recent vulnerability was introduced in December 2011 and it has been published in April 2014 – over 2 years the adopters of OpenSSL considered themselves secure. A full list of OpenSSL vulnerabilities can be seen here, a list of exploits that continues to grow. Hindsight awareness is not security.
The Secure Reverse Proxy Solution
At Forum Systems, we built the Forum Sentry API Security Gateway as a secure reverse-proxy that provides a centralized location for SSL processing and key management. Forum Sentry does not use OpenSSL. As detailed in the article Predictions from 2002-2003: Heartbleed = Criminal Negligence, from our inception as a security company, we have maintained a code pedigree and assurance on industry standards and independent certifications such as the NIAP Network Device Protection Profile (NDPP). This ensures that our security code and capabilities are held to the highest of standards, and this is also why our customers choose our solution over other industry solutions. The simple fact is that there is a huge difference between “an integration product with security features” and “a security product with integration features”.
By deploying an API Gateway as an intermediary, you remove the need to manage keys and key-stores on end-mile services and applications. This deployment process is completely seamless and it will not impact your clients or services at all. Often the only change required is a minor update on the load balancer or a DNS entry change.
The benefits of a centralized security model are clear:
-
One location to manage the keys
-
Secure Storage of the key information to ensure no ability to compromise
-
Use of tight memory bounds checking and code that is not susceptible to over-flows, under-flows, or other memory exploits
-
One location for remediation issues, should they occur
- Every application and service behind the Gateway is secured
The ROI of Security
It’s not often that risk mitigation can be easily monetized as it takes events such as Heartbleed event to truly highlight the impact of a weak architecture and technology. Witnessing first-hand costs of lost passwords, lost keys, and lost trust is a hard lesson to learn, but many are tabulating those costs as they remediate this issue. Consider for example, the following remediation steps that are necessary for companies exposed to Heartbleed must take:
- Upgrade your OpenSSL libraries
- Generate new public-private key pair
- Issue CSRs to your CAs
- Install the new X.509 certs on all of your servers
- Issue advisories to all of your users, customers, and trading partners
- Have all of your users change all of their passwords and X.509 certificates
- Block all session cookies issued prior to the OpenSSL upgrade
- Enforce X.509 revocation checks on all servers
Indeed the ROI of security is hard to measure when things are going well. It’s starkly evident when you are exposed. Forum Sentry customers did not need to do anything to mitigate Heartbleed, that’s about as good as you can get for an ROI.
Patching OpenSSL Does Not Protect You Against the Next Exploit
Patch and forget, or is it patch and hope? The modern era of computing and the nature of security exploits demands a more pragmatic approach to security. Through intelligent architectural design, the use of API Security Gateway technology can reduce the risk of end-mile and unsecured technology products. It can do so without impacting the business goals and ability to facilitate secure business integration. In fact, this is the primary goal of API Security Gateway technology to enable business communication without sacrificing performance or security. Move away from ‘patch and hope’ era and move into the modern era of API Gateway security protection.