Most organizations are reliant upon hundreds or thousands of third-parties for products or services that are integral to their operation. Unfortunately most organizations do not do a good enough job of differentiating reliant versus RELIANT. Let’s put it in perspective:
If the cafeteria doesn’t get its shipment of ketchup in time for lunch – we may have some angry tater tot loving employees (until someone can run to ShopRite). While the lack of ketchup is a “risk”, perhaps even a probable risk, the impact to the business is low, and compensating for the risk or recovering from the risk is relatively simple.
On the contrary, if I’m running the sales force for Merck, and the cloud CRM solution we moved to has a major outage – we are going to have angry employees, customers and shareholders. The lack of CRM is a notable risk, and although it may not be probable, the impact to my organization could be catastrophic if the outage was extended. Compensating for the risk may be possible (if I understood the risk in advance and planned for it), but fully recovering from the risk will not be possible.
Got an interesting email this morning from a SAAS vendor we are considering using – a few of the excerpts so clearly communicated the risks (and the pain/impact of their realization) I had to share them:
“ Recently, however, we’ve had somewhat more serious outages that have affected a small number of our customers – and that illustrate the darker side of “Cloud dependence”. Basically, the problem was neither with “OurAPP” nor “TheirAPP” (an app we are totally reliant on for OurAPP to function) but with the internet hops between our customers and their servers. A broken or mis-configured router or firewall rule wouldn’t let those customers access TheirAPP servers. For most of our customers, OurAPP is a mission-critical application, so any downtime can be a real problem – especially at the wrong time. While our team was quickly able to establish that the cloud service was not down and that the client’s data was safe and intact, we found ourselves in a situation that as a solution provider we are not comfortable with: We couldn’t do anything about the problem. We had no control of putting our customer’s systems, which were running just fine, back in touch with their Cloud-served data, which was also running just fine. We were relying on others to correct the glitch in the customer’s pathway to their Cloud services. Naturally, as a Cloud solutions provider we knew that downtime could occur that we might not be directly in control of on behalf of our customers, but this additional level of vulnerability hit like a thunderbolt on several levels – not the least of which was the many hours we spent attempting to resolve the issue and provide alternatives …”
Fortunately, Vendor Risk Management does not have to be rocket science:
- Understand the risks associated with the proposed vendor. Take a “solution” view. Easiest way is generally to develop a Secure Data Flow Diagram that clearly identifies the information under consideration, and the processes that act on it.
- Analyze the risks and their business impact. Fundamental risk analysis requires garnering a basic understanding of the vulnerabilities, probabilities and impacts. In short, how probable is it that threat agents can act on vulnerabilities and what the impact would be.
- Ensure that you look at Sixth-Party Risk. Notable Third-Party cloud outages (e.g., Sales Force) were caused by their Third-Party outages (e.g., Amazon.). The easiest way to look at Sixth-Party Risk is to ask for the Third-Party’s Risk Assessment.
- Where residual risk associated with a Third-Party is not acceptable – determine whether you can implement compensating controls to reduce the risk to a level that is. If not, can I transfer it (to the vendor or an insurance company)?. If not, time to look for a new vendor.
- Determine how you are going to communicate your risks and security requirements and then SLA/monitor them on a go forward basis. In short you need to “operationalize” your Vendor Risk Management as part of putting it into place. ISO 27002 sections 6.2 and 10.2 do a great job of jump-starting this process.
This risk management based approach is core to operating an “Information Security Management System” (the fundamental tenet of ISO 27001). Without a comprehensive approach of this nature – you too may be sending out a “mea culpa” email to your stakeholders. Sadly, while it takes years to build a reputation it can only take minutes to destroy one.