InfoSecurity Professional INSIGHTS Newsletter

InfoSecurity Professional INSIGHTS is our bi-monthly e-newsletter, associated with our members-only digital publication, InfoSecurity Professional. Similar to the magazine, it will deliver timely, compelling content written with the professional development of infosecurity practitioners in mind.

June InfoSecurity Professional INSIGHTS

Who Should Have Control in a Zero Trust Environment

By Dave Cartwright, CISSP

Implementing a Zero Trust approach in your organization is just one part of a far greater operational and cultural challenge. Overcoming change and a perceived loss of control must also be considered and addressed, as Dave Cartwright, CISSP, explains.

---

When recently discussing the impact of adopting a Zero Trust approach to security in our organizations, I arrived at a curious conclusion: that one of the biggest business impacts resulting from moving to a Zero Trust (“ZT”) regime is the perceived disempowerment of middle management.

If this sounds odd, let me explain. Unless you have a well-established system of Role Based Access Control (RBAC), in which there’s a clearly defined set of access permissions for every job in the business, the traditional approach to provisioning system access is: Step One – raise a ticket to request access; Step Two – get the user’s line manager to approve the request; and Step Three – provision access accordingly.

The Traditional Approach Is Broken
The problem is that if we think about it carefully, Step Two makes no sense at all, security-wise. Yes, it makes sense to have some kind of sense-check when a user requests access to something. In most other cases, it’s someone’s manager who gives permission for something to happen – vacation requests, expense claims, and so on. Unfortunately, what’s happened over the years is that “line manager approval” has been taken as the default approach for pretty much everything, and this has led us to an unfortunate position, security-wise.

This correspondent is CISO for a bank, and my line manager is the CTO. Would he understand the security implications of approving my access request to something? Yes, he would. But he’s in the minority – the average line manager simply doesn’t have sufficient knowledge or understanding of the security impact of approving someone’s access request. Incidentally, please don’t think for a moment that I have a negative opinion of line managers, far from it in fact. I am one, after all. However, just as the Finance team wouldn’t ask me to check and approve the annual accounts, because I don’t have the required knowledge, neither is it sensible in the average case for a line manager to make significant access or other security decisions.

Should we instead forward access requests to the security team? No. Unless the organization uses the aforementioned RBAC regime, the security team will, more often than not, have limited knowledge of the implication of granting an access request.

Who Should Decide?
The right person to make the decision on who should have access to a system is the business owner of that system. The right person to make the decision on who should have access to a data set is the business owner of that data set. After all, if you’re accountable for the existence and day-to-day use of a system or data repository, it’s not really fair for anyone else to be making decisions on who can use it. Of course, this brings a complication: many organizations don’t have the concept of a “business owner” for systems or data. After all, it’s the IT department who run the system (and, of course, it’s perceived to be IT’s fault if it breaks down, even if the issue was user error). So, all of a sudden, if we want to introduce a Zero Trust operating model, we have to completely re-model the ownership model of the applications we run.

Is this a bad thing? Yes and no. The downside is that very few of our colleagues “in the business” (by which we mean non-IT people) have any spare time alongside their day job that they can use to carry out this extra system- or data-ownership role. If they had, we might have previously moved the ownership onto them (or maybe we already tried in the past and it didn’t happen because of time pressures). The upside, though, is vast: if the person who’s accountable for the user-influenced aspects of an application or data repository suddenly gains complete control over that entity, they can – for the first time – be assured that no unqualified person can blow up their world without their knowledge or permission.

Redefining Business Ownership to Enable Zero Trust
Is it hard to move to a scenario of proper business ownership? Yes – it can be a long and tortuous process, and it will almost certainly require a complete re-write of the Identity and Access Management (IAM) policies and procedures. Is it worth it? Yes again, for the reasons stated above. And the most important question: can it be done?

Yes, absolutely – I’ve seen it done on a complex core banking platform, and although it was difficult and cumbersome to get there, it paid dividends when complete. The key ingredient was that the individual we thought most appropriate to be the system owner signed up on day one, because he was a bright guy who needed little explanation of why he’d benefit from it. In hindsight, once we’d actually got the changes done, the ongoing effort required was minimal (the occasional approval of permissions for a new user, mainly) and the workload when we came to the annual re-certification of who had access was vastly reduced because changes had been controlled so firmly through the year.

---

View INSIGHTS Archive >>