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.

The promise of attribute-based access control (ABAC) is positively mesmerizing. Most IAM products can assign access based on roles and rules built on user data. Training usually provides simplistic, easy to follow use cases. Business analysts can quickly analyze data and sort out use cases for automation which should improve security, lower overhead, and enable the business. While this all sounds great, and is great, a lot of online and product documentation leaves out a key component – data stewardship. If the departments that own the data don’t know how it is being used, and agree to it, side effects of automation may ensue leaving users without the access they need, and the IAM, Sec Admin, Access Admin groups in SOS mode. Here is a cheat sheet that lays out definitions, benefits, and potential “gotchas” organizations should be aware of before launching their ABAC initiative.

Data Requirements for Implementing Attribute Based Access Control (ABAC)

• Data Stewards – responsible for each data element used in ABAC
• Data Integrity – with established accuracy and completeness thresholds
• Understanding of Use – and acceptance of the use of the data by the data owner and provider
• Data Protection – changes to data objects and available data values must be governed,
• controlled, documented and communicated

ABAC Benefits

• Automation for access decisions and provisioning based on data – business enablement
• Ability to map data to business roles to access in systems and applications
• Improved security posture and better housekeeping
• Bundling of access into roles

ABAC Concerns

• Missing or incomplete data requires fallback to default logic for error handling
• Timing – data may change for a worker before or after the true date when action should be
• applied to worker accounts
• Point of failure when logic is dependent on specific data values that can change based on
• Finance, HR, Org changes – such as or Cost Center or Org Name changes
• Potential for changes to large numbers of worker records simultaneously
• Retesting – Upstream changes require updates to IAM system and retesting
• Finance and organization data changes may not be communicated to IT and identity teams in
• advance, resulting in downtime or fallback to default logic

Funnily enough, a quick Internet search for “RBAC is dead” will reveal a trove of articles on the rise of ABAC.

James Dodds

IDPro Editorial Committee

A Look Back at GDPR and A Look Forward to CCPA and LGPD 

What can we learn from GDPR (the General Data Privacy Regulation) about how to manage privacy legislation? What does impending privacy regulation like CCPA (the California Consumer Privacy Act) or LGPD (Lei Geral de Proteção de Dados, Brazil’s personal data protection law) mean for the privacy landscape in general? How can we future-proof our privacy practices to move beyond prepping for the next set of rules?

GDPR is now a year and a half old! I will always remember the day GDPR was born, as it was preceded by 800 companies I don’t remember ever interacting with sending me emails asking me to approve their updated privacy policy. It also marks the era of cookie notifications on every website, each of which with an “accept” button but no “decline” button. It’s the same behavior as when I’m offered cookies at my mom’s house, so I’m actually pretty used to it. You’re gonna accept these cookies and you’re going to love them!

Seriously, though, GDPR is a positive step. It is a major legislative piece that tackles the issues of data rights and consent for a big group of people and it represents that people are demanding more control over their data. This can feel daunting for marketing teams, who have to make sense of all of these rules and may feel like they are losing their ability to generate leads. And that can be true in the short term – but the effect in the long term is that companies will start to have more genuine relationships with those who remain, and the ability to really develop a trusted relationship with those customers results in greater customer loyalty and a higher lifetime value. But, before we get into that – let’s take a look back at GDPR over the last year and a half.

So what’s happened?

In the first year:

280,000+ cases

144,000+ complaints

89,000+ data breach notifications

90+ fines

56,000,000 Euros in fines

To date:

200+ fines

460,000,000 Euros in fines

