Chicken and egg – do I stop stuff, or just log stuff?
We go through this exercise with customers all the time: do I practice detective or preventive security? Do I react to what has happened, or do I try to block things from happening? It seems easy, right? Of COURSE you want to stop bad stuff from happening, and there are ample opportunities to do so. Your firewall can deflect traffic from known bad places, or even unknown, untrusted places. If a user flubs a password three times in a row, he stands in the corner. If your role says you don’t get into accounts payable, then you don’t get in. But here’s where it gets tricky. Consider the scenario in which a guy stops at a souvenir shop in the desert to buy some painted rocks or a rubber snake for his kids while on the way home from a distant funeral. The cashier accidentally dings his credit card three times in a row instead of just once, and they’re both blissfully unaware. A few miles down the road, the guy stops at the last gas station for ninety miles, beyond which is the desert, past which is home. He swipes his card at the gas pump and – DENIED. He’s screwed. Doesn’t have enough cash, and has just the one credit card. He hasn’t done anything wrong, but the credit card company’s computer saw some badness during his previous purchase, assumed his card had been duped or otherwise compromised, and he’s shut down.
It’s called a FALSE POSITIVE. It’s why companies are often afraid of proactive, preventive medicine. They bake into the cost of doing business a certain percentage for dealing with bad stuff. They fear blocking good traffic (equating to business) in the cause of blocking the bad. My wife and kids were buying some junk (it’s a thing they do) at Navy Pier in Chicago. Then they walked a ways and bought some more junk. Yes, they are serial junk buyers, shut up. Anyway, at the second stop, da wife’s credit card was refused. This took me some time to unravel later, but what happened was that one of the Navy Pier vendors processes their transactions out of Los Angeles. So it appeared to the credit card company that my wife was engaged in something called Improbable User Acceleration, meaning there was no way she bought junk in LA then very quickly tried to buy some in Chicago. And so the card was temporarily shut down. In theory, this is a good security measure. It’s why I always call the credit card guys to let them know I’ll be in Europe in advance.
But when it comes to larger transactions, or even large volumes of smaller ones, companies are often loathe to prevent, because of these very types of scenarios. Real-time security means blocking stuff as it’s happening. “This smells fishy, so I won’t let it go through.” As opposed to what’s called NEAR-real-time, in which something looks fishy as soon as it hits the audit log. Alerts are generated, and perhaps subsequent behavior gets flagged as well, but the original transaction has already occurred.
This can even occur at the database level. Tools exist for enforcing Segregation of Duties within a database. You can even seal off portions of data, or specific tablespaces, even from service accounts. That bot account can do payables, and this one can do receivables. That’s the kind of granular segmentation that could have limited the damage in a number of awful hacks. So here’s the deal. Sometimes you can’t tell something bad has occurred until it’s contrasted with other past behavior. A ding on a single IP address might look okay, but when you line it up with dings on other IP addresses, and all coming from the same SOURCE address, well maybe now it looks funky. This is what SIEM and audit vaults and their brethren are looking for. Sophisticated fraud engines (increasingly relying on Big Data backends look at the sum total of behavior to build and use these models.
BUT .. here’s the final word. Those reactive, detective-only systems only help if you DO SOMETHING with the results. You look at that near-real-time data about bad stuff going down and you take steps, you build policies to prevent future such behavior.
In other words, don’t be the kid who says, “Mom, I broke a vase.” Be the kid who says, “Mom, I broke a vase, but I cleaned it up.”
Jeff Scheidel is a 32-year veteran of the software industry, with more than two decades in security. He is the author of a McGraw-Hill book on identity and access.