Shellshocked by Shellshock? This Bash bug may make your hearts bleed...

    Bust out your IT-signal, the Penguin and Pomaceous-man are vulnerable to attack.

    There’s a lot of media hype around this new bash vulnerability “Shellshock”. I could go over all of the meaningless fluff other people have covered, but I won’t. Speculating on whether it’s going to be “bigger than Heartbleed” isn’t a worthwhile endeavor. What we should doing instead, is implementing proactive security practices and incident response plans, so people are prepared for these sort issues in the future.

    Bugs Happen

    There is no absolute security, nor is there such a thing as perfect code. Human beings by their very nature are fallible. We mess things up, we make mistakes, and that’s simply how things are. What is critical is how we approach these issues, not only as they appear, but also proactively. People always say “the problem would have been prevented if…” in the aftermath of a breach, bug, exploit, or any major IT disaster.

    Here’s a newsflash, hindsight is 20/20.

    If you’re only responding to issues after they occur, then you’ve missed the point. IT security, more specifically application security, isn’t some paint by the numbers step-by-step process of crossing t’s and dotting i’s, it’s all about risk management and risk mitigation.

    Risk Management and Risk Mitigation

    Let’s look at this subject in how it applies to Shellshock. 

    Let’s say that there are two networks, each has a single vulnerable website hosting server, an internal storage server, and 20 or so other end-points. 

    “Network A” has its web server in a DMZ, while “Network B” decided not to use a DMZ as they wanted easy access to their web server.

    Both systems were attacked using this Bash exploit, and root access was gained on both systems. “Network B”, because it had no DMZ, was fully accessible to the exploited web server and was fully compromised as a result. “Network A”, however, was able to avoid the brunt of the damage, as the web server was isolated from the intranet.

    Does keeping your web server in the DMZ make exploits like this a non-issue? No!
    Does segmenting the network in this way decrease the risk of these exploits? Yes!

    This is a prime example of managing and mitigating risk.

    The administrators of “network A” recognized that its external facing web server had a high risk of being affected by some sort of attack, and knew that, because of that risk, it was safer to keep it isolated from the internal resources which contained more sensitive information.

    The administrators of “network B” gave no thought to risk mitigation beyond installing a firewall, and, as a result, their mismanagement of risk put their entire network at risk.

    There’s no such thing as absolute security

    Anyone that tells you "absolute security is possible because of their product" is lying to you. Zero-day exploits like Shellshock are unpredictable and often function in ways no-one could have imagined. You may think something like a PDF is safe, but a malicious exploit of PDF scripting can provide root access to almost any system. Even the most innocuous things in IT, like a USB keyboard, can become an IT security risk; however, so long as you follow IT security’s best practices, you can get through these issues in one piece.

    Ready to Get Started?

    Let's Talk