<i>Tech Insight</i>: Finding Common Ground For Security, IT Teams

A Special Analysis for Dark Reading

Disagreements are a common occurrence between IT security and other IT groups, but nothing brings out their differences of opinion and practice like incident response or an emergency patch, such as Microsoft's fix this week for Internet Explorer.

A security team can butt heads with other IT groups for many reasons -- anything from personality conflicts and management styles to fundamental differences in opinion about how IT systems should be managed. A few key problem areas that come up regularly in organizations of all sizes are password policies, patch management, and network security with firewalls and VPNs.

Passwords are the weakest link as well as the biggest lightning rod: Users don't want complex, hard-to-remember passwords. Security wants passwords that are uncrackable. And systems admins don't want to be caught in the middle implementing a policy that results in users constantly complaining or needing regular password resets. The process of developing secure password policies almost always ends with none of the involved parties happy with the outcome.

Getting all groups on the same page about passwords usually requires a compromise all around, but several things can ease the pain of implementation. Educating users on the importance of passwords, along with tips and tricks on creating a secure password, is by far the cheapest method. Self-service portals for password resets, too, can help reduce the load on the help desk and sys admins after new password policies are put into effect.

In addition, multifactor authentication, if implemented properly and comprehensively, can reduce the reliance on a single, complex password and make it more difficult to crack. Multifactor authentication is typically something the user just has to stick in, or type a number off of, rather than recalling it every time they want access.

Patch management, meanwhile, borders the duties of both system administration and security. The logical place for this role is within the sys admin group, but it sometimes falls on the security team to implement it. Sys admins know the systems and are directly responsible for their well-being, while security must be constantly monitoring threats, vulnerabilities, and their mitigations. The blurring of responsibility here comes from the perception that patching is strictly security-related -- for resolving vulnerabilities. But it can also include nonsecurity bug fixes and feature enhancements.

Conflicts between security and IT about patch management tend to center around how soon to apply patches after they're released: Security groups want them applied immediately, while sys admins want to test for unexpected issues before deployment. The answer to this conflict is risk assessment -- assessing the threats, probability, and impact of successful exploitation. With the latest Internet Explorer zero-day patch, for example, desktop users who use the Internet for business purposes should patch immediately, while servers not used for Web browsing can get patched later, during a normal maintenance window.

Network management, firewall implementation, and IDS/IPS maintenance are all potential hornets' nests, too. In my experience, most of the hangups that IT operations and sys admin staff have with firewall and related network changes is that they don't truly understand networking. They know enough to get servers and clients working together, but it often ends there; their expertise lies in system, not network, management. When something goes wrong, recent network changes are the first to be blamed.

Resolving network change issues probably requires the most tact from the security group, because they must explain the changes in detail so that the sys admins, and sometimes the users, understand what is being done and why. Put egos aside and focus on technical details and facts. A quick presentation with diagrams is another way to help those affected understand the impact of the changes.

IT security doesn't have to be the bad guy when it comes to enforcing policies, pushing patch deployment, and making changes to the network infrastructure. Taking the time to explain why certain security measures are needed -- instead of simply insisting that something must be done -- will go a long way to keeping peace and fostering better interaction and cooperation with IT.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message