Part 1: Why Third-Party Risk Management?
Security awareness and preparation are getting more widespread. Corporate boards and C-suite executives are taking Third-Party Risk Management (TPRM) more seriously as they see what has happened to other enterprises in the not-so-distant past. I am speaking primarily of the top-level enterprises, but even smaller companies and less tech-oriented companies often have a hard time securing their infrastructure. If you are a widget supplier with a hundred employees, it’s hard—maybe impossible—to dedicate a full-time resource to things like patching, firewalls, identity and access management, and intrusion detection and incident response. The money just isn’t there.
Let’s say you store passwords to client accounts in a plain-text spreadsheet, which includes the account for the remote access widget you have installed at your biggest client. Your widget wasn’t built with the latest recommendations from OWASP and proves easy for malicious actors to access and manipulate. That widget becomes the entry point into a much larger and more desirable enterprise, which was otherwise well protected.
Obviously, this is a contrived scenario, but it’s not that outlandish. Your own IT doesn’t even need to be that involved. If a third party does data processing for you and they fall prey to a simple email-based attack, you could have equally serious consequences. To make it more complicated, third parties often have fourth parties, and you have even less control over them.
So, what is a conscientious security manager to do? Implement Third-Party Risk Management. At a high level, we do our due diligence on every vendor before we sign a contract, ensure that they guarantee to meet our security requirements, assess them regularly, and track remediation via our fully implemented GRC tool. Everyone has that all set up, right?
There are some messy realities. Not every vendor went through security due diligence, especially if your TPRM program was set up long after the vendor was onboarded. Tracking what the vendor actually does—so you can gauge its inherent risk to your enterprise—can be challenging in a large company. You may not have a contractual right to audit, and your tracker may be a spreadsheet.
To add to our challenge, there are usually multiple stakeholders in this process and they have different agendas. The TPRM process must account for all stakeholder needs and interests. Business needs and priorities frequently depart from those of InfoSec (at least in the short term). The business unit needs this vendor NOW—they have work to get done. Security must make sure that the vendor is secure, and that assessment takes time. It may even reveal that the vendor, which may be performing services already, has significant issues. If a business unit has millions of dollars at stake, and security is stepping on the brakes, there will be some difficult discussions and decisions.
Now we throw cloud vendors into the mix. NIST tells us many things about information security and provides invaluable references, including this definition of cloud computing: “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”1. What’s not in NIST (at least not directly): Fred in accounting can sign the enterprise up for an unvetted cloud service using a company credit card and start putting sensitive or regulated data into a misconfigured public cloud in just a few minutes, rapidly turning it into a “mission-critical” system. Apparently, those are the “on-demand network access” and “rapidly provisioned” aspects. It happens. In years past, it typically required some special knowledge and privileges to set up an external service. Today, you don’t need to be technical at all to create a shadow IT problem for your company. You might not even need a credit card if the service is free.
Using a cloud-based vendor has many advantages, which we won’t go into here. We do want to talk about some key differences between today’s cloud service providers, and the traditional vendors of old. One of the most significant is that you can acquire many cloud service providers, effectively immediately. This removes some significant controls from InfoSec’s arsenal such as the ability to consistently apply change control and configuration management. Now, you may have controls to catch such things after the fact, or even to prevent them—perhaps your firewall will block the service, or finance will catch a new subscription—but these are not universal. If your organization is large and decentralized, and your IT security controls are not as strong as they need to be, there will be a real possibility of a significant shadow IT issue via the cloud.
Additionally, you will generally lose the ability to negotiate a contract. The terms of service are what they are, and you can’t dictate security controls and responsibilities, especially to the larger services. It will be up to you to understand what the service does and does not do, what it enables you to do, and what additional controls you may need to build.
Reaching a point of contact with the technical team to deal with issues may also be a challenge. What if you have an incident originating in the cloud service provider? Who do you talk to or coordinate with? What if there’s an outage? Understand that you may be isolated in such cases, and may need to deal with such things independently.
You may also have a fourth party involved: the actual cloud hosting facility. The service may not have its own physical infrastructure; it may be on someone else’s cloud. In that case, how will you factor in that risk?
Another key issue: In the Stone Age of the internet, the paradigm was that if you really cared about the security of a data set, you did not connect it to the internet. That made a great deal of sense, given the many security weaknesses in internet protocols, operating systems, and applications. None of those exist anymore, right? Everything is totally secured, so we don’t need that paradigm… Well, no, a lot of those things still apply, but pretty much any data we really care about might be internet-accessible today. If you shared data with a legacy vendor, it was over a VPN or a private line. Now it’s over HTTPS. The reasoning underlying the paradigm hasn’t changed, but the circumstances and execution have. So, we need to take that into account.
Part 2: The Service
The specific security services you get from your cloud service provider will vary based on the type of service: Infrastructure as a Service (Iaas), Platform as a Service (Paas), or Software as a Service (Saas). At one end, IaaS gives you bare bones—they control the cloud fabric and infrastructure, and you get a bare virtual server. Security from the Operating System (OS) level on up is your responsibility. At the other end, SaaS gives you an application with limited ability to configure it. You will have control over things like access control, but much of the underlying security is the provider’s responsibility. Note that the categories may bleed into one another or, more specifically, a particular provider and its services may cross these lines. For instance, Microsoft Azure and Amazon Web Services offer IaaS, but also offer plenty of services that would fall into PaaS. The exact dividing lines are not critical. What is critical is to understand where the service your enterprise contracts for falls onto this spectrum, and to understand your security responsibilities as well as theirs. This demands a security architecture and design to document where the specific security controls lie, and what roles or software implement them. This is critical to determine up front as part of the vendor due diligence process. If you don’t know what your provider is doing, and you haven’t planned what you will need to do, it’s likely there will be a gap.
When we talk about understanding vendor risk, we are talking about an aspect of overall governance and risk management. In the cloud space, this is substantially the same as it is everywhere else. One important difference is in response management. When you have a traditional vendor, you can work with their InfoSec manager to set up protocols for incident response: phone numbers, email addresses, SLAs, etc. In some cases, you can get your traditional vendors to participate in drills. This will rarely be the case with a cloud vendor. If they have an outage or a security incident, you will typically be waiting for them to send out updates. The major exception here will be if they have an incident involving a breach and compromise of your data. In that case, there will be substantial interaction and the likelihood is that there has been no desktop exercise to game this out. Plan accordingly.
It should be obvious that we need to pay attention to the risk from our vendors. Security frameworks call for it explicitly. For instance, look at the NIST CyberSecurity Framework, under the ID.SC Category. In addition, most of the regulatory bodies we report to require it. Their language may be general or specific, but there’s little doubt that an enterprise of any size or complexity will need to show some regulatory body that they are effectively performing this function.
Ideally, there is a process to vet your vendors before you sign the contract. In addition to the usual business drivers—questions like: Does this vendor do what I need? What is their expertise? Can I work with their pricing?—there is also a need to understand the security controls they bring to the table. This needs to be defined in the contract. It’s a virtual guarantee—if they don’t say they’re doing it in the contract, they aren’t doing it.
Your specific contractual needs will vary based on your business, risk, and regulatory requirements. Some of these are documented in the 2015 FINRA Report on Cybersecurity Practices. These are basic and you may wish to add more. Again, referring to our earlier point, you may not be able to negotiate for all the security controls you want them to provide. Therefore, you may have to provide the control, do without the control, or find another provider. This is one of the most critical issues in dealing with the problem of Fred in accounting—he may have done an excellent job in determining what business functions were needed, but he probably didn’t do as great of a job in evaluating the security controls.
Part 3: Assessing Your Vendors
In conducting a Preliminary Vendor Risk Assessment, you need to know what data is flowing to the cloud, what is happening to it there, what data is flowing back to you, and what data may be flowing to fourth parties. This lets you establish a basic risk rating. This is not a full blown NIST 800-30 or FAIR Risk Assessment, it is a high-level rating based on a few key factors. For instance, any data flow involving PII or PHI is probably going to get your highest risk rating since a compromise of that data will trigger regulatory breach notification requirements and result in significant liability.
On an ongoing basis, you may then decide to modify that risk rating based on various mitigating factors. A key outcome of the due diligence exercise will be your ongoing risk treatment; specifically, how deep you intend to review the vendor. If the vendor is refilling your candy machines (cloud candy?), then the physical access is your main risk, and you aren’t likely to do a deep review of its IT infrastructure. On the other hand, if the vendor is receiving and processing PHI, possibly involving a fourth party, it will be getting your highest level of review—external certifications, onsite inspections, and penetration testing, for instance. Again, make sure this is in the contract before you sign.
Understanding where your data is, where it is going, what is happening to it, and what controls are applied at each stage are critical steps in understanding risk and are challenges for many companies. This can be a time-consuming process, often involving a lot of manual effort, and it doesn’t add to the bottom line or assist in daily operations. As a result, these controls are often missing or in need of remediation. Every new vendor onboarded should have an associated data flow, and every vendor risk assessment should strive to validate that the data elements mapped are still valid. Even when there is an initial data flow done, it may not ever be updated. Data elements, however, may be added, deleted, or modified over time. Even if this went through proper change control, it may not trickle back to the vendor risk processes.
This needs to be documented over the full set of vendors, and cloud providers in particular. In the absence of a controlled process, this may involve a multi-pronged discovery effort, including manual discovery from interviews with users, review of procurement records to identify ongoing payments to third parties, firewall traffic analysis, and, if you have one, use of a Cloud Access Security Broker, or CASB. The CASB is a vital tool in combatting shadow IT. Shadow IT’s main risk in the third-party risk arena is that it is difficult to be confident of your security if you do not know what goes where, and how it is secured. Identifying the data flows to the cloud and, just as importantly, putting teeth in the enforcement of your policies against this, is critical to getting this problem under control.
From a vendor risk standpoint, external certifications and audits are subject to a love/hate relationship. We love them because they provide us with an in-depth, objective, technical review of the third party’s security. We hate them because they do not always cover the scope we need them to cover, or they simply do not provide a complete picture of risk. A certification or clean audit report does not mean the enterprise is secure. What they do, of course, is provide a basic level of assurance that the vendor is trying really hard to be secure. These reports might be your best available resource for understanding a cloud provider’s risk—make sure you read it right.
Some key points to consider when reviewing the reports:
- Scope: Is the business stream and/or application listed in the scope included in the products or services provided by the vendor?
- Scope: Are all the products or services provided by the vendor in scope?
- Scope: Are all required regulatory requirements in the scope?
- Scope: Are the control categories adequately addressed?
- Scope: Are all vendor locations that provide the service/product in the scope?
- Scope: Are relevant sub-contractors included in the scope?
- Scope: Is the timeframe (when the audit was conducted) of the report/certification relevant/current?
- Type: Is the report the result of a point-in-time assessment or a review over a period of time?
- Applicability: Is the certification current and have mandated interim or surveillance audits been carried out?
- Auditor/Assessor: Internal or external audit? If external, conducted by a reputable company? If it is a certification, is it by an accredited organization?
In some cases where permitted by the contract, you may actually be able to do technical testing against the cloud vendor. That’s an unusual case, and it may be limited to your infrastructure only. In that case, it’s of limited value—you are really testing yourself or your client, not the provider. However, let’s assume that you do have a reasonable level of access, documented in the contracts with the provider, and with appropriate contracts between you and the client.
The likelihood (not the certainty) is that basic security hygiene has been taken care of. If not, the provider has probably already been owned and the problem is different. We are more interested in the configuration higher up the stack, at the application level. We will want to look at the proxies in front of the internet-facing apps: Can we even get to the application interface without valid credentials? What are the application-level issues? Are all of the OWASP Top 10 addressed? What about misconfigurations—did someone just forget to turn a service on or off, or put the wrong value in?
You can also use the contract to transfer some of the risk to the cloud provider. Naturally, the cloud provider will want to assume as little risk as possible. As an assessor, review the contracts to understand what, if any, risk they assume. If, as expected, the answer is “little or none,” then look to cybersecurity insurance policies. Again, it’s important to review these policies carefully. You need to make sure that the policy addresses appropriate risks and at a reasonable level. What defines appropriate and reasonable will vary drastically from company to company. It’s not a cookie cutter answer, and legal advice from your counsel is critical here.
Given all of the measures listed above, there will still be security gaps that the cloud provider cannot or will not address. Therefore, the client must have a way to deal with these. The client can implement internal controls intended to mitigate specific risks.
System isolation may be an option in some cases. If risky vendor systems are isolated on their own networks, with security boundaries between them and the general network, the risk can be reduced.
What about vendors processing the client’s data? If they are handling PHI, payroll, or other sensitive data, there’s not a lot that can be done in the way of internal controls or system isolation to mitigate the effects of a compromise of the third party. This falls back primarily to the pre-contract due diligence, the risk assessments, the contractual obligations, and whatever risk transference can be arranged.
When considering third-party risk, all of these aspects should be considered to understand the residual risk presented by the cloud provider.
Overall, we will need to modify the basic process for conducting a third-party risk assessment. We normally would start with the vendor answering questions, and us reviewing those answers. We know that we are unlikely to get a response here. When we review the vendor answers, we would probably identify issues with the responses, and have follow-up questions. If we didn’t get answers in the first place, we will not get this either. An onsite visit isn’t going to happen so we’re not going to get that physical security walkthrough, or gauge the depth of security from the responses we get in a live interview. That leaves us with little data to analyze and little to write about. So, the normal process isn’t going to cut it. What do we do?
We take the resources we have—the resources we have been talking about—and do our analysis based on those. Recognizing that our standard vendor assessment process is of limited use for a cloud vendor, we can still gather a great deal of data from sources such as external audits, certifications, breach databases, contract reviews, and other sources. Between all of these sources, I should be able to gauge the risk presented by a given cloud security vendor.
Of course, there’s an unstated risk here. If a cloud provider presents a significant risk, can we get them to change? If the risk is a core part of their business model, probably not. Will the client change? If the cloud service is now mission-critical, they may be unwilling to drop the service. This is the worst of all worlds. Risk management means taking steps to mitigate risk, and that may mean dropping a vendor. That can be a challenge, and as practitioners—switching from an assessor hat to an operator hat—we may need to look back to the risk mitigation page and build out additional controls. Where that’s not practical, pursuing documentation of the business’ risk acceptance may be the best we can get.
In conclusion, the new and evolving world of cloud services means that we need to reconsider and adapt our methods of assessing vendor risk. There are ways—from due diligence to ongoing reviews—but constant vigilance is the price to be paid.
1 SP 800-145, The NIST Definition of Cloud Computing