What's going on with IT security in WA?

WA government departments are still failing to secure their most critical business applications, even after eight years of being exposed as insecure and risky by the state's auditor.

WA auditor general Colin Murphy is so frustrated with WA agencies that he’s threatening to name and shame those that don’t up their game.

It’s sad that it’s got to this stage, however, there must be something fundamentally going wrong with information security in WA. So what is it?

There’s one common theme running through this year’s report [pdf]. Agencies don’t seem to understand the need for up-to-date policies and procedures. It’s amazing to think that something as important as having policies, procedures and information security standards is not done well.

This is, after all, one of the easiest things to fix; typically the operationalising of standards and policy requirements is harder. If agencies aren't telling their developers what security requirements need to be met, it’s little wonder they are not being designed with adequate security controls built in.

This is the fundamental problem: if you don’t have policies, your architects, developers and even operators have no benchmark as to how secure systems need to be. Without a cogent, well-engineered set of requirements that you can pass to developers, you’ve no one to blame but yourself when the systems are built with insecurities.

Take, for example, the Department of Commerce’s complaints and licensing system (CALS). It contains plenty of sensitive, personal information that has been shown to be at risk due to insecure information transfers passing over the internet to third-parties, coupled with database vulnerabilities that increase the risk of unauthorised access.

“Commerce does not have a formal policy to govern software development standards and processes,” Murphy wrote.

Face palm. When you hire a software development company to build a new application, you need to tell them what you expect. You’ll undoubtedly undertake interface design workshops, as well as user requirements workshops and even systems requirements engineering discussions, so why wouldn’t you include information security and secure coding practises in your contract?

It’s not good enough to hope for the best. Yes, secure coding costs money and once you introduce it properly you’ll seed threat modelling, software security architecture and security requirements management into the software development lifecycle, which will inflate the cost.

But is this a reason not do it?

No. The cost of building security into your systems from the architecture stage of the project is significantly less than finding issues during testing.

Leaving your security check to the final stages of the project will see you presented with vulnerability reports that simply cannot be addressed before the system goes live. The risks highlighted by the project will be transferred to an operational team, who may have no say whatsoever in whether they accept them or not and when they can address them.

Furthermore, these risks may just be added to long list of other operational problems being juggled by management, so once again what was seen as a moderate or even critical risk in a project becomes nothing but noise in the chaos of day-to-day operations. 

This is Murphy’s eighth annual information security audit. His team has shown that WA has not improved in business continuity planning or even basic information security matters over this time.

WA agencies need to take the threat of being outed seriously.

They need security policies, information security standards, guidelines that tell developers how to code in your environment, and an assurance framework that system and software teams can follow. It also needs to be governed to make sure it works. They should also run their own internal audits to reduce the risk of being named and shamed in next year’s audit.

And ultimately, if you don’t have someone responsible for security within your organisation - someone on the payroll - you need to consider hiring one.

A chief information security officer should be the guy you look to who will help deliver strategic security guidance, who publishes cogent and clear policies, standards, guidelines and procedures, and has the gravitas and communications skills to work with all teams, internal and external, to deliver a joined-up approach to information security that truly lifts your game.