Defense in-Depth Simplified

I like things simple. When things are simple they are easier to explain, document, implement, revise and manage. Take defense in-depth. Defense in-depth is a term, which means, security implemented in layers. If one layer fails another layer is present to take its place, to continue defending an organization's sensitive asset(s) such as a computer system, data and information.

So how do we simplify defense in-depth from a planning, design and implementation standpoint? Over the years, I've adopted four main pillars as my approach for developing a defense in-depth strategy.

The pillars are:
Protection
Detection
Response
Awareness

Within each pillar are three types of security controls:

Administrative
Technical
Physical

I like this framework for addressing risk. It is a simple and straight forward approach that is easy to understand and communicate. This approach to defense in-depth gets us thinking about the details, in terms of the specific controls we may need to deploy to reduce, transfer or eliminate risk for the business. It is also helpful, I find, to lay out this framework when conveying an overall information security strategy to the business, CIO and/or Board members.

Wherever you learn about risk within your organization, whether it is physical or digital, ask yourself, what do I need to protect, detect, respond to or make people aware of? For example, if your Finance department is planning to outsource its payroll process to a cloud service provider, and the provider doesn't employee encryption at rest for employee social security numbers in their database; that is an important discussion to have with the business and the service provider.

We probably want to start by suggesting to the service provider options to protect employee social security numbers using truncation, tokenization or encryption - technical controls. Can we put a detection process in place such as auditing account access at the database layer, review data center access logs for those coming and going into and out of the data center, and add language to our contracts (service agreements, etc.) - technical, physical and administrative controls. Can we implement a response process and/or policy or service level agreement (SLA) to alert us if unauthorized access to social security numbers is attempted or achieved; and can we review camera footage to see who tried to gain local access to the database - a technical, administrative and physical control. And lastly, what can we learn from this in terms of raising awareness to the stakeholders involved in the project - an administrative control that is tied to security training and education.

In a real life scenario, the example above may be a bit more complicated than I laid out. When it comes to doing business where a high probability/high risk scenario exists - the loss of confidential and sensitive information - sometimes we need to file an exception and live with the risk. There are many reasons why this happens. The important thing is to document it and keep it on the radar until it can be mitigated. At least you walked through your defense in-depth framework and identified your controls. Your work is done. On to the next project.