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!
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
13 Comments
Anton,
The name “web application firewall” is very indicative of the prevailing line of thought in application security defense today. Most people are interested in quick fixes and that’s where the word “firewall” comes from. It is, of course, unreasonable to expect that a WAF will be successful in “firewalling” against complex attacks (where even traditional firewalls — dealing with much simpler attack scenarios — often fail). In the hands of a skilled operator a WAF can be used for foolproof protection via virtual patching, but outside that, WAFs’ main purpose is to increase the cost of an attack. In the meantime, most people are missing out on the benefits of application-layer situational awareness. It took years for NSM to gain popularity, and it will take many more years for ASM to come anywhere near. There is sadly still very little interest in application-layer defense.
I would guess that most WAFs today are indeed are designed as application-layer IPS products, but it does not have to be that way. To me, monitoring of application-level traffic was always the most important characteristic of a WAF.
Ivan, thanks for the comments. Am I correct that “W” in WAF stands for “web”? 🙂 This was essentially my point: even if WAFs do 10x better than they currently do, only web apps get the protection.
And, how often are WAFs deployed internally, NOT at the perimeter?
“There is sadly still very little interest in application-layer defense.”
Why do you think this is the case?
Hi,
In order to have ‘proper’ application monitoring in place one should really consider building it in. The output should be going to logs which also have some or many of your sources. This sound quite close to ‘telemetry’ idea, and this is how I understand ‘application context’.
The application logs then would show behaviour data from the application users and misusers. The behaviour data is based on application features and typically quite hard to catch by any third party tools.
These sources then would be monitored and analysed by persons or event correlation software and persons.
The coverage of the monitoring and its sources are mandated by the classification of the system i.e. probably only mission critical systems would be having such dedicated application monitoring. Most will do less.
Please note, that vulnerability management is ‘sort of’ part of the application monitoring too. All the components of the software: libraries, frameworks, auxilliary software sources should be monitored for any critical security vulnerabilities, as the normal vulnerability management targets: operating systems, databases, web servers etc.
And when you get paranoid, do you trust your code? Will you do monitoring during the development of the software? The code reviews and other App Sec methods will cover that field.
Thanks for your insightful comment!
> In order to have ‘proper’ application monitoring in place one should really consider building it in.
Good idea indeed! And, yes, I used the word “telemetry” to mean “logs and whatever else needed.”
However, waiting for it to happen would be somewhat counterproductive, right? Yes, 3rd party tools will have trouble, but what choice to organizations have if “built-it-in” isn’t there?
You are right about VM, but I like to remind myself that vuln assessment is ASSESSMENT (and generates useful context data for monitoring) which is different from MONITORING.
Regarding your comment on vulnerability management – I tend to differ the vulnerability assessment – scanning, testing from vulnerability management, which actually does not need any tools, only the information of the software assets. Monitoring in this context would be searching information of the vulnerability sources and your own source code which typically is not followed by any other party. Sorry about vague use of words over here.
Relying on the vulnerability scanning tools such as Nessus would not necessary reveal all the weaknesses of the software as the scan will not penetrate through application logic, would not otherwise be ‘visible’ to the scanner as it may be in the case of software libraries.
oh, yes. VA is different from VM, that is indeed our position. VA is assessment, while VM is a whole surrounding process, as well as technology.
And, of course, VA (traditional network VA) will often not (never?) detect app logic issues
Interesting post. On the web app side, I think we have some pretty good monitoring solutions, but of course there’s a lot of room for growth. App monitoring hasn’t been a big topic, so it’s nice to see it get some attention.
Building the monitoring capability into apps in a great idea, I just can’t say it will ever be practical. It’s hard enough to get developers to write secure code, let alone code that helps monitor application security. The OWASP AppSensor project might help with that, but I think some major frameworks would have to adopt that capability to see widespread usage.
“Building the monitoring capability into apps in a great idea, I just can’t say it will ever be practical. ”
Well …this is klinda painful and I guess I can attack your “ever” (like “would you mind replacing “ever” with “3-5 years?” :-)), but you might be right. Engineering apps for in-app security monitoring is, at best, a long-term project.
However, I feel that given the dearth of other options for app mon in the cloud, this just might happen (unlike the on-prem apps).
Also, Eric, thanks for a pointer to AppSensor – I’ve heard of it before and will now explore it in detail.
NSM has been largely successful in protecting against infrastructure security exposures, for example a server that is not patched or has unnecessary ports open.
The majority of the serious attacks today are at the application layer, and Anton, you rightly point out that product vendors sometimes mis-represent their products such as WAF, DAM etc as application security monitoring tools.
OK, so WAF… if properly configured will enable only valid calls from the Web tier to the Application tier and that does protect against a range of current attacks, but more is required.
In my opinion there are few areas that need to be looked at:
– Secure by Design. Before we start protecting the apps, lets try and build them up in a secure fashion.
– User activity trace-ability. Majority of applications use system accounts or service accounts for their calls from the application tier to the database tier. This approach misses valuable information about the attacker’s identity (or makes it very difficult to correlate). Better approach would be for applications to be designed and configured to present the actual user (requester) identity to the database. (same applies between the Web tier and the App tier)
– Application behavioral analysis. Each application has a way of operation (normal behavior). Application behavior model (or DNA as you stipulate) should be developed (possibly during the Secure by Design process) and then monitored. Any time the application displays different behavior is a potential attack.
Today WAF systems can be configured to “learn” the valid flows from the Web to the app tier, and then subsequently based on that knowledge protect and implement WAF rules. The same approach could be used for the remainder of the application tiers.
Velimir, thanks for the comment.
“User activity trace-ability” is definitely one of the key items, as well engineering apps to support such traceability/visibility/auditability.
App behavior (not only web app) is also quite important and, in my view, largely unresolved today
You’re right, ever was a little bit strong. I’ve been in software security for what feels like a really long time and it’s made me a little cynical; especially when we’re talking about developers implementing security features. Unless the frameworks/app servers/whatever does it for them, I think 3-5 years is a stretch. Developers don’t think about security, plain and simple. Maybe 10 years =).
Eric, thanks for the comment. You are correct, hoping that app dev guys will get logging/sec monitoring data right is slim to none.
Libraries or VERY easy guidance is the way to go, but not an easy way.