RSAC 2010 Guide: Application Security

By Adrian Lane

Continuing our postings from the Securosis Guide to the RSA Conference 2010, we turn our attention to application security.

Application Security

Application Security is a nascent market, but data from several recent data breach reports and OWASP studies have disproven the myth of the “Insider Threat”. The primary cause of breaches is poorly executed applications – specifically web applications that rely on complex multi-layered infrastructure. While there is no agreement on which methods and technologies are ‘best’ for securing applications, application developers show growing interest in learning about the available options.

What We Expect to See

  • A Focus on Web Application Development Security: As a general rule we don’t have very good statistics in security and risk management, but this trend is changing. With better forensic information we are showing that web application breaches are the leading cause of security breaches. While this has not yet translated into a significant change in security spending, expect to see long lines and greater interest in code security products and education. Vendors will be disappointed at dealing with lower level IT and software practitioners who come across as tire-kickers who ask too many questions, but this is tomorrow’s buying center! These are the people who will change their applications and deployments to be more secure, not CIOs.

  • Anti-exploitation: While education in the development community lags regarding what constitutes risky code, tools that identify poor code or provide anti-exploitation will get a lot of attention as they raise the bar without a lot of re-engineering. The tools vary greatly in the depth of their features, how they are deployed, and where in the development cycle they fit. For example, some examine source code, some examine objects while they are compiled or linked, and others offer run-time protection. You will need to ask the vendor what classes of anti-exploitation they provide, and see if their model fits your development framework.

  • Integrated Assessment and Firewall Technologies: Web application development cycles are so short that full regression testing of new functions is generally impossible. More, test systems fail to mimic live production sites, so many vulnerabilities are missed prior to deployment. This has increased demand for application scanning, and changed it into a never-ending task. The window of time between when a vulnerability is introduced and when it is discovered is very small. In most cases exploitation begins before a fix can be identified, implemented, tested, and rolled out to production servers. To fill the gap, vulnerabilities discovered by application scanners are being fed into web application firewall (WAF) platforms in near-real-time to block while the application fix is underway. Since the 2009 RSA show, the number of WAF vendors who offer dynamic blocking has tripled. The quality of the assessment is still key, but investigate what your WAF provider is offering, how quickly new policies can be deployed, and what the performance impact will be. This is an effective security feature but has potential policy management and performance impacts which you need to understand.

For those so inclined (or impatient), you can download the entire guide (PDF). Or check out the first post in the RSAC Guide on Network Security.

No Related Posts

I believe I will be in SF from Wed-Fri, “mostly” for RSA

I think a high level audience needs to know about the things that I mentioned, btw. I also think that “validation” is an optimum, agreed-upon solution between dev/IT/mgmt to “solve” a majority of application security vulnerabilities

By Andre Gironda

Dre - great comments. Appreciate the analysis. Sorry if you were disappointed, but this series is intentionally a high level overview, and dare I say it, you are not the target audience for this post. By the way, are you _going_ to RSA this year?


By Adrian Lane

I expected more out of your analysis (but you would guess that of me—aren’t we all so predictable?).

First of all, anti-exploitation really fits more nicely into 3 categories, 1 of which includes application firewalls.

Check out the AppSecuritySchool Podcast with Cory Scott (of Matasano) and Nicole D’Amour (editor of SearchSecurity) for some of my logic/reasoning here:

Anti-exploitation should really be:
1) Removing (or toning down) public interfaces, functionality, or data interfaces that are exploitable. This would be something that an automated tool could theoretically do, but it would require knowledge of every software component, especially third-party components/libraries. This, today, is basically impossible and must be done manually—usually by going through XML configuration files, looking for that functionality and how it is exposed

2) Minimizing the impact of currently exploitable vulnerabilities. I normally think of stored procedures here; ones that don’t have “full privs” on “all databases/tables”. Basically, lowering privs, reducing the ability to run scripts (especially cross-domain), and restricting filesystem or code execution access. These could be CIS-CAT, Bastille Linux, or other Linux/Unix scripts. They could be GPO policies that match the requirements outlaid by PCI DSS 2.2, CIS Benchmarks, or NIST/NSA/IASAE-STIG server and application hardening guidelines. Or some other tool. I don’t see these promoted that often—most people are wrongly concentrating their efforts on desktops (e.g. FDCC) and not servers and their apps

3) Cory states that when “preventing exploits” with an application firewall—to be sure not to block proof-of-concept or “one-off” exploits. This appears to be counter to the VA+WAF offerings, and thus in-line with what the industry actually wants versus what it is being given. He (like many others including Robert Auger of cgisecurity) believes that blocking-WAFs are only useful FOR whitelisting WHEN whitelisting is not already in place OR WHEN it’s faster, easier, and less costly to fix than the code directly

Honestly, the best WAF is Mod-Security—but note that even Mod-Security won’t get in-between integration tiers (e.g. Web Services, LDAP/AD, Federated Identity services, other classic services such as SMTP, et al)—only the presentation and client tiers (i.e. HTTP). SSL/TLS can also be a limiting factor. Logging (or sniffing) SSL and session management data could basically lead to further (and more advanced and devastating) compromises

By Andre Gironda

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.