Why read another article on the Shellshock bug when there have been a number of well-written articles and blog posts on it? Because almost all of the articles and blogs are talking about the bug itself, how it can be exploited, and how much of the Internet is open to it. However, what you should really be interested in is the security of your organization. Your response to Shellshock can tell you a great deal about that.
At the crux of Shellshock is Bash. If you are not worried about Bash, you should be. Why? Bash is just an example of a long line of ubiquitous code that has been and will continue to be exploited by opportunistic hackers and targeted attackers. If you are or were panicked about Bash and the Shellshock bug, it might be your lack of a defense in depth (DiD) strategy.
Consider that about half of the internet is running some flavor of Apache and most of those are on a *nix box according to Netcraft. This bug should make you look at your security policies and (DiD) strategy. If you have a well implemented DiD strategy, then most likely you are a lot less concerned.
While driving down to Derbycon with a friend we talked about how many of the IPS/IDS signatures that were released for Shellshock were easily bypassed. Several key observations resulted from that conversation:
- Many IPS/IDS signatures are ineffective
- Many security devices that we all use are running on Linux; therefore they are vulnerable
- Many of the patches released were ineffective – they did not truly patch the vulnerability
Defense in depth is a strategy for using several safeguards to collaboratively protect information assets. Each of these safeguards should protect systems from different vectors, using different principles of defense, and different technical frameworks. That way, if one system fails to stop an attack, others would catch it.
Let’s say your patching policies are ineffective or slow. Let’s say you have even yum’ed an equally vulnerable Bash script last week. If you had restrictive rules on your *nix boxes, restrictive configurations on your Apache daemon, a web app firewall, a strong Security Information and Event Management (SIEM) that sends your security team a “say what?” when it detects strange activity on your Apache server, and an advanced malware appliance watching for suspicious inbound and outbound traffic, then you still have a strong chance that you’ll stop malicious use of Bash on your servers.
What does this mean for security teams? It means that DiD needs to be emphasized to identify which collaborative controls are in place to address these issues. Chief among these controls for risks like Shellshock is having strong patching processes. Organizations tend to have poorly implemented patching programs. Consequently, servers and appliances remain vulnerable to the weaknesses in ubiquitous code like Bash, BIND, Sendmail, and OpenSSL. Even without proper patch management in place, a DiD approach means that an attacker would have to bypass a next generation firewall, an IDS/IPS, an advanced malware detection appliance, security incident event management (SIEM), and a web application firewall (WAF). The likelihood that all of these technologies fail? Is well, unlikely.
Defense in depth and proper patching do not address all security issues, nor do they make an organization totally secure. They do, however, reduce the overall risk of a successful cyber attack, they give less reason to panic when ubiquitous code becomes vulnerable and they should help you sleep better at night.