2011 September

September 2011

Patching Issues and Outdated Web Browsers Still Plaguing SCADA and Industrial Control Systems

With each assessment that we perform on live operational SCADA systems, we continue to see themes or trends in the security findings. Some of the security issues that always makes the top 10 list are missing patches and hotfixes and outdated web browsers. While most of the SCADA and ICS community are well aware of the patching problems that continue to be an issue in operating and maintaining secure SCADA systems, the outdated web browser issue is often overlooked and misunderstood.

Older legacy SCADA and Process Control Systems used thick client applications installed on servers and workstations that were purpose-built and engineered for the SCADA application suite. As these systems evolve they become more like traditional IT systems. The IT community has long realized the benefits of moving from thick client to thin client architectures, and now most Enterprise IT applciations are browser based. As with most technology evolution in the SCADA market, the adoption of browser-based applications started to become mainstream several years ago.

About ten years ago, many of the SCADA and Control System vendors began to offer browser-based SCADA HMI, alarm, data historization, and data trending applications. They were marketing this capability as a way for Operations to easily access the data and information that they need to make decisions about the operation of their plant, all from the convienience of a simple web browser. The vendors started by implementing web servers in the SCADA servers, database servers, and view nodes. Eventually this adoption of web technology made its way down into the embedded devices, and even as early as 2001 several PLC and RTU vendors were shipping with embedded web servers running in their hardware. They also began using the term “web” in the name of their products, with examples like the “PlantWeb” system from Emerson – just to name one.

Although browser-based computing provide a greater ease of use for operations, this proliferation of web technologies deep in the SCADA environments creates a challenge for security. Many forms of malware and attack exploitation techniques leverage brower weaknesses, so while web-based SCADA systems are attractive to operations, it opens up the system to a much larger range of cyber attacks than when these systems were based on thick client applications.

We often find SCADA view nodes, HMI consoles, and data trending portals running with Internet Explorer 6, and in some cases we have found they have updated to IE 7, but it is extrememly rare to find a fully patched environment with up-to-date browsers. When we bring this issue up in our briefing sessions with our client’s technical teams, the engineering and operations team often downplay the risk and say that they are not using the web browsers to go onto the Internet, so the risk is low. However, they miss the point that even if these older browsers are only used in a closed SCADA-Intranet purpose, just having the older browsers installed on the client and server systems leaves them open to malware and other attacks that can leverage the older browser framework to exploit the host.

I find this a timely issue, and in fact just today Robert Lemos, Contributing Editor from Dark Reading posted an article about how outdated web browsers are still leaving many organizations vulnerable to attack. His article builds on this issue, and you can find it at the following link:


I suggest giving his article a quick read, and while you are reading the article, think about how this relates to SCADA and ICS systems. If you are a systems administrator for a SCADA environment that utilizes browser-based applications, you may want to take a quick inventory of your systems. It would be a great time to clean house, update all of the OS and security patches, and update those old vulnerable browsers.



SCADA Vendors Use Public Routable IP Addresses By Default

Most IT Professionals understand the difference between public routable IP addresses and private IP addresses. Unfortunately, we still find many SCADA and Industrial Control System vendors that ship their product to their clients with public IP addresses as the default build. System Integrators and Control System Engineers may not know the impact of implementing TCP/IP based control systems with public addressable IP ranges, so they accept the default public IP addresses and simply build the system around the core system blocks that were provided to them by the vendor.

Since we run into this situation in almost every field assessment, I thought it was a good time for a quick primer on private IP address ranges and why SCADA and Industrial Control Systems should never be configured with public IP addresses. For many of you, this briefing will be a review of some basics that you already know… for others, this may be helpfiul, so let’s begin…

For internal systems that should never be accessable directly from the Internet, there are only three IP address ranges that are reserved by the RFC 1918 and 4193 as private address spaces. They are classified as private because they are not allocated to any specific organiztion, and IP traffic addressed by these IP address ranges can not be transmitted over the public Internet.

RFC1918 name  IP address
number of addresses        classful description      CIDR block
24-bit block – 16,777,216 Class A
20-bit block – 1,048,576 Class B
16-bit block – 65,536 Class C


The network ranges shown in the above table are reserved for use for internal private networks, and most of us are familiar with the 192.168 range from configuring our home and small business routers. When designing and implementing private networks, these are the only ranges of IP addresses that should be used. Unfortunately, there are several major SCADA and Industrial Control System vendors that do not ship their systems configured to operate in these IP address ranges, and we find SCADA systems that are publically routable over the Internet in almost every one of our field assessments. When we bring this point up, some SCADA and Control Engineers simply reply that it is how their system came from the vendor, or they will justify it and say that the address range does not matter because they are behind a firewall.

Using public routable IP addresses on the inside of sensitive mission-critical SCADA systems is not a good practice, since the firewall(s) protecting these systems are the only line of defense from malicious packets and payloads being routed from anywhere on the Internet into these environments. Configuring firewalls to protect public routable addresses on the inside is also much more complicated because you can not take advantage of built in features for routing classless routes to the outside interface for Internet-bound traffic. Also, if any component of the system is inadvertantly exposed to the Internet, then the system is exposed to attacks that can be routed into the system from anywhere in the world.

Hopefully SCADA and Industrial Control System vendors can start shipping their systems with private IP addresses as the default, and system integrators and asset owners can start implementing these systems with private IP addreses from the start. If the system is up and running in a live state actively controlling production systems, converting from public to private IP addresses is a challenge that may not be possible unless the system is down for maintenance.

More food to chew on while you enjoy the weekend…


Leave a Reply