Skip Links

A primer on roles

Roles defined

Security Identity Management Alert By Dave Kearns, Network World
September 24, 2007 06:36 AM ET
Kearns
Sign up for this newsletter now!

The foundation for security and enterprise management

  • Print

Last time, we discussed roles and I promised some more about that subject. In particular, it's the whole definition of roles – what are they, what are they useful for – that I wanted to talk about. So here it is.

Roles are an administrative tool.

Roles allow identity and security administrators to grant privileges (or entitlements) using a layer of abstraction that allows for easier management. By using roles to administer rights, we can cut down significantly on the number of transactions needed to initially assign those rights as well as to maintain, modify and remove them.

Let’s say that Jane Doe is a technical writer for the Jupiter, Thor and Zeus Technology Co. She works in Building 7 of its Palo Alto campus. Even before her first day of work, she could be assigned the following roles:

Employee – all badged employees of Jupiter, Thor and Zeus
Marketing – all marketing dept. employees
TechWriter – all technical writers in marketing
PaloAlto – all employees (badged and contract) at the Palo Alto campus
Bldg7PA – all employees (badged and contract) who work in Bldg 7

This should be enough to get her access to buildings, rooms, parking lots, networks, servers, applications, benefits, and much more with a minimum of effort on the part of the identity and security administrators of the company. Some of these privileges may need to be augmented for her particular case, but only minimally. In fact, a lot of this could be self-provisioned by Jane the first time she accesses the network – which could be during an orientation session even before she begins work.

This works because almost everything Jane has rights to, almost all privileges she has both on the network and within the physical plant of the enterprise are not a result of who she is personally (although that may have played a part in her being offered the job in the first place). It’s almost entirely a result of the role(s) she fills. It isn’t “Jane Doe” who needs access to PageMaker, but a technical writer. It isn’t “Jane Doe” who needs access to the printer with the asset tag “JTZ54$127”, but the Bldg 7 employees on the third floor east wing. And it isn’t “Jane Doe” who is allowed to park in lot No. 5 of the Palo Alto campus, but badged employees of grade C2 or below.

Now, as I said last issue, the NIST (the National Institute of Standards and Technology) documents about roles do seem to spend a lot of time talking about separation of duties (a subject dear to the heart of government regulators, but also of importance to chief security officers). While we certainly wouldn’t want someone whose role is “payroll clerk” to also hold the role of “check approver,” there is no way to simply look at the names of roles and determine if there should be separation. A thorough examination of the actual privileges is needed, and rules discerning which privileges cannot be held need also to be instituted and enforced automatically. Someone who can create a check for payment (whether in the role of payroll clerk, accounting clerk, or administrative assistant) cannot also be allowed to approve the payment. Roles might possibly help, but shouldn’t be relied on for this important security operation.

Dave Kearns is a consultant and editor of IdM, the Journal of Identity Management.

  • Print

Videos

rssRss Feed