I'm one of those people who takes extensive notes but rarely goes back and read them. Today was one of those exceptions: I was looking through Evernote for something, and a statement I'd copied some time ago stuck out.

John H. Sawyer, Contributing Writer, Dark Reading

December 14, 2009

3 Min Read

I'm one of those people who takes extensive notes but rarely goes back and read them. Today was one of those exceptions: I was looking through Evernote for something, and a statement I'd copied some time ago stuck out.The average incident response team has absolutely no visibility into Web app attacks.

Unfortunately, Twitter is probably where I found that statement, but I haven't been able to track down the source -- yet. When I first read it, I thought it was wrong. If an IR team has access to the Web server logs via some centralized logging facility, and its intrusion detection system (IDS) is logging attacks, then it has visibility. Right?

Not necessarily. The problem of visibility goes beyond just being able to see an attack took place; it requires an understanding of the target. In the case of Web apps, understanding the Web app includes the underlying server operating system, Web server software, programming language the app is written in, and how the app actually works. A lot of things can make visibility more difficult.

But if you have those things covered, then you have visibility and you're all set. Well ... almost. There's another issue I didn't think of until it bit me last week -- encryption. If the Web applications you're expected to protect start with HTTPS, then things are going to get a little more complicated.

For example, I received a call about a password attack against a client's Web site. They asked what I was seeing in the IDS, and my response of "nothing" was shocking to them until I explained the impact of encryption on an IDS (and pretty much any network sniffing solution like IPS and DLP). The interim solution was to provide me with the server's private key to decrypt the traffic, but it only allowed for manual analysis using the tools at hand.

The Web has transformed so much of our world that the impact to security and things like incident response and intrusion detection are mere afterthoughts for most organizations. Having an SSL load balancer in front of the Web servers and being able to monitor with an IDS after the traffic is decrypted can certainly get you closer to a state of visibility; knowing how the apps work is up to you.

And don't forget to have something in place to monitor those logs because they can also help determine if an attack was successful. Never underestimate the power of logs.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

About the Author(s)

John H. Sawyer

Contributing Writer, Dark Reading

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights