7 Design Patterns To Detect When There Is Drift From Security Policies
By: Opinionated Security
Tags: Governance, Security, Ciso, Cybersecurity, Leadership

Good standards governance requires the definition of sound policies that include both best practice and good practice. But, defining policy and ensuring that controls, systems, and users STAY within policy require completely different governance approaches.

Think about how quickly your organization can identify when your controls have drifted out of policy and react to that drift. As this post is aimed at senior cyber leaders, do you have a way to communicate to the executive team and other stakeholders how mature that your program is for detecting drift across all of your control families, the efficiency of the detection, and where additional investment is needed?

This blog post will help you understand what standards drift is, why standards drift needs to be addressed quickly and efficiently, and provide some design patterns that can be used to classify, measure, and communicate the maturity of your ability to detect standards drift as an organization.

STANDARDS DRIFT OVERVIEW

Standards drift is the difference between your published standards or policies and the actual state and configurations within your systems, applications, and network. In practical terms, drift represents an increase in risk. Drift within critical controls can lead to negative audit findings or, worse yet, an incident.

The Greek philosopher, Hereclitus, said that you can never put your foot in the same river twice because the river is always changing and you are always changing. The same principle applies to your network. Networks are always changing. You will always have new systems, new applications, new users, and new requirements that constantly change your network and machines. Drift then could be considered completely normal if you only rely on your standards and policies without any process in place to identify and remediate drift.

As security practitioners, we can’t pretend that standards drift doesn’t happen with systems, applications, or users. That said, we do like to pretend that drift never occurs. We often find comfort in our policies that may be doing nothing more than sitting on a shelf and “finger wag” that we have policies against whatever drift was most recently found by an audit or was the root cause of an incident.

Your ability to detect standards drift is one measure of the maturity of your controls governance. The more mature your governance, the faster and more automated the response to any drift from standards is likely going to be.

That said, the ability to measure and communicate one’s level of maturity around detecting standards drift is largely hit or miss. My guess is that we all overstate our level of maturity to some degree. We focus primarily on missing controls but tend not to invest in knowing when existing controls aren’t in the state that we expect. The proof isn’t in the pudding in this case — it’s in your audit finding and incident root causes.

My anecdotal evidence of this likely overstatement is the frequency with which senior cyber leaders continue to be surprised by controls that we thought were in place or not meeting the control objectives. A number of factors contribute to the surprises. Some of these might include work that we thought was completed but wasn’t because of distracting work, shifts in work priorities, lack of training, or even potentially malicious activities.

At the end of the day, senior cyber leaders won’t get what they expect; they’ll get what they inspect. A mature program won’t rely on manual design patterns to fully scale across all of the required areas to be inspected…..and yet we often do try to do exactly that. I know the frequency that I hear, “yes, we’ll review that quarterly” and the frequency that the review is actually are performed. The expectation normally doesn’t meet the action.

Let’s briefly put a pin in this topic for a second as you might be thinking, “hey, isn’t this all the job of internal IT audit?” The IT audit role isn’t to govern. I believe that governance is the job of the security team. IT audit’s role is to verify and validate the governance.

Relying on IT audit to govern can be a risky proposition. This validation process most likely occurs too infrequently for critical controls in most organizations. Perhaps even too infrequently for non-critical controls too. The standards drift that might occur between validations can have grown in a way that is invisible to the security team and also create an opportunity for far more risk than the organization’s risk appetite allows for.

Properly governed, standards drift within an organization’s controls landscape can be quickly identified and reigned in, put under a treatment plan, or at least carried on the organization’s risk register. This way, IT audit will rarely if ever produce audit findings that were not previously known to the security team.

Let’s jump into the design patterns….

SEVEN DESIGN PATTERNS FOR DETECTING STANDARDS DRIFT

Design patterns (which is a term borrowed from software engineering) can be used by cyber security organizations to help classify their approaches to detect standards drift in a normalized way across controls families. Wikipedia defines software design patterns as follows:

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

So, I’ve defined seven design patterns for detecting standards drift. They are loosely ordered from most mature and most automated to least mature or more manual. The seven design patterns are as follows:

Secure by default Self-healing Automated detection Compiled Analysis Raw Data Correlation Manual Review Manage By Exception

