About a year ago I wrote Network Forensics with NetWitness. Today NetWitness is an independent company (again, congratulations) and is launching a new product suite. I was already a fan of their product last year but I will be taking another look at it in the coming weeks. If you want to know why please see last year's post.
I'm writing this post in reaction to
Startup Led by Ex-DHS Cyberchief Rolls Out Forensics Tool. Specifically, I take issue with this excerpt:
[A] security and risk management analyst... says NetWitness's technology is basically immune from anti-forensic tools that attackers increasingly are using to deter investigations of breaches, for instance. "NetWitness allows organizations to investigate user activities at a level that neither attackers nor most users will be able to tamper with."
When I read that comment I immediately remembered The Eavesdropper's Dilemma, first mentioned in Latest Plane Reading from May 2007.
Network forensics can be attacked just like host forensics can be attacked. (If someone can please point me to the original citations for these, I would be grateful. I remember the terms but I can't remember who originally demonstrated the differences.)
- Anti-forensics means attacking the evidence. Encrypting network traffic is a simple network-based anti-forensic technique. All of Matt Blaze's paper describes anti-forensics. Chapter 18 of my first book describes ways to attack NSM as well.
- Counter-forensics means attacking the tools. All of the Wireshark security advisories describing remotely exploitable or denial of service conditions are examples of counter-forensics (e.g., Ethereal 10.x AFP Protocol Dissector Remote Format String Exploit.)
I am sure NetWitness suffers both types of problems just by the nature of its operation, like any other network forensics application.
Perhaps the comment was inspired by thoughts like Hardware-Assisted Virtual Machine Rootkit or TaoSecurity Enterprise Trust Pyramid, where I defend the notion that the network doesn't lie like a compromised host does. However, like I mentioned in Marcus Ranum Highlights from USENIX:
At a certain point the complexity [of the firewall/filter] makes you just as likely to be insecure as the original application.
This is true for protocol-aware analysis tools as well as firewalls/filters.
Update: If you check the Dark Reading article again you'll see the word "resistant" replacing "immune". Please check the comments to see a post by the person who Dark Reading "quoted" to learn what can happen when you speak to reporters!
0 komentar:
Posting Komentar