Great Answer

I asked for a useful scenario for OpenID in the enterprise. Johannes Ernst delivered.

I do think though that while this sounds like a good use-case for some of the underlying technology, it may not contradict what I was thinking. What I was referring to, regarding user-centricity in the enterprise, was the authentication and user information management model that enables people to manage their own information rather than have that information managed by the application owner (think eBay, Amazon, iTunes, etc.). Rather than have each of those companies store information about me, I can own that information and perhaps store it at an identity provider that I choose. This is the model that I believe, while providing tremendous value in the consumer world, may not often translate to the enterprise.

And I agree with Pamela Dingle who wrote:

My advice to Enterprise decision-makers is simple: take the tools and find out if there is a story that those tools can tell that brings value to the organization. If the story is there, adopt the tool. If the story isn’t there, walk away. Whether or not the marketing term applies is, to me, utterly inconsequential.

But as a technologist, I want to understand all the creative uses of technology so that I can recommend the right approach when I speak to companies who are looking to improve their operations. And as an employee of a company that deals with identity audit, I want to get ahead of the curve. If there will be a need to audit the use of technologies in a user-centric model, I want to know what that means.

I'm not trying to make any statements here about what OpenID should or should not be. I'm just trying to understand what the value-proposition would be that would lead an organization to internally adopt a user-centric model.

And a more secure un-spam-able messaging environment sounds like a good start.

NetVision Webinar: Surviving an Identity Audit

On Tuesday of next week (Dec. 18th) at 1PM EST, NetVision is presenting a webinar on Surviving an Identity Audit. The content is loosely based on our whitepaper of the same title.

You can sign up or get more information at the NetVision Events page. If you attend, we will help you to:

1. Understand the Business Drivers for Identity Audit

• Compliance: Government, Industry, Internal
• Organizational Risk: Unintentional, Malicious, Opportunistic

2. Manage the Identity Audit Project Lifecycle

• Create policies that minimize effort across multiple regulations or best-practice frameworks
• Implement automated controls
• Audit identity controls, user behavior, and user empowerment

3. Create a Culture of Compliance

• Build a multi-regulatory approach to minimize effort and streamline the audit process
• Leverage tools that automate audit reporting
• Utilize a continuous audit model

Look forward to seeing you there!

---
UPDATE - A condensed version of this webinar has been provided at the NetVision web site.

Insider Threat - By the Numbers

I've been talking with customers and colleagues about the insider threat throughout most of 2007. I've mentioned stats that 70% of electronic security breaches originate inside the firewall and 90% of those are users with elevated rights (systems administrators, etc.).

For the most part, I've rationalized that most of those attacks are likely in one of these two categories:

• Opportunistic
• Unintentional

The category that's missing is malicious. I leave out malicious because I believe the large majority of breaches are not intentional or at least not driven by ill-intent. From what I've seen, people break security policies because their everyday jobs lead them to it. Sometimes, people break security protocols in order to meet a deadline or otherwise get a task accomplished. Other times, opportunity just presents itself.

Consider these scenarios:

• A DBA opens a database to accomplish a work-related task and encounters data that's just too enticing to ignore.
• A file system administrator is asked to grant a new HR manager access to the file share that houses previous employees' offer letters and he/she can't help but take a peak at a few co-worker salaries.
• An employee is asked to take some work home and rather than carry a company laptop, they put sensitive information on a USB key that they often use to share songs or other trivial files with friends. Or they email files to/from a personal account which may not be secure.
• In software development and/or integration, I've seen numerous people make decisions to share a password, grant full permissions or otherwise remove security restrictions to troubleshoot some software or configuration-related issue.

All of these scenarios represent a real security risk to the organization but none would be considered a malicious attack. When I first saw the 70% number, I thought it had to include these types of scenarios. I know malicious attacks happen, but I just don't see it in my daily life. These scenarios, however, are another story. It's almost hard to work on any corporate project and not encounter these types of security breaches.

A series of articles posted yesterday in Network World by Denise Dubie provides some air cover for the arguments I've made based on personal experience. Check out just a few of these quotes, then go look at the articles for yourself. Great food for thought.

End users behaving badly
Most employees knowingly violate corporate security policies.
By Denise Dubie, Network World, 12/10/07

"most companies say they have security policies in place, yet data breaches continue to plague more than 75% of Fortune 1000 companies"

"More than 50% of survey respondents admit to copying confidential information onto a USB memory stick, and 87% say they believe that the company's policy forbids it. But 40% also reported they knowingly break the policy because the company doesn't enforce it, and another 21% said 'no one really cares about compliance with this policy.' Close to 30% said they'd violate the policy because otherwise they would not be able to complete their work on time."

"46% of those polled said they share their passwords at work, and 40% of survey respondents believe that sharing passwords with co-workers is necessary to get work done within deadlines"

Trusted users pose significant security threats, survey finds
RSA survey data reveals innocent insiders create data exposures of extraordinary scope
By Denise Dubie, Network World, 12/10/07

"35% of people polled said they need to work around their organization's security policies to get their job done"

"34% reported having held a door open for someone they did not recognize"

Scary tech stories: How dangerous user behavior puts networks at risk
IT managers share tales of how users' actions can cause security nightmares
By Denise Dubie, Network World, 12/10/07

"end users just don't think passwords are a big deal and think we are just here to make their lives miserable when we request them to change or update passwords"

User-Centricity in the Enterprise

Most of the on-line discussions about Identity Management over the past few years seem to have been about consumer authentication. The industry has developed solutions for user-centric authentication models. I'm not going to go into detail here or try to define those models. But, now that OpenID and other technologies has brought the user-centric model to reality, I'm beginning to see more chatter about user-centricity in the enterprise.

Patrick Harding doesn't seem to think that the enterprise is the right place for a user-centric model. I agree. I also agree with Pamela Dingle who noted that user-centric technology may be useful in an enterprise for the purpose of users keeping some information up-to-date.
I would qualify that, though, by saying that it's only going to be the information that the enterprise decides is unimportant enough to leave in users' hands. Companies never allow employees to update critical information on their own -- job title, pay grade, SSN, email address, etc.. Nor do they allow employees to decide what information they choose to share with the company's HR department. Companies require forms to be filled out completely. And if there are blank spaces, there's often warning that it could be just cause to rescind the employment offer.

Nishant Kaushik doesn't seem to think that the user-centric model is right for an enterprise environment. And Johannes Ernst disagrees.

I've been thinking about this for a while and I'm with Patrick and Nishaunt on this one. The goal of user-centricity is to give control of their identity information to the end users. That's great in the consumer world. Enterprises, however, have been spending millions on Identity Management specifically so that they (the enterprises) can control identity information more effectively. In the consumer world, it makes sense for people at home to want control over their information as it travels across the Internet. But, in a corporate environment (or government or education) employees and associates don't have rights over their identity information. Since Johannes is the one I've seen to recently claim otherwise, I'll look at his comments.

First, he talks about potential customers. For most enterprises, potential customers are anonymous or simply contact info and notes about whatever the enterprise can learn about their interest in the company's product. He talks about current customers and their desire to use user-centricity when interacting with the enterprise. OK, I can see that point, but that's not really enterprise. To me, that's still a consumer solution.

He then talks about affiliates. This is the typical use-case for Federation. Since this is about business transactions, the most important component of the federation model seems to be the non-technical stuff -- business agreements, contracts, terms of use, processes, etc.. It's not a scenario where you want one business partner to decide to withhold information from the other for the purposes of privacy or information control. Affiliates don't tend to share personal information, but business account information and transactional information that are both critical to the transaction in process.

Finally, he mentions user-centricity within an enterprise's own internal systems. Specifically, he gives the example of a personal cell phone number. To me, that's not enterprise data -- you can manage sharing your personal contact information with friends and close co-workers through social networking sites. Company-sponsored cell phones and IM addresses should be part of the corporate identity management infrastructure. Employees may be allowed to keep information up-to-date, but they're not allowed to decide which managers can view their information and which can't. The company makes the decisions about information use.

