InfoSec Policy - why not?

Policy.

Ugh.

Most people in the IT field dread anything that relates to documenting "how" to do something related to their positions. Why should we? It's all up here (point to your forehead - i.e. the steel trap).

I'll be honest. Documentation isn't my FAVORITE thing to do. But then again, neither is working, period. So why am I writing about infosec policy? Because time and time again, we come up short; whether that means our infosec policies don't exist at all, or they cover only "Acceptable Internet Use", or they're:

1. Super long
2. Super hard to read
3. A super waste of paper and hard drive space

Why do we all fall short in the area of actually writing information security policy? I've got a couple opinions, and the masses can disagree with me if they want (I know you're out there).

First opinion: we get lost in thoughts of the policy having to cover everything. That's like saying, "I don't want to create any laws because I want to make sure that no one commits any crime." Not possible! But wouldn't we be better off having 5 laws versus no laws? Don't murder, don't steal, don't lie, don't litter, and don't be a jerk. I would think the world would be a better place having those 5 laws versus NO laws whatsoever. Same goes with an infosec policy. You might as well get started now, because anything you outline and document is better than nothing at all.

What does policy mean? "A definite course of action adopted for the sake of expediency, facility, etc."

How do I define it? It's a blueprint. Plain and simple. You wouldn't build a house without a plan, right? Why would you build a holistic security strategy without a plan on what you're going to do, how you're going to do it, who will be responsible for which parts, etc. It's that simple. Seriously.

But wait, here comes the second opinion. Blueprints are big. REALLY big! Not necessarily, my peoples. They're a guide. The blueprint doesn't have to be the SIZE of the actual house. Neither does your infosec policy. I was at a security seminar a few years ago, and the guy (can't remember his name) asked the audience if their companies had an information security policy. 25% of the audience raised their hand. Then he asked how big the policies were and what they covered. I'll never forget this dude from IBM raising his hand and telling everyone that their infosec policy was 5,000 pages long.

C'mon, seriously. Whoever or whatever team wrote that pile of crap obviously liked to hear themselves type or were a bunch of reefer addicts. I would take that thing out into a parking lot and light it on fire, and then start over with something that someone WOULD ACTUALLY WANT TO READ.

Isn't that the point? For people to read it, understand it, and follow it's direction?

So my goal, and what I was taught, is that it should be clear, concise, and written at a 7th grade reading level. I shouldn't have to bust out the dub-dub-dub dictionary.com in order to understand what I'm being held accountable for. Right? Thanks for agreeing...

What is the point of this post? Start working on something now. And don't do it because HIPAA, SOX, or PCI made you. Do it because you need and want to do the best thing for the positioning of your security posture. Stop talking about it. Stop saying, "We don't have an information security policy." Start doing.

A general information security policy could start by putting together a quick one or two page outline of how the organization takes security seriously, and it's goals. Then start on the sub-policies that actually define specific areas.

What are sub-policies?

• How do you administer changes to the firewall? Who approves the changes? Now you have a Firewall Administration policy.
• What can I do with my computer? Am I allowed to hack Switzerland? Now you have an Acceptable Computer Use policy.
• Do you have third-party organizations connecting to your WAN/LAN? How should they connect? Now you have a Third-Party Communications policy.
• Am I allowed to use a signature including my e-mail address, phone number, title, and address when I post to my favorite tech forum? Now you have an Information Dissemination policy.

I know I'm making it sound ridiculously simple. But then again, it kinda is. It's NOT rocket science. Why? Because rocket science IS rocket science. Infosec policy writing, isn't.

If we just start doing, instead of talking, we can all get through this process. We have to. Every solid security organization depends on it. I promise.

Respect it.

Knoppix-NSM

Just downloaded Knoppix-NSM, a bootable Debian .iso for network security monitoring. I saw an article about it in the October issue of Information Security Magazine. Includes stuff like Snort, Sguil, BASE, etc. Very clean and trimmed down from what I've seen so far. I'm going through the HDD install right now, and will soon throw it on my home network.

I'll update the masses.

I know you're out there.

Microsoft IAS & PEAP. What fun...

I started deploying my first large(r) Microsoft Internet Authentication Service implementation at a client a couple weeks ago, and it's been a work in progress. At first, the client was using RADIUS as a second set of authentication for their remote VPN client connections. After their wireless security was tested (and rated poorly), they decided to go with a PEAP/WPA2 auth/encryption architecture. Sounds good! Unbelievably, Microsoft has an entire certificate solution laid out for this sort of thing, with Verisign. Stop the world!

All in all, it's working out well. There's roughly 70 devices using AAA now; I have a primary IAS box, with a secondary IAS box for redundancy at the same physical site. I wish IAS config was replicated automatically, but the manual process is pretty easy. And what's with IAS proxies? WHEN DO YOU ACTUALLY NEED TO USE THEM? Are there any benchmarks to go off of?

The one area I found to be challenging was the creating specific profiles with the Remote Access Policies. Getting the right attributes as "match" criteria within the policies, AND putting the policies in the correct order for application can be difficult. Lots of trial and error. Unfortunately there isn't a ton of documentation out there on the subject, especially if you want to use the same IAS box to authenticate wireless users, VPN users, and network administrators gaining access to LAN/WAN hardware.

George Ou from TechRepublic posted his "Ultimate Guide to to Enterprise Wireless LAN Security" earlier this year, and there are a number of step-by-step guides on deploying PEAP using MS IAS as the RADIUS server. I don't know about you, but using the word "Ultimate" in a title of anything info/net sec related just makes me sweaty. Seriously, "Ultimate"? Maybe if Joshua Wright wrote it. Then again, "ultimate" is a strong word in our field.

PEAP w/ MS-CHAPv2. Secure? Sure. Most secure? Obviously not. But, if a weak password policy was a problem before implementing a wireless PEAP auth strategy, it'll always be a problem.

So there you go. My first post. Don't hate! Respect it.