There have been more than a few hysterical articles, also full of hysteria, in the press based on attack information provided by DHS. Wow, a number of large companies have been subject to a spear-phishing attack! ICS specific threat or attack information = 0.
This could be a precursor to a serious attack on pipeline or water ICS, but based on the information DHS has put out it is merely everyday life for a large corporation connected to the Internet with users who email and access web sites. It is odd that DHS plays up these issues and downplays the serious vulnerabilities that continue to go unfixed by vendors and unaddressed by owner/operators in the deployed ICS.
There is also a question as to what is the criteria for a DHS fly away team getting involved in a cyber incident. All it takes is any cyber attack on a company with some link to the critical infrastructure? The question I would have asked at during the ICSJWG case study on the Curran-Gardner water non-incident is “why did DHS get involved in a small outage in a small water utility?”. This is a topic for another article, but it ties together with the CSSP at DHS groping to prove its doing something in this space while still avoiding the contentious issues where their leadership is needed.
So after a bit of DHS bashing, and in the spirit of the DEFCON scale, here is our SCADACON Rating Scale:
SCADACON 5
A critical infrastructure company is receiving a wide variety of almost continuous attacks from the Internet. Attackers are banging against the corporate/Internet firewall. Attackers are sending email with malware attachments and links to compromised websites. SCADACON 5 is every day for any company or individual who connects to the Internet.
SCADACON 4
Your company is receiving some sort of targeted attack. This could be a spear-phishing or some other attack customized with company information to lure your employees into taking an action that will give an attacker a foothold. The attacker could have already succeeded and is enumerating the network or even gathering or corrupting any data besides specific information on the control system.
Most companies are living in SCADACON 4, and it is naive to believe you are not if you are a company of any size — critical infrastructure or not. The information in the dire warnings from DHS to date have been SCADACON 4. This is why they are hysteria from an ICS perspective. Based on the information DHS provided, the fact that they are pipeline or water system related is incidental.
SCADACON 3
Now we have reached an ICS specific attack level.
At SCADACON 3 an attacker from the Internet or partner/customer network is trying to gain access to a system on the corporate network that is allowed to communicate to the ICS, such as a database server, SCADA admin PC, or IT staff system responsible for ICS switches.
A good example would be an email, including a file or a link with an important bulletin on the DCS application in use, purporting to come from a known DCS vendor source and sent to a DCS admin.
SCADACON 3 is very similar to SCADACON 4 except the monitoring has detected that capturing ICS information or attacking the ICS a goal of the attack.
SCADACON 2
An attacker on the corporate network is trying to gather information on the ICS or compromise the ICS.
The attacker has achieved the first, not too difficult, step of gaining a presence on the corporate network. The attacker could be trying to access file servers or databases with configuration files, drawings or other helpful information in crafting an attack. The attacker could be trying to find the corporate/ICS firewall and then find a way through it to a server on the ICS DMZ or actual ICS. ICS protocols may be seen, ICS default credentials, known ICS vulns will be exploited or perhaps web server, database or other 3rd party software on the ICS server or workstation will be compromised.
At SCADACON 2 you should be disconnecting the ICS network from the corporate network. Yes, I said and meant air gap. You should also assume you are about to lose control and view and at least have your emergency response plans ready.
Admittedly, the SCADACON rating could jump directly from SCADACON 4 to 2 if the attacker chose to find the easiest, non ICS-specific way to gain a presence on the corporate network. However if we treat every corporate network attack on a critical infrastructure company as an attack on the critical infrastructure we will waste a lot of energy. It’s better to focus on identifying events that would lead to SCADACON 3 or 2. Monitoring and detection of ICS specific attacks is key, and fortunately it is an area that is getting increasing attention in the ICS security community.
SCADACON 1
The SCADA or DCS system has been compromised and an attacker is implementing a real time or future loss of control or loss of view attack. The owner/operator no longer has reliable control of the process. Safety, economic, environmental and other worst case impacts could be looming
The frightening thing is it is very easy to go from SCADACON 3 to SCADACON 1 given the complete lack of user or data authentication in the most of the devices that control and monitor a system.
I’m not suggesting anyone actually use this SCADACON scale, but hopefully it is useful in understanding what we are looking for in monitoring actual ICS attacks and useful data.
In my view, DHS / ICS-CERT should not even be issuing warnings until SCADACON 3, and if they cannot provide some level of detail about the ICS-specific nature of the attack it is crying wolf. There are legitimate concerns about protecting data and keeping promises to the companies that have shared the information, but even the following generic statements are examples that would not give any owner/operator identifying information away and still be helpful:
- The attacker has targeted computers on the corporate network with access to the ICS network.
- The attacker included control system information relevant to the ICS in the target company as part of a spear-phishing attack.
- The attacker has attempted to gather information about the control system
- The attacker was probing the network for ICS protocol ports
- The attacker was attempting to login with ICS default credentials
- The attacker was trying to find a way through the corporate / ICS firewall
- The attacker had a rogue HMI / EWS attempting to issue commands to ICS devices
- The attacker was using ICS specific Metasploit modules
- The attacker was trying to load rogue ladder logic and firmware on a PLC
Wouldn’t that be useful to know?
Image by Manual Cernuda