I don't know if I'm "defining away the issue of user-centric identity in the enterprise", but I don't see any major value or realistic adoption of a user centric model within an enterprise. The examples presented in the argument for it seem to be consumer scenarios and not enterprise scenarios. If you're expected to be available at 2am, then it's the enterprise who controls where your cell phone number is posted for anyone who needs to find you.

Let me be clear. I'm not bashing Mr. Ernst or trying to minimize his argument. He's obviously an intelligent guy and has contributed a great deal to the industry. But I'm challenging him and others to give me better examples of where the user-centric model may be useful within the enterprise. Because right now, I don't see it.

David Rowe - New Blog

I've previously mentioned that David Rowe is the visionary behind Policing the Power of Identity. David has introduced a new blog at powerofidentity.wordpress.com where he'll discuss what it means to police the power of identity. He also provides a link to his recent paper on the subject. The paper is not a product pitch and is not written with a customer focus. It describes a vision of how companies can empower employees without fear – and how we as an industry can define standards and leverage open protocols to help our customers achieve that vision.

If finding a balance between freedom and control to empower digital identities within an enterprise environment is a topic of interest to you, please visit David's blog and join the conversation.

Managed Identity Management Services

Identropy has brought to life a long overdue idea in presenting their managed service for identity management. As Corbin Links pointed out, it takes a significant skill set for companies to plan, deploy, and manage an identity management infrastructure. It's not always easy to find the right talent for any given project. And there are pitfalls in most identity management projects as Mark Dixon advises in his list of project success factors.

Identropy isn't the first to offer a managed service for identity -- I know Oracle/WiPro and probably others have tried it. But, Identropy is the first I've seen from a smaller services organization. In the services world, smaller generally means quick, flexible, and ready to respond to market needs and changes.

Forrester says we're ready for managed Identity services. They're betting on Mycroft-Talisen to successfully offer a managed service for identity. I don't know if they've brought it to market yet, but the combination of Mycroft and Talisen has the talent to make it happen.

Anybody have other experiences with managed/outsourced identity management offerings?

Provisioning with SPML

About 18 months ago, I wrote a paper for MaXware about Identity Management in a Service Oriented Architecture (SOA) and described the scenario of initiating provisioning events from enterprise applications via SPML to the provisioning system (now called the Provisioning Service Provider in an SPML scenario).

Martin Raepple of SAP just published an article titled No Limits for Identities. In it, he discusses the process and business value of leveraging SPML for provisioning. He also discusses the role of the Provisioning Service Provider (PSP).

It seems that SAP has done a good job of quickly leveraging one of MaXware's core strengths to enable the NetWeaver platform to act as an open and available PSP for the enterprise. Many of the other major provisioning platforms also support SPML, but I haven't heard of many customers leveraging a service-based provisioning model. I still expect this type of architecture to become more commonly used. Have you seen it in action?

Identity Mgt. Deployment Tips

I was soliciting input from Corbin Links on something and it brought me to his latest blog post which is titled When Good IAM Software Goes Bad. It describes the common pitfalls of Identity Management software deployment. He really hits the nail on the head in terms of the types of frustrating issues you encounter when deploying IdM solutions. AND - he provides some tips on how to avoid them and gives some great advice.

Incidentally, it's not the first really useful post by Corbin. If you're a company that needs to roll out Identity Management solutions, he should be on your reading list. e.g.) For a pragmatic approach to dealing with Role Management, check out his post on Role Mayonnaise. ...not to be confused with Mayonnaise on a Roll, which I've been told was a tasty snack during The Depression. (sorry for that)

NetVision Links and Stelogging

I haven't been blogging much lately. I've been busy though. I already mentioned my whiteboard presentation and my recent white paper on Surviving an Identity Audit. We also recently launched a new NetVision web site where we talk more about Policing the Power of Identity and our slick new Reporting Console. You might also be interested in NetVision solutions for Active Directory, PCI-DSS, or ISO 17799 / ISO 27002. You can also sign up for our upcoming webinar
on Identity Audit.

Stelogging

I also found out this week via a Google Alert that someone is stealing and reprinting my blog content for profit. And they're using my RSS feed to do it. I've seen it called a Splog, but this is actually not Splogging (according to Wikipedia) because I'm not doing it to drive up link traffic or SPAM my audience. This is someone else re-purposing my content. Maybe this will be called Stelogging? I generally like to see people including my content in their discussions, but this doesn't feel right. What's worse is that Google helps them out by advertising (via Google Alerts) and providing a revenue stream (via Google Adwords). I'm not going to disable the RSS feed -- the point of this is to allow people to read the content. I'm not really sure there's anything to do other than ask them to stop. I suppose I can also include a footnote on my posts to the effect of:

If you're reading this at a site other than 360tek.blogspot.com, please DO NOT click on the advertising and support the use of stolen content.

I suspect we'll see more of this kind of thing. If this snow balls, it may become difficult at some point to discern the original author from the re-publishers. Is this something I should even care about? I suppose if I had 4 million visitors daily and my blog was my primary source of income, it would be a big deal. As it stands, I'm not sure why I'd be a target for this sort of thing since I have a very niche (but excellent) audience. This is a strange thing to be thinking about.

HP's Security Handbook

Thanks Marco for pointing out HP's Security Handbook. It's a guide for securing an enterprise with a focus on identity management, proactive security management, and trusted infrastructures.

One section worth pointing out is in Chapter 1 on Governance where they define the differences between corporate governance, security governance and IT governance. I find that people often use these interchangeably or confuse the regulation-of or solution-for one with another.

I also like the section later in this chapter which suggests a move to continuous, real-time assurance or continuous compliance -- what I (and others) have previously referred to as creating a culture of compliance. Identity Management gets an entire chapter. And there's a glossary and appendices that cover topics such as IPsec-over-L2TP, placement of a reverse proxy server, and the difference between TACACS+ and DIAMETER. Good Stuff.

Surviving an Identity Audit

Smaller companies can feel overwhelmed by big company issues. Although they don't have the reach of the Fortune 500, they still feel the effects of governmental and industry regulations. They have similar requirements with much fewer resources to get the job done.

In this whitepaper titled Surviving an Identity Audit, I tried to help people at smaller organizations get their arms around some of the big challenges related to compliance. Specifically, the focus is on the identity portion of an IT audit.

Regulations such as SOX, HIPAA, GLBA and PCI-DSS have requirements and/or guidance that relate directly to IT – more specifically to information security. And digital identities are at the core of information security. So, an audit of an organization's identity infrastructure is a vital component of an IT audit or a larger regulatory audit.

In this paper, I cover the Identity Audit project lifecycle, leveraging a multi-regulatory approach, and creating a culture of compliance.

For more info:

• SOX – Sarbanes-Oxley Act
• HIPAA – Health Insurance Portability and Accountability Act
• GLBA – Gramm-Leach-Bliley Act
• PCI-DSS – Payment Card Industry Data Security Standards

Securing borderless networks

Here's a nice blog entry on 10 ways to secure borderless networks. It could have been written by EMC/RSA as it covers many of the capabilities they've been talking about for the past year (and for which they have pretty nice solutions).

The reason I mention this article is to re-raise the point that security needs to be handled from numerous directions and in numerous ways. There's no single security solution that will prevent against every type of attack or breach. People are mobile and our information is mobile. A good security strategy needs to cover many fronts - from remote user authentication to data encryption.

One note to the author: MIIS/ILM is not a federation solution. And while I'm on that subject, I wouldn't have even included Federation as a solution to make systems more secure. Although the argument can be made that it provides greater control over user accounts by the identity provider, it's primarily a solution that enables ease-of-use in a secure way rather than a solution for increased security.

And since there's an empty spot on the list, we could replace it with real-time user behavior monitoring as another good way to enhance security in a borderless environment.

NetVision: Policing the Power of Identity

NetVision issued a press release today in conjunction with our appearance at Digital ID World. It's primarily about our very cool new reporting capabilities to be officially released in October. The release also points to a four minute whiteboard session explaining what we mean by Policing the Power of Identity. If you have four minutes, please take a look. Since I created the presentation, I especially hope you enjoy it.

