Myths, Mistakes and Outright Lies (when it comes to IT Security)

Life is full of urban myths and twisted beliefs, and that could not be more true for network security and the internet. I would like to present just a few favorites of mine that I have seen, and in many cases, had to live with (support) and overall dedicate my life to making them work (since I designed them). In the course of that, we would make design situations that fit the issues we were dealing with then.

Look, network security is a weird and complicated place sometimes. Security is about accounting for what people do, not machines, so because of the way risks change, a solution that at one time, made total sense, suddenly doesn't make as much sense anymore. But by then, it's written into some operations manual that's tied to an audit that just could not survive with this vital piece of equipment firing out reports no one pays attention to anymore. You probably have something like this in your network, something like the intrusion detection system monitoring the internet connections coming in, BEFORE the firewall.

Myth, you need an IDS on the internet.

Don't get me wrong, you may have some huge requirement to sample large volumes of useless alerts and packet dumps, I am in no way saying you should never do this, but unless your companies core business has something to do with studying internet attacks, it is highly unlikely you will be able to convince me your getting allot out of this solution, it just doesn't have that bang for the buck it takes to manage that IDS/IDP solution.
If you have an IDS attached to the internet, try an experiment, pick that thing up and put it inside your network somewhere. Have it monitor a network your actually care about and see how valuable that information becomes. Oh, and don't actually jumble up your network because I said so, tell them it was your idea. Chances are, no one will notice anyways :)

So once you stuck that IDS device inside and discovered bad stuff behind the firewall, what next? If it's bad, you may be subject to a big mistake around planning and deploying your policy, and our next myth.

Let's just worry about what's coming in.
The proverbial firewall myth, that somehow the firewall saves everything. Problem is you are forgetting that it is just a tool, and it's only as good as how you use it. For example, if you have a policy that looks like the one above, you probably have a serious security problem. On the bright side, you probably won't know anything about it, since you are not enforcing any kind of bi-directional policy enforcement. When your are planning a security policy, what is going out, is just as important as what's coming in.

Here is a mistake we all make as users, and that is trusting our networks, be it the corporate one, or your internet provider.
You know that alert, if your doing your banking and the web browser complains about the site, you should not continue, right? (I really wonder how many people just ignore it, making this a moot point) At any rate, it is possible for someone to intercept your traffic, even encrypted traffic, so be aware that nothing is 100% safe, even if you DON'T see the warning.

Let me ask you, if you are doing things, like your online banking, at work, and technically on your employers network, is it OK for them to decrypt and view that traffic? I don't know the answer, I'm just saying it's a mistake for you to assume your company, or your Internet provider, can't do it.

Remember when dual vendor security strategy was cool? We all got to play with more boxes, and our blinky light capitol went through the roof, but it also spun us into an unsustainable security architecture, too painful to support. I blame this insanity on a report from the late 90's that somehow justified spending 4X your money to create 3x the complication requiring 2x the people to manage very little gain in actual protection or security. I'm not pretending to be some network guru who saw right through this, but anyone who actually had to implement and support such an environment, should have realized about halfway through the project lifecycle that this was not going to be pretty. Let me tell you how I saw dual vendor security shake out. I was always told, that if there was a vulnerability in one firewall, the other firewall will, theoretically, still be able to protect against the attack, since it is a different architecture.

Here is how it worked out in the real world. We implemented a dual vendor solution, and after much pain over years of managing security policy changes across disparate systems, the day finally came, when a vulnerability was revealed in the ssh protocol that, guess what, was vulnerable in BOTH FIREWALLS.
Actually it put pretty much anything that used ssh at risk, but ironically enough, not the firewall in a way that was risky or even a concern. See the firewall, being a security device, was never configured to talk to anyone on the network, unless you were an authorized admin through a VPN connection. So the only people that could be running ssh exploits against the firewall, were the administrators that, surprise, already have all the system access they need. If they are running shell exploits to gain administrative control over machines that they are already the admins of, well, we all have much bigger problems then.

If you take this thinking to the next logical step, if firewall attacks aren't my concern,(most just exploit perfectly good and allowed services) why use the dual vendor security strategy? We should be applying it to the real targets, servers. So go ahead, run linux AND windows based servers so a vulnerability on one system won't hit the other, right? We will have to invest pretty heavily in application cross platform development and support, but OK. While we are at it, we should split our user base into windows users, mac users, and ubuntu users. That will really cut down the impact of worms and virus. Will triple support costs, not including user training and retraining, but hey, two is better than one, so three has got to be the best ever! Right?

It doesn't work there, why would it work in security solution support?

I think what the report was trying to create (and I'm giving allot of leeway here for interpretation) was something where a supervising body oversees two distinct groups that implement policy changes as separate entities.
That would crush the conspiracy risk of your support team subverting your security and therefore undermining the entire company. If that is something that poses a big risk for you, consider keeping this structure to manage your security. Cost would still be up there, more in the change management part, but if you like this level of segregation of duties, I guess this dual vendor thing might work out for you. Mind you, it still wouldn't make sense to use multiple vendors since you would want the changes and reporting to be consistent, but if your the NSA, (or some super corporation that needs this level of security,) it is highly unlikely you are going to be reading this blog for its network design tips, so I'll just call this one out as pointless for the rest of us.

I can't end this post without saying something about 'the cloud'. Yes THE cloud. There are a ton of people much smarter than me on cloud computing and SaaS solutions, heck, I'm a big fan of some of them (the experts and the cloud services). . .obviously. . . but I don't consider security in 'the cloud' that crazy a challenge, as long as we learn from our mistakes and apply appropriate solutions as risk dictates. Actually that sounds kind of wishy-washy, how about this, instead. Just because 'the cloud' is virtualized, does not make it immune from risks, so factor that into the services you move into the cloud. There are ton's of services that make total sense, in 'the cloud'. And by the same thought, allot that aren't worth the risk to relinquish security control, because security is managing risk, and if it's not under your management, its simply at risk. Like any outsourced solution, if it is not providing the same (or better) level of security audit, control and reporting, it is not going to be worth the risk. Make sure your 'cloud' security model is not based on it simply being THE 'cloud'.

There is absolutely a future and a need to utilize cloud services, but sending ALL your data into 'the cloud' sounds like a dangerous idea to me, but one I have heard somewhere before. Where was that now?. . . something about putting all their resources, power, focus, into a single device. . . . .Oh yeah, now I remember,
http://www.cracked.com/topic/119-the-death-star/