Don’t Launch the ABAC Ship Without Stewards Onboard
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:
- Understand your customer data
- Make it easy (ish) to manage
- 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:
- 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:
- RSA tokens were allegedly cracked (mostly not true)
- SS7 flaw will drain all your bank accounts (true, but hard to implement)
- NIST Killed SMS 2FA (sort of, but not really)
- Modlishka makes SMS useless (sort of, but not really)
- Google Security keys have Bluetooth flaw (recall for some, not all)
- Yubikey FIPS keys flawed (recall for some, not all)
- Apple promoted modifications to SMS 2FA for improved anti-phishing strength & joined FIDO’s board.
- 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.
- 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.
- 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.
- 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/