The End of Encryption?

OK, I realize it's not the end of encryption, but this is a big deal. Separate groups of researchers in Australia and China have independently used quantum computers to factor the large numbers used for much of today's asymmetric encryption. Asymmetric encryption is used for PKI which is the underlying concept behind SSL -- probably the most fundamental component of security on the web.

Here's how SSL works (simplified):

1. persons 1 & 2 agree on a base number (x)
2. person 1 raises x to the power of a large secret key (y1) = z1
3. person 2 raises x to the power of a large secret key (y2) = z2
4. persons 1 & 2 exchange values z1 & z2
5. person 1 raises z2 to the power of y1 = k
6. person 2 raises z1 to the power of y2 = k

They now both have k as a secret key that nobody else knows.

The security of the process hinges on the fact that an eaves dropper wouldn't be able to take x and z1 (which are both passed openly) and quickly figure out y1 (the secret key) -- or do the same for y2. If that were possible, they would be able to listen in on SSL transactions. And that's pretty much what these researchers are now able to do.

The article suggests that "For the moment, enterprise computers seem pretty secure, since you'd have to be a quantum physicist to crack today's codes." But, one might speculate that if a secret is worth enough to a would-be attacker, quantum physicists or their tools may become purchase-able. It's probably not a big deal for joe consumer, but for governments, large defense contractors and the like, it's probably time to take a look at their use of certain algorithms in asymmetric encryption. That analysis of course should be and probably is a continuous, on-going process. Interesting stuff.

Identity Management Detective

Jackson Shaw asks "is there a role for an identity management detective?" Although I suspect it was mostly a rhetorical question, the answer is absolutely. You may have seen my recent post on Policing the Power of Identity. The challenge that Jackson describes is exactly what we have in mind when we talk about policing identity. Many of NetVision's customers recognize that they can't provide answers to basic questions about what identity controls are in place, what are people doing on the network and what power has been given to users. The combination of controls, behavior and power is what makes up the power of identity. And our customers are definitely finding value in tools that provide policing/detective capabilities around that power.

Identity Cartoon

A little identity humor for your viewing pleasure...

Identity Audit != Identity Management Audit

I've posted a few times now on identity audit and I've noticed that some other smart folks in the industry have used the term identity audit (IdA) when speaking about what I call identity management audit (IdM-A). The Identity Management software vendors are especially (and understandably) guilty of this. So, I'm taking this opportunity to point out that identity audit is NOT the same thing as identity management audit. I realize that I probably won't eliminate the confusion across the entire industry, but at least you'll be aware of the distinction and will be able to educate those around you.

Abbreviations:
IdM = Identity Management
IdM-A = Identity Management Audit
IdA = Identity Audit

Identity Management Audit

IdM-A is usually provided by the IdM software vendor. It's an IdM system's internal audit of IdM activities. It can tell you about the identities that flow through the IdM system. It generally relies on the logs generated by the components of the identity management system. If it's one of the better IdM-A solutions, it may even report on what it sees in its connected data repositories. IdM-A is typically limited to an audit of the IdM system itself and is somewhat myopic in that sense. Any reports that it provides are based on its own view of the environment and may be less reliable than an independent audit mechanism.

Identity Audit

Identity Audit solutions provide a more external view of identity information. It can provide independent reports on the data within identity data stores to verify whether the IdM system is doing its job correctly. It can also identify and take action on activity that happens outside of the IdM solution. For example, if an administrator subverts policy by manually adding a friend to the domain admins group, IdA can capture that event, throw alerts and potentially provide remediation as well -- perhaps through an existing IdM system. IdA solutions are equally if not more useful in environments without IdM systems. For example, in a smaller Microsoft Windows environment where users are managed in Active Directory with no or limited automation, an IdA solution can provide a useful tool set for auditing the power of identities within the environment -- without the requirement for an identity management system.

Conclusion

Identity management systems along with other information security mechanisms are controls put in place to enforce organizational policies. Identity Audit provides an independent and wide-angled view of identity controls, identity behavior and identity power to ensure that policies are being enforced. IdA solutions are complementary to IdM systems and continue to provide value in environments where IdM systems aren't available (or required).

Own the Burden

Chris Parkerson of RSA raises an excellent point about the expectations that organizations put on employees regarding data protection. He asks "Is it really possible to expect employees to be educated enough about such policies to always do the right thing?" And he goes on to make the point that "well intentioned employees in many cases are under pressure to complete projects in record time and with minimum resources. The consequence of this dynamic is employees will prioritize getting a critical project completed above adhering to company security policies."

I think he's right. It's not an issue of having bad-guy employees. It's that productive employees have too much going on to be constantly thinking about security policies. Some employees may even think that policies are important for audits, but don't really need to be followed day-to-day. Ask your co-workers and friends and I'd bet you'll find a few people who think along those lines. If you've ever worked on a software integration project, I bet at some point you encountered a permissions error and elected to just give the user admin rights to get things working. Of course you eventually went back and revoked those rights, right?

So what can an organization do to protect themselves short of mass employee hypnosis? Own the burden. Put the right security controls in place and continue to balance employee education with effective IT controls. And, of course, run regular audits and real-time monitoring on those controls. Create a culture of compliance. Automate the process of security and most employees won't fight it. They'll probably like it better if they don't have the option to subvert security because there will be no pressure to do so by coworkers or deadlines.

Compliance: More of an Art than a Science

I just read an article titled Perfect HIPAA security impossible, experts say. It covers a few healthcare companies' different approaches to HIPAA compliance. The main premise is summarized by Barry Runyon of Gartner:

[Companies] need to take a risk-based approach to HIPAA compliance that takes into account their individual circumstances and resources, he said. "Tailor the HIPAA security rule to your organization so you don't break the bank… It comes down to being able to prove you've taken due diligence," he said, adding that documenting the reasons why a HIPAA provision can't be implemented usually is sufficient for auditing purposes.

Whenever I hear from experts on industry regulations, it sounds as if compliance is more of an art than a science. I find that very interesting. When we think of an audit, we tend to think of accountants reconciling numbers in a ledger. ...and everything needs to match up. But in IT security, that conceptualization doesn't ring true. So, be careful about searching for the perfect compliance checklist. And be careful about consultants who have a proven formula. This is an iterative process that requires corporate lifestyle changes. Toward the end of the article, there's also a nice example of how identity management solutions can be an enabler for compliance.

Policing the Power of Identity

I borrowed the title of this post from NetVision's visionary CEO. You may start hearing it more from us in months to come. I previously discussed some of the steps involved in an identity audit project life cycle and I also discussed the value of living a lifestyle of compliance. Now, adding to those concepts, I'm going to attempt to boil it down to a few real-world customer challenges.

The Internal Threat
Most of us have seen the stats that tell us that much of the risk associated with organizational information technology breaches comes from inside the firewall. And a huge portion of that internal threat comes from our privileged users. These are the very people to whom we have purposely granted elevated rights. They are system administrators, DBAs and application owners. Most are not bad people. I believe that the number of incidents is high among this group of people not because there's a high rate of criminals in the group -- it's driven more by mere convenience or opportunity. Anybody that has access to multiple system databases will occasionally come across a batch of data that looks interesting. And since we're allowed to access that database, why not look around? It's not only not-a-crime, but we have been specifically granted access by management to view that information. When it comes to information about people -- like salary data, net worth, health info and other juicy information, sometimes it's just too tempting not to look. ...and maybe too tempting not to share. ...and if for work purposes, some or all of that data is downloaded to non-production systems or even a personal laptop, it becomes very difficult to protect the data because the non-production environments are not secured as well as the production systems. They often use default or shared passwords, limited access control, etc.. As a consultant, I was often restricted from access to my customers' production systems but few thought twice about giving me access to the non-production systems. And many of my customers used production data in the development or testing systems.

