Creating a 'Defensible' Cybersecurity ProgramTom Scholtz of Gartner Says Flexible, Executive-Endorsed Programs Succeed
Security teams want to avoid being dubbed the "business prevention department."
Yet Tom Scholtz, a Gartner analyst, says one of his European customers ruefully revealed two years ago that his team was slapped with that label. Scholtz, who spoke at the recent Gartner Security and Risk Management Summit in Sydney, says the label was the result of a security team not crafting an appropriate custom cybersecurity program.
"It's very difficult to convince people that you are governing your security program from a business perspective if the business does not have a seat [on the steering committee]."
"That's what you end up with when you are just focusing on ticking the boxes," Scholtz says. "You end up with this mistrust, the lack of support. That then feeds back to the executives. The executives are also worried if they're doing enough, and you end up with this vicious destructive cycle."
Instead, the security department should focus on creating a "defensible" cybersecurity program that demonstrates it has made the appropriate risk-based decisions and investments that also keep in mind business objectives, Scholtz says.
A defensible program allows a company board to go to its stakeholders and argue that it is doing the best that it possibly can do to mitigate risk, Scholtz says.
Charter, Reference Models
The effort, he says, should start with a cybersecurity charter - a brief document with no technology references that's written in plain language. It should be signed and endorsed by executive leadership, which gives the security department the mandate to move forward.
The charter should establish the owner accountability principle. That means the security of data doesn't ultimately rest with the CISO or the CIO but rather with those who control it.
That's important because it doesn't allow a data owner to shift the responsibility for a security failure up the chain. Without that, business people may try to use technology in ways that pose cybersecurity risks, Scholtz says.
"The only exception is when you have shared resources or shared information; then the CIO becomes the proxy owner," Scholtz says.
The next step is a reference model. Scholtz recommends that a cybersecurity program be rooted in a common taxonomical reference or standard, such as ISO 27001. Following an industry cybersecurity standard helps to contribute to defensibility, Scholtz says. But organizations don't need to wholesale adopt one to the letter.
By modelling a cybersecurity program on an industry standard, executives have a strong defensibility argument if things go wrong, Scholtz says. But the pendulum shouldn't swing too far, with the sole focus on merely complying with the standard.
"The reason that you need a standards-based framework from a defensibility perspective is because you use it as a reference model, not as your objective," Scholtz says. "The framework is a means to the end, not the end itself."
If possible, it is wise to keep the CISO independent from the CIO, Scoltz argues.
In fact, New York state's Cybersecurity Requirements for Financial Services Companies requires organizations over a certain size to have a CISO who is independent.
It's ideal to give the CISO a level of independence, Scholtz says (see: How to Comply With New York's Cybersecurity Regulation). That helps prevent the CIO from taking risks that may not be defensible, Scholtz says.
"It's not necessarily always practical that you have an environment where the CISO is outside of IT just from a scalability perspective or from a political perspective or from a maturity perspective," Scholtz says. "But in more and more organizations, you may well find more audit pressure to make that separation."
Business units also need to have input on the security steering committee to ensure that the security team is aligned with business goals.
"It's very difficult to convince people that you are governing your security program from a business perspective if the business does not have a seat [on the steering committee]," Scholtz says.
Dashboards or scorecards can be helpful for showing how security relates to the business and what the risk position is, Scholtz says. But implementing those takes time.
Progress reports for executive boards can be tricky, Scholtz says. Executives don't need day-to-day operational information. Providing too much information may get executives interested in granular details that they ultimately have no control over, he points out.
Scholtz's tips seem to offer a helpful start for setting up a cybersecurity program that supports business goals. But are they, indeed, practical? Let us know what you think.