Don’t Keep Us in the Dark: Addressing the Cloud Change Management Gap
Published 12/14/2022
Sean Heide, Research Technical Director at CSA
Jez Goldstone, Director of Security Architecture, Cloud & Innovation | CSO Cyber Security Assurance at Barclays
Hillary Baron, Sr. Research Technical Director at CSA
John Yeoh, Global VP of Research at CSA
The innovation in cloud services and platforms is incredible as they introduce hundreds to thousands of new features every year. Yet the impact of each of these changes on customer environments and applications can often leave customers in the dark. In the past, change management in technology has been a somewhat chaotic process for in-house teams. It consisted of a trouble ticket of sorts, a review of the issue, a plan of action to address, and the potential impact on operations before a final sign-off would be provided to complete the work and push patching and updates. Now in our current state of cloud infrastructure, there has been a shift of responsibilities of ownership. A shift that can often create confusion for businesses when changes take place with little to no warning, or without a proper outline in place of the impacts of said changes. If we thought in-house was tough, we now have an entirely new beast to manage.
The risk here would be the potential security configurations that may inadvertently change in your ecosystem without you knowing because the Cloud Service Provider has pushed them out with limited warning, no warning, or without the customer being able to properly manage those changes under their own supervision or structure. This has forced teams to recognize that their once applied controls are no longer as effective due to the nature of the change within their environment.
Alongside industry partners, CSA has identified this as a potential change management gap in the enterprise world. If a business were able to identify changes to their cloud applications, infrastructure, or platform ahead of a scheduled release, or at minimum, the impact that said changes would create, security teams would be able to properly align their current risk portfolio and ensure that no change will override current settings. The ability to stop a break before it happens. The ability to know impacted systems. These are all things that we have heard as critical components to resolving a change management process in the cloud that is currently missing.
Potential resolutions to this however do not have to be daunting. In fact, with support from providers, the fix could bleed itself into an automated system that all customers could benefit from. No matter the size. One of these ideas is to incorporate a simplified structure using JSON formatting into the cloud providers themselves.
Example:
{"Service Impacted": ["eg S3"], "Class of Impact": ["Security","Cost","Behavior"], "Narrative": "Oops, I accidentally opened the whole thing", "URL":"https://blogpost.htm" "Setting":"GetObject", "Setting from":"None", "Setting to":"ANY", "NDA":["Yes","No"], "Date of release": <datetime>}
With a bit of input such as: the change detail, area of impact, does it impact all users, and lastly, will it impact current security controls in the environment, we can begin to receive output from the service provider on areas of changes. To simplify an example for this, think of the ability to login to your personal LinkedIn account from a Microsoft Exchange account, under the control of the business that you work for. Wouldn’t an employee’s ability to tie their personal information into a business account be something that you would want to know before applying? Certain frameworks have stated that this feature must be turned off to be compliant against their controls. If a change were to take place that automatically enables this, you can now assume you are not truly meeting preventive controls in your cloud environment.
We want to work towards identifying more of these concerns across the board and build a discussion with the cloud service providers to build an automated reporting format that can feed into customer systems to allow for a review of future changes and their impact. Rather than reading something lackluster in a blog or release document, we want customers to feel empowered with the information they are receiving on certain cloud changes and be allowed to review it well before a change takes place. This will allow the business and the security team to stay aligned for potential cross-department changes that would otherwise potentially fly under the radar.
CSA is actively researching this concept, and with additional input from you, the community can begin to build a broader use case that will help cement this discussion with vendors and cloud service providers. The goal is to note the problem and present it to CSPs in order to discover a way to best address a resolution for moving forward.
Let your voice be heard! In the meantime, we encourage readers to take this short survey so we have more starting data regarding change management and the concerns of those it impacts.
If you would like to help build out these use cases, please feel free to reach out to us at [email protected] to schedule a discussion.
Related Articles:
Texas Attorney General’s Landmark Victory Against Google
Published: 12/20/2024
How to Demystify Zero Trust for Non-Security Stakeholders
Published: 12/19/2024
Why Digital Pioneers are Adopting Zero Trust SD-WAN to Drive Modernization
Published: 12/19/2024
Managed Security Service Provider (MSSP): Everything You Need to Know
Published: 12/18/2024