The Success of the UTM
I have been on a kick about what security admins and managers have to do to sell security. And I posted a huge list the other day to help those same admins and managers start their own list of duties so they could get organized and possibly show the boss all the stuff they have to do day in and day out. (BTW, forgive the formatting of the list. The Blogger people royally screwed up some of my formatting during some maintenance they were performing today, and I am just too dang lazy to go fix it!)
So when you look at that list, you wonder how you can get it all done. Alan Shimel asks the same question here. I think the one fact that security admins and managers have so many chores and tasks and jobs to take care of is the biggest factor in UTM success.
Look at Chris Hoff’s post on UTM’s. One line from his post is, “If ‘good enough’ security is good enough, you have lots of UTM choices.”. I contend that the UTM is so attractive because “good enough” is what many (not most, but maybe not far off) security people are looking for in their security because they are strained and pulled and stretched and yanked in so many directions that “good enough” is all they have time for. Call it lazy or whatever, but the truth is there.
What Chris wants is for the good ol’ days of risk management to come back, where you identify your risks, you determine what your tolerance for each risk is, and then you determine what measures to put into place to mitigate those risks. I agree with Chris wholeheartedly. But the reality is that it just ain’t always possible, unless you want to work about 80 hours a week.
So, UTM looks good to that overworked (or oft times lazy) admin or manager, and they want their auditors and execs to see a cool piece of hardware that they can grab some reports from. So UTM it is.
That kinda leads into my next point.
Goverment Regulation Can Actually Hurt Security
I am sure someone has written about this, and I did find this post with a very quick Google search. It didn’t exactly address my point, but oh well. Anyway, my contention is that compliance with HIPAA, SOX, GLBA, etc. can often do more damage than good to the security posture of organizations. Now, this totally depends on some of what I mentioned above, namely whether or not the security admin / manager is lazy, overworked, etc. But basically, here’s the reason compliance can hurt more than help: it often causes the security department to reach for compliance INSTEAD of reaching for actual security.
Look at HIPAA. It has not one shred of actual technical advice. Most people say that is good because it allows for flexibility in the security approach. I agree. But if I am a lazy security guy or an overworked security guy whose boss tells him to make sure the company is compliant, then I may look at compliance in another way.
First, I do some research and find that many of these regs don’t have any real enforcement to them. I don’t tell the boss that because my job just might go flying out of the window. So, I write (or find on the Web) some policies and procedures that are HIPAA, SOX, whatever compliant, then I put in some security measures that look cool and give nice pretty reports, and then I can step back and say, “That should convince the auditors.” I have not hired a third party to come out and do a risk and gap analysis. I have not taken a look at what I am trying to secure and where best to place security measures. I don’t even really know what risks are there, so I have no idea what the companies tolerance for them are.
It basically becomes a game to LOOK compliant so you fool the auditors. Since you really don’t expect the HIPAA, SOX, GLBA police on your doorstep any day soon, why should that concern you?
But let’s look at this one more way. I have to honestly say that this does not just apply to lazy or overworked security admin / managers (though most of us are overworked). It soon simply becomes a realistic view. Maybe you are a hardworking security guru, and you are going to do your dead level best to secure the network, come hell or high water. So, you do the risk analysis with a third party, you determine your risk, you fill all the gaps as best you can, and you come out with a secure network that will stop a hacker dead in his tracks. But you stopped worrying about the reg-de-jour a while back, just like everyone else. And you have no regulation specific policies and procedures in place, even though you followed every ISO standard even remotely applicable to security since the history of man. And someone decides to give some teeth to the reg. What happens when eve your strong, secure network gets breached? You get busted.
Man, what a drag.
So, what’s the answer? To both problems above, the answer is more staff, more money, and more training put directly towards security. Executives, LISTEN UP! Let your people do what they need to do. Dedicate the resources on the front end, let the security people get your network secure from a practical and regulatory standpoint, then just keep it going. Your costs will decrease to a great degree after the initial push is complete. Yes, risks change, but not every risk will change at the same time. Yes, technology needs to be refreshed, but that is true of IT in general, and it is usually every three or four years. Yes, new regulations come up, but the infrastructure will be there to meet those. Get it done, and you will be secure. You will be able to flex and move with all these changes. Make the investment now. Please.
Vet
