If your organization is like most, you know that cloud is here to stay. Even if your organization is new to cloud, as a security practitioner, you know that it’s not a matter of “if” but “when” key business processes will find themselves becoming increasingly more dependent on externally-hosted services and cloud technologies.
In fact, cloud is so useful – so powerful in its application, valuable to the business, and (let’s face it) intractable in today’s technology landscape – that most organizations find themselves in the position of having not only one cloud provider that is business-critical but multiple cloud environments that play a role. This can lead to some fairly steep challenges from a security point of view. How to do we ensure that security models are enforced across environments? How do we best protect resources so that they stay secure and resilient regardless of where they are fielded?
It is with these challenges in mind that ISACA has provided a new white paper, Managing Security Impacts in a Multicloud Environment, to highlight the risks, benefits and practical security approaches around “multicloud.” Multicloud, characterized by one organization employing multiple cloud environments simultaneously, can have significant impact from a security point of view. It can mean new risks – and potentially new opportunities as well (both business opportunities as well as opportunities to improve security posture.) The intent of the white paper is to give actionable information back to practitioners about how multicloud comes about, why it matters, how it can impact their security model, and what organizations can do about it.
With this in mind, let’s look in more detail at one of the techniques discussed in the white paper, that of discovery.
Cloud Discovery
It’s an old maxim in the security world that “you can’t manage what you don’t know.” You’ve likely heard this old saying enough that it’s become somewhat trite. However, it is demonstrably true when it comes to cloud usage.
There are numerous ways that multicloud can come about: shadow IT adoption, mergers/acquisitions, differences in capability offered by providers, cost, or numerous other facts. Often it can occur through a planned, purposeful strategy (for example as a continuity strategy, as a cost control measure, or for other reasons), but more commonly arises “organically” – meaning, it wasn’t planned that way but instead just “grew.”
Either way, one very important part of securing that cloud usage is discovering that it exists in the first place. This is where discovery techniques come in.
The white paper outlines discovery strategies as part of your data-gathering toolkit as part of informing your multicloud security strategy. There are numerous strategies you might employ to find and document cloud providers in use in the organization. However, three have worked particularly well for me: systematic canvassing of business teams (ideally in parallel with another activity), establishing communications with procurement/accounts payable and partnership between technical security teams and technology audit.
The first item, systematic canvassing, refers to going out and asking business teams (and/or peer technology organizations) what cloud services they use and for what. Ordinarily, this would be time-consuming and a boat-ton of work. However, opportunities can arise to help make the process easier (for example, if you are engaging already for other reasons). Consider business impact analysis (BIA) for business continuity planning activities. In a nutshell, this involves going out to business teams and supporting technology organizations, and asking them about what applications they employ. You can incorporate a data-gathering step to ask those teams about their use of cloud technologies. This helps you identify where you might be using cloud services that you wouldn’t otherwise know about. It’s not just BIA though; any situation that involves close interactions with a large subset of the organization can help you do this, too. Activities like application threat modeling, security architecture planning, compliance-driven activities like creating data flow diagrams supporting PCI compliance, and other activities where you’d be out collecting information anyway can give you a useful opportunity to ask about, and document, cloud usage.
Secondly, direct and purposeful communication with provisioning, sourcing, or accounts payable can help here. It’s a fact of life that for any service we use, someone has to “pay the piper.” Therefore, somebody, somewhere is keeping a record of each and every cloud-related bill that comes in to the organization. This means that, were you to do a little digging and ask the right questions, you can establish a data-gathering mechanism about cloud usage via a communication channel with this part of the organization. At its simplest, this just means having someone give you a head’s up about known and approved cloud relationships (for example, maybe telling you the monthly charges to allow you to look for increasing usage or outlier expenses) as well as new charges incurred related to new providers you might not know about. It’s not perfect by any means, but it can clue you in to changes in usage (since cloud billing is typically “on demand,” which is often reflected in the amount your organization is charged), as well as new usage.
Lastly, consider partnerships between technology teams and internal audit (technology audit if this exists at your organization.) As many ISACA members know, internal audit teams interact with many different parts of the business as part of the execution of their annual audit plans. This means that they get “up close and personal” with portions of the business that technology-focused security teams might never have a chance to learn about in depth. Establishing a healthy working relationship between the two teams is a good idea anyway, but for security practitioners, this relationship can yield tremendous dividends for learning about new cloud usage within business teams. A useful strategy here is for the relationship to be bi-directional: perhaps providing technical expertise to the audit team or assistance with evidence collection, and in return leveraging information gleaned from the audit team to help find and catalog cloud usage.
The important part here is that you not only just capture that there’s usage but that you collect meta-data about it: who is the point of contact, what is the usage for, what business areas does it service, what data is stored there, etc. As you gather this information, fold the information that you find into a broader multicloud strategy. Remember that you not only want to find and identify cloud relationships at a given point in time, but also as part of an ongoing, continuous process.
