New Windows Virus Targeted at Industrial Controls

In reply to David Ferguson: To correct something that you said, the PLC was not being "hacked". It was being re-programmed using the normal PLC commands which are present for that purpose. The computer however was being "hacked" by the virus, via security holes in MS Windows.

There is a very important difference between the two situations. There are many tens of thousands (hundreds of thousands?) of viruses which affect MS Windows. Viruses which affect anything else are extremely rare. While this particular virus is quite clever, the same sort of attack on PLCs (any brand of PLC) could be repeated using any run of the mill MS Windows virus. New MS Windows viruses come out all the time, so anyone who felt motivated could repeat this feat quite easily.

And to address another point that you stated:

> switching the OS will not change a thing, if
> they want in, they will get in, even if that
> means walking in and accessing the machine with
> the Linux software...........IT IS NOT THE
> SOFTWARE, it is the fact that there is software
> at all, instead of hard coded HARDWARE.......

Well, if as you said you're granting physical access, then they can indeed reprogram the hard coded hardware just as easily as they could the software. Of course they could just smash the machine up with a sledge hammer in that case too.

You can talk about all sorts of hypothetical situations, but I like to look at things from a practical point of view. Let's look at what is happening in the real world here. We don't have the Mission Impossible team rappelling through the skylights to plant a bug in our PLC programs. We have an MS Windows virus just like thousands of other MS Windows viruses except this one re-programs PLCs instead of stealing information or sending spam. It's just taking advantage of bugs and holes in MS Windows, just like all the other viruses.

From a practical point of view, we don't need to solve the global MS Windows virus problem. We just need to find a way to avoid being directly affected by it.
 
D

David Ferguson

Curt:

Nor will they know or care about Linux security, we are a product of our own demise...........if you make it complicated or if it requires them to RTFM (read the F***ing Manual) then this is what happens. Our jobs get hard as we are expected to know all of this (including Windows security, or Linux). As we have less and less people doing more and more, as I like to say the memory bank only holds so much and there are fewer and fewer good control people out there let alone good ones with IT security background.

But lets not kid ourselves, THEY ARE ATTACKING THE PLC they are getting there via a wooden horse (Windows) but they are getting there because the guards are sleeping and the very same people you say will configure Linux to be secure etc will be a short in demand as the ones who know how to truly lock down windows. In other words there are not enough good guards out there anymore. There are not 2 or 3 for every company in America (let alone the world).

It would be just a matter of time until the same determined person would get to the PLC. It is also just a matter of time before someone with a little knowledge, opens up all your security holes because they are tired of getting phone calls (just like Windows).

The only thing your plan would do is to DELAY this happening again, but the huge outlay of effort to switch over would cost the country billions. I say train people to secure what we already own. We won't do it because we are lazy but it takes issues like this to bring it to a head.

The issue is if we go out and switch every company and every software vendor to Linux based OS with much pain and cost (yes it is more than the cost of the OS, it is the time to rebuild every machine and the downtime and resources which do not exist), then someone will hack it because it is now a bigger target. We would have SP's to fix the patches. We would complain that it was not accessible and we would have to open it up for accessability and after 10 - 15 years (if you could pull it off in that time), we would be on this list complaining and calling to use Blunix or whatever was the latest patch.

