Wednesday, 04 November 2015 15:45:00 (UTC/GMT)
I attended to the Swedish industrial cyber security conference
4SICS last month and brought back a bunch of PCAP files.
Not just any PCAP files, but captured network traffic from the ICS lab that was set up in
the Geek Lounge at 4SICS. These PCAP files are now made publicly available
here, because captured network traffic from ICS/SCADA
networks is a really scarce resource.
4SICS is the the leading Industrial Control System (ICS) security conference in Europe,
which brings in speakers and attendees from all around the world.
I tought a one-day class on analyzing network traffic
as part of the pre-conference training at 4SICS.
In this class we analyzed PCAP files containing industrial protocols,
such as Modbus/TCP and IEC-104. Unfortunately there aren't many capture files around that carry these protocols,
so the ICS analysis part in my class wasn't as advanced as I wanted it to be.
I have been aware of this limited access to ICS traffic for some time now,
which is why I decided to work with the 4SICS crew in order to set up a sniffer in the ICS lab at the 4SICS conference.
This lab contained devices such as PLCs, RTUs, servers, industrial network equipment
(switches, firewalls, etc), which were available for hands-on "testing" by 4SICS attendees.
4SICS ICS Lab. Image Credit: 4SICS
The network TAP vendor Garland were Technology Partners at 4SICS, so I didn't even have to bring a network TAP to the lab.
I just connected my sniffer machine and let it record for three days.
Chris Sistrunk also joined the sniffing party later in the conference
by connecting his SEL-3355,
which runs SecurityOnion, to the network TAP.
Image Credit: Patrick Nixdorf
The 350MB of network traffic that was captured during the 4SICS conference is now publicly available here:
Posted by Erik Hjelmvik on Wednesday, 04 November 2015 15:45:00 (UTC/GMT)
Wednesday, 24 August 2011 14:47:00 (UTC/GMT)
The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) issued a
security advisory for Siemens' SIMATIC Step 7 PLCs
a couple of weeks ago.
I've previously recommended asset owners to
monitor the network traffic in their Industrial Control Systems (ICS),
and ICS-CERT have followed my line of thinking by suggesting the following defensive measures:
"Configure an intrusion detection system (IDS) to monitor traffic for unusual or unauthorized activity.
- Monitor traffic on the ISO-TSAP protocol, Port 102/TCP.
- Monitor traffic being unexpectedly sent outside the automation network.
- Monitor traffic between workstations. This traffic may be indicative of attacker pivoting through your network"
The German ICS security cowboy Ralph Langner
has written a somewhat confused blog post
where he is critisizing ICS-CERT's advisory.
In this blog post Langner says the following about ICS-CERT's recommendation to monitor the ISO-TSAP traffic:
"It would be interesting to learn how the authors of the advisory suggest this should actually be done.
We wonder if they have ever peeked into the data traffic of a Siemens PLC’s port 102 in a real installation [...]
In order to make any sense out of TCP port 102 traffic it is required to do deep packet inspection.
Unfortunately, the details of the layer seven protocol that needs to be analyzed, along with certain peculiarities at layer four such as pre-defined binary TSAPs, are not documented by the vendor.
So in essence what ICS-CERT suggests is that asset owners start reverse analyzing the S7 protocol in order to configure their intrusion detection systems, which seems like a far stretch."
So, is Langner saying that the Siemens S7 protocol is too complicated to be reverse engineered?
If encrypted and strongly obfuscated protocols like Skype can be reversed,
then the S7 protocol should be a piece of cake.
I've manually reverse engineered multiple protocols when building protocol parsers for NetworkMiner,
and I can testify that most unencrypted and non-obfuscated protocols can be reversed in just a few hours.
It would therefore be quite simple for IDS vendors to add support for the S7 protocol to their software.
I also believe that even a very rudimentary IDS functionality, which just checks which IP addresses that are communicating over TCP port 102,
would provide value.
Such a simple feature doesn't even require the IDS vendor to implement a parser for the S7 protocol or even the ISO-TSAP protocol.
Ralph also criticizes ICS-CERT's recommendation to "Monitor traffic being unexpectedly sent outside the automation network" by saying:
"While the advice per se might not be completely wrong,
we don’t see any relation to the Beresford vulns which highlight the risk of process manipulation,
not the risk of industrial espionage and exfiltration of trade secrets."
A machine on an ICS network trying to contact an external IP address is typical Indicator of Compromise,
but Langner fails to understand this basic principle of network security monitoring and incident response.
Malware very often use outbound connections to access Command-and-Control servers as well as to download additional software to maintain its foothold on the infected machine.
I'm certain that this is why ICS-CERT recommend asset owners to monitor for outgoing traffic,
especially since ICS systems normally don't communicate with external systems and typically don't host any confidential data or "trade secrets".
A point that ICS-CERT failed to stress, however, is the need for asset owners to also store the full content network traffic
from their network monitoring installations.
This is an absolute necessity when investigating an alert from an IDS in order to better determine if an event is a security incident or just a false positive.
More on capturing network traffic can be read in my blog post
Sniffing Tutorial part 2 - Dumping Network Traffic to Disk.
Posted by Erik Hjelmvik on Wednesday, 24 August 2011 14:47:00 (UTC/GMT)