Security Audit, Review and Test Planning

For the purpose of this post, I will state, audit, as the reality is that even a penetration test is a form of audit.

Security audit planning involves all actions that need to be taken before the audit actually begins. There are five key phrases involved with audit planning.

These are:

1. Researching the system or processes
2. Determining the scope of the audit
3. Formulating a strategy for the audit
4. Creating the audit checklist
5. Developing audit procedures and plans to ensure that the audit completes successfully.

The planning phase of any audit is arguably the most critical stage. This holds as much or more for a security audit where the results have to be justified and validated if the site under examination is to remain secure and vulnerabilities and risks are to be assessed correctly. It is in effect equivalent to the initiation stage of a project, and in fact an audit is analogous to a project in many ways. It is important to ensure that the scope of the audit is defined and agreed prior to starting the audit. A failure to agree on the scope will lead to cost overruns on may be problematic due to issues with permissions. This is one of the reasons why research is so critical. The research phase of the audit planning ensures that the audit team and management come to understand both the reason why the audit needs to occur and also the desired outcomes.

Additionally, good research will provide resources to the team that may aid in alleviating ill feelings or misgivings that often occur before an audit. Both technical staff and management commonly distrust audit teams. It does not matter whether this has occurred because of poor processes or bad feedback in the past but it does matter how the audit is handled presently. Quality research will demonstrate forethought and alleviate many of the concerns surrounding and audit.

Material collected during this phase will also go a long way to creating the “How To” component of the audit checklist. Detailing independent best practice research through the use of this document allows the others with in the organization to validate what you are doing before it occurs.

One of the real secrets of auditing is that the purpose of an audit is not to catch people out. By providing the checklist to those whose systems we seek to audit prior to the audit, we can provide them with an opportunity to rectify any control failures before we get there. In some instances the checklist may be provided weeks or months in advance of the audit date. This provides more than adequate time to allow for systems to be patched and vulnerabilities rectified.

The thing to think about is why we are doing this. Are we auditing to catch people out and get them in trouble? If so, we are unlikely to achieve any lasting results and at best technical teams will do their utmost to subvert the audit process. On the other hand if we work with the organization (ours internally or as an external party client) we will achieve better results. If you think about it, it is always better to have a system vulnerability patched before an audit. If we are waiting for the vulnerability to be mitigated or control to be implemented following an audit it may be a year before the next audit occurs. In this event it is likely that any improvements to the system will occur just before the next audit.

This could be a year later.

Ideally, the best audit strategy is a rolling audit of at least 120% of the systems selected randomly without notification. Here, a small section of the organization is tested before moving to the next. As the process is random and covers 120% of the organization, all sections will be audited yearly, but employees and contractors cannot become complacent as their systems can be audited again in any following period.