TMCnet News
How to implement role-based access control(Computer Weekly Via Thomson Dialog NewsEdge) 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. <a href="http://en.wikipedia.org/wiki/Role-Based_Access_Control">Role- based access control</a> 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 <a href="http://en.wikipedia.org/wiki/Robert_Hanssen">Robert Hanssen</a> 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 <a href="http://www.computerweekly.com/Articles/2002/06/06/187611/french-atos- buys-two-kpmg-consulting-units.htm">KPMG</a> 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 <a href="http://www.computerweekly.com/Articles/2006/12/01/220322/patients-fir st-in-ormond-street-it-integration-plan.htm">Great Ormond Street Hospital</a> are taking the plunge and combining role-based access control systems with legacy applications using <a href="www.computerweekly.com/soa">service oriented architecture</a> (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. Copyright ? 2007 Reed Business Information - UK. All Rights Reserved. |