(Reference: https://enforcementtracker.com/)

As a reminder, the GDPR gives national watchdogs extensive powers to investigate privacy breaches and to hand down fines of up to 20 million euros (around $22.4 million USD) or 4 percent of a company’s global annual turnover, whichever is greater.

More than 280,000 “cases” were reported in 27 european economic area countries in the first year of the GDPR. Of these, around 144,000 were “complaints” (e.g. improper data processing), as opposed to 89,000 that were data breaches (i.e. insufficient measures to secure data).

As of this writing, the top complaint category is insufficient legal basis for data processing, by almost twice the number of fines of any other category. In total, 460 million euros in fines have been levied (which is more than four times the amount of fines just six months ago!)

This sounds like a significant number, but it turns out that more than 400 million of that is British Airways, Marriott, and Google. British Airways and Marriott were fined around 200 million and 110 million, respectively, for insufficient technical and organisational measures to ensure information security, and Google was fined 50 million by CNIL [ke-nil] (France’s privacy regulatory body, the Commission Nationale de L’Informatique et des Libertés) for failing to inform users adequately about its use of their personal data and failing to seek “valid legal consent” from users to personalize ads. 

Now, that leaves 60M euros over 200 fines levied, and some of you might be thinking to yourself – okay, 300,000 Euros, and only 200 organizations have been fined. Maybe there’s a risk discussion we need to have before investing any further in privacy. But, don’t get too comfortable, because it turns out regulators aren’t letting things slide, they’re just really, really busy. As DLA Piper research puts it:

“Regulators are stretched and have a large backlog of notified breaches in their inboxes. [T]he larger headline grabbing breaches have taken priority …, so many organizations are still waiting to hear from regulators whether any action will be taken against them …”

which means that, as Giles Watkins, IAPP Country Leader for the UK explains:

“… I sense that there is only a limited time for organizations to put their houses in order before the commissioner does revert to the enhanced penalty regime, with potential enforcement actions perhaps being even more significant to businesses than the monetary fines” – Giles Watkins, IAPP Country Leader, UK

Okay, great, so we really do have to care about this. But . . that’s not all. We don’t just have GDPR to worry about: every country and their mom are coming out with a privacy regulation. Are we going to be living a GDPR Groundhog Day for the rest of our lives?

Not necessarily – but first, let’s talk a little bit about what’s definitely maybe coming and how these regulations overlap.

The next big regulation to hit the scene this year is the California Consumer Privacy Act, the CCPA. This law has been called GDPR-lite or the California GDPR, which I think just means it’s privacy regulations with some avocados on it? I kid. In all seriousness, though, there are some differences between the two, which we can take a quick pass through.

Both regulations require transparency or audibility of operations. Both require maintaining a data privacy notice, policies and procedures for obtaining consent. However, the CCPA notice

requirements on personal information disclosed or sold to third parties only covers the 12 months preceding the request

CCPA is specific about the ability to opt-out of the sale of personal information to third parties as well as protecting those users from price or usability discrimination, while GDPR is not as explicit about that particular scenario.

CCPA 1798.115 (d) A third party shall not sell personal information about a consumer that has been sold to the third party by a business unless the consumer has received explicit notice and is provided an opportunity to exercise the right to opt-out pursuant to Section 1798.120.

The high level take away from this comparison, is that we should expect to have to grant users the right to manage their data in a variety of capacities. So, what does this look like when we add in LGPD?

The high level take away from this comparison is that we should expect to have to grant users the right to manage their data in a variety of capacities. So, what does this look like when we add in LGPD, another major privacy legislation to appear post-GDPR?

The LGPD is very similar to GDPR in terms of personal data rights and protections – in each of the major categories we examined for GDPR, LGPD follows suit exactly. There are some minor differences with the LGPD. For example, LGPD does not differentiate anonymous data from pseudonymous data. When the difference between those categories is related to risks of re-identification of the data subject, the Brazilian law does not relax legal obligations for controllers that employ pseudonymisation techniques when compared to the EU regulation. But, on the whole, similar data strategies and rights considerations can be employed between the two.

So what are we going to do? To hit the overarching themes and impetus behind the regulation, every organization should do three things:

1. Understand your customer data
2. Make it easy (ish) to manage
3. Give control to your customers

In order to understand your data, you need to:

• Catalog your data: What data do you have? Where is it stored? Why do you have it/how is it used?
• Know who can see your data: Who can access your data? To which third parties do you share/sell data and what data do you share/sell?
• Assess your risk: What is the sensitivity of each piece of data?

In order to manage your data you need to:

• Minimize Data: Determine what data is needed and what isn’t – delete data you don’t need, anonymize data you don’t need to tie back to an individual
• Data Retention: Based on your catalog decide how long you need each piece of data and implement process around retention and disposal of data
• Data subject processes: Make it as easy as possible to respond to requests like: portability, vendor sharing/selling, deletion, processing by having APIs or processes in place with each data owner
• Review/Enhance Security: Protect data from unauthorized access, use classification to drive access

Finally, giving control to your customers means:

• Transparency: Show your customers how you’re using their data and with whom it’s shared/sold. Give them the ability to revoke those purposes or third party access
• Data Access Rights: Give your customers the ability to exercise data rights like portability, restriction of processing, right to be forgotten. The more automated, the better.
• Consent and Preferences: Give your customers the ability to opt into or out of data uses (as much as is possible) and establish their own preferences for communication and data use.

Doing this will not only keep regulators happy and your organization off the fine list, it will also create a trusted, transparent relationship between organizations and the data subjects whose data they are stewarding, which means these regulations, if handled well, can be a win-win for both organizations and customers, consumer, and all data subjects.

Marla Hay

Sr. Director

Product Management – Privacy & Data Governance

Salesforce

Evaluating 2FA in the Era of Security Panic Theater

It seems like today’s world offers constant reminders of how insecure our digital lives can be. As a security professional, part of my job is to monitor for threats to my company and the organizations with which I have a relationship. A significant part of that effort lies in assessing how likely or realistic those threats are. If you believed every infosec vulnerability headline you see come across twitter, it would be easy to feel somewhat like chicken little, with the sky ever falling. I’ve actually coined a term for this phenomenon (though I’m not sure if I actually originated it, but Google seems to think so): Security Panic Theater.

If this term sounds mildly familiar, it is because of its proximity to the phrase ‘security theater’. We experience this pretty regularly whenever we attend a major sporting event like the World Series and we have to go through long lines where people wave a wand over us to ensure my keychain knife doesn’t get admitted to the stadium. This takes place even though the track record of seizing weapons that would matter is pretty poor. But the mere act of this experience makes patrons feel safer. This is even worse when we travel and pass through TSA’s gauntlet of screeners. Consistent penetration tests reveal a woeful rate of actually detecting items that could cause us harm while we are in flight. To add to the insult of this process, there is a comic reality with what actually is seized. I’ll let comedian Steve Hofstetter explain:

If you bring too much liquid, the TSA confiscates it and throws it away, in case it’s a bomb. So they throw it away. In case it’s a bomb. In the garbage can, right next to them. With all the other possible bombs. In the area with the most amount of people.

In case it’s a bomb.

Security Panic Theater (SPT) is a bit of a different experience. The process for SPT goes something like this:

Vulnerability/breach announced regarding a product or control (x) [Security]

+ Inflammatory internet headline(s) regarding (x) [Panic], which leads to the conclusion:

Product or Control (x) is useless/defeated [Theater]

A relatively recent example of this was the release of a penetration testing toolkit by Polish researcher Piotr Duszyński named Modlishka, which loosely translates in English to Mantis. The central feature of this toolkit was the use of a reverse proxy that could accelerate a phishing flow by sending a user to a spoofed URL, but the rest of the web experience was as the user expected. This enabled a man-in-the-middle (MITM) attack to capture both the credential and the SMS code being used by the user.

The significance of this new framework didn’t lie with the fact that you could now phish any 2FA method that used OTPs. What made this release notable was that it was now significantly easier to accelerate the phishing flow because you didn’t have to spin up a fake site. A reverse proxy would do the work for you. To be clear, that is certainly noteworthy, but also not new.

However, to hear the twitterverse and online media outlets talk about it, you’d think all our credentials, even if protected by 2FA, were suddenly moments away from being captured by hackers. Now, to be fair, there are some responsible journalists who try to treat these topics fairly, but even a sane article can often be overridden by a clickbait title like “Is 2FA Dead?”

Let’s get a few basics clear for the sake of sanity & clarity:

1. 2FA can’t be killed . It isn’t a combination of factors for authentication, not a single technology or pattern. The last few years alone have had a litany of episodes where a particular technology may be at risk (often temporarily, or misleadingly so), such as:
   1. RSA tokens were allegedly cracked (mostly not true)
   2. SS7 flaw will drain all your bank accounts (true, but hard to implement)
   3. NIST Killed SMS 2FA (sort of, but not really)
   4. Modlishka makes SMS useless (sort of, but not really) 
   5. Google Security keys have Bluetooth flaw (recall for some, not all)
   6. Yubikey FIPS keys flawed (recall for some, not all) 
   7. Apple promoted modifications to SMS 2FA for improved anti-phishing strength & joined FIDO’s board. 
   8. 2FA implementation in Iowa Caucus renders app nearly unusable 

Notice the trend here? While there is some truth for most of these from a vulnerability perspective, the reality is that these technologies still work to protect your credentials. Apple’s recent announcement has its own debate worth talking about (and has been on IDPro’s Slack site) and the debacle in Iowa shows that any technology is a dumpster fire waiting to happen if its implementation is designed poorly.

1. The diversity of the 2FA landscape makes it stronger, not more vulnerable. 

Let’s take a look at the following categories of authentication: 

Pretty diverse to be killed with a single vulnerability, I would think! Now let’s overlay which ones have at least one known vulnerability:

If we look at all the ones in red, that would be pretty disheartening to the casual observer. That’s where journalists and analysts need to take special care in talking about vulnerabilities. The real story doesn’t fit neatly into a simple headline regarding the vitality of the authentication landscape.

1. All methods of 2FA are still incredibly effective (some more than others) 

Google published a study of some internal findings on various methods used to secure their public credentials. Yes, SMS should be the low hanging fruit of 2FA but guess what, even this well-beaten pinata of 2FA stopped 76% of targeted attacks and nearly 100% of automated & bulk phishing attacks!

Microsoft recently published some numbers to similar effect, that the risk of account compromise is reduced by 99% using multi-factor authentication (MFA). I’d say 2FA is far from dead in that context.

1. Yes, we should get rid of the 2 in 2FA, long live MFA

The biggest reason for this is that users can be more secure, and less inconvenienced when they have access to multiple ways of authenticating instead of one token combined with a password that can be lost, or a phone that can be upgraded and lock a user out. Without promoting one vendor, I can say thoughtfully that I have several methods to secure my key accounts and that diversity of options, I believe, is the key to giving our users the power of choice as to how they want to login. That power is how we eventually do reduce passwords to an edge use case. The key is that more sites need to support those methods to incentivize adoption. We’re not there yet, but the last few years show a lot of promise in eventually achieving that goal.

The reality is, even the coolest methods of authentication will eventually find a vulnerability. History proves this. But we don’t throw the baby out with the bathwater when those are discovered. We fix it, learn from it, and stay secure. Let’s leave the theater to the actors, where it belongs.

Lance Peterman

IDPro Board

Resources:

• https://www.extremetech.com/extreme/173108-researchers-crack-the-worlds-toughest-encryption-by-listening-to-the-tiny-sounds-made-by-your-computers-cpu 
• RSA Paper – https://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf 
• Modlishka Introduced- https://blog.malwarebytes.com/cybercrime/2019/01/two-factor-authentication-defeated-spotlight-2fas-latest-challenge/ 
• SS7 – https://www.wired.com/2017/05/fix-ss7-two-factor-authentication-bank-accounts/ 
• NIST SMS – https://threatpost.com/nist-recommends-sms-two-factor-authentication-deprecation/119507/ 
• NIST SMS 2 – https://www.zdnet.com/article/nist-blog-clarifies-sms-deprecation-in-wake-of-media-tailspin/ 
• Modlishka – Mitigation approaches https://www.cert.pl/en/news/single/recommendations-on-mitigation-of-man-in-the-middle-phishing-attacks-evilginx2-modlishka/ 
• Google Security Keys recalled – https://www.engadget.com/2019/05/15/google-recalls-some-titan-bluetooth-security-keys 
• Yubico FIPS Recall – https://www.theregister.co.uk/2019/06/13/yubi_key_bug/ 

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