Although not as widely recognized, there is also a degree of separation between the people in IT who establish levels of security (usually through groups within Active Directory) and the people who are closest to the resources and applications for which that security is provided.
Given that most of you usually strive to grant the lowest level of privilege required (that is, you’re not wanting to give everyone full access to everything), it’s important to understand just how bad the separation really is.
Acknowledging the existence of this separation is crucial for one very important reason:
- By not recognizing that there is a gap between IT and the business teams that are closer to the action, IT runs the risk of “living in a bubble” — of believing that it has a complete handle on security, with all users having exactly the permissions necessary to accomplish their job, and nothing more.
In reality, it may be that your best effort is really a least effort. Your level of security depends on how many degrees of separation you are from the security you wish to implement.
So, how many degrees of separation can IT really find itself in?
I can think of 4 degrees of separation that keep your security from being as accurate and robust as possible. (If you can think of another, please add it in the comments section below.) Here are the four:
- Who Needs Access: You know the folks in marketing need access to the marketing portal on SharePoint, but do you know specifically who should have access? And when someone changes jobs, gets a promotion, or moves departments, are you even notified? And with that notification, are you informed about what changes in access are necessary as part of the personnel change? If you’re like most IT departments, the information you receive is probably little more than just a list of everyone in marketing.
- What Access is Needed: Not everyone necessarily needs the same levels of access, even within a department. Continuing with the previous example, some users in marketing may need only read-only access to the department calendar. In this case, giving the entire team either Edit or Full Control access wouldn’t be appropriate.
- What Access is Possible: To implement the right match of what access should be given to a specific individual or group, it’s important for IT to know the functional subsets provided by each application and how they are tied to permissions. For example, with regard to SharePoint Online permissions. there are over 80 different permissions assignments available! While you may be a SharePoint expert, you may not be an expert on the next application the business needs to run.
- When All This Changes: So long as there are no changes in personnel, no changes in access, and no changes in application functionality, the previous three degrees of separation are a one-time problem. But we all know that reality is quite different: Because applications get upgraded (along with new features and capabilities), and because users and roles are never static in the long run, the tie between the two (by definition) is a constantly moving target.
So, what are you supposed to do about this? You don’t have time to become an HR and application expert!
The answer lies in not relying solely on IT to build the security model for any given application. IT needs to build a bridge with the owners of the applications and the lines of business. IT needs to engage these teams not only to assist in defining the “who” and the “what” mentioned above, but also to actually help IT manage security. Who’s better suited than someone so close to the day-to-day use of an application and its data?
Building these bridges with the right teams is the most effective way to ensure that these degrees of separation don’t have a negative impact on your security.
(If you’d like to read more on the topic of shifting AD group management responsibility to the rest of the organization, check out the whitepaper, The Importance of Collaboration between IT and Business for Effective AD Group Management.)
Jonathan BlackwellView Profile
Since 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.