When I go out on exams to client sites, I am often amazed that I find things in bad shape – terminated users on systems, unpatched servers, holes in firewalls, secret 5 on Cisco routers…..Why? Because it’s not rocket science. Whether it’s SOX, SAS 70 or PCI, auditors will be checking pretty much the same things.
First – Policies and procedures? Got em? Don’t make ME do it. If I write your policies (by requiring you to do it to become compliant), you have no investment or interest in implementing them or maintaining them. Write your own, and you own the procedure. I recently got an “Incident Response Policy” which had been flagrantly plagiarized from a university. The author, an admin in a service bureau, didn’t bother to read the complete document and at least Find|Replace the appropriate nouns and names. He had actually set himself up to fail with a policy that would be impossible for him to implement.
Second – Access Controls? Who is in charge of requesting adds/changes/deletes, and who completes the request? DON’T make me do it. Don’t tell me you track it by emails, because those get lost and deleted. Email is NOT an access control. Who wanted it, who approved it, and who did it? When? I’ll be asking…..
Third – System Security? Are your servers patched? Don’t make me do it. If you give me a bunch of MBSA reports, you’d better READ THEM FIRST. That way, when I start asking you why there are so many local administrators on your database server, you’ll have an answer ready….especially if those IDs belong to users who have left the company. Do you REALLY want to explain why you’re missing 37 patches? While your manager and CSO grind their teeth behind you? I understand why you haven’t applied IE7 or the Windows Malicious Software Removal Tool (which Micro$oft says is a “critical” item), but security updates labeled “critical” and are over two months old WILL require an explanation. Count on it, and better yet, get it patched.
Any good auditor will give you the test AND the answers you need to pass. If you flunk, it’s not me. Do you really want to have to implement security the way an auditor (who does NOT know your network) recommends? Please don’t make me do it. If you know what I’m going to ask for, build it in, own it, make it yours, not mine.
And, I’m sorry to say, all of the examples are based on my experience in the real world of IT.
I had a great discussion today with the head of auditing for a regional bank. He talked about the need for IT Auditors to understand the systems they were auditing. But how much knowledge of technical environments should an IT Auditor have?
Quick answer: As much as possible.
I have met numerous CISAs and CISSPs that cannot audit systems without a checklist or a software tool. I’m not saying we have to know everything about each operating system; we don’t have to be engineers. (But it sure helps!) If we’re only as good as our tool, we’re doomed.
We have to know how users, groups, access controls to files and directories are created, maintained and changed. If an engineer says he can’t get something from a system for me (like a list of etc/password) I need to be able to show him what I want. Otherwise I don’t know what I’m talking about, and he can get rid of me by playing dumb.
I worked with an Oracle DBA not long ago who didn’t know about being able to turn off the TNS Listener if it wasn’t password-protected. He didn’t believe me when I said I could turn it off. So we agreed to run a test, and I turned off his TNS Listener service remotely, with no password. (Needless to say, we did this on the DEVELOPMENT server).
His attitude towards me did a total 180 degree turn. After a pregnant moment of silence over the phone, in a whole different tone of voice, he asked where I had gotten my information and what I did. From then on we had a very good relationship – he no longer treated me like a pain in the anatomy. (PS, this only works on Oracle 9i and below).
If you don’t know about this exploit, and why it’s important, read the whitepaper from here.
There’s nothing like a demonstration to clarify the point. If I hadn’t done that, he would have dismissed my finding. I frequently have to make my geek bones with engineers when I go on an audit, but I don’t mind because we can then operate from a position of mutual respect.
So many audit departments don’t have the depth to truly partner with their IT departments. It should be a match made in heaven, but it doesn’t work if one group has more knowledge than the other.
When I did a PCI exam for a Tier 1 merchant who had outsourced their IT functions, I ran an MBSA scan to determine if the systems were patched. Their outsourced vendor claimed that the servers were all patched, and he had the change control documents to prove it. I went on a sample of twenty servers and confirmed that the servers were not patched by looking in the file system, and I returned the results to him. Unfortunately, somebody got fired, but now the servers are patched and they check to confirm.
What would the response have been if I couldn’t prove the finding? That’s why IT audit needs to know systems.