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

[Anonymous Coward]

When you say "Monitoring and "remote support" by KGB included free with every purchase!", are you Putin us on?

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.

[jythie]

Yeah.. secure systems tend to be ineffient to use or more work to maintain, so often people just switch off a lot of the security, esp when they are being used/maintained by people who just want to use them in order to complete other tasks.

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.

[AK Marc]

It won't work. SCADA was built off the assumption of physical security. It would take firing everyone who ever worked in SCADA to design the next generation of applications to get anything with security in it. Why would anyone switch to this "secure" system, when it's already more secure (physically) than any "program" can make it?

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.

Re:This is a good idea with countless benefits.

[jythie]

And that is the crux of the problem... while OSes have a wealth of security problems, generally when you drill down into break ins, one often finds that the hole was human (or institutional) in nature. Outside unintended consequences, making something secure and making something functional are mutually exclusive (or at least often conflicting) goals that humans will often just turn off security when it gets in the way of doing tasks they need done.

Re:This is a good idea with countless benefits.

[bluefoxlucid]

This is actually not as much of a problem as you think. Programs don't last forever, and they get rewritten a lot. Upgrades. New features. Refactoring, replacement. Remember the shiny new thing is more attractive, so businesses throw out the old and make new just for the sake of being more up-to-date than the competition.

As such, a feature that says "Requires you to disable the security features of your OS for this particular program" and a big scary warning box that says "Program is requesting policy to disable anti-hacker security protections for itself, may be susceptible to viruses and hackers [X]Allow [ ]Deny" will become a blight next to the competitor's app that "Takes advantage of advanced security protections." Eventually everyone fixes the minor bugs that cause this shit, and then everything just 'works' and we simply expect it to.

Your vendor doesn't want people looking at him funny. Fixing the problem is usually easy--with dynamic compilation (Java, .NET, etc) it's fundamentally impossible, but otherwise it's a matter of not doing a certain thing like self-modifying hand-optimized assembly.

Re:This is a good idea with countless benefits.

[bluefoxlucid]

No, that's stupid. As I said, the stricter guarantees that you must follow under PaX-alikes tend to make programs easier to debug. ASLR and W^X policies cause hard failures to happen more often and earlier in the failure process, rather than letting the program off-by-one and get away with it or just hobble along half-dead until it sputters out and dies miles away from where the error actually occurred. Debugger intervention and proper core dumps (with library layouts and other memory mappings) can be used to reconstruct the program state at the time of the error.

That means security makes the system easier to develop correct programs for, in this case. Correct programs are easier to use because they don't fuck up so much. Incorrect programs that run until you do something you really normally wouldn't do will of course get exploited...resulting in a crash because the security system doesn't allow for the basic required functionality that allows those kinds of exploits. There's a log, and the programmer scratches his head and issues a patch ten minutes later, correcting some poor bounds checking.

Re:This is a good idea with countless benefits.

[Platinumrat]

It won't work. SCADA was built off the assumption of physical security. It would take firing everyone who ever worked in SCADA to design the next generation of applications to get anything with security in it. Why would anyone switch to this "secure" system, when it's already more secure (physically) than any "program" can make it?

That's a bit of a stretch. I work in SCADA and it's not the developer's who are the problem. I, myself, harp on about security every other week. However, the marketing and development managers don't give a rats arse. If it's not a new "shiny" or something the competition has, then no money gets put into it.

Even when security is called out in the standards or client specifications, it's usually just security theater. The maintainers and end users don't want security and tend to bypass the token methods implemented anyway.

Re:This is a good idea with countless benefits.

[AK Marc]

I wasn't talking developers specifically, but usually SCADA is written by engineers and supported by IT, so you'd have to get rid of the engineers that made/designed it, as well as the managers that supported it. There's so much inertia around SCADA, and it started as an electrical spec for monitor, with an idea on someday using electricity to control. The "original" SCADA was electrically driven analogue gauges for monitor, with no control ability. Later, it evolved into a 2-way control, assuming you are in a locked room with the equipment and no external connectivity, so security was not even a passing thought, as if you were in the room alone, you has 100% control of the system in the first place, so securing the voltage on a few short wires was idiocy. I still use SCADA that is nothing other than analog voltage, which isn't securable in any form (increase voltage to increase opening, decrease to decrease opening, output gauge is a voltage, and +12V = 100%, and linerly decreases from there to 0V=0% or sometimes -12V = 0%).