Identity Audit Business Drivers
Identity audits seem to be driven by two forces: compliance & risk management (security). Compliance may be driven by governmental or external regulations or it may be internal policies. And even if there are no compliance requirements, the goal of identity audit is often just to to mitigate risk (which is ultimately the driver behind the regulations). Over the past decade, I have experienced the emergence of Identity Management as its own industry and organizations have sought out and realized the business benefits promised by Identity Management systems. What has been left unanswered is whether the identity controls being put in place are doing what they're supposed to do. When asked to provide proof of this by IT auditors, IdM system owners have limited options. If they're lucky, they can provide a report of the logs created by the IdM system itself, but that doesn't include actions that occur outside of the IdM system. They may be able to pull logs from individual systems, but the job of cross-referencing and correlating data across logs or finding specific incidents becomes extremely daunting. So, the challenge presented to identity audit solutions is ultimately to reduce organizational risk (and thereby achieve compliance) by providing state-based reporting and real-time monitoring of identity systems.

Internal Affairs for IT
In tackling the identity audit issue, the first place to look is often the privileged user community. The identity audit solution really does two things: (1) protects the organization against the internal threat and (2) protects the privileged users in the event of a system breach against unwarranted investigation. By tracking events like new user creation and group membership changes, you're able to see who, what, when, where and how -- which means that the post-event forensic work becomes an extremely simple process. And you can go further by reversing changes that occur against policy. This means that policy compliance is not only reported upon automatically, but it can be enforced via automation as well. The identity audit solution becomes an internal affairs system for the organization protecting it against the misuse of properly granted permissions. And in turn, it facilitates the investigation and sometimes even prevention of a breach event.

Conclusion
Identity Auditing is about verifying that the IT controls in place are actually achieving the goal of the security policies that they intended to enforce. Often, the biggest threat in IT related to identity and access control comes from internal users with privileged access. Identity Audit solutions can reduce organizational risk and help achieve compliance by policing the power of identity through system reporting and real-time monitoring.

Internet InSecurity

I stumbled across this today

and thought it was pretty cool idea. Use a 3-minute video to educate employees on the dangers lurking in their inbox and reduce your enterprise risk. Nice and simple. And free.

Then, this evening I saw this

IRS employees giving out usernames and passwords to someone who called them on the phone and didn't even attempt to identify themselves. Why worry about password hacking techniques when all you need to do is call up Jerry or Sally at the IRS and ask them to change their password so that you can use their account? Well, at least the IRS doesn't have any sensitive information in its systems. (pardon the sarcasm)

And I remembered this

People don't even bother to look for the security mechanism (SSL icon or the HTTPS in the URL) when it's present so they can conduct their Internet banking.

And I recalled the old adage

We made it foolproof and they produced better fools.

We really have to take users out of the equation and make the security mechanisms invisible. Or make it impossible for them to accomplish a task without taking proper precaution -- like maybe build a browser that doesn't accept any form input unless the site uses SSL with a trusted certificate so the user doesn't need to think about that stuff. Of course, even that won't stop the old phone-call-password-change gag.

It makes you wonder about all the work being done on the identity metasystem for a secure Internet. Putting users in charge of their own information sounds dangerous. Are Jerry and Sally going to take their secure infocard with SSN and credit card info and send it to any site that asks for it? After all, why create more than one card? - that sounds like work.

As a society, we seem to have a massive mental block related to digital security. Maybe we need public service announcements on TV and radio about digital identity theft and secure password management. I think it'll be another decade before the Internet security issue is really figured out for the masses. Unfortunately, it may take that long for general knowledge about computer security to infiltrate society and for the security technology to meet people half-way with making security transparent.

Livin La Vida Compliant

I just read a compelling white paper that I found on the IT Compliance Institute site. The theory behind the paper complements what I wrote in March of 2006 about the Identity Management Project Continuum:

Implementing IdM is not a single project. Nor is it even a few stand-alone projects. I call it a continuum.

I also mentioned others who called Identity Management a lifestyle. Compliance should be thought of in the same way. When a company aligns IT with good security practices and lives it on a daily basis, compliance happens by default. If you try to shift an entire organization into information security compliance to meet a particular audit or react to a breach, you're going to have your work cut out for you. And you're going to feel like a mouse in a wheel never quite catching up to where you want to be.

The paper encourages organizations to "adopt a culture of continuous risk management". It's worth a read for organizations who want to understand how to achieve some level of compliance -- or maybe just to minimize their overall level of risk.

In Dave Kearns' Network World newsletter today, he mentions an old truism that you should "make the cost of pilfering an asset higher than its value while keeping the cost of protecting the asset lower than the cost of replacing it." There's some truth to that -- it's a juggling act. Luckily, good security practices span across assets making the cost of security minimal on a per-asset basis. But, I think Dave's point fits nicely with the ideas above. Getting your organization into a culture of compliance will enable you to balance cost with risk and make your long-term security costs more predictable. And when regulations and compliance rules change, you'll be ready.

CIO.com - Identity Management Primer

The next time you're asked to answer the basic question of what is identity management? you can point your audience to an article at CIO.com titled ABC: An Introduction to Identity Management. Writer John K. Waters provides a nice high level view of the capabilities of IdM systems. He's a little simplistic on the technology part, but if this is the question you're answering, that's probably OK.

IdM... So simple a caveman could do it

This isn't new, but I hadn't seen it before. ...not sure where it came from or how I found it. Hopefully, I'm not contributing to the exposure of someone's actual IdM architecture.

Boeing Data Theft: NetVision Use Case

An Information Week article titled Boeing Employee Charged With Stealing 320,000 Sensitive Files discusses a massive data breach by a Boeing insider. It's another illustration of the fact that the biggest threats for organizations are insiders. The perpetrator (Gerald Lee Eastman) was ready to share Boeing's sensitive information which could cost Boeing as much as $15 billion in damages.

This type of attack is a good use case for NetVision file system monitoring (part of our NVMonitor product). The article explains that Eastman had to exploit a weakness in Boeing's computer system to access the stolen files. Over the course of two years, he methodically searched the Boeing systems looking for unprotected file shares and was routinely denied access to many. As he searched for files and found ways around the file system security mechanisms, NetVision file system monitoring could have caught the behavior and alerted security officers with each attempt. ...nipping this issue in the bud two years ago when it began.

Anatomy of an Identity Audit project

In speaking with a number of customers about Identity Auditing, it's pretty clear that there's a lack of clarity in the space. And customer needs differ. Some customers want help figuring out how to navigate the regulations that govern their industry. Others want a solution that puts them in compliance. And yet others are looking for a solution that proves that their controls are working. I think this variety of needs is symptomatic of the fact that each of those customers may be at a different stage of the Identity Audit project cycle. Even if you haven't called it an Identity Audit project, simply defining policies related to identity management & access is the first step toward an IdA solution. Here's a breakdown:

I. Determine Policies

Organizations may base IT security and identity-related policies on any number of requirements.

a. Often, identity policies are driven by external regulations. Sarbanes-Oxley and HIPAA as examples help companies determine what security-related policies to implement.

b. Another set of policy drivers are industry standard best practice frameworks like COBIT or ISO17799. An organization may choose to comply with one of those standards and allow it to determine many of the identity policies.

c. Of course, risk mitigation is an obvious driver of security-related policies. So, an organization may implement certain policies to achieve a more comfortable level of risk. For example, a company with no regulatory or standards-based requirement for two factor authentication may still choose to implement a solution to minimize risk associated to a given application.

d. Some policies may be based on business enablement requirements. For example, the policy decision to grant employee access to a given set of files may not be related to regulations, standards or risk mitigation. It may be driven by a new revenue opportunity that's success is dependent upon employee access to those files.

II. Implement Controls

Identity-related security controls can be implemented in a number of ways. A common way to implement policies on a Microsoft network is to build policies into Active Directory and leverage Microsoft Window's built-in file system access security. Access to systems outside of the Windows file system can also be granted or denied based on Active Directory group memberships (via LDAP calls). Identity Management tools help implement controls by enforcing business rules during the user provisioning and reconciliation processes. There are numerous third-party applications and in-house solutions that can help implement identity controls. For example, a PKI infrastructure may be implemented to meet a two-factor authentication policy. An entire book can probably be written on the various methods for implementing identity-related policies. Generally, all of the software vendors in the IdM space attempt to provide this capability to some degree.

