adrian_ilie825 - Fotolia
How to build and maintain a multi-cloud security strategy
When using multiple cloud service providers, it's critical to consider your enterprise's cloud scope and the specifics of each cloud service to maintain security.
There are some things that, by nature, come in groups. For example, have you ever known a garden to have just one rabbit? Wherever there's one rabbit, it's a safe bet there's a warren full of them just out of view.
Enterprise cloud usage is the same way -- and it proliferates over time. Barring extraordinary circumstances, it's a veritable certainty that, given enough time, an enterprise will wind up with more than one cloud service provider within its scope. In fact, a typical organization might support multiple cloud models or services from the same vendor or use competing services from different vendors with different configuration options and settings for each.
There are a few reasons why this happens. In some organizations, leaders may explicitly decide to use multiple providers as part of a larger disaster recovery or business continuity strategy -- building in redundancy to help make sure that they can't be taken down if one service fails, for example.
It can also happen unintentionally. Consider mergers and acquisitions: If two companies merge, with one using cloud provider A and one using cloud provider B, what happens? Since it can be time-intensive and expensive to retroactively migrate entire environments at scale, the post-merger organization may well find itself maintaining both sets of services for an indeterminate period of time. This can also happen outside of mergers and acquisitions, such as when two business units within the same firm make different purchasing decisions. Also, don't discount shadow adoption as a driver for these situations.
Regardless of how it does come about, more organizations are now dealing with multi-cloud situations. Whether it's multiple services from the same vendor, e.g., an organization using one vendor's IaaS and PaaS; similar services from different vendors, e.g., two different IaaS providers; or a hodgepodge of both, this situation can be challenging from a security professional's point of view. Bear in mind that each provider -- and each service -- will have different security models, different tools for ensuring security, different configuration parameters, different dashboards and different contact points. Putting all these details together and creating a coherent multi-cloud security strategy is a must.
Determining cloud scope
As a practical matter, how can security teams best deal with this and ensure multi-cloud security? There are a few strategic options to consider, but the absolute first thing to do as a starting point is to get a handle on scope:
- How many providers are there?
- What are they used for and by whom?
- What, specifically, is being used?
The answers to these questions are important not only from a due diligence standpoint, but they will also provide the raw materials to understand the security-relevant cloud surface area of what is being used and what it's being used for. Keep in mind that this information is likely to change over time; just because a given service isn't being used right this second doesn't mean someone won't start using it 10 minutes from now.
Instead of doing a point-in-time inventory of services used, establish a process to keep the list updated regularly -- this can be completed opportunistically. For example, keep an eye out for cloud usage when doing business impact analysis for continuity planning. Completing an application assessment? Look for and record cloud usage. An internal audit? Record any incidences of cloud usage. If there are more services than are manageable to keep track of in a spreadsheet -- which is most likely the case in a large organization or if SaaS is also tracked -- an inventorying tool can be used. As each is recorded, keep track of a contact point that can be reached later to ask additional questions.
Putting a multi-cloud security strategy together
Once scope information is gathered, the next step is to get a handle on the specifics associated with each service.
At this point, some self-education is required about the specific security considerations and models for the services that have been identified. The specifics of this will vary depending on the services, but it's important to understand at both the technical level and the procedural level what is involved in and relevant to securing the service. This can include any additional tools that might help facilitate securing them, such as GuardDuty for AWS, Sentinel for Azure, logging specifics for SaaS systems and so forth. Fully understanding this may require gathering additional details from the organization's users about the services. This is why it's so important to document a contact point when identifying services in the first place.
It's also important to understand the overlap of operational duties germane to security -- i.e., what needs to be supplied versus what is supplied via tools or processes from the cloud provider. Sometimes, this will be explicitly documented; for example, Microsoft Azure and AWS document shared responsibilities and whether the provider or the customer is responsible for aspects of security operations and management. With smaller providers or SaaS offerings, these details will be less explicit, but they will still need to be accounted for in planning stages.
In addition, it's vital to understand the various tools available to assist. For example, IaaS providers may have sophisticated tools available for monitoring, while SaaS providers might provide only a minimal set of application, user activity or API logs. Keep in mind that, because there are multiple providers in scope, the tool set will be different between those providers. Provider A may provide access to different tools -- and via a different interface -- than provider B. More providers make this exercise more complicated, so putting a multi-cloud security strategy together ultimately means getting familiar with these options, mapping security goals against the areas of responsibility, identifying and putting into operation the tools and resources provided by the vendor, and identifying any areas that may still be not covered so they can be systematically addressed in subsequent planning.
