Yes, I do speaking engagements

I was asked by two peers recently if I do speaking engagements to trade groups, at conferences, or to large companies that aren't salesy, but provide opinionated analysis and can talk technology with business users.

The topic arose when they were asking what analysts I knew, who I had used in the past, etc. because while they are extremely valuable for research what they really want are opinions about what to do and what to avoid - from experience. I would actually like to see a residency program in the Gartners, Burton , and Yankee groups where you go out for 6 months to a year and work with a company in the field you analyze to see what really happens after your analysis is implemented.

I'll even show up in my kilt...

identitystuff @ gmail.com

HSPD 12 Solution - Slam Dunk?

I was in our nation's capital yesterday for some meetings, one of which centered on HSPD-12. Specifically, what are agencies doing given the lack of guidance in the Presidential Directive other than do something by October 27th?

In a word - scrambling.

There were some interesting things that were discussed, specifically what HSPD-12 actually means agencies need to do to satisfy requirements fully and what really needs to be done by October 27th. What came out of the discussions was that agencies are focused on implementing a Physical Access Control (PAC) solution for new employees only. In my opinion this is smart for two reasons - focusing on this population means you get to see what the process should be with a smaller population without the baggage of the as-is process, and these are the most risky users to any agency - unknowns.

The other interesting thing we discussed was that there seems to be such a laser focus on PAC solutions that are card or biometric based, with little vision to the next iteration of HSPD-12 compliance which is Logical Access Control (LAC) which includes networks & IT infrastructure.

What I immediately picked up on was that these agencies will go through satisfying the guidance twice - once for PAC and once for LAC. The other thing I figured out after the meeting is that vendors and integrators are supporting this vs. doing the right thing in my opinion which as an integrator - pick a PAC and integrate a LAC solution on the same platform. One platform to support, and even better is that there is one platform to implement, you just do it in two phases.

We cooked up a viable solution by the end of the meeting that covers both PAC & LAC and I will be talking to Federal SI's and PAC system vendors since I will bring the LAC component to the table with integration in 4-6 weeks, which means there are 6 weeks to implement the early adopters, sign up others, and give every agency not only the PAC solution for HSPD-12 but the LAC part too.

If you're a Federal SI, email me - identitystuff @ gmail.com. We should talk...

I'll keep you all posted...

Insider threat - UBS

If you want to prevent this, email me and I'll tell you how. The perimeter isn't the most dangerous place anymore...

identitystuff @ gmail.com

July 21, Information Week - UBS trial aftermath: Even great security can't protect you from the insider. The recent UBS PaineWebber computer sabotage trial is a perfect example of the damage that can be caused by a knowledgeable insider with high-level access and an axe to grind. A company employee is already inside the perimeter, where the vast majority of the protective technologies sit. That same employee also knows what information is most vital to the company's ability to make money and sustain itself. He has knowledge of passwords, and he also probably knows what kind of machines and operating systems the company is running. An IT professional has all this information, plus he has access to the inner workings of the infrastructure. He has high-level privileges that allow him access to key servers and databases, and possibly even root-level access, which would give him all-encompassing power over the system. UBS PaineWebber's network was hit by a logic bomb in March of 2004. A jury last week found Roger Duronio of Bogota, NJ, guilty of two crimes: computer sabotage for building, planting and distributing the malicious code that brought down nearly 2,000 servers on the company's nation-wide trading network; and securities fraud.
Source:
http://www.informationweek.com/showArticle.jhtml;jsessionid=DY4LHGUFJWTSEQSN
DLPSKHSCJUNN2JVN?articleID=191000063

Intersting week in the trenches...

I had a chance to talk to some great companies this week about identity management, where they thought things were headed, how they now view identity management, and we shared some horror stories along the way. I also had a chance to validate my hunch that identity management and access control are converging and the convergence is best handled, and will ultimately occur in the network layer.

My first meeting was a dinner with a global financial services firm that like many global FS companies has an issue with how they operate in Switzerland, and ultimately manage the delicate and mandated balance of control, identity, and privacy.

As it was explained to me, you need to be a Swiss citizen physically in Switzerland to access Swiss Bank information. Because the system has a high degree of anonymity/privacy this is not easily accomplished when your networks in the Americas, APAC, and elsewhere are all connected, yet operationally Switzerland is a walled off silo.

