In an earlier twitter discussion on Siemens, Joel advocated the use of NAC as a significant step forward in securing ICS. We have not yet seen NAC in ICS, and NAC has had a rocky road in IT security. So I was curious to get Joel’s view on why and where an owner/operator should consider NAC.

It ends up being a bit of a debate, friendly of course, with the closest thing to an agreement is that NAC may be best applied to a switch in a DMZ. I encouraged Joel to report back when he has some real world case studies of NAC in ICS.

I actually believe we don’t have enough debate or frank discussions in the community. It is refreshing to see Joel take a different tack and defend it. After all, this is the same community that thought technical security controls like anti-virus and firewalls could never work in ICS.

Patrick and the EnergySec crew have been attending a huge number of events lately as part of their outreach effort. Patrick and I talk about the top three items getting attention (I found #3: Detection to be the most interesting), surprises at the events, what vendors are asking for, and the EnergySec annual conference.

My point — we, the SCADA Security community, need to put all our efforts and emphasis in the PLC, RTU, controller space on getting vendors to add basic security features to their models available for sale today. Beginning with authenticating the source and data sent and received from the PLC and continuing with other Security 101 features. We should not say or pretend that any other solution besides this is acceptable. Fix the problem! We have lived with this and PLC vendor inaction far too long, and it is pathetic that there is no serious secure PLC offering.

Last week I had a public back and forth with Joel Langill, @scadahacker, on Twitter. Here is a excerpt from the conversation.

[blackbirdpie id=”78605457375232001″]

[blackbirdpie id=”78607635565383681″]

[blackbirdpie id=”78771316378968064″]

[blackbirdpie id=”78824397917519872″]

[blackbirdpie id=”78771538555449344″]

My main disagreement with Joel is not on the value of NAC. It would not be on the top of my list of new technical controls like white-listing / HIPS, but it is probably worth considering its value as a compensating control. I hope to have Joel on a podcast soon to talk about his advocacy of NAC as an important tool for ICS security.

The problem is we should not be providing any cover or any excuses for PLC/RTU/PAC/Controller vendors to further avoid designing security into their products. This has happened for years with the air gap fantasy and then the firewall “preventing access” to the PLC. PLC’s were not considered vulnerable even though they were vulnerable by design because the attacker shouldn’t be able to reach them. The last thing we need is another silver bullet technology that allows vendors to avoid fixing this gaping ICS security hole.

Let’s take it a step further. In two weeks Joel will be presenting on Stuxnet, other attack vectors and stopping them at the Siemens Automation Summit. Unless Siemens is prepared to announce a new line of PLC’s or major upgrade that will have the Security 101 features, this is a huge mistake. The only message that security professionals should have at that meeting is how wrong it is that the Siemens PLC’s are designed with little or no security; that Siemens response has been late and misleading marketing spin on Stuxnet and now the Beresford vulnerabilities; and that Siemens’ customers should revolt and apply all pressure possible to make the vendor truly address the problem. I make the same plea to John Cusimano of Exida and Eric Byres of Byres Security who will also be there presenting on ways to address Stuxnet and other ICS security issues. Remember this almost one year after Stuxnet and three years after a Siemens requested INL assessment pointed out many of these Vulnerable by Design problems. After all this time there should at least be a detailed announced plan to address it.

The last message that needs to be delivered at a Siemens User Group is that all will be ok because you can deploy NAC technology, set of IDS signatures, or Tofino field firewall and be secure. This is not to knock those or any other compensating controls. These are worthwhile presentations in other venues, but definitely not the message to deliver at any user group meeting where the vendor continues to ignore designing basic security features into even their flagship, new controller product lines.

Dale's Tweets

About Us

Digital Bond was founded in 1998 and performed our first control system security assessment in the year 2000. Over the last sixteen years we have helped many asset owners and vendors improve the security and reliability of their ICS, and our S4 events are an opportunity for technical experts and thought leaders to connect and move the ICS community forward.