Inside-Out Security

8:00 AM -- Defense in depth -- it's a term we hear all the time in security, and some of us practice it without even realizing it. But it's probably one of the most important theories to a solid security architecture.

Let's look for a moment at what a normal, small, mom-and-pop e-commerce site looks like. It is probably running on Linux in a shared hosting environment, with FTP access. There's probably a firewall in place, but it allows inbound FTP, HTTP, and HTTPS from anywhere. It's unlikely that mom or pop even know how to link to the SSL-enabled portion of their site. The site allows PHP, PERL, and Java. The site does a fairly good job at isolating the user accounts in their respective FTP directories, but that's about all it does.

What I've described is vulnerable not just from the outside, but it's also vulnerable to man-in-the-middle attacks, as well as other users of the same system. It makes the assumption that the only people who are going to attack it are outside the perimeter, and there are no vulnerabilities in the Web application or the services provided. Furthermore, it makes an assumption about the fact that those protocols have nothing sensitive traveling over them.

This is about as simple as a network gets, and it's also just about as vulnerable as it gets. This is not a well defended application. While you are designing an application, you need to think about it from a number of attackers' perspectives -- remote attackers and insiders.

Insiders can be part of the company, or like in the case above, they can be other users of the same virtual system. Building up the network to defend against external threats makes sense, but you cannot rely on it alone, as you still need the application to listen on ports 80 and 443.

Understanding that should help explain why auditing code, and looking at the Web application as its own problem requiring additional layers of security, is critical to analyzing your risk profile. Adding layers is never a bad thing, as long as you aren't causing those layers to deny service when it is a critical, always-on type environment. Weigh your business risks against the Web application's purpose, as well as how it interacts with the rest of the system, its developers, and the consumer. And, oh yeah -- just say no to shared hosting if security is a concern.

— RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F*the.net. Special to Dark Reading.