Re:This is a good idea with countless benefits.

[grantspassalan]

Why do critical control systems need to be connected to the Internet? Computerized control systems such as SCADA have existed far longer than the Internet. There is also a difference between allowing critical quantities to be controlled remotely and these same critical quantities being monitored remotely. It MAY be permissible to allow read only monitoring over the Internet, but certainly, critical controls should never, ever at any time under any circumstances, be accessible from the Internet, so that some hacker in Russia, China, Iran or elsewhere in the world can change the parameters of a critical process.

Re:This is a good idea with countless benefits.

[mikael]

It's cheaper to run traffic over an Internet link that it is to buy a dedicated line. Knew one oil company who wanted to run an RGB composite video cable all the way underwater from an oil rig to the head office, just so the CEO's could see what was happening on the control system offshore. Fortunately, the consultants persuaded him that converting the video signal to digital and running that through the existing fibre-optic network would do just as well.

Re:This is a good idea with countless benefits.

[rioki]

Whats the deal?! Modern SCADA systems are secure by them selves. (Save a few implementation flaws, like any other system.) The problem is that the installations often are ridiculously unsafe. You get things like the Industrial Ethernet being switched with the office network, default passwords, the SPS in program/run mode and the likes. The important thing to remember about SCADA systems is that physical security is also part of the deal, who cares about the SCADA systems when you can access the petro chemical plant directly. I think the entire issue is overblown after Stuxnet and every security researcher wants to pitch in. The real weak spot are the engineering machines, which mostly run windows and are probably connected to the internet. You all know what that means. But apparently nobody ever considered this bit in the debate. Oh yea, how did Stuxnet work, yes it infected the engineering machines and altered the program and config. After that the program and config was totally valid in itself, thought not what it was originally meant to do.

Re:This is a good idea with countless benefits.

[AK Marc]

The engineers are the worst, almost as bad as doctors. They have a "technical" degree, like a degree in petroleum engineering makes you an expert in computers or programming. So they'll develop the thing themselves then demand the IT department hook it up to the network, and the IT manager doesn't want the fight with the COO, so yes it goes. And they are one virus away from a serious problem.

Re:This is a good idea with countless benefits.

[jythie]

Stricter programming tends to fall by the wayside as soon as development encounters things that the requirements make more difficult to prevent completely since, even if underwriters are putting pressure on, there is usually a more dirrect pressure to get something hacked together and out the door. If you have the luxary of time and funding you can build something using strict methodology.. but in corperate development that is rarely the case... esp when stricter development only covers a narrow class of exploits like PaX does.. leading to debugging that isn't all that much easier (unless the error falls into that specific range) and doesn't lead to that much better security (unless, again, the exploit is in that range). While still good practices, the cost is often seen as outweighing the benifit, and a false sense of security is part of that cost.

Re:This is a good idea with countless benefits.

[cusco]

businesses throw out the old and make new just for the sake of being more up-to-date than the competition.

Not so much for SCADA systems and the like. I worked at a place that still had a knee-high pile of 386 laptops in 2005, because the control program for their half million dollar radio tower wouldn't run on any other architecture. Finding a SCADA system that runs, for example, a power dam which is less than five years old will be difficult, since that's really a situation where "if it's not broke don't fix it" is really, really important. Even something as simple as an access control or video monitoring system will frequently stay in place without being touched for years. We have a customer whose access control system resides on a Win95 box, and which will stay there until the "server" finally dies. Very soon I'm going to be upgrading an access control system whose last update was 2002, and last year I moved one off of NT 4.0 SP3.

Not a problem when the system lives on its own network that touches nothing else in the world. The problem with these ancient systems is that in the name of efficiency they're getting put on the network backbone. Too many executives think that a VLAN is a security measure. Why would they run two separate networks with all of their attendant costs when both apps could run across the same switch? You know as well as I that people who get to make budgetary decisions in big companies don't get their positions by "wasting" their division's budget.

