Cracking the code

Cracking the code

Technology is raising the stakes for corporate IT security. Regular audits adhering to minimum standards are necessary, but determining appetite for risk is even more important.

For many chief information officers, defining exactly which IT systems should be included in a complete security audit is as simple as working out the length of a piece of string. And for the chief executive, the most serious part of a security assessment is the problem of scope. Should they charge the CIO with auditing systems against absolutely any potential vulnerability or compliance standard to find any holes, or should they take a more realistic approach? The best way, CIOs and security experts say, is to audit systems to find your actual appetite for risk and eat accordingly.

What CEOs want from a security review is a better night's sleep and, to give them this, CIOs need to provide audit results in a way that clearly defines risks and what's being done to guard against them.

Assistant commissioner of IT security for the Australian Taxation Office, Chander Vohra, says that, ultimately, what the CEO wants is a security audit that puts risks in context and presents a mitigation plan the IT team has already developed.

Vohra also says it is critical to present the CEO with a clear implementation time line to remedy any vulnerabilities found during an assessment. "The ATO's IT systems are audited against the Defence Signals Directorate's 'protected' level," he says. "This means internally we review our systems from time to time but applications is what we've been typically focusing on.

"We have a list of critical applications and we focus on auditing against them because they have implications for the ATO."

He says the ATO attempts to audit internally against a review cycle of between two and three years, as well as organising independent third-party assessments. The Australian National Audit Office also conducts regular evaluations.

"My team keeps monitoring any systems through a formal process to develop plans for mitigation," Vohra says.

"The Commissioner of Taxation, Michael D'Ascenzo, wants to see a process-orientated approach to implementing changes. Basically, he doesn't want to see us accept risks for the sake of letting a project go ahead and wants to see that we implement controls at an acceptable level."

The chief executive of Australian information security consulting firm SIFT, Nick Ellsmore, says security audits are mainly to ease the collective mindsets of both the CIO and CEO. Executives want to know that they are at least as well protected against threats as their competitors are.

Ellsmore says an IT controls review, possibly conducted annually as part of an accounting audit, is normally just a checklist. He says security audits test the controls to "see if they can be subverted in creative ways that you can't identify in a checklist".

"The reality is, when you present an audit to the CEO, to them it's critical to weigh up the overall risk," he says. "The important thing is to get them information on how IT security relates to overall business risk."

Ellsmore believes that what the CEO is ultimately looking for as a result of a security audit is for the CIO to have a good understanding of risk and risk management, and what is being done about both.

Unless you are reviewing your systems against a specific compliance standard or have a benchmark of results you are attempting to meet, there is no defined starting or finishing point for a security audit - unless you are matching against a particular list of a vendor's known vulnerabilities.

Public, private: all the same

In the case of the ATO, being part of the public sector has a direct pay-off. The office can follow a set of established guidelines to implement security practices as outlined in the Protective Security Manual (PSM), issued by the Attorney-General's Protective Security Policy Committee.

Although private-sector companies have various compliance standards to audit against, such as Sarbanes-Oxley, public-sector organisations and government agencies, such as the ATO, adhere to procedures outlined by the Australian Government Information and Communications Technology Security Manual (ACSI 33) and other official walk-throughs, like the PSM.

Vohra says the ATO audits against the PSM whenever a new change comes through and its internal compliance base is regularly tested against ACSI 33, using both internal audits and external compliance reviews. Most of the nine or 10 members of Vohra's vulnerability management and research team plough through the various standards to keep their systems in compliance daily. They also trawl through vendor vulnerability lists. Help comes, in part, through an outsourcing relationship the ATO has with EDS, as the company can do much of the grunt work and push patches through for the Tax Office's approval.

LogicaCMG security practice manager Ajoy Ghosh says that in his experience auditing IT security systems in both private- and public-sector organisations, the issues are nearly always the same, regardless of which compliance or industry-specific IT standards are followed.

