An Identity Correlation Framework

Identity correlation is simply the process of mapping an account from an application or system back to its authoritative origination point. This is important in order to more simply understand the what, where, when, and how of the account’s reason for existing and if it should exist where it is with the capabilities that it manifests. That understanding is much simpler when the account is correlated to a known quantity.

Examples:

• The account is an end user account on the enterprise directory and it belongs to employee Susan who is allowed to have the account because the employee is actively working for the company.
• Or the account is an enterprise directory account is a service account belonging to an employee Mr. Tumnus and is assigned privileges X, Y, Z to do function Foo. It was requested and approved on <date> and was certified on <date>.
• Or the account is a database privileged account belonging to manager Lucy and is assigned privileges H, I, J in order to process the function called Bar and is authenticated using another account belonging to Lucy on the enterprise directory.
• Or the account is a bot account WW with access to applications G, H, Y, the enterprise directory, and belongs to consultant Edward who works in the robotics process automation program.
• Or the account was disabled because it belongs to consultant Peter who has left the firm.
• Or the account is unknown and needs to be disabled, investigated.

The following simple framework is for practitioners in highly regulated identity spaces. Certain conditions may be curiously vexing in large and long-established companies that simply don’t exist in spaces where everything is new, and where everything can’t be made new again by dropping into a new clean space.

The framework here isn’t a fit for every situation, as if anything could be, but has proven useful in certain situations for resolving recurring issues once and for all, rather than catching up at various points in time. Admittedly, it may seem dull, and a bit of a grind, but we are yet to find any tool, software vendor, consulting firm, or magic bullet that can take the place of doing the work, sticking to a plan, and most importantly, taking the first step if it needs to be taken.

An Identity Correlation Framework

Partnership

An effective evergreen process requires on-going partnership between identity practitioners, the business they serve, security, risk, compliance, architecture, dev-ops and other stakeholders to ensure that applications and systems are built and managed in a manner that allows continuous adherence to standards and adaptability to changing conditions and technologies. Much to the chagrin of practically everyone at times, identity and access management is not a project with an end date; it is a continual and extensible managed process.

Pillar A : Onboarding Identities with a Unique

Identifier (Expansion of oft-used process)

Humans are traditionally identified uniquely and it may be useful to apply that model to almost every account in the enterprise. Humans in the enterprise, employees, consultants, third parties, are probably uniquely identified already. It isn’t terribly difficult to do the same for nonhuman accounts.

Why? Consider that there may be more requested nonhuman accounts distributed in systems and applications across your enterprise than there are for all of your employees, consultants, and third party humans combined, and consider how much time is spent trying to identify who owns those accounts, what they are for, or even when they were last used.

Just as your human resource system maintains the manager relationship, insertion of a unique identifier and accountable account owner into the non-human account request and provisioning process will eliminate much of the headache around nonhuman accounts. Implementation of an automated process to update accountable owners of accounts as owners move across or leave the organization will go a long way toward eliminating the troublesome practice of maintaining account ownership data in applications when that data is impractical to maintain or simply ignored. An upstream system handling the job on everyone’s behalf has significant benefits, and can be implemented very inexpensively.

How? Review the types of accounts that are problematic and how to insert a unique identifier into the request process for those accounts. Include general categorization of account type. Assign an owner. Replace the owner if the owner terminates. Provide a process for requesting and approving ownership changes from one active person to another.

The Category Naming Conundrum: Function and Privilege Over Nomenclature

The significant differentiator between nonhuman accounts should be the level of privilege and the account’s function, rather than nomenclature. Classifications and naming conventions that aim to provide guidance are often not well understood, not accurate, and not maintainable over time. What is the difference between a service account and a functional account as a category? Let the debate begin, or prevent it by keeping the naming of categories assigned to unique identifiers simple. Information about the account privilege and function is far more useful when derived from the account and its privilege itself. The category of ‘employee’ does not attempt to denote anything material about an account other than that it belongs to an employee. Other data is derived elsewhere. Use the same for nonhuman practice accounts.

Pillars B and C: Maintenance