The good news was that over the course of a couple of beers and some fantastic Chinese food, we came up with a solution that we both hope to pilot in the next few weeks that will segment users, by machine and by network, so that this company can know absolutely that the users are Swiss citizens accessing data from machines and networks physically in Switzerland. Very cool brainstorming in 95 degree heat in Manhattan.

Tuesday I met with a global information concern and we traded stories about IdM implementations. They had decided to abandon their incumbent vendor to go with one of the big guys – it was not Sun, BMC, or IBM – and they were very interested in learning more about what not to do in their implementation, which I felt compelled to share based on my experience of dealing with large organization implementations. We laughed a lot and I probably saved them $100,000-200,000 on sharing a few key questions they need to answer before they start thinking that they can jump in and start writing XML code.

Wednesday I met with a juggernaut in the IT business twice. Once in the morning to discuss the notion of removing anonymity on the network, implementing policy and ultimately enabling control of the entire network by user, device, or subnet. We met for 30 minutes and they asked us to stop – I’m thinking game over – and they asked us to come back at 4 pm to talk to a bigger audience that was working on a $400M project. Who was I to say no…

The 4 PM blew their hair back to the point that I stayed over another night to meet with an even broader audience to pitch the notion of control to. Funny thing is, they were far more interested in audit capabilities since that was the immediate need. What I learned was that in a project of this size, magnitude, and importance (people will die if it doesn’t go well) is that knowing what is happening in real time on the network by who is on the network and what they are accessing (whether they are supposed to or not) will drive the best possible policy development, and ultimately policy enforcement which is the end goal (I think) of implementing an identity management solution.

The issue with IdM to date has been establishing the correct identity of a user and automating what applications they get access to, as well as automating the termination of what applications they have access to. Control. I guess to a certain extent audit – how many users do we have? Are they legit/known? How do you know this?

The rub is that someone will always have root access to a server, and/or administrative rights to applications and guess what – they can establish whatever access they want without IdM or even in spite of it.

Network Layer vs. Application Layer Identity

I want to understand that given where technology is today, why anyone would want to implement an application based IdM solution. I used to do it for a living, until I saw a better mousetrap and went to work for the company, but in this day and age I can’t understand why a company would fund a large IdM project without asking a key question - In which layer of our environment do we want our solution?. Please feel free to comment on this one (or anything else I’ve offered including my Playbook, which is for application based IdM implementations). The biggest reason I can think of is that IdM applications are fairly mature, there are some best practices to follow, and there are hundreds of thousands of consultants who know how to implement the applications, but that’s as far as I get. Maybe the workflow tools embedded in the applications, but that does little to prevent a DB admin from going outside the workflow to write to the database/LDAP directly setting up a ghost account.

I thought a lot about the key differences between application vs. network Identity Management and one thing keeps ringing in my head – managing identity in the network layer, means that the infrastructure layer and the application layer are included in this, whereas an application based IdM solution includes the application layer and still allows access to and visibility of your network.

In the application layer, you cannot (to my knowledge) segment the network to block access to assets which is an issue in two key areas I want to look at – offshore vendor management and Swiss banking regulations. Both cases involve a US based company needing to extend their control offsite and out of country.

In the case of offshore vendors it’s probably a good idea to limit access to production systems to a few key people, and also have some level of control of what assets they can see and interact with. Customer databases, dev, test, and staging environments, and other applications that have high levels of restrictions for export control or compliance are specific areas where companies need to focus on. In the case of Swiss banking, if you are a bank operating globally, the Swiss issue has been a big one since you cannot have employees outside of Switzerland accessing information. If a person can get on your network, or the network segment in the case of a Credit Suisse First Boston or Citibank for example, then they can conceivably get access to things they are forbidden to access.

To this end, looking at an IdM solution that operates in the network layer provides several significant benefits over an application layer IdM solution:

1. Endpoint control outside company and geographic borders
2. Protection of Network, Infrastructure, Applications, and Data
3. Greater flexibility of policy enforcement by zones

Identitystuff @ gmail.com

Slide Presentation

This is a deck of slides I pulled together in about 30 minutes that gets to the meat of what an IdM project strategy needs to consider. The link is to another site where I can park files and it's not pretty, but the content is decent. At least my customers and peers tell me so...

