The Case for Integrating Application Security with Tried-and-True Perimeter Defense Strategies

A couple of weeks ago, I was meeting with the application security team at a Fortune 500 company and one of the testing team members asked, “Does it matter whether or not software’s built securely? Can’t we just block attacks at the perimeter with an NGFW (Next-Gen Firewall), web application firewall or application delivery controller?”

Adherents, including yours truly, to the importance of building security into software and implementing secure by design methodologies might scoff at that kind of question. But, consider for a moment if there’s any merit in it. I believe there is, but in limited use-cases. Perimeter defense appliances should never be considered as replacements for robust development practices. However, there are several situations where bolstering your perimeter defenses to protect your applications makes perfect sense.

Here are four practical examples:

1. To Manage the Inevitable

A “secure by design” approach calls for building security in from the requirements definition phase, and incorporating it through all phases of the development lifecycle. Security reviews and risk assessments during architecture and design, static testing during implementation, dynamic testing at pre-launch and ongoing security testing and monitoring in production.

The goal?  Find and fix each and every vulnerability, before putting applications into production.

The reality? Even the most stringent development processes can miss hard-to-find vulnerabilities like business logic errors. And, changes in rapidly-evolving production environments can expose vulnerabilities that weren’t visible before.

If your exposures can’t be fixed immediately, placing rules on perimeter devices that can block exposure and prevent future exploits may be a lot more business-friendly than taking your applications off-line.

 2.  When Deployment Time is of the Essence

If you’ve worked with web application deployments, you’ve probably experienced that last-minute “oh-no” moment, when security testing comes back with a stack of high-risk issues and recommendations (or rather, mandates) not to launch applications until issues are remediated.

If there’s a critical business need to get applications into production ASAP, sending them back to development for revisions may not be an option. Standard operating procedures often require application or business unit owners to sign off on exceptions, accepting risks before they place the apps into deployment.

Rather than placing known vulnerable apps into production in an unprotected state, doesn’t it make better sense to write rules for perimeter devices to block those exploits? Granted, not every vulnerability can be blocked or mitigated in that fashion, but having some protection is definitely preferable to having none.

3. Compliance Gotchas

Great day in the morning! The PCI (Payment Card Industry) QSA (Qualified Security Assessor) just finished her RoC (Report on Compliance), and your company failed because a web application that stores, processes or transmits credit card data is vulnerable to XSS (Cross-site scripting) attacks.

While it may be too late to pass the RoC, it isn’t too late to block the exploits, if you can place rules on your web application firewall to mitigate the exposure.

4. Legacy Liabilities

For a while in the 90s, many of us hoped that as old, legacy applications and languages were retired, we could usher in a golden age of strong, well-tested secure web applications. Sadly, that hasn’t been the case.

Ironically, most companies struggle with “legacy web apps” that were written years ago, but are popular with users and simply aren’t ready to be replaced. Development costs for new applications that offer the same user experience may not be available, and developers who wrote the original apps are probably long gone. And, since attackers are getting ever more clever with their exploits, those legacy web apps may be particularly vulnerable to older attack vectors.

Again – wouldn’t it be better to put some kind of protective rule on perimeter devices, instead of leaving your applications completely wide open?

All of the above are mentioned as limited-use stop-gaps or compensating controls, to be employed while applications can be remediated and vulnerabilities removed. And, in no way am I suggesting that all WAFs and NGFWs can prevent every exploit path through to your web applications. But if vulnerabilities can be mitigated with perimeter devices or other compensating controls, shouldn’t they be?

Have you used these strategies in practice? Do you agree that they’re valid use cases? Please let us know in the comments section.