I have a problem with field security devices. Well, not really A problem, but multiple problems.
1. Avoiding The Root Cause of Insecurity
There is a tendency in the ICS community, and even among those considered ICS security gurus, to promote building higher walls around insecure by design products and protocols rather than adding even minimal security controls to those ICS products and protocols.
Many loyal blog readers are shouting at their browser — Field Security Devices Are Compensating Controls! True, and they have their place as an interim strategy. However every critical infrastructure owner/operator who is considering buying and deploying field security devices should be simultaneously demanding their vendor provide a plan (features, cost and timetable) to add security to their PLC or RTU. If the vendor says no, go to another vendor until you find one willing to produce and sell a secure PLC.
By the way, this avoiding the root cause of insecurity goes well beyond proponents of field security devices. Take a look at NERC CIP, ISA99, ISASecure certification and other standards and community efforts and you will see the higher wall approach.
2. PLC’s Still Expose Vulnerable Services (by necessity)
In most SCADA and DCS there is still a need to access the PLC in a way that a field security device can not prevent or protect. Write function codes typically must be allowed through. If you want to use the multitude of capabilities in a Modicon Quantum you need to let function code 90 through the field security device. Since these protocols lack even basic authentication, an attacker with a spoofed IP address will be able to attack through the security device.
Similarly, many owner/operators, particularly those with geographically dispersed SCADA systems, have operational requirements for insecure PLC management protocols such as Telnet, FTP and TFTP. The activities that are required for remote management are the activities an attacker would use.
3. Overselling The Benefits
I don’t blame a field security device vendor for promoting their product and every possible benefit, it’s their job, but others should be a bit more skeptical. In a recent blog entry: SCADA Security: Tofino Provides an Alternative to Patching, Eric Byres discusses how security profiles in Tofino can detect and prevent attacks on known vulnerabilities in the PLC it is protecting. For example, it could detect an attempt to login to the FTP with default or hard coded credentials. Or if a known string causes the PLC to crash, it could be blocked.
There is some benefit to this, but if the ICS protocol or other required protocols allow writes, ladder logic changes, firmware updates, etc., how much risk have we actually reduced. In addition, these same restricting feature could be configured in infrastructure routers or switches in a much more efficient manner. Or some of the PLC’s allow you to turn off vulnerable management services such as the http or telnet service.
I guess if you have deployed Tofino’s it is another way to take advantage of a paid for and deployed device, but it hardly would be a reason to recommend a field security device. To be fair to Eric and Tofino, he flat out states it is not a panacea for all PLC security faults.
The Place For Field Security Devices
After that rant, you may think I don’t believe in field security devices. Not true. They have their place including:
- The read only models are useful for segmenting DCS from Safety Systems (SIS). For example, the Tofino Read Only Modbus firewall allows the DCS to pass properly formatted read requests packets to the SIS, but it blocks writes, diagnostics and all other function codes. We have seen a few owner/operators use this with great success.
- In front of fragile PLC’s that crash with malformed or unexpected traffic. An attacker can still compromise the PLC, but the vast majority of PLC failures have been from non-malicious but unexpected traffic hitting the PLC interface. I have wondered if vendors such as Honeywell chose to sell a firewall in front of their controllers rather than fix fragile protocol stacks.
- As more granular ICS protocol support is added, the potential benefits increase. Everyone starts with Modbus TCP because it is such a simple protocol, but you could come up with a set of non-invasive capabilities (an extension of the read only idea)
- Integrated into the Ethernet card of the PLC as one of many embedded security features. This is the future.
Finally another Weissian comment. Reid Wightman is testing a number of field security devices and will present the positive and negative results at S4 2013.
What worries me most is that going into what should be an objective review, there are clearly preconceived notions about these devices! I have and will continue to disagree completely with the authors view of security, and his claim regarding a “root cause for insecurity”.
Risk is the result of three equally important factors: threats, vulnerabilities, and consequences. Risk can be reduced by reducing any or all of these factors. In other words, the author believes that the only way to reduce risk is to eliminate vulnerabilities. My approach focuses on a more comprehensive look at risk, and that sometimes you can obtain more risk reduction through threat and consequence management! I guess this is the value that my functional safety background brings to the world of operational security!
For those that have attended any of my classes or workshops in the past, you know how important these devices are as part of a comprehensive security solution, and are vital in protecting legacy equipment that is faced with numerous vulnerabilities or potential vulnerabilities. When I present this topics and the available products, I walk attendees through a process evaluating each of the various devices against several factors, and show that it is very difficult to try and compare devices against each other, but rather against the risk you are trying to mitigate!
I can only hope that this session at S4 won’t turn into another Project Basecamp where the purpose is not to discredit these invaluable devices, but rather focus more on how these devices are one of the “game changers” for ICS security!
Stay secure …
Joel – I really have no idea what you are talking about.
Any threat model would identify an attacker or process changing the process via write commands, ladder logic updates or other valid PLC commands. If your process requires these function codes or features, and most do because they are the raison d’etre of the control system, a field security device will not address this threat.
The reason the read-only field security device mitigates this threat in the DCS/SIS situation is limited functionality is required so the Tofino or other can block it.
It seems you have fallen in the trap of falling back on buzzwords and the “you just don’t get it because you don’t have decades of operational experience” defense. I almost expected to read proactive holistic security.
Dale Peterson
Digital Bond, Inc.
“As more granular ICS protocol support is added, the potential benefits increase. Everyone starts with Modbus TCP because it is such a simple protocol,..”
I’m still waiting to see how this approach is handling something a bit more complex, e.g. IEC 61850.
To start … it is pretty easy to see that I don’t agree with Dale here … and that is ok! Everyone has an opinion that hopefully is based on information one has collected as a result of field experience.
I can’t accept any of what Dale says above for a few simple reasons. First, “write access” is not the same and “program access” – so why do you continue to use these in the same context? These devices are highly flexible, and is why it is possible to only allow “write” access to specific registers versus a typical packet-filtering device that would allow all function codes through. Furthermore, it is quite simple to block on configuration commands (i.e. “ladder logic updates”, “firmware downloads”) without impact operational data flow. So YES, a field device does address these threats.
I am confused why you continue to refer to these as “read only” … the whole purpose of content inspection is to provide the ability to allow specific function codes through without allowing all of them … and these codes can represent bidirectional read and write operations.
Hopefully, once you finally get your hands on some of these devices will you be able to see how powerful they can be when properly configured. Good luck with your evaluation … I am sure that it will be fair and unbiased from those that have field experience implementing these types of solutions.
To Stephan comment … the vendors are working on additional protocols, and in fact, Modbus is the most often used because it is one of these most vulnerable protocols. Protocols used between devices like Honeywell C300, Emerson DeltaV Controllers, and the like are much newer protocols that include a lot more security preventing unauthorized writes, downloads, etc.
Stay secure …
“To Stephan comment … the vendors are working on additional protocols, and in fact, Modbus is the most often used because it is one of these most vulnerable protocols.”
The protocols we have to deal with over here like IEC 104 or 61850 and numerous vendor-specific I’m not allowed to mention are all equally vulnerable like Modbus. They are just more complex.
regards,s.
Joel – the reason I use Read Only is that Tofino sells that model. It’s pre-configured out of the box and easy to deploy for a DCS/SIS connection. One of the things Tofino focuses on is ease of deployment with the idea that a technician/field engineer can deploy these devices rather than a firewall admin.
Dale
I wanted to get back with Stephan after I did some offline confirmation (since I do not spend a lot of time working with Energy-focused protocols), and am happy to say that at least one of the industrial firewall vendors that offers content or deep-packet inspection via a transparent (aka “bump in the wire”) solution is actually quite far along with their IEC-61850 and GOOSE protocol models, and hopes to have a product out soon!
Like you … I can’t wait to get my equipment upgraded and give this a thorough spin! As more information is available for public release, I will be sure to let you know.
as always … Stay Secure …
I agree with Dale’s comment “that every critical infrastructure owner/operator who is deploying field security devices should be simultaneously demanding their vendor provide a plan to add security to their PLC or RTU”. That is the right way to fix things in the long run.
Unfortunately users have to deal with the real world, a world that has real constrains on available resources. Even if the vendors put 100% of their dev and QA teams on making all their control products secure, it will be several years before these devices shows up on the market. And unfortunately security isn’t the only demand on a vendor’s resources. Customers demand a lot besides security and unless a company wants to lose its customers (and the CEO his job) any successful company needs to balance those demands. Security will be one of many features in next generation controllers, and it will take time.
Then there is the end user. Just because a PLC might only cost $1000 (or even $10,000) doesn’t mean that is cost of replacement. In fact, CPU hardware is typically a small fraction of the cost of a project. Back when I was actively designing control systems, a project using a $10,000 CPU typically involved $100K to $300K of design and commissioning. Replacing a control system could quickly end up in the weeks of down time and many hundreds of thousands of dollars in project costs.
Projects this size don’t get approved overnight – typically it can take years. For something with an RoI as ill defined as security, a project just with security benefits may never get approved. Sad, but true.
So what is the controls engineer supposed to do while he or she waits for the vendor to release the secure RTU, PLC or DCS? And then he/she waits several more years to get project approval?
This is where Field Security Devices come in. They are not intended to be the perfect long term solution. They are a solution that will work today for a few thousand dollars, a price that most engineers can get approved easily. And as far as I am concerned, good security today is better than waiting for perfect security five years from now.