Developing Information Security Strategy: Define your solutions, Part 2

 

Introduction

Welcome back to our series on how to develop an information security (InfoSec) strategy. If you haven’t already done so, we recommend reading Parts 1-6 to familiarize yourself with the design thinking process that we will follow for the rest of the series. 

We started discussing the DEFINE phase in the previous article.

Figure 01: The DEFINE phase of our Design Thinking approach

Figure 01: The DEFINE phase of our Design Thinking approach

To recap, the goals of the DEFINE phase are to:

  • Define solutions for your organization’s security requirements

  • Define the value proposition of the InfoSec strategy for your stakeholders

  • Map your solutions to the value propositions

  • Align your InfoSec strategy with your organizational strategy

  • Document the strategy

  • Estimate the strategy budget 

  • Define timelines

We discussed the first three goals of the DEFINE phase in the previous article. In this article, we will discuss the remaining goals and conclude this phase.

Align your InfoSec strategy with your organizational strategy

For your InfoSec strategy to succeed, it must align with your organization’s strategy. Such alignment should be balanced, simultaneously addressing stakeholder pain areas, achieving regulatory compliance, and empowering the business to take more bold steps towards achieving their vision.

One way to ensure alignment is to use an IT framework like COBIT. However, most small and medium businesses (SMEs) have not implemented COBIT. It’s also quite common for  SMEs to forgo a corporate strategy and instead rely on yearly goals. While this isn’t inherently bad, it can mean that these SMEs make short-term decisions without proper insight into the long-term effects.

We will not discuss frameworks in detail in this article, as that topic is broad enough to warrant a series of its own. Such as COBIT since they are a series on their own. If your organization does not have COBIT in place, we urge you to start using it. 

Before defining your strategy’s alignment, you need to determine your strategy’s individual programs’ objectives. Each of these objectives can be derived from the potential solution objectives you have identified, based on your organization’s security requirements (refer to Part 6).

If implementing COBIT is not something your organization can do, then you should instead do the following:

  • Align your InfoSec strategy with your risk management framework

  • Align your InfoSec strategy with long-term organizational goals 

Align your InfoSec Strategy with your the risk management framework

An enterprise risk management framework (ERM) with well-defined impact areas is an excellent resource to base your InfoSec requirements. Referencing your ERM in this way will help you prevent a security breach that would affect your business’s identified impact areas.

Figure 02: Sample risk assessment matrix

Figure 02: Sample risk assessment matrix

 This method for alignment requires building an alignment matrix that uses the same impact areas as your ERM. Below is a partial matrix based on two of the impact areas from the above RMF. 

Figure 03: A sample partial alignment matrix using ERM impact areas

Figure 03: A sample partial alignment matrix using ERM impact areas

As you can see, this alignment matrix serves as an additional tool to help an organization fine-tune its security strategy. 

Align your InfoSec strategy with long-term organizational goals.

In addition to referencing your ERM, we recommend aligning your security program objectives with your organization’s long term goals. Alone, this approach is not as effective as the ERM method, but it can complement it well. Only referencing long-term goals should be a last resort. In fact, if your organization does not have a strategy, long term goals, or ERM in place, it’s likely that your organization is not under mandatory regulations and seeks to implement a security strategy that is simple and cost-effective. Furthermore, without a foundation of ERM and long-term goals, COBIT will not be effective.

With all that in mind, below is an example of an IT outsourcing company using its long-term goals as the basis of its security strategy. We’ll call this company “ABC.” ABC’s mission statement is: 

To contribute to our clients’ competitiveness by providing them with IT services in a timely, transparent, reliable, and specialized manner and with a strong service attitude.

ABC’s mission statement translates into the below long-term goals:

  • Establish ABC as a leader in providing IT services to small and medium businesses

  • Provide services that are secure, reliable, and trustworthy

  • Provide cost-effective services

  • Tailor our consultancy services to our clients

  • Provide tangible value-add services to increase the competitiveness of our clients

Next, we will map ABC’s security program’s objectives with its long-term goals.

Figure 04: A sample partial alignment matrix, using long- term business goals

Figure 04: A sample partial alignment matrix, using long- term business goals

The above alignment matrix is almost identical to the one produced using the ERM business impact area.

Using any of the techniques provided in this article will help you ensure your security strategy satisfies your stakeholders’ requirements and is aligned with your overall business strategy. Demonstrating alignment will help you justify your security strategy and get stakeholder buy-in.

Documenting the strategy

Once your stakeholders have vetted your security programs and their objectives, it is time to document them as a potential strategy. In the next phase, you will likely need to transform the strategy further to suit your stakeholders. As you prepare to present your strategy to stakeholders, we recommend documenting it with a spreadsheet. This will help you keep things organized. Then simplify the strategy in a presentation to discuss with the executives (the strategy itself should be no more than one slide). For illustrative purposes, though, we will format this simplified security strategy as a table.

Figure 05: A partial sample security program for an organization

Figure 05: A partial sample security program for an organization

You must still determine one more piece of information before presenting your security strategy to your stakeholders: your programs’ timelines.

Estimate strategy budgets 

Estimating the strategy’s budget involves many discussions with potential software solution vendors. Seasoned security professionals are often good at estimating the strategy’s cost. The estimate does not have to be accurate, so do not spend too much time on this calculation. 

However, do not inflate your security strategy’s cost and risk of being shot down by your organization’s executive team. In general, make sure to factor the below costs into your budget:

  • Software solution cost (licensing)

  • Hardware cost (some of the software solutions will be on-premise)

  • Consultancy cost

  • Backfilling cost for your IT infrastructure specialists

Once you have the budget for each program, add them together and add another 10% to reach a final cost.

Defining timelines

Timelines are a trap you should always avoid at a strategic level. However, they are essential at the program level. Defending the organization from threats is not a one-time thing. Instead, it is an ongoing effort that should last as long as the organization exists. Hence, at a strategic level, we propose using a maturity model instead of a time-based timeline. 

The timeline to achieve such maturity could be anywhere from three years to ten years, depending on your organization. 

There are many options available to use as a maturity model:

Alternatively, you can create your maturity model based on your corporate alignment framework. Bear in mind that creating a customized maturity model will, in turn, require additional effort from you when developing a maturity assessment questionnaire and justifications for the maturity model. 

Below, we have used CMMI Maturity Levels to demonstrate the utility of maturity models. To keep it simple, we have assumed that the company using the model is a privately owned small business that does not need to comply with mandatory industry regulations. We have also applied limits on the number of programs and the levels of maturity in the CMMI.

Figure 06: A sample maturity model for the security strategy

Figure 06: A sample maturity model for the security strategy

Using a maturity model instead of a timeline enables organizations to implement each program optimally without increasing the budgets. By following a maturity model, you can systematically build a robust (and effective) security system. You will also be able to keep the startup cost of each program relatively low, and your teams will have sufficient time to adjust to the resulting changes in their operational activities.

Closure

Referencing your corporate goals is an important part step towards developing an effective InfoSec strategy. Once the alignment is satisfactory, you need to document the strategy for discussion. This strategy is not final since it should be discussed with your stakeholders before implementation. You should avoid providing concrete timelines for your strategy and instead adopt maturity levels. Furthermore, consulting with potential vendors will help you determine a realistic budget. When the strategy is approved, the programs will have a definite timeline and fine-tune the budget.

We will conclude this series in the next article by discussing the remaining phases.

Previous
Previous

Developing Information Security Strategy: Discussing and concluding

Next
Next

Developing Information Security Strategy: Define your solutions