III. Test and Confirm Controls (Identity Audit)

Once policies and controls are in place, an organization can start to think about testing and auditing those controls. The goal of these audits is to ensure that the controls in place are putting the organization in compliance with its defined policies. If the policies are driven by regulation, then proving that the policies are being properly controlled also confirms that the organization is in compliance with that regulation. This is really the goal of identity audit solutions -- to ensure that the identity systems in place (which implement controls) are effective at enforcing adherence to an organization's identity policies.

Conclusion

Hopefully, the above provides a basic overview of the core components of identity auditing. One of the main take-aways should be that it's near impossible to prove compliance without defined policies. Without clearly defined identity policies, what would you be complying with? I suppose an argument could be made that there's value in just auditing that the identity system is doing what it's supposed to do as determined by the identity system's requirements document. But, I think the real value lies in proving that an organization is meeting its identity-related business goals as determined by its identity-related policies.

My daughter is on the cover of Wired

...at least she is on my copy of Wired. They ran a promotion a couple of months back stating that if I send them a photo, it'll appear on my copy of the July issue. This type of personalization is a small example of what happens when we have identity figured out. Some of what we do (identity management) is about security -- and we tend to get caught up in that part of it. At least I do. The other part that we need to keep in mind is the enablement that comes with strong identity controls. If you have control over the identities in your systems, you can leverage that control to create opportunities that didn't exist before. Wired found a way to make its point about the hyperlocal, totally personal geoweb by sending me an ultra-localized version of their magazine. So local in fact, it's just for me. And as a proud dad, I couldn't wait to dive into this month's issue. It's a win for Wired, its advertisers and its customer (me). Think about what the right identity management solution can enable your business to do!

Good-Enough Compliance?

In this article from CIO magazine a few months ago, Allan Holmes discusses the challenge of surviving a regulatory audit. This excerpt sums it up:

"The dirty little secret here is that everybody tries to figure out how much risk they can assume without being embarrassed or caught,” says David Taylor, a former Gartner security analyst and now vice president for data security strategies for Protegrity, a security and privacy consultancy. “The people I regularly talk to are trying to figure out if [their security] fails, what’s the smallest amount they need to do to stay out of trouble and how they can blame someone else."

To make matters worse, different auditors interpret the regulations differently and enforcement metrics are open to interpretation. Holmes points to another article on the ROI of noncompliance in the mid market in which he quotes a PWC advisory partner as stating that "You can get 80 to 90 percent of what you need to find ...and that does a lot to comply." In a related article, back in September, CIO pointed out that executives across all industries are making slow but incremental improvements in deploying information security policies and technologies.

Looking at all of this information together, it seems that an extremely functional tool set that maximizes value on the dollar and gets an organization 80% down the road toward full compliance may be more compelling to many organizations than an all-encompassing solution that consumes a huge portion of the security budget (and effort) and gets them closer to 90% or 95% down that road.

I believe compliance is more shades-of-grey than all-or-none. But, how much so? Holmes seems to be suggesting that it's extremely open to interpretation and that executives are constantly looking to deploy a minimalist solution that will win the CYA game while exerting as few man-hours and dollars as possible. It's an interesting discussion to be sure. Thoughts?

See the Statue

An old friend has migrated to a new blog titled Marcus Lasance's Identity Management and Privacy blog and posted today about the relationship between identity and philosophy. It's a topic that immediately caught my attention because I was a philosopher before I was a techie. I did my undergraduate work in Philosophy at a small mountainside university and I often took long hikes up the mountain to reflect on life's big questions. That was back when I was a user - you know, one of those people that just logs in and uses a computer without thinking about what's happening under the hood. It's been a long time. Do you remember when you were a user? Enough digression.

For me, the take-away from Marcus' comments is that we should remind ourselves to remove our blinders as we envision a new system design or architecture. We all have blinders of one kind or another - whether it's prejudice against data redundancy or preconceived notions of identity. We ought always to start with the essense of what we're trying to build and work outward from there - like Michelangelo who saw the statue within the block of marble. The question you should be asking is: What are the business requirements that we want to solve? If they're unclear, start over and try again. If they are clear, make sure that your design decisions support the successful meeting of those requirements and don't get caught up in pre-existing ideas about Microsoft or databases or enterprise architecture. Thanks for the reminder Marcus!

More on LDAP and the Novell-Microsoft Bridge

While at Tech-Ed, I picked up some literature on the efforts of Novell and Microsoft to build bridges with each other toward interoperability. I found that they also have a web site on this topic where you can still read the original press releases and FAQs from November 2006. Conspiracy theories aside, interoperability is probably a good thing.

While I was looking for more info on their planned directory & identity interoperability, I came across an article titled Novell eDirectory vs. Microsoft Active Directory. I can assure you that it's not part of the interoperability literature. In fact, I wouldn't be surprised if it's soon taken off line to preserve the recently positive flow of energy between these two companies. While it's clearly and unapologetically written to sway would-be buyers toward Novell's directory product, it's quite an interesting read for those evaluating LDAP options. If you read my introduction to LDAP directories and are ready for a more thorough drill-down that doesn't require you to read the LDAP RFC, it's a good next step. Novell provides a thorough business level view of what to look for in a directory server.

Incidentally, I didn't find much on their plans for directory interoperability. From what I could find, it sounds like any identity interoperability will initially be at the user access layer and not at the data storage layer. If you have any more details, please comment!

NetVision

I mentioned previously that 70% of electronic attacks originate inside the firewall. And 90% of attacks are perpetrated by technical employees with privileged access. These are FBI/Computer Security Institute stats. I don't have a link to the original source, but I've seen it quoted in numerous places across the web and by numerous organizations. I believe the original data should be at gocsi.com, but I didn't have luck getting that site to load.

This isn't just stats from a survey. This is real world. Even from our common experience, we know that Joe from accounting and Sally from Marketing aren't cracking the DBA password and writing the database information out to a private FTP server for sale on the black market. It's the DBA who already has access that realizes how easy it would be and figures what the heck. While at RSA, I talked to customers about the shift from perimeter-centric security to information-centric security. I primarily focused on authentication of users, access control to information and data protection via encryption technologies. My next move focuses on the same threat, but from a different angle.

NetVision is a company that's been around 12 years and has a strong legacy position in the Novell Netware solutions arena providing audit, reporting and monitoring of Netware environments. In 2003, when Novell purchased SUSE, the writing was on the wall. Netware may not be the operating system of the future. NetVision made the natural move and began to support eDirectory and SUSE Linux. Now, NetVision supports Active Directory environments as well.

So we now have the ability to provide audit, reporting and monitoring of Windows, Netware and SUSE Linux environments to ensure that organizational security objectives are being met. How does that relate back to the threat mentioned above? Well, in the identity management arena, your privileged users are the domain admins, enterprise admins and super users. If you're one of those privileged users and you want to hide your tracks, you can just create a new user, grant elevated rights, logon as that user to perform some actions, then remove the user from the system. In many environments, there's no way to prevent that or even know it's happening. NetVision can enforce security policies even amongst the system administrators. We can intercept an attempt to skirt the security policy, reverse the changes and send alerts to appropriate parties. And we can provide a nice audit trail of what changes were made, when and by whom. NetVision is solely focused on the identity space. Primarily, we're looking at data in AD or eDirectory, but also File Systems, Event Logs and more. What we're not looking at is Firewall or IDS logs -- we're not trying to be a solution that would consume logs from every device on the network. And that gives us a leg up when it comes to drilling down on identity information.

I think we're in a very important space and we're presented with a unique opportunity to bring identity management to the next level with regard to integrated policy enforcement. I know that sounds a bit theatrical, but I'm excited to be ahead of the curve on this one. I don't know the stats, but most companies are running Windows/AD or Novell. And some have started to implement IdM to the extent that user account creation and/or modifications are automated -- maybe they even keep an audit trail, but there's still a big need out there for the ability to provide reports on whether or not we're in compliance with our intended policies. And it's even better if we can prevent or reverse an attempt to purposely subvert policy. And we can. Ask for it wherever quality identity solutions are sold.

