Getting to the bottom of the top 5 vendor risk management best practices
Outsourcing the work doesn’t mean outsourcing the risk. Consider these vendor risk management best practices to build a secure and successful partnership.
We cannot enter into alliances until we are acquainted with the designs of our neighbors.
–Sun Tzu
Opening this post with an Art of War quote may seem a bit cliché. At the same time, it really hits the nail on the head when discussing vendor risk management. After all, the best way to manage risk is to keep everything in-house by generating everything internally. The problem with this approach is that there’s too much to do. You’ll most likely have to rely on external vendors to develop code, store data, or provide services. While it may feel like you’re offloading risk with this responsibility, your business is still on the hook in the event that they fail.
While you may not be able to drive security in a vendor’s organization like you can in your own, there are still measures your business can take to minimize its exposure. Let’s dig into the top vendor risk management best practices:
1. You can’t make risk management a priority to the vendor until you prioritize it in your firm.
Before you go shopping for a new home for your data, evaluate the criticality of the data and applications you’re going to host off-site. Factor in the business uses for the data. Additionally, calculate the value that would be lost if it weren’t available or in the event of a leak. When outsourcing source code that is run in-house, perform the same calculations.
Identify potential threats of all kinds and factor those into the risk calculations. If you don’t know what’s at stake, you can’t assume that your partner will know either.
2. Anticipate problems before they become problems.
When negotiating a contract with a third-party, the contract needs to anticipate problems before they affect your organization. If you’re negotiating with a cloud host, clarify the security responsibilities of both the host and your organization. For instance, the host should be responsible for uptime of the platform. Meanwhile, your organization should be responsible for patching the operating system and application. Assigning clear roles from the beginning ensures that the ball won’t be dropped due to unclear expectations.
When outsourcing source code, anticipate the types of security vulnerabilities that may be present in an application. Ensure they aren’t present by requiring source code reviews, dynamic scans, and external third-party penetration tests. Even if your organization isn’t responsible for an application’s design, you may still be able to perform or require a threat model or architecture risk analysis for the application. Even if your organization doesn’t run the tests, you should be able to set test criteria for approval.
3. Get the vendor on board.
The vendor is your partner. They have just as much stake as you do in this. If they aren’t interested in security, motivate them or find a partner who is. It may be enough for a development team to follow the letter of the contract when developing applications. However, to truly secure software and applications, developers should embrace security as a priority.
If your organization provides coding guidelines, best practices, and training to the vendor, the odds of creating insecure applications drop considerably. Empowering vendors to be an equal partner in security motivates them to rise to the challenge.
4. Trust but verify.
Even the best developers have blind spots. Relying on self-attestation when it comes to security can lead to problems. Most vendors allow for their clients to arrange third-party assessments. Set early expectations for source code scans by an impartial third party. Thus, developers can anticipate it and can also build bug fixes into their schedules.
If you can’t scan the source code for some reason, it’s a great practice to perform a DAST assessment on any application that you will host in-house or that stores your data. Build something along the lines of “Acceptance of the product or service is contingent upon appropriate security testing” into the contract. Any reasonable vendor should accept this. Those who don’t may not be an ideal security partner.
5. Create a partnership for the ages.
Software vulnerabilities don’t stop being vulnerable after delivery. It’s key to have a plan in place to fix vulnerabilities upon their discovery. Negotiate a timeframe and determine who is responsible for patching security vulnerabilities before an application or service goes live. Additionally, strategize incident response plans and disaster recovery plans before an application or service goes live. Once it’s live, make sure that monitoring and vulnerability management practices are in place. Some applications may have continuous support. Others may warrant on-demand patches. Simply accepting a piece of software and discontinuing the relationship upon delivery is security heartburn waiting to happen.
Summing it up
Outsourcing the work doesn’t mean outsourcing the risk. To build a secure and successful partnership:
- Know what you’re trusting the partnership with.
- Anticipate problems so you can plan for them.
- Bring the vendor into security discussions.
- Verify security as much as possible.
Just because you can’t control the actions of your third-party vendors doesn’t mean you can’t control the risk associated with the partnership. Don’t let risk stroll through the front door.
