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."

Comments

Free with every purchase...

[Splat]

Monitoring and "remote support" by KGB included free with every purchase!

This is a good idea with countless benefits.

[Revotron]

They'll never go for it.

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.

Re:This is a good idea with countless benefits.

[Chris Mattern]

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.

And right there you've put your finger precisely on the problem. Fixing the program is hard--if you got it from a vendor, it might well be impossible. Removing the policy, on the other hand, is easy.

Just take them off the internet

[Billly Gates]

Make the client OS use DNS SEC and encrypted traffic for a secure network that is not physically connected to the internet or any network with a gateway to the internet. Why is this so hard?

This secure OS will eventually get compromised too if it has USB ports enabled, physically access to the machine, or be on a network.

Re:Just take them off the internet

[Anonymous Coward]

All of the SCADA systems I have installed are wireless. A potential hacker doesn't need physical access, they just need to be in range.

True story: The largest wireless SCADA system I did was for an oilfield company. I originally set up passwords made of random letters and numbers, making them as secure as possible. But less than a week after the system was up and running, they complained the passwords were too difficult to remember. So I was forced to change them all to something similar to President Skroob's luggage combination or not get paid.

(The SCADA radios ran Linux, in case you're interested...)

Re:Just take them off the internet

[Anonymous Coward]

No it wasn't WEP, and I'm in Canada. Iranians would never survive our winters.

Re:Just take them off the internet

[Billly Gates]

For one I can install a network sniffer on it to gain passwords. Then upload my own program to interact with the SCADA and destroy your equipment. With slashdot's earlier story of Iran planning a 9-11 like attack on American Infrastructure this is a very real concern.

Even Linux has security holes. They are not exploited on the net like Flash or Java ones but a rogue government or terrorists can use them to gain access.

Re:Just take them off the internet

[Chris Mattern]

Make the client OS use DNS SEC and encrypted traffic for a secure network that is not physically connected to the internet or any network with a gateway to the internet. Why is this so hard?

Because management wants the real-time reports on their desks. What do mean it's not secure? Everybody else does it. You're the only one who seems to have trouble doing this!

(another) BSD fork()?

[i.r.id10t]

Why waste the time in new development. Start with one of the BSD systems (already approved under iso9001/9002 type stuff) and either set up custom configurations, or fix what needs fixing.

I like the idea

[kasperd]

I do like the idea of an operating system designed with such security in mind. The operating system is probably also going to require some sort of real time guarantees, but otherwise no requirements for ultra high performance.

As far as security goes, I think one important aspect is transparency. Code running on the operating system should probably not have much freedom to modify the underlying system, but it is crucial that they can see what is going on, such that you can monitor that nothing unexpected is running on the system.

I guess for most SCADA systems the risk of bad stuff happening due to unauthorized changes is a much greater concern than leaking information from the system.

Are Kaspersky the right people to build the OS? Time will show.

Security through obscurity

[jader3rd]

"re-designing ICS applications is not really an option". If redesigning the apps isn't an option, how would a new OS help?

Re:Good Luck

[mlts]

That is exactly the same problem general desktop computing has. The OS is secure, the hardware is secure, it is the poorly engineered browser addons (and sometimes browsers) which bring the system to its knees from a security persepective.

Yes, this embedded OS is secure, but what gives me the ability to trust it? Old Cold War tensions aside, if someone hands me a lock and says, "trust me, its secure", that doesn't give me much assurance. Having source code available for peer review (even if it is commercial like PGP's source) would go a long way in assuring.

Otherwise, I don't see that much improvement between what it offers, and Linux's AppArmor/SELinux. I do like the fact that writes can be redirected elsewhere which isn't a part of any UNIX OS, but if need be, that functionality could be sort of cobbled together by making a snapshot and having a clone be a new filesystem.