Sure. Please send email to eugeneschultz@emagined.com

Best wishes,

–Gene

http://www.naplesgov.com/Home/Privacy.aspx

http://oma.od.nih.gov/ms/privacy/faq.html

http://www.msstate.edu/dept/audit/0119.html

This one is excellent and should set an example. Notice the verbiage about use of cookies
http://www.defenselink.mil/warning/warn-dl.html

While you are connected to any web server the data you send to it is out of your hands, and is subject to storage, review, etc. This is nothing new and if you are reading this, you use a computer and likely submit data to someone’s web server on a daily basis. Second there is no evidence in the form of network traces, weblogs or virus alerts that the government is secretly putting malicious code on your system.
If that is ever the case, you can bet I’ll be among the first to protest. They did do the wiretapping, but pulling off a massive worm / virus attack would be difficult not to mention political suicide. Third, Glenn and his associate mentioned something about cookies spying on you. How ridiculous! Cookies store data about your preferences and specific session data. It is true that some cookies can be poorly written which can leave them around long past the web session they are associated with and sometimes poorly written cookies can store sensitive data like a password. But cookies are not malicious code like a worm or virus.

We do have many problems, but this one was over blown and taking away attention from more important issues (health care, middle east, economy). When a large news agency, such as Fox, makes a mistake and scares people, they should own the mistake and make amends. Hopefully Glenn has done this.

“The new intrusion detection will have functionality that enables it to obtain information from multiple sources and then correlate it to determine that something is wrong and what its exact nature is.”

This is called a SEIM, see splunk, ArcSight, etc. These systems have the ability to correlate firewall, ids, netflow, etc and allow for defining relationships between those events. Usually, only in relation to causal and temporal metrics, IE A B and C happened in X time therefore its Z. The real interesting work here is figuring out how to automatically create those relationships and add extra dimensions and metadata to it so its easier to determine that the event is more important than another event.

“Because of the growing proportion of attacks against applications, Web applications in particular, application firewalls also need to be part of the new intrusion detection”

I’ve never really understood why a sub set of IDS/IPS functionality is another market. WAF’s are little more than specialized IDS/IPS devices that only focus on the HTTP protocol. There is nothing limiting an IDS/IPS from detecting the exact same attacks, and most if not all of them included plenty of functionality in this area. But that is really not here nor there, so sure all “new” IDS/IPS’s should detect web attacks.

I’ve break your flow analysis and data extrusion into two parts.

There are plenty of applications/products Sourcefire’s RNA included that can parse, correlate, and make decisions about network flows and whether or not they are normal/strange/or are leaking data. Additionally not to plug my company too much, as that isn’t the point of my comments, these flows can be tied to intrusion events so that its easy to make casual relationships between these events. Allowing the operator to determine that some hosts are acting strange, and could if an event happened tie that back to attack that changed that hosts behavior.

Before I get into extrusion detection, I think you missed a major feature that any new IDS should have. The ability to classify assets, classify users, and classify the movement of data on the network. If you don’t know what hosts/systems you have on your network, and how important they are to your organization its impossible to determine what if anything will happen if they are compromised. Additionally you don’t know what you should be protecting. Its like wrapping an egg in bulletproof vest and then dropping it off a building. Same goes for users and data, if you don’t know who is on your network, what capabilities they have on the network (admin, normal, contractor), you can’t determine risk of those assets if they are compromised. Data also goes into this category, if you don’t know where your data is or what it is, how can you possibly determine if it was leaked?

Now for data extrusion. If you don’t know were your data is, what it is, and its importance, its relatively difficult to do extrusion detection. I’m sure all the DLP vendors will disagree with my statements as there are tons of companies devoted to scanning network traffic blindly for SSN’s, Credit Cards, and the word “confidential”, but if your just blindly scanning for that content you have no context as to were it “should” be and how it should be used. Is it ok for Bob in accounting to send an XLS sheet of SSN’s to Mary in HR? Is it ok for Bob in sales to look up a customers Credit card? Is it ok for Bob to do that 10 thousands times in a day? (one last plug, Sourcefire, does all the above except data, working on that.)

Finally, when it comes to investigating hosts, its not cost effective. If you know what user was their, what events happened, what data was lost, (because you have all the stuff above I mentioned), then there is no reason to spend any money digging deeper. Just wipe the host.

Deep Packet Inspection these days is considered a layer 7 technology. Depending on how you think of the OSI model DPI could be as simple as normalizing HTTP requests for unicode, or SMTP data/headers for spaces, or as complex as handling DCEPRC fragmentation and SMB transaction state tracking. Snort supports all of that, and much more in its protocol decoders. Allowing it to work with higher level constructs like please find me a DCERPC packet with UUID bind handle of XYZ and OPNUM 4.

Additionally most malware doesn’t open up a secure back channel that is completely encrypted. Most malware communication works over existing non encrypted channels so that is harder to profile. If the entire connection was encrypted finding stuff like this wouldn’t be all that difficult.

So the malware authors go with something like this.

POST /someurl/google.cgi?oid=XYZ HTTP/1.0
Headers:
foo=ipaddres; bar=oid; tracker=uuid; data=encrypted info bad guy wants;
Maybe some other encrypted data here

This allows for plenty of room for matching / parsing / finding bad things like this.

You might also want to investigate the numerous netflow analysis products in the marketplace, as they aren’t simple connection trackers. But more on that in my comments to your second post.

However, you can make the classic argument about not eating your seed corn. There really are attacks against any enterprise that are ongoing NOW, and cutting security defenses against them will raise costs NOW. But can any consultant tell you how much your losses will go up per dollar of security budget reduced? IMHO, any one who claims to be able to do this is living in a dream world of perfect data. Making good decisions based on bad data is why executives are paid the big bucks.

I not amazed this happened at UCB. I am more amazed at how many places that haven’t woken up yet.

Roshid

The main problem was that the packets could not have come from us because they were usually zones behind physical separation or dead space on our network. Our networks had sensors that captured all out-going traffic and we could never correlate the reports with actual traffic. [This was usually replied to that our sensors were of course not as good as theirs since they of course saw the traffic.]

Later we did some followup because our replies were followed up with emails to our ‘masters’ who wanted a full audit to show what was happening. The problems usually turned up with open BGP or other routers that someone took over and advertised for a subset of our space.. and then use for filesharing, UDP-1025 SPAM popups, etc.

Not to say we weren’t without problems.. just not the ones dshield users were finding