Counsellors do it, actors do it, and people advertising
on handwritten cards in telephone boxes do it. Although role
playing is not common in IT departments, if they were to do more of
it, it might prevent the kind of situation that analyst Rob Enderle
remembers occurring at an IT company several years
ago.
A contractor had been working on a system within a company, and
the firm discovered that he had been abusing his access rights.
"They discovered the guy was going in and doing things he had no
business doing. He was pulling intellectual property out of the
system and doing all kinds of horrid things," Enderle says.
Role-based
access control is designed to prevent that situation arising.
In most companies' systems, you will find different user accounts
scattered throughout various applications in the organisation.
Those user accounts may have a few different levels offering
different privileges, but they are unlikely to reflect the complex
combinations of privileges present in the hierarchy of employee
roles.
Not tying account privileges to real-world company roles leaves
networks open to both external attack from hackers, who compromise
user accounts, and internal attack from users abusing privileges
that they should not have.
This vulnerability helped
Robert
Hanssen to deliver much valuable intelligence to the Soviets.
Hanssen, an FBI agent, was arrested in 2001 for selling secrets to
the Russians. Hanssen's arrest triggered a security review that
found the FBI's network wanting. In the resulting congressional
statement Hanssen said "any clerk at the Bureau" could have done
what he did.
Five years on, the General Accounting Office delivered the
results of another FBI network security review. It was still in
grave danger of compromise.
Origins of role-based access
The concept behind role-based access control has been around for
years, but it was first defined as a formal methodology in 1992 by
David Ferraiolo and Richard Kuhn from the National Institute of
Standards and Technology (NIST).
Their definition was taken by the American National Standards
Institute and worked into a standard methodology for role-based
access control called Ansi Incits 359-2004.
Role-based access control takes the privileges associated with
each role in the company and maps them directly into the systems
used for accessing IT resources. Implemented properly, it enables
users to carry out activities - and only those activities - allowed
by their role.
Unfortunately, many companies do not adequately align their
security needs with their IT security. "They may have defined
separation of duties in their business model on paper, but they did
not enforce it technically. You can easily open up a vulnerability
that way," says Dawn Cappelli, team lead for insider threats in
Carnegie Mellon University's Computer Emergency Response Team.
Trying to bring the IT department's security practice and
internal organisational controls together is an important part of
converged security.
But how does role-based access control work? Do not make the
mistake of equating it with identity management systems. An
identity represents you within your company, but the team that
defined the seminal role-based access control methodology at Nist
argues that a role is a collection of permissions that can be
applied to either a user or to a group.
You can do role-based access control with or without identity
management systems, says Stew Wolfe, a manager in
KPMG Canada's advisory services practice.
"Role-based access control can be thought of as a superset of
identity management services, where roles are fed into an identity
management system for user provisioning. Or it can be used as a
stand-alone system to define roles and associated entitlements," he
says.
Donal Casey, principal consultant at Morse, says that most
people adopt a simpler approach to role-based access control than
using an identity management system. Instead, they can tie a
role-based access control system to a credentials repository based
on Lightweight Directory Access Protocol (LDap), such as a
stand-alone directory service or an implementation of Domino.
The role-based access control system can then be used to tie
roles to assets, such as user or group accounts in the directory
service.
Identity management systems would be a useful way to tie users
to roles, ideally empowering business managers to provision those
roles themselves. "But companies need to watch out for biting off
too much too soon," says Chris Bauserman, manager of security
product management at IBM Tivoli.
Incorporating role-based control
Companies need to understand the roles that exist within the
organisation. Beware of falling into scenarios where administrators
and business managers assign permissions to roles and roles to
users without any central control. "You need to start off more
coarse-grained, in smaller chunks. Then get into more fine-grained
access control as you begin to show some wins along the way," says
Bauserman.
Whether you choose to use an identity management system or not,
the move to role-based access control is unlikely to be a
greenfield operation. Organisations will have legacy applications,
some of which may refer to an LDap repository for user information,
and some of which will not. In these situations, some kind of layer
will need to translate the role-based information into a form that
the legacy software will understand.
An identity management layer will handle this. The components of
an identity management system - the provisioning and credentials
servers - can be used to translate the roles information for the
legacy software.
Or, says Casey, a piecemeal system using an LDap repository
could be used instead. "If the systems are all Windows-based,
Active Directory will do most of that," he says.
Apart from LDap for straightforward directory access, Extensible
Access Control Markup Language is a useful standard for
communicating role-based information to various applications.
Governed by standards body Oasis, it is designed to transmit
information from role-based access control systems.
SOA's role in access control
Organisations such as
Great Ormond Street Hospital are taking the plunge and
combining role-based access control systems with legacy
applications using service
oriented architecture (SOA) - the middleware "jam" that
converts legacy software into services that can be reused by other
applications.
David Bowen, electronic patient record programme manager at the
hospital, hopes that role-based access control will be able to talk
to the back-end applications via these services.
Great Ormond Street is one of many organisations modernising
under the NHS National Programme for IT. The hospital is using
Sentillion - an identity and access management specialist for the
healthcare sector - to provide role-based security services as part
of a broad applications overhaul within the organisation, says
Bowen.
The role-based access project affects two key projects within
this larger IT modernisation programme. "The first involves single
sign-on, along with context management. We are also starting off a
business process management system project, which takes role-based
access to a higher plane.
"The problem with what we are doing right now is that it will
only go as far as the applications will allow us. So, typically, in
current healthcare applications, some allow you a lot of
granularity in terms of what you can do. Very few will allow the
administrator to say you can look at one group of patients but not
another," says Bowen.
Ideally, the National Programme for IT will solve a lot of this
problem, he says, because the NHS is focused on role-based access
and the representation of legitimate relationships. "But we are not
holding our breath on that. There is a lot of legacy," says
Bowen.
Instead, the hospital is factoring role-based access control
into its business process management project, which will abstract
the legacy applications into services presented in formats such as
web portals.
The roles will include nurses, doctors and patients, as part of
the move towards patient self-management. "That would be done at a
technical level of tiers. The roles are defined and constrained in
the same way, rather than being predefined by the developer of the
application," says Bowen.
The hospital has its work cut out. SOA is an expensive and
complex task, and abstracting legacy applications into reusable
services has been a holy grail for organisations since at least the
early 1990s, when the Corba object-oriented framework attempted to
do what web services are promising now.
Deployment challenges
The challenges facing role-based access control users do not
stop at software. The roles themselves, along with the people that
occupy them, are just as difficult to manage. People do not fit
into roles neatly they are often half-filling multiple roles in an
organisation.
Casey says he has about three and a half roles. Even if you
deploy a decent provisioning system, how are you supposed to cope
with roles that may fluctuate according to the organisation's
needs?
"It is about looking at the roles that your employees have and
potentially changing them completely. It is about saying 'within
our business, you should not have a half-role somewhere else',"
says Casey.
But in the real world, things do not work that way. Your local
town floods, and half the people cannot get into work. Those who
make it in need to fulfil part of the roles of others.
Role-based access control systems may not easily be able to
handle the immediate division of roles into new sets of
permissions, especially in an emergency situation where people are
waiting to log in. A quick-fix solution is to temporarily assign
extra roles to those people available, but to put a time limit on
it, Casey says.
But does allocating new roles on a piecemeal basis not make the
whole idea of role-based access control moot? And what about the
dangers inherent in password sharing?
Cappelli says, "Some organisations enforced role-based access
control technically, but they did not have security awareness among
the users to understand why. So whole teams of users would share
their passwords to work more quickly. They did not realise that
they could inadvertently give up their account to commit a
crime."
The answer to both of these problems is accountability. If a
system is configured tightly enough to monitor permissions and the
users who have these permissions, it should be capable of logging
access, so auditors can tell who did what and when.
Ultimately, that is where all such compliance-focused
technologies seem to end up you do your best to prevent a breach of
internal control, but if it happens, you will at least be able to
tell where it started.