Everybody knows what “network security monitoring” actually is (even if not everybody is DOING it…). There is a whole book on the subject. In addition, there is a shared understanding in security community about it. Specifically, NSM includes various logs/alerts, packets, flows, session captures, etc.
However, what is “application security monitoring” (ASM)? As I am pursuing my second research project this quarter – one related to SIEM technology futures – I am coming across people attaching the “ASM” label to various technologies and processes. Specifically, these are:
- “We have a web application firewall (WAF) – thus we do ASM” (if “firewall” = “monitoring” and “web applications” = “applications,", then maybe it is indeed ASM)
- “We collect application logs” (which, in reality, means “some application logs” that often nobody understands; also notice the word “collect” contrary to “analyze” here. And what about application context?)
- “We have a tool that analyzes application transactions for fraud” (this sounds like one specific use case of security monitoring inside the application, but what about others?)
- “We decode network traffic up to an application layer” (which likely means that you do NSM right, in contrast to doing application security monitoring)
- “We have a DAM” (which means that requests that the application makes to its database can be looked at; such requests do not constitute the entire pool of security-relevant application activity)
- “We convinced our developers to implement application telemetry useful for security” (this sounds like it will enable application security monitoring; however, what happens with that data after it is generated?)
- “The tool we have can monitor all system calls and API calls made by the running application” (same question: is there any capability, in that tool or another, that helps make sense of the information deluge?)
In your opinion, do any of the above constitute application security monitoring on their own?
Personally, I doubt it. At best, ASM might mean “all of the above” or “many of the above," but I think a few components needed to achieve ongoing visibility of all security-relevant activities inside off-the-shelf and custom applications have not even emerged yet. It may be that security has to outgrow its network roots first and get some application DNA implanted.
The theme that also seems to emerge in my research is that unlike with NSM, answering “what happened?” (example: “error 945842 on application XYZ”) is comparatively less important than answering “what it means?” (example: “security control failed to prevent malicious activity at application XYZ that is important for our business”). Thus, we need to both collect more telemetry AND context, as well as build tools to make sense of that data!
Thus, both enterprises and vendors have work to do in the coming years!
Read Complimentary Relevant Research
Five Golden Rules for Creating Effective Security Policy
Policy writing is a risk communication exercise that is frequently performed by people who lack the skills needed to create good security...
View Relevant Webinars
Office 365 and Google Apps for Work: Security Comparison
Google Apps for Work is increasingly a viable option for many businesses as a replacement for Microsoft Office. As CISOs consider their...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.