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
Security Monitoring and Operations Primer for 2017
Security monitoring and operations excellence is a key component of any effective security program. Gartner's 2017 research will guide...
View Relevant Webinars
Top Take-Aways: 2015-2016 Security and Risk Surveys
Analysis from results of surveys conducted in 2015-2016 for CISOs, security, compliance, risk, business continuity and privacy professionals....
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.