At Tech-Ed?

If you're in Orlando at Microsoft Tech-Ed, please stop by the NetVision booth tomorrow and say hello.

More on The End of IdM

More evidence of the end of IdM and Identity being baked into the platform as BMC is forced to discontinue it's .NET Identity Management suite. I would blame big bad Microsoft, but I think this is just more of the same with the entire industry. And there's actually some value to having baked-in Identity capabilities. But, it's more foreshadowing that the end is near.

Data Loss Worse Than I Thought

Here is the list of Data breaches provided by the Privacy Rights Clearinghouse. We keep hearing about the same two or three events (VA, TJX), but there seems to be a new one almost every day. And the data is sneaking off the network in almost as many new ways as there are incidents. If you're building a data security policy, this list can be helpful in identifying areas where policies can be useful.

Information Centric Security

I received an email today asking for clarification on the concept of information centric security. I don't know if he'd want me to use his name, so I'll call him Dan. Dan watched Art Coviello and Bill Gates speak about information centric security but felt like he wasn't getting the whole picture. The main point of confusion seemed to be that Dan is technically-minded and wasn't able to see a clear path from nice story to technology solution. I'll see if I can help.

The move from perimeter security to information centric security is really a paradigm shift. It's a new way of thinking about securing enterprise information. It's not a specific technology or even a specific set of technologies. Five years ago, securing an enterprise meant standing up hardened firewalls and protecting against incoming email attacks. But, we've seen that this type of security is insufficient. 70% of electronic attacks originate inside the firewall. 90% of attacks are perpetrated by technical employees with privileged access. So, how do you protect against that? Well, you apply security to the information itself rather than only building walls around the network.

Now, to get to Dan's question. How is that security implemented? As I mentioned, there isn't any one particular technology set that provides a silver bullet for this problem. Solving the information centric security challenge requires a long hard look at what information needs to protected, where it lives, who should have access, what is the perceived and actual risk associated with loss of that information and what are the policies or regulations associated to that information. That's the first step and it's as important as any technology portion of the solution. One you know what your information security requirements are, there are a number of technologies that can be combined to provide a secure information infrastructure. These include authentication & authorization solutions, a secure hardware & storage platform, data encryption & key management and audit & reporting solutions. So, to give a few examples, information centric security solutions could include the following:

• Required strong authentication to servers that store information (even for local access in the data center)
• Encryption for sensitive information as it's written to a database or file system
• Encryption of information as it's written to tape for off-site storage
• Rotation and secure management of encryption keys
• Protection of individual files via DRM so that sensitive information can not be shared via email or USB key
• Real-time alerting when policy is averted
• Easy to use reporting on the information life cycle

Part of Dan's question was specifically about RSA and EMC. Hopefully, it makes sense how RSA/EMC can provide customers with a secure information infrastructure. EMC has core strengths and industry leadership in each of the sample solutions. The actual technologies include RSA SecurID, RSA Key Manager, RSA enVision, EMC Documentum with IRM and EMC's SAN solutions. And there are a wealth of others. Some requirements are better met by partners - like whole disk encryption for laptops. And some may have yet to be developed or marketed or just widely adopted. Dan specifically mentioned a Mandatory Access Control -based file system. Interesting concept, but not one I'm too familiar with.

Hope this helps.

Identity Management Success Factors

In his post on Identity Management Success/Failure Factors, Mark Dixon asks:

Please send me your list of the five most important factors that contribute to the success or failure of Identity Management projects.

I know this is going against the grain, but I think the reports of wide-spread failure of Identity projects are grossly exaggerated. At least, troubled projects are no more prevelant in the IdM space than they are in relation to other technology projects. Technology for enterprise information management is inherently complex. But, I've been a part of a number of successful projects - their success measured by the feedback of the project sponsor at the conclusion of the effort. And I've spoken to a number of people in the field who tell similar tales. I only occasionally hear a real horror story about an IdM project. Usually those troubles are based on misaligned expectations or poor project management. That is, an executive sponsor expects a project to solve 100 problems, but the implementation only solves 50 and it seems like a failure. Or a development team tries to build a solution based on a half-baked design which keeps changing and there's no change control in place so the project quickly falls off schedule and over budget.

With those comments in mind, here is my list:

1. Establish clear and attainable objectives up front. This is vital. The only way to acheive success is to make the criteria for success clearly known and agreed-upon by all those involved. If this process is rushed or not clearly articulated, then there will be no consensus on the success of the project. While establishing criteria requires some knowledge of the business and the technology, this is primarily a perception issue -- not a business challenge and not a technology challenge. But, I think it deserves the #1 spot on the list.
2. Strong Project Management. The project manager is the person who establishes the objectives and manages the project toward those objectives. In a complicated project involving complex business and technology challenges, strong management is extremely important to keep things on track.
3. Build the Right Team. If the project requires interviews with business personnel, don't rely on a programmer and a DBA to deliver the project on their own. And don't expect a project manager to create a technical architecture. You need to understand the skills and roles required to reach your objectives as well as the capabilities of those on the team. Get the right team in place to cover all the roles. If the DBA is also a good business analyst, then maybe they can play two roles, but pay attention and spend the time and budget to build an effective team. I would also say that previous experience with the specific technology you're using would be great, but it's actually less important than having the right people in each role.
4. Have a Project Champion at the Right Level. IdM projects cross organizational boundaries and sometimes cross organizations. They tend to need executive sponsorship. The projects that were easiest for me to get through were sponsored by the CEO (or other business leader) and not only the CIO (or related technical folks). I was once working as a consultant interviewing a phone system admin for a provisioning project. During the interview, he asked if we had seen the movie Office Space because he felt like he was interviewing for his own job. This was, of course, not the case. But, it illustrates the importance of executive sponsorship. If it was the AD admin instead of the CIO that had brought us in, we may have had trouble scheduling time with this particular gentleman.
5. Build Cyclical Iterative Successes. Although I think the first four items are a sufficient recipe for success, if I had to come up with a fifth item that would make success more easily acheiveable, it would be to follow an iterative process rather than trying to do too much in a single project. Nothing builds momentum better than a few quick wins. In a large IdM rollout, this could mean having a project just to create an enterprise directory. Don't build the directory as the first step in the enterprise provisioning project but rather make the directory the result of it's own project. That success builds confidence amongst the team and the stakeholders. ...and divides up success into smaller, more easily measurable chunks.

There's definitely some overlap here with what Mark wrote. But honestly, I'd be more surprised if anyone presented a list that didn't have significant overlap. Thanks for the effort Mark!

SAP acquires MaXware

There are some readers of this blog who read based on their interest in MaXware and MaXware's identity management products. Well, if you haven't seen it anywhere else, MaXware is now part of SAP. Congrats to all those who worked hard to make MaXware an attractive purchase for a successful company like SAP! I suppose it's too early to speculate on the future of MaXware's products, but... I don't know SAP as a company that would bring to market a stand-alone utility product like a virtual directory or metadirectory. I'm sure however that MaXware's products will compliment SAP's core product architecture. This may be good news for Radiant Logic, Symlabs and other virtual directory vendors who may begin to see less of MaXware in customer product comparisons. On the other hand, if SAP decides to throw their weight behind MaXware's products as stand-alone offerings in the IAM space, I wouldn't want to be the competition.

Identity via SOA

Nishant Kaushik of Oracle provides an excellent overview of Identity as a Service and raises a good point about the ambiguity of the phrase. The industry has become comfortable with the phrase Software as a Service to represent hosted software solutions. So, IaaS will naturally bring to mind hosted Identity services analogous to that of SaaS. We have enough ambiguity and confusion in this space, don't we? (see: SSO vs. RSO vs. ESSO) I vote for a rename of the enterprise identity-via-SOA concept. Then, mass education of this important concept. If we want people to immediately understand what this is, how about something along the lines of i4SOA - Identity for SOA. Of course, this can cause confusion with providing identity and security services for the SOA itself. Or IvSOA - Identity via SOA. Whatever we call it, this is the direction we need to be heading. Build an identity services layer based on open protocols and reachable via SOA standards and integration & infrastructure flexibility will become significantly easier to achieve. Thanks Nishant! The diagrams are well done.

