Passwords can cause serious problems. Jessica Twentyman looks at keeping IDs under control.

It's no secret that many employees find it difficult to remember the various user names and passwords that they need to log into corporate systems. A random sweep of most corporate departments will reveal a veritable treasure trove of them casually posted on monitors or lurking in desk drawers and underneath keyboards.

But even a company that cracks down on such practices may still be unwittingly exposed to a variety of threats. Earlier this year, research published by the US Secret Service and the Computer Emergency Response Team (CERT) at Carnegie Mellon University revealed that, in an examination of 23 incidents of fraud conducted by insiders in recent years, 78 per cent of perpetrators were authorised and active computer users at the time and a surprising 43 per cent used their own usernames and passwords to commit the crime in question.

That points to a far deeper problem in the way that identities are defined, managed, audited and documented. It's an issue that drives many organisations to invest in identity and access management (IAM) software in response, in the hope that this will help them establish better internal control.

Analysts at market research company IDC define IAM as “a set of solutions used to identify users in a system, such as employees, customers and contractors, and control access to resources within that system by associating user rights and restrictions with their established identity.” They have forecast that total worldwide revenue for IAM software will reach more than $4.9bn (£32.8bn) by 2001.

That's great news for software companies in this market, who include Sun Microsystems, Oracle and Novell, as well as a number of smaller, specialist vendors such as Evidian, Imprivata and Courion.

But even the most enthusiastic customers of such products warn that the successful implementation of an IAM system brings challenges. In fact, it's fair to say that the purchase of software licenses constitutes only a tiny fraction of the effort involved. In a recent study of European companies that have rolled out IAM systems, conducted by management consultancy firm KPMG, a “significant gap” was found between the expected and actual benefits of doing so. “The majority of IAM projects failed to meet expectations in terms of greater business value,” say KPMG's researchers. The most prominent reason for failure, they add, is that these projects too often “concentrate on technology and lack sufficient business focus and vision.”

The drivers behind implementations are two-fold, says David Ting, chief technology officer at Imprivata. “Firstly, companies are looking to reduce the manual burden of providing users with passwords, because that can be an enormous drain on the IT department or helpdesk function,” he says. In fact, according to studies by the Burton Group and Gartner, around 30 per cent of all helpdesk calls are password-related, with the average call cost estimated at between $25 and $50 (£16.7–£33.5).

“Secondly, they're looking for a way to be able to link security events back to an individual user – IAM plays an important role in compliance and in forensic audits.”

Aligning the IAM project with a specific organisational goal is a vital prerequisite to getting the go-ahead for it, but the practicalities of preparing the ground for a new IAM system remain demanding. “For most companies, the first step in rolling out an identity management is getting a clearer idea of the identities that already exist in various systems directories,” says Graham Jones, UK managing director at security integration company Integralis. “This can be quite disorganised; in fact, it can sometimes be chaos, so we use mapping tools to get a better understanding of identity profiles. Without this step, you're simply transferring that level of chaos to a new system,” he says.

A useful tactic for analysing identities and getting them in order can be to look at each individual within the context of their job title and function, seniority/position, employment status (full- or part-time) and location, as well as the applications and information they need to fulfil their defined role. This is often referred to by vendors as ‘roles-based access'.

“This process requires buy-in from lots of different areas of the business: human resources, compliance, legal and, of course, line-of-business managers,” says Stuart Hodgkinson, UK general manager at Courion. For one thing, he explains, job descriptions and titles may not reflect the realities of work in a department. “And it's not just enough to know that a person has access to some modules in Oracle Financials – you're going to need to know exactly which ones in order to build a comprehensive picture of their identity.” Common problems identified during user account reviews include IDs that are out-of-date, inaccurate or irrelevant or even generic (shared by more than one user).

This process also requires all parties to agree on the particular naming convention they intend to adopt for passwords in the new IAM system. The idea is to remove confusing discrepancies in many organisations – a user who is ‘ptucker' on one system might be ‘pht' on another and ‘T3246830' on a third. Once the IAM system is installed, however, the IT group can create a ‘parent' user ID that will create user IDs and permissions across other required systems and applications. With this in mind, it's vital to ensure that the chosen naming convention for parent IDs doesn't lead to clashes; for example, if an organisation has a ‘ptucker' in accounts and a ‘ptucker' in sales. Another key task is to define and tune the business rules that will apply to the IAM system.

Arguably the most important task is to decide how your organisation will handle not only new recruits, but also employees who leave or are dismissed and those who change roles in the course of their employment.

One common problem is that payroll information is often used to establish that an employee has left, but since in most organisations, wages are paid bi-weekly or monthly, this can leave a significant gap of time between the employee's departure and their digital identity being removed from the IAM system, thus creating a potential ‘window of opportunity' for them to keep logging on to systems. “The problems with access management become more endemic the larger the organisation is,” says Ian Kilpatrick of security company Wick Hill. “It's very common to see someone progress through an organisation over a number of years, without anyone taking away their existing rights, even where they're no longer required, and potentially giving them access to systems that are no longer their concern.”

It will also be necessary to decide upfront how auditing will be handled. Most IAM systems offer auditing tools on the promise that it will provide them a valuable ‘log' of activities on their network that might prove vital if they become the target of a regulatory inquiry or legal action.

But auditing tools can also be used to tailor an implementation as it matures; by analysing what the IAM observes, it's possible to see what changes need to be made and potentially, to identify where users are working around the system as it stands.

Throughout the pre-implementation process, documentation will be vital. Without it, it's almost impossible to manage an IAM long-term.

Important decisions will be made at this time that eventually become part of established practice, and it's essential to demonstrate that decisions that proved unworkable are not re-implemented at a later date.

The good news is that, with this work in place, organisations should be much better positioned to choose between the various ID management systems available. But a successful implementation is by no means the end of the story, according to Gartner analyst Ant Allen.

“The last element of an IT programme is governance. IAM can make a significant contribution to information security as a governance function, but IAM is also a function to be governed.” The real proof of an IAM governance structure, he says, is modelled on committees and reporting functions that meet regularly and share information freely.

CASE STUDY: MEGGITT AVIONICS

One of the most frequent complaints among companies looking to establish greater control over identity management is the perceived need to buy an all-encompassing suite of identity and access management (IAM) products that fulfils more functions than they require, and must be integrated with other security software.

It was hurdles such as these that deterred Meggitt Avionics, a supplier of in-flight systems to the aircraft industry, from deploying IAM products from Citrix and Oracle in its search for a solution to its password management challenges, according to Stewart Gale, network services manager at the company.

“We needed to put an end to a number of problems that we were experiencing: the problem of passwords being passed around between employees and the problem of access to systems outside of helpdesk hours,” he says.

“But what we wanted was simply a single sign-on solution, without having to add a whole level of software to our infrastructure.”

In Meggitt's case the answer was Imprivata's OneSign appliance, which doesn't aim to fulfill all the demands of a full IAM suite but focuses on rapid deployment for SSO and authentication. It sits between the user, the relevant identity stores and target resources, providing a funnel for data on who the user is in the context of multiple identities and what the user is doing, so that administrators can check it.

For some users, this appliance-based approach might suggest limited scope, especially given Imprivata's focus on Windows-based systems. But for Meggitt Avionics, which only needed SSO for around six main enterprise systems (a remotely hosted email system, its corporate ERP system from SSA Global, its IT helpdesk and around three bespoke apps), it equated to a simple and speedy implementation. The proof-of-concept, says Gale was completed in around half a day, and the full implementation to some 350 users took just three months.

ARE YOU READY TO IMPLEMENT AN IAM?

There are a number of issues that any company considering implementing an IAM should consider. Challenges include deficiencies in existing user administration processes; definition of control and process owners; knowledge of compliance requirements; and understanding of audit demands.

IT security professionals must ask:

  • What is the organisation's user account landscape and its complexities? Who do we employ and what do they need to access? What happens when a new recruit joins, or an employee leaves or changes role? What if a user changes their last name? How do we handle user accounts for contractors? Which accounts should be deleted? Which are generic, outdated, stale or orphaned (on the system after the network user ID has been deleted or disabled)?
  • Who will be in charge of the IAM when it's up and running? Because the IAM will have ultimate control of parent user IDs, users are in a privileged position. It's important to restrict access to the IAM tool and implement controls to prevent or detect any inappropriate use.
  • What training is needed? In some organisations, training will be required to help users understand why and how the IAM system is being implemented. An employee self-service function for password provisioning will need to be explained and demonstrated.
  • What are the strengths and weaknesses of suppliers under consideration? Key issues include cost; function; the verdict of reference customers of similar size and in similar markets; leverage (do you have a relationship with a supplier that could give you financial discounts?); and scalability of the solution.
  • The need for executive sponsorship and consensus from all key stakeholders on the scope and approach taken?
  • The regulatory requirements that apply?
  • The reality that IAM will remain an ongoing process? Organisations should review coverage, protocols and risks at least once a quarter.