Building a healthy relationship between security and sysadmins

Far too often, the relationship between engineering and security departments at an organization is highly antagonistic. Both of these teams have the same set of overarching goals, so why is there such animosity here?

Below, I outline a few reasons why these two teams can butt heads and what we can all do to bridge the divide.

Assume good faith

When the security team comes to the systems engineering team with a new project, tool, or vulnerability, and the risk assessment is inappropriate, the need for respect cuts both ways. The systems engineering team must be willing to bring a documented dialog to the security team. Correspondingly, security teams must be willing to trust the technical expertise of their operational teams. They are the subject matter experts, and they live the infrastructure day in and day out. If there is some minutia of the environment that protects you from a certain vulnerability, or a tool will not work as expected in the environment, this must be taken into consideration.

Additionally, though, the security team did nothing wrong by raising what they did. They cannot be expected to be experts in every aspect of the organization. This give and take must come from both sides of the organization, with each focusing on what they do best and sharing information when necessary. When this is done respectfully, and with an assumption of good faith, we build healthy relationships across the organization.

Explain the "why"

The organization's engineering side is full of deeply curious folks who seek to understand how and why complex systems operate as they do. If the security team suppresses
or obfuscates the reasoning behind policies, procedures, or frameworks, willingly or unwillingly, this can be perceived as an unwillingness to cooperate. At worst, an engineering team will think that you do not trust them with the information.

Involve the engineering side in the planning sessions when building a compliance framework for the organization. Actively solicit input on policies and procedures. Explain why models like SOC2 or BSIMM are appropriate for the organization and what benefits they bring. By doing so, you can help demonstrate for the engineering side that these things are not being built in a vacuum, and they provide real value. The intellectual rigor of being challenged on your assumptions will help build a better security program, as those with a fresh, unbiased perspective may bring up issues with the program that you may not have ever considered.

[ You might also like: 3 best practices for working on a distributed team ]

Create theory out of practice

As a security department, you need to ensure that the policies and procedures you are bringing to the organization will bring tangible value. The most direct way to do this is to build out from the material conditions of your organization today. The industry is awash in frameworks, policies, procedures, models, standards, checklists, programs, guidelines, protocols, and principles that might be wildly inappropriate for the operational reality of your organization. Read these, know them, take inspiration from them, maybe even implement them one day, but understand that they are simply a variety of options that you can pull from, not the default option. You have the ability to build whatever security culture your organization needs to derive the best outcomes. If that means your policy will be highly flexible on who can approve a change management request, be flexible. Focus on the operational outcomes and not blind adherence to orthodoxy.

All one team

Everyone is working to keep the bad guys out, keep our systems up, and have a little fun along the way. Keep it light, and remember that we are all on the same team.

[ New research from HBR Analytic Services - IT talent strategy: New tactics for a new era ]