Comment from Ralph Langner
Time: October 24, 2007, 9:16 am

Is this good news or bad news? Hard to tell…

From a technological point of view, it makes sense to incorporate filtering into switches — which is exactly what enterprise networking vendors have done in the last couple of years.

The downside is that this development makes survival and growth for the few security vendors even harder. However these few companies used to be an important force in educating asset owners about security.

Comment from Matthew Franz
Time: October 24, 2007, 9:44 am

Something I’ve been meaning to chime in for a while on the whole field firewall topic — one of the interesting technical limitations of using Linux (Iptables/Netfilter) in the class of firewalls is that there is no support for redundancy/high availability (meaning active/standby that are exchanging state updates) the way that can be achieved on *BSD with PF/Carp/Pfsync…

But I’m guessing these devices are only deployed as single units vs. high availability pairs — as opposed to the way most enteprise grade firewalls…

Comment from Ralph Langner
Time: October 24, 2007, 2:49 pm

Matt, as far as I know, best practice for dealing with a defective field firewall is to send down the maintenance guy and bypass the little, eh, thingy.

Comment from Ron Southworth
Time: October 24, 2007, 4:23 pm

Hi Matt that is a good point!

It also depends on how redundancy is accomplished in the control system.

Many times redundancy in control systems takes the form of separate process plant and equipment & associated control and safety networks so the need for a device to have redundancy, may not be an issue.

In manufacturing and automation process systems is where I have seen the need for devices to have the sort of redundancy you speak of.

Another aspect that sometimes outweighs this as well is the kiss principal. The added complexity and increase of multiple points of failure to the system does not justify the need for components to have redundancy as a feature.

I know that you guys are keen to see these sorts of devices employed at end points but I think that initially the best you can hope for is for this type of device to sit at an entry point to a zone or compartment at least until the devices are proven…

Ralph’s description of the mitigation method for handling failure modes is very accurate.

Comment from Jake Brodsky
Time: October 24, 2007, 6:16 pm

Well, if Hirschmann is going in favor of VxWorks instead of an open OS, then many of the attractive features of the Innominate unit disappear. I like being able to watch developments and vulnerabilities on open source OSs. This way, I know when to expect patches and exactly for what. With a proprietary OS and firewall, I’ll have a harder time.

I like Matt’s suggestions for the *BSD flavor of OS. However, if these devices are used properly, they shouldn’t need to be redundant. I’m of the opinion that redundancy causes as much headache as it solves. I prefer the KISS principle, where someone goes out there and swaps the unit. If this is done right, we shouldn’t need to go out there all that much in the first place.

Comment from Matthew Franz
Time: October 24, 2007, 8:10 pm

Well apart from working properly (nice concept, hehe) redundant pairs of devices can make troubleshooting and hardware/software upgrades much less risky in highly available environments. Even single purpose *NIX boxes that do most of their work at the kernel level (packet filtering) occasionally need to be bounced or otherwise tweaked to be kept in good health.

But keeping configurations (rules, routes, etc.) and system state (clock, etc.) across multiple nodes can be a hassle but I sleep better, sometimes….