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!

Re:Free with every purchase...

[arglebargle_xiv]

Sumerians? A bunch of amateurs! If you want a great OS, you have to with a Hittite OS.

I'm sorry, we're Medes and we're lost in this desert of a web board. Could you direct us to the exit? And sorry about the arrows.

Re:Free with every purchase...

[socceroos]

I was russian to say the same thing but you beat me to it. I'm stalin to think that this whole thing is a hoax.

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.

Internet passports

[EmperorOfCanada]

Aren't Kaspersky Labs the bozos who supported Internet passports? That is such a dumb idea that my computer lost 100Mhz just browsing the article. These guys just have verisign envy and want to get between users and hardware in order to charge rent.

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!

Re:Just take them off the internet

[LordLimecat]

For one I can install a network sniffer on it to gain passwords

Not if youre using a secure application like SSH, which was his point.

Re:Just take them off the internet

[Billly Gates]

Easy to reduce costs and PHB can get their real time reports. If you have lets say 45 oil wells out in the field over a 700 mile area it is much more cost effective to have them on the internet where Bob with IE 6 with is all secure non signed activeX control, can work on each of them and check settings etc.

In the old days you would need 20 people doing Bob's job driving to oil well after oil well doing work, shutting off leaky valves, and documenting paperwork. Nuclear powerplants love internet enabled controls because it reduces the personnel in potentially dangerous areas.

These are targets Iran would love to attack and the State department said are in the process of doing. It seems retarded for safety reasons but it can cut on costs and automated software and do things like shut down values on leaky oil pipes. The PLC in the SCADA can easily destroy the equipment as they instruct the motors what to do.

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

Re:I like the idea

[TubeSteak]

As far as security goes, I think one important aspect is transparency.

FTFA:

Threatpost: What are the most important features for the new OS?

Eugene Kaspersky: Alas, I cannot disclose many details about it.

A secure OS shouldn't need to be kept secret.
It should be publicly vetted like an encryption algorithm

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:Security through obscurity

[JWW]

I'm assuming they want to sandbox access to lower level hardware, which can be done with a modified OS.

Except SCADA's a strange bird in that respect. While low level access to network hardware might not be needed by the control interface, low level access to the controllers and monitoring systems is needed.

They're onto something when they're talking about a custom OS. But that problem had largely been solved in the past, until all the engineers and operators wanted SCADA interfaces that ran on Windows. After that security was always an afterthought and you reap what you sow.

Re:Security through obscurity

[sapphire wyvern]

I'm confused about what, exactly, is supposed to run on top of this new operating system.

Is it supposed to be a new OS for devices with physical-layer control capability like PLCs (Programmable Logic Controllers), DCSs (Distributed Control Systems) and RTUs (Remote Terminal Units)?

If so, I don't see how it would help, since each of these devices has its own unique proprietary hardware architecture. It's highly unlikely Kaspersky could effectively support the hardware.

Or is it supposed to be for hosting central SCADA servers, and historian/MES server type applications?
This is probably the easiest place to gain some traction, although most of the SCADA servers, historians and MESs I've ever worked with have been based to a lesser or greater extent on Microsoft technologies. For example, the OPC APIs are one of the most common ways of interconnecting server-side ICS software from different vendors, and that's based on COM/DCOM - so it's unlikely to be supported on non-Windows platforms. One way you can make it work is to have the SCADA server itself run on a non-Windows platform which then communicates using a proprietary protocol to a Windows data interchange "gateway" which runs an OPC interface. But if your data interface gateway gets pwned, you might not have gained much from having the main server process running on some kind of ultra-hard OS.

Or is it supposed to be for hosting client applications that humans interact with directly (HMI) for control, monitoring, data analysis, or engineering (configuration/programming/diagnostics/troubleshooting) purposes?
At the moment, the actual operator interface for most SCADA systems are proprietary desktop apps, although there does seem to be a trend towards using HTML5 and other web technology for the operational HMI. That eliminates the need to deploy & manage client software and reduces the dependency on Windows. With appropriate access controls on the SCADA server (DON'T allow access from the internet!), that's not necessarily a problem. But right now, an operator generally interacts with their SCADA server by running a desktop (usually Windows) application which connects to the server. The desktop apps are maintained by the ICS software vendors and for reasons of cost and market penetration, almost all the "modern" ones target Windows primarily and other OSs secondarily if at all.

But aside from the fact that most of the client apps are Windows apps, the operator interfaces generally need to run on a general-purpose OS because analysts need to be able to collate & correlate data from ICS and non-ICS sources, and plant operators need to be able to access other business systems like maintenance planning & dispatch tools, weather data, security camera systems, work plans, enterprise reporting systems, etc. There's no point in collecting extensive data about your operations if you can't actually use it to improve your business's operations!

Basically, you need to be able to run Excel, a web browser, and (for the engineers) more proprietary tools from your hardware vendors for things like configuring/troubleshooting the SCADA hardware.

Web browsers are of course very cross-platform, and non-Excel spreadsheet software does exist (although Excel basically owns corporate data analysis at the low to middle end, at least in the West). But web browsers on all platforms are pretty flakey from a security perspective and almost all the configuration, programming and diagnostic software tools which come with industrial hardware are, again, based on the Win32 or .NET APIs because that's what corporate computers have. There is little likelihood that industrial hardware vendors will be enthusiastic about rewriting all these tools for an exotic new OS. And since the primary design objective of the exotic new OS is security, it presumably doesn't use existing complex and bug-riddled desktop environment software stacks.

Is a WINE + Mono compatibility layer on

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.