Why Does Strategy Matter?
The term ‘security strategy’ can be ambiguous and often means different things to different people. Because of this, many organizations do not have a formalized security strategy and those that do may not have an effective one.
This is understandable. Managing the day-to-day issues associated with a security program (alerts, audits, projects, personnel issues, etc.) can be challenging, and it is often useful to eliminate anything that is not directly solving workload concerns.
Additionally, if I don’t have a clear understanding of when or how to use a tool in my toolbox, it is often easy enough to ignore that tool and to approximate workable solutions using other tools as needed.
When used correctly, a security strategy can be a low-effort, high-impact tool for reducing operational noise and improving organizational decision making.
Before building a strategy, it can be helpful to define what a security strategy is and what it’s for.
At the highest level, a strategy is a series of concepts that align tactical decisions to long-term goals.
In other words, it’s the list of stuff that you want people to keep in mind when they are making day-to-day decisions. The list of stuff that, if kept in mind, will help prevent people from making choices that ultimately cause emergencies, rework, and other kinds of operational pain.
A clear and well communicated strategy won’t prevent all potential operational mistakes, but it can help avoid and/or mitigate many of the worst ones.
Step One – Define Context & Current State
Step one in defining a strategy is getting an understanding of where you are today. While there are many tools available for defining current organizational maturity within a larger context, I like to use following four-stage pyramid, which I’ve loosely based on Maslow’s Hierarchy of Needs. In short, the pyramid represents the high-level stages of growth of an organization’s security program. Organizations start at the bottom and proceed toward the top as they become more mature. Although some organizations try to perform higher-level functions without fully maturing a lower level, these efforts are generally ineffective, as each layer builds on the prior organization ceases to work on the earlier stage – it simply means that all the foundational components of that stage are in place.
There are many options for identifying currently operational maturity within a larger context, and many of the major security frameworks include a mechanism for identifying where an organization currently exists within the larger maturity security ecosystem.
If you wish to use the above pyramid as a starting point, a high-level description of each tier is as follows:
- Prevent/Detect: An organization at this stage is primarily concerned with building out the ability to prevent and detect security issues. Although most organizations are frequently updating their preventative and detective capabilities, organizations at this tier have large known gaps in current capabilities.
- Measure: An organization at this stage has begun to quantify and measure its security processes. While many tools provide out-of-the-box metrics, organizations in this phase are selecting the metrics that are meaningful to their organization and are building out historical data associated with those metrics. Like the above tier, originations will never be ‘done’ adjusting their metrics, but a clear understanding of what is important and how to consistently measure those elements is the key to graduating from this stage into the next.
- Optimize: An organization at this stage is using internal and external measurements to fine-tune its tools and processes. At this stage, originations are making conscious and intentional decisions around the detective and preventative measures which are in place, using quantitative factors to replace poorly performing controls with more efficient and effective controls.
- Compare: An organization at this stage is primarily concerned with comparing its security program with its own past performance along with the control performance of its peers. Although it can be tempting to compare your organization to another, prior to measuring and optimizing, these comparisons are often misleading and/or ineffective. This is primarily because without effectively measuring it is highly unlikely that the comparisons will be accurate. Additionally, without having optimized, the results of the comparisons will not drive any meaningful decisions – the organization will still wish to optimize its processes in order to reduce costs and/or increase effectiveness.
Step 2 – Define Targets & Timelines
Once an organization knows where it is, it simply needs to define where it wants to go, and how long it expects to take to get there.
Generally, strategic goals are defined every few years. Setting annual strategic goals can work, but if the strategy is drastically different every year individuals will begin to ignore the strategy statements.
Additionally, where it makes sense to do so, organizations can carve out different strategic goals for different elements of the business. For example, different business units or geographies may have different starting points, and so they may require different goals, or the same goal with different timelines. This approach is perfectly fine as long as organizations are careful not to get too complicated. The more complicated the goals are, the more it will dilute the overall impact of the strategy.
Lastly, sometimes the best approach is to select targets that have less to do with operational maturity, and more to do with larger organizational goals like cost efficiency, speed to market, etc. If not already required, tying security targets to these larger goals can lend additional weight to the strategy that you set.
Step 3 – Define Tactics
Defining context, current state, targets, and timelines are all necessary precursors, but tactics are the heart and soul of your strategy.
In their simplest form, tactics are a high-level description of how the organization intends to achieve the targets and timelines (defined in step 2). Some examples of generic tactics include ‘increased automation’, ‘lower error rates’, or ‘faster issue acknowledgement’.
Although similar in a few ways, tactics are not projects, and the tactics you define should not be tied to specific projects. Projects are planned, defined, time-bound, and have very specific intended outcomes. Tactics are a summary of the guidelines that individuals should keep in mind while making day-to-day decisions.
Once context, current state, targets, timelines, and tactics are defined, they often combine very easily into a strategy statement such as: ‘We will move from [CURRENT STATE] to [TARGET] by [TIMELINE] by implementing [TACTIC 1], [TACTIC 2], and [TACTIC 3]’.
Although it’s a simple concept, defining and broadly communicating this type of strategy can significantly help to ensure that individuals are making operational decisions that help long term goals, rather than inadvertently hindering them.
In order to ensure strategies are effective, organizations should keep the following in mind:
- Strategies are most impactful in large, quickly moving organizations. The smaller and slower the organization, the less impactful a strategy will be.
- Strategy statements should be considered guidelines. They are not policy, and there will be times where the best decision runs counter to the strategy.
- A defined strategy should be communicated to everyone, regardless of whether or not they are on the security team. This can help avoid other teams making decisions that adversely impact security goals.
Ultimately, a well-defined security strategy should be a lot like advice from a highly skilled park ranger prior to going on a long hike. It does not replace your map (multi-year security plan), it does not change the park’s rules (security policies), but in situations where you are on your own for a long period of time (large organizations which are moving quickly), keeping the advice in mind can absolutely help a lot of people avoid quite a bit of trouble.
Once clearly defined, a security strategy is not hard to put together. It may not directly solve the operational items that occur daily as part of a security program, but it can play an important role in cutting back on the noise by preventing unnecessary issues from occurring.
Author: Rick Yocum
Rick’s independence, curiosity, and sense of humor have always driven him to explore. As a baby, exploration meant breaking out of any crib that had the audacity to try to cage him. As an adolescent, exploration meant remotely accessing classmates’ computers in order to pass notes and perpetrate pranks. But the real value of exploration is not in discovery—it’s in the application of discovered knowledge. Therefore, as an adult, Rick is passionate about helping organizations explore how technology and behavioral economics can be leveraged to reduce risk and improve operations. Rick is eternally grateful to the teachers and mentors who have allowed him to explore (and have sometimes even paid him to do it).