As the project owner, you should plan your own audit, taking into consideration:

Planning is important to ensure results will reflect the objectives of the audit. The planning should be documented and should include:

Planning is arguably the most critical phase of any audit. Without it, you will waste precious time, miss the opportunity for improvement, and potentially leave a system vulnerable.

Good planning leads to good scope definitions and an awareness of potential issues before you start. Keep in mind that the auditor's and others' time is limited. What will happen if the people you need to interview are on vacation when you decide to meet with them? Planning cannot stop all problems, but certainly reduces the damage that can occur without it.

You should collect, analyze, interpret, and document information to support your findings. The process of examining and evaluating information is as follows:

You should formally report the results of your work as follows:

A Security review should be a comprehensive assessment, by a skilled security professional, of how effective your security environment is for today's threats.

During a review of your environment, it is essential to examine:

A security review should be designed to take a snap shot of your network's security. To do this, you need to correctly examine a site's security from a technical, policy, and procedure perspective. Understanding the various stages in auditing and reviewing a network will ensure you will not miss sections of it. Planning now will help save time later.

To be complete, a security review involves the following areas (this is not an exhaustive list; other areas may be discovered):

Plan the final report early. This document will need to include the details of all the information discovered in the preceding phases along with recommendations on how any identified deficiencies can be corrected.

The report should be structured to include and identify areas needing improvement, identify why they need improvement, and recommend methods of improving them. Most importantly, do not be afraid to point out what the organizations being reported are doing well.

Whether you do it in-house or if you hire an external party, a Security Review is performed to help you discover if the security of your organization's environment is adequate for its security requirements. This process is unique for each organization; the issues faced by one company will not be the same as another. Yes, there are going to be common frameworks (such as in requirements like the PCI-DSS and privacy), but there are also extensive differences even within industries. Instead of just auditing your security environment and reporting what you pass and fail on, add the following:

A common issue in any audit is individuals exceeding their authority. As an auditor, you do not generally own information or processes within an organization. Consequently, it is critical that you work within your scope. It is also important to understand the relationship between information and its owners. Scope should be defined by the parties with authority over the systems you wish to test. Without authorization, you may be in violation of the law, so always ensure that the person who signs off on the scope of the audit has the authority to do so.

This leads to a common problem in audits, and projects in general—scope creep. There are two aspects of Scope creep of particular concern to an auditor. First, any time we exceed scope we are exceeding authority—this is never good. Next, exceeding scope costs extra time and resources, which will not be viewed favorably.

One of an auditor's most critical tools is the checklist (also known as the auditor's pitchfork). Subsequent chapters of this book discuss the details of finding the information necessary to create a checklist. The best secret to learn to be an effective auditor is how to create a great checklist. If you can create a checklist from consensus-based principles that will improve your organization's security, you're already a step ahead.

Checklists, like policies, are often created without detail, and generally based on the knowledge of the individual auditor. The best thing any auditor can do is learn how to cite industry references and consensus benchmarks. These benchmarks will add support to your technical statements based on the weight of authority associated with the consensus effort that has created them. This is not to say you will not find opposition, but it is easier to overcome.

This makes the audit process less subjective. The creation and use of industry consensus-based standards in audits backs up your assertions and findings and adds a level of scientific reproducibility to the process. If you create a separate scope and methodology for every single system, you are asking for “snowflakes” in your environment. This also gives ammunition to technical staff who notice differences between systems and become more likely to report other discrepancies.

The next benefit of a systematic checklist is that you can distribute it widely throughout the organization. The goal of the audit process is not to catch people out; it is to instill good governance principles and due diligence within information technology in an organization. If you hand the checklist to information technology staff and management well before any audit, they are more likely to implement the recommendations. An audit with no findings because the issues were mitigated before you got there is a good audit.

The audit checklist should always include a statement of scope, which will include what needs to be verified and if necessary, why. Further, any metrics that will be used to measure compliance can be included for agreement up front. Always document the process. This documentation should be simple enough to be understood by management, yet comprehensive enough to be implemented effectively and consistently within your organization by the technical people.

An important aspect of the scope of any audit is to define the audit objective; in other words, the goal of our audit. The audit objective must be understood by the auditor and all individuals and groups involved in the audit process.

The auditor needs to research many areas prior to an audit, including:

