The main issue with ICS environments is the fact they nearly always require 24 x 7 x 365 up time. Not the usual 5-nines availability for critical or data storage or web apps. These environments cannot be stopped. Think oil pumps, water extraction systems, electricity production plants, gas transportation systems and so on. It's not really a case of finishing at 6pm, doing a few hours patching and updating, testing and ready for the 8am login rush. Those sorts of outage windows simply don't exist. This makes management of such environments difficult and has often lead in the past to legacy systems, often un-patched, performing critical services, simply because the downtime to replace or improve them is too great. Introduce the likes of Stuxnet into the equation and you can see the opportunity for malware is too great to ignore.
The scenario of SCADA and ICS systems becoming active targets is increasing. Not only are there potential nation-state sponsored cyber-war style attacks, but also the general cases of disgruntled employees and malicious and non-malicious negligence are common.
So whilst a new operating system could help, why hasn't this been done before? Microsoft, Apple and Linux have distributed operating systems for 25 plus years, but still their vulnerabilities are exploited daily. Kaspersky argue that a new OS would need to be so singularly focused, there has been either no business or technical incentive in the past for one to be completed. They also make the interesting point that a new OS would need to be developed independently of any previous code and to incorporate all the latest and greatest the security world has to offer.
This makes another interesting discussion point. Security isn't new. It's not as if all the security products in the market place today, with their new frameworks, approaches and standards, have all simply been created since Y2K and if we implement every single one, they will be no data breaches or exposures.
The 1975 reference paper 'Secure Design Principles' by Saltzer and Schroeder, makes several statements that even in 2012 still stand the test of time:
- Economy of mechanism: Keep the design as simple and small as possible.
- Fail-safe defaults: Base access decisions on permission rather than exclusion.
- Complete mediation: Every access to every object must be checked for authority.
- Open design: The design should not be secret.
- Separation of privilege: It’s safer if it takes two parties to agree to launch a missile than if one can do it alone.
- Least privilege: Operate with the minimal set of powers needed to get the job done.
- Least common mechanism: Minimize subsystems shared between or relied upon by mutually distrusting users.
- Psychological acceptability: Design security systems for ease of use.
If all points are applied to even the smallest of coding project or piece of business process, the security posture of an environment would be greatly increased. Small and simple design is an obvious one, which should be applied to any number of challenges in life.
Open design is another powerful aspect, often cited as the argument for general open source software. If the source code if freely available, the number of potential reviewers and bug fixers, out numbers any risks associated with adversaries seeing the code. This can also be applied to the basic recommendations surrounding cryptographic algorithms - choose an existing one that has had many years of both cryptanalyst attack work and adversarial cracking done against it. The main features of access control list management are all still sound. Use of separation of duty constraints are common in many role based access control framework products off the shelf and least privilege is built into many operating systems by default.
Psychological acceptability is an interesting concept, which still brings up discussions to this day. If security becomes too complex, inhibits end user productivity or convenience, it simply wont be implemented, resulting in less security not more. The outcome to strive for, is to either make security easily implementable, make security embedded into the product or process so it's there by default or make security entirely transparent - it's there, but it has zero impact on productivity.
The last few years has seen several opportunities for new operating systems, for things like smart phones and set top boxes. Whilst many rely heavily on what has gone before, they were a good opportunity to implement some of the basic key principles from Saltzer and Schroeder.
It will be interesting to see the results of the Kaspersky offering that hopefully will solve many of the basic security issues still being faced.