Once the process is started, keep doing it. Attention to housekeeping (deletion of deprecated applications from the IAM systems, purging of aging account data, will simplify the process. Connection with an enterprise application portfolio EAP system as an authoritative source of application status information and other application metadata can streamline the process.

There may be account data captured in some applications that won’t correlate to an authoritative source and tagging will help to, at minimum, categorize them into buckets for further review. For example, a tagged out of the box account (OOTB) may need to be checked to ensure appropriate controls are applied but filtered out of the uncorrelated account totals.

Maintenance includes the applying of typical identity management functions for automation of termination, transfer, access certification, etc.

Pillar D: Apply Governance

Examples of applying governance include:

Producing a report on correlation percentages with a threshold for highlighting applications that don’t meet an

Testing anticipated correlation rates as part of the system development lifecycle in advance of an application’s first aggregation or significant update. Set a high bar.

Sending an alert when an application moves negatively across the threshold and investigating the cause.

Be flexible in assisting application teams understand why their accounts don’t correlate – this may be a simpler task for identity personnel than for an individual application team.

Where feasible, make recommendations to application teams to request unique identifiers for existing nonhuman accounts or to determine where a related correlated account already exists – such as on the underlying authentication system.

Pillar E: Manage Application and System Identity Requirements

Company application build or buy requirements and security assessments may benefit from being updated to account for identity specific account correlation requirements.

Apply a periodic review of newer applications that have presented significant challenges – review approval process and identify causes, with lessons learned sessions and process updates to follow. Add all newly implemented applications to correlation reporting and dashboards.

To conclude, practicing the steps outlined here may be a good step if you are suffering from the need to periodically clean-up your identity data or track-down its owners, or the more serious consequences of not knowing the who, what, where, and how of accounts on your network.

• An IDPro Founding Member

In Favor of the Shift 

A spring without baseball allows time for reflection about the big issues in life—about what really matters. As a result of these few past empty months, I’ve come to a realization: the defensive shift is good for baseball.

The defensive shift occurs when the defense plays out of its typical alignment. Instead of being distributed across the field relatively evenly, the shift typically involves the third baseman or shortstop moving over to the right side of the field. At times, this shift can become extreme. One of the prime examples being this four-man configuration used by the Los Angeles Dodgers in August of 2014:

https://www.mlb.com/video/dodgers-use-wall-of-infielders-c35789081

Over the past few years, many have decried this defensive tactic, claiming that it is against the spirit of fair play, or puts hitters at too much of a disadvantage. But the shift is not new. While the origin of the shift dates back to the 1920’s, it became well-known as a response to Red Sox legend Ted Williams. He had hit an unheard of .406 in 1941, in 1946 he was hitting .476 headed into May, and opposing teams were desperate to slow him down. Williams was a left-handed pull hitter, making him a candidate for a unique defense.

http://www.baseball-fever.com/showthread.php?56039-The-Ted-Williams-Shift

This approach to Williams found enough success that other teams duplicated it, and the Fleer company even dedicated an entire baseball card to it:

https://marketplace.beckett.com/item/513/1959-fleer-ted-williams-28-the-williams-shift_15570564

Despite still hitting .348 from 1947 to 1957, Williams had difficulty adjusting to the shift. He hit 1000 of his 1252 ground ball outs in the 1950s to the right-hand side alone.

But there are ways to beat the shift, which brings us to Mickey Mantle. He, like Williams, faced the shift during his career with the New York Yankees. Mantle, however, modified his approach to beat the shift in multiple ways: (1) Hit it out of the park: he hit 536 total home runs, good enough for 18th on the all-time list (in his 500 th HR in 1956, you can see the shift being used against him.) (2) Hit to the undefended side of the field: Mantle was also a switch hitter, so he could just change sides of the plate and hit to left. (3) Bunt: this is perhaps the most controversial option, but it is one that serves the team if it advances the runner . . . and it won Mantle the Triple Crown (league-best batting average, home run total, and runs-batted-in) in 1956, over none other than Ted Williams himself.

In August of 1956, Mantle was eight games ahead of Babe Ruth’s 60 home run pace. He outdistanced Williams by 28 home runs and 48 RBI, but the batting average was a close contest. Mantle, however, continued to beat the shift by bunting. Over the course of the year, he attempted 21 bunts, the most of his career, and hit safely in 12 of those at bats. Here you can see the bunts against the shift and their impact in the Triple Crown race:

Mantle’s innovative approach had won him the Triple Crown, and the Yankees went on to win the World Series in seven games in 1956.

The shift was good for Mantle—it forced him to develop his game in new ways, to develop new skills, and to exploit new opportunities. While Williams allowed his focus to be on the defense, and what was being taken away, Mantle sought new ways to develop his offense.

We’re in a similar position when it comes to identity. We are often focused on what we must prevent rather than on what we can enable; we are continually reacting rather than being proactive in our identity-driven security strategy.

When any shift occurs, our tendency is to hunker down in our safe zone, worrying about what could possibly go wrong. To do more than survive, though—to successfully beat any shift—we should examine our options and adapt; we should diversify and develop our game. We should play offense rather than defense.

Mantle, when asked why he was bunting so much in 1956, was quoted as saying, “When I tried to bunt for a hit, it was because we had to get something started. I figured that winning the pennant was the most important thing of all. Sure, I wanted to break Ruth’s record, but not at the expense of winning.” Like Mantle, we must focus on what is the most important thing—what “winning” is for our organizations—and adapt our strategy to achieve that.

Some of these strategy modifications may be home runs: Rethinking the core of identity itself. Reorienting our approach around identity—equipped with adaptive technologies such as machine learning—can flip an organization to offense, proactively providing access to users before they even know that they need it.

Others are the equivalent of switch-hitting: a new perspective that we might not have considered before. Exploring the reuse of new forms of digital identity can open up new long-term opportunities for new markets and partnerships. Implementing privacy controls and securing the data of customers and employees—even before governments mandate these controls—can help prove that the organization can be trusted with sensitive data.

Bunting should not be neglected, either. Every small step towards securing resources with identity is a step towards “winning.” Often this means expanding the visibility of an identity program into the dark corners of previously uncontrolled apps.

The shift, then, rather than being a negative for our organizations and for baseball, forces aggression, forces adaptation, forces innovation—it forces the advancement of the game. To ban the shift is to kill opportunity and to settle for the status quo.

The shift is good for baseball. But don’t get me started on the designated hitter.

Mike Kiser

Global Security Advocate, Office of the CTO

SailPoint

Why the World Needs IDPro

So, June is always a big month for the Identity Industry. Identiverse Virtual is in full swing and many of us are having virtual reunions with our fellow Identerati. While it’s a very different Identiverse this year, there’s actually a lot I like about the virtual conference experience. No more “feast or famine” with scheduling; we can attend every session that interests us and never worry about a time conflict. It’s kind of nice that the recordings are showing up within an hour or so after the session, which means I don’t have to worry about “work” intruding on my conference time. In fact, more people from my company have been able to join Identiverse than we’ve ever been able to send in the past. Another very cool aspect of the virtual experience is the live chat throughout the sessions. While the chat can sometimes get distracting, it’s also really slick being able to ask the speaker a question and see a live response, all while the presentation is still running, uninterrupted. Plus, of course, many of us are veterans of Identiverse and the Cloud Identity Summit before it. We’ve come to know each other through these conferences, and our membership in IDPro. It’s great getting to chat with each other during the sessions, especially since this year, we aren’t going to be meeting up in person so much.

Which brings me to my next observation. There has been a lot of great conversation spilling over from the Identiverse chats into the IDPro and Identiverse Virtual workspaces on Slack.

Janelle Allen recently asked this question in the #identity-geek channel on IDPro: “Did you know you were doing identity when you started identity?” More than a dozen of our fellow IDPro members chimed in to share their experiences with much more than yes or no answers. There were stories. And with few exceptions, there was the expected theme we’ve come to know in this industry. Many of us had no idea, for years, that what we were doing was managing “Identity”. It was LDAP directories. Account Management. Directories of email addresses. Record matching in health care systems. PKI strong authentication and authorization.

Sometimes it was “Security” work. Some of us were even cautioned against getting too close to that work: “If you screw up the security they’ll fire you.” Some of us arrived here by being assigned to fledgling SSO projects. Some of us were pushed. Nearly all of us learned what we know through experience, making mistakes along the way, and surviving them. If you want to read the full set of stories, hop over to #identity-geek on the IDPro Slack. (Don’t worry, they’re all short stories!)

For all its importance, Identity is still a small part of the overall Information Security industry, and there aren’t all that many places we can turn to for guidance as we develop our careers. This is why IDPro is so valuable to us as Identerati. Being able to come together with our industry peers and share ideas and stories, ask questions and actually receive useful replies, find mentors, and learn from each other is what IDPro offers us. And with the recently released collateral in the IDPro Body of Knowledge and our upcoming certification program, we’re enabling the next generation of Identity Professional to learn the right lessons and skills in far less time than our shared curriculum took at the school of hard knocks.

My thanks to Janelle, Mark, Vittorio, Ludo, Lance, Lorrayne, Bertrand, Matt, Catherine, David, Paul, Corey, Dean, Vipin, Patrick, Michelle, and Marc for the great stories. Keep it going!

If you need an invitation to our Slack workspace, shoot an email to director@idpro.org and we’ll hook you up .

Greg Smith

IDPro Editorial Committee