identitystuff @ gmail.com

Has Your Deployment Been a Complete Disaster Too?

I’ve had two interesting discussions in the past 24 hours – one with a Fortune 10 that is a year into an Identity Management implementation, and one of our branches of Government, just getting started. The latter will benefit from the former’s experience and I think it’s of value to blog about since there are millions of dollars that could be spent elsewhere, returned to investors, or used for more research and development for noble causes and major problems.

I spoke to a buddy of mine I had done some work for and made his department successful in implementing an identity management solution. He did it the exact opposite way that everyone else did it, and is the only one of his peers who is done and successful and maintaining his system. The rest of the company, however is in total disarray, and those folks who jumped into their identity management projects with vim and vigor, are running away even more quickly. Apparently the promise of SOX compliance hasn’t showed up yet. The good news is they only have another 2 years of work ahead of them before they think they’re done, and that’s assuming nothing has changed in their environment or in their process, assuming their processes are known and documented to begin with. So I asked my buddy if you could hit the reset button, what would you do today? Verbatim response:

‘I would implement your stuff (TNT Identity) and SSO and that’s it. Total project done. All objectives met, all metrics met or exceeded, and for the cost of what we paid for our discovery documents alone.’

The second discussion I had was with a branch of the Government today. I went to meet two ladies who thought it was way too early to meet since they were just starting to look at what identity management is. I was pushy and asked for the meeting anyway, because whether we got to discussing a specific solution, product set, whatever, I would save them at least $100,000 in an hour meeting. I am happy to report we saved them at least $100,000 probably closer to $1M in initial project costs, not even including maintenance and support of the completed solution.

Want to know how I did it? Two simple questions –

What is your end goal? Audit Compliance or Policy Control/Enforcement?

&

Do you want to manage identity in the network layer or the application layer?

Coming up with answers to these two questions will pay for itself before you even start. Since the network layer includes the application and infrastructure layers, you will have killed three birds with one stone – implementing a global policy that governs the access of networks, servers, and applications using user identity (and/or machine identity) of authenticated user only. Add to this SSO and you have a simple, extremely effective way to manage identities. Whatever that means.

I gotta catch a flight, but I’ll expand on this later. If you want a slide deck that talks about this in some depth, and encapsulates the discussions, email me – identitystuff @ gmail.com

Are We Managing Identity Based on Incomplete Data?

I was thinking about a conversation I had last night with a friend here in Manhattan about Identity and what it means vs. what we perceive, and the deltas of the two.

Identity management means a lot of things to a lot of people depending upon your definition of it. That got me thinking about what is the definition of identity. Back in the day it was about a directory with a username and password, and in essence was a records management application - I managed attributes of your 'identity'. Well, what is that identity? Is it your role, is it what you say it is, is it your behavior, is it your device you use to interact with applications, is it what someone else higher up the corporate food chain says it should be to satisfy a particular momentary need (emaergency password resets, or TPS Reports)?

In practical application it is a mix of all of these components. As an IdM leader I am tring to manage all of these components and map them to a single piece of data (username for example, or SSN) and based on this component mix, come up with a way to make sure that what I believe is in fact happening as it should and is accurate.

Version 1.0 of IdM seemed to be movement from directories (user centric data files) to provisioning (building on that user centric data file to establish and implement an automated process). Now what? How do I add more value to the management part of Identity Management? What does the Management part of identity management mean, since we seem to have the Identity part of Identity Management mature enough to be useful.

Is Management validation? Is Management audiability, is Management all about enforcement? What layer should Identity Management take place - the app or the network layer. Having spent time in both worlds now for several years I have made the move from thinking about Identity Management as moving from the application layer to the network layer. If someone is on my network I want to know who it is, even if they are unknown, and I want to be able to control & enforce what they can see, what they can do, and what they can access.

There are typically fewer network admins than applications and corresponding application owners which means that there are fewer people who have access to the control and enforcement ability, which makes it more manageable than say an organization with 1000 applications and 1000 application owners. Which means you've added a ton of value to your application owners by protecting them and their feifdoms, to risk management looking at risk based security, and to the security organization from the badging folks' applications, to the sensitive databases with millions of user records.

