Why Security tools are like pr0n to the Security Professional
I love the technical end of Security. Coming from a mathematical background, I crave that buzz that comes from proving a tough theorem. In Security, there is nothing that really matches the buzz of reversing a tough binary, or figuring out some undocumented protocol with nothing but blackbox fuzzers and a packet sniffer, or writing that fuzzer that generates an exception in some popular app. Security research is sexy, fun and stimulating. At the same time, it doesn’t often impact the bottom line (or goal) of a more secure network. It’s mental masturbation – fun, habit-forming, sometimes beautiful but meaningless shortly after complete.
Now, all of this uber-technical research leads to … well, it leads to uber-technical security tools. Cool tools – Star-Trek-Cool or Matrix-Cool. We have tools which mimic the human body and tell us when an anomaly occurs within a TCP session, or when a kernel call was followed by some other call which had not been modelled into the norm. We have tools which automatically shut down attacks based on some learned or programmed behavior. We have tools which exploit a flaw and then drop a shell, allowing the clueless user to initiate a second scan from the exploited machine. I could go on and on. We have a veritable CRAPLOAD of tools. We buy these tools, rush them home to our shiny network, deploy them, and at the end of the day there is no discernible increase or decrease in Security Posture. It doesn’t take a Phd in Statistics to tell us that the tools are (at best) a marginal help. They make us *feel* more secure without actually being more secure. Are the tools useless? Some of them are. Are the tools either used wrongly or used at the wrong time in the Security cycle? Many times, yes.
The problem is that the really useful security applications have already been discovered, marketed, and sold. Firewalls, vulnerability scanners and anti-virus are largely useful tools, but that market is already saturated. So, we get these over-engineered, marginally useful security tools. Many vendors would have us buy a tool for it’s technical aesthetic value. Many of these tools are breathtakingly spectacular, complex, and elegant. We, the geeks, gather around a console at SANS, blackhat, or some other show and catch a chubby watching all that arousing, binary pr0n. And, at times, I nearly succumb and buy the product just to reward the original thought and sheer beauty of the engineering. But, I won’t buy a jigsaw if I need a hammer and neither should you. Art is art and a tool is a tool and rarely the two shall meet. A tool should serve a purpose – a specific purpose relative to your infrastructure and policy.
FOCUS. Are you with me? The goal of a Security Professional should be to (here it comes) increase the level of security on the network. As I mentioned in a prior post, securing a network can be as simple as creating, communicating, and enforcing a specific corporate policy. Increased compliance implies an increase in my security posture. The tool(s) that I deploy will be designed to increase compliance with policies and standards.