As organizations plan to move workloads and applications into the cloud, they encounter a fundamental problem. The security controls and practices they’ve built for their on-premises environments aren’t quite what they’ll need in the cloud, where everything is software-based and deeply integrated. So, how do they move past this problem? Cloud migration strategies have been around from a while, but what about security best practices during migration?
Cloud environments experience — at a high level — the same threats as traditional data center environments; the threat picture is the same. That is, cloud computing runs software, software has vulnerabilities, and adversaries try to exploit those vulnerabilities. However, unlike information technology systems in a traditional data center, in cloud computing, responsibility for mitigating the risks that result from these software vulnerabilities is shared between the CSP and the cloud consumer. As a result, consumers must understand the division of responsibilities and trust that the CSP meets their responsibilities.
1. Self service increases risk:
CSPs make it very easy to provision new services. The on-demand self-service provisioning features of the cloud enable an organization’s personnel to provision additional services from the agency’s CSP without IT consent.Due to the lower costs and ease of implementing PaaS and SaaS products, the probability of unauthorized use of cloud services increases. The use of unauthorized cloud services could result in an increase in malware infections or data exfiltration since the organization is unable to protect resources it does not know about. The use of unauthorized cloud services also decreases an organization’s visibility and control of its network and data.
The solution to this to have a organization controls on cloud to only allow approved services and settings. On Azure a org policy can do this. Similarly most cloud providers have this feature to limit services, but often times companies do not set it and this creates a risk with anyone able to spin off any services with any specifications. You can also limit to images you want developers to use for VM creation.
2. Internet accessible API’s
APIs can contain the same software vulnerabilities as an API for an operating system, library, etc. Unlike management APIs for on-premises computing, CSP APIs are accessible via the Internet exposing them more broadly to potential exploitation. Developers need to follow security best practices for API.
3. RACI is not clear
Oftentimes cloud is assumed to be secure as CSP is responsible to many aspects which were done by IT on the On premise servers. There needs to be a review of shared responsibility matrix on various cloud resources. Processes need to be defined to cater to these. Some could be quarterly patches, monthly patches, sometimes secure settings need to by design.
4. Decommission of services
There is a need to tighten the cloud decommission processes when a resource is no longer needed. After migration to cloud I have seen where data from on premise is left on public buckets( used while migration) and forgotten about. If a threat actor gets access to this data, there is high risk of data loss. So, clearly defined decommission process for resources no longer needed after migration has to be included in the overall plan.
5. Increased complexity create security loopholes
Migrating to the cloud can introduce complexity into IT operations. Key management and encryption services become more complex in the cloud. The services, techniques, and tools available to log and monitor cloud services typically vary across CSPs, further increasing complexity. There may also be emergent threats/risks in hybrid cloud implementations due to technology, policies, and implementation methods, which add complexity. This added complexity leads to an increased potential for security gaps in an agency’s cloud and on-premises implementations. I have seen developers push back on best practices like key rotation , password rotation due to the complexity. Oftentimes, organizations just use default encryption( which is good enough), but forget that providers like AWS do not have platform encryption on EC2 unlike on Azure and GCP VM’s.
6. Risk due to supply chain
If the CSP outsources parts of its infrastructure, operations, or maintenance, these third parties may not satisfy/support the requirements that the CSP is contracted to provide with an organization. An organization needs to evaluate how the CSP enforces compliance and check to see if the CSP flows its own requirements down to third parties. This increases threat on an organization . While the new CISA mandate on SBOM’s is good to see, it is still just a list and nothing is actionable. Hence, a robust vendor management is needed. But, oftentimes those are checklists of questions and not based on data. Maybe SBOM’s data with existing vulnerability is something to work on.
7. Missing Disaster recovery plan
Cloud is not perfect, there could be data loss due to insufficient DR plan. A clearly defined plan for DR, backup, recovery plan is a must before going live. This cannot be pushed as an afterthought, but a mandatory item to be defined and tested. The association of disaster recovery is mostly thought to be a process for uninterrupted business. But its crucial in considering and checking how much data loss a company can risk.
Some aspects of security remain the sole responsibility of the consumer. Effective cloud security depends on knowing and meeting all consumer responsibilities. Consumers’ failure to understand or meet their responsibilities is a leading cause of security incidents in cloud-based systems.