SCADApedia
AAA  AAA 

IDS v. IPS

An interesting tech segment on Pauldotcom podcast, episode 110 at 21:00. They compare the design and engineering priorities for an inline IPS and IDS.

Inline IPS Priorities

    1. Stability - at all costs stay up and don’t take down the network
    2. Performance - don’t slow down the network traffic
    3. No false positives - don’t block legitimate network traffic
    4. No false negatives - don’t allow any attacks through the IPS

Hmmm . . . sounds a lot like control system priorities. First three priorities say ignore the security ramifications if it is a decision between availability and stopping an attack. The last priority is actually security. Maybe those IT guys are not totally different?

IDS Priorities

    1. Eliminate false negatives - identify all attacks, see more alerts but don’t miss anything
    2. Eliminate false positives - remove the noise so an analyst can focus
    3. Performance - the IDS ability to process all the passively collected traffic
    4. Stability of the IDS platform and application - don’t crash the IDS

Larry and Paul both prefer IDS over if IPS if a choice has to be made.

All control systems are a bit different, but we typically recommend an IDS sensor first on the control system followed by a sensor on the DMZ - - assuming there is also a commitment to monitor these passive devices.

We see inline IPS as more of a rifle shot for specific issues. Let’s say a system on the DMZ can’t be patched and you need to allow traffic on the affected port through the firewall to the DMZ server. Well this is known to be a successful attack, so this IPS signature should be turned on and set to block. Since most modern firewalls have IPS capabilities this really just involves intelligent use of the IPS feature as a compensating control for the unpatched vulnerability.

Author: Dale Peterson
Posted: June 18th, 2008 under IDS / IPS.
Comments: 4

Comments

Comment from Marcin Antkiewicz
Time: June 19, 2008, 12:09 am

> Maybe those IT guys are not totally different?

Sure we are not, it’s just that we are working under different SLAs :-)

Seriously, the IPS list is just a checklist for a mature service offering, just what you, control system folks, are used to.

Seriously, it’s a reasonable requirement for what is essentially an automated, heuristics-based filter for network traffic. It has an awesome potential for creating network instability that will evade normal troubleshooting due to it’s dependence on random bit-pattern “triggers”.

IDS cannot cause sysadmins and analysts to spend countless nights troubleshooting random domain login failures. It can only waste analysts time chasing non-existing events, which can be managed and prioritized…

Comment from amino world
Time: June 19, 2008, 9:49 am

chemITC has recently published a paper on IDS in the control system environment… enjoy!

http://www.americanchemistry.com/s_chemITC/sec.asp?CID=1638&DID=6198

Comment from Landon Lewis
Time: June 19, 2008, 3:32 pm

I’ve noticed lately that a lot of folks aren’t trusting that IPS is working effectively because they are use to receiving excessive IDS alerts (most of which are false positives). This lines up exactly with the priorities mentioned above and needs to be taken into consideration by analysts.

The hard part to determine is which vendor’s sigs/filters are tuned in which direction (over or under firing). I find it most problematic from the vendors who started in IDS and migrated to IPS. Most who have this type of vendor solution look at you like your crazy when you even mention IPS blocking. The solution sadly enough is purchasing a different vendors device or spending a lot of hours tuning your sigs and filters for your particular environment.

Comment from Jake Brodsky
Time: June 20, 2008, 7:48 am

Landon, I want to point out that in a well engineered process control system, traffic flows are extremely regular and well understood. A reasonably well configured IDS shouldn’t give you many false positives.

This is in sharp contrast to most office applications where you really don’t know what normal traffic would look like from one day to the next.

I also get suspicious about an architecture that might fire on legitimate traffic. I’m not willing to dismiss the concept entirely, but it does seem like the application would need to be carefully balanced and tweaked so as to prevent middle of the night failures. Security is good –as long as it doesn’t come at the expense of availability.

Write a comment