Defense in Depth
Defense in depth is probably one of those clichés that every auditor loves using and companies struggle to understand why is it necessary? After all, it does cost the extra money. If my risk is already low, why do I need additional security. The “What if” analysis can and does sometime go to the extremes.
The quickest and the easiest way to create an analogy is this – even though you have locks outside your house, do you just keep all your valuables in the living room? After all, there is a lock on the door, right? No, you never do it. Defense in depth is a virtual world analogy of the same security practices that are known to be truths (and are never debated) in the physical world.
Easier said than done! How does one actually go about implementing defense-in-depth? Let’s take a simple example. Suppose your organization is hosting a web application that has a high risk profile and it is a standard multi-tier application with a web server, application server, and a database. Let’s assume for the sake of simplicity that there are no middleware or web services involved (however, that won’t change the solution that we will be implementing). Let’s go layer-by-layer, from an infrastructure perspective, to enforce “defense in depth” on this architecture.
Physical layer – The devices should be hosted in a location where an attacker should not be able to gain physical access to the servers. If these are implemented using Virtual machines, the host should not be vulnerable to boot attacks, etc. that can be performed by an attacker with physical access.
Data-Link Layer – The servers should be separated from each other using Virtual LANs if possible. The objective of using VLANs is that another server in a different security level but in the same broadcast domain should not be able to sniff any sensitive information out of the server
Network Layer / Transportation Layer – Only those services should be exposed that are needed to be exposed at each trust boundary using a stateful firewall or a load balancer. E.g., to the world only 443/tcp or 80/tcp might need to be exposed. Between the app server and the database only port 1521/tcp may need to be exposed. From the database segment to the application server only certain other ports may need to be provided access. If load balancers are being used, configure the load balancer such that only the necessary ports are accessible on the servers hosting the application. IDS/IPS systems could also be deployed to get alerts or block attacks against the infrastructure. IDS/IPS systems generally span various layers of the OSI model such as network, transport, session, presentation and application layer.
Session Layer / Presentation Layer – Using a channel encryption using something like SSLv3 with only strong cryptographic protocols and not allowing resumption of SSL sessions or renegotiation, using legitimate SSL certificates signed using a valid Certification Authority (CA) might be a good idea to protect. A lot of times, organizations tend to use server farms that lie behind load balancers. The SSL terminators in such cases could lie on the load balancer.
Application Layer – A lot can be done on this layer. One could use Web application firewalls such as ModSecurity for Apache or database firewalls such as GreenSQL. IDS/IPS systems could also be deployed that alert on attacks or stop them in transit. At this layer, other things can also be done such as using secure development practices (which could constitute a whole book in itself). Using strong access controls with good authentication and separation of privileges at the application layer between the database and the application server or between any of the two components of the multi-tier architecture could also create an environment for a secure application. Using other detective controls such as log management mechanisms that alert on right levels at the web server, IDS/IPS, database, app servers could also help in detection or post-incident analysis.
All these techniques (and more) could be implemented just to secure one application. The question always is what is the risk of the breach and the expected loss incurred due to a breach. If this amount is more than the cost of the infrastructural controls, then it is always a good idea to implement controls by following “defense in depth”.