Ghosh says there is no one security standard in private- or public-sector industries that is held as the definitive rule, just different ways of achieving the same outcome. However, some private-sector organisations are requesting government-level security audits that may be outside the scope of their needs, so they can conduct business safely with either government agencies or the private sector.

"I think this push is being driven by critical infrastructure protection," Ghosh says. "Some private-sector organisations call us in to ask what commonwealth agencies want in terms of IT security.

"My frustration is that some private-sector organisations have spent a significant amount of effort complying with one particular standard and have called us in asking us to achieve the same thing but in a different way, with another standard.

"We recently completed an IT security audit for two large Australian banks, and in both cases the issues we found were not about what they were doing in terms of IT security, but how they were doing it. It wasn't insecure at all, just different from the way the government wanted them to do it."

Ghosh believes that the critical difference between an IT security review and a business-compliance audit is that in the former, the client expects the security team to turn over every stone in the organisation and point out vulnerabilities or even non-compliance. A business audit is generally performed to find out where new IT services can be added, to develop a future plan for software or services development.

One security problem common across private and public sectors is personal data being leaked or exposed. It is a problem that could become even more serious because of the possible introduction of a mandatory data-breach notification law included in an amendment of the Privacy Act that is due out in the next few months.

Establishing known risk

"The customer data is [usually] found outside where the organisation thought it should be, and it is typical to see an organisation spend a lot of money attempting to secure systems from this," Ghosh says. "But then the customer's data ends up populating other business systems and the organisation doesn't upgrade its IT security products and procedures until we do an audit, and then they're forced to change."

Deloitte's risk services partner, Tommy Viljoen, confirms that the CEO typically wants IT systems protected against whatever security incident has put competitors in the media. He says that from the CEO's point of view, this is done in one set way: the use of a security audit to establish a known risk and delegating the responsibility of fixing it to the CIO.

One issue clouding the picture for the information chief is determining which compliance framework or security posture to audit against or implement, because many elements already overlap. Viljoen says some companies may find they have to audit the same existing systems four or five times against multiple and overlapping compliance frameworks.

He says that the tricky part is finding out where the overlaps exist and delivering the most efficient responses to the various requirements.

"There are three elements to your typical IT security audit," Viljoen says. "Making sure that you have adequate IT controls in place; making sure the control is adhered to and is effective; and then the business element, which is making sure what is in place is sufficient for the business against the appropriate level of risk.

"That's very different from a business audit, which basically looks at efficiency and future systems.

"We look at things like adequate password protection, change-management procedures and a regular patching cycle, which is more about ensuring the integrity of the information rather than the confidentiality, as financial audits rarely look at privacy."

The ATO, in part through its relationship with EDS, has developed what Vohra says is a streamlined process of dealing with software vulnerabilities, anti-virus signatures and a host of software patches and implementations.

He says many of the software vendors they use keep them updated well ahead of time, sometimes by as much as six months, as to which patches are going to be released and when, and their level of critical or not-so-critical importance.

"We're constantly reviewing all published vulnerabilities and then make an assessment on their value to the ATO," he says. "We then follow through to the stage of application upgrades and the vulnerability management team performs penetration tests of systems before the changes go into production. The penetration test could take from one week to three weeks.

"As any new initiative for the ATO comes on board, we begin looking at incorporating security requirements from the initial design stage of the application and, as we go across every stage of the systems development life cycle, we make an assessment on which steps are required.

"We might get a risk assessment performed and, in some instances, we may go further and do full-penetration testing of the system. So, basically, risk assessment is an ongoing task with respect to everything we do. It's a well-established process.


  • Define the auditing scope with the CEO before starting a security audit.
  • Determine the desired outcome first and match the audit against that.
  • Understand the business's appetite for risk in IT systems and secure against it.
  • Consider the role your outsourcing organisation plays, especially with regard to systems management.
  • Patch regularly and often.
  • Keep an eye out for vendor vulnerability releases and factor in how they apply to your specific environment and risk appetite.

Fairfax Business Media

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags security audit

Show Comments