Managing Indentity at the newtork layer gives you the ability to quickly extend YOUR control and enforcement to partner organizations and control and enforce what they can see, do, and access more quickly than to request an audit of their 1000 applications by talking with their 1000 application owners and trusting what they find, or inheriting their potentially higher tolerance for risk. It is being able to control and enforce YOUR policies whether your partners want to follow them or not.

I think this has a profound impact on managing offshore vendor access with a high degree of granularity, by being able to segment a network's access and only give access to certain network segments by offshore vendor or offshore project team by user and by their specific device. In so doing you're controlling access to the servers and applications they need to interact with, while staying within the risk tolerenaces that your company has in place, and insuring that your policies are being followed.

Another use case to follow soon...

Mark

identitystuff @ gmail.com

My Email to Clay Johnson 6/29/2006

When I first read the memo, I thought it was a draft to be reviewed before issuing, not the final copy see it here. So then I just read that there was another toothless memo issued that reminds folks of the August 7th deadline but provides absolutely no indication of what will happen if an agency does nothing.

So if I am a high level employee, what shall I do? My vote is... Nothing. Not until they give me some specific options on how to address the problem and not until I know what will happen to me. Why should I do anything other than what I'm doing if there are no consequences?

Have a great weekend.

And no, Mr. Johnson did not reply to my email. I get the sense it's like trying to talk a dog off a meat wagon...

***
Mr Johnson,

Am I totally naïve or do I not understand why guidance would be issued without guidance on possible solutions that exist in the marketplace? Is it so that any wrong choices don’t come back as a lawsuit down the road?

How are people expected to be held accountable, let alone do the right thing, and implement something that actually works to conform to the guidance issued by your office? Doen’t this have a chance to come back and bite you and your office personally for issuing guidance, with no solution, and another breach happens and it points back to this memo with your signature? I don’t get it.

As someone who keeps firms out of the papers every day, I am having a hard time understanding you issuing a toothless memo, especially when it can and probably will come back to bite you.

Mark

Coke and Pepsi in the news

I was reading about the former Coke employees trying to sell secrets to Pepsi. I don't know what they were thinking. I mean do you really think that two corporations that have been in business for decades, with a global presence, and a lot to lose would participate in something like this? The competition may be fierce, but it is done above board. That's the way most companies have to operate if they want to stay in business.

This incident as well as every data breach that has happened in the past few years points out - Identity and Trust are the compenents that make up the next iteration of Identity - Enforcement.

Once we determine identity and ultimately trust, we move into a reactive psoture/mode of assessment, validation, authentication, and making sure that things are as they need to be. If something happens, we react, put out fires, sign up for identity theft credit monitoring, add some new technology into the mix, scream at vendors until some other poor organization grabs the headline and takes the spotlight. Reactive is OK, but it it doesn't use the power of identity which I believe ultimately is enforcement of access to data where it lives.

I have stayed off my TNT soapbox on this blog but with the headlines I've seen in the past 24 hours from the IAPP, Infragard, and a host of other places I am going to go on a rant here - you can stop the madness, you can protect your assets, you can become proactive in your access management, and you can do it very quickly with a single platform solution.

The concept is simple, the technology deploys in hours or days depending on size of organization, and is competitively priced at $25-250K for most deployment scenarios. So what do you get?

You protect servers, applications, and data from unauthorized access
You control who, from what device, has access to what servers and applications
You report on all valid and invalid connections and connection attempts
You report on who accessed what by user, by group, and/or by device

You enforce IDENTITY BASED access policy in the network layer. If you aren't a known or trusted USER or a known or trusted MACHINE you can't see, ping, or access the IT assets of the organization.

Case in point: Coke's secrets are kept on a handful of servers that sit behind the TNT appliance. Only specific individuals from specific machines can even see, let alone access the servers and the apps and data contained on them. In their specific case that executive would have access to the secrets, but their Admin would not, even if the Admin had the username and password for the Executive.

I could go on about this all day long and discuss at least a dozen scenarios where I can help. The bottom line is get serious about identity management and figure out how you will add value to the organization beyond an IdM deployment. Look at enforcement - it will keep you out the papers, and cost SIGNIFICANTLY less than even the spin control on a breach. And by the time the next company grabs the headlines, your solution will be deployed.

identitystuff @ gmail.com