Online MS in Cybersecurity from Drexel University
Drexel University’s online MS in Cybersecurity utilizes the College of Computing & Informatics and College of Engineering’s network of professionals to give students access to the latest research, tools and insights, and prepares students to meet the workforce needs through rigorous academic and experiential practical training. Learn more!
One of the biggest business impacts resulting from moving to a Zero Trust (“ZT”) regime is the perceived disempowerment of middle management. Dave Cartwright, CISSP, explains.
Boards and cybersecurity teams are all discussing the impact of adopting a Zero Trust approach to security in our organizations, and at least some have 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 us 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: (1) raise a ticket to request access; (2) get the user’s line manager to approve the request; and (3) provision access accordingly.
The problem is that if we think about it carefully, step (2) 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. And 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 author 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, actually 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 view of line managers (I am one, after all) – but 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 major security decisions.
So we should 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.
The right person to make the decision on who should have access to a system is the business owner of that system. And 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 organisations 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: the person who’s accountable for the user-influenced aspects of an application or data repository suddenly gains complete control over that entity, and can – for the first time – be assured that no unqualified person can blow up their world without their knowledge or permission.
Is it hard to move to a scenario of proper business ownership? Heck 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 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. And 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.