‘Defense In Depth’ And The Control Triad

A lot has been written recently regarding that the PCI DSS relies on the concept of ‘defense in depth’.  However, very little has been written about how ‘defense in depth’ is actually implemented by the PCI DSS.

Before going into the PCI side of defense in depth, let us discuss the concept of defense in depth.  Defense in depth relies on the triad of preventative, detective and corrective controls.

• Preventative controls are those controls put in place to prevent, as best possible, a security incident.
• As I have repeatedly pointed out, security is not perfect.  Detective controls are designed to back up preventative controls by detecting incidents that may occur due to a shortcoming in or failure of the preventative control(s).
• Corrective controls are those controls that back up both the preventative and detective controls by providing feedback to ensure that any lapses in those controls are corrected or those controls are redesigned to better prevent or detect their respective conditions.

With that as background, let us discuss an example of the preventative, detective and corrective controls that are part of the PCI DSS.

One of the primary preventative controls in the PCI DSS is network segmentation.  Properly implemented, network segmentation physically or logically separates PCI network traffic from all other network traffic.  By separating PCI network traffic from all other network traffic, you minimize the potential that PCI traffic is corrupted by non-PCI traffic.  Network segmentation comes in many forms.  It can be the firewall based on the rules that are implemented to segregate PCI network traffic from the Internet to the DMZ, the internal network to the DMZ or the general internal network to the PCI internal network.  It can also be the VLANs that are implemented across your internal network to segregate PCI traffic from all other internal network traffic.

On the detective side, logging is probably one of the biggest detective controls.  Every device can generate a log and, if properly configured, logging can provide a plethora of information regarding an organization’s network.  However, in order to detect an incident, log information must be reviewed and analyzed.  Not only must it be reviewed, but also with today’s sophisticated attacks, the log information must be correlated to other devices’ log information.  This requires a security information and event management (SIEM) system that centrally collects all log information from all devices and then conducts real-time or almost real-time analysis of that information looking for indications of any potentially anomalous behavior.  When potentially anomalous behavior is believed to be detected, the SIEM alerts the appropriate personnel to further investigate the behavior.

Detective controls can also be corrective controls.  The analysis of the log information is an example of just such a control.  Not only is it a detective control, it is also a corrective control.  That is because the analysis of the log information typically results in corrective actions to address the anomalous condition that is detected.

The Report On Compliance or Self-Assessment Questionnaire process is also an example of both detective and corrective controls.  Either process asks your organization to examine the triad of controls and detect any shortcomings in how these controls function.  If the controls are not functioning properly, the process identifies those controls that need to be changed and allows for the development of plans to correct those controls.

An incident occurs when the triad breaks down.  The preventative control is not properly designed to prevent all likely incidents.  A detective control does not detect all possible flaws in the preventative control(s).  And the most common offense?  When issues are identified with preventative or detective controls, action is not taken to correct the shortcomings of the preventative or detective controls.

Trust me; regardless of how good your organization is at following its policies, standards and procedures, you will have areas where the control triad does not function properly.  A good organization seeks out, identifies control issues, and addresses them as soon as they are identified.  A really good organization does not make their efforts to seek out and identify failings as a ‘witch hunt’ because they recognize that people are only human and always need to improve.

I could go on and on and on regarding the control triad and how it applies to the PCI DSS requirements.  However, I think you get the general idea.  So, the next time you are complaining about why a particular requirement exists, think about what it prevents, detects and/or corrects.  All of the PCI DSS requirements are there for a reason and provide cover for a significant number of the other requirements.  And that is what ‘defense in depth’ is all about.

Advertisement