Since these aren’t finished designs, this blog post will only cover these design patterns at a high level. You can find a more rigorous review and examples for each design pattern in the youtube video clip, “Seven Design Patterns For Detecting Standards Drift” which itself has been edited from a more general podcast episode around standards drift.

Secure By Default is the most automated and mature design pattern because the security governance for a given control (or set of controls or perhaps even a system) has been thought through and designed in a way that the governance guardrails never allows the user to drift from standards. A good metaphor for this design pattern might be an ATM machine — the system has enough guardrails that any given user can do many things but none of them are unsafe and the bank only has a low, fixed amount of risk anytime the ATM is used. If your users can never get out of policy while using a system even for a millisecond, you likely are using this design pattern.

Examples of this design pattern might include use of Windows group policy objects or AWS landing landing zones.

Self- Healing is a design pattern in which both the detection of standards drift and the enforcement needed to bring the drift back into policy are performed in an automated way. If a user gets outside of a policy, they will be gently brought back into policy. The difference between this design pattern and secure by default is that drift can occur with this design pattern and that drift may not be enforced or otherwise deterred in real time.

Examples of this design pattern might include anti-virus or data loss prevention controls.

Automated Detection is a very common design pattern in which the detection of standards drift is performed in an automated and high fidelity manner. If there is an alert, some control or activity is out of policy. The remediation for the identified standards drift will have to be completed in some manual way.

Examples of this design pattern might include continuous SIEM monitoring or automated pen testing controls.

Compiled Analysis is a design pattern that indicates likely standards drift through the use of metrics and measures. The collection methodology for detecting standards drift in any given control might range from fully automated collection or fully manual depending on the control and underlying systems involved. This design pattern is the first in which detection may not be in real time and might only be detected with the frequency that the metric is collected (daily / weekly / monthly / quarterly).

Metrics designed to detect drift are the most common example of this design pattern.

Raw Data Correlation in which a manual search of raw or low fidelity data is required to find standards drift. Usually, the data to be searched has been moved off the source system or con even have been generated in some automated way. If the drift requires manual search of data, alerts, or emails to find, this is the design pattern that is being used. Standards drift is only detected with the frequency that the raw data is manually searched.

Manual log searches or manual threat hunts are common examples of this design pattern.

Manual Review is a common design pattern in which system data or configurations are reviewed manually. This review normally happens on a single system or less frequently with remote access tools across a number of systems in a manual way.

This can include controls such as configuration reviews or manual pen tests.

Manage By Exception is a common design pattern in which little ongoing effort is invested in identifying standards drift and the drift is only really detected as findings in audits, reported by users, or as a root cause in incidents.

This design pattern is in use when little or no ongoing internal effort is expended to identify drift and some external event or activity alerts the organization to a drift in standards. The external event might be accidental discovery, an audit finding, or even a security incident.

HOW TO USE THESE DESIGN PATTERNS AT THE PROGRAM LEVEL

The intent of these seven design patterns is to allow normalized measurement and comparison of approaches used to detect standards drift. These can be used in a consistent way and with a similar taxonomy across the granular differences of control families that are not similar. The design patterns raise the level of abstraction so that different controls can be classified in similar ways.

For instance, use of group policy objects on windows machines might share the same design pattern (“Secure By Default”) as landing zones on AWS. A wide range of controls that are never reviewed might share the design pattern of “Manage By Exception”. As you gain visibility of the maturity level of controls at the individual level you might consider rolling up the design patterns in the aggregate and draw interesting conclusions that impact your future work plans and influence conversations with your executive team.

Different systems, different controls, same vocabulary.

The key is being able to measure your current level of maturity for detecting drift. What if you found that a larger than expected percentage of controls impacting critical systems were in reality being managed by exception? What if some of the controls being managed by manual review could be more easily matured with just a bit of additional resourcing. These data might spark a conversation to resource maturing the governance of these controls in a more automated and mature way.

Hopefully, this post helps you to understand how to use design patterns to spot gaps and areas of improvement in your ability to detect and respond to drift away from your policies. Using design patterns can raise maturity and reduce risk as well as provide a way to measure and communicate with your executives at the cyber security program level.

Your cyber security program is yours to define. Make it a good one!

You follow me on twitter or Youtube by searching for opinionated security.