Quite a lot has been written about the importance of due-diligence in a cloud environment. Sometimes the importance of security and compliance-related vetting in the cloud is easy to justify, like when you’re evaluating an off-premises public cloud hosted at a new service provider. Other times, executives might take some convincing, like when you’re talking about an internally maintained private cloud, before they see the value.
Either way though, most organizations that have gone through a cloud deployment — or organizations that are in the middle of one — have probably put some level of effort into due diligence to ensure that the data and services going to the cloud are appropriately secured. This can take different forms — onsite audits, questionnaires based on standardized resources (e.g., Cloud Security Alliance’s GRC stack, Shared Assessments’ SIG, FedRAMP), or numerous other types of evaluation.
Vetting a service provider’s capabilities when it comes to security or evaluating an internal team is obviously a useful first step, particularly in the case of highly-visible usage (think: your clients/customers see it) or when confidential or critical data is in scope.
However, sometimes the temptation is for organizations to view this as a “fire and forget” activity. They do it once at the beginning of the effort with the idea that they’ll revisit it at some future time, maybe a year down the road or maybe when the service provider’s contract comes up for renewal. However, this isn’t always an ideal strategy from a security standpoint. Organizations may not want to hear it, but it really is a good idea to continuously validate, revalidate and vet their service providers throughout the relationship. Why, you ask? Because the relationship an organization has with its service provider isn’t static, and neither are the service providers themselves.
Usage Changes
First and foremost, the way that your organization makes use of a cloud provider can change, sometimes without an explicit mandate from — or even knowledge of — the IT and security organizations. Consider as an example, an IaaS (Infrastructure as a Service) provider, either internal and on-prem or vendor-provided and off-prem.
During the evaluation and transition, you may have decided to virtualize and move certain systems but deliberately left others (maybe those that store client Social Security numbers) out of scope, either for security purposes or business purposes. After the move, what happens if someone decides to expand the scope to include this other class of devices as well? Keep in mind that for competitive reasons, service providers try to make it easy to migrate virtual hosts from their infrastructure to a competitor. They often provide tools for exactly this purpose — tools that a tech-savvy business user might be able to operate without IT involvement. A tech-savvy business user might also have the technical “chops” to conduct a physical to virtual move themselves.
Obviously, the scope of governance and due diligence you might choose to do for non-SSN data is very different from what you’d do when the data includes client SSNs. You may have, for example, made a cost decision not to perform an on-site audit because the data wasn’t personally identifiable. You may have chosen to evaluate only a subset of security functionality. But if those assumptions change? Well, all bets are off. It very often happens that service providers are evaluated according to their ability to supply functionality “A”, “B”, and “C.” And they subsequently get used in practice to provide “D” once their foot is in the door, especially once they’re on the “approved vendor” list.
Practices Change
The way that vendors and security teams perform certain security-relevant operations change as well. Just like this happens in your organization — for example, you decide to change security technology vendors — this happens at your service providers. If you’re using an external provider and you’ve gone through the due diligence process, chances are your contract stipulates they’ll inform you about major operational changes that they make to their service. But how many of the operational update bulletins providers send does your organization actually read in detail? How many of those bulletins make their way to the security team for them to subsequently pick through with a fine-toothed comb?
If you do vet a service provider and observe they have key technical security controls (e.g., IDS, anti-virus, audit logging) today, what happens if they decommission one of those controls? Does your contract require they tell you? Even if it does, is that notification one that somebody in the security, IT or compliance teams actually reviews and can act upon? The answer is not always “yes.”
Revisiting Technical and Non-technical Evaluations
This is why it is so important that your governance process (at the very least that for critical vendors) address continuous vetting and testing. It’s all well and good to start with a thorough review of the environment, but that’s only useful to the extent that the assumptions, and what you assessed during the review, stay current.
One strategy for doing this is to complete the thorough baseline assessment at the beginning of the relationship, perhaps an onsite assessment, and follow a questionnaire-based process at comparatively frequent intervals (say, quarterly) during the “bootstrapping” period of your cloud efforts — say the first year or so. It’s helpful to evaluate both the “vendor” side (be it an external vendor like a cloud services provider or an internal vendor like an on-prem private cloud) of the relationship by vetting them, but also at the same time vetting the business side for changes in usage.
A thorough evaluation at the beginning is good, but don’t waste that investment by failing to keep it current as time goes by.
Loading ...
