- Identity is the modern perimeter and updating controls to account for changes in how organizations operate is required
- Coding / Scripting / API integration skills will make or break an IAM implementation
- Establishing RBAC is a skill an organization will have to grow into if the practice doesn’t already exist
- Using integrators or partners may get a deployment done faster but the price paid on the back end will be substantial
Defining the Problem
Identity sprawl both within an organization and throughout the various SaaS (Software as a Service) and IaaS (Infrastructure as a Service) is challenging how most organizations manage access to data, processes, and administration interfaces. The phrase “identity is the new perimeter” may sound cliche but it is entirely accurate when describing the boundary by which business systems are segregated from public access. While technologies such as MFAs (Multi-Factor Authentication) and CASBs (Cloud Access Security Broker) help fill gaps in the detection and prevention processes the reimagination of existing identity processes for an organization can establish long term security stability by ensuring users are given access only to what is needed and thus reducing the overall attack surface of the organization. However, this is easier said than done. Refreshing an identity management process is fraught with risks and challenges for organizations. While there are many excellent tools that exist today it’s important to prepare your organization for the difficulties that lay ahead so that they may be in the best possible position to succeed. Below are some thoughts and reflections on what our journey has looked like as we have labored to redefine how we manage identities both inside and outside of our organizational environment.
Preparing Your People
The most important step in performing any level of identity management work is to lay the appropriate foundations. Preparing your people (both on your team and within your organization) will allow you to control the narrative and identify potential conflicts related to identity management. My experience with identity management is that there are rare instances where the issue is purely technical, but as technology professionals, we try to make everything a technical problem. Preparing our people calls on us to flip that script and focus on the people/process element and wrap our technologies around it. Our work is about mitigating risk and satisfying business needs which at some point is going to call into question why our processes are the way they are.
Speak in Opportunities
When we decide to redesign any process, especially one that has been in place for years, you will naturally encounter a lot of push back. This is to be expected… Imagine having dedicated many years of your career to just be told by a new analyst or manager that the process doesn’t work and your work is getting ripped out. Nobody likes hearing your baby is ugly (even if, deep down, they know it). This is why speaking in terms of opportunities is so important. Extending someone’s work or helping it reach new heights is an admirable ambition and will likely lead to greater help and championing. An excellent manager I’ve gotten to work for said it best, “you’ll be amazed at what you can get done if you check your ego at the door”.
“you’ll be amazed at what you can get done if you check your ego at the door”
In addition to changing existing processes, you are likely going to shake up the natural order of things by asking teams or systems to do work they’ve never had to do before. These are always difficult discussions to have as you are introducing unplanned work and responsibilities on teams that don’t necessarily have the bandwidth or skills to perform. How do we facilitate a positive change in task or process ownership? The same way we eat an elephant… one bite at a time. We liken the effort to the concept of water torture, a slow steady drip of pressure leading to the inevitable conclusion can help an organization change direction. The trick here, however, is to not apply too much pressure too soon or you will wash out all your efforts.
Preparing Your Technical Teams
Identity as the perimeter assumes a strong authoritative source with the processes and resources to go along with it (which is a blog post for a different day). Once you control the core aspects of an identity you can begin to branch that identity out into other applications or capabilities. The reality is not all of these integrations are going to be seamless or “supported”. Hacking together your identity processes to blend with the target application or capability will require Identity Access Management professionals to pick up some new skills with development/API utilization being chief among them.
Nearly every tool enterprises deploy today has some sort of API that can be used to grant access to a particular resource. Achieving this capability will most likely require your team to utilize a scripting or development tool of some sort. My teams have been successful with Microsoft PowerShell, mainly because we are a windows shop, but also because it’s a relatively easy scripting environment to learn. Key capabilities include the ability to understand not only how to code up various API calls and receive the data back, but also how to read API documentation provided by the vendor. If you’re interested in learning PowerShell or enabling your team to do so I recommend purchasing the book Learn Windows PowerShell in a Month of Lunches. Your team should understand the current processes, the pitfalls within them, and now with new technical capabilities hopefully overcome them.
Reflecting on the Past Year
We heeded some of the advice above, but not all of it, and this is where we sit today… For the most part the new implementations are in and are constantly being tuned. New features are introduced as they are ready and support continues to improve as we get miles behind us, but looking back what are some things that we could have done differently that would have improved the overall results of the project. The standout items are the development of coding skills, a deeper understanding of the underlying identity processes, a reduced reliance on a third party integrators. Since we’ve already gone over the development of coding skills I’d like to jump into developing a deeper understanding of underlying identity processes.
It’s natural for people to look upon the condition of a system or process and question the sanity of whoever initially implemented it, but remember… these systems are installed at a point in time and were likely designed to meet the current need and not necessarily the need you have today. Identity processes, like many other enterprise systems, don’t really like to change as they are likely complicated with vast downstream impacts every time you make an adjustment to the process. Project teams only get a few chances to modify enterprise-wide identity processes so if you’re going to push for change you must be ready to execute at a high level. If you have the political capital you need to take your shot but be sure you’re ready because a poor deployment can jeopardize your entire identity management program.
The Problem with Integrators
This is my own personal take but I am increasingly less enthralled by the promise of an integrator or professional services engagement. My main issue is that companies bring in these resources to build out a solution, which they do more or less to spec, then they offer some level of support but they do eventually leave. With things like Identity Management
Identity Management refreshes can be an incredibly useful to an organization and should be embraced by security teams as they can help implement changes to better protect identities across the multitude of applications and environments organizations rely on to execute their business strategies. It is important to properly prepare your teams (both technical and the business themselves). Developing coding skills amongst your identity management teams will lead to higher levels of integrations between your source systems and target applications. Lastly, it’s vital to not overly rely on third party implementors as the short term gain will not be worth the long term hurt when you’re stuck supporting these tools on your own, or relying on that third party to support your tool (at a healthy premium of course).