The business-security disconnect that won't die

For years businesses have talked about how important security is to their customers and to the success of their business. However, with so many breaches in so many different industries, it's tough to take organizations at their word.

For years, many security managers and chief information security officers have talked about how the "business" side of the house doesn't understand security, or take what the IT security team has to say about risk seriously.

Somewhere, clearly, there is a disconnect.

Related: Talk the walk

"The IT security profession is always looking for ways to get into the requirements and design phases of a new application or initiative," says the security manager at a large regional health care services provider. "But we're often not brought to the table until the actual initiation of the project," he says. "Unfortunately, by then, there's little we can do because the architectural standards are gospel in the requirements. Also, there's little that can be done at that stage to improve security design without increasing costs tremendously."

Our discussions with CISOs, operations team members and other IT members support the security manager's assertions: security tends to remain consistently a step behind business operations in many organizations. "Often, when we bring IT security into the system design functions, all we hear from security are roadblocks about why things can't be done securely," says the enterprise architect at a global engineering services firm. "They're often overly technical, way too early in the discussion, when talking to the business side," he says.

Related: The new CISO: How the role has changed in five years

And there lies the all-too-common friction between business managers, IT operations, and IT security. The disconnect forces security groups to take the hapless position of having to "bolt on" security controls well after a new initiative is underway. That's a much harder and more expensive thing to do. "The earlier we are part of the discussion, the better and more secure the initiative," he says.

Other security managers cite times when application development teams purposefully shunned security guidance for as long as possible, in an attempt to push their guidance so late into the process that it becomes irrelevant. Few IT security professionals talk about positive relations among security, development, and other business groups within the early stages of an architectural discussion.

Can't beat 'em, join 'emThe challenge for security teams is to become an integral part of the discussion. "Before you talk about technical specifications or the risks of a new initiative you need to have something else in place first," says Mike Rothman, analyst with the security research firm Securosis. "That 'something else' that must be in place is 'credibility.' It all starts with building relationships, getting face time with business managers."

Brian Honan, founder of Dublin, Ireland-based information security consultancy BH Consulting and founder and lead of Ireland's first Computer Emergency Response Team, agrees: "You want to have steady contact with the business and establish those relationships," Honan says. "So when the time comes, you are not some strange guy who suddenly appears from the back office that nobody has seen before."

That credibility and rapport goes a long way when it comes to getting oneself heard at critical moments. "You also have to consider yourself as working within the industry that your company operates -- and not just as a security person," Honan adds. "Only this way can you build a risk profile that the company needs, and speak in ways that the business leaders understand."

Also, one of the most common ways security professionals rifle their good standing is by persistently throwing up roadblocks, and claiming initiatives can't be done because of the risks. "Explain to business leadership the risks that do exist with projects, and the costs to mitigate those risks," says Honan. "Let the business decide if they are risks it wants to take, avoid completely, or mitigate."

"It's about saying "Yes, but" instead of saying "no freaking way," adds Rothman. Risks need to be articulated to the business so that they understand the benefits of deploying an application or platform a certain way, verses what could go wrong. "Show them the real-world risks of doing it in an insecure way. Use clippings and recent examples or demonstrations to make your point," says Rothman. "The important thing is to talk in business terms, not in security jargon," he says.

"If you are just throwing up roadblocks to people, the organization will find ways to go around you," Rothman says. "If you want to be in the discussion early -- when you can affect real security change on the final outcome -- you have to relate to the business first, and then explain risk on their terms," he says.

George V. Hulme writes about security and technology from his home in Minneapolis. You can also find him tweeting lots of security jargon on Twitter @georgevhulme.

Read more about executive communication in CSOonline's Executive Communication section.