Jericho Trumpets At Identity's Walls

Founded almost a decade ago by a group of international chief information security officers (CISOs) grappling with the seemingly diametrically opposed demands for both a more collaborative and more secure IT environment, the Open Group Jericho Forum has unveiled a set of identity commandments focusing on the fundamental design issues surrounding identity management and the access to systems, services and data. The forum, which focuses on defining and promoting solutions relating to the issue of de-perimeterization and secure collaboration within cloud computing enterprise environments, has published the Identity, Entitlement and Access Management Commandments, or IdEA, a set of 14 open and interoperable principles that IT professionals can use to build a user-centric security framework within their organizations.

According to a new Ponemon Institute survey, the cost of U.S. data breaches continues to rise, reaching an average cost of $7.2 million in 2010, up 7% from $6.8 million the previous year. The cost has increased every year since the first survey was released in 2006.

The two big issues driving this segment are how you protect data that you own but don't manage (for example, data in the cloud) and how you understand all the things that are connected to you (identity), says Paul Simmonds, co-founder and board member of the Jericho Forum. While there are lots of really good things happening out there in protecting data, “identity is a mess,” he adds. “Identity is what is holding us up as an industry from making good risk-based decisions. So Jericho did what it did best--ignored the technology and took it up two levels, to what is the root level, and that's the principles.”

There is a fundamental problem with the traditional approach to identity and access management (IAM), says Simmonds. “It's wrong ... you have to separate identity and access management; what sits in the middle is entitlement.”

The other problem is the belief in the bigger the better. “The days of big government databases are very flawed, and the concept it's going to scale doesn't work,” Simmonds says. What is relatively simple and secure with a 50- to 100-person company doesn't work when scaled up to 20,000 or 100,000 people, he says. “You have a whole bunch of people sitting there trying to glue this together with custom glue … it's very expensive and doesn't work.”The other problem with size is that the bigger something gets, the more attractive it becomes to “bad guys,” says Simmonds. “Once any critical ecosystem gets to a critical mass, the bad guys are going to target it. That's the crown jewels, especially if it includes super-persona--everything about you.”

IdEA is just the starting point, he says. “You need to have an identity strategy out there, to move from IAM. ... It's quite a fundamental shift in architecture, not something to do overnight, but over the next two-three years.” The danger, he says, is that this will happen whether you want it to or not: “You have no choice about doing cloud. Your only choice is if you want to do it securely.”

IdEA Commandments:

1. All core identities must be protected to ensure their secrecy and integrity.

2. Identifiers must be able to be trusted.

3. The authoritative source of identity will be the unique identifier or credentials offered by the persona representing that entity.

4. An entity can have multiple separate persona (identities) and related unique identifiers.

5. Persona must, in specific use cases, be able to be seen as the same.

6. The attribute owner is responsible for the protection and appropriate disclosure of the attribute.

7. Connecting attributes to persona must be simple and verifiable.

8. The source of the attribute should be as close to the authoritative source as possible.

9. A resource owner must define entitlement.

10. Access decisions must be relevant, valid and bi-directional.

11. Users of an entity's attributes are accountable for protecting the attributes.

12. Principals can delegate authority to another to act on behalf of a persona.

13. Authorized principals may acquire access to (seize) another entity's persona.

14. A persona may represent, or be represented by, more than one entity.

For the full version, visit: http://www.opengroup.org/jericho/Jericho%20Forum%20Identity%20Commandments%20v1.0.pdf

See more on this topic by subscribing to Network Computing Pro Reports Strategy: IPv6 Security (subscription required).