Gartner Blog Network


Many Faces of Application Security Monitoring

by Anton Chuvakin  |  February 2, 2012  |  20 Comments

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!

Category: application  monitoring  security  

Tags: application-security  security  security-monitoring  

Anton Chuvakin
Research VP and Distinguished Analyst
5+ years with Gartner
17 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio


Thoughts on Many Faces of Application Security Monitoring


  1. Ivan Ristic says:

    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.

  2. 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?

  3. […] the article here: Many Faces of Application Security Monitoring Comments […]

  4. JTH says:

    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.

  5. 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.

  6. […] blogger was Anton Chuvakin, who wrote about the Many Faces of Application Security Monitoring. Chuvakin did a nice job of looking at how IT organizations believe they are monitoring application […]

  7. JTH says:

    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.

  8. 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

  9. Eric says:

    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.

  10. “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).

  11. Also, Eric, thanks for a pointer to AppSensor – I’ve heard of it before and will now explore it in detail.

  12. […] Anton Chuvakin is a research director at Gartner's IT1 Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio Coverage Areas: ← Many Faces of Application Security Monitoring […]

  13. […] Anton Chuvakin is a research director at Gartner's IT1 Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio Coverage Areas: ← Many Faces of Application Security Monitoring […]

  14. […] Anton Chuvakin is a research director at Gartner's IT1 Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio Coverage Areas: ← Many Faces of Application Security Monitoring […]

  15. […] Anton Chuvakin is a research director at Gartner's IT1 Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio Coverage Areas: ← Many Faces of Application Security Monitoring […]

  16. Velimir says:

    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.

  17. 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

  18. Great website…

    […] listed are some links to sites that we link to mainly because we believe they are worth visiting […]…

  19. Eric says:

    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 =).

  20. 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.



Comments are closed

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.