In the not so distant past, an organization’s IT infrastructure was simpler and more self-contained. For many, security only had to be enforced in a small set of applications, with an outer layer of protection with dedicated networks and limited access via firewalls and virtual private networks. Even larger and more sophisticated environments had a single identity store (LDAP or Active Directory)—or maybe a couple of them for different groups, such as employees and customers.
Anyway, that simpler time is now behind us. Everyone and everything is connected most of the time. Employees, customers, and vendors all want to go mobile while remaining connected. We also have an explosion of cloud-based software services such as Salesforce, Dynamics 365, Workday, etc., and these have become important extensions to our accepted and normal business operations.
In addition, microservices are extending new services to us and providing new capabilities to others. The ability to have a single, central place where we grant and revoke access has almost become an obsolete concept, but we can't live without that capability, so this is where cloud security administration tools come in. These tools give access to a wide array of on-premise and cloud services and ensure we have an administrative function even though we now have many many identity stores and access permissions.
So now we have a tool, but the problem does not really end there. The issue is that the security teams are responding and reacting to issues and threats at an ever-increasing pace. The procedural request to grant or revoke access has now become a burden to these teams. They are not really the right people to act on them anyways, as they frequently don't know the individual involved in the request or even the implications of the access request being granted.
Defining application roles that meet audit and separation of duty concerns can help, but I think it is true to say in most organizations that access simply becomes more open over time as people cover for one another or change jobs and roles but keep prior accesses. What needs to happen here is security-defined roles and audit checks, but the issuing of access and revoking of access needs to be delegated to the individuals who understand what the access means.
The problem with delegated authorization is that people get lazy and tend to give out the access they have in order not to have to deal with requests. So the last part of the puzzle is to ensure the organization has a planned attestation cycle. This process revalidates that teams are taking accountability for both the granting and revoking of the accesses. Plus, by being closer to the work, hopefully the right access is being given to and revoked from the right people at the right time. Security teams then become the enforcement arm rather than the givers.
The last challenge is that many folks need access for a finite period—say, when someone is out on vacation, or someone is covering two roles for a time. These tools need to also support timed/dated access extensions that will automatically be removed when the period has expired. Luckily, many tools already do.
What does your organization do? Are there orphaned access grants sitting out there that everyone has forgotten about? I don't like security scare tactics, but I know many of you have these things, or have them and you don't even know about them...
About the Author
Mike has been with Prolifics since 2006. He has over 20 years of IT experience covering project management, enterprise architecture, IT governance, SDLC methodologies, and design/programming in a client/server and Web-based context.