Building a shared risk model for secured cloud
- Posted on June 1, 2017
This is a guest blog post written by Avanade alum, Wayne Anderson.
As we see our enterprise clients embracing the public cloud, the benefits of efficiency, agility and speeding innovation are gratifying to see. Even years into the introduction of Microsoft Azure and other services to the enterprise, we continue to see challenges in understanding the extent to which information security is “entrusted” to these vendors.
The best of good news is that more companies my team and I work with recognize the shared responsibility between client and the cloud service provider (CSPs), such as Azure. Few clients, however, are readily able on day-one to define where their own security teams and functions correspond with those of a provider like Avanade in the overall delivered capability.
As Avanade’s director of Global Client Information Security, I see the same four themes that drive the overwhelming majority of cloud engagement security discussions we are having with clients.
1. Introducing the Shared Security Model
A small number of the clients I speak to each week need help in understanding and building a shared security model for protecting cloud transformation. As a result, they often lack the early planning for the areas where they must retain ownership in the public cloud – or have higher level of fear because of a perceived lack of control.
Basically, there are some things your cloud provider does, some things your implementation team does, and some things that you or your implementation partner will need to be able to do for you. As a company, you must make the strategic determination of how much of which security domains you entrust to the provider – and how you verify them.
Whomever you choose to partner with on your journey to cloud should not only to help you make the journey, but potentially to help with the design of the operations – even if those operations stay internal. Cloud requires effective operations that recognize the way the resources change, how they are purchased and how the resources are metered and used.
These kinds of partner relationships create further opportunities to “plug” model gaps and transfer – or share – deployment and operational risk for the organization. Additionally, it also requires a partnership agreement to the intended responsibility domains. This shared understanding enables us – or whomever your partner is – to reduce your overall transformation risk.
2. Security by Design
A second key element, approaching “security by design,” sometimes means extending analysis and design portions of project work to leverage security features of the cloud solution in your enterprise’s favor. Azure, for example, will secure the overall global cloud infrastructure and foundational services in the public cloud. A great example is Microsoft’s availability of a well-connected identity platform where Azure’s marketplace of hundreds of applications can be pre-integrated with Azure Active Directory (AD) for single sign-on capabilities.
Your enterprise, as the client, would need to design (or work with your implementation partner to design) from the start how they expect the organization to utilize Azure AD, and authenticate users connecting to Azure into a full unified identity structure. The underlying elements of complexity in federation, however, Microsoft has abstracted that in the former hosted world would require your organization to do advanced configuration, hardening and maintenance.
Your organization meets its required security context, maximizing the cloud benefit by designing the platform the right way from the start using the capabilities available.
3. Security by Delivery
Which brings us to a key part of the shared responsibility model – establishing security by delivery, where the experience of the consultancy together with your team can create a solution that reduces the amount of complexity your enterprise continues to own. In Avanade’s own example, our Digital Marketing services may be hosted on Azure, but Avanade can work during delivery to modify the implementation so network- and application-level controls lessen the security requirements for the client. Avanade also works with you to integrate encryption and authentication into our cloud solutions.
Your chosen implementation partner – together with your security team – will need to continuously work throughout the cycle of the cloud migration to define what the governing standards are, and ensure each component in the configuration and delivery process meets that governance model. That means defining them during the aforementioned design process earlier, implementing them during the build, and verifying them to meet the governance expectations.
4. Bottom Line
While Avanade – and Microsoft – can own some of the security elements, clients still need to secure their own customer data and content. The Azure environment, Azure Accounts, Access Controls and Network Configuration are all part of the “chain” that needs trust constructed at every level to produce a safe experience. We will continue working alongside our clients every day in advising, designing and delivering this transition – it doesn’t have to be hard or scary. Businesses face business risks in the threat landscape they operate within. Avanade partners with our clients to actively manage their information security risk to meet our clients risk appetite.
What is required is a deliberate approach and willingness to engage early in partnership and conversation around the security and privacy considerations of the business – so that these considerations can be incorporated into the project design and purchasing process (don’t wait until project delivery!). Performing these conversations early in the process allows Avanade to set the stage for your success and minimize risk.