The application is the perimeter

An interesting trio of articles hit yesterday. One is a summary of industry response to the announcement that President Bush intends to fund a massive network security initiative. The money quote is from Veracode’s co-founder and CTO, Chris Wysopal, who compares the initiative to “posting police on every corner in a dangerous neighborhood, but failing to fix shoddy locks on the houses.” The second is an article by Chris about improving development processes to reduce the number of security-related flaws that go into your software in the first place. And the third is an interview with Chris, co-founder and chief scientist Christien Rioux, and senior director of security research Chris Eng (the three Chris’) about the founding of Veracode.

The interesting bit about President Bush’s proposal is that it proposes to put so much money at the network layer while neglecting to recognize a key fact: the application has become the perimeter. All the network security in the world won’t stop an attack against a flawed application that is sitting on an open Port 80—as it has to be to be accessible over the Web—and that, if compromised, can hand an attacker access to sensitive customer and transaction data as well as potentially compromise other machines inside the company’s infrastructure.

The world has changed. In the early 90s, the only security that anyone thought about was viruses and the attack vector was floppies. The advent of the Internet brought about the rise of the network firewall and other network layer technologies. When attackers proved to be able to route around that, the machine-level firewall appeared, signalling a shift of the perimeter to individual computers and servers. But no firewall can guard against an intrusion that occurs in the form of a fraudulent interaction with an application, using the application’s own interfaces and protocols. To guard against that, the application has to be hardened.

In short, the administration’s focus on network security proposes to spend lots of money on a problem that hasn’t been at the real perimeter for about eight years now. Worse, it proposes to do it by placing “sensors” into government and private networks, which sounds like the introduction of additional points of vulnerability to me.

Chris’s article proposes an alternative to doing this, an approach that has actually had a fair amount of success at Microsoft: focus on how you can write secure code and not introduce the flaws to begin with. Because once you recognize that the application is a critical part of the security perimeter, the question should become: how do I catch those potentially exploitable flaws before they reach my production environment?