Maybe you are new to the cloud or cloud security, no worries, my intent here is to help share some ideas and guidance for beginners.
Attack surface, and asset and service inventories
Depending on where you are with your overall cloud journey, this exercise may take a bit longer, but generally, the end goal here is to better understand and have greater visibility into your attack surface.
It is really helpful to start generating a list or inventory of the various native cloud services, and other third-party services and tools that are used throughout your cloud environments and accounts. Here we also want to think about what specific apps or services you have deployed within the cloud. This may include such things as APIs, VPNs, containers, server less, database servers, web/file servers, or simple object storage using AWS S3.
Start thinking about the how, from where using what in terms of how both you or your teams access your cloud accounts, or other resources and services. The why portion was likely completed above when you created lists and inventories, but if not it's okay, you can still complete that now.
A Threat Actors View
When we think about our cloud environments, compared to what we have on-prem for example, I think we can draw some threat parallels between the two. After all, if I am running an MSSQL database server on-prem or in the cloud, the potential threats and or potential vulnerabilities targeting the MSSQL server are the same, are they not?
External threats
-Accounts
-Zero-day
-malware
Internal threats
-Misconfigurations
-Compliance and regulations
-Insiders
Vulnerabilities and Misconfigurations
Again, depending on where you are on your own cloud journey, this can be something that starts out relatively simple. However, over time as systems, code, features, and functionality evolve, the challenges around patching, updates, and upgrades start to increase rather quickly.
Leveraging more automation, such as setting up recurring vulnerability scans to regularly scan your web applications, source code, configurations, IaC scripts and templates, and other infrastructure endpoints (internal and external) becomes really important. The automation piece becomes paramount as these scans are never a one and done, they are reoccurring. Depending on the environment, there could be one or many assets to scan, make sure you scan stage and production for sure, but even better is to simply scan everything you have budgeted for, that way you aren't leaving something unscanned, which in turn creates gaps and potential for some undue risk. Another really important aspect of the feedback loop from the scans is to have clear visibility into what is vulnerable, compared to what is exploitable. Having a clear picture of what's exploitable within your environments, can help to prioritize resources and set clear objectives for what needs attention now, and what can be addressed later and tracked using a backlog.
When we talk about scans and automation, for example, the topic of tools inevitably surfaces. For me, there isn't a single tool in our cyber toolbox that can solve everything. Instead, it should be thought of more as there are various tools, strategies, and solutions that when properly bundled together become a viable solution. As an example, AWS offers many different native security services and products, but those native security products alone aren't always the entire solution, they become part of what goes into delivering or achieving some object or goal. Perhaps that goal is to earn or retain a customer or a new project or another piece of business. Maybe the goal or objective is to meet and maintain SOC 2 compliance.
Top comments (0)