The term SCADA (Supervisory Control and Data Acquisition) refers to an industrial control system for a given process, which is usually of a mission critical nature and usually exists in industrial, infrastructure or oil & gas environments.

We have carried out a number of security assessments for such environments and the sections below highlight some of the key BlueScopes related to SCADA Security.

Scope of Work
The first activity is to define the scope of the engagement, which typically consists of the following components:

  • SCADA/EMS application system comprising of typical IT infrastructure, such as Sun Solaris servers, Windows workstations and network components.
  • In the case of the energy sector, additional components related to tariff, billing, and reporting would also be part of the scope
  • The Windows systems connected to the SCADA environment
  • In some cases, it is now a regulatory requirement to publish real-time information from the SCADA system on an Intranet or Internet portal. The systems used for this are also part of the scope.
  • Security risks with the ICCP protocol used for communication
  • RTUs at sampled locations
Typical Security Issues in a SCADA Environment
Due to the traditional mindset that an “air-gap” exists, security was always an afterthought when it comes to Industrial Control Systems. Since this infrastructure runs multi-million dollar operations, any downtime can be disastrous. Therefore, implementing security controls that might impact operations was a risk that system owners were highly wary of taking.

All of this changed with the advent of Stuxnet, Duqu and Shamoon. Suddenly, the “air-gap” fallacy became public, the mask of obscurity was blown away, and these systems stood exposed to even simple security issues. The list below not only represents typical security issues, but also highlights focus areas for critical infrastructure companies to focus on:

Absence of well-defined security controls framework
A lot of these enterprises operate in a poorly defined security controls framework when it comes to ICS. The policies are too generic and more applicable towards the traditional IT infrastructure. The need for tighter access control, multiple layers of network segmentation, and extreme precaution when connecting vendor laptops to the network is not emphasized upon. In some cases, we observe policies are completely bypassed even when it comes to ICS since operations are paramount!

Network Security Vulnerabilities
From poorly configured switching and routing devices to weak access control lists on the firewalls that are supposed to segment the ICS from the rest of the network, network security is usually found wanting. Lack of proper logging and monitoring infrastructure further compounds the problems. In some cases, we have even been able to sniff the ICS Communication Protocol – ICCP using simple ARP-spoofing techniques. The need for a proper Network Access Control (NAC) implementation is most crucial to prevent unauthorized systems from connecting to the network.

Poor Patch Management Practices
Patching involves downtime, and this is a big no-no as stated earlier. In some cases, we have even observed systems with operating system versions and patch levels going back 4-5 years! This situation is made worse by ICS vendors who simply don’t provide support for their systems to work on patched infrastructure. This is why it is not uncommon to hear that running a vulnerability scanner such as Nessus or Qualys brought some components of the infrastructure itself.

Application Security Issues
Many of the applications that run around the ICS – tariff, reporting, management, etc. – are often not very secured. This means that they allow an easy conduit for an attacker to access the ICS. Since these are considered as trusted systems and allowed via the bridging systems to access ICS, they can become the first target of compromise for an attacker.

Susceptibility to Denial of Service Attacks
Controlled simulation of DoS attacks on some of the ICS infrastructure reveals that it would take not more than 10-12 minutes to immobilize some of the most critical components and render much of the system unusable or at the very least inaccessible for critical operations.

Physical security
While physical security for the main production facilities is usually of a very high level, the same may not be true when it comes to Remote Transmission Units. Some of these are located in small towns or villages, and often left unattended. It is potentially a trivial exercise to break open the locks or social-engineer the local team into providing physical access to these components.

Absence of proper hardening
For the reasons stated earlier, a lot of the components in an ICS infrastructure are not hardened as per industry-accepted or enterprise-wide hardening guidelines. We sometimes find highly vulnerable and completely unnecessary services running on these systems, which should have been shut down at the time of installation itself.

Root Cause Problems
Finding such widespread security issues on the SCADA systems, we tried to determine their root causes which have been responsible for them. Here is our summary of observations that we made:
  • SCADA systems are highly expensive and very mission-critical - Therefore, they are generally not tweaked or hardened once they’re up and running
  • SCADA systems are widely considered to be obscure – Since no one knows how they work, no one is going to mess around with them; so why bother securing them?
  • SCADA systems are thought to be isolated – This has been shown to be false multiple times. Many SCADA systems are inter-connected to the corporate TCP/IP network or other TCP/IP networks. This opens them to the same issues faced by public facing systems.
  • SCADA vendors are necessarily very concerned with security aspects - once a multi-million dollar SCADA system is up and running, it is just left as it is. Hence, these systems are highly vulnerable due to vendor apathy.
SCADA systems should be treated as highly vulnerable and can be the target of an attack. Attacks on SCADA systems are very much a reality today. Well known targeted attacks such as Stuxnet, Duqu and Flame are a major wake up call to all those organizations who consider that their SCADA systems cannot come under attack due to isolation from the Internet.

Organizations can no longer afford a lax attitude towards their SCADA systems leaving their SCADA network infrastructure in a default and unpatched state. The necessary step should be to conduct a thorough assessment of these mission-critical systems under safe circumstances with prior management approval.

They should also routinely check if they are compliant against security standards such as ICS-CERT, DoE (Department of Energy), DHS (Department of Homeland Security), NIST SP 800-82 Rev 1, NIST SP 800-53 Rev 4, ISA-62443-2-1, ENISA guidelines for ICS systems and National ICS Security Standard, Qatar etc.

Relevant Articles/Blogs:
  • India’s National Cyber Security Policy – Implications for the Private Sector
  • Advanced Persistent Threats – De-Mystifying The Jargon
  • Indian APT – the Hangover Effect – Full Report
  • Cyber Security In Civil Aviation

Next ShowcaseMobile Security Assessment