Profile Network Activity Comments Articles Blog Bookmarks Contact
 

To Worry or Not to Worry About Icky Worms

By Kathleen Davis
August 5, 2010   |   2 Comments

Do you like this blog post?

Email   Bookmark Bookmark   Print   Share
 
Content Technologies
 

The information and views expressed in this blog post are solely those of the author and not necessarily those of RenewableEnergyWorld.com or the companies that advertise on this Web site and other publications. This blog was posted directly by the author and was not reviewed for accuracy, spelling or grammar.

2 Reader Comments
Comment
1 of 2
August 6, 2010
Marcos Taccolini, the CEO of Tatsoft, sent me a note about the worm today. Here are his comments:

That is a perfect example of the hidden costs and potential problems when you keep installing on mission-critical applications, like scada systems, a piece of software that has an architecture created more than 10 years ago.

What had enabled that VIRUS to be attack those system is that the Siemens system, as well most of the solutions still on the market place, were create on the before the Microsoft.NET Framework era, using technologies like VBA, VBSCRIPT, Active-X and other technologies that are intrinsically "UNSAFE".

I am not criticizing any supplier here, my own previous product created on the later 90' is still using VBSCRIPT and TEXT non-protect files that also very vulnerable for attacks. Only my latest product generation, created from the principals in managed .NET code I was able to prevent completely that kind of vulnerability.

The fact is, whatever the supplier, if the technology is used in the product internal is the same from 10 years, a lot of potential problems can happen. I will list some of those problems, that not only Siemens, but many other still have:

1) Scripting language is VBA or VBSCRIPT, that creates two issues:

1.1- It is interpreted, not compiled, so an external program, like that virus can add malicious code

1.2- Lots of errors are only found on RUNTIME, as on the engineering the error-checking capabilities are very limited.

2) Project is composed by hundreds of files, many of them in pure text files. That create the following problems:

2.1. There is no encryption on the project configuration, allowing both malicious actions and access to the control logic

2.2. It is not hard to a file get mixed with an out-to-date version or when moving, an application can "ADD" by accidentally pieces from other applications.

3) The interface is based on ACTIVE-X and custom TCP/IP protocols on non-standard ports.
Comment
2 of 2
August 6, 2010
Taccolini comments continued:

3) The interface is based on ACTIVE-X and custom TCP/IP protocols on non-standard ports.

That is the I.T. nightmare for security, you cannot really protect from an Active-X components. The non-standards TCP/IP protocols in one side force to disable Firewall ports, on the other side, most of the protocols those SCADAs use to exchange data between their station or their servers and client viewers is a very simples text or value data stream inside the TCP/IP message what makes very easy to network attacks and also to get access unauthorized access to the data.

Those are just some examples, but there are more issues. The good news is that is the company decides to stay updated with the current technology, any of those issues would create a problem in a solution created using the latest technologies. For instance:

On item 1) The new systems can use C# and VB.NET as scripting language that is compiled and embedded inside the application, making impossible the work of that virus and also solves the runtime robustness issues.

On Item 2) The new systems save all the project files in a unified SQL-compatible database with encryption and access protection

On item 3) the new systems use WCF (Windows Communication Foundation) and connection oriented data transfers protected by built-in login validation on the protocol and standard firewall-friendly protocols.

The bottom line is the SCADA is not different from a car, the fact it was working well the past 10 or 15 years is not your security for the next five years, in fact, it exactly the opposite! If is in place the past 10 to 15 years, it means the internal and kernel architecture it is using is from that age, not prepared to our new inter-connected environment and if you want to "drive" safely the next five years you should think about evolve to the generation systems.
Add Your Comment

Registered users, please make sure to Sign-In. We and others want to know your ideas and opinions. If you are not yet Registered -- it's quick and easy. Just click below.
Thanks!

Register Now   Sign-In

Kathleen Davis

View Kathleen Davis's Profile
About: Kathleen Davis is senior editor with POWERGRID International magazine and Electric Light & Power magazine (online at www.power-grid.com). Additionally, she serv... more »

Advertise With Us

Michael Best & Friedrich LLP Sol Systems LLC Solaire Generation EnPower Systems Inc. Intertek Talesun Solar Schneider Electric
World's #1 Renewable Energy Network
PennWell
Renewable Energy World Magazine North America Renewable Energy World Magazine International Renewable Energy World Conference & Expo North America Renewable Energy World Conference & Expo Europe Renewable Energy World Conference & Expo Asia Renewable Energy World Conference & Expo India Renewable Energy World Conference & Expo Africa
RenewableEnergyWorld.com Photovoltaics World Magazine Solar Power Gen Conference & Expo Hydro Review Magazine Hydro Review World Magazine
HydroVision International HydroVision Brazil HydroVision India HydroVision Russia
Twitter Facebook Linked In RSS Feeds e-Newsletters