Six Tips For Application Security Monitoring Success

Many organizations are using advanced log management and security information and event management (SIEM) systems in response to tightening security compliance standards, such as PCI DSS, so now could be the perfect time for forward-thinking businesses to consider pushing monitoring up the stack -- into the application layer. With these SIEM and log management systems in place, organizations now have the ecosystem necessary to process all of the data coming from disparate applications into something meaningful for the security team.

"PCI has driven a good ecosystem in the log management space, so the back-end technology is there," says Gunnar Peterson, contributing analyst for Securosis and managing partner of Arctec Group. "The part that is missing is the front end where the sensors are that actually collect the event in the first place."

The trick is figuring out the right technologies to act as the sensors feeding data into that SIEM system and developing a sound means of implementation.

Peterson says technologies such as Web application firewalls and XML security gateways should play a more prominent role in application-layer activity that has thus far been difficult for many organizations to track. "Those can play a pretty important role because they are outside of the application so the security teams don't have to necessarily get involved with the application build process as much," he says. "But at the same time to support something that's going to be useful you have to be down at the message data level. So you definitely have to get underneath the network space."

As for best practices, Peterson says it varies by industry -- but he has some suggestions for any organization to get started. We've summarized some of his top tips, along with others offered by Steve House, senior director of product marketing at BlueCoat, for those security teams looking to dial in more meaningful application-monitoring practices:

1. Adjust the fire hose.
One of the biggest problems organizations face when monitoring applications is adjusting the stream of data coming from the front end so that it is both useful and manageable, Peterson says.

"From a monitoring standpoint I think they usually either monitor too much or too little," he explains. "It's sort of an art and a judgment call. Everyone is going to make mistakes and will usually fall into the too much or too little camp. The trick is to get that as close to the middle as possible."

2. Don't rely on port numbers.
You can't count on port numbers to identify applications. As House points out, applications such as BitTorrent and Skype hide in HTTP traffic specifically to elude security controls. "A monitoring solution that just classifies traffic on port 80 as HTTP is potentially exposing the organization to infected content online, especially pirated software and media files with embedded malware," he warns.

3. Leverage standards to link the front to the back.
"I think there are tools and technologies on the very front end where you're going to collect the data, and there are tools on the very back end that you can publish the data to," Peterson says, "but one of the hard problems to solve is the in-between."

Peterson says organizations need to leverage standards, such as CEE, which is being pushed by Mitre, or XDAS, which the OpenGroup is supporting, to help the front-end monitoring solutions "talk" with the back-end log management systems and enable you to fine-tune the data that makes it into the hands of the incident response team.

4. Distinguish between content and applications.
Social networking sites have gone a long way toward blurring the lines between content and applications online. Many sites, such as Facebook, host thousands of applications, many of which bring along risks to privacy and data loss, and also open organizations to compliance or legal issues, House says.

"To mitigate this threat, an application monitoring solution needs to be able to identify and control both the content and the applications that are part of social networking sites," he says.

5. Ask the incident response team what they need.
Speaking of the incident response team, if they're largely the ones that will be relying on these systems to do their jobs, wouldn't it make sense to involve them in the deployment of the tools as soon as possible? Too many organizations fail to really ask the incident response handlers about what kind of data they need from these systems in order to pinpoint risks. That needs to change, Peterson says.

"Developers and security architects should spend time with those incident response teams just as if they were your business user -- because, in fact, they are your business user -- and interview them," he says. "They should ask, 'For these types of events, what kind of data would help you work the case?'"

6. Complement application monitoring with real-time Web security.
Web-based malware evolves too quickly for traditional defenses that provide daily or weekly updates. With real-time ratings of new content, including malware, a Web security solution can help provide granular visibility into Web traffic.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.