Unfortunately, I've also seen a few stumbles that I'd like to soapbox on. These are things that seemed like a good idea at first blush (see below) but in reality, not so much.
This isn't an exhaustive list and may not even be the most prevalent problems in the industry, but in my experience, this is what I see cropping up most commonly.
1. Prioritizing controls based only on auditor's demands instead of risk.
When you do this, you waste resources on possibly unnecessary or unimportant risks. Auditors don't know everything and compliance frameworks don't always fit everyone. Beware the fallacy that a missing control is the equivalent of a risk. I've seen it more than once: "We're buying a NAC system because it was a finding in the audit." Is that a significant risk? "Well, not really... I'm not sure. Maybe?" Prioritize based on risk.
2. Prioritizing controls based only on the Headline of the Week.
Egad, IOT DDOS botnets of doom! We need new defenses. Stop, is that an actual risk for your organization? What is the impact of a DDOS? Do the math and figure it out. Sometimes the answer will surprise you.
3. Confusing Impact with Risk.
Impact is one factor of the risk equation. An insider attack where someone steals all your source code will have a huge impact. But is it a big risk? What are the odds of it happening? How about an earthquake? Don't fill up a risk report with just impact statements. Risk is a combination of Impact and Probability of occurrence.
4. Confusing Frequency with Risk.
Similarly, to the previous item, just because something is very likely to happen doesn't mean it will have a big impact on your organization. Many also forget about all the good controls they already in place. I've seen IT folks freak out about the high volume of SSH password brute force attempts... against a server set up to use SSH keys. Or high volumes of TCP Port 1521 probes from the Internet when the database servers are buried deep between 3 layers of firewall and NATed. Very unlikely that these common attacks are actually going to get very far.
5. Overprotecting the wrong thing.
The classic: I have more budget so I'm going to get a new firewall. However, your old firewall is managing things pretty well and you have other serious risks to tackle next. Maybe you need to fix cross-site scripting on your web application or lock down physical access to the server room. Not as fun and sexy as a new firewall but you should make sure all your major risks are controlled before enhancing protection for a particular risk.
6. Deploying shelfware.
You've got a big problem and a vendor offers a big solution. POs are cut and solutions are deployed. Except they're too complicated to manage. Or too cumbersome for users to deal with. Require too much overhead to keep running. Or require more admins than you have staff for. This can also happen when IT and Security don't work together on a solution. Don't waste a bunch of money deploying a giant control that doesn't actually fit in your organization. This has been discussed by others before.
7. Attacking an intractable head on with a supposedly simple solution.
I've seen folks go after the Big Whales of InfoSec risk with nothing but a fishhook and a row boat. Everyone in the organization has "local admin"? Just take away all their rights, we'll roll out a policy and force it through. Yeah, except your organization isn't homogenous in use case or deployed versions of operating systems. This quickly turns into a morass of exceptions and workarounds... and before long the whole thing is abandoned.
Want more examples? How about fixing SQL injection on the web app? Tell the developers to just patch it. Easy to fix, just get them programmers motivated to fix it. Phishing emails? Time for more user training. It's never that easy. If it was, don't you think everyone else would be doing it? As Mencken said, for every complex problem there is an answer that is clear, simple, and wrong. It's not always a straight line to victory so think before you implement.
Sorry for the listicle title. I couldn't resist. :-)
No comments:
Post a Comment