SOX

Security Policies: Five Basic Mistakes and Five More

I finished an IT audit not too long ago with an organization that did not have any policies. They had an employee handbook, that had some declarative statements that employees signed off on during their first week on the job. They are a small company growing into a medium-sized one, and part of their business maturity model was to standardize and document the structure of their organization. Having corporate policies is a critical element in business growth. Why?

Every regulatory requirement and/or compliance standard I’ve seen requires them. SOX, PCI, HIPAA, GLBA, FFIEC, COBIT, ITIL, etc. So in order to grow your business, at some point you will run into this requirement. And as an IT Auditor, I’m required to read them.

So I get to read a lot of policies - and a lot of them are bad.

An article from Anton Chuvakin highlights five basic mistakes, and I’d like to add five more (I like things in tens; you know, ones and zeros!) So here’s his five:

1. Not having a policy
2. Not updating the policy
3. Not tracking compliance with the security policy
4. Having a “tech only” policy
5. Having a policy that is large and unwieldy.

These are good points, and it’s a great read, so it got me started thinking about what I come across for policies and have been concerned upon seeing; so here’s my five:

6. Having a policy not mandated and approved by the “top of the house”

If no one from upper management has reviewed and approved these policies, they are just your opinion, or your mandate for your particular department. They do not cover the organization as a whole and provide no legal protections (enter the obligatory “I AM NOT A LAWYER” here). If the management doesn’t stand behind the policies enough to mandate and promote them, they are toothless and the employees will figure it out. So will their lawyers.

7. Having a policy that tries to incorporate standards and procedures

Quick, what’s the difference between policies, standards and procedures? (If you’re planning on taking the CISA or CISSP exams, better know this one). Go here for an answer from the FFIEC.

8. Not keeping employees educated and requiring an annual signed confirmation

Putting rules in an employee handbook that gets read (if that) during the first days of employment sends the message that security policy is not terribly important outside of HR - kinda like signing up for direct deposit and health insurance…. Keep the policy updated and make sure everyone reads and agrees annually. CYA.

9. Borrowing something you got off the Internet to make the auditors happy

Certainly my personal favorite. You may think you don’t have time to really craft a policy, but if it has been approved by management, you will be held to it in a court of law. Don’t borrow something you can’t possibly do and claim it’s your policy; when that policy is tested, you will most certainly flunk in a particularly public way. Ouch to your career.

10. Not taking ownership of the policy

Leaving security policies up to management, or internal audit….anybody but you so that you can complain about how terrible it all is and how much work you have to do in order to support it.

Consider that if you craft the policy, you can create a document that will address the needs of your environment. If it’s a realistic policy, you can build a set of standards and procedures you can incorporate into your workload. You can use these to generate statistics for getting more staff to monitor compliance and implement security. If you write it, you own it. Make it yours, make it real, it will be worth the time it takes to make it right.

Compliance is Only a “Gentleman’s C”

A comment from Dr Chuvakin reminded me of how long I’ve been thinking about “checkbox security.” As an auditor, I am certainly familiar with checkboxes, in fact, for my firm, I’ve written a number of them.

When I am going over doing an IT Audit with a new auditor, having a method for examining the environment is vital. Heck, having a method for pen-testing is vital. But it seems that so many people get caught up in thinking that the method IS the solution. If everything is checked off in the methodology, the environment is secure, right?

No. A thousand times. No. I’m sure TJMaxx had a bunch of checkboxes filled in for somebody. Didn’t do them a darn bit of good.

A few years ago I did an internal pen test for a company, and discovered that their use of a web proxy required that the user log in via HTML each time they went to the Internet. Long story short, Cain and Abel easily decrypted their casual hash for me and I was very shortly inside the network, up to admin level AND the CFO’s password. (Geez that was fun; but I digress…)

I asked my engagement manager, who was also doing a SOX 404 audit for them, if their SOX audit would have found this issue. No, of course not! Auditors don’t run Cain and Abel! (Maybe they should, eh?)

So where would that have left that company? SOX “compliant,” but still easily broken into by anyone with a simple tool. Not good. So much for checklists, checkboxes, and methodologies. The difference was, the company cared enough to pay for a quality pen test, not just someone coming in to run a scan. They changed their proxy, and now this issue no longer exists. They’re proud of their security, and they should be.

But if we are not thorough and specific, we can miss the obvious “low-hanging fruit.” In my mind, that’s all an auditor can really hope to do. And even that seems to be a full time job.

So, for those folks who say, “we’re compliant!!!” it doesn’t mean you are supporting a secure environment. It means you’ve gotten all the little boxes checked in someone’s methodology. It’s a “Gentleman’s C.”

What would an “A” look like? More on that later.