“It was the damn network again!” This tired refrain is often the refuge of the application developer. I have built a career on explaining to coders why it isn’t the network or the firewall that is causing an app to break. What has to happen is that application developers have to wake up and take some accountability. That being said, one way to improve matters is to have better application logging. Or better yet, REVIEW the logs that apps generate. Simple root cause analysis seems to be dying a slow, agonizing death replaced by the pointed finger.
Application servers have a lot to tell us when doing analysis and more admins should be checking this information.
Because we’ve built perimeters around our organizations and are pretty good at keeping out traffic that dramatically differs from the accepted profile, we’ve made it too difficult to sneak unwanted protocols through our borders. Therefore, attackers now attempt to tunnel attacks through the protocols that we allow. This has led to the rise of SQL injections, buffer overflows and other application layer attacks, which forces us to revise our logging strategies. While we’ve primarily focused on network-centric attacks in the past, retaining data like firewall alerts and netflow data, we now need to focus on application layer logging.
This will help to give us a better idea of what is going on on our networks. Now that perimeter protection has improved the nefarious element has moved to a different attack vector.
[tags]Application Security, Logging, Log Analysis, Root Cause Analysis, Application Logs[/tags]