Designing a Cloud Security Strategy?
Well, at the end of the day, the goals are simple: safety and security -Jodi Rell
Having a good security strategy for your cloud workload is a must, not just a strategy but a good one.
Plenty of things to start with but let me just call out this one “ doesn’t matter whether you’re using @awscloud or @azure or @gcp or any multi-cloud approach is working out for you just fine, maybe you are still at a hybrid architecture.” one thing remains constant and that is How you’re planning on to deal with the threats out there.
People out there are blindly doing brute force attacks, DDoS attacks just on anything available, try launching an instance in the public subnet and you’ll get to see what I’m talking about here. Some organizations rush into the cloud and subject themselves to several issues by just considering the promise of cost reductions, operational efficiencies, and improved security (of the cloud), not in the cloud (this part has to be done by us, we are provided with many security services).
Having a strategy in place will also help you prevent overspending both time and money on cloud security controls. Now the question is how to get started with one. well here are a couple of things to look out for. Before anything else, I would highly recommend you to go through Cloud Security Alliance (CSA)’s Notorious Nine Cloud Threats
Getting Started
Now with things in order: I’m assuming you’re already been through the process of choosing a vendor who aligns with your demand and workload.
IAM — Identity and Access Management: let’s start with authentication and authorization. Writing strong IAM policies (resource-based, attribute-based, & role-based) will help you a great deal with the authorization part. Following the zero trust mantra with a combination of granular access with the least privilege principle. Keep track of your access keys (disabling them, rotating them periodically).
Now coming to Infrastructure ( to save time here we’ll include everything from instances in public or private subnets to Lamba functions or API gateways, CI/CDpipelines, Kubernetes clusters, or our CDN’s, also the storage of all kinds — block, bucket, databases literally everything that is not used for monitoring or alerting purpose.)
Start with reducing the surface area, use as much backbone network as you can for data to travel for example use vpc endpoints for internal communications. Make use of encryption for data in transit as well as at rest. Design policies to make sure data is not uploaded to let’s say buckets without encryption. For transition, use SSL/TLS(non-vulnerable versions) at load balancers, gateways, keep the database instances in private subnets using the best practice like only accepting data from application tier security group.
A layered Approach will provide maximum security kind of like a Chakravyuh. sorry for the reference :) but forming layers where request/data enters our cloud to the destination by making use of WAFs, NACL’s, security groups, and conditional access policies will have a great impact in making sure things are secure.
Logging and Monitoring Everything: each and everything that too centrally not much needs to be done, a couple of security services are provided for this purpose. Let’s say in the case of AWS, GuardDuty (infrastructure logs, all the API calls from cloud trail logs, vpc logs, DNS logs) everything will be ingested into GuardDuty for threat intelligence. Security Hub is another one for having all the findings from these kinds of services like macies, inspector, config et cetera in a single place. Sentinel in case of azure cloud.
Visibility into the cloud is much needed especially when the workload is big enough. A lot of third-party tools might help but built-in security capabilities of the cloud are somewhat lacking when comes to visibility as compared with third-party tools.
Security Posture Management: Lookout for misconfiguration, failed patches, run security assessments, and automated compliance monitoring. Remember: UseAutomation, will help a lot.
And the biggest attack vector Insider Threats — I guess this line will do here, “Trust but verify”, don’t neglect suspicions.
Tons of other things will need considerations like SSO’s, Backups, DR, DLP’s, MFA’s, strong password policies, establishing outer permission boundaries with SCP’s (ServiceControl Policies), and whatnot. The list is never-ending.
But this is it for now. #PeaceOut
