CISO Best Practices Cheat Sheet: Cloud Edition
This guide is for CISOs and cloud security leaders who want to move beyond fire drills and dashboards.
Whether you’re inheriting a cloud program, scaling to multi-cloud maturity, or aligning with board priorities, this cheat sheet helps you cut through the noise, focus on measurable outcomes, and lead with clarity - all with practical frameworks and 90-day actionable steps.
Mitigating Cloud Denial of Service Incidents
The cloud can be just as useful to an attacker as it is to a legitimate organization. All the advantages that appeal to those of us who use the cloud in our day-to-day operations – scalability, value for money, high-speed connectivity, speed to market, automation – can also be leveraged by anyone who wants to use cloud services to attack us.
Denial of Service (DoS) is particularly well-suited to the cloud, because the two key ingredients required are in plentiful supply. The most impactful type of DoS is the Distributed Denial of Service (DDoS) attack: launching a coordinated, automated attack on a single organization from dozens or even hundreds of servers spread over cloud installations around the world gives the bad actor seemingly infinite amounts of bandwidth whilst giving the victim the challenge of trying to cut off an attack that is coming in from hundreds of directions at once.
There are, happily, plenty of tools we can use to mitigate the risk of DDoS.
Combating Cloud-Based DDoS
If we run on-premise systems the most effective approach we can take is to put them behind a cloud-based Web Application Firewall (WAF). It can feel slightly counter-intuitive to put an on-premise system behind a cloud-based barrier, as it is easy to worry that (for example) our services will slow down by having to take a detour through the WAF, but in reality, this is rarely a problem and the users seldom notice. It can also be argued that putting the defenses on your own systems limits effectiveness – it is a breeze for the attacker to saturate your internet connection and put you off-line with little effort.
The way to go these days, though, is to put our services in the cloud. This is not the place for us to shout out all the great technical reasons for moving to the cloud; we shall, however, look at the additional defense systems that are available once you have done so.
DDoS protection is, of course, pretty much standard across the big cloud providers and so step one is to ensure you have purchased that option and turned it on. As you are in the cloud you also have the potential to take the next step and employ Global Load Balancing (GLB). This works by enabling your services to be accessible via many different regions and, if you use the GLB offering from the cloud provider that hosts your services, you can spread the service across multiple regions and service each connection from the location closest to the user. This means your APAC clients might be served from the Australia region while your North America users hit the U.S. region and Europeans land in Amsterdam. A certain amount of cleverness is needed to make the back-end applications multi-region, but the performance benefits are worth it and from a DDoS point of view you are not putting everything you care about behind a single internet connection, making it a single target.
Design and Architecture is Key
There is only so much you can do, though, by simply turning on the service provider’s defenses and doing some clever multi-region architecture. It is easy to be complacent and assume that doing this will somehow protect you against anything bad, but that is not the case – it is still vital to design and architect your applications well and be meticulous with housekeeping and patching.
For example, consider whether you want your services to be accessible from anywhere. The chances are you do not have customers in North Korea or Russia due to current sanctions, so configure the filters to disallow connections from any countries that don’t have a legitimate reason to be knocking on your door. The rule of where to block is simple: as far away from your systems as possible – so on the WAF or the GLB – so that the traffic never stands the slightest chance of reaching your systems. If you have access to a database of IP ranges that are known to have been used by attackers, interface it into the WAF or GLB so that connections are blocked. While these might be legitimate organizations’ IP addresses and your management may be nervous about blocking connections from them, point out that they ceased to be legitimate when someone compromised them and that even if the attackers have been evicted, the systems’ owners need to earn back the trust of you and CISOs like you.
Similarly, be concerned about your patching regime. Any internet-facing system, even if you have limited inbound connectivity, faces being probed by a significant number of bad actors. The worst thing you can do is expose systems to the internet in the knowledge that you have unpatched, known vulnerabilities.
Minimize Outward Exposure
Next, while we are on internet-facing systems, work with your architects to find a way to minimize the number of internet-facing systems. Why put a web server in an internet-facing DMZ, for example? A better approach is to put a feature-poor cache server or reverse proxy facing the internet and hide the organization’s technology behind the firewall. Keep internet exposure to the absolute minimum, only enable essential capabilities that are required to run the applications. If you do have to expose business logic – for example if you provide API access to systems for your clients – do everything you can to require strong authentication and to limit the IP addresses from which they can be accessed. Even though we are in 2025 there is still no particularly robust way to secure an API, because unlike systems that are used by humans you don’t have the option of using things like Multi-Factor Authentication (MFA) to control and mitigate access requests.
Achieving all of the above will put you in a very positive position. It will make attacks sufficiently hard, helping to deter all but the most determined criminal. It will not, however, make you immune to an attack. We can only ever do cyber defense, not cyber protection or attack prevention. The average person thinks of words like “protect” and “prevent” (particularly “prevent”) as absolutes – that is, they keep out all intruders. But use the words “defend” or “defense” and people naturally understand these as doing a good job but exhibiting fallibility. Rather like the 40 points’ worth of fallible that the Kansas City Chiefs were on the evening of 9 February 2025, people “get” that defenses don’t have a guarantee.
So along with your defenses, it is important to ensure you are ready for someone to get through them, round them or over them.
Prepare For Threats
So, log judiciously and ensure you understand the tools that the service provider has given you for reading and analyzing them. Be particularly vigilant about attacks that your defense systems are batting off: just because the WAF dealt with an attack does not mean the attacker will not return using a different technique. Log in all the layers of defense: there is every chance that an attack might get through one or more of the outer layers and be thwarted by (say) the on-board firewall on a server, so enable yourself to find these so you can shore up the outer defenses and keep them out next time.
Most importantly, have a robust Incident Response Process (IRP): an organized team, a coherent plan that everyone understands and knows how to use, and documented and tested playbooks for dealing with likely scenarios. Doing so means that you can respond effectively and do everything you can to keep the downtime caused by an attack to a minimum. There is plenty we can do to mitigate the risk of cloud DoS attacks, but we can never become entirely immune to them.