Research is generally one of the more time-consuming aspects of the audit. Successfully planning the audit in creating the checklist and scope prior to commencement will save time. Many people skimp on research time, believing they can make it up during the audit. This is a fallacy. Treat an audit like a project. Although the scope may change, there needs to be reasons for this change and it needs to be agreed and documented. The best way to ensure this will occur is to formalize the process, and the best way to do so is to start by researching the audit.

Even when you're auditing the same systems, research is critical. If you come back six months or a year later, there will be additional vulnerabilities, frameworks may have changed, policies could be updated, legislation could come into effect, and many other constraints that affect the system could now apply. A common mistake in audits is to assume nothing has changed and rerun the audit using a prior scope and checklist without reviewing and updating it where needed.

The research stage provides all the material for our “How To” guidelines. Each time an audit is conducted, this material should be saved. Although it needs to be updated every time an audit occurs, not all the material will change, and in fact, much of what we have done will also apply to other systems within an organization. Citing references also provides authority. Psychologically, people react to authority, and the addition of external references makes it more likely that the audit will be accepted and fewer scope changes will occur.

Planning the scope of an audit needs to be a collaborative effort, involving the audit team, management, and the system or process owner. Additionally, technical experts and other interested parties may also need to be involved.

The purpose of the audit will help us define the scope—“the why” of the audit. Generally, it is necessary to start with the purpose of the audit and refine it during the research phase as additional information becomes known. Working from the purpose of the audit (such as the need to become compliant to a regulatory standard such as the PCI-DSS for payment card processing), research will lead to a definition of the systems that need to be checked, the timeframe, and the standards that need to be met.

With the purpose and research together, scope can be planned with various milestones and completion stages. The goal of the scoping exercise is to get a basic scope plan together before taking it to management. There are likely to be changes when the scope is initially given to management, most of which will be rectified based on agreement. On the other hand, obtaining agreement on scope before doing additional research that leads to a change in scope and subsequent management re-approval makes the auditor or audit team appear incompetent.

Always ensure that you have researched and fully documented your scope before taking it to management for approval. Including a Gantt chart (see Figure 4.1) with the scope also makes it look like you have put more effort into the planning. It is generally unlikely that management will scrutinize the Gantt chart in any detail, but the simple fact that you have included it makes it more likely that the scope will be accepted, as it demonstrates forethought.

Research so far has provided the scope of our audit and hence the “what” of our audit. Now we need to think about the “how.” In the research, we covered many of the potentials for determining how we will conduct an audit, so now we have to choose which ones to use.

When creating an audit strategy, our aim is to produce the most effective means of achieving our purpose.

Categories of audit strategy include:

Each of these is detailed further in later chapters.

Audits should be treated as a project. Ensure that you have accounted for time and maintain metrics to report on time usage. Following an audit, these metrics can be used to see where overruns occurred and determine if inefficiencies exist. There are a number of reasons for this other than just budgeting, one of which is the ability to audit the audit. We can baseline the audit process itself and use these metrics to improve the process and aid in our determination problem areas.

In the event a particular phase or audit test takes far longer in one system or department within an organization, we can use the metrics to help point this problem out. This also provides ammunition if we need to go to management to solve the problem.

The old adage that “time is money” is true in audit and compliance just as much as any other area of business. The more efficiently we run our audit program, the more effective it will be. This does not mean that we run our testing as quickly as possible instead of as efficiently as possible; doing so would not give us the results we need. Similarly, if we spend too much time auditing a system seeking perfection, we will leave little or no time to audit any other systems.

Some aspects of time you need to consider include:

Time comes with a cost. When interviewing or working with others such a system administrators, we have to remember that we are taking their time—this is a cost. One of the reasons for collecting metrics about the audit is to be able to assess the real cost of conducting the audit. A further benefit is that this information may be used to justify the purchase or inclusion of commercial automated tools.

The cost of having a system administrator run a particular test several times a year to validate a control can be significant. For example, if the system administrator spends 100 hours a year running particular control tests and is paid $175 per hour, including benefits and office costs, the control test will cost the organization at least $17,500. If the job is particularly boring or undesirable, the cost may be higher because of staff turnover. If the time to conduct these tests was cut to 40 hours per year with the purchase of a tool that cost $6,000, we have an initial savings of $11,500 with potentially greater savings in future years.