By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Application servers house a wealth of valuable data. They store your organization's Web pages, serve as the gateway to critical data and process sensitive information on a daily basis. They're also one of the greatest sources of risk to your organization's information security. 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.
Application logging strategies
Over the past several years, regulatory compliance issues forced many information security pros to focus their efforts on logging and retention of security data. Many enterprises implemented centralized logging servers based upon industry standards, such as the Unix syslog format, and built monitoring and alerting apparatuses around those servers. Now that most organizations have a basic logging infrastructure in place, it's time to consider enhancing that infrastructure to meet both business and security requirements. Let's look at some of the enhancements you can make to improve application logging in your organization.
Many application servers have the ability to capture and log copious amounts of security-related information. It's our job to configure them properly and determine what data to retain and what can be safely discarded.
The key to application logging is to base your efforts on standards. This is true on two different levels:
First, use industry standard protocols and formats to ensure consistency in logging across applications, platforms and devices. This makes the job of both automated and manual analysis simpler by a factor of a hundredfold. Using standard formats like W3C logging for Web servers and netflow for network traffic helps correlate alerts generated by different systems. Logging via standard protocols like syslog and SNMP helps consolidate our efforts into a single, centralized platform.
Second, implement standards in the actual data that you log. Many organizations simply make a log server available to system administrators and consider their work complete. It's critical to go the extra mile and provide administrators with standards to follow when configuring logging on various systems. The key questions are, "What data should we log?" and "How long should we retain it for?" The answers will vary from organization to organization depending upon business, technical and regulatory needs. No matter what your requirement, however, it's essential that you define it precisely and communicate it clearly. Consider the types of events you might log relative to the threats you're facing. Authentication successes and failures may provide valuable insight into a password guessing attack against an application. Logging HTTP requests may expose attempts (successful or unsuccessful) to exploit a buffer overflow or SQL injection vulnerability. Failure to standardize will result in administrators interpreting the standard differently and will dramatically reduce the value of your centralized logging infrastructure.
Configuring application severs and logging infrastructure to support detailed logging of application layer events can provide you with critical information in the event of a security incident. Proactive monitoring will provide you with the ability to detect events in near real-time, while reactive monitoring will offer invaluable assistance to forensic investigators. It's not difficult to get started – as we discussed, you probably already have the basic infrastructure in place.
About the author
Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles including the CISSP Prep Guide and Information Security Illuminated.