Considerations in your IAAM journey - Part III: What should I manage in my IDG system?

Before you read, catch up on Part 0: An IAAM system overview and Part 1: Who does what.

In our previous blog, “Role Based Access Control the Unicorn of IAAM…or is it?, we discussed the unicorn of IAAM; automated role-based access control (RBAC). I think you should definitely start with those birthright applications (see previous discussion) and then pause and think about it a bit. I say that because it’s pretty hard to get automated RBAC running for your applications.

When you bring in an IAAM system, as we’ve said before, you’re looking to protect your applications and data and prove that you’re doing that. To prove you’re doing that, you’ll need to use the governance, risk management, and compliance (GRC) portion of your system. At the same time though, you’re looking to create some efficiency in your current provisioning process, which the automated RBAC certainly does. So, you’ll have to decide which one of those competing priorities wins—easy decision for me, as I know why I brought the system in in the first place (protection).

If you agree with my prioritization then you should probably look at managing some applications rather than setting up those applications for automated RBAC. First let me explain what “managing” an application means. In Imprivata's IDG system, you can manage applications—I’m not sure if you can do this with other systems, sorry—instead of getting them full automated RBAC, which can take days/weeks to do. When you manage an application in IDG, you’re using the system to keep track of which digital IDs have access to which applications, only. You’re depending upon your “old” provisioning processes to get accounts created in those applications for those digital IDs. Now, why the heck would you do that, rather than take the time to automate things?

It’s all done for the sake of a more robust GRC program! You see, the more applications your get into your IAAM system, the more data you have for GRC. Sure, perhaps you won’t have some of the granular data you may want, like access to modules within applications, but you’ll have the “metadata” you can use for GRC. So, you’ll know which digital IDs have access to the managed applications and who the supervisor of that digital ID is, at minimum. That lets you run some GRC reports that are pretty important in healthcare, namely the User Attestation/Periodic Access Review and Orphaned Accounts reports. And, the more applications you manage, the more UA/PARs you can automate and the more visibility you can have into orphaned accounts.

An orphaned account, by the way, is an account that still exists in a non-AD aware application after the digital ID has been disabled in AD. As you know, in healthcare, we have a ton of applications that aren’t AD aware (Radiology, CV, etc.), so you really have to have a good process when you deprovision accounts to make sure you don’t miss one of those. The Orphaned Account Report helps you make sure that you don’t miss one of those accounts when you deprovision.

So, you can see why/how even just managing applications in your IAAM system can really, really help with GRC. Oh, and not to mention what it does for you with license management. I know I used to over buy licenses just so I could make sure I wouldn’t run out, but I’m sure none of y’all do that. Obviously, I wasn’t running a very good IAAM system at that time and didn’t have much of a handle on things.

Finally, in Imprivata's IDG system, it only takes a matter of minutes to “manage” an application as compared to the days/weeks to automate RBAC in the system. The benefit to your GRC program in managing applications makes the hours spent on getting them into the system well worth it. Beginning with the end in mind, like Lean tells us to do, helps me make the decision to manage as many applications as possible as soon as I possibly can in my IAAM system so that I can both protect and prove I’m protecting my applications and data.

Next: Why take the risk of integration?