Vulnerability Management Can Work Across Multiple Enterprises

[Excerpted from "Sharing Is Daring: Multi-Enterprise Vulnerability Management Strategies," a new report published today in Dark Reading's Database Security Tech Center.]

Conducting a thorough, comprehensive vulnerability management assessment is tough enough when there's only one enterprise involved. But what about testing for vulnerabilities in a supply chain or group of interdependent organizations, where security may be essential to multiple enterprises?

That's the subject of a new report, "Sharing is Daring: Multi-Enterprise Vulnerability Management Strategies," posted today by Dark Reading. The report offers a look at the vulnerability management process when it runs across more than one organization.

In a supply-chain environment, the possibility of introducing vulnerabilities is even higher than in a single enterprise. For example, issues the business faces in terms of internal collaboration are exponentially more difficult when reaching beyond the firewall and working with partners, contractors, and clients.

The report outlines three steps toward building a vulnerability management process among a group of enteprises. The first step is to understand and document the legal and contract issues between the partners.

When it comes to the implementation details a partner must provide in order for the security team to effectively run a vulnerability management program, CISOs must start communicating with legal more than they do now. We see an almost stunning lack of collaboration here, even though the legal group can be your best ally when it comes to talking about risk management with a potential partner.

The second step is to establish clear lines of communication among the partners. First, ask your key contact who will be responsible for returning the information you request, such as details about remediation, vulnerabilities, and access to new policies. Get the specific person's name, phone number, e-mail address, and mailing address.

Next, ask who will be empowered from the partner organization to make decisions. Typically, the partner will say it is the same as the security point of contact mentioned above, but that is almost never the case. You want to have direct access to the person, or team, who can authorize the release of what may be deemed sensitive information, escalate issues if the main security point of contact is not returning information promptly, and make decisions during times of outages or breaches.

Once the legal and communication lines are drawn, you can get down to the technical issues. During your initial kick-off meeting, describe exactly how you perform your automated testing. Give detailed descriptions of the types of vulnerabilities you're looking for, stress that you do not actively exploit the vulnerabilities (unless you do), and ask for a list of the servers you will scan, ranked by risk. State that this list will then be segmented and scans will occur against these servers in a rotating fashion, every other week, month, or other period you choose.

This approach does a couple of things. First, it sets the expectations of your organization up front -- you want to scan the most vulnerable/highest value servers as often as possible. Second, it allows you to lower the risk of bringing an entire operation down because you don't scan all of the servers all of the time. Your segmentation will reduce the risk to only a certain subset. Also, since you provided escalation and contact information previously, they can rest assured if an issue does arise, then a process is in place to resolve it.

To get the details on these multi-enterprise vulnerability management processes, including statistics on how enterprises handle contractor security, download the report.

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