Auditing Your System: What to Look For

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

If you have been asked to do an IT audit of an organization, what’s the first thing to do when you meet the executive who is commissioning the audit? Answer: define the scope and type of audit — you want to know why the company wants an audit. What many people worry about when they are asked to do an audit is the checklist, that is, the specific items you check or measure in an audit.

In my experience, this is the sequence to do last. Defining the scope is like a top-down network design. In every case, management will have a goal in mind: Is it to be a policy, procedure or system-level audit? Most importantly, if you define what you are auditing before you know the specifications, you avoid the problem of picking a flawed or too narrow method to measure compliance — you don’t choose a method just because it is something you know how to do.

Another reason to narrow the scope: For large companies, it would not be possible for even a group to audit every IT facet. Of course, the audit perspective will differ, depending on whether it is an internal or external audit. You will want to decide if it should be a conformance audit (how well policies and procedures measure up to the organization’s policies and procedures) or a security audit, which commonly measures policies or procedures against best practices. You might even measure internal audit controls against known standards.

Whether you are tasked with an external or internal audit will be critical in one of the least-considered audit aspects: how you handle communication with those you audit.

Auditors usually are seen as the evil emperor, but in the meet-and-greet session, you have a chance to dispel that notion. You should not be asked to evaluate personnel — make that very clear — what you are doing is measuring relative risk, as well as how policies and procedures compare to a defined standard.

If you stress to the network administrators and technicians whom you meet that you are truly objective, fair and will communicate their concerns to upper management, they will see this as an opportunity to share potentially embarrassing incidents with you.

It’s all in how you present yourself — you aren’t telling the people you met how they should be doing their job, but rather, you are presenting the audit as a learning experience, the network administrators are much more likely to be open and forthcoming.

What happens when the scope of an audit is very large? There are several strategies to follow: Break the tasks into smaller pieces, ask network managers for documentation or even assistance covering the parts you wish to examine, and audit the most important parts first — audits should be risk-driven.

There are several stages of an audit. Organizations name the steps differently, but in general, they consist of the following:

Initial Planning: Where you set the scope and meet the people who commissioned the report.

Initial Meeting: Where you meet the people who protect what you are auditing.

Examination: Where you measure the systems against a predetermined baseline.

Report Preparation: Where you actually make sense of your data and include neutral references supporting your position.

Presentation: Where you present the results to the affected individuals, and separately, a high-level summary to upper management. Sometimes, either or both are done only in writing.

Most auditors are most concerned with the baselines, that is, what they are going to measure against. Standards supporting various baselines include governmental standards such as the federal information processing standard (FIPS) or Federal Information System Controls Audit Manual (FISCAM) — which  used by the U.S. General Accounting Office) — HIPAA, Sarbanes-Oxley, etc.

If standards overlap, what do you do? The System Administration, Networking and Security Institute (SANS) is in the process of creating a Site Security Standard (4S) based on 7799 as a framework that maps requirements in common for various standards. An example of that is found here: www.cyber

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|