But we would be too stupid to put 2 and 2 together (goldfish memory) and realize we had not addressed the real issue. Do not hook your control system to the Internet without DMZ (and I say do not at all), do not allow access to your control system boxes (KVM's extenders and locked control rooms). Hire back some of the people you laid off to stay on top of securing your system and generally do the right things..........

Like they say the only secure way to prevent access to a computer is to shut it off.

The answer to 10 problems is not 11.

Dave Ferguson
 
D

David Ferguson

That is my point, a trojan horse is being used to get in but once in, it is the PLC that is being modified "hacked" (using the tools to modify the PLC program) if that makes you feel any better. I agree potato or potato........

As to Curt's point, you can lock down Windows just as secure if you want to and you should.......we do. If you install it straight out of the box then you get what you deserve, but then again everything said above is my point exactly.

As to the age old WINDOWS rant ................. you get out what you put in, if you leave things wide open and plug them into the internet and let them play solitaire on your control boxes..........you deserve to get HACKED.

Dave Ferguson
Control Systems Engineer
 
In reply to Robert: Reports indicate that so far the virus seem to be targeting its payload for the combination of Siemens WinCC with Siemens S7 PLCs. Hypothetically any PLC, servo drive, robot, or anything else that can be programmed or configured via a PC could be affected by some future version of this or some other virus. However, right now this particular virus is designed to re-program S7 PLCs.

The virus does take up residence in any MS Windows computer it can find. The virus is being sprayed out in all directions in the hope that it will find a PLC somewhere. Most of the people who are having problems with this virus have nothing to do with PLCs. Some of the people reading this may have the virus on their computers at work or at home but don't realise it yet.
 
In reply to David Ferguson: You said:

>the very same people you say will
>configure Linux to be secure
>etc will be a short in demand as the
>ones who know how to truly lock down
>windows. In other words there are not
>enough good guards out there anymore.

I think you're missing the point. Of *course* the average *user* won't and can't know how to secure a computer properly. That's what people have been trying to *tell* you. However the *vendor* can hire the necessary experts to figure out how to do this *provided* the vendor is supplying the complete OS and application stack on the same disk as their SCADA/HMI package.

You would stick the disk in the slot and press the go button and 15 minutes later it would have installed everything you need for a secure SCADA or HMI system. You wouldn't configure anything except your SCADA/HMI screens and tags. That's how high security computer systems work. If the vendor has to re-compile the OS with some special compiler setting to get "super security" mode, that's *their* problem. And if the resulting system won't run iTunes and 15 year old accounting packages, nobody cares. It's an appliance. It has a particular purpose in mind so the vendor doesn't have to make compromises to keep the video game and Facebook fans happy.

The SCADA and HMI vendors can't do this under their existing model because they aren't supplying the complete software stack (OS, libraries, development tool chain, databases, etc.). Their customers are buying PCs at stores or from on-line retailers with MS Windows already installed and configured any of hundreds of different ways with different MS Windows versions, different libraries, different Dot Net frameworks, etc.

There's no standard system they can rely on so they can't make any assumptions about the way things are configured and they know that if they start meddling too much with the configuration settings in MS Windows the whole thing might stop working. The result is that the responsibility for securing the system gets left up to the end user, which usually means it doesn't get done at all.

The only way to reliably do a proper job of computer security is to completely wipe the hard drive and install a system that is closely tailored to the application and carefully tested. Trying to tweak random video game / Facebook computers into high security systems is a waste of time.
 
C

curt wuollet

I'd like to be a fly on the wall when you tell your customer they deserved to get hacked. And I'd like a show of hands of all our gentle readers as to how many of them could install Windows tonight, and get it locked down properly, up to the latest threats, betting their job upon it?

I think distributing a secured system is a much better bet. A purpose built OS without thousands of published exploits would seem much less likely to be compromised by any rational analysis, but as I've mentioned before, the defense of that decision is anything but rational. And simply _not_ leaving security up to chance or the luck of the draw as to who installs the stuff seems like a more reasonable choice if you want any degree of confidence. But, in the real world, the way it is actually being done, is obviously not securing anything.

Controlling a large portion of that process and eliminating the variability would seem to be hard to argue against objectively. But then, sticking with the most penetrated OS in existence must make sense to someone.

Regards
cww
 
C

curt wuollet

That is pretty much the point, yes. And even if you can't go all the way
to the appliance level, simply using an OS with all the consumer crap deleted and all unnecessary services disabled would be orders of magnitude better than depending on the average user, who is often the problem.

Regards
cww
 
C

curt wuollet

Hi Dave

DF: >Curt:
Nor will they know or care about Linux security, we are a product of our own demise...........if you make it complicated or if it requires them to RTFM (read the F***ing Manual) then this is what happens. Our jobs get hard as we are expected to know all of this (including Windows security, or Linux). As we have less and less people doing more and more, as I like to say the memory bank only holds so much and there are fewer and fewer good control people out there let alone good ones with IT security background.<

The idea is that they don't have to care about security, it's out
of their hands. And as for complexity, the application would be all
they have to worry about. With a dedicated automation OS, you can
set it up so they never even know what OS it's running on. All they
see is the application, you can't get much simpler than that. And I
can probably personally suggest enough people with the required expertise to cover the automation vendors. That's the whole advantage of securing it at the source. You would never know that your Android phone is running Linux, and it doesn't seem to confuse anyone.

DF: > But lets not kid ourselves, THEY ARE ATTACKING THE PLC they are getting there via a wooden horse (Windows) but they are getting there because the guards are sleeping and the very same people you say will configure Linux to be secure etc will be a short in demand as the ones who know how to truly lock down windows. In other words there are not enough good guards out there anymore. There are not 2 or 3 for every company in America (let alone the world).<

As I've said before, I think any "always on" connection between your control systems and the world is simply not worth the risk. But, since people will do this anyway, a secured system is even more important.

DF: >It would be just a matter of time until the same determined person would get to the PLC. It is also just a matter of time before someone with a little knowledge, opens up all your security holes because they are tired of getting phone calls (just like Windows). The only thing your plan would do is to DELAY this happening again, but the huge outlay of effort to switch over would cost the country billions. I say train people to secure what we already own. We won't do it because we are lazy but it takes issues like this to bring it to a head.<

A more reasoned argument, but I think the delay has already occurred. It's time to do something different and it will not happen given the direction Windows is taking. It's simply the wrong direction for automation use. I am reminded of Deming's definition of insanity. That's where you keep doing things the same way and expect the result to be different.

If past history is any indication, that change is not coming from Redmond. And users, by and large, don't seem to be changing much either.

DF: >The issue is if we go out and switch every company and every software vendor to Linux based OS with much pain and cost (yes it is more than the cost of the OS, it is the time to rebuild every machine and the downtime and resources which do not exist), then someone will hack it because it is now a bigger target. We would have SP's to fix the patches. We would complain that it was not accessible and we would have to open it up for accessability and after 10 - 15 years (if you could pull it off in that time), we would be on this list complaining and calling to use Blunix or whatever was the latest patch.<

I suspect the cost would not be much more that the cost of all the antivirus measures and labor to try to plug the leaky boat when offset from savings on the software and elimination of the upgrade mill. For the vendors to have control of the OS would save vast amounts of time and effort riding the MS merry go round. It wouldn't
take many "upgrades" eliminated to pay for the whole process. And everybody saves that way.

DF: >But we would be too stupid to put 2 and 2 together (goldfish memory) and realize we had not addressed the real issue. Do not hook your control system to the Internet without DMZ (and I say do not at all), do not allow access to your control system boxes (KVM's extenders and locked control rooms). Hire back some of the people you laid off to stay on top of securing your system and generally do the right things.......... Like they say the only secure way to prevent access to a computer is to shut it off. The answer to 10 problems is not 11.<

The problem with that is that, while we aren't looking the PLC is becoming the computer, That will continue and speaks even more strongly for a uniform OS that can run on the PCs and PACs across architectures and is tailored for automation. Switching now could make that happen seamlessly. I would be surprised if someone, somewhere, isn't already designing a PAC using Android or Embedded Linux. It's simply the easiest way.

Even I can do that :^)

Regards
cww
 
D

David Ferguson

Well I guess we will just go into year 12 or 13 or 15 and see who is right. I am guessing that we will not do anything about this issue. There are rumors out there that this looks to be too good a virus to be other than being done by a "nationality" state sponsored event. My guess is if that is the case...........no system would be safe.

I think you oversimplify the solution and all of the issues with hardware etc. but then again we are sitting at this babble for over a decade and here we still sit......the loud minority still has not convinced the silent majority to change.......

Remember the huge expense you say is coming from the Redmond extortion upgrade mill is a very, very small part of the projects that I do. I am lucky if the control system is 1% of the project............so getting someone to take on a risk or a change from "acceptable" risk won't be happening..................after all how is the acceptance coming for the "open" plc, many posts, no open PLC, no open HMI yet?

Not going to happen in my career time, doesn't even hit the radar of the people I work for.

But before we argue this we should know what is really happening with Stuxnet, not what is being thrown out in the media and on this list as FUD........

Dave Ferguson
Still making a living solving problems with the currently accepted methods !!!!!
 
K

Ken Emmons Jr.

Curt,
I kind of know where you are going with this secure linux thing, but to go around saying it will be cheaper to replace all of our PLC systems is a bit odd. Perhaps starting from scratch (where it is appropriate) with a new SCADA/HMI type system similar to Michael's MBLogic platform would be good for *new* projects, but we still have existing apps to support.

Plus there are applications where standard linux is not appropriate (RTOS and motion).

CWW said:
> I suspect the cost would not be much more that the cost of
> all the antivirus measures and labor to try to plug the leaky
> boat when offset from savings on the software and elimination
> of the upgrade mill.

A lot of my machine programs take man months to complete/debug due to their complexity and I'm sure I am not alone. It would be someone's full time job to retrofit my machines and it would take years and a lot of down time to accomplish.

Changing to a secure linux out of the box might be a choice for some that have one system doing some simple sequencing and monitoring but what if you have dozens of existing systems across your plant (or customers' plants)? If things really got that bad (and they might) I would ask our IT guy to give me exclusive access to one programming laptop with a dedicated fileserver share. I would then unplug the machines from any Ethernet connections except where needed for programming. This would be a lot less expensive than reprogramming
all of my machines!

I really feel for people having to connect all their machines to windows computers connected to non secure database systems and windows SCADA machines. These might be good candidates for a systematic redesign.

~KEJR
 
C

curt wuollet

It certainly would be cheaper if big automation switched to an automation oriented version of Linux. There would be porting costs, but then _they_ would control the upgrade cycle. Imagine for a moment, what it cost to rewrite for Vista, and it's already on the trash heap. Wouldn't it be cheaper if the current version of your software simply ran on the next version of the OS? If you could plan a life cycle? If they and their customers weren't driven to upgrade every time MS needs a revenue bump? And yes, you would have to support the old apps. You have to support the old apps either way. And it's not like Windows has meant that you could write once and be done.

In the typical lifetime of an automated machine, lets say 15 years, you have had W3.1, NT, W95, WNT4, W98, W2K, WME, WXP, Vista, and W7 and there's probably at least one I forgot. I don't pretend to be expert on how much commonality there is, but that's a _lot_ of churn that could be avoided simply by having an automation oriented OS with a lifetime of at least 7 years. That churn has cost a _lot_ of money, which indeed is the major reason for it. And if you look at how many of those "advances" were a good thing for automation, the cost/benefit looks pretty dismal.

In fact, I'm fairly sure I've programmed the same PLCs in all or most of those, and I haven't noticed things getting much better. I have accumulated a vast number of versions of various automation apps which combined with all the versions of Windows represents a pretty big mess with _high_ attendant costs and very little relevant or necessary "innovation". Cost, large - benefit, very modest at best. That's because it wasn't at all driven by, or even considering the needs of, automation.

Now suppose that span had been spent using an OS managed for the long life cycles of automation, with only those changes needed or at least, desirable for automation. With attention paid to backwards compatibility and the other criteria important to automation and control. I think the cost would have been very much lower. And not just for the vendors, but multiplied by the users. And that's not even counting all the anti malware crap. And just wait until MS goes careening off into Cloud Computing, or the next buzzword after that, and obsoletes whatever you hold dear.

Can you see, that for control people, controlling their environment holds major advantages, and _planning_ change would save big bucks? Getting off the crazy train would make a _lot_ of things better, not the least of which is security. In summary, as we know better than most folks, a process that you can control is far more likely to produce favorable results than a process that is completely beyond your control.

Regards
cww
 
In reply to KirkC: That is an interesting analysis from Symantec (an anti-virus vendor). Some of what they have said however doesn't agree with other analysts, such as whether the most heavily affected country is Iran or India. That may however be do to those vendors having more customers (and so more reporting points) in those countries.

What I found particularly interesting can be summarized as follows:

1) The virus will directly infect Step-7 and WinCC project files. If you open one of these infected files, your computer will become infected with the virus. Apparently the project files are not simply data, but opening of the files can trigger loading of executable code. This is leveraging the design of Step-7 and WinCC project files with a known design flaw in MS Windows (other viruses have also used the same technique in the past).

2) It directly modifies programs in running PLCs. I will come back to this point later.

