We are pleased to announce the beta release of some Quickdraw software components today. Quickdraw is a Digital Bond research project funded by the US Department of Homeland Security (DHS). This beta release is the first three SCADA IDS preprocessors that were the crux of the Quickdraw project. They are:

• DNP3
• Ethernet Industrial Protocol (EtherNet/IP and the encapsulated CIP protocol)
• Modbus TCP

We’ll follow up with some more detailed blog posts about functionality in the next few days, but for now here are some of the basics. This package adds three preprocessors to the Snort IDS/IPS application, these do the heavy lifting and parse out the protocol into nice structures for later use. We’ve also included several detection plugins that expand the Snort language to allow matched based on the data that the preprocessors have given us. From there you can send off an alert using the standard Snort mechanisms or the syslog support.

Specifically, the plugins in this release include matching on the Modbus/TCP function code or unit code, the DNP3 checksum and internal indications, EtherNet/IP CIP service and several others. And if your comfortable with the Snort source code you can easily add more of these plugins yourself, but if your not then you’ll have to wait on our next release thats coming soon. We plan on adding many more plugins so writing Snort IDS rules is simple and have many examples of where this would be useful not only for detecting attacks, but also for troubleshooting.

We appreciate any feedback you have and will continue working on this project to make these modules as useful as possible. Look for updates coming regularly, and more specific details on using and extending
Quickdraw here and on the Scadapedia.

Key Links:

• Main SCADApedia documentation page on SCADA IDS Preprocessors
• SCADA IDS Preprocessors download page

Dale’s Note - Like many research projects, we have learned a lot in the program. My guess is that two or three years from now these SCADA preprocessors will be viewed as the major contribution from this research program. Not only are they needed to detect and write security events for legacy field devices – - Quickdraw, but they are also hugely useful in enabling and making more effective many more SCADA IDS/IPS rules, adding deep inspection to field firewalls and probably three or four uses we have not thought about yet. Once you have easy access to the decoded SCADA protocol fields there is a lot that becomes much easier.

Congratulations to Daniel and Victor Julien from the Netherlands for some really great work.

As Daniel said, we will follow up with some very practical posts and examples on how these SCADA IDS Preprocessors can be used.

We have created a SCADApedia entry on Secure DNP3 as a companion to the recent podcast with Grant Gilchrist. We should have a DNP3 entry up in the next day or so for those new to the protocol.

Also don’t forget the DNP3 IDS signatures that have been deployed in many of the commercial IDS and are available to subscribers for the Snort IDS signatures. I found it interesting that most of the function codes that required mandatory protection in Secure DNP3 matched the function codes we focused on in the IDS signatures. Of course the IDS signatures provide attack detection while Secure DNP3 provides protection from attacks.

Our first podcast is now available.

Here is a direct link to the podcast if your reader blocked the embedded reader.

In it I talk with Grant Gilchrist of EnerNex about the Secure DNP3 protocol developed by the DNP User Group. Grant was one of the Secure DNP3 authors and explains the protocol and the reasoning behind some of the decisions made in the protocol design.

Tired of control system protocols where any attacker with network access can poll and control a field device? Check out the podcast, and I think you will start hounding your PLC, RTU, and IED vendors to implement Secure DNP3.

We added two new SCADA IDS signatures for DNP3 to our SCADA IDS release package. Like the recently released Modbus TCP signature update, these two new DNP3 signatures will identify when an attacker is performing a reconnaissance scan of a DNP3 outstation (PLC, RTU, IED, etc.) The first signature will identify someone scanning for all possible points, and the second will identify a function code scan.

These signatures leverage the Internal Indication (IIN) bits and look for a configurable number of errors in a configurable amount of time. The signature has our recommendation for limits, but they are easily modified by anyone with basic Snort knowledge.

Subscribers can download the latest package and view the documentation pages for each signature.

Most protocols (particularly SCADA protocols) and many field devices have a “magic packet” that allows them to say HERE I AM! that are great candidates for discovery algorithms in vulnerability scanners such as Nessus.

I discussed this phenomena in an ISA Talk back in 2003. See the slide on “discovery protocols.” The best way to find these is to capture traffic when you unbox your field device and fire up the (typically) Windows configuration utility, which will probe devices on the broadcast (or even multicast) network for some weird UDP port.