TJX Breach at $1.6 Billion, points to poor key management

This article estimates the cost of the TJX breach to be about $1.6 Billion. That's a big number. It also points to this article which suggests the core of the compromise may be related to poor encryption key management. Read that last sentence again. $1.6 Billion because of poor encryption key management. That's amazing to me.

I've spent nearly a decade building identity and access management solutions some of which seem very complex. In addition to identity and access management, security infrastructures have perimeter security (firewalls), intrusion detection, anti-virus, anti-spam, anti-malware, etc.. How often have you heard people focused on building strong encryption key management? Probably not enough. I have to admit that I didn't think much about key management before a key management solution became part of my portfolio. It's a very interesting organizational challenge. It's frightening how insecure systems can be -- even if they have strong data encryption. How the encryption keys are managed is probably more important than the strength of the encryption itself. Yet again, prior to joining RSA I never heard IT managers talking about their encryption key management projects. And it seems like such a simple thing.

Think about it. If all of the data for 45.7 million users is protected with a single encryption key and the key is stored in plain text somewhere on the network. Then, the strong 2048-bit AES algorithm used to encrypt the data really can't be that effective. And each place where encryption is happening throughout an organization probably has another key sitting somewhere -- on a dev server? on a cd in a drawer? in a spreadsheet? Not good. If your organization has this problem, get your arms around it. Solutions are available that allow you to use strong keys, rotate keys regularly, distribute keys securely and ensure that you'll have the right key when you need it for decryption (even years down the road).

Jeff Bohren's blog

I'm a little late, but Jeff Bohren of BMC started blogging back in February. I met Jeff briefly while I was working with OpenNetwork technologies (since acquired by BMC). Jeff is a bright guy and I suspect his blog will be worth reading. Jeff has hard core real-world experience building and deploying solutions - which I think is an especially useful background to bring to the blogging world.

What is a Directory? ...LDAP, AD and ADAM

Note: This is not content for LDAP professionals. This is
content for the LDAP-confused. Proceed with caution.

Overview

An LDAP directory is simply a type of database that is hierarchical in structure. LDAP is the protocol used to interact with that database. So, when you hear someone refer to putting data into LDAP, what they really mean is using the LDAP protocol to put data into a directory (a hierarchical database that communicates via LDAP).

Relational Databases

The databases used most frequently across today's IT landscape (Oracle, SQL Server, MySQL, etc.) are relational in structure. That is, data is stored in tables and data is connected to other data by way of relationships between tables. For example:

In this sample database, we see that Joe Johnson is a Clerk that reports to John Smith. Joe's job title is not in the same table as his name, but we know what it is because of the relationship between the tables. This is a relational data structure and it's the structure that's commonly used when we use the term database.

LDAP Directory Structure

An LDAP directory is hierarchical in structure. Joe's data would look like this in a directory:A directory uses the concept of an object to represent Joe's data. The directory schema defines the type of objects that will be allowed in this directory and what attributes are associated to those objects. Above we see that an object exists for Joe Johnson with attributes for employee number, first name, last name, job title and manager.

Directory Servers

There are a number of directory servers available on the market, including but not limited to:

• Sun Directory Server
• Novell eDirectory
• Oracle Internet Directory
• IBM Tivoli Directory Server
• OpenLDAP
• Fedora Directory Server

Note: I purposely left Microsoft off this list because I'll
cover AD and ADAM in the next section.

Each of the directory servers listed above (and most others) support a common protocol for storing, accessing, modifying and managing data. This protocol is LDAP. By standardizing on a common protocol, application developers can write their applications to store data in any LDAP compliant directory server. Organizations can choose to implement whichever directory server they prefer and feel fairly confident that an LDAP-ready application will be able to consume or interact with their data.

Vendor-neutrality is theoretically achievable with relational database servers as well. I say theoretically because the big database vendors provide add-ons to the standard SQL language that are convenient for developers but sometimes challenging for portability. The main reasons the industry moved away from relational and toward directories for some uses are as follows:

• Query Speed: LDAP directories typically provide faster query response times
• Ease of Management: LDAP's hierarchical structure makes it easy to assign rights and privileges to subsets of users as well as to enable delegated administration over portions of the directory tree.
• There are probably others, but I believe these are the two big ones - please let me know if I'm missing anything here.

Microsoft Active Directory

With the release of Windows 2000 and the migration from Windows NT as their business networking platform, Microsoft introduced Active Directory (AD). AD is an LDAP directory at its core but it doesn't necessarily play by all the same rules. Because AD is used to manage a network environment - authentication, access rights, user management, etc., AD needed to be much more than just a database.

Note: AD is a predominant part of most IT organizations today. As I travelled to various organizations as an IdM consultant, I almost never encountered an organization that didn't have a mature AD environment containing some of the most up-to-date employee data in the entire organization. Based on my experience, AD has become the de-facto enterprise directory for most organizations.

As the identity management market grew throughout 2000 and 2001, organizations realized the need to leverage LDAP directories more and more. Because AD was already widely deployed and held good data, many organizations wanted to leverage AD -- or at least AD data -- for their identity infrastructure. AD administrators however recognized the need to protect their AD infrastructure and most decided against using AD for anything outside of its core network management role. This is why Microsoft introduced ADAM.

Microsoft ADAM

ADAM (Active Directory Application Mode) is based on the same core LDAP technology on which AD is based. But ADAM installs without all the overhead of the OS and network management capabilities that AD provides. ADAM is a stand-alone LDAP directory store similar to those provided in the list above. ADAM does not require AD to run -- it's not an extension of a given AD environment. But, it can be used to augment the functionality of AD. For example, some organizations use ADAM to store employee information for white pages or other applications that they prefer not to query AD directly. Other organizations use ADAM to store non-employee data while relying on AD for employee information. One interesting use of ADAM is as an authentication proxy. You can send an authorization request to ADAM and have it pass the request to AD - thereby leveraging AD credentials while disallowing applications to connect directly to AD.

Conclusion

A directory is just a type of database. LDAP is a way to communicate with a directory. ADAM is a stand-alone directory and not a feature of AD. There are lots of LDAP directory varieties to choose from.

Let me know if I should include additional info here. My main point was to tackle the simple points made in the conclusion. I run into confusion on those topics quite often.

Truth really is sometimes stranger than fiction

This has got to be the weirdest story of on-line hacker activity that I've seen. It references another interesting story about the hacker economy.

The End of IdM

I've been telling people over the last 2-3 years that in 5-6 years (circa 2010), there will no longer be stand-alone identity management companies. IdM will be rolled into the platforms. We've seen this Nostradamus-like prediction coming true as Oracle has moved in that direction for a few years now - Peoplesoft, Oblix, Thor, OctetString. And Sun too, of course. Microsoft has integrated many security features (anti-malware, firewall, encryption, etc.) into Windows. And now, I'm hearing more people saying the same. Especially at EMC. Art Coviello made this point clearly at the RSA conference. It's one of the reasons I joined RSA as they were becoming part of EMC. The future is wildly uncertain for smaller independent security providers. EMC really gets it. The focus is on information-centric security. The systems that control your information need built-in security -- not bolt-on security. Bill Gates' RSA address had much of the same focus.

Gates urged companies to think beyond traditional "glass-house" and perimeter-centric security strategies focused largely on keeping intruders and malicious activity out of corporate networks. What is needed, he said, is a "far more powerful paradigm" that uses security as a way to secure information access, not as an impediment to access.

"People want more access" to information, and they want that access at any time, from wherever they happen to be, and via whatever device they happen to have, Gates said. "Traditional network perimeters are fading away," mandating new approaches to security, he added.

