I have a slide in my security presentation deck that discusses the concept of defense in depth and how when you start opening ports or start using encrypted data streams how you are punching holes into one or more of your security layers. It amazes me how many people still do not understand how defense in depth works and how much security standards such as the PCI DSS rely on this concept.
So let us take a look at the various elements of security and the requirements of the PCI DSS and see how they bring defense in depth to bear. Keep in mind this is an example and does not encompass everything an organization could do to increase defense in depth.
For most organizations, the first level of defense is at their firewall. Requirements 1 and 2 talk to how you should use a firewall and secure it. The biggest mistake that organizations make is not configuring their firewall properly. And by configuration, I am not just talking about the configuration of the firewall’s software; I am also talking about where and how the firewall is used in the network.
The next level of defense for most networks is usually some form of intrusion detection/ prevention system. Some of the requirements in 10 and 11 talk to intrusion detection/prevention. IDS/IPS capability may be provided in a separate appliance or may be part of an organization’s firewall. The key to using an IDS/IPS is ensuring that it is kept current with its attack signatures, monitoring its log data and/or console and ensuring that it is not be overwhelmed by network traffic.
One thing that continues to amaze me is how many implementations of IDS/IPS I encounter where the IDS/IPS are in the middle of encrypted data streams. IDS/IPS systems cannot examine encrypted data streams unless they have the decryption keys which they typically do not have access. As a result, encrypted data streams are not examined and therefore sensitive data and or attacks could be going right past the IDS/IPS.
How users authenticate to your network and devices is also a level of defense. Requirements 7 and 8 of the PCI DSS talk to this point. And it is not just authentication to applications that process, store or transmit cardholder data, it is also authentication to infrastructure devices and to databases.
It has been more than five years since the “sa” default password debacle and yet you still encounter applications that use service accounts to access their database and those service accounts have no password. The rationale? “We did not want to code the password into the application,” is the common reply.
The other big area of authentication issues that you encounter is with firewalls, routers switches and other network infrastructure. The problem is that the network administrators all use the same account and password. You can understand their rationale, particularly those networks where you are administering thousands and thousands of devices.
There are a number of ways to address this situation, but these are my favorite two. The first is to implement 802.1X authentication using a RADIUS server. Under this scenario, every network administrator has their own unique account and password to access the network devices. Those unique accounts should be different from the network administrator’s account they use to get email and network access like every other user. A lot of organizations already have the RADIUS server implemented for remote access, so adding in network administration access control is relatively easy.
The second way to address network administration access is to use a “jump box.” In a “jump box” implementation, two or more “jump boxes” are placed at strategic points on the network and all network administration access is conducted through a “jump box.” The “jump box” is fully instrumented in that all keystrokes, applications, etc. are logged and those logs are reviewed at least daily to ensure that network administrators are not changing things they should not be changing. That means comparing service tickets for the network against the logs from the “jump boxes” and ensuring that only what was required to be changed was changed. “Jump boxes” can also be used to control access for server administration.
A level of defense that usually gets little recognition is operating system (OS) hardening. What some people seem to forget is that any computerized device has an OS whether it is a firewall, router, switch or server. Requirement 2 talks not only to the hardening of wireless, but also firewalls, switches, routers and servers. Every vendor publishes a guide that explains how to securely implement their OS. Where things can get sticky is with third parties that argue that their product or software will not function if you follow the vendor’s OS hardening recommendations. In my experience, testing a vendor’s product or software in a hardened environment typically does not have an adverse result. However, the key is to conduct a test.
Another level of defense is anti-virus and anti-malware software. This solution also usually includes a personal firewall on mobile devices such as notebooks, netbooks and smartphones. Requirement 5 of the PCI DSS talks to anti-virus and anti-malware while a requirement in 1 talks to personal firewalls. Nothing gets some people wound up more than anti-virus software. The requirements in 5 can have compensating controls, but implementing those compensating controls consistently on mobile devices is usually just about impossible. So while you may not have anti-virus/malware on your e-Commerce servers, you should have it on all of your desktops, notebooks, netbooks and other systems.
A level of defense that most organizations poorly manage is their collection and analysis of log data from their network devices and servers. Requirement 10 speaks to the importance of log data. As I have written before, log data is IT’s version of commercial aircraft’s flight data recorder. If you want to why a problem occurred, log data from your devices can usually point you to the reason. The problem most IT professionals have with log data is that they do not want to log everything because that generates too much data in their opinion. However, until you have an incident, you do not know what log data will be important in identifying why the incident occurred therefore you need all of it. The last thing you want to have happen is to tell management that you could not determine the cause of an incident because you did not record the critical information required in identifying the incident.
The final defense most people think of is application development which is covered by requirement 6. If you are going to get push back, this is the most likely and consistent place you will get push back to the PCI DSS or any other security program. Application developers are very protective of their environments, so when you start infringing in their area, they can get rather upset. As a result, you hear the typical lament from developers that security, “restricts their creativity.”
In today’s rush to get things done, application developers usually do not have security at the front of their minds. As a result, by the time anyone knows that there is a security issue, it is too late for it to be fixed and the application goes into production with the fix to be part of version 2. That was the whole point the PCI DSS addresses in requirements 6.4, 6.5 and 6.6; avoid putting susceptible software into production. The whole point of these requirements is to build a certain amount of security into the development process to minimize the amount of security issues that end up in production.
The real final defense is an organization’s policies, standards and procedures. Yes, that paperwork that everyone thinks is “make do” work, really does have a purpose. An organization’s policies, standards and procedures are the rules that everyone is to follow to ensure security. Those rules also provide a way to measure people’s compliance so that, in the event of an incident, those people that did not follow the policies, standards or procedures can be shown their mistakes so that they can correct their actions in the future. These rules also provide an organization’s framework for explaining to personnel as to how the organization is protecting their information assets and defining those assets.
There are a lot more options for defense in depth, but I think you get the idea. Now that you understand how defense in depth works, you should now also understand what happens when security personnel are asked to open ports for an application or change configurations that reduce the number of levels in an organization’s defenses. The fewer levels involved the higher the likelihood that a lapse in control can result in a breach, particularly when a number of lapses in controls are occurring simultaneously. This is how supposedly PCI compliant organizations end up breached.