Howver, DNP3 (if unsolicited messages are turned off) tends to follow the “if you don’t have anything nice to say, don’t say anything at all” philosophy. This is much different from the behavior of ICCP/COTP which provide an “address unknown” message if you get the TSAP wrong (some vendors even give some juicy bits like a “(c) vendorname” for good measure, thanks guys!) or send “protocol error” back if you send an invalid message.

The DNP3 REQUEST_LINK_STATUS message (FC 9) is useful for this, if you get the destination address right it sends back an 0×0B as you can see below. Notice how the 5th byte (immediately after the control field, 0xC9) increments, ignoring all the requests to messages except for the valid one (in this case, 4)

mdfranz@franz-d610:~/dev/pydnp$ ./dnptest.py 192.168.169.11 Src: 0 Dst: 0 Sending 056405c900000000364c Closed by 192.168.169.11 Src: 0 Dst: 1 Sending 056405c901000000de8e Closed by 192.168.169.11 Src: 0 Dst: 2 Sending 056405c9020000009f84 Closed by 192.168.169.11 Src: 0 Dst: 3 Sending 056405c9030000007746 Closed by 192.168.169.11 Src: 0 Dst: 4 Sending 056405c9040000001d90 Received:0564050b000004003e6c Src: 0 Dst: 5 Sending 056405c905000000f552 Closed by 192.168.169.11 [(4, 0)] 

Not only can we identify a DNP3 slave based on the 5th frame, but we now know its link address and can start moving up the stack.

