Challenges and Best Practices with Vulnerability Risk Management Collaboration

Last updated at Fri, 10 Jan 2020 14:30:40 GMT

Even in the most high-tech environments, remediation and risk reduction don’t just happen. In order for vulnerability risk management to work, it takes collaboration from technical and security teams across a broad array of initiatives.

Recently, we sat down with a panel of professionals who are on the front lines of VRM to discuss best practices, challenges, and their personal approaches to making vulnerability risk management a priority in their organizations.

First up, let’s introduce the webcast panel:

• Jonny Beggs, Security Operations Lead, Rapid7: As part of our internal security team, Jonny looks after all of Rapid7’s assets and works to create a secure environment to protect customer data.
• Kolby Allen, Platform Operations Architect, Zipwhip: Kolby’s team is in charge of all aspects of the Zipwhip business texting platform, including security.
• Kurt Hazel, IT Security Manager, Security Finance: Kurt’s job description encompasses managing everything under the infosec mantle for the personal loan organization, including DevelopmentOps and IT security.
• JC Polanycia, Security Engineer, Infor: As part of the architecture and tools team at the ERP cloud software company, JC works to choose the right security tools for his organization and ensure that teams are using them.

What remediation challenges have you faced when working with technical teams?

The panel agreed that competing objectives and priorities are the biggest challenges technical teams face when trying to remediate issues quickly and effectively. The top two ways to overcome this are to formalize agreements with teams by including additional context and making requests more actionable. Also, partnering with the development and engineering teams to ensure they have support from security helps ease the issue of competing priorities. Using the data that comes from remediation processes, the security team can engage in regular communication with technical teams to set up a precedent of problem-solving with the security team.

Defining the remediation process itself can also be a hurdle. How can a team break down the remediation process into sprints in an agile environment? A common solution is to unify teams against a common enemy or toward a common goal. Providing visibility is also important so that it’s not just a ticket coming from the security team; instead, the development and engineering teams are part of the process and can see the progress they’re making.

How do you influence technical teams to prioritize remediation efforts?

Once again, the panel members agreed that promoting organizational ownership over security is key to addressing remediation efforts expediently. If you can help your technical teams understand that security issues are as important as any other issues the organization faces, then remediation processes can integrate with other processes rather than being a side project or an afterthought. This ensures remediation is addressed quickly, which is key to reducing risk.

It’s also necessary to mitigate fears from team members. Intrusive scanning or other processes that may cause risk to the environment while trying to discover vulnerabilities can blindside team members and quickly turn the process into a blame game. However, if remediation and risk assessment is part of the everyday work cadence with proper service-level agreements (SLAs), team members will be much less afraid of having vulnerabilities discovered.

Defining simple priorities is also key to getting buy-in from technical teams. The panelists recommend partnering with system owners and remediation teams to create a vulnerability risk management model to get the basics down so teams know what to focus on. For instance, external-facing and customer assets should be prioritized over assets that only certain teams have access to. Teams can also leverage knowledge and expertise, not just from the internal team, but from vulnerability management tools and information that is available to the public.

How has InsightVM helped you to better collaborate with technical teams to drive risk reduction in your environment?

The panel agreed that InsightVM dashboards were an important part of collaboration within their organizations to increase visibility. Dashboards are especially key to executive team members.

InsightVM’s Goals and SLAs feature was also mentioned as a helpful tool able to provide extra context and level of urgency with system owners so teams can drill down and focus on the most important issues. Tagging and grouping assets are also helpful features to provide context and information to other teams. The ability to create a taxonomy that includes everything is important to reduce risk throughout the organization, especially in hybrid companies where there are both traditional onsite IT assets and cloud assets.

According to the panelists, the reports available through InsightVM are extremely important to being able to explain to the board and other stakeholders where the team is at and to create a timeline of remediation projects and vulnerabilities. Beyond giving organizational leaders insight into what the team is doing, the timeline actually buys system admins time to find windows to do the necessary remediation work.

For organizations too small to have a dedicated security team, InsightVM can provide a flexible solution that is easy for security and technical teams to use. While the dashboards are important for executive team members to gain an understanding of the security initiatives, the API on the backend of the tool can provide data directly to security teams in a way that allows them to get to work immediately. This flexibility around data presentation makes InsightVM invaluable to teams that want to stay agile while still addressing organizational buy-in.

What are some best practices to managing successful vulnerability risk management programs?

The panelists agreed that the current discussion around integrating security into the development pipeline has been a valuable guide to creating successful vulnerability risk management programs. Integrating security into the base of the organization helps the team ensure programs are secure from the beginning, rather than having to be retooled for security after they’ve already been built. If vulnerabilities are treated as any other type of event in the infrastructure and assigned a priority, engineering teams can address issues promptly as part of their regular process.

The panelists recommended engaging with engineering as early as possible when picking their VM tool and defining processes so that the security and vulnerability risk management processes are integral to the process, rather than an afterthought.

Visibility is also necessary for the simple fact that you can’t remediate what you don’t know about. And providing system owners and remediation teams a look into how the VRM program works, as well as a say in how it’s organized, allows everyone to avoid conflicts from the get-go.

Another best practice is using vulnerability risk management solutions to tell the story of remediation and security throughout the organization’s timeline, from legacy systems to the present, in order to help provide context for budgeting and planning for upcoming technical projects.

To hear the panelists’ perspectives, as well as what they’re focusing on in the future, listen to the full webcast here.