I've been looking for an actual secure architecture, at least for the server, for years. Not an OS like Windows or Linux that acquires "security" by a series of patches slapped on months/years after the fact, but one that is designed secure out of the box. We need to be able to at least secure the environment that these critical infrastructure systems run in, and the app should be prohibited from doing something stupid outside of its own memory space. Once the OS is secure we can start pointing fingers at Siemens and Bosch and the other vendors to fix their own products, but until that happens they don't have a whole lot of incentive to spend the money to do so since "everyone else has the same issue" and they can point the finger for any problems (rightfully or not) at the operating system.

Re:This is a good idea with countless benefits.

[bluefoxlucid]

Narrow class? 86% of the first 60 security exploits published as advisories by Ubuntu were covered by ASLR and W^X supplied by PaX.

Also, as I"ve stated repeatedly, the development changes under ASLR policy are: DON'T MAKE BROKEN CODE (really, the only break here is to assume an address for a dynamically allocated resource is always the same and hard-code it; or subtle corruption that semi-works because generally things don't move around). For the W^X protections supplied by PaX, W^X, ExecShield, and a host of other things, the most common problem encountered by non-broken software is that somebody wrote self-modifying hand-optimized assembly code or, ridiculously, thought they were clever by accomplishing a task with a small strip of assembly they put on the stack. That's actually harder to do than it is to NOT do.

These specific changes have minimal, predictable effects. W^X protections have to be disabled for i.e. Java and .NET, due to runtime code generation; otherwise triggering W^X is either a result of something being very broken--and it will tell you where--or someone being clever writing hand-optimized assembly that self-modifies or loads into a program variable on the stack or heap (neither of which is very clever). In either case, failures are both more predictable (i.e. easier to reproduce) and earlier in the failure sequence (i.e. easier to trace to root cause), meaning easier to debug.

If your argument consists of "well, sometimes, in development, there are trade-offs, and the changes can do some things, but it makes other things happen that have to be figured out, and that can be hard..." then you obviously don't understand computers as much more than a nebulous box that runs programs and sometimes gets a virus. Don't comment on program execution flow restrictions unless you actually understand program execution flow.

Re:This is a good idea with countless benefits.

[bluefoxlucid]

businesses throw out the old and make new just for the sake of being more up-to-date than the competition. Not so much for SCADA systems and the like.

Your entire argument becomes irrelevant because such systems aren't going to upgrade the underlying OS into a "secure OS" anyway. The OS is going to rot away with the underlying program because the WHOLE PACKAGE works, and if management wants it upgraded they're going to want the WHOLE PACKAGE upgraded--why the hell would you move a program from the 90s off an NT4 box onto an XP box? You get a NEW program and install it on shiny new Server 2008r2.

You want a secure architecture without bolt-on bullshit, go microkernels. Thing about microkernels is you can actually bolt-on bullshit without it BEING bolt-on bullshit. The pieces are largely like Legos, instead of like buildings in which you're trying to reenforce doors and add surveillance and alarms. In the very worst case, they're fairly easy to completely rework fundamentally--you can change pieces and wedge the interface in, then move through and correct everything piece-by-piece without getting lost.

Re:This is a good idea with countless benefits.

[cusco]

Actually very few are connected to the Internet, and then only by morons. More often what happens is the dedicated SCADA network gets "upgraded" and put on the corporate backbone by IT executives who think that a VLAN is "just as good" as a private network. This makes it a lot easier for the operator, who no longer needs a dedicated workstation just for the SCADA part of his job and who no longer has to sneaker-net reports from one network to the other, but the utter security failure is obvious to anyone below the level of Management.

Re:This is a good idea with countless benefits.

[cusco]

you can change...

Well, maybe YOU can, but I can't. I just install the stuff and make it work, I rely on folks like to give me the parts to put it together. I don't really **want** to move that 2002 package from NT to Server 2008 or Red Hat version whatever, and then repeat the exercise again in a few years. If the underlying OS is secure enough that it doesn't have to go through a major upgrade every two years (with all the necessary testing and downtime that involves) we can start poking vendors with sharp objects to get them to fix their own products. What we (the people out in the field) really need is a system that we can install and configure and then not touch until time to replace the hardware. The vendors have to remember who their target audience is, and that the vast majority of them are **NOT** computer security specialists.

I'm probably preaching to the choir.

Re:This is a good idea with countless benefits.

[bluefoxlucid]

