AI Security Board Report Template
AI security introduces new risks, but boards still expect clear, business-aligned answers. This free, editable board report template helps CISOs and security leaders communicate AI risk, posture, and priorities in a way the board understands, using real metrics, risk narratives, and strategic framing.
What this template helps you do:
- Frame AI security in business terms
- Highlight risk using clear metrics and KPIs
- Drive informed board-level decisions
Cloud Zero Trust and Secure Access Frameworks
Zero trust is arguably a mature concept, zero trust in the cloud is less so, mainly because the use of the cloud to host significant portions of our enterprise infrastructure has occurred on a more recent and accelerated timeline. We consider some of the key challenges of zero trust in the cloud and how to approach mitigating them.
We have written on many, many occasions on zero trust (ZT). This is no surprise because the approach continues to grow in popularity, with one recent vendor survey finding that 11% of respondents already use ZT, 23% plan to do so in the next year, while a further 46% are currently rolling it out. And knowing as we do that the concept of ZT has now been around for 15+ years, it is a mature idea too.
ZT in the cloud, though, is a much newer concept, as the use of the cloud to host significant portions of our enterprise infrastructure has spiked in recent years. For example, it took until 2020 for the cloud to become the hosting location of choice for 50%+ of corporate data. This will continue to grow, but there is a fundamental problem that still remains: there is a cloud skills gap. For example, the ISC2 Cybersecurity Workforce Study found that 34% of respondents see cloud data protection skills and essential, alongside needs such as least privilege access control implementation (33%) and identity-centric security (30%). Meanwhile 36% of respondents said their security teams needed cloud security skills, second to only AI. It seems fair, then, to extrapolate that to a presumption that ZT in the cloud is immature relative to on-premise implementations. So, what are the key challenges of ZT in the cloud and what we can do to mitigate them?
No More Hard Borders
The first novel concern when doing ZT in the cloud is that there is no longer a perimeter to our network. Our on-premise systems have two physical perimeters – the physical buildings they reside in, and the firewalls that connect the systems to the internet or to other organizations. The same cannot be said of the cloud – in fact by default everything in our cloud installations is potentially connected to the internet by default (and as we all know, it can be both straightforward and common to inadvertently expose cloud services to the public).
Second, and related to the first challenge, is connectivity into our systems. For public-facing systems nothing much changes, but our traditional virtual private network (VPN) connectivity that we have used for decades for remote access is not at all well suited to cloud operations.
Next, similarly associated with the complete lack of physical assets, is visibility of our systems. There is much to be said for being able to point at a physical server in a rack in a server room or data center. Even where we run our own virtual server infrastructure we still have that physical element to fall back on.
The fourth challenge, as we alluded to earlier, is knowledge. Cloud technology is, quite simply, different from the on-premise systems we have used for tens of years, but only a limited number of technical staff in the ISC2 study cited earlier were of the view that they had the training they required.
Transferrable Skills
These issues aside, though, there are far more similarities than differences when we compare on-premise systems with cloud. This means we can largely apply the same ZT approaches to our cloud installation as we do to our on-premise infrastructure.
Device validation comes next. (This is often referred to as “posture”, but “validation” is much closer to what we are really doing). This is all about ensuring that a device or system is only accessible, or able to gain access to something, if its security is adequate. For example: a current, supported operating system with patches up to date; current anti-malware software, again recently updated; your chosen endpoint detection and response (EDR) product. The cloud approach here does not need to be any different from on-premise, of course.
The same applies to micro segmentation: separating systems that do not need to interact with each other. Preferably, this would be done as separate network segments and subnets, separated by virtual firewalls, but if not then at least with their own built-in firewall technology configured to deny by default.
Similarly, monitoring. There may be some technologies you use in the cloud that perhaps were not being used in your legacy self-hosted systems (perhaps part of your motivation for shifting workloads to the cloud was, for instance, to move from a traditional server-based architecture to a new container-centric world). But overall, your monitoring setup will be very similar across all your technology stacks.
In the same vein, we have governance controls: everything discussed above is presumably implemented in accordance with your cybersecurity policies, procedures and standards. Again, while there might be some adjustments required in order to cater for the cloud elements, you will definitely not find yourself writing reams of new policies and discarding vast amounts of legacy security control concepts.
Off Site Does Not Mean Out of Sight
And let us go back for a moment and address a couple of the dissimilarities we mentioned earlier. While it’s true that a distant, fully virtualized service can be harder to keep track of than something in your own building, the task is not massively more difficult. A vendor’s administration and configuration tools can address that. Although engineers with years of experience of localized systems can still find themselves scrambling up a steep learning curve when systems move to the cloud, this is again a far from insurmountable task. Both of these concepts have associated risks, but they are manageable ones.
Connectivity
One major difference remains, though: how we connect to systems. We noted earlier that the traditional VPN is not the tool for the job for cloud ZT: as one vendor puts it, rather eloquently: “Traditional perimeter security works on the assumption that everything inside the network is trusted”. So, we need a new approach. One solution is session-based security: that is, every time a user device tries to access a service, that service re-authenticates it. It authenticates not just the user but also the device and its configuration: users should be authenticated against a centralized single sign-on (SSO) identity and access management (IAM) database, always using multi-factor authentication (MFA). Similarly, the user endpoints should be similarly registered and validated when they connect, generally via an agent app on the device. The normal approach is not, of course, to demand a login ID and MFA response every time a user clicks something, but to persist the identity through the lifetime of each session with each application (hence the term “session-based”) and then re-authenticate for the next session or app.
There is one final element to consider. As the statistics we cited earlier imply, very few organizations have shipped their entire technology and data inventory off-premise. It is more likely than not, then, that any ZT implementation on cloud services will in fact not be cloud-specific but will by hybrid. The alternative is to run two separate ZT implementations – but as we have just noted, there are such similarities and so few differences between self-hosted and externally hosted systems, that it makes perfect sense to have a single ZT security framework that spans both.