1. 192.168.169.61 -> 192.168.169.11 TCP 46364 > 20000 [SYN] Seq=0 Len=0 MSS=1460 TSV=83393561 TSER=0 WS=2
2. 192.168.169.11 -> 192.168.169.61 TCP 20000 > 46364 [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
3. 192.168.169.61 -> 192.168.169.11 TCP 46364 > 20000 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=83393561 TSER=0
4. 192.168.169.61 -> 192.168.169.11 DNP 3.0 len=5, from 0 to 4, Request Link Status
5. 192.168.169.11 -> 192.168.169.61 DNP 3.0 len=5, from 4 to 0, Status of Link
6. 192.168.169.61 -> 192.168.169.11 TCP 46364 > 20000 [ACK] Seq=11 Ack=11 Win=5840 Len=0 TSV=83393571 TSER=1742209
7. 192.168.169.61 -> 192.168.169.11 TCP 46364 > 20000 [FIN, ACK] Seq=11 Ack=11 Win=5840 Len=0 TSV=83393574 TSER=1742209
8. 192.168.169.11 -> 192.168.169.61 TCP 20000 > 46364 [ACK] Seq=11 Ack=12 Win=17510 Len=0 TSV=1742209 TSER=83393574
9. 192.168.169.11 -> 192.168.169.61 TCP 20000 > 46364 [FIN, ACK] Seq=11 Ack=12 Win=17510 Len=0 TSV=1742218 TSER=83393574
10. 192.168.169.61 -> 192.168.169.11 TCP 46364 > 20000 [ACK] Seq=12 Ack=12 Win=5840 Len=0 TSV=83394392 TSER=1742218
11. 192.168.169.61 -> 192.168.169.11 TCP 46365 > 20000 [SYN] Seq=0 Len=0 MSS=1460 TSV=83396574 TSER=0 WS=2
12. 192.168.169.11 -> 192.168.169.61 TCP 20000 > 46365 [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
13. 192.168.169.61 -> 192.168.169.11 TCP 46365 > 20000 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=83396574 TSER=0
14. 192.168.169.61 -> 192.168.169.11 DNP 3.0 len=5, from 0 to 5, Request Link Status
15. 192.168.169.11 -> 192.168.169.61 TCP 20000 > 46365 [ACK] Seq=1 Ack=11 Win=17510 Len=0 TSV=1742241 TSER=83396575
16. 192.168.169.61 -> 192.168.169.11 TCP 46365 > 20000 [FIN, ACK] Seq=11 Ack=1 Win=5840 Len=0 TSV=83397576 TSER=1742241
17. 192.168.169.11 -> 192.168.169.61 TCP 20000 > 46365 [ACK] Seq=1 Ack=12 Win=17510 Len=0 TSV=1742249 TSER=83397576
18. 192.168.169.11 -> 192.168.169.61 TCP 20000 > 46365 [FIN, ACK] Seq=1 Ack=12 Win=17510 Len=0 TSV=1742260 TSER=83397576
19. 192.168.169.61 -> 192.168.169.11 TCP 46365 > 20000 [ACK] Seq=12 Ack=2 Win=5840 Len=0 TSV=83398589 TSER=1742260 

Although this is the output of a simple Python tool (but not as simple as I would have liked since DNP3 goes absolutely crazy with CRC16’s both in the link layer and after every 16 bytes of data in the application layer) these are the sort of checks we are writing for Nessus in NASL3.

I had a chance to talk with Grant Gilchrist of Enernex at Distributech about the efforts to add security to DNP3. This is an effort of the DNP Forum and others through IEC TC57 WG15. The six part draft standard is 62351.

• Part 5 of the standard will provide authentication and integrity at a minimum. This protection is provided at the application layer and therefore will be present for both serial and TCP/IP DNP3. New objects, such as challenge, response, and key change, are being added to existing function codes to support the exchange of the required security information.
• The application layer security involves hashing a message, date/time, challenge, and a key. Actually, I’m a bit unclear whether the request/response message is in the hash. It should be. Since the key is only known to the communicating pair, only that pair can create and verify the hash.
• Certain function codes will be labeled Critical. Critical function codes will be secured with this application layer protection. There also is a performance enhancing aggressive mode where a challenge is reused. This is acceptable if the date/time or some other parameter changes and replay is detected.
• Key management is always THE ISSUE. It is here as well. The plan is to distribute a unique top level key pair to each coummnicating pair. So if N units communicate there (N-1)! key pairs must be created and manually distributed. These top level key pairs can then exchange session keys over the network. This is the old banking ANSI X9.17 approach from the 80’s and early 90’s. It is a nightmare even with sophisticated management systems. It baffles me why the SCADA Security community continues to propose this already failed system. Maybe because it is easy to explain and specify, but the implementation is another matter in all but the smallest networks.
• Part 3 of the standard specifies security at the IP layer. This is basically SSL/TLS. I’ve blogged in the past that I’m not crazy about this, but since there is protection at the application layer it is less of a concern except for the real possibility that we will see the continued increase of web servers in field devices. Part 3 will also apply to securing ICCP.

I would really like to see the option of using public key for the top level key or at least not precluded by the standard. Think of this. If a system/key at the control center needs to be added or changed, the proposed key management will require a manual rekey of all units in the field. In the public key mode it would only require a new certificate in the one unit in the control center. Public key may not be practical for serial systems, but DNP3 over TCP/IP is expanding and probably where security is needed more.

All the same arguments against public key, bandwidth and computing power, were made in the banking world. In the end, what fueled the acceptance was the private key systems were unmanageable, and I say this as someone who worked for two companies that spent man decades developing and selling private key management systems in that market.

All and all there is a lot of positive action here. Security at the application layer, message integrity and identifying critical functions are great. The standard is moving forward and is scheduled to be out in late 2006/early 2007.

I’m teaching the SCADA Security class for Infosec Institute next week in Chicago and in early September in DC. We have been able to add a couple more labs thanks to kind loans by some vendors.

Triangle MicroWorks is allowing us to use their Communication Protocol Test Harness and Plantdata is sending some of their field firewalls, now called patriotSCADA. The test harness will be used to for examples of SCADA protocols and simulated PLC’s in the protocol vulnerability module of the course. The field firewall will be used to highlight field security issues and an as an example in the new solutions module.

The class is not an endorsement of any product, but we will incorporate anything that will help the students learn. Thanks to both vendors.

It is a challenge finding software and hardware that can form an effective lab in a small classroom environment. We are still looking for a SCADA or DCS application vendor to provide a sales / demo version of their administrator GUI. This would be software they run on a sales laptop. In the course we discuss all of the authorization methods that are commonly found in these applications, and we would like to have a hands on lab to replace the current paper lab. Any SCADA / DCS vendor interested?