More on Application Security Monitoring

As I mentioned in “Many Faces of Application Security Monitoring,” the industry has not yet figured out what application security monitoring (ASM) is yet. For that reason, a lot of the guidance, while useful, stays at high-level and does not dive to details.

This also leads to a weird kind of disconnect in conversations since the parties might have wildly different definitions in mind. I’ve heard a story where an enterprise asked a consulting firm to “get their top 300 critical business application under monitoring” (= logging into a SIEM, in this case) in the next “few weeks.” I’d run out of paper listing all the reasons of why it is impossible, staring from most organizations not even knowing what the most critical applications are and possibly ending with the fact that many of those applications won’t have any useful logs to send into a SIEM.

This visible disconnect around ASM generates even more hilarity when one side of the conversation talks about “cross-site scripting in web applications” while the other talks about “fraud in internal financial applications.” Needless to say, approaches, tools and practices for these problems are very different. Still, these two – web apps and financial fraud – are likely two of the most understood use cases for ASM. WAF logs, web server logs, some middleware logs and some database logs (or a DAP data feed) will give you a decent web application monitoring capability. On the fraud side, there are a lot of dedicated tools (e.g. see “Who’s Who and What’s What in the Enterprise Fraud and Misuse Management Market”) that are often run outside of a security team and thus barely qualify to be call ASM.

What else is common? “Shallow ASM” such as looking at application authentication records (who is logging in? why at 3AM? why from “Country C?”) and very (very, very!) few other application events is somewhat common, but it barely scratches the surface of application behavior and application threats. Monitoring of privileged application users (such as for SoD) is there as well, to some extent.

Another useful way to think about ASM is like “a security brother” of APM. In “Criteria Are Maturing for the Magic Quadrant for Application Performance Monitoring”, Gartner defines APM as “having five dimensions of functionality” including “runtime application architecture discovery, modeling and display” and “component deep-dive monitoring in application context.” What do we have to match that on the security side? Is there demand for broader, more comprehensive application security monitoring? I think there will be, in the near future!

Finally, we all know why monitoring is hard for organizations: it is an open-ended commitment – you have to start monitoring  yesterday (ok, “now” will work as well ) and continue forever. In fact, it is a “non-ending” commitment in that sense since you cannot “buy it” or “do it once.” You have to start the process and keep running  it – and running it well!

Past posts on the topic:

• Many Faces of Application Security Monitoring