One of my favorite management concepts is Job Role security.
The core of job role security is the logical extension of Role Based Access Control that comes from aligning job function (more specifically task oriented work groups) to security rights. This alignment both accelerates IMAC operations and reduces complexity of compliance events by directly relating the majority cause of permissions changes to the resulting effective permissions. It’s a methodology for concrete tactical security based on a heuristic simplification of implied access, but it’s rarely implemented (probably because it is based on heuristics, not on definition or queried permissions, which are both easier to CYA).
This concludes the buzzword portion of our broadcast.
In simple(-er) English, it means that the access a user is granted by the company is connected to the job that company has asked them to do.
- We have hired you to do job A.
- Job A requires access rights B.
- Therefore we will grant you the access rights B as long as you are doing job A
I try to explain this to every client I walk into, and I’ll go through over the next few posts, in case anyone can find use for it. There’s a TON of potential in this concept, but it requires a bit of upfront work. My goal with this series is to go through one use case and show the benefits and execution, and hopefully give you the tools to implement this in your organization.
The First Case:
In the traditional case, Bob has access to the tools cabinet and the building supplies depot. The only way we know this is to look at the permissions on those locations (or the resource groups that control those locations). Does bob need those permissions? what about Tim? Frank?
Bob is a builder. So we need to understand what work and (more to the point) what access being a builder implies. Mr. Vila is the supervisor who runs the builder team. He tells us they need access to the building supplies depot, the tools cabinet, and the first aid box. We’ll define a builder role and add the access that the manager tells us his team needs. Being a builder doesn’t tell us anything about whether they need access to the petty cash, the locksmith cage, the drawing rooms, or the waste disposal skiffs, so we’ll not include those in the role, and he’ll get denied by default.
Another possibility is the negative. Mr. Vila tells us that no one who is builder will ever have access to blueprints room. he’s had problems with his builders going out of scope when they get their own blueprints, and we don’t get paid for that. No one who is a builder should ever get access to the blueprints room. We’ll add this as a deny ACL.
So far, not much is different from the traditional case, but there are a couple of important points already. By allowing (and in fact requiring) direct line managers to assigns responsibilities to their teams we can be sure:
- That the access aligns to the responsibilities that are really required by that job. we can know for sure they don’t need access to the other locations, because otherwise all the builders would complain to Mr. Villa.
- We capture access that outside reviewers might miss because they are not involved in the day to day operations. I.E. The first aid box, which nobody would think a builder needs access to, but Mr Vila remembers that time Tim the tool manager got over excited with the buzz-saw, and has recently added first aid expertise to the team’s duties.
The general terms for these two concepts are Specificity, or how narrowly the roles matches the needs, and Sensitivity, or how completely the role definition covers the needs. Stats nerds will already know about sensitivity and specificity, the statistical terms that cover these concepts for binary tests, like an access control check.
So we create an AD Group, let’s call it “JobRole-Builders”, make Mr. Vila the manager of this group, and grant the specified access to the specified locations. While we are granting access for this group, we’re going to remove any overlapping permissions that might exist, as a clean-up effort.
In Other News:
There are a couple of caveats on this method.
First, I grew up in manufacturing, where this type of job role access works very well; i.e. hire a mechanical engineer and he needs to do mechanical engineering with engineering tools against mechanical systems. Some industries, especially creative industries like Software Design, Consulting, Advertising, etc… might better benefit from Project Team Security, organizing access against the project a person is doing work for, rather then the job they do. I’ll cover this methods more in further parts.
Second, this method requires some attention and understanding of the business. You’ll have to free up some people to find and interview line manager, define these roles, and maintain them. You’ll also have to spend a lot of effort in understanding the business uses of the technology, which is something IT departments have historically been very bad at, rather then taking the “Field of Dreams” customer service plan.
Third, if your organization is small, or has a lot of unique roles, then this method might not end up saving you any time. don’t be tempted to slice the roles so fine that they are only a couple of people. AD job roles should really reflect the business work groups; lit. groups of people who do the same work. “Accounts Payable” is a good example of a work group, since all AP work requires the same rights and the same tasks; i.e. processing incoming bills and paying accounts. Conversely, “Quality department” is too broad and “Assembly Line 7 position 21 third shift” is too narrow.
The case here is a bit like the counter-intuitive physics of orbital mechanics. Most spacecraft use more then half of their fuel to get up to orbit, but as Robert A. Heinlein said “Reach low orbit and you’re halfway to anywhere in the Solar System.” and, sometimes you have to burn in a direction that doesn’t make sense right now, because it puts you where the goal is going to be by the time you get there. (unrelated: Kerbal Space Program is awesome)
I’m curious how organizations handle job related access, Jump over to my Interrogations page and help reduce net universal ignorance.