Kaspersky To Build Secure OS For SCADA Systems

Trailrunner7 writes "Attacks against SCADA and industrial-control systems have become a major concern for private companies as well as government agencies, with executives and officials worried about the potential effects of a major compromise. Security experts in some circles have been warning about the possible ramifications of such an attack for some time now, and researchers have found scores of vulnerabilities in SCADA and ICS systems in the last couple of years. Now, engineers at Kaspersky Lab have begun work on new operating system designed to be a secure-by-design environment for the operation of SCADA and ICS systems. 'Well, re-designing ICS applications is not really an option. Again, too long, too pricey and no guarantees it will fit the process without any surprises. At the same time, the crux of the problem can be solved in a different way. OK, here is a vulnerable ICS but it does its job pretty well in controlling the process. We can leave the ICS as is but instead run it in a special environment developed with security in mind! Yes, I'm talking about a highly-tailored secure operating system dedicated to critical infrastructure,' Eugene Kaspersky said in an interview."

Re:This is a good idea with countless benefits.

[bluefoxlucid]

I think a Linux system that used PaX would be easy. Actually I used to maintain the list of incompatible apps--mostly Java itself, a handful of other things that turned out to be broken (and occasionally have critical security holes, none of which I personally found)--for Gentoo Linux. Thing about PaX is when something is killed, it's logged, and you get a wealth of debug data--when your program misbehaves, it usually dies from it early and it's easier to find the problem. This means developers have an easier time getting their software more correct, and the system doesn't do odd unexpected things (by bad software or by being hacked and worm-infested), and so the more secure system becomes the more usable system and the more maintainable system.

Similarly, for Unix environments, you could work on building out Minix and bolt on services that supply security guarantees as PaX does, and that interface between the user space utilities and the OS (because the OS Syscall handler is itself a service, you run the program under a DIFFERENT SERVICE) to implement namespaces and act as functional jails--virtualization, semi-virtualization. Services supplied under full microkernels like GNU HURD, L4, or Minix are small and thus easily audited for correctness--and thus improve security.

It all requires policy, of course. The PaX stuff is policy: no write/execute and no !execute to execute. If that crashes the program, you need to fix the program or remove that policy restriction. Semi-virtualization is mainly a file access policy--hide (can't see it), read-through (can see it, writes are redirected a la UnionFS), read-write (can see and change it, object is shared)--and a resource policy--PIDs, network devices/addresses, etc are hidden or shared. It's on the developer to do that, although forced policy on deployment is possible (you can externally generate a policy). grsecurity has always supplied a learning mode that logs and then develops policy automatically, which you can then audit for monkey business.