Among the many challenges and complexities that a CISO must navigate, ensuring alignment of security operations with overall business objectives is a common one. That's the power of context, understanding, and empathy.
We can likely all recall times when new technology was rolled out before gaining a full understanding of the risks it exposed—the “implement first, and figure out the risks later” approach. The inescapable truth is that risks are intrinsic to business outcomes. A solution is only as valuable as the information it produces. Tamper with that information or bring down the solution, and the business outcome will collapse. And, too often organizations realize this after implementation, when risk treatment options have become limited and, as a CISO, you’re left picking up the pieces. The recently released F5 and Ponemon report, “The Evolving Role of CISOs and their Importance to the Business,” unearthed some disconcerting results around how well aligned CISOs believe their security operations are with business objectives.
Surprisingly, this survey also found that 58 percent of CISOs say they treat security as a standalone function and almost half of those polled say security has no clearly defined lines of responsibility in their organization.
If security isn’t aligned with the objectives of the organization, then does the security program exist in its own silo?
This raises a question: if security isn’t aligned with the objectives of the organization, then does the security program exist in its own silo? If that’s the case, how much traction do you think a security program will get? Security has to exist in context, and that context is the organization’s objectives.
It seems clear that performing risk analysis with the business and operational groups is valuable not only for performing due diligence required by regulatory and industry associations, but also for helping leadership understand risk and the different ways to deal with it. But why are so few CISOs following through?
Maybe one reason so many security programs aren’t aligning is that, according to the same survey, only 16 percent of CISOs have a business background (Figure 2). If you’re struggling to align your security program with the business, here are some things you can do.
Understanding the Business of Your Organization Matters
To build a security program that aligns with organizational objectives, you first have to understand the business of the organization. How? By asking questions and doing your homework—not just about your organization but about your industry sector, too.
You need to clearly understand your organization’s reason for existing. That means knowing the answers to the following questions:
• What’s unique about your organization?
• Who are your customers? (Even non-profit and government agencies have customers—that includes anyone your organization serves as part of its mission.)
• Who does the organization serve?
• Who are the biggest customers and what do they want? What do they expect?
• Who are the key partners? What do they expect?
• How does your business compare in all of these aspects to others in your industry sector?
• What’s unique about your organization?
• Who are your customers? (Even non-profit and government agencies have customers—that includes anyone your organization serves as part of its mission.)
• Who does the organization serve?
• Who are the biggest customers and what do they want? What do they expect?
• Who are the key partners? What do they expect?
• How does your business compare in all of these aspects to others in your industry sector?
THE INESCAPABLE TRUTH IS THAT RISKS ARE INTRINSIC TO BUSINESS OUTCOMES. A SOLUTION IS ONLY AS VALUABLE AS THE INFORMATION IT PRODUCES.
The next step is to understand how revenue flows into, and out of, your organization. Is it constant, cyclical, or tied to sales? How does it lose revenue? Are there cash reserves for rainy days?
How do you prioritize what you protect?
From there, you need to determine what assets need the most protection. What does the organization want to keep secret? What parts must never be tampered with? (Hint: this should always include the financial systems.) What functions must always keep running? Is it critical that the website is always up? What do employees need to do their jobs? What information do they need; what systems? What happens if they don’t get those things? Also, what regulations must the organization abide by? What critical contracts must be fulfilled?
WHAT DOES YOUR ORGANIZATION WANT TO KEEP SECRET? WHAT PARTS MUST NEVER BE TAMPERED WITH?
Next, be sure you understand the biggest challenges the organization faces. Is it growth? Survival? New markets? Changing regulations? Competition? Shrinking customer base? Shrinking budget? What are the major organizational processes? How does the organization circulate information internally? What physical locations does the organization use? Not just the offices and factories, but warehouses, offsite storage facilities, parking lots, and rented temporary offices. What technology is in use now? In the past? Planned for later? What problem is each of them intended to solve? Are they working effectively? Do they need to be upgraded or replaced?
Now that you’ve done your homework, you can use this information to get buy-in on risk reduction programs. Remember that when a security incident occurs, it can have many different kinds of impacts: loss of customer confidence, reduction in sales advantage, regulator fines, operational overhead, and loss of competitive advantage due to breached trade secrets. Find the hot buttons and push them. Gene Kim, co-founder of Tripwire, wrote a great example of how he would have framed an IT failure as a business risk.
“ From what we can tell, we experienced a complex and cascading failure in the critical technology systems that run these incredibly important business processes. The accident last week was not due to a power failure, or an IT failure—this was a business failure. After all, we were unable to perform some of our most critical business operations for nearly three days.”
And if you’re not in the position to best manage the amount of risk involved or want to offload some of that responsibility, consider risk transfer opportunities. This can involve buying an insurance policy to help compensate the business in case of an exploit or other compromise to the system. It can also involve contracts that transfer the risk to another party. However, this does require you to obtain an accurate picture of the total cost of your potential exposure to ensure the impact is acceptably transferred.
If You Want People to Listen to You, Listen to Them
A key to building cooperation is to develop the skill of empathetic listening to engage your ears before you start hammering on your message.
Listen to people’s complaints. Users work in different contexts than IT and security. They have work that needs to get done that has nothing to do with your security policies. Listen carefully to their problems and then, once they’ve had their say, you can connect their jobs to the security mission.
Put Security Processes in Context
To break down barriers and silos, you’ll need to align users’ daily practices with security. Hopefully, your examination of organizational processes and goals gives you the information you need to do this. It also helps you frame your security messages in the language of the organization’s culture, not in terms of security culture. In fact, this leads to a key part of making this work: give people relatable reasons for your security processes.
FRAME YOUR SECURITY MESSAGES IN THE LANGUAGE OF THE ORGANIZATION’S CULTURE, NOT IN TERMS OF SECURITY CULTURE.
Talk About What You’re Trying to Prevent, Why, and How. By using that institutional knowledge you’ve gathered, you can explain why you’re putting these particular security processes in place. Be specific and detailed about what you’re trying to prevent from happening, and clarify how the process will control it. This will also help get people on your side when a process doesn’t work perfectly. For example, if you explain that customer social security numbers should always be encrypted, then users can let you know when they see them displayed in plain view. This way you can quickly zero in on security incidents and fix problems.
Another big motivator is explaining how security incidents directly affect the organization’s ability to function and meet its business objective. We’ve discussed this before: measuring risk in terms of the loss of operational efficiency and business capability.³ This is a powerful technique, as long as you have a strong grasp on what the organization cares about.