The Golden Age

We can trace the field of Identity and Access Management (IAM) back to the creation of the password by Fernando Corbato in 1961. We’ve had to manage user accounts ever since.

Because of these user accounts, two further inventions have shaped IAM since that milestone:

• The creation of Relational Algebra ( Edgar F Codd, “A Relational Model of Data for Large Shared Data Banks”, 1970). Which led to the creation of the first SQL-based Relational Database System, Oracle v.2 in 1979;
• The creation and eventual approval of the X.500 set of standards in 1988.

These 3 inventions are still ubiquitous—33 years after the creation of the last one. Nothing new has really happened since. We still store and manage Digital Identities in Directories and/or SQL databases, and we’ve done this since Epoch.

However, the challenges of the hyperconnected modern era have shown massive cracks in these old foundations…and some companies have started to notice (I have names).

The Problem with Modern Identity

Volume

We live in a very different world today than during that famed epoch. 4.6 billion users had access to the internet as of the end of 2020, 50% of all internet traffic now goes through mobile devices, there are close to 36 Billion installed/live IoT devices this year around the world, and that number keeps growing.

Figure 1 below best summarizes this trend: the total volume of data created worldwide since 2010 and projected up to 2024.

The thing to note is that before 2010, the total amount of data stored worldwide was negligible when compared to the amount in use today.

Complexity

But data volumes are not just humongous nowadays, data has also become exceedingly complex. For instance, the Observatory of Economic Complexity (OEC) publishes data visualizations of the complexity of worldwide economic exchanges.  Figure 2 below represents an example of the data they make available:

There is indeed a relationship between textiles fabricated in China and chemicals produced in Europe. Not a “1-hop” relationship mind-you—not at all. Instead, you have to follow certain paths of products and subproducts, of interconnected partnerships and data exchanges to get from one to the other. It’s not just 1-1 or 1-N relationships anymore. No, it’s more like 1-N-N-…-N-1 these days.

Complexity arises as soon as several actors interact and start exchanging data. Complexity increases further when one starts to ponder the ways in which to protect the access to all that shared information. A good case-in-point here is the new B2B2C business model. We currently lack a truly holistic view of all the actors and resources involved in such systems.

Graphs

At this point, we have to stop and ponder the reasons why Relational Databases and LDAP Directories have been, and still are, ubiquitous in IAM. The reason is simple: both can capture the relationships that link entities together—to some extent at least.

LDAP Directories can only represent hierarchies (parent/child relationships). This in itself is very limiting, as the only way to relate any 2 objects to each-other is to create a common parent. This quickly leads to an unmanageable explosion in the number of such parents as the number of arbitrary relationships increases—exactly the cause of the infamous RBAC Role Explosion.

At least SQL Databases support all kinds of relationships. Nevertheless, they can’t cope with the sheer number of relationships that must be modelled. As mentioned above, we now have to deal with many 1-N-N-…-N-1 relationships. And as we know, joining huge tables (remember the Billions of Identities we need to manage today?) together, or with themselves (the infamous “friends-of-friends” query), many times over can bring the most advanced SQL databases to their knees pretty fast.

Not so for Graph Databases!

Graphs are simple diagrams made of Nodes and Relationships (arrows) that can actually model any data at all.

Figure 3 below is a simple Identity Graph example that depicts the relationships between 2 Identities (a User and a Client) and a Company (“Walstuff”):

A great value-added of Graphs is that they are easily readable in plain natural language, and readable by pretty much anyone. For instance, just follow the arrows in the graph above to “read the data” in plain English.

Representing data as Graphs actually solves all the problems inherent to the legacy tools we’ve been using for so long.

In particular:

Multi-Joins

Querying a Graph for an Access request for example boils down to finding a path, or set of paths, between a subject identity and the resource it tries to access. A path in the graph has the same length no matter how many other billions of nodes are stored in the database. The time it takes to process a path query is the same, regardless of the amount of data in the graph. Compare this to SQL joins. 

Data Complexity

This is better shown. 

Figure 4 below is still a simple Graph. To the Graph of Figure 3 above, we’ve now added a B2B2C partner (“InstantShop”), as well as their flagship Web App “OnlineOrders” and only 1 of their users. The result is still readable in plain English—just follow the arrows.

Now the clients of our Walstuff supermarket can also buy their products online through their OnlineOrders app. Same products, same clients, different channel. Note that employees from both sides should be able to support this new system.

Who can access what in such a model?

Please note that this is just an example and doesn’t reflect any actual IAM system. 

Ok, now try to model that in LDAP (and please email me if you find a good solution).

Conclusion

It is time for a paradigm shift in IAM. Given the challenges we face nowadays, we need data stores that can truly manage relationships, ones where relationships are true first class citizens, which can represent any arbitrary type of relationship. It is time to switch to Identity Relationship Management (IRM)! 

In the fully distributed and Identity-centric world of tomorrow, full of Distributed Identities, Consents, and Verifiable Claims, the only real way to make sense of Identities and their Entitlements is to consider them along with their relationships, in context—their context graphs.

The post The Case for Identity Graphs appeared first on IDPro.

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

The post IDPro Newsletter – June 2020 appeared first on IDPro.