The next level up from basic controls, are what I’m calling the more advanced technical controls. These are the things usually used by the organizations who’d be sued if their security was breached. Again, this is the low-water mark list. And like before, most of these security controls are overrated, overly relied upon, or implemented narrowly.
Strong authentication
Strong authentication, by which we mean two-factor, by which we usually mean carrying a token thing. These are great replacement for passwords, but that’s about it. It all gets very interesting when you use a token to authenticate to a box that has significant vulnerabilities (see patch management). And for most strong authentication systems in place, I’ve found several work-arounds implemented by the system administrators just in case we get locked out. Thus begins the whack-a-mole game with the auditors and operations staff. And don’t think strong authentication will be helpful with man-in-the-middle attacks or phishes. I’m not saying throw the baby out with the bathwater, but I just remember that strong authentication is only an upgrade for a password.
Storage encryption
If your organization hasn’t encrypted all its laptops and backup tapes, someone in IT is probably is working her butt off trying to get it done. If you’re really advanced, you’re encrypting all your database servers and anything else that’s Internet reachable. Here’s a wonderful case of doing something so we don’t look stupid. Is there a problem with cold boot ram attacks against laptop encryption keys? Sure, but the law says if someone steals a laptop and it’s encrypted, I don’t have to disclose. And yes ma’am, the database is encrypted - but the password is in a script on an even more exposed web server in the DMZ. Whatever, the auditors demand the database be encrypted, so shall it be done. In any case, it’s safest to assume the breach - if an adversary has physical access, they are going to get in eventually.
Vulnerability scanners
Take patch management and now repeat with vulnerability scanning. It goes like this: scan your machines, analyze the results, find a hole (and you always will), request that IT patch the hole, request that IT patch the hole, request that IT patch the hole, insist that IT patch the hole, raise a major fuss about IT not patching the hole, IT patches the hole. And then repeat. And this doesn’t count the zillions of false positives because your vulnerability-scanning tool is banner grabbing instead of actually testing. No, vulnerability scanning isn’t worthless. Heck, anything that gives you some visibility into your enterprise is a good thing. But it will it truly give us battle hardened servers ready to take on the deadly sploits of the Intarnetz? No, not really. And depending who you ask, more trouble than it’s worth.
Logging
The vendor’s cha-ching. This is the security information management (SIM), security event management (SEM), etc. It’s the big box o’ log data. Essentially, it’s syslog on the front, database on the back, with some basic rules in-between. If you’ve paid a decent amount of money and/or time on those rules, then you’re only trying to drink from a lawn sprinkler instead of the fire hydrant. In any case, getting useful real-time information out of your logging system is a part-time job in of itself. Now there are intelligent log analyzers out there, but usually they cost around 80K a year plus benefits. Can automation? Get serious. There is simply too much data to make a decision in a timely manner. And remember, you are facing intelligent adversaries. The most useful automated intelligence you’re going to get out of logging system is a measure of the background radiation of the worms and bots. Now, again visibility is a good thing. I use my logging system for forensic detail after suspicious events. I also use it for trending and for showing management just how dirty the Internet is. But as an actual alarm system? Only if I’m lucky. And producing actionable intelligence? Not so much.
1 comment:
Post a Comment