Changing Approach: Essential for Cloud Zero Trust

n

nn

n

nWhat We Mean by Zero Trust (ZT)?n

n

nSecurity vendor Crowdstrike puts it rather nicely, describing it as an“security framework requiring all users, whether in or outside thenorganization’s network (such as in the cloud), to be authenticated,nauthorized, and continuously validated for security configuration andnposture before being granted or keeping access to applications andndata”. In short: assume nothing, trust nothing and nobody.n

n

nIf you’re thinking: surely that’s the same as the Principle of LeastnPrivilege (PoLP) … well, not quite – it’s actually a lot more. The PoLPnis all about granting the right access capabilities to each user andnsystem once they’re logged in; ZT is the layer on top that both: (a)ndecides whether access is even granted in the first place; and (b)nchecks regularly during the session to see whether access shouldncontinue.n

n

nWhen dealing with cloud services, this is of particular use due to thenphysical off-siting of the application, often reducing visibility andnreal-time awareness of what might be happening.n

n

nLet’s take a real-life example from the banking world – thennSWIFTnntransaction interchange co-operative. SWIFT has a comprehensive set ofnsecurity requirements – the 132-page Customer Security ControlsnFramework, or CSCF – and each bank has to attest annually that they’rencompliant with all the mandatory requirements it contains. Each year newnthings are added. In 2023, the new mandatory requirement was all aboutnnetwork segmentation and ensuring people can’t access the securenSWIFT-connected part of the network from other parts of theninfrastructure.n

n

nTo quote the requirement: “A separated secure zone safeguards thencustomer’s infrastructure used for external connectivity from externalnenvironments and compromises or attacks on the broader enterprisenenvironment”. And this is, of course, what ZT is all about – defendingnone part of your infrastructure from attack in the event of another partnbeing compromised. For the average organization a non-trivial amount ofnsystem change and ongoing oversight will be needed in order to comply.n

n

nTo the team running the systems, ZT is a gargantuan job creation schemenand can bring massive inconvenience. The utopia for a system manager isnthe ability to manage all infrastructure, on and off-premise, though ansingle platform (or, more usually, a manageable number of platforms).nIt’s great, for instance, to have a central monitoring system to keep anneye on all systems and generate alerts when something goes down or isnperforming sub-optimally. That’s actually not a huge problem in a ZTnworld because if all you’re doing is monitoring (that is, the softwarenjust has read-only rights to the infrastructure) then the risk isnmodest. The issue comes when you want to be able to make changes from ancentral point: a single management platform becomes a single point ofnfailure and a super-convenient way for an intruder to damage the entireninfrastructure in the event of a compromise. In order to inconveniencenthe bad actors, you have to inconvenience yourself. You should alreadynhave production, pre-production, test and development systems segregatednfrom each other, and these should take into account internal andnexternal software services as well. ZT adds a whole new level and makesnyou do further separation within each of those environments so that ifn(say) a bad actor compromises the finance system, they can’t jump offnonto the email system, the file server, and so on.n

n

nCan We Automate or Use AI to Lighten the Load?

n

In truth, not really!n

n

nThe problem is simple: the moment we let a machine decide whether tonallow access to something, we’ve broken our model. One might try tonargue that the decisions we make on allowing access to something arenbased on reasoning: when one resource (human or computer) requestsnaccess to something, we follow a process of reasoning to decide whethernthis should be allowed.n

n

nIf the new starter in Accounts Payable requests access to the financensystem, we logically deduce that this is a sensible thing to grant andngo ahead and give them it. But that’s outside the realms of AI – that’snjust basic Role Based Access Control (RBAC). Letting a machine reasonnfor itself whether a user asking for access to X should be given thatnaccess because they already have access to A, B and C is asking forntrouble. Yes, we can automate stuff, but only in a very basic sense – bynimplementing an RBAC approach where we define the rules and implement ansystem that grants and revokes access based on them … and even then, wenstill have a job on our hands to define those rules and configure themninto the provisioning systems.n

n