The court battle between Battelle/INL and Corey Thuen at Southfork Security is over. The settlement agreement gives Battelle all rights to Thuen’s Visdom product. While the case hinged on whether Visdom was a copy of Sophia and the Thuen employment agreement, the courts reaction to “you called yourself a hacker so you will break the law argument” and the lame national security impact contention were what made it worth watching. Now clear of entanglements with INL, Theun could start over and build a similar product, but neither Sophia or Visdom were hardly novel or even competitive with more full featured solutions.
Microsoft introduced a new version of their free threat modeling tool. We used their old tool in consulting projects, and look forward to trying out and writing about the new version. One immediate plus is it no longer requires Visio. Microsoft has included a drawing tool in the package.
Bloomberg reported “Electric, natural gas and major water companies and regional distribution systems in Connecticut have been penetrated by hackers and other cyber attackers, but defenses have prevented interruption”. We will be seeing this in slide decks.
WOW! NYISO unveiled their new $38M control center with a 2300 square foot video wall. There are a wide range of opinions on what makes a useful control room, but this one will certainly make an impression on visitors.
And we probably need to put a note in about Heartbleed. There have been a few ICS-CERT advisories on the issue. Asset owners should look at SSL remote access to the ICS and SSL to security perimeter devices for management. Pre-Heartbleed, remote access to ICS should have been physically disconnected except for when emergency support is required.
Digital Bond recently released two Nmap Scripting Engine (NSE) scripts under our Project Redpoint. The second NSE was an attempt to convert S7 enumeration scripts written in Python by SCADA Strange Love into an Nmap NSE. Over the course of development of this script and the BACnet script a lot was learned about development in Lua, especially when it comes working with existing Python code.
Lua is a scripting language that I had not previously developed in, and the only places we knew it of it being widely used, outside of Nmap, was in the gaming industry (e.g. World of Warcraft). Based off some research into Lua and some sample code exercises, we learned that there are many reasons why Nmap had chosen Lua as its scripting language choice. According to the Lua Website, Lua is meant to be fast, portable and light weight. Lua has a great community around it with lots of documentation on how to develop inside the language.
Nmap has also developed its own Lua libraries that is included with the Nmap builds. These libraries help implement a lot of the missing functionality in Lua as compared to other languages such as Python and Ruby. Within the Nmap documentation there is a specific Nmap library that includes how to create sockets and also how to perform error handling within a try/catch for an example.
Nmap has 110 Libraries that were developed to help extend Lua for nmap for basic functions to protocol specific applications. These applications include as an example http, dns, eigrp and snmp. This helps when trying to interface with well known protocols and can make simple queries against the protocol to gather information. Below is an example of both creating a new socket, and using a try/catch to validate that if the socket was created successfully or not.
local result, socket, try, catch
result = “”
socket = nmap.new_socket()
catch = function()
socket:close()
end
try = nmap.new_try(catch)
try(socket:connect(host, port))
result = try(socket:receive_lines(1))
try(socket:send(result))
Lua is a classless language, and it proved to be a challenge when trying to convert existing Python code into Lua. In some cases, classes had been defined and multiple functions were created within each class. One solution to this was to create a function name with the class name inside of it. As an example, for a class named Protocol and a function to parse that specific protocol, you could write a function named Protocol:parse() as a basic way to achieve some basics of classes. More advanced classes that require initialization as well as other actions upon setup can be achieved in more complex ways. We do have some working examples of NSE scripts that utilize multiple mock classes.
Another lesson learned was Lua does not have fully developed methods and functionality. In some cases it was necessary to write a basic function that would be found in most other languages. In the An example in Project Redpoint is a function to determine if a string starts with a specific character.
function string.starts(String,Start)
return string.sub(String,1,string.len(Start))==Start
end
With the S7 Enumeration NSE it proved to be easier to start with a clean slate rather than port the Python script. However the Python script was very helpful in identifying desired output, generating packet captures, and testing to make sure the NSE was working correctly. The clean slate LUA approach also makes it more likely the code will be accepted by the Nmap project for distribution with the other NSE. The Nmap project team has been very helpful in getting the Redpoint NSE scripts ready for submission and has provided great feedback on writing scripts to meet the Nmap NSE code standards.
Full credit for the idea and concept for this script goes to Positive Technologies and SCADA STRANGE LOVE. We ran PLCScan to generate the pcaps, copied what they found useful to enumerate, and used it as QA for our Redpoint script. This script is basically a way to get the PLCScan capabilities in Nmap. Since we use Nmap for enumeration in our assessments and have a number of Redpoint scripts we run in an Nmap category, it was worthwhile for us to port it over. Hopefully the large community that likes Nmap will find it useful.
Let’s go to the screen shots:
We pulled the information from the Module field to identify the model, eg S7 315, S7 317, S7 312. Beyond the value for inventory purposes, it is helpful to identify what are the high powered, most critical PLCs or how large and complex the process you found is.
The System Name and Plant Identification Fields could be very helpful if they were entered by integrator or asset owner. We have scanned devices where the System Name was descriptive and others where it was not changed from the default (and therefore not included in output from the NSE). We have yet to see the Plant Identification Field used, but a large organization with multiple plants may find this helpful, as would the person enumerating the S7 PLCs.
Rotem Bar of Limpox Advanced Solutions closed out S4x14 with a look at how integrators can introduce vulnerabilities into an ICS. This point was actually brought out as well by Sistrunk and Crain with the DNP3 vulns. In that case the TMW master station was not vulnerable to the Project Robus attack methods, but some vendors who had implemented the TMW stack in their master station fell over when fuzzed.
Rotem looks at an example API, from GE Cimplicity, and finds a lack of validation, control and unnecessary features. He then proposes an architecture to resolve many of these issues.
We normally don’t bother commenting on ICS-CERT alerts or advisories, but since we broke that rule already … the latest advisory update on an Allen Bradley denial of service vuln is another reminder that vulns and patching matter little in this insecure by design world. Why worry about a vuln that can cause a denial of service when an adversary can send a legitimate EtherNet/IP Stop CPU command?
Siemens and McAfee announced they “are extending their partnership to enhance the security offerings for industrial customers to protect against rapidly evolving global cyber threats.” Hard to tell if this is marketing fodder or more. The ICS vendors are choosing partners to work with for application white listing, security monitoring and other solutions. Symantec and McAfee being the major players along with the newest Lockheed/Industrial Defender combo.
Innominate’s mGuard was one of the first industrial field firewalls. At Hannover Messe this week they announced support for OPC. The “OPC Inspector masters the complex connection tracking of OPC dialogues across their changing ports and connection directions, thus enabling an effective control and filtering of OPC based on the stateful inspection firewall principle”. They sell a virtual machine software version in addition to the physical, industrial rated module.
Last month I had a conversation with security conscious client who was forced by corporate policy to upgrade their engineering laptops from XP to Windows 7 prior to XP’s end of life. These were the laptops that had the PLC and other programming tools on them to troubleshoot and update logic/programs and other devices at field sites in a SCADA system. They followed the corporate edict and updated the OS. And some of these software tools stopped working.
The story continues, they had to go back to the software tool vendors and upgrade or load a newer version of the application tool that was supported on Windows 7. Now I would like to say the right lesson was learned, but we were not there yet. The wrong lesson the engineers initially took away was it was dangerous to update an OS on ICS workstations and servers, and it should not be done.
However, once we started to have a discussion on how they approached this upgrade and how they approached physical system upgrades at the field site they started to identify and internalize the right lessons. They consider the impact of other engineering changes to the field sites, and perform the appropriate research, testing, outage (if necessary), recovery, etc. In this case they did not check with the tool vendors, who had very clear documentation on their sites on the versions that were compatible with Windows 7. There is nothing ICS unique about verifying application and OS compatibility.
This was one of the many conversations I had with asset owners dealing with the move from XP to Windows 7. There were a number of other lessons learned in processes, vendor selection, budgeting and other areas.
Starting in the 90′s the ICS community bought into the myth that we could have mission critical IT networks that did not require any time or expense to maintain. XP end of life was a great example that asset owners need to plan for periodic upgrades of operating systems and applications.
I think the best treatment of ICS security through basic engineering practices is Ralph Langner’s Robust Control System Networks.
Are Risk Based Approaches Bound to Fail in Securing Critical Infrastructure ICS?
The idea for the topic was a Bound to Fail paper by Ralph Langner and Perry Pederson for the Brookings Institution. We had Jim Gilsinn of Kenexis and Marc Blackmeer of Cisco arguing that risk based approaches are helpful and necessary. Zach Tudor of SRI and Mike Ahmadi of Codenomicon making the case that risk based approaches are bound to fail.
After the four of them argue the issue for 25 minutes it is thrown out to the audience for the remaining 25 minutes. You will see the S4 attendees are not shy about giving their opinion and mixing it up.
This two day course starts with the NERC CIPv5 Foundations course offered by EnergySec, and concludes with a deep dive by yours truly into applying technical NERC CIP and security principles and practices to the generation environment.
Those interested may register on the EnergySec website here. Cost for the paired training is $1,295.00 total, a savings of $100 is recognized when signing up for both courses. Seats are limited to the first 25 participants, and EnergySec partners are offered their customary training discount.
The most frequent question I get from reporters is “why haven’t we seen more security incidents in ICS”? It is now common knowledge that ICS are vulnerable, and eventually we will get the message out that they are, in fact, insecure by design. Why aren’t we seeing parts of the critical infrastructure, factories, building automation systems and more go down?
There are more security incidents than you hear about, accidental, non-directed (such as mass market malware) and directed attacks. The ICS world does not talk publicly about security incidents any more than other sectors.
There are potentially large consequences to taking out critical infrastructure. People could die; major environmental damage; large economic damage; and a big bullseye on whomever is responsible. An attacker will get a lot of attention attacking critical infrastructure even if he does not try to cause an outage or damage. Hunted down, jail, drone strike … and for what gain?
Lack of a profit motive or business model to ICS cyber crime. Security incidents jump in volume when criminals learn how to make money from the incident. Most of the ICS cyber incidents reported by ICS-CERT and others actually are attacks on the corporate network that runs an ICS. Manufacturing recipes, oil exploration data and other business data can be monetized.
The nation states who have exploited their adversaries critical infrastructure ICS have not received the order to attack.
I’ve been thinking about that last bullet for a while now. It lead to the paper Offensive Cyber Weapons, an ICSage session on Preparation and Persistence of ICS Cyber Weapons, and our PLCpwn research project. Every week there are more quotes and information that indicate the US and other nation states are deploying ICS cyber weapons in adversary critical infrastructure to have a capability to use the ICS cyber weapon when requested.
As part of our military thought, we now think of cyber as a domain. Let me define air dominance for you: Air dominance is the ability of the United States to use the air domain at times and places of its own choosing while denying its use to its adversaries at times and places when it is in our legitimate national interest to do so. It’s just a natural thing for him to transfer that to the cyber domain.
If a military wants the capability to use the “cyber domain” to take out part of an adversary’s critical infrastructure “at the time and place of its choosing”, it is necessary to have the ICS exploit in place and the ability to communicate with the exploit. (My Preparation and Persistence items).
The other item comes from the NYT article on the NSA Shotgiant program to compromise Huawei equipment:
N.S.A. analysts made clear that they were looking for more than just “signals intelligence” about the company and its connections to Chinese leaders; they wanted to learn how to pierce its systems so that when adversaries and allies bought Huawei equipment, the United States would be plugged into those networks. (The Times withheld technical details of the operation at the request of the Obama administration, which cited national security concerns.)
Planning and deployment of the exploit is very helpful if a nation state or other organizaton wants a reliable capability to effectively launch a cyber attack. Another pertinent example is NSA’s introduction of vulnerable crypto into RSA. The virtual stack of articles I’m collecting on offensive cyber efforts is large and only the proverbial tip of the iceberg that is visible.
The increasing offensive effort combined with the vulnerable and insecure by design ICS leads to the conclusion that exploits are already deployed on critical infrastructure ICS around the world awaiting an order to attack. Since effective ICS offensive efforts are increasing at a much faster rate than effective ICS defensive efforts the number of critical infrastructure ICS awaiting an order is likely to increase over the next 1 to 3 years. Perhaps there will be some ICS that have deployed exploits from multiple countries awaiting an order.
And don’t assume the weapon does not exist and is not deployed just because you don’t see a critical infrastructure ICS suffer a cyber attack. Most weapons are never used against a potential adversary.
——–
Loyal readers may have noticed that we haven’t written about whether what NSA and other organizations around the world are doing is right or wrong. It is an important discussion, but our focus on this site is security, not ethics. We will increasingly cover what is happening in ICS cyber weapons and how this affects offensive and defensive ICS security programs.
I may be biased as an ex-NSA guy from decades ago, but I think a lot of the anger aimed at NSA is misdirected. An organization like NSA is tasked with missions and given rules, or lines they must not cross, to achieve those missions. There are a lot of talented and dedicated people who believe in the mission at NSA, and they will do whatever they can within the rules to achieve it.
The mission has expanded and the rules have gotten very loose since 9/11 (it’s very different than the 80′s where people would be in jail now). Some of this is necessary because the Internet wasn’t an issue in the 80′s, but what the administration is asking from NSA and what Congress allows NSA to do are perhaps better areas to focus attention on.
Have a great research idea for “Automatic Detection and Patching of Embedded Systems”? Take a look at the DHS pre-solicitation notice announcement for funding under the Small Business Innovation Research (SBIR) program. There is a heavy Internet of Things slant to the item. FYI, this SBIR was what initially funded our SCADA IDS signatures and preprocessors that are now integrated into most commercial IDS.
Critical Intelligence released there annual ICS Security Trends and Analysis Report, for purchase. The analysis of the quality and quantity of the new ICS vulnerabilities is the sizzle, but the most useful information is on new attack and defense techniques, threats and information that will help your detection efforts.
The National Institute of Building Sciences announced two workshops, for a fee. “The Introduction to Cybersecuring Building Control Systems Workshop and theAdvanced Cybersecuring Building Control Systems Workshop are both built around” the new Cybersecurity Framework. BYOBACnet script.
.gif)
The court battle between Battelle/INL and Corey Thuen at Southfork Security is over. The settlement agreement gives Battelle all rights to Thuen’s Visdom product. While the case hinged on whether Visdom was a copy of Sophia and the Thuen employment agreement, the courts reaction to “you called yourself a hacker so you will break the law argument” and the lame national security impact contention were what made it worth watching. Now clear of entanglements with INL, Theun could start over and build a similar product, but neither Sophia or Visdom were hardly novel or even competitive with more full featured solutions.
![1760642062_06f0ba2096_n[1]](http://digibond.wpengine.netdna-cdn.com/wp-content/uploads/2014/04/1760642062_06f0ba2096_n1.jpg)
