My temporary job here at Digital Bond is to support Digital Bond’s control system technology lab and specifically the Quickdraw project. That means primarily to identify and generate significant ‘representative’ network traffic, specifically control system traffic that may have security significance. We are using real control system hardware devices to produce the ‘representative’ network traffic. In this blog entry I am going to outline how this work relates to some of the other Digital Bond projects and to describe at a high level what has been done toward identifying control system security significant traffic. But the real reason I am writing this is to solicit feedback about the events we have identified (or missed) so far. I am also going to describe the software tools that I am currently using to stimulate the control system hardware to produce relevant network traffic and to solicit suggestions on other tools or methods that I might be able to employ. I am especially interested in tools that can not only interact with actual control system devices to produce control system traffic; but, can also facilitate the production of control system device security related traffic e.g. authentication, account creation, audit policy logging, etc.
Portaledge – Quickdraw – Quickdraw Security Events
By now most of you have at least heard mention of the Portaledge, Quickdraw and Security Events projects at Digital Bond. These projects have a large degree of synergy although they are not entirely interdependent. At a high level, the aim of Portaledge is to aggregate security events from a variety of data sources. One of those sources might be passive log generation from the Quickdraw project. The Quickdraw project is all about tracking network communication to generate logs for user transactions with “security implications”. The Security Events  part of Quickdraw project aims to recognize control system specific “security events, extract[…] parameters and create the security event, and send[…] the security event to a log server, historian, SEM or other log aggregation server.”
Quickdraw security events.
The benefit of identifying the Quickdraw security events is two fold. On the one hand, Quickdraw provides a mechanism to compensate for the lack of explicitly security related logging support on today’s control system equipment. However, arguably even more important is that by identifying potential security events we are exploring just what kind of process control events might signify or contribute to detection of a security condition and should therefore, in the future, be included in the security audit capabilities of control system devices.
A while back I brainstormed a set of potential security events. Based of feedback from Dale there is a first cut of these events on a Scadapedia page
It turns out that some of these events can be facilitated with the basic network technologies available. I can toggle power on devices, change DHCP mac address entries and such. I can push ladder logic, firmware, etc. But process control traffic and especially security specific process control traffic is a bit more challenging. As I have attempted to generate ‘representative’ network traffic I have become more concerned that I don’t have the tooling to address specifically security related aspects of the protocols e.g. authentication, account creation, audit policy logging, etc. I am also a little concerned about a point raised in a comment to a blog on an unrelated subject by Digital Bond’s Kevin Lackey. That comment, from Ralph Langer stated:
‘The big risk with controllers, however, is process manipulation. This can hardly be done via firmware upload, but it can easily be done by using the controller’s command protocol, be it Modbus, Ethernet/IP or whatever proprietary stuff.”
I am not convinced that the events we’ve come up with so far in any way relate to ‘process manipulation’ as described by Ralph Langer. Maybe by the time the process is being manipulated the game is already over, but I’m definitely interested in other people’s thoughts on the matter.
Another key problem I have encountered is that although Digital Bond has been acquiring several paradigm examples of networked control system components, the Digital Bond lab does not represent an actual industrial process. So you take even a really simple event, like say event #45 Reboot or Restart. Some devices announce themselves when they come online but without any sort of heartbeat or normal traffic in place, a device might conceivably come on and go off-line without so much as a peep.
Now I would like to solve this by essentially building a big old ‘hard’ honeynet architecture, with for example Wonderware being used to monitor the systems and IO simulation pumping normal events into the various controllers, all generating ‘representative’ control system traffic. In this way there would be a background to compare against so if a new device were rebooted/restarted that would be detectable in the traffic not only by the temporary absence of traffic but by failure to connect type events, etc. Note that wouldn’t always be true because some industrial protocols use connection-less UDP based packet broadcasting and multi-casting which means that rebooting a data recipient still may not create an observable. Anyway, a full blown ‘hard’ honeynet architecture isn’t an option right now, so let’s look at the control protocol client software technology I’ve been working with so far.
For the Ethernet/CIP technologies I can work with RSLogix ladder logic upload/download. I can view the status of ControlLogix memory by querying with the Wonderware via the Wonderware Ethernet/IP Data Acquisition Server. That strategy also works for the ModBus traffic too. In addition to Wonderware, a very simple tool I can use to both read data from and write data to a ModBus controller is the Win-Tech ModScan32. The demo only runs for a couple of minutes, but I can use it to demonstrate basic connectivity. I use RSLogix to change MNet1.WriteData on the controller and then the change appears in 40001 holding register. I use ModScan32 to change the 40601 holding register and I can see with RSLogix that the value has changed in MNet1.ReadData.
Unfortunately, Wonderware doesn’t ship a DNP3 Data Acquisition Server. For DNP3 I have found that I can use the Triangle Microworks Communication Test Protocol to verify connectivity with the DNP3 devices. By copying the DNPSNET.Status.Scn_cnt to the DNPSNET.Data.DNP_A1 data address in the Ladder logic, I can then use the Triangle Microworks Communication Protocol Test Harness to read the first analog value, which reflects the ladder logic induced changes to the DNPSNET.Status.Scn_cnt. Another advantage or the Triangle Microworks Communication Protocol Test Harness is that it is the only tool I’ve found so far that I believe is going to help me with the explicitly security related features of DNP3.
It looks like there is quite a bit more I can do with the Triangle Microworks Communication Protocol Test Harness, especial when accessing devices like SEL-351s. I am thinking that the ASE2000 from ASE Systems would also be very helpful.
So my questions to the Digital Bond blog readers are:
1. What do you think of the initial security event list, what is obviously missing, etc.:
2. What do you think of the client tooling approach we are taking? Will these protocol clients be able to generate the requisite security events? Would it make more sense to go with a full package from a single vendor to get features like authentication? Are there available demo applications that would be useful for instrumenting control system traffic?
Advice, criticism, comments etc. welcome!