Infrastructure Security Audit: Guidelines for Best Protection


The key to passing any IT security audit is demonstrating firm control over enterprise technology and the people that use it. It’s not much different for an infrastructure audit except in this case the focus is on showing that enterprise hardware is secure.

Yet, there are numerous potential points of weakness in hardware that can make it difficult to know where to begin. Fortunately, there are guidelines that can lead you in the right direction and help form the foundation of an infrastructure audit framework that you can build on over time. Here’s a look at some of these.

1. Establish a Baseline

Infrastructure audits shouldn’t take place in a vacuum. The absence of benchmarks can make it difficult to determine what outcome means your infrastructure has passed the audit and what are the characteristics of failure. You must develop a baseline against which the audit is rated.

This isn’t a one-time thing though. Technology often changes much faster than the business policies that oversee it can keep up. An annual risk assessment (preferably by a third party assessor) can ensure that the security baseline stays current, relevant and effective.

A baseline also helps you know whether the organization is making progress in protecting its infrastructure or is moving backwards.

2. Granular Role-Based Access Control

Develop and enforce a role-based access control policy for all servers and network devices. Whenever there’s an unauthorized attempt at logging into your hardware, IT security staff and IT management should receive an immediate notification so they can alert system administrators as well as the relevant line department heads.

In instances where some processes are outsourced or partially handled by a third party, the same controls applicable within the organization should be applied to the infrastructure of these third parties. The organization should ensure contracts include the right to audit user access rights at the third party’s facility.

3. Maintain Insightful Audit Trails

Organizations tend to focus on the audit trails of business applications and fail to do the same for their hardware. Yet, infrastructure activity logs such as the components of .NET architecture are just as if not more important than application trails. Remember that if someone can take control of your infrastructure, they have great sway over the applications that run on it.

Ergo, keep audit trails of your servers and network devices. Most hardware manufacturers will allow you to choose the fields you’d like to see in the logs. The purpose of a log is to notify you of suspicious activity and give you the depth of information you need to identify who or what is responsible.

At the minimum, infrastructure audit trails should tell you the what, who, when and where of all system activity and changes.


4. Robust Change Management

All IT infrastructure has a useful life. It could be that the device has fallen into such a state of disrepair and obsolescence that maintenance and firmware upgrades wouldn’t help much or make financial sense. At other times, infrastructure must be changed because the business needs better quality and higher capacity equipment to accommodate its medium term goals.

When an organization does change its equipment, it’s crucial that the new equipment remains compliant with enterprise security standards as well as industry best practice. As opposed to waiting until the end of the year to confirm compliance (thereby exposing the business to cyber threats), the enterprise should include an IT security compliance checkbox as part of the standard checklist followed when installing new equipment.

5. On-Demand System-Generated Historical Reports

Audits are meant to confirm that system configuration and user activity is in compliance with company policy and industry regulation. To do this, the infrastructure security auditor must have access to historical reports of system activity to confirm that security standards and controls are enforced consistently.

But not just any reports will do. Security reports should be system-generated and require little to no human intervention (perhaps with the exception of initiating the report generation itself). The reports should include a mechanism to check if the report has been manually altered in any way after system generation.

The less the need for human intervention, the more reliable the reports would be.

6. Ensure Independence

One of the biggest dangers to the quality of an infrastructure audit is a conflict of interest. If an infrastructure auditor reports to the COO, CIO, Head of IT or other senior manager who was deeply involved in the acquisition and installation of IT infrastructure, they may run into determined resistance to their findings even before they can get the report to the board.

Since these senior executives can determine the auditor’s rating during the annual performance appraisal, the auditor will be hesitant to file a report that would depict them in poor light. Instead, the infrastructure auditor should report to an office or body that has oversight over the people in charge of enterprise infrastructure. That would be the board and, in some cases, the chief risk officer.


By applying the above guidelines, organizations will be in an excellent position to not only pass their next audit but also assure their users, customers, shareholders and regulators of the security of their infrastructure.