This year and 2008 may be the last years for the independents. So, it's time to nail down the technology and get it into your favorite platform - the end is near and the paradigm is shifting.

Phishing Special Report

Another interesting paper from RSA’S Anti-Fraud Command Center (AFCC)...
Phishing Special Report: What we can expect for 2007

Phishing attacks are more numerous, more varied and more creative than ever. And this on the heals of a NY Times report about a study by a few MIT and Harvard researchers that suggests that site-to-user authentication (generally believed to be a good anti-phishing solution) is ineffective for many users. The full report is available here.

I enjoyed Don Park's comment on the subject:

While I have little doubts about their integrity, I do wonder if the study is not flawed. For example, doesn't using people who willingly let others observe them signing into their bank account for such a study skew the result? It's probably not as bad as counting virgins among prostitutes but I would like to hear more about how they accounted for such problems.

The report does note that participants may have had reason to behave less securely than they would in the real world. But I'm not completely surprised at the report's findings -- the report isn't really saying anything about technology -- it's talking about people.

An interesting premise was made by the researchers:

In real life, security is rarely a user’s primary goal.

Based on the context of that statement, I believe what they're really saying here (in an understated way) is that security is often the furthest thing on a typical user's mind -- the site-to-user authentication (and other security technologies) failed because the user's weren't even trying to look for them. So, even if the technology is effective, it's vitally important to educate end users about how the technology works and what's at stake.

Things are clearly going to get worse before they get better. Since there's no silver bullet that can put an end to all phishing attacks, we can only attempt to provide the right tools and educate people as much as possible.

Don't run with scissors... Look both ways... Wear a helmet... and always verify your financial institution prior to providing credentials. OK - I need help with the wording, but the point is that we need to get more mainstream about on-line security education.

Vantage from RSA

The latest edition of Vantage Magazine is available and there's a nice write-up on my old group at Unisys. It's nice to see them in print again - there are some wicked smart folks over there.

There's also some good information on EMC's vision for Information-Centric Security. After all the billions spent on security in recent years ($40B in 2006), less than 20% of companies believe that their information is secure. Firewalls are not enough. This issue provides some insight into how EMC will help solve the problem.

Also - look for the article on Vouching from RSA Labs. I haven't seen this idea anywhere else and it's a nice idea for helping people with lost or forgotten tokens -- without having to burden the Help Desk or use traditional User Self-Service.

re: Synchronization versus Virtualization

In his entry on Novell’s Cool Blogs, Volker Scheuber discusses the use-cases for virtual directories versus metadirectories and asks for input. Considering my number of previous posts on this topic, I felt an obligation to respond.

I've done a significant amount of services work around both metadirectory and virtual directory technologies. My last company had both and my current company offers neither. The bottom line is that if I were designing an IdM solution, I would want both options to be available. As with any enterprise technology, there's usually more than one way to accomplish a given goal. Most IdM data integration requirements can be met with either meta or virtual technologies. However, there are some scenarios that, for all practical purposes, require one or the other. A while back, I posted some common scenarios where a virtual directory can be really useful.

Even for some of these scenarios though, you may be able to achieve a similar result by standing up another data store and setting up data sync rules with a metadirectory. But it often requires a significant amount of programming that would need to be maintained in addition to the new data store (LDAP or other) and related infrastructure.

Here’s an example:

Let’s say you were deploying a COTS application for insurance claim processing and security is important. The app uses an Oracle database for system data and is built to leverage an enterprise LDAP store (eDirectory, Active Directory, etc.) for authentication. Each employee that needs access to the system already has an account and credentials in the enterprise directory (ED). The system leverages the ED’s groups to grant or deny access. And of course the ED user needs to be enabled.

Due to the sensitive nature of the material, a requirement is made that the system should not allow access to the app unless the employee is punched-in to the company time-clock system. So, if an employee were to piggy back off of a manager’s home VPN connection, they could not access the system unless physically punched-in at work where all claim processing personnel are monitored. The time-clock system has a MySQL database with both system and user data. The APIs for the claim system and the time-clock system are both difficult to work with and complex to maintain.

What are the various ways to meet this requirement?

You could potentially try to work with the API’s and write a custom authentication module that would connect to the time-clock system and verify that a user is punched in before granting access. This would require some internal training, development time and will need to be maintained as either vendor releases new versions in the future.

You could implement a metadirectory solution that sets the ED user as disabled each time status changes in the time-clock system. This may require some custom code, but should be fairly easy to implement. However, we don’t want to disable users in the ED each time they’re punched out. They still need access to HR benefit info and other systems. Not to mention that disabling a user in the ED may trigger other unwanted events to occur (de-provisioning).

You could have the metadirectory solution switch to a different attribute instead of disabling the user, but you’re back to writing a custom authentication module. Also, these metadirectory options will likely introduce some latency because metadirectory sync jobs are typically scheduled. So, there may be some window of time between when the user punches out and when the system denies access. This time window can be exploited to circumvent the intended security controls.

Or – you could have the claims app connect to a virtual directory that is configured to join data from the ED and the MySQL database in a way that is transparent to the claims app. The app sees the virtual directory as an enterprise LDAP directory, but when the user is not punched in, the user appears to be disabled. This is generally a very simple thing to configure for a virtual directory. And if the claims app expects a single group to grant or deny access but the ED groups are arranged differently, the virtual directory can display group memberships however is most appropriate for the app.

Let’s further suppose that the business rules are changed to grant restricted access for the user when punched in but at an alternate location. The virtual directory can be easily configured to set a flag indicating restricted access based on the requestor’s IP address. This is not easily accomplished with a metadirectory solution.

And it’s a plus that the same virtual directory can be used to display user data differently for any number of systems that need access to it – and without altering or moving the data. As we move toward increased regulations and encrypting sensitive data where it lives, reducing the number of data stores that need to be managed and encrypted is an advantage in itself.

Having said all that, I can come up with a number of examples where a metadirectory is clearly a better option than a virtual directory, but I think those are generally easier to see.

Hope this is useful.

2007: Encryption Everywhere and Phishing Attacks

Encryption Everywhere

In this article from CNET News, Jon Oltsik describes 10 things to know about info security in '07. Number 5 on his list is encryption everywhere. I agree. I admit that I didn't think much about it until joining RSA on the day that it became the security division for EMC, but there's an advancement happening in information security that shifts the focus from perimeter security to information-centric security (an EMC term). Data encryption, therefore, seems to be on everyone's hotlist for 2007. It's about protecting data where it lives -- not just in transit or while being used by a particular app.

Will Sturgeon in his article posted on silicon.com supports the premise that data needs to be protected from inside the perimeter. He quotes Jay Heiser, research VP at Gartner, as saying:

"For many organisations, the biggest risk will be insiders, not outsiders. The fact is that a significant amount of proprietary and regulated data walks out the door everyday"

In this article from Information Security magazine, Marcia Savage lays out IT priorities for 2007. She points out that in 2007 IT managers will shift toward focusing on the inside threat.

All of this data encryption will present significant challenges for Identity and Access Management professionals as well as application developers. Encrypting data means use of encryption keys which need to be managed. And determining who should have the ability to unencrypt data. And making sure that users who have rights revoked are no longer capable of performing unencryption tasks. It should present a lot of interesting discussions.

Phishing Attacks

Another commonly mentioned priority for 2007 is the prevention of Phishing attacks. For vulnerable organizations, Anti-Phish efforts will be critical.

At RSA's Phishing Reports site, you can download a copy of December's On-Line Fraud Intel Report. A quote from the report:

The number of institutions coming under attack rose to an all-time high the final month of the year, surpassing the previous high of 195 set in July. This was largely a result of fraudsters stepping up the use of security-upgrade-related cover stories in advance of the FFIEC guidance deadline in the U.S. That said, the number of brands being phished is not expected to fall off markedly in Q1 ’07.

That's nearly 200 different organizations in a single month reporting phishing scams. That means that someone you know is likely being phished for information (if you're in the U.S.).

Here's a place to find more fraud stories from the FBI and NW3C.

Happy 2007!