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-4  to familiarize yourself with the design thinking process that we will be following for the rest of the series. 

In the previous article, we concluded our discussion of the IDENTIFY phase. To recap, the purpose of the IDENTIFY stage is to speak with your organization’s internal stakeholders to determine what factors should be considered as you build your strategy (and its associated processes). In this article, we will outline the next step: the ANALYZE phase.

The goals of the ANALYZE phase are to:

• Consolidate information from the IDENTIFY phase

• Begin defining the InfoSec program objectives  

• Describe the problem statements, 

• Identify problem patterns

• Gain sufficient insight to define the strategy

Consolidate information from the IDENTIFY phase

In this phase, you need to consolidate the information you have gathered in the IDENTIFY phase and shape your strategy. The information you have collected is unstructured of nature, and hence, there is no single format to follow. Instead, you may have to go through some of the techniques we have detailed below to make the information useful. The first step is to determine the context for the analysis.

Determining the context for the analysis

The context of your analysis during this phase will depend on your reasons for developing an InfoSec program. Some typical rationales include:

Regulatory compliance mandate - If your industry is regulated, your strategy will need to comply with the associated requirements. As such, your analysis will likely focus on the areas of breach identification and disclosure.

Past breaches - If past breaches are your primary reason for organization, your analysis should focus on vulnerability management, network security, and threat intelligence.

Board-initiated - If your board of directors initiated the InfoSec strategy, it’s likely your scope will be quite broad, and therefore your analysis may be too. It’s common in this case that the involved security professionals will want to develop an ambitious strategy. 

Customer concerns - If your organization handles customer data, you should prioritize analyzing the information you’ve collected about data protection and privacy.

Additionally, If your organization has previous or existing security programs, you can look at these for further insight. However, keep in mind that old strategies may have been developed in silos or be otherwise lacking (otherwise, you probably wouldn’t be developing a new one!).  

Defining the objectives

Once you know the context you should consider when analyzing the collected data, you need to define the objectives. The chances are that you have already defined some objectives by this point. If that is the case, you will just need to fine-tune them using the data you have collected.

Even though your InfoSec strategy isn’t external-facing, your program’s objectives must be aligned with your overall business goals and strategy. Hence, you will need to look at your interview data to define them.

The rationale for implementing a new security program will provide you with objectives that the board of directors will find relevant. The problem statements you collected during the IDENTIFY phase will be beneficial as well. 

Combining your interview data with your pre-established context will enable you to determine your InfoSec program objectives.

Once you have identified these objectives, be sure to compare them with any initial objectives you may have had when you began working on your InfoSec strategy. Your updated objectives will often align poorly with older ones, but that shouldn’t be a point of concern. Initial objectives are usually vague or ambitious. In comparison, objectives at this stage are based on data. Having this data should make it easy for you to justify significant changes to the board of directors.

Defining the problem statements

Creating problem statements and linking them to the objectives will help you clarify the objectives, the problems that must be addressed, and the niche problems that can be ignored or addressed later. You will use the customer jobs and pain areas from your customer profile canvas sheets to create these statements. 

For example, by analyzing the stakeholder requirements you collected from a Finance Director or CFO (see Part 1 for the Customer Profile Canvas methodology), you might end up with a problem statement similar to the one below:

Sharing information with external parties without the means to secure the information poses a security threat.

Your problem statements should be well-defined and of clear concerns and pain areas. You must also remember to refrain from providing solutions to problems in the ANALYZE phase, which will be addressed in the DEFINE phase.

Once you have written the problem statements, you need to compare them with the program’s objectives and eliminate any that are not well aligned.

Note that the statements in Figure 03 do not provide IT solutions. They simply state the problems the security program should address. Most of the problem statements have technical solutions that are managed by IT. Although your objective is not to offer IT solutions to the business, finding where most of the problems reside will help you discuss solutions with IT. 

Identify problem patterns

Once you have mapped out your problem statements, it is time to look for problem patterns. This is done by highlighting keywords and phrases.

Based on Figure 03, your problem patterns would look something like this:

The table in Figure 04 highlights the critical aspects of the problem statements. These highlighted words will give you the clues you need to design a security strategy draft. In the above example, the clear pattern is that there are prevalent concerns regarding confidentiality and information integrity.  As such, When you start putting together the draft for your security strategy in the DEFINE phase, you would know that classifying, monitoring, and controlling access is a  priority.

Gain sufficient insight to define the strategy

Using the above techniques we have discussed, you will gain sufficient insight to define the strategy. However, your analysis should not be limited to the only techniques we have discussed here. The context you have established for the analysis should guide this phase to define problem statements and patterns used to define solutions. If regulatory compliance is essential to achieve, you should conduct a gap analysis between your current security practices and the compliance framework to come up with the problem statements to address in this strategy. 

Conclusion

During the ANALYZE phase, you must be familiar with your organization’s rationale for implementing an InfoSec strategy — it’s this context that will enable you to focus on the right areas and to refine your objectives. Using the IDENTIFY phase data, you should create problem statements that clearly outline the security concern your internal stakeholders are facing. These problems will help identify critical issues that your InfoSec strategy should address.