Out of Sight, Out of Mind? With Security, That’s Out of Your Mind.

Nathan McMahon
Posted on Aug 4, 2015 5:00:00 AM


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.

How many enterprise IT administrators can say they truly have a firm grasp into their security practices? For example, can they rattle off what encryption protocols, cipher suites, and certificates that are currently running on specific servers, client devices, and web browsers? What versions of these devices are they even running? As an enterprise becomes larger and more distributed, these questions become naturally harder to answers, meaning that implementing security and encryption-best practices become that much more complex. You can almost understand why many IT admins might take the “out of sight, out of mind” stance. Almost.

Out of mind quickly turns into out of your mind when the inevitable “oh bleep” event happens. Let’s look at this using a recent real-world scenario. Let’s say this is October 2014 and you are alerted to the security advisory on POODLE, which specifically infiltrates vulnerabilities in systems running legacy encryption protocols. Soon enough, this issue has made it to the media and now even your CIO is calling you to go “kill off poodles” lurking in the system (the CIO doesn’t have a security background). The workaround solution for this situation is actually pretty straight forward as reported by this popular security blog:

The obvious and correct solution to this problem is find and kill SSLv3 anywhere it lurks. In fact, this is something we should have done in the early 2000s, if not sooner. We can do it now, and this whole problem goes away. The problem with the obvious solution is that our aging Internet infrastructure is still loaded with crappy browsers and servers that can't function without SSLv3 support. Browser vendors don't want their customers to hit a blank wall anytime they access a server or load balancer that only supports SSLv3, so they enable fallback.

The key points are in the second part of the paragraph. Yes, many servers, clients, servers still support and run on SSLv3. But how many? And yes, most companies might prefer incurring more security risk vs. severely undermining the user-experience on their public websites. So, without a clear understanding on how many devices may be impacted and the full extent of the impact of turning off SSLv3, IT admins may be resigned to asking questions like this instead of taking immediate action. Or worse, they may end up rolling the dice and taking no action because the unknown can be even more frightening than the known. Unfortunately, here’s what the “known” looks like in many enterprise security profiles today:

root@pm-lab-mgmt:~# openssl ciphers


You can see why even basic troubleshooting, impact analysis, or other practical administrative tasks is beyond difficult with this level of complexity. OK, but what if your security profile looked like this instead?




Welcome to a new era of software-defined security powered by inline analytics enabled through the most modern application delivery controller available in the market today. Essentially, our product alleviates burden of real-time security monitoring and mitigation from the IT admin by automating many of the key tasks and presenting an overview of important data that even non-IT people can readily understand. Our product does this because it is a true SDN built with hundreds of virtual, micro-ADCs that collect and correlate millions of points of telemetry data points each second. These data points then get filtered through our analytics engine and then ultimately fed to our centralized SDN controller.

As you can see in the graphic above, having this capability delivers a snapshot of the security insights (both DDoS and encryption) that the Avi ADC routinely serves up today with information such as:

  • Types of attack, duration, and origination
  • Severity of those attacks and likely impact presented has a score
  • Overview of security transactions – versions, cipher suites, deployed certificates, protocol versions
  • The number and rate of security transactions and errors

This is yet another important proof point of the advantages that Avi has over legacy ADC providers in modernizing networking practices. It’s not as if legacy ADC vendors would not like to provide their customers with this level of easy-to-understand and actionable insight. It’s just not possible with legacy architectures in the old one ADC appliance for every application deployment model. If you’d like to learn more, please join us for our next episode of our “Take off Tuesday” webinar series that focus on how real-time analytics can turn into valuable and comprehensive security insights. Please register for that webinar here where you can also access on-demand views of our past webinars.


Topics: SDN, SSL, Analytics, Security, Virtual Service

New Call-to-action

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all