<i>Tech Insight</i>: Finding Common Ground For Security, IT Teams<i>Tech Insight</i>: Finding Common Ground For Security, IT Teams
Tips for security and IT teams to better cooperate on hot-button issues of password policies, patch management, and network security
December 19, 2008
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
About the Author(s)
You May Also Like
How to Combat the Latest Cloud Security ThreatsNov 06, 2023
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and PhishingNov 01, 2023
SecOps & DevSecOps in the CloudNov 06, 2023
What's In Your Cloud?Nov 30, 2023
Everything You Need to Know About DNS AttacksNov 30, 2023
9 Traits You Need to Succeed as a Cybersecurity Leader
The Ultimate Guide to the CISSP
Protecting Critical Infrastructure: The 2021 Energy, Utilities, and Industrials Cyber Threat Landscape Report
Building Immunity: The 2021 Healthcare and Pharmaceutical Industry Cyber Threat Landscape Report
The Rise of Extended Detection & Response