By Abishek Chauhan, Teros
The electric energy infrastructure—from power generation sites through the transmission system to distribution points—is currently built (or updated) to include supervisory control and data acquisition (SCADA) systems as a critical component of its basic instrumentation.
Like seemingly ever other technology, these SCADA systems are becoming increasingly connected to the Internet. As an unfortunate result, utility SCADA systems are becoming much more vulnerable to electronic attack—putting utility business interests, power reliability and, ultimately, national security at risk.
Why SCADA Systems are at Risk
Traditionally, SCADA systems were kept separate from the rest of the IT infrastructure and placed on isolated networks with dedicated power supplies, special disaster recovery plans and separate system development protocols. Due to this isolation, security was not a priority for SCADA systems, and they lacked more than minimal access controls. SCADA systems were considered to be on the other side of “the brick wall” that separated process control networks from the company data management network. Fears of accidental intrusion, data mixing and system interface problems kept the brick wall in place for a long time.
However, a number of factors are driving facilities to connect SCADA systems to their corporate networks, intranets, wireless networks and, now, the Internet. One of the newer technologies that is becoming ingrained in process control systems is the web-based interface. As a matter of convenience for system operators (and those responsible for maintenance), the Internet-style of “browsing” a complex computer-controlled system using the ubiquitous PC has gained popularity. Just about everyone has some sort of Internet connection in their office and at home, and is familiar with the daily use of web browsers. The Internet seems to be everywhere so why not use it in place of expensive, dedicated wires? Since it is part of the basic control system, the SCADA system goes right along with it.
Many existing SCADA systems are radio-based, using proven spread-spectrum transmission technology. With the rapid frequency hopping inherent in this type of communications, malicious interference is statistically minimal. However, once the PC-style system on either end is interfaced to an Internet-connected network, the security becomes flawed, and the entire system is vulnerable.
As a result, these developments expose SCADA systems to the same vulnerabilities and threats facing corporate networks and Internet-facing applications. The following factors are increasing the exposure of SCADA systems, indirectly or directly, to the Internet:
Deregulation. The opening of the utilities industry to competition is putting pressure on companies to lower operational and service costs. To reduce operational costs, companies are increasingly leveraging public telecommunications networks, including the Internet, for connecting business applications between distributed facilities and with suppliers and customers. Web applications, while cheaper and easier to deploy than client-server applications, significantly increase security risks and vulnerabilities associated with programming errors.
Consolidation. The continuing trend of mergers and acquisitions is forcing companies to integrate a number of disparate and inherited systems so they can communicate with each other. This has resulted in many companies replacing older control systems infrastructure (distributed control systems, SCADA systems, substation automation, etc.), which were based on proprietary specifications, with standards-based hardware and software, such as Windows, UNIX and third-party applications. In many cases, pure economics has dictated reducing several complex control systems to a lowest common denominator. These developments create varying security levels that open enormous doors for hackers.
SCADA connection to corporate networks. Business units increasingly require real-time data, which has driven companies to integrate SCADA systems with corporate software programs so that business metrics and financial information are available to operations management. However, connecting SCADA systems to corporate IT applications exposes these once-isolated systems to the same internal and external vulnerabilities facing mainstream applications and networks. Since most of today’s business applications use Internet protocols and many companies use standard operating systems such as Windows, Solaris and Linux to run their websites, a malicious user could exploit known vulnerabilities to hack into a web server and then gain access to an unprotected SCADA system within the network.
Outsourcing. Smaller utilities such as municipal utilities and rural cooperatives often cannot afford SCADA systems. As a result, these smaller utilities often have lacked the resources to monitor their substations and other infrastructure on a 24/7 basis. However, the Internet’s ubiquity and low cost have given rise to utility application service providers (ASPs), which provide complex enterprise management services, including e-SCADA functions such as monitoring, analysis and control. These ASPs allow smaller companies to “level the playing field” and access SCADA functionality with just a web browser and a monthly subscription fee. In this scenario, companies will rely on the ASP’s security implementation, which can range from moderate to completely unsecured.
Securing Web Interfaces to SCADA Systems
Protecting web-exposed SCADA systems, whether directly connected to the Internet or linked to an internal corporate network that is connected to the Internet, requires a security infrastructure that blocks break-in attempts at every network level. The maturity of network-level technologies, such as firewalls, has forced hackers to look for other vulnerabilities within Internet-connected networks. As a result, the focus of security threats has shifted to the applications themselves. According to technology research firm Gartner Inc., 80 percent of all hacking incidents last year occurred at the web application level.
With security vulnerabilities doubling every year and easy-to-use hacking tools lowering the skills required to break into web systems, application-level security is required to protect SCADA systems that are directly and indirectly connected to the Internet.
Defining Web Application Protection
As is often the case with new technology, terminology is the first hurdle that must be addressed. Unlike firewalls or intrusion detection systems, the market has not yet settled on a generic term for describing the new web application security solutions. Among analysts and vendors, some of the names currently in use include application protection system (APS), intrusion prevention device, web application firewall and others.
Regardless of what these solutions are called, they all work in basically the same way. Each solution inspects traffic coming in and out of web servers to ensure that users (inside and outside the firewall) are only able to conduct activity within predetermined boundaries, depending on the specific application or site.
Unlike traditional “scan and fix” methods of securing applications, these new solutions provide a comprehensive, proactive, real-time barrier to attacks against websites. They protect against both known and unknown attacks, and, when deployed properly, prevent unauthorized users from compromising a web application, remotely controlling it, or entering a secured corporate network undetected.
Key Considerations for Web Application Protection
The level of security provided by an application protection system depends on how it examines traffic to and from a website. For example, most products only come with a predefined internal rule set, similar to a set of virus definitions within an anti-virus product. These solutions will only be able to protect applications from known vulnerabilities. As an alternative, the most advanced application protection solutions use intelligent, active learning engines which can build new rules on an ongoing basis by monitoring web activity.
Some of the specific threats that should be protected by any web application security solution include:
- cookie tampering
- forceful browsing
- form mismatches
- HTML header tampering
- hidden field manipulation
- buffer overflow attempts
- user session hijacking
While these threats are fairly representative of the broad spectrum of web vulnerabilities, it’s important to note that the non-profit Mitre Corporation (cve.mitre.org/cve/) estimates there are currently more than 2,000 separate verified vulnerabilities today, with another 1,600 being evaluated for classification over the next year. The ability of a web application protection system to stop threats without using patterns, signatures or any knowledge of the attack structure is vital.
In addition to examining incoming requests to a website, an application protection system should examine the website’s responses to determine if the website has been modified by an attacker or malicious code. It should examine the site for specific words or phrases commonly used when defacing a web page, and also for specific words or phrases that should always appear on the web page. For example, if it spots an obscenity, or does not spot your copyright notice, it should block access to the page and notify a system administrator immediately.
Rapid Deployment
Deploying an application protection system can vary significantly based on whether the product is distributed as an appliance or as server-side code. With server-side solutions, each web server will need to have an implementation of the software added to the server, customized and managed. A solution that is distributed as a security appliance should not require much, if any, customization, and should be deployable in a much shorter time frame. In addition, the stronger the learning engine embedded in the solution, the less time it should require to deploy a solution.
A typical deployment or pilot life cycle should begin with the actual hardware or software installation and some minor configuration, all of which should require no more than a few hours. Following that is a two- to three-day learning period during which the product is placed into observation mode and suggests rules based on site activity. An administrator should then spend a few hours evaluating the suggested rules and determine which should be implemented. Following that the solution can be placed into blocking mode, and it should begin blocking unacceptable activity immediately.
A Matter of National Security
Connecting SCADA systems to corporate networks and the Internet, through direct and indirect interfaces, makes them extremely vulnerable to attack from inside and outside the company. With most information security breaches coming through websites and web applications, there is no question that application security must be implemented to ensure the security of web-exposed SCADA systems. Providing application-level security for SCADA systems connected to the Internet is as much a matter of national security as it is a business imperative for any company operating such a system.
Abishek Chauhan is CTO and co-founder of Teros (www.teros.com), a developer of application protection systems.
