In previous IAM Best Practices blogs my fellow customer advisory board members have discussed identity ownership, ensuring identity uniqueness, where to start with provisioning and de-provisioning and discovery of assets for privileged access. Now that you have a solid foundation for your IAM program, it’s time to move on to establishing processes for incorporating IAM into new applications.
Application onboarding is a key layer in an identity and access management (IAM) strategy. It gives security managers the visibility they need to oversee enterprise systems and identify which accounts and privileges users have throughout the organization.
All new applications, systems development or vendor purchases should require an IAM review process. But IAM onboarding should not be limited to just end-user accounts. It should also include any system identities that are part of the application infrastructure, such as the database, messaging systems, and other runtime accounts.
A complete view of all user and non-user accounts associated with an application is the first step in managing lifecycle and governance for that application. When you know which accounts are being used, it leads to better control over what the levels of access and authorization are required.
Don’t wait until the end of the development cycle to bolt on security
Time is key in this process. It is imperative that organizations discuss onboarding well in advanced of application development. Make your strategy proactive instead of reactive. Prioritizing IAM in discussions when the application is still under development allows for IAM to be incorporated into the application from the very start.
Once in use, it is important to track all applications – even if they cannot fully integrate to your provisioning technology solutions. And don’t ignore applications that don’t integrate with your IAM systems and expect to get to them later when you develop custom adaptors – or when the application migrates to use one of your centralized identity stores.
Also note that it is important to have a process to track and monitor applications even if they are disconnected from your IAM services. These user and system accounts will be your most vulnerable and most at risk, with a higher likelihood of becoming orphaned. With this in mind, ensure you have a process in place to quickly deprovision accounts, and manage those privileged accounts in disconnected systems.
Best practices for incorporating IAM into application onboarding
Consider these following best practices to make your IAM part of application onboarding:
- Make things clear and less complex by having a repeatable process for application teams to follow. Multiple integration patterns for development teams to use is extremely helpful. IAM onboarding should be as simple as a process for applications to follow in order to encourage compliance.
- Use least privilege when creating and using application system accounts. Use groups and roles for assigning permissions instead of assigning directly to individual accounts. Use vaulting for system accounts to enable rotating of credentials. Do not use default root accounts.
- As the IAM program matures, move that IAM checkpoint as close as you can to the application development to create common application/IAM integration patterns.
- Make sure you focus on all identities that are part of an application eco-system: users, system and accounts.
- Tie all identities to an owner to make sure there is always some ownership of the identity. Having an owner ensures orphaned system IDs which no one knows how they are used or what permissions are needed. Often they are left with high levels of authorization for fear of impacting a process as a result of limiting its permissions. Have a strong application onboarding check point where all applications have to go through a review process before they are allowed to go live.
Consider how your culture impacts your IAM efforts
Culture is an important part of change and improvement in technology. While teams may understand the importance of security, there is often resistance, which comes from the outdated security stance of saying ‘no’ to the application community. A culture change must occur. Security practitioners need to think of themselves as business enablers, and switch to saying “yes, and this is how…”
Business wants to be agile in our current always-on, interconnected, digital world. Application development is moving at lighting speed now with agile practices in devops. IAM needs to adapt to that same rapid pace to keep up – and to be seen as another enabler, while also protecting the company assets.
About the Author: Carlos Garcia, Sr. Principal Architect, Optum Office of CIO, has specialized in Identity And Access Management systems for the past 20 years. His experience has been in the architecture and implementation of large enterprise and consumer IAM systems. Most of his career has been spent designing and running the large scale IAM systems for UnitedHealth Group. His experience and leadership led him to work on unique challenges such as helping to stabilize and improve the 2013 troubled implementation of healthcare.gov, as well as other state health exchanges. In his current role, he works in collaboration to drive the future technology state of UnitedHealth Group.
