Citrix NetScaler’s recently exposed security exploit, which allows attackers to bypass authentication and take full control of the load balancing infrastructure, is frightening. But it is hardly a standalone incident. Every product from every company may eventually succumb to a critical vulnerability. This raises some good questions around security. How does a vendor test the security of their product? If vulnerabilities are inevitable, what is the vendor response and customer strategy?
The news coming out of Hackmageddon, that January reported an unusually low number of Attack Techniques", was quite disturbing. Did the security industry really manage to get the upper hand? Wait for it...oh, here comes another devastating vulnerability!
I recently read an interesting blog post on an ADC vendor’s site that demonstrates a Rube Goldberg approach to showing common SSL information. Now I won’t name names but I will admit that it inspired me to write a quick blog post to show the business-ready alternative to the science project approach!
I recently came across a SaaS company that required support for Perfect Forward Secrecy (PFS) for better SSL security. They bought 4 pairs of [redacted] ADC / load balancers from a proprietary hardware vendor to perform the SSL PFS termination. At first glance, this seems like a safe, logical decision. Just like real estate was a safe and conservative investment strategy in 2006 before the bubble burst, or .com stocks in 2000 right before the stock market's implosion.
I’m pretty certain that whoever first uttered the phrase “anything easy isn't worth having” was no IT administrator. This certainty derives from the seemingly path-of-least-resistance attitude that many enterprises hold when it comes to enforcing stringent levels of encryption security for public infrastructure including their websites. We’ve previously blogged on the excuses many enterprises make for their lax encryption practices, but it’s worth examining what I believe is the primary culprit for this: lack of visibility and insights into their security profiles.
The cold truth: You are rarely secure when you connect to an SSL encrypted web site. The browser shows a happy little lock icon, and you think nothing further on the subject. But recent revelations and exploits, such as NSA, nation states and others scooping up vast quantities of Internet data, courts ordering websites to give up their SSL keys, Heartbleed leaking session data, have proven that we need to revisit the level of security used by web sites.
Load balancers and application delivery controllers have one critical job. No, it's not distributing clients across servers, though that is an important aspect of their job. At its core, a load balancer's task is to reduce risk. One of the most common vectors for the introduction of risk is the complexity of a system, such as a legacy load balancer.
Take an example of a jet engine. It is comprised of numerous components, each adding its own complexity and potential for failure. By taking advantage of new technologies, such as 3D printing, GE has been able to reduce their jet engine's 25 part fuel injection nozzle down to a single part. This helps reduce cost, time to market, and complexity from the overall system, which also improves the reliability of the engine. At its core, it reduces risk. In the context of application delivery and load balancing, what if a single button can guarantee optimal SSL security settings or maximize application acceleration?