Handling Vulnerability of Network Security
Every security manager knows that no matter how comprehensive your vulnerability management processes are, your network’s security depends on cooperation between all stakeholders involved in the processes. All too often, IT teams push back against security requests, especially if they feel they are excessive or exaggerated. As a security manager, how do you handle this seemingly inevitable problem?
Overcoming Vulnerability Remediation Pushbacks
Although every company, just like every network is different, here are three general principles for reducing pushbacks about vulnerability remediation:
Have a clear SLA
A few paragraphs of clearly stated expectations are worth dozens of angry, frustrated emails. The best remedy against pushbacks is a clear inter-team agreement about how to respond to news of a vulnerability. Although we tend to think of SLAs as being agreed upon between a company and its customers, it makes sense to apply similar principles to an internal set of rules and responses. Who is responsible for notifying whom in case of a discovered breach? What is the procedure for dealing with theoretical breaches? Is there a way to let third parties report security problems with your website?
Working out these details will take some time and they won’t cover every contingency, but the process of creating and implementing such an SLA will in itself improve your company’s responses to vulnerabilities. It will also impose a de facto limit on the number of times IT is called in to solve problems, reducing IT’s feeling that they are always being asked to do extra work.
Build Trust by Not “Crying Wolf”
Be sure to prioritize vulnerabilities so that IT doesn’t end up being asked to take care of minor issues. People are more than willing to respond to genuine emergencies, but if “emergency” calls and texts get made too often, they’ll get ignored or resented.
It’s essential to use risk analysis when you decide which vulnerability to tackle first: you don’t need to fix every vulnerability announced in the media — focus on the issues that pose the most serious threat to your network. CVSS scores and other metrics are useful, but should only be one of the considerations when prioritizing, not as the sole factor. Use remediation methods that are easier to implement, such as changing configurations, rather than applying patches. Whenever possible, use automated solutions, which are more consistent and accurate as well as involving less tedious work for the people implementing them. By reducing the quantity of calls to IT and increasing their “quality,” you will go a long way to improving your company’s security and work environment.
A successful approach is not only about risk analysis – it’s also about triage and preventing false positives. Work with IT teams to have a good asset configuration inventory to make sure all vulnerabilities are applicable. The key here is to turn IT into your partners to make sure your data is accurate and to avoid wasting time filtering out false positives that obscure the real issues.
Be Sure You’re Speaking the Same Language
Language matters, so be sure you’re speaking the same language as IT and developers. To do this, first of all, be sure that discussions about security don’t turn into finger-pointing. Focus on problem-solving more than fixing blame, especially if the vulnerability is due to code written or approved by someone in the company. As HackerOne co-founder, Michiel Prins, notes, people get defensive when vulnerabilities are discovered, so combine diplomacy with your technical observations.
Second, be sure to speak IT’s language, focusing on what specifically needs to be done. Phrase requirements in a way that makes sense to the people who are actually going to implement them. Naturally, you might want to give some context to these instructions but keep it to a minimum. Moreover, try to present solutions that can be implemented using IT’s set of tools, rather than just submitting a list of problems.
Working Together for Better Vulnerability Remediation
Security doesn’t work in a silo. It’s crucial that organizations learn to work together to address the vulnerabilities that pose the highest risk. Reduce pushbacks by involving security, IT, and other stakeholders in creating an SLA that emphasizes risk-based analysis as the basis for setting remediation priorities. Build trust by showing restraint in your calls to IT — make sure you don’t ask for help with trivial issues. Finally, strive to meet IT team members on their own terms — speak their language in discussing and solutions. While these principles can’t guarantee an end to pushbacks, implementing them will make problems less frequent and less severe.
Click here to learn more about a vulnerability remediation platform based on these principles.