Rifts between the security team and other groups lead to inefficiency and reduced effectiveness. Information security isn’t getting as much done as is necessary in our breach-of-the-day world, yet old problems like failure to collaborate persist.

Man in the mirror

Rifts between the security team and other groups lead to inefficiency and reduced effectiveness. Information security isn’t getting as much done as is necessary in our breach-of-the-day world, yet old problems like failure to collaborate persist. One of the most harmful of these disconnected relationships is the one between security and operations teams. Seemingly, operations should be a team with which security finds commonalities; both groups, theoretically, aim for smoothly-functioning systems, which not only means users can accomplish job tasks easily, but that the users are protected while doing so.

Nonetheless, security and operations teams discover themselves regularly at odds. Each group feels the other hinders its goals, and as a result, arguments flare. In extreme situations, opposing groups refuse to collaborate or communicate unless absolutely necessary. The divide is pervasive and well known, but most organizations merely acknowledge the truth, refusing to budge.

I’m gonna make a change, for once in my life

Antagonistic relationships don’t aid any situation, and often what is needed is just a slight shift in attitude for two people or groups to realize shared goals. At DerbyCon 2016 during a Stable Talk, Craig Bowser presented on “Security v. Operations: Bridging the Gap,” in which he talked about ways security and ops teams can come together. With both sides “harboring mutual disrespect,” he said, the organization is hurt by lack of cooperation. Too frequently, security is blaming and yelling at ops teams when an alert is triggered or an incident is declared, and so it’s up to security to extend the first olive branch.

Bowser explained that two underlying issues contribute to some of the infighting: Foundational and technical issues. The foundational issues, he said, are:

  • Bad staff structures
  • Groups over-siloed
  • Lack of coordination
  • Ingrained resentment and friction

Much of the above can be attributed to poor leadership, but “leadership” doesn’t necessarily mean the C-level person in charge. Anyone can be a leader; all it takes is a willingness to bring together and inspire people. Still, doing so is difficult (though not impossible) when staff structure is fractured. When operations reports into one manager and security to another, the managers needs to make a concerted effort to form that dotted line to one another and encourage cooperation between teammates on a regular basis. Not every issue has to “go to the top” for a resolution, and in fact, fewer issues are bound to escalate to the top if cooperation at a lower level occurs regularly.

It’s gonna feel real good

Management needs to align goals, policies, and procedures. Organizations can’t have either uptime and efficiency or security; it needs to be both. Two sets of incident response plans cannot exist; operations and security need to be on the same page before an incident happens. Teams can’t be wondering to whom they should report when an alert is triggered; decision-making authority needs to be determined and communicated clearly. Working across functional areas to communicate and gain acceptance for these goals is management’s job but can be facilitated by every person on the team. Communication is an ongoing process and no organization on the planet is free of communication breakdowns. Just as security wouldn’t implement a SIEM or firewall and set-it-and-forget-it, so too must be the approach to communication and coordination with operations.

Gonna make a difference

Technical issues are also an impediment to security and ops cooperation, said Bowser. At the heart of the technical issues, however, is good communication across groups. Patching and configuration is one such example. Security might run a scan and find software requiring a patch. More likely than not, security instructs operations to “get on it,” without much explanation beyond, “all systems need to be up to date on patches.” In the operations team’s mind, the patch may or may not be critical, and updating could break configuration management. Before ops can explain this to security, though, security is typically out the door, already looking for some other system problem.

To remediate this type of exchange—which leaves both sides angry and certainly doesn’t make operations want to rush to execute what’s being barked at them—Bowser recommends prioritizing patches for ops teams based on criticality and likelihood of the vulnerability, and engaging with them (preferably prior to making a request) to find fix suggestions to common problems. For sure, conversations will revolve about technical solutions—and both sides may not entirely agree on the technical solution—but the key is the communication. Security and operations have a significantly greater chance of working more effectively and getting things done when cross-team collaboration exists.

Gonna make it right

Another scenario presented in the session was the deployment of new applications. As a security practitioner, how often are you made aware of new implementations by the ops team ahead of time? Seventy percent? Fifty, maybe? Operations’ strategy is “deploy now,” in an effort to meet customer and business demands. Security, when it learns about applications after the fact, wants to slow the process, checking for vulnerabilities, ensuring the app doesn’t do something that puts the business or its users at risk. Both goals are integral; neither is “better” than the other, but the result of the two ostensibly opposing goals is resentment and halted progress. The same is true when security is driving implements of new tools and processes without alerting operations.

To remediate these types of technical stalemates, the recommended tactic—for both sides—is to involve the other team early. Ensure communication is flowing bi-directionally and teams have time to prepare. Preparation and voicing concerns doesn’t mean that either side can slow down the other if/when a timeline is inflexible, but giving the “head’s up” eliminates a lot of consternation and may even introduce new considerations that may affect the outcome of the project…in a positive way.

When possible, build and use test beds for phased implementation, too. Doing so requires communication and agreement. Security can’t demand operations use a test bed; operations has to buy in to the idea. What better way to win friends and influence people than to be nicer and work more collaboratively? Take time to understand the problems operations is trying to solve, and offer to explain to operations security’s biggest challenges.

No message could have been any clearer

Teams don’t have to agree on a solution 100% of the time, nor is it reasonable to expect that security will get its way all of the time once improved communication is fostered. The key is genuine communication and honest effort to understand the operations point of view. “Humble communication will bridge hostility,” said Bowser, and reduced friction will certainly free up time for more productivity and enable focus on issues that matter.