More Thoughts on Application Whitelisting
Let’s get this out of the way — application whitelisting does not equal perfect security. But neither do any of the other host-based security products that are competing to get on your control system servers and workstations. The bloated AV programs that do signature-based scanning, heuristics, packet filtering, and intrusion prevention can’t even solve all your problems and often create new ones for you. For example, how do I get signature updates into my isolated network and how much time do I have to spend testing updates to make sure they don’t break my control applications? (See Daniel’s post for more AV discussion.)
Host-based security technologies (HIDS, AV, local firewall, etc.) each address specific issues and have their own place but let’s look at this from the perspective of an executive or even a control engineer. They want the biggest security bang for their buck which includes not only hard cost but ongoing maintenance expense. Of course they should consider using the Bandolier security audit files to help harden and audit the application and OS. But assuming that and other policy, network, life-cycle, and perimeter issues are addressed, where do you go from there for host-based security? Specifically — if you had to make a decision about a single host-based, bolt-on security application for your control system servers and workstations, which technology would you add first?
The right answer depends on many factors but I’m convinced that application whitelisting is at least on the list for consideration — something I would not have said six months ago.
Author: Jason Holcomb
Posted: December 2nd, 2008 under Anti-Virus, Security Tools.
Comments: 3
Comments
Pingback from Digital Bond » Finding The Fox In The Hen House - Practical Tips
Time: December 2, 2008, 6:49 pm
[...] question is not even what we do about it, but how do we deal with it in a cost effective manner. In Jason’s previous post he poses part of the the problem referred to as the “Security 3-legged [...]
Comment from Rob Lewis
Time: December 4, 2008, 12:44 am
Jason,
Whitelisting is the way to go, but the app level is not granular enough. We do behavior whitelisting at the kernel level, which includes governance of file access requests, system and network calls. It can appear to be regulating at the app level, but we have a special treatment for special users such as root, such as partial root privileges, or set limits for root user actions, or just plain old privilege escalation prevention. It is not just host security, we monitor applications as required to provide busines rule context for allow/deny decisions.
It is the way to go for control systems because it is pre-determined (deterministic) or proactive rather than reactive, and works against zero day attacks, since unrecognized access attempts (behaviors) fail, or fall off the system as non-events. You now have no need for loading signatures, testing, monitoring for false positives, (because there are none) and your control engineers can do their work.
Keep considering, you are going in the right direction.
Comment from Martin Solum
Time: December 4, 2008, 2:04 pm
Hey Jason, I definitely agree with you that whitelisting, AV, firewalls in general all have to be on the list of defensive technologies to consider because there are situations where each of these defenses can be a reasonable defense or even just the most reasonable defense the asset owner is willing to consider. That being said, I think the important thing is to define where and when these technologies make sense. Also I think it is especially important to consider when these technologies may be fine as a ’second line’ of defense but really a bad idea if deployed as a ‘first line’ of defense. Finally, there are times when they are superfluous or even dangerous because they promote a false or simply less effective defense posture than is practical.
Key factors include the process involved, the ISA/Purdue level of the network being addressed ( i.e. safety & protection, basic control, supervisory control, operations management, enterprise systems) and the cross-site connectivity requirements.
Here are some examples to consider:
If the process is very dangerous and the safety instrumented system is dependent on ethernet capable components, the safety instrumented systems should be air-gapped if at all possible. If the safety instrumented systems are air-gapped, whitelisting is really not necessary. In such a case whitelisting is superflous. If the safety instrumented system is not air-gapped, whitelisting may be creating a false sense of security.
Another time where I think whitelisting suggests “we are secure” when in fact whitelisting is not the best solution is when whitelisting and a firewall are used to separate supervisory control and operations management. This seems to be the typical and generally recommended approach. I am mostly a researcher so my practical experience is limited. But I would look at a data diode solution as a potentially better approach. In fact, any time a firewall is being considered the viability of an air-gap or data diode solution should also be considered. For an example of a data diode technology see: http://www.owlcti.com/.
However, when cross plant internet communications are required at the supervisory control or operations management levels and the process is not particularly dangerous, whitelisting may well be a valuable component of an overall cyber defense plan.
Write a comment