Comment from Ron Southworth
Time: May 14, 2008, 12:19 pm

Hi Dale this is a great aspect to identify

I would say that this should be part of a logical extention of effective modelling and detection on information flows of our SCADA systems the challange is in how you separate the gold from the dirt!

Comment from Landon Lewis
Time: May 14, 2008, 2:58 pm

An effective method I keep running into which is nearly always for spam/malware are semi-realtime blacklists that are imported into internal DNS and directed to a blackhole honeypot for analysis. A rule has to be placed in the perimeter firewall before your drop rule of course so that the honeypot can receive the traffic.

Comment from Ralph Langner
Time: May 14, 2008, 4:16 pm

“You are blocking unnecessary outbound http, smtp, ftp, … requests.
This is an important point and common assessment finding.”

My experience tells me otherwise. So far, I have never seen a properly configured firewall at the process network perimeter which would limit outbound traffic to what is required and legitimate. Folks just can’t imagine that something bad could originate inside the process network. Usually they conceive all the evil on the outside, which may prove to be well beyond the real threat scenario.

“Many firewalls start with a default ruleset that blocks all traffic from less secure zones to more secure zones, but allow by default all traffic from more secure zones to less secure zones.”

This somewhat seems to contradict the previous statement. Anyway, I think it is worthwhile to contemplate for a minute if the process network always IS the more secure zone by nature. Seems that in many cases it’s not. Most of the time, we see all kinds of unhardened and vulerable systems, plus a bunch of unrestricted remote access points for contractors who are not bound to any form of reasonable security policy. Like it or not, one could argue that for many organizations, compared to office IT, the process network is the less secure zone.

Comment from Dale Peterson
Time: May 14, 2008, 4:20 pm

Ralph - Sorry if the post was unclear. The fact that unnecessary outbound traffic is not blocked is a common assessment finding, which coincides with your experience.

Comment from Dwight
Time: May 15, 2008, 1:35 pm

Dale:

I just arrived back from a security forum and one of the eye-opener discussions was on the vulnerabilities found in Multi Function Devices (MFD) i.e. network copiers and printers. In one example, the customer discovered one of their MFD’s was an active porn server. The customers of the MFD noted that particular unit was always a great deal slower than the other units on the network.

As you point out, extrusion detection and intrusion detection are both important.

Dwight

Comment from Julian Rrushi
Time: May 15, 2008, 8:34 pm

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

Taking into account that the core underlying task of both extrusion detection and intrusion detection is to detect malicious activity, I would think of extrusion detection as being a variant of intrusion detection. Such conceptual variance, in my opinion, in addition to the fact that extrusion detection focuses on outbound network traffic, at least in part is also due to what detection is used for.

Intrusion detection in its traditional definition is used to protect computing resources from being exploited, while its variant, i.e. extrusion detection, is concerned with containing exploited computing resources, and hence preventing them from exploiting other computing resources.

As an aside, blog readers may be interested in reading a research paper on attack containment found at the following link:

http://cairo.cs.uiuc.edu/publications/papers/icccn07.pdf

I’m using the term computing resources to refer to both entire networks and individual computer systems as I want to leverage the granularity of outboundness. In his post Dale covered extrusion detection inspecting outbound network traffic at the network granularity in an industrial context, rationally suggesting perimeter firewalls as possible points where extrusion detection could operate.

I think that Dale’s discussion may be augmented by considering extrusion detection inspecting outbound network traffic at an individual device granularity. We certainly want to prevent a compromised control system from exploiting other control systems within the same network, say a process control LAN. What could be interesting to note is that extrusion detection may be applied to confine compromised devices as well as innately malicious devices.

I’m referring to real-time detection and confinement of control systems running on malicious hardware. While the issue of possible presence of malicious hardware such as ASICs or FPGAs in critical systems has been raised by the military, and in this regard I can mention the DARPA TRUST in Integrated Circuits program, I think this issue affects control systems as well.

After all, haven’t FPGAs been proposed to be used in nuclear power plants ?

http://www.nrc.gov/about-nrc/regulatory/research/digital/res-activities/emerging-tech.html

Moving along this line, I think that it may be interesting to apply extrusion detection for the purpose of monitoring the activities that an edge device performs on a physical system, and hence not only prevent a control system from exploiting other control systems, but also deter a malicious control system from destroying digitally controlled physical systems.

Julian L. Rrushi

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFILNYK3JhHvEZ9fsERApjgAJ9+N6dgESBAoqcuj7FTzKoS4J2jPACfbxtX
NYa6XlmZ0qxlbgBoBrzU/Fk=
=Zm9u
—–END PGP SIGNATURE—–