Bryan Singer and Lily Glick start off the S4 Technical Sessions with a great presentation they named The Pragmatic Pwn of ICS. They focus on the engineering aspects of a cyber attack and the defense of a process using a distillation column (making 80 proof vodka) as an example.
They describe a Process Hazards Analysis (PHA) and introduce the concept of a Cyber Security Process Hazards Analysis (CS-PHA). “A PHA establishes criticality, but likelihood only from entropic failure”. A CS-PHA would include directed threats as well.
Some rarely heard but important points made in this presentation include:
Properly designed systems will have mechanical devices/processes that will prevent certain hazards (explosion in the column due to too much steam), even if a cyber attacker has complete control.
Manual process can be hacked if you know the system well. Trigger alarms that cause the operators or technicians to take the manual action you want taken.
Manual verification of true status before potentially dangerous control actions are taken can be an effective defense.
Operator rounds can be a detection security control.
There are a lot of gems in this session worth watching for those who generally focus on ICS hacking.
Here is my short, 13-minute introduction to S4x15. After going into a brief review of S4x12, x13 and x14, it covers the theme of S4x15 and where ICS security research is heading.
Assume an attacker has gained a presence on the ICS, such as gaining control of a computer or finding a way to connect to the ICS network.
What could and would an attacker do?
What can a defender do?
This moves the discussion from a “hacking” focus to engineering and automation. The “hacking” continues to be the easiest part of an ICS attack. What an adversary does after gaining control of a cyber asset is a much more difficult project than the common “I can take down …” bravado that is often read.
Engineering and automation also offers great opportunities on the defensive side, particularly on reducing the consequences of a cyber attack.
Admittedly this moves the ICSsec research community further out front of the ICS community, and there is a concern that we may be outrunning our supply lines. However, if we keep doing “research” on known and solved issues we will lose the best researchers and not be ready when the ICS community comes to the realization this is a problem that can be and needs to be solved.
One final thought that I’ll write more about later. While the ICS security researchers and thought leaders need to press forward, there is a huge and growing need for the typical ICS security conferences and training programs that the S4 attendee has little interest in. The ICSsec 101 needs to be taught to large numbers of people, and scaling these learning activities up is likely to be a major problem.
Stephen had an article yesterday on the ICS Village / Capture The Flag (CTF) competition at S4x15. We also will be putting up a page with more info on the flags, techniques and pcaps in the next week. In the meantime, check out the interview with the winning team.
The Classic S4 Cocktail Party on Wednesday had an area where you could try piloting a drone. There was a larger drone overhead recording the party on the Kovens deck.
Finally, the SCADA Diva mantle has been passed from S4x14 winner Ronnie Fabela to the new SCADA Diva … Chris Sistrunk. He was awarded the ceremonial pink hard hat and all of the other perks that come with the office. Bonus points are awarded for on-site pictures with the hard hat. Of course based on long standing tradition, Chris will select the next SCADA Diva at S4x16.
This year at S4x15, Digital Bond set out to create an ICS Capture The Flag, or CTF. Flags were created to simulate real world situations that an attacker would encounter if he targeted an ICS. By the end of the CTF, there were over 30 teams playing. Most of the teams consisted of a single player, however the top scoring teams had multiple team members.
An example of an easy (100 point) and more general forensics flag was to identify the potentially infected machine on the Corporate Zone. To do this you needed to visit the GigaView TAP Aggregation Switch that Digital Bond had placed within the ICS Village. (A big thanks to Liam Randall at Critical Stack for providing this for our use in the ICS Village.) Once you collected some traffic, you needed to find a host that was trying to perform a DNS lookup of a known malicious site.
Two more flags were related to this infection inside of the Forensics section of the CTF scoreboard. Below is the traffic you would be looking for and once you found this traffic, the host name was the flag
Another flag that had good feedback from contestants required reading values from a PLC on the network. There were two flags hidden in the Holding Registers of a Modicon PLC. The first one was found in Holding Registers 23 to 33. These values were stored in these registers were decimal representation of ASCII Characters. Depending on the tool you were using this could take some work on converting the numbers found in the registers to ASCII; however, some Modbus Scanners would convert this right out of the box which made it easier for some.
In the same Modicon PLC, there was a flag that consisted of a series of Boolean registers that one needed to convert the binary 1’s and 0’s into ASCII. This flag was rewarded with a higher point value than the other Modbus read flag, as it took more time to concatenate the information back together and convert it to ASCII. Below shows a screenshot of the Holding Registers that were configured with the some of the Boolean values that made up the flag.
A BACnet Flag was hidden inside of an actual BACnet device and could be found on the Internet. There were many different techniques teams used to capture this flag. Some teams downloaded and tried multiple tools, while other teams attempted to modify Digital Bond’s Redpoint script to collect more information to find the Flag. In this case, the Flag was found within the Object Name of an Analog Input inside of the BACnet controller. The Flag is shown below; to find this Flag you would have to read the descriptions of the analog points to know that this Object name was the proper string for the flag.
One Flag (1000 points) proved to be quite difficult, and only one team was able to capture it. This flag was the only 1000 point flag that was found without bending the rules (looking at you team Foobar), and was in the Forensics category. This flag involved using some reverse engineering skills as well as a few hints that were handed out by the judges during the CTF. On the FTP Server in the Corporate zone, there was a Firmware file in a .hex format. In this case, it was a SREC format file. After the team was able to dissemble the file, they were left with assembly code. It was no small task running though the code to find the flag as the flag was hidden inside of an add instruction as shown below. The hex value 0x4841434b then converts to HACK which was the flag.
At the end of the S4x15 CTF, 10 of the 42 Flags were not captured. This is not unusual for a CTF. Out of the remaining flags, some of them were focused around 0-days inside of the ICS based products that were inside of the ICS Village CTF Network. However some of the flags were just overlooked and the judges didn’t give out hints to those flags. Here is the final scoreboard as we shut down the flag submissions:
Over three days the CTF changed leaders a few times with a final result of a team made of Swedes and one Canadian won. Team Foobar won with a final score of 11200 points. The top 10 teams (of which there is single player teams) are as follows:
A big thank you to our sponsors Cisco and mGuard, as well as Checkpoint and Belden for providing hardware for the ICS Village. Without their help, the ICS Village CTF would not have gotten where it did this year. Once again, thanks to all those who played, and we look forward to once again improving the ICS Village next year.
There were 150 people in attendance for this bonus day / early start to the week.
In addition to the OTDay sessions, the ICS Village opened and the Capture The Flag competition began. Sponsors all had tabletop displays lining the bustling main hallway.
The event was capped off with the Welcome Party sponsored by PFP Cybersecurity and Waterfall Security Solutions. It was a Cuban themed party with cigar rollers, mojito’s, Cuban food, domino contests, and absolutely perfect weather this year.
Many of the items below come from experiences with clients, peers and ICS community friends. They are not as visible as most of the pessimistic items, but they are activities going on in real companies making real progress on these issues.
Many large asset owners, those with 10, 50 or 100 ICS spread around the world, are deploying ICS security programs across all sites with required security controls and metrics that management is tracking.
The mainstream press remains hot on ICS security stories.
Multiple high quality ICS security training options are available.
Application whitelisting deployed on ICS computers with and without vendor blessing.
Some universities are now performing true ICS security research.
More ICS vendors are implementing an effective security development lifecycle (SDL).
The NIST Cybersecurity Framework is launching C-level discussions and programs.
Governments around the world are now engaged in this problem. Varying approaches, different results.
Peer pressure … multiple examples in 2014 where ICSsec projects were launched because competitor/peer was doing it.
Virtualization is becoming a mainstream deployment option.
Greater acceptance of the need for an inventory, data flow diagrams and other basic documentation.
Leaders in wide variety of sectors beginning ICS security efforts. It’s not focused on electric, petrochem any more.
Wait … we are still running Windows XP? Management awakening to state of cyber maintenance neglect and finding it unacceptable.
Vendors are, admittedly still slowly, adding security posture acceptance tests to FAT and SAT.
Large consulting practices, i.e. IBM, PWC, …, are creating ICS security teams.
If this is too depressing, wait for Monday’s article 15 Reasons to be Optimistic about ICS Security in 2015.
Almost all ICS protocols are still insecure by design with no end in sight. Access to ICS = Compromise.
Most potentially influential organization, US Department of Homeland Security (DHS), still will not say critical infrastructure ICS need to be upgraded or replaced. Playing small ball with little or no impact.
No legitimate or reasonably honest and objective Automation Press to reach engineers and technicians.
ISASecure stamp is still being put on insecure by design PLC’s and other embedded devices.
Influential ARC Advisory Group saying 20-something controlling the plant from his basement is inevitable and focus on securing it.
SCADA Apologists still dominate the ICS security thought leader / guru / industry and government expert positions.
ICS vendors seeing no negative financial impact to vulns/insecure by design product offerings. They are fearlessly saying our product offers no security.
The Internet of Things is confusing ICS security efforts.
“Nothing will change until something really bad happens” mantra.
Even when an ICS vendor has well documented security controls, the ICS vendor or integrator more often than not installs the ICS in most insecure/easiest to install configuration.
CSET.
Continued fascination and focus on vulnerabilities that matter little to critical infrastructure ICS risk.
Widespread misuse of defense-in-depth principle, just put up more security perimeters, as the solution for ICS security issues.
Get your S4x15 Hotel Reservation at The Surfcomber today or tomorrow. They still have rooms for Tuesday through Friday nights at the $249 conference rate. The non-conference rate is $529.
We are in the fourth and final tier of S4x15 registration. Seats 151-190 and they are going fast. 36 seats left at the time of this writing.
I’ve been heads down writing assessment reports, so haven’t had time to comment on the attack on Sony Pictures. Probably a good thing as I would have just added to much of what has been mostly speculation without facts. The most relevant aspect to ICS to watch is the response. We better understand the expected response to an actual war, in Thomas Rid’s definition. How companies and countries will react to attacks by ICS cyber weapons that cause economic damage, environmental damage and perhaps minimal loss of life is a wild guess at this point. How many people would have predicted capitulation if you ran the Sony Pictures scenario past them before it occurred.
The more relevant attack news this week came from a German BSI report on ICS attacks in Germany and neighboring countries. (Thanks to Stephan Beirer of GAI NetConsult for the tip and translation.) They discuss some incidents related to Havex, but the most interesting is the attack that damaged a steel plant. It was from the easy to accomplish attack vector of spearphishing people who have remote access to the ICS. “The results were massive damage to the system” (translated).
Less attention has been paid to the disturbance in the Austrian power grid covered in Section 3.4.2 of the BSI report. “The failure was probably due to a Control command issued during the commissioning of a gas system in Southern Germany … triggered errors and also reached Austrian power grid. … This caused major disruptions to Instrumentation and control system for network control. … The grid stability could during the incident be ensured only with great effort.” (translated) We are trying to find someone to speak to this report at ICSage and would appreciate any tips or referrals.
Threatpost and a handful of other news outlets are reporting on a worm actively exploiting the Shellshock bug against unpatched NASes. As an aside I find it a bit strange that the attackers are only performing clickjacking attacks — a much more obvious attack would be to use CryptoLocker or other data ransomware, since the current worm is targeting storage devices.
The question becomes, whose job is it to find and patch these kinds of bugs?
I hate to always say ‘the vendors,’ although that is my default response. Vendors however often don’t have the personnel to do reviews on code that they write themselves, let alone to review external code. Third-party components are usually open source and are often volunteer-driven.
I feel that a group of vendors would be well-served to get together and fund code reviews for commonly-used components. Those vendors could then share back those findings with the public, or, at their discretion, keep the findings internal to their group for proper patching. ‘Collaboratition,’ is a phrase often used in national labs for this kind of information-sharing — not ideal financially, but oftentimes it is the right thing to do (or the only way to get it to work).
Lightweight web servers seem like a good candidate for review, since so many embedded systems make use of them. We came up with our list of candidate servers based on devices in our lab, then searched for fingerprintable servers on Shodan to get a feel for their popularity overall. Results are rounded to the nearest 10,000 to help anonymize the actual software that we’re looking at:
Server A: 150,000
Server B: 100,000
Server C: 80,000
Server D: 60,000
Server E: 20,000
We then went ahead and did a cursory code review on every server that we could find code for. This review was just a really basic ‘grep’ analysis, looking for unsafe uses of unsafe C functions: blind strcpy() calls or strncpy() calls that use user-supplied lengths, uses of malloc() that never check for success, calls to sprintf() that never check lengths of input. Our ‘code quality’ analysis is a generalization based on how much of a headache we got looking at the code: the bigger the headache, the more unmaintainable the codebase is and the more it will cost to fix.
The big story of the week was from Bloomberg’s Robertson & Riley: Mysterious ’08 Turkey Pipeline Blast Opened New Cyberwar Era. While the headline isn’t correct, the sourcing is anonymous and some of the technical conclusions are wrong, this is a great example of what cyber weapons may be used for in the future. There may be, and I’d argue will be, many uses of ICS cyber weapons that will not be “war”. I’m looking forward to these discussions at ICSage.
The US House and Senate passed some cybersecurity legislation this week. It will have little impact on critical infrastructure / ICS security, but now the Representatives and Senators can say they did something. It is truly sad if Rep. Meehan is correct in saying, “S. 2519 is the first significant cyber legislation in a decade and among the most important legislation that has been passed this Congress.” You can judge for yourself. Here is the House write-up of the benefits of S.2519 National Cybersecurity Protection Act.
Bedrock Automation has been in semi-stealth mode, if there is such a thing. They have been positioning a “clean sheet of paper” approach to ICS and ICS security. Building a new system from scratch. Details have been and are still very limited, but they released a white paper this week.
Threatpost and a handful of other news outlets are reporting on a worm 