Well, maybe YOU can, but I can't. I just install the stuff and make it work, I rely on folks like to give me the parts to put it together.

Bolt-on bullshit is bolt-on bullshit because refactoring a huge multi-million-line codebase is really freaking hard. Microkernels and other modular programming designs rely on small, specialized tasks so that the pieces can be shuffled, improved, and have other pieces interposed without the whole system needing a reworking front-to-back. Even Andrew Morton would have an easier time adding stuff like LSM to Minix rather than the (already completed, obviously) task of adding it to Linux.

Micro-modular software can get incremental updates more easily, for example notice you update library files easily enough and they rarely break. New versions of programs, completely reworked, still use the same core facilities in .dll or .so files. Similarly, microkernels like Minix and HURD tend to evolve in such a way that you can test new services individually and effectively upgrade the kernel in pieces. That makes things a bit easier, and security patches a lot easier to target and review (it's in this 4000 line service, these two lines. Not something that has major impact on the other 18 million lines of code, or a small 20,000 line subset thereof scattered amongst the sea of 18 million lines of code, which often happens).

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

[AK Marc]

Why encrypt the network if you encrypt and secure the application?

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

[ibsteve2u]

Concur. Makes me shudder to think of running SCADA over wireless....even if it were encrypted spread-spectrum technology. Between RF noise and signal injection/interception...lollll...makes my whole background want to throw up. Gimme that fiber!

Re:Just take them off the internet

[Billly Gates]

Just like the nuclear powerplant disaster in Japan the PHBs and cost accountants only care about costs as in have it all wireless so we can have 1 guy do the work of 20 by having it on the internet instead instead of having someone there.

This should be regulated if SCADA is used for any public infrastructure and one of them is no networking. Even a fiber link can get spliced. It is more difficult and expensive to do but Iran has the dough to do it and would be a target.

Re:Just take them off the internet

[MozeeToby]

There's more than one way to infect a system, and yes, most of them require user stupidity but there is no end to the supply of stupid users. The most commonly described example is to drop a few USB thumb drives in the parking lot with your worm on them, then just wait for some well intentioned (or not) employee to pick it up and either plug it in to see who it might belong to or start using it for day to day activities, such as updating software on the 'secure', air-gapped systems.

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

[grantspassalan]

Please explain to me how you can destroy equipment, if none of that equipment is connected to the Internet? Why do the controls say for a generator in a power station be made accessible over the Internet?

Re:Just take them off the internet

[Billly Gates]

Then someone will find another. The point is exploits do exist and the best solution is to focus on the problem. Not the symptoms. That is access. A more secure app or OS just reduces the symptoms that are totally preventable.

Power, telecommunications, water, nuclear, and oil/gas need regulation as dirty as that word is in the US because of idiot managers who love real time reports and remote manageability to cut down on costs. Something horrible will happen one of these days and it will be a very expensive problem to fix.

I do not trust kaspersky as I am sure Russia would love to have its own STUXNET as well.

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.

Re:Just take them off the internet

[F.Ultra]

Probably becayse encrypting the network is easier than securing a bunch of applications. Also there are standarads for how to secure a network so buggy and insecure implementations are less likely than with each application developer trying to secure their app.

Re:Just take them off the internet

[ibsteve2u]

Just like the nuclear powerplant disaster in Japan the PHBs and cost accountants only care about costs as in have it all wireless so we can have 1 guy do the work of 20 by having it on the internet instead instead of having someone there.

This should be regulated if SCADA is used for any public infrastructure and one of them is no networking. Even a fiber link can get spliced. It is more difficult and expensive to do but Iran has the dough to do it and would be a target.

Splicing is a mechanical action, and since humans do not move faster than light, that means that you can detect the signal alteration/disruption resulting from tampering with fiber.

I will concede that ability to safeguard the nation's SCADA networks does not rule out the possibility...the likelihood...that one or more CEOs will/have decided that short term profits - that is, increasing the value of their stock options, which is called "increasing shareholder value" for public consumption - outweighs the public's and the nation's safety and security and so the nation's industrial control systems are...Swiss cheese-y.

That - the only priority is "increasing shareholder value" - has been the rule in America since Jack Welch made it so...and he indeed was involved in the nuclear industry.

Re:Just take them off the internet

[cusco]

Splicing a piece of fiber can, and will, be detected as a momentary interruption in comms, but will anything be done about it? 99 % likelihood that as long as the original comm traffic resumes as normal the answer is 'No'. Switches reboot, GBICs lose connection momentarily, do you send someone to inspect the entire 20 miles of fiber run every time that happens? None of our customers do.

Re:Just take them off the internet

[cusco]

The worst problems aren't in the hardware or the software, but in the wetware. You can't fix stupid.

Re:Just take them off the internet

[foniksonik]

What's so hard about a one way dump of data? Open an outgoing port and send the data. Block all incoming requests.

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

Re:(another) BSD fork()?

[gentryx]

Exactly what I thought. Why reinvent the wheel? Shouldn't be too difficult to make BSD real-time capable.

Re:(another) BSD fork()?

[bluefoxlucid]

Minix. It's easier to do a major modification--the fact that it's only basically functional is not an issue, since it's a functional Unix OS without bells and whistles and you're going to be designing and implementing most of the bells and whistles.

Re:(another) BSD fork()?

[buttfuckinpimpnugget]

Agreed, but why beat around the bush? Start with OpenBSD.

Re:(another) BSD fork()?

[Anonymous Coward]

Once again the OpenBSD clan has stepped forward with a reasonable plan for saving the world, unfortunately as is par for the course with OpenBSD, their chosen representative refers to himself as buttfuckinpimpnugget to which the world replied with "oh god, what is wrong with you, go away, just go away!" and promptly returned to their course of apathetic self destruction.

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

Re:I like the idea

[kasperd]

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

That wasn't the sort of transparency I had in mind, when writing my comment. But I still agree with you. However I don't see a problem with it being kept secret in their design phase, as long as it is publicly vetted before being put in production. A bug bounty would also be a good idea.

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

[Kaenneth]

I would guess the new OS would be binary compatible with the old OS; just like you can run Windows 1.0 applications on Windows 7 (subject to quirks...)

Which would also be why just using BSD wouldn't work.

Re:Security through obscurity

[VortexCortex]

I've made several OSs -- It's not that hard. Protected Mode should have been the end of it, but you see, even hardware has bugs. Perfect software can be vulnerable on different hardware. Just look at any BIOS interrupt listing -- some BIOS interrupts are known to trash certain registers in an undocumented way. If our hardware doesn't always perform per spec then you're barking up the wrong fucking tree when it comes to security... Software is only part of the problem.

Re:Security through obscurity

[future assassin]

how would a new OS help?

Magic.

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

[gnalre]

If I had the points, I'd mod you up. Basically summed up all I was thinking

The 1970's called

[Anonymous Coward]

They want their capabilities architecture back.

Won't help much..

[Anonymous Coward]

The problem isn't the os. The problem is the programmers.
The culture, the style, the programming best practices.. It needs to change when it comes to embedded systems that need high security.

You need high standards for these things.. Instead mostly they are still slapped together like the crappiest web apps.

So now you're going to build an idiotproof os?
Well you know what they say about that...

Good - keep mickey out

[shalomsky]

Keep M$ out of mission critical and high-danger environments? Good, and it's about time. Nothing could be smarter.

15krpm

[Alex Belits]

That's how my eyes are rolling right now.

Kaspersky Lab is a company that has its whole business centered around digging through compromised insecure systems. They wouldn't know a secure design if it bit them in their faces.

Re:15krpm

[VortexCortex]

That's how my eyes are rolling right now.

Kaspersky Lab is a company that has its whole business centered around digging through compromised insecure systems. They wouldn't know a secure design if it bit them in their faces.

Man, I've still got this head-ache...
Well, damn, man. Don't you think you should see about getting that bear trap removed from your head.
What bear trap?!

Take your time, please

[netwarerip]

We aren't done completely hosing Iran's nuke program just yet. Once that is completely kaput then have at it!

Surely the military has solved this problem

[davidwr]

But then again, anyone who knows the solution would have to kill you if they told you.

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.

Re:"Argue with the numbers" vs. these companies

[Anonymous Coward]

I'm confused... GP never mentioned a hosts file...

first, redesign the assumptions.

[swschrad]

assumption 1: we can have remote control work. FALSE. any backdoor anywhere will open.

assumption 2: the vendor is secure. FALSE. any fixed system password is known to somebody bad.

assumption 3: we can use lowest-cost hardware. FALSE. there will be flash drives and dongles and games placed on these machines from who knows where.

assumption 4: we can firewall the net and have Smart Grid work safely. FALSE. it's >ALL fixed passwords out there in StupidGrid, wireless here and there, customer access... it's all bad. all. bad.

dump these bogus assumptions, and reconsider 50s systems management for SCADA... big box in the middle, no intelligence elsewhere, and no connections to anything outside the control room. much more secure.

But Windows is secure - NOT!

[hamster_nz]

Those of us who have been around a while will remember Microsoft trumpeting Windows NT's security.

"Microsoft included security as part of the initial design specifications for Windows NT, and it is pervasive in the operating system"

The whole Orange Book / Red book, C2 security level and so on,

They would be better off improving the failings of the existing system, rather than inventing a whole new set of ways to fail.

TCP for SCADA

[aaarrrgggh]

Wow.... You know what I really want... Trusted Computing Platform for SCADA. Because, hey... If I don't have verifiable challenge-response between a sensor and controller, how can I really trust it. Maybe they can even make the Thunderbiolt connector the standard, with authentication for all the cables! That would be great... Then we could just blame system failure in a bug on the authentication layer!

The need for interoperability is where most of the problems seem to come from. Properly securing and making a system truly bulletproof just isn't always justified.

Secure OS from ground up?

[aglider]

Or maybe Kaspersky will engineer some tightly security checked distribution of Linux/*BSD/Solaris?
Kaspersky should also take into account solutions like L4 or Minix3. I fear that really witing an OS from zero would be overkilling.

ICS?

[SuperMooCow]

Ice Cream Sandwich? Android?

Re:Good Luck

[lennier]

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.

If an operating system is written in such a way that it blindly gives full root-level access to untrusted third-party binary add-ons -- then your definition of "secure OS" is not the same as mine.

Seriously, it seems like in the last 20 years we've forgotten (or deliberately chosen to unlearn) everything we knew in the 1980s about security. The trend then was away from monolithic kernels towards microkernels, because, well, it's the only mathematically possible way to achieve security and reliability. (In the same way that "not distributing the decryption keys with the content" is the only mathematically possible way to achieve secure encryption.) But it was slow, at least back in the days when 4 Mhz CPUs and 1MB of RAM was a lot. So... we threw away security for speed. Raw C/C++ everywhere. And then built an entire global Internet based on operating systems built on a completely non-securable model. That includes Linux. Yes, do let's run native x86 machine code shared libraries everywhere, we can mitigate the damage after the fact with sufficiently clever code signing / virus scanning / patching. Except that, of course, in practice we can't.

Security of arbitrary x86 binaries is as much of a pipe dream as DRM is. It's simply impossible to close all the gaps when you're passing raw memory pointers and rewritable memory blocks around. The only way to do this right is to start from scratch, use a tiny security-audited microkernel at the bare metal level, with a securely designed message passing architecture everywhere above it. It'll be slow, it'll cost trillions of dollars in coder hours to rewrite all the incorrect code we wrote in the 1990-2000s boom, but it will be mathematically provable to be secure and not kill people.

So, of course, we won't be doing that anytime soon. Welcome to the Gibsonian cyberpunk present. System cracking as a videogame where everything is vulnerable and it's just a matter of how much you want to pay the Somalian Pirate Mafia or disgruntled USAF cyberwarfare cadets to buy the latest exploit. I used to think Neuromancer was a ridiculous scenario, that of course we'd fix the obvious bugs before Internet went 1.0; but we didn't, and now we're living the result.

We could have done it right. But we're stuffing up everything else on the planet, why did we expect that software would be any better?

Will only work if we get rid of the biggest issue

[rat7307]

This is all good in theory, but let's not forget WHY we have ended up here:

The Customer.

The Customer WANTED to have Windows based servers, the customer wanted to have integration on to their business networks using Windows protocols and standards.

DCS vendors for DECADES had their own OS's from the PLC up to the HMI , granted they were not secure, but they didn't need to be as they were not externally accessible, nor could they run anything untoward.

When the customer sees this new OS and can't get the data they want on to the managers desktop without expensive interfaces/hardware they will vote with their wallets and maintain the status quo.

I don't believe this will go anywhere.

SCADA/DCS/ICS Vendors will harden up their systems end-to-end and customers will still go and put VNC on their servers negating any work on the vendors behalf.

Qubes: the secure OS

[dgharmon]

"After nearly three years of development, Invisible Things Labs has finally released Qubes 1.0, a Fedora 17-based Linux distribution that tries to be as secure as possible by isolating various applications in their own virtual machines using Xen. If one of the applications is compromised, the damage is isolated to the domain it's running in" link

Re:London Stock Exchange, eh? LMAO!

[socceroos]

It's interesting to study the motivations behind posts like these. I find these posts quite hilarious and to absolutely miss the point.

One the one hand we're told, "don't feed the trolls", and this person is an obvious troll. But, some part of me wishes to implore them to see the bigger picture.

To whoever you are: circumstance should dictate the tools you use - sometimes this means Windows, sometimes this means Linux. You will rarely see Linux running the domain of a large business, but you would equally rarely see Windows running on the planet's super computers. Also, no operating system is secure. There are relative levels of security, yes, but please keep things in perspective.

Personally, I think the OS needs to be reinvented (I'll drool over a realtime, event sourced, distributed microkernel) - but it is prudent to recognize that this is merely one spoke in the wheel of security. Another spoke would be 3rd party applications, another would be uptime - the list goes on. Widen your field of view and smell the roses: everything sucks - make it work the best you can and be smart.

Re:London Stock Exchange, eh? LMAO!

[socceroos]

Oh yes, microkernels and especially event driven ones have high overheads - I just think that the trade-offs in this day and age are worth it. In terms of an event driven microkernel, I haven't really used one for my daily computing, no - but I am very interested in them, I'm a hobbyist in this area (however terrible I may be at it). I completely recognise that there is no silver bullet and that my wet dream of an OS could well be proven inadequate in the long run, but that doesn't change the fact that the industry at large has recognised the shortcomings of current designs.

Re:Posting truths != trolling

[socceroos]

I'm not stating you're a troll because all your information is incorrect - not so. But the manner and circumstance in which you have delivered this information lends yourself to be defined as such.

For the sake of brevity, I'm going to say you're not a troll.

Now, I've read many of the links you've posted and found them quite interesting and informative. What is your opinion of the Linux kernel? Also, what do you think of my opinion of the state of all the major OS kernels out there?

It's in C/C++. Can't be taken seriously.

[Animats]

They're writing it in C/C++. What could possibly go wrong? There are already embedded operating systems with reasonably good levels of assurance, such as LynxOS and QNX.

Re:Like I said before - posting truth != trolling

[socceroos]

Ah, so you're a linux desktop user of past releases? Slackware + Ubuntu/Kubuntu have been the ones I have tried too. And before Web 2.0 I spent most of my time on the FreeBSD command line using lynx! Wasn't maintainable though if I wanted to be involved in the WWW. =D

Just to help out your posts for future benefit (the ones that are concrete, verifiable, & undeniable facts as per your post: http://it.slashdot.org/comments.pl?sid=3189435&cid=41672457), it is worth noting that the second item on that list (NASDAQ) is misleading. Firstly, the comparisons are incorrect since they're not talking about the same transaction method (TPC-C vs TPC-E: http://www.siemon.com/uk/white_papers/08-03-03-latency.asp) and secondly, NASDAQ actually runs Linux for all the real market transactions (http://www.computerworlduk.com/in-depth/open-source/3246835/london-stock-exchange-linux-record-breaking-system-faces-new-challengers/) - they do this at over a million transactions per second (approximately 1,390,000 a second - please note that this is a bit faster than 65,000 per second). It's worth noting that nearly all exchanges run Linux for their core trading platform - that doesn't mean Linux is perfect though!

But I'm not attacking Microsoft Windows! I'm just helping you clear some things up. For example, the last semi-major stock exchange to use Windows was this one: http://www.microsoft.com/en-us/news/press/2010/dec10/12-15directedgepr.aspx

As you can see, Microsoft lauds the low latency of their new system (340 microseconds), but did you know that the latency of NASDAQ's Linux system is under 40 microseconds? That is unfortunately a huge difference in the Trade world: http://www.nasdaqomx.com/technology/marketplacesolutions/trading/

Anyway, I think there are OS's out there that can do better than both Windows and Linux in this area, but that's another discussion. I haven't got time to check all of your other links to verify that they are indeed all concrete, verifiable, & undeniable facts, but I'll leave that to you.

Re:London Stock Exchange, eh? LMAO!

[socceroos]

Which suggestion did I go back on, sorry?

Re:QNX...

[moogla]

QNX has had some security issues in the past, weaknesses built-in access control mechanisms and legacy capabilities that I think are dangerous to the uninformed, maybe giving you enough rope to hang yourself.
But he certainly seems to be reinventing the wheel; if security is paramount I'd recommend GHS Integrity RTOS. If you need something more well-known, it's certainly possible to develop secure firmware with VxWorks as a base.

The real security comes from a sound design on top of the COTS product(s), and a workable way to integrate that with external C&C, which is the responsibility of the group designing the whole package, and it can only be enhanced, not enforced, by the developer of the RTOS and other components.

If Kaspersky builds something that, as he claims, cannot be used insecurely, he may also develop something no one would want to use.

an actual secure architecture

[r00t]

Qubes OS, previously seen on Slashdot, ought to do nicely.

It looks like Linux, but it isn't. It's more like VMWare ESX Server. It's a tiny kernel that provides a desktop consisting of composited windows from guest VMs. Each window is labled according to the VM it runs in, with window borders colored according to security compartment.

Re:Good Luck

[mlts]

Even though SELinux and AppArmor provide limits on executables so something that has full root really doesn't, I will agree with you on the general point.

In the 1980s, we had many CPU architectures, with many varying bit lengths from 4 bits on up.

Come the 1990s and 2000s, we ended up with a fairly limited set of CPU architectures in the mainstream. Basically, ARM, x86, x86 with AMD 64 bit extensions, Itanium, SPARC, and POWER.

Yes, they are "good enough". However, these architectures were either designed for speed or squeezing the maximum performance out of every watt of energy used. Security is an afterthought.

I do agree that we need to start from scratch with a new CPU architecture designed from the ground up for security. Real security as stated above -- a microkernel and a proper message passing architecture. Perhaps we might even go on a limb and use the Harvard architecture so there is no way that data can ever be executed as code by accident, ever.

The reason we got to the mess we are in, are two things:

First, the "good enough" fallacy. x86 is cheap, so might as well use that, even though a future F0 0F bug, or even worse, a bug that allows escalation to ring 0 from ring 3 can be possible. Similar with ARM, ARM has "worlds" support which can have stuff run not just on different access levels on the same CPU, but split the security sensitive code to a completely separated, virtual CPU. However, few companies actually bother using this.

Second is the mantra of "security has no ROI/Geek Squad can clean up the mess" which has been the norm in companies. It is far cheaper to sweep the mess under the rug than actually do stuff the right way.

I'm sad to say, but this will keep going on. CPU architectures with security as an afterthought will continue to be the norm. If there is a "cyber-9/11", the only things that will change at a hardware level are added DRM stacks and backdoors, not actual security.

Re:I'll answer FOR him... apk

[socceroos]

I guess you didn't answer my question.

Re:VLANs

[cusco]

Ohh, a separate VLAN! Security by obscurity! How innovative!

Re:You answered for me... apk

[socceroos]

Still didn't answer my question.

Re:Linus Torvalds can... apk

[socceroos]

No, sorry, that doesn't answer my question in any way whatsoever. You still haven't answered my question.

Re:I replied on your ideas ... apk

[socceroos]

I'm not sure you understand - even if I did talk to Linus about microkernels it would not answer the question I asked you. You still haven't answered my question.

Re:Why don't you just ask it again

[socceroos]

You still haven't answered my question: http://slashdot.org/comments.pl?sid=3189435&cid=41677587

Re:Wasn't me on that one

[socceroos]

Yeah, I know that. But it still doesn't answer my question. You're not very good at this are you.

Re:Wasn't me on that one

[socceroos]

About 13 posts above you attempted to answer my question but you didn't - as you have already stated. So, you still haven't answered my question.

A provably secure OS is actually possible.

[jcr]

Look into the work that Jon Shapiro et al did on EROS and COYOTOS when he was at Johns Hopkins.

-jcr