Tag: Burton Group

Stripping Search

In response to regulatory pressure and to apply some pressure on their competition, Yahoo has announced that after 90 days it will anonymize search queries and remove personally identifiable information (PII) from them as well.  Specifically, Yahoo will delete the last eight bits from the IP address associate with a search.  Further, Yahoo will remove some PII data, like names, phone numbers and Social Security numbers from the searches.  The goal is to (eventually) destroy the ties between a person and what that person searches for which could include embarrassing, compromising, or sensitive items such as information about medical conditions, political opposition materials, adult entertainment, etc.

There are two points I want to draw you attention to.  The first point is related to the amount of time search providers, like Yahoo, hold identifiable search queries.  Regulators have recommended to search vendors to reduce how long they hold identifiable searches.  The EU has recommended 6 months, for example.  Yahoo, reducing their retention time from 13 months, has taken a laudable step to reduce that time to 90 days.

In the future, the time it takes a search provider to extract whatever goodness it wants to out of a search query (to feed its varied businesses) and anonymize that query will reach zero.  External pressures aside, the Googles and Yahoos of the world will achieve near-instantaneous goodness-extraction/anonymization of search queries simply because it reduces what they have to store, maintain, and worry about.  That being said, even though search providers will be able to achieve near-instantaneous extraction and anonymization, they will never be able to put it into practice.  Why?  Because there will always be a desire on the part of law enforcement to gain access to those identifiable searches. Continue reading Stripping Search

CA’s Acquisition of IDFocus

Yesterday CA announced its acquisition of IDFocus,  a small Israeli company.  Among other abilities, IDFocus provides a finer-grained segregation of duty (SoD) analysis engine.  CA has previously integrated this engine into Identity Manager, their user provisioning tool.

This is an interesting wrinkle in an ever-changing market.  CA now possesses a preventive-controls engine with the ability to look further into the security stack of an application.  This engine allows customers to make SoD decisions below the role or group level, at the lower ACL/security object levels.  Provisioning vendors have until now done this by calling external services provided by Enterprise Application Controls Management (EACM) vendors.

On one hand, CA has partially obviated the need to integrate with an SAP, Oracle, or Approva by integrating the IDFocus capabilities into CA Identity Manager.  On the other hand, CA’s move may have made things more confusing for customers.  By increasing the number of controls repositories that a customer has to maintain, integration of IDFocus makes compliant provisioning deployments more challenging.  What would be really slick is if CA could find a way to work with the EACM vendors to synchronize SOD tests so that a customer could use the same test for both detective and preventive applications.

I was speaking on this very topic in Europe last week.  I commented on the various architectures for integrating EACM into user provisioning to provide compliant provisioning services.  (For more on this subject, check out Lori’s report on the matter.)  CA has now introduced a fourth deployment model in which the provisioning engine owns the entire compliant provisioning event from the request through the SoD test to the provisioning event itself. An interesting alternative. I’ll be curious to see where CA takes this.

(Originally post on Burton Groups’ IdPS blog.)

Thinking about Matt’s Simple Question: Correlating accounts and people

Matt Hamlin, over at Sun, mentioned a conversation we had last week about a topic in identity management which doesn’t usually get a lot of airtime: the correlation of accounts to people.  The exercise is the first step in answering Matt’s simple question of “Who has access to what?”  Matt writes:

This step is the foundation for Access Certification, Role Mining, Entitlements Management, Policy Evaluation, Identity Auditing, and numerous other custom services developed by our customers.

There were two major omissions in his list: password management and user provisioning.  The reality is the correlating of accounts to people is a requirement for all identity management exercises.  This correlation isn’t glamorous work and isn’t a one time affair.  None the less, it is crucial “Identity Gold” for identity management projects, but also as the foundation for risk mitigation exercises as well.

Here’s a tip to enterprises out there – ask your software vendors and deployment teams what capabilities they have to help facilitate this correlation.  Ask early and before you start down the path of an identity project.  Make it an on-going process governed by your overall identity management program.

I’ll be touching on this a bit in an upcoming Telebriefing I am doing.  On October 1st and 2nd, I’ll be giving a sneak peak of my research on access certification and will cover this and other topics.  If you are a Burton Group subscriber, you should check it out.  If you aren’t a BG customer, you should become one.  😉

Chasing the magical GRC animal

I’m sure you’ve been following the Terry Childs case. Mr. Childs was a sysadmin in San Francisco who decided to change a few passwords and thus locked the city out of their new wide area network. Though it is still not clear why Mr. Childs did this, he had been recently written up for poor job performance. 

Among others, Matt Pollicove wrote about this and the need for trust.  Matt asserts that trust is a must and I completely agree. That being said, the last two points in his post are mistaken.

First he says:

This means, making sure there’s no orphan or rogue accounts in the systems.

While this is a generally accepted good practice, it would not have necessarily helped San Francisco keep from losing their network. Privileged account management would have been far more useful.  Discipline and control around how sysadmins gain access to and use root-like accounts, the bread and butter of privileged account management, would have helped avert some of San Francisco’s problems.

Second Matt says:

GRC tools will be a must in this verification.

This first thing that springs to my mind is a question: what aspect of governance, risk management, and compliance would have helped the city of San Francisco in this case? A good governance and risk identification and management process would have helped a great deal.  But we have to keep in mind there is no such thing as a GRC tool; there is no such animal.  In fact, GRC is starting to sound like the wonderful magical bacon animal that Homer Simpson dreams of. If pork chops, ham and bacon all come from the magical animal in the Simpsons, then privileged account management, orphan account management and provisioning all come from the magical GRC animal. Where does it end?  The reality is that the industry has confused the benefits of good governance processes and risk management capabilities with automation tools that aid, but never replaces, those processes and capabilities.

Privileged account management is not and should not be considered part of the marketing fog of GRC. Does the controlled management of root-like accounts constitute good operating procedure and help reduce risk?  Absolutely. But that doesn’t make privileged account management a GRC technology.  Is orphan account removal a critical process from a security and risk mitigation perspective?  Of course. However, that doesn’t mean the technologies to do that are GRC technologies.

Specificity of language is crucial. Telling the city of San Francisco that the solution to their problems lay within “GRC” would have done little except lengthen the time to finding what their real problems were.  Our industry cannot take the easy route and lump every possible technology and procedure under the sun onto the GRC heap or else we’ll find ourselves chasing Homer’s magical bacon animal.

Originally posted on Burton Group’s Identityblog