3) The virus injects itself into the Step-7 programming software and takes over some of its functions. One of the things it does is hide the changes in the PLC programs from you. If you attempt to view a program on line in a PLC to see if it has been affected by the virus, it will strip out the modifications and show you the "cleaned" version. It also intercepts attempts to erase certain blocks to prevent you from removing them. What this means is that if your computer has the virus, you *cannot* tell if your PLCs have been modified by examining the PLC programs.

4) One of the things the modified PLC programs do is to modify Profibus messages "on the fly". It replaces a standard library function block with a modified version, which can alter the Profibus messages and then pass them on to the "real" function block. This is one of the ways in which it can hide what is doing in your program.

5) If you connect the the modified PLC on line, it will temporarily suppress the modified behaviour. That may be intended to try to hide the changes from someone attempting to trouble shoot the machine.

6) The press reports so far have been emphasizing how the effects were very narrowly targeted at a specific configuration. From what I can see in the report, that is based on a misconception they have about PLCs. The "narrow targeting" is simply that the virus is targeted at two specific models of S7 PLC. However, compatibility between different models of PLC is usually limited, so it shouldn't be surprising that the virus was written with specific models in mind. The actual PLCs are the S7-315 and the S7-417, but those are two very popular Siemens PLCs, so the targeting isn't really all *that* narrow!

7) What seems to be impressing the anti-virus vendors and the "security industry" about this virus is that the authors have gone through the effort to combine multiple virus techniques in a single virus. Generally, virus authors just rely on one technique at a time. I read the whole report, and while I'm not an anti virus specialist, I didn't see anything that on it's own was exceptional about this virus (other than the target). Some of the things about it that people had thought were new turned out to in fact have been seen before, but were just never fixed in MS Windows (and several of the known security holes that it uses are still not patched). As I said, what is apparently new is that someone went through the trouble of combining multiple techniques in a single virus.

8) It is apparent from reading the report that the anti-virus industry doesn't understand the industrial market or the conditions under which which people working in it operate. The anti-virus specialists apparently had a great deal of difficulty understanding how the virus operated because they simply didn't know what a PLC was or anything about how they are used. I think they *still* don't grasp all the implications. There are lots of very simple things that a virus could do to a PLC that would be disruptive to an operation but very difficult to trace.


I think what has kept this sort of thing from being more common up to now has been lack of motivation on the part of people who might be able to do it. Now that it has received so much attention people may start to think about ways in which they could benefit if they could temporarily shut down or disrupt things like electric power plants, pipelines, oil terminals, large mines, semi-conductor manufacturing facilities, and other operations.
 
In reply to Ken Emmons Jr: If an existing vendor decided to do a Linux or BSD version of one of their existing products, I imagine they would base the design on their existing MS Windows version. In that case a user should be able to port a machine project over to that platform with minimal (if any) changes.

I'm not going to claim to be an expert on SCADA systems, but I have written a soft logic system so I might have a few ideas about what the issues are. I can say that with a soft logic system that unless you've made some very poor design decisions there really wouldn't be a lot of platform specific features in software of that nature. It's basically just a lot of network I/O and logic processing. With my own program I ship the exact same code for both the Linux and MS Windows packages. People run the Linux version on Apple Macs, and I've never even tested it on that platform (I don't have a Mac). The user programs, configurations, and screens are absolutely identical no matter which platform you run it on.

I won't comment on what tool chain or library problems a SCADA/HMI vendor might have porting their software over, since that isn't visible to the end users. What might affect an end user is if the vendor is using third party code for certain features but can't find a cross platform equivalent that is at least 95% compatible. I was going to list some examples of that, but after doing a bit of research I can't actually think if any likely ones that I'm sure of. The user program, graphics, etc. could be completely independent of the underlying OS platform.

In the end, it will all come down to whether vendors think there is really an upgrade market for products that offer better security. After recent events, I wouldn't want to say that there *isn't* a market for it, even if companies with critical operations have to be pushed into it by legislation. Anyone who did get into that market however would probably include software tools to help convert existing applications to their system since customers wouldn't want to re-write everything from scratch. There's nothing unusual about that in the software industry however.

I think that creating a "secure system" involves a lot more than just a port to a different OS (although that might be part of the process). I've hashed over that idea a few times before however, so I won't go over it again in this message.
 
Speaking as a developer of Windows based SCADA/HMI and engineering software (our controllers are running a RTOS, of course), I'm very sick of the constant Windows version churn. Years ago I put together a PanelPC based HMI product based on Embedded NT 4.0 that fits in 20MB of flash and still works perfectly well today--but Microsoft will no longer sell licenses for NT 4.0 embedded, so I was forced to move the whole thing to XP. XP is now obsolete, and we basically have to obsolete the product because porting it again is just too much of a pain.

On the other hand, we chose Windows for our products for good reasons: at the time the project started (about 1996), the linux platform was nowhere near mature enough. Microsoft's development tools are still the best of any platform (IMO, not going to start an argument about that :) ), and in 1996 it wasn't even close. Later, even better tools were available on Windows--the .NET platform is far easier to develop on than C++, lowering development costs and allowing us to have a better product than we could have delivered on linux or Unix with the same development resources.

Now that linux is a more viable option, we have a code base of 5 million lines of Win32 heavy C++ code and C# code--changing platforms isn't going to happen. Plus, too many of our users have had bad experiences with *nix based engineering tools and want no part of it--even if the modern linux world is totally different.

We also get major productivity benefits for being on Windows: easy networking, ability to run our engineering tools on any PC (including a lot of home PCs for our users), ability to integrate tons of 3rd party tools (ie OPC clients and servers, DTMs, etc), and easy integration with enterprise level applications (ie copying to and from Excel, Matlab, etc). This matters a lot to the huge number of users that are not actually running on the ICS, but are developing standard libraries, doing customer FATs, etc.

Certainly we've seen viruses and malware attack customer systems; usually it is a result of a lack of procedures or discipline to follow them on their part. We ship our systems properly configured to restrict access to USB drives, installation of software, etc. When the customer does something bad anyway, we kind of feel like a dentist does when they tell patients to floss. We could enforce the rules by having a closed architecture--it really wouldn't even require linux, just some super glue as Ken E suggested. However, most of our customers have told us they prefer an open system so they can make changes themselves. Though we do still get the occasional demand for Solaris support. :)

Going forward, one way a lot of vendors are dealing with the constant platform churn (including us) is to write lots of HTTP/HTML based tools. Embedding a small HTTP server into the controller allows us to drop a cheap interchangeable web browser in for our UI. It isn't appropriate for our main engineering tools or plant HMI, but works quite well for configuration and automation of small devices.
 
B

burt johnson

just to add: a lot of talk about which os to use windows? linux? old school siemens T2000 dcs runs on a stable platform of unix. makes me happy that we have not upgraded to T3000 on windows os. will be happy to ride out the storm before that move is made!
 
In more news, IDG Computerworld reports: "Dutch multinationals under attack from Stuxnet worm".
http://news.idg.no/cw/art.cfm?id=7948A378-1A64-67EA-E473A18859381224
They state: "A major supplier of industrial sorting systems based in the Netherlands has repelled two attacks by the dangerous Stuxnet worm ...". The problems here were in airport luggage sorting systems.

What is of particular interest is the response (or lack of response) from uses so far. The news report states:

"The commercial sector is mostly still oblivious, however. Communication efforts from Microsoft and Siemens about Stuxnet are missed, ignored or not taken seriously by IT companies and administrators. Companies are either not aware at all, or see no need for updates. Van Asseldonk, of service provider TASK24, is not aware of any company that has implemented the important patch from Siemens."
 
In reply to Demigrog: I think you have a good point about legacy code. A lot of existing automation software originates from the mid 1990s era, when MS Windows NT started to see serious commercial use. A lot of current also started out on MS Windows 95/98, and then jumped from there to MS Windows NT. GUI code is what tends to be the least portable unless you use a cross platform GUI toolkit. While cross platform toolkits are quit common today they weren't common back then.

I want to make a point about the "gluing USB ports" solution that often comes up. That was a trick that came from the IT industry a few years ago, but it's not really that realistic today. It is pretty hard to find new hardware that comes with PS/2 mouse ports, and it won't be long before PS/2 keyboard ports disappear as well. You can't glue all of them shut. People already do things like unplug their mouse so they can plug in a USB stick (I've seen it done!) to copy some files. Putting glue into the USB ports is just giving you a false sense of security while solving nothing. USB ports are essential and here to stay, and quite frankly much less of a risk than the Ethernet ports (and I can't imagine the utility of a SCADA or HMI system that can't communicate with anything else).
 
R

Rahul P Sharma

I agree that people in the industry are still not willing to take this seriously or are lazy to even talk about this virus...... The feeling that 'we are not at risk' is all too pervasive..... I spoke about this virus with a couple of friends in industry and they just couldn't appreciate the potential implications of such a threat..... And what surprised me the most was that our Siemens' person, who routinely comes for installation and commissioning and Maintenance purposes to the Plant was not even aware of this thing.....!!! And he just took this information with a mild sense of surprise.....

I am just wondering if during his next visit, should we even allow him to connect his Field PG (A normal Laptop used to communicate with Siemens' PLCs) to our Step 7 PLCs....!!! If he doesnt even know that such a threat exists and India is being reported in news as one of the country with highest number of Stuxnet Infections, then it is impossible to expect them to have taken any precautionary measures, like disinfecting their own Field PGs which they often use at various sites for PLC Maintenance..... I guess, this lack of awareness amongst those responsible is a bigger threat than the virus itself...... These guys will go on using the same Field PGs at all the sites oblivious of the threat of virus lurking in their own backyard.....!!

au revoir
Rahul
 
Top