IT Security from Down Under
Nevertheless, there are signs that public-sector employees are realizing that these data-security requirements are a normal part of doing business and will therefore be the normal IT methodology from now on.
If we contrast this methodology with that of the U.S., we can see that budget issues have started to encroach on the need to reduce the security-risk profile, as has been the norm in Australia for several years, even after the economic downturn hit the world’s economies.
In fact, if we look closely at the Signals Intelligence (SIGINT) aspect of U.S. national security we can see that the shift in U.S. intelligence collection priorities since the September 11, 2001, terrorist attacks on New York and Washington has continued, largely thanks to a security commitment made by the U.S. government in the aftermath of the tragedy.
But what’s interesting about the U.S. approach to national infrastructure and that seen in Australia is that Australia’s public-sector workers have effectively been told which operating system and software they will be using in the workplace — i.e., what IT governance/security staff can plan and accommodate accordingly — while their U.S. counterparts are still allowed to select which software suits them best.
IT purists might argue that this makes for a more efficient IT user base in the U.S. government and its agencies when compared to their Australian colleagues, but there are real reasons behind the Australian mandate on what operating systems and software employees can and cannot use.
A clear example of this is the use of SCADA (Supervisory Control and Data Acquisition) computer control systems, seen at the heart of many industrial automation and control systems. Developed in the 1960s, SCADA-driven systems really came into their own with the arrival of the first PCs in the ‘80s, and are typically found in industrial systems such as power plants, chemical plants, electricity supply grids, and many others that require a high degree of computerized control as well as 100 percent systems availability.
This is Mission Critical: capital M, capital C. Many businesses claim their IT processes are mission critical, but SCADA control systems are often critical to national infrastructures. For example, if a country’s electrical grid goes down it can cost industry many tens of millions of pounds per hour, and in the case of hospitals, air-traffic-control systems and the like, can actually place people’s lives in jeopardy.
Despite the fact that a growing number of PC users in the private and public sector are migrating, or have migrated, to the Windows 7 platform (with Windows 8 on deck), most SCADA-based systems use a robust and ruggedized version of Windows 98, a 16-bit version of Windows dating back to the late ‘90s.
The reason for this apparent Luddite approach is quite simple: by using a stable and unchanged operating system that’s been fully updated and completed its life cycle, SCADA-based systems can have their operating system loaded into firmware. This means that although there is no equivalent of Microsoft’s “Patch Tuesday” update program for Windows 98, cybercriminals can’t easily subvert the code of SCADA-based systems since the firmware-based operating system is fixed and can’t be updated.
This fully embedded firmware approach is fairly unique to SCADA-based operating systems but helps one to understand why a highly controlled operating system and software environment, as mandated under the Australian DSD’s diktat, has a far lower risk of subversion than the open-market approach seen in the U.S. and certain parts of Europe.
While we understand the need to maintain choice in an open-market environment, this doesn’t mean that the Australian ideas enshrined in the DSD report can’t be applied elsewhere in the free world.
