Panel: What Happens When Applications Don't Use the Identity Standards We Have Built

Perhaps you get, you could introduce yourself first quickly and then we can answer this question. Yeah.

Hi, I'm ma, CEO of Context and so very briefly, I came into identity from Jan Rain. I was part of the January management team and then led the Janrain business, Akamai. And I think Akamai started to really see that a lot of organizations weren't really using all the tools in their toolbox when it came to their applications at Entity and Security. So just to get to sort of asking that question, I think maybe be helpful to give a a use case that will help frame the conversation. So maybe if I let the other panelists sort of introduce themselves, then I'll come back and that use case.

Thanks Mayer. So I'm Mark Hain. I've been working in financial services for, for too long really, but one of the things I've ended up doing came into security, which led me into customer identity, which led me into open banking, which led me into the Open ID foundation. And I'm now co-chairing a couple of working groups there. I'm helping promote the, the foundation and specification family, and I'm also a board member of the Open Identity Exchange as well. So. Good. So my name is Haw from Dallas. I'm currently working on the product strategy for identity and access management.

Maybe on a personal note, I, I went back through my notes from the EIC conference a couple of years ago, and it was back in 2014 that Okta announced that they would support or out for the first time in the next release. So one of the major vendors in the, in the industry only support that particular standard for the last nine years yet. So we're still, my point of view is still very young, very nascent in this industry. And so we still have to cover quite, quite some ground to become mature in supporting standards. Cool. Up to You. I got my own microphone here. All right.

So my name is English Shubat. I'm a principal architect slash field CTO at rsa. And are we already answering questions or like you wanna start with that?

No, He's, he's got a use Case. He's got a use case. All right.

So, you know, why are Stan used? Well, first of all, I think, you know, they are such a lot of them, right? And if you are poor full stack developers somewhere, yeah, it's hard to, to choose. And I know it's often some, some knowledge problem as well, right? I think we all experts here and we know which standards to use, but if you're like an enterprise developer, I think you have other challenges, sometimes bigger challenges than to worry which standard to use. Yeah. And I think that is part of the problem. Thank you.

And I, I think what might be helpful to frame the question is a real life use case. So in May 21, it was announced this very, very public vulnerability of a very well-known direct consumer company.

Now, what had happened was a security researcher had let this company know they have a subscription service, they have a connected device. And so there's obviously log in registration, a pay entitlement, and a collected device, right? So that's their stack and it's their core business. A security researcher let them know that the backend that they have, cause they obviously they have applications, right? They've got a database, they've got a directory, and then there's a way that the applications talk to those services.

The security researcher let them know that, hey, one of your endpoints has a search. And if I hit that endpoint with a query string like a question mark and the letter A, it returns all of your customers with the surname BIU A. And unfortunately it also provides the you their, their user id. And because of the way you built your app and the way you've done your, your paywall and your architecture, I've also was able to find out you've got another endpoints that is the edit profile endpoints. And if I change my ID to their id, I get their data. You've got 90 days to fix this.

The very well known, very well financed direct consumer supplier. Great, thank you very much. 90 days later, back to the, to the researcher fixed it. The researcher said you, you haven't fixed it.

No, no, no. We have, you can't get to those endpoints anymore.

No, no, no. All I have to do now is go and log in, create a new account, hit that search endpoint and add my id. I can still get all the data and I can go to somebody else's record with my id, querying their id. And they were like, oh, you mean we had to do authentication and authorization? And so this is a new company without any technical debt. They don't have a sun system somewhere or Sam on the trying to work it out. They could start from best of read cloud first and they couldn't get it right. And so this is sort of going back to your first question is, was it why not? Or this is why not.

So I think you said something there about the developers themselves are the ones who are required to deliver a solution and this smorgasboard of, of standards that we have and best practices and architectures and patterns and all that sort of stuff is out there to help them. But they don't understand this stuff. At the end of the day, with no disrespect to the developer at all. They're not, you know, late in their career.

They haven't had the time or the energy or even the sponsorship from their leadership to get to know all of that complex security authentication and authorization stuff inside out. They're just there to deliver a function in an app. And so they're not the ones that who should be held accountable for not solving these problems.

Yeah, I think it's, you know, the fund we always talk about, hey, you know, security needs to be there from the start, but the fact is that developers usually targeted to develop function X not to securely develop function X. Right?

So, and that, that's a difference. And again, like if you have the knowledge, it's like, you know, to us it will be obvious that yeah, you know, you use OMI Deconnect or Sam whatever, like the standards, we all know scheme and whatnot. Yeah. But that's not obvious to everybody. Yeah. And I think this is one of the fundamental problems is it's, it's not that the standards are bad or that they don't deliver what, you know, what they promise is that sometimes, you know, in your environment Yeah, they still use Radius and Lapp.

So, you know, why would you use anything else, right? It has been done for the last 20 years and what worked for the next 20 years, right? Yeah.

It, Is it the software developer that needs to understand the standards? Or is the software vendor that needs to understand the standards?

I would, I would, I would argue that being in the vendor space, right? So I think that vendors should invest so much more in supporting the standards and making, making it extremely simple for a developer to use these standards. Even without understanding the standard. We cannot expect that any developer starts reading a spec to implement a standard. I would extend that. I think vendors are a really critical part of the, the landscape here, and they need to support the mature standards that enable the delivery of secure solutions.

But I think it also needs to fall to more senior members of the implementers. So I think particularly for me, product owners need to be more clear about not just delivering the functional requirements of an app, but the non-functional requirements, critical one, obviously we're talking about here is that the, the, the data and services are appropriately protected.

It crosses over into a panel, I think, or a presentation that I saw earlier that was, was talking a bit about this, that in order to secure a solution, you should start from what the business function is, what the flow through the app is, and minimize everything that is not required for delivering precisely the flow you've designed through your product. So I'm, I'm pretty confident product owners are a really important link in the chain.

Well, I think you guys answered the question, why not? And maybe the next question that comes to my mind would be how can organizations balance API security, user experience and privacy effectively?

I, I think if you think about the negative impact of a data lake or a hacks endpoint or a broken supply chain, that's obviously quite a challenge for, for user experience. If we think about the standards that we have being as part of our toolbox as, as businesses and business owners. And to Mark's point about nonfunctional requirements, I think as a business, one of my non-functional requirements apart from building in the login flow so that I can use my connected device should be that the approach is interoperable and secure.

So if we think about the, there's a open source organization called O osp and they create a number of the top vulnerabilities. And so they have the O OSP 2019, and that's been re-released and reordered for 2023. These lists, all of the standard exploits that we see over APIs, and this most recent version, 2023, the top five were all density related, whereas historically it was more like a glorified version of an ES SQL injection.

So we, we know that the authenticated web is, is now the biggest use case. So we have that as a data point, which is that the new perimeter for a density is APIs. The second thing we know is an Akamai state of the internet report from last year, 86% of all attacks on the, on APIs, on the internet were known vulnerabilities. That still means that there are an, there's enough code going out there not using standards based approach that they are shipping. People are shipping out code that has a vulnerability that could have been picked up before production. That is a staggering amount of data.

Akamai sees more than 80% of all enterprise traffic and 70% of their traffic is APIs. Let's just think about the ESG impacts of that. So we think about privacy as apart from a governance's perspective, the carbon cost, the compute cost, and all of this stuff could have been fixed before production. So I think it's very holistic.

So the business I think is very, very well sort of, it should be very well motivated to see that the density purchases that they make are used in a way that, you know, that applications take best, best, best practices to, to sort of, sorry to prevent this from I am whispering now, mark, save me To be fair, I had, I was just off one, wasn't I? You guys want to save me? I should have finished my products whilst I was saying that. So API security, API security, privacy, right?

I, what I still like in the, in the standardizations landscape is more emphasis on the authorizations part. So what we did in the last 10 years is working on identity, right? But by using these standards like open Id connect and, and all the good stuff, we actually gave tools to the developers to share more PII across multiple platforms.

And we, we make the problem bigger rather than smaller. And the way ahead, my point of view is that we should have, we should focus less on the identity and more on the authorizations part. So a transaction is authorized, it's not necessarily needed to know who that user is that is actually executing that transaction. Someone says that this transaction is allowed and then we touch on on stuff like, like, like decentralized identities and verify our credentials and stuff like that.

And if we use these type of technologies, we need much more standards to deal with authorizations rather than with identity. I think that we crossed that bridge, I like that idea, but there's a level of complexity, which is hard and costly that goes with that I'm afraid. And in some regards, there's a real tension from a business perspective about delivering solutions that are competitive in the market and are swift enough to deliver that the, the competition haven't already delivered it and, and eating all the, all the cream as it were.

So I think that's, while it's accurate to say in a perfect world, that's what we would do, I think, you know, all of the fine grained authorization stuff that we've been hearing about from various vendors and standards bodies and you know, open source vendors or providers is great. We've been kind of trying to make that happen for quite a number of years already. And I know that it's an extremely hard sell to get a business to invest the time and effort into that level of fidelity when it comes to security.

And I, I think you know, why they should do that is also if, if you don't support modern identity standards, you know, again, no matter which ones they are, but if you don't do that, you are already starting with a lot of technical debt. I mean, products get shipped with technical debt all the time, let's just be clear. Yeah. But you know, it's much more than it needs to be if you still, you know, use some older tech or your homegrown implementation, you are already basically shipping something that's actually outta date.

And you know, we all know you need to support a lot of security reasons, primary and all that, you know, you need this. Yeah. So catching up later Yeah. Will be just harder, more expensive. Yeah.

So again, it's, I think it's shipping with technical depth that it's unneeded if you don't support the modern standards. So, So do we need a new standard on how to decommission technology Yet another thing that everybody needs to learn?

Yeah, perfect. That comes back to the, you know, there's so much to choose from anyway. Yeah.

So yeah, it's, it's nothing that's easily solvable to be honest. Right. I'd like to keep the panel discussion interactive with the audience. So maybe we can open the floor to some questions. I know there's already some online questions, but if anyone in the room has any specific question? Not yet. Maybe you can question. Alright. I was just wondering, as end users, you know, we have to protect ourselves, but what if the, the applications we are using is not following the identity standards, how can we actually protect ourselves then Don't use it.

But if, what if we have to? So there's a, there's a couple of options there.

Well, maybe not options. There's, there's a couple of challenges there. One is how do you even know Exactly. Yeah. And the other is even if you do know perhaps that unwritten contract between you and your vendor is, Hmm, this is really handy. I like this app.

Okay, I suppose I'm willing to weigh the benefit of this lovely little app, whatever it does with some level of risk. A lot of people will go for the shiny toy in exchange for a level of risk or a level of cost or a level of data abuse. But for somebody like you, obviously you're going to take the right decision and not use the app. Correct. Thank you. Thank you.

But, but, but it depends if I still may because it's not, because the standards are not followed that you can assume that it's insecure, right? So there are environments that have very particular security requirements that actually are not covered to its standards. Look at the company that I represent, right? And so the standardization is about commoditizing a certain practice and making sure that that same practice can be used across multiple vendors across multiple types of applications.

Yeah, I think, I mean that's the, obviously the ambition of this is that these are solved issues and as a consumer you should expect these things to be solved. And I think that should be our expectation of all of, all of our suppliers that they are adhering to, to this standard of quality.

I think, you know, what was, you know, certainly a concern after Cambridge Analytica and et cetera, I think it started to make consumers more and more aware of where you can have authentication, authorization and issues. I think Cambridge Analytica kind of bought it into the, into the public domain, but I think the biggest concern is when consumers start to get breach fatigue and don't care anymore. I think that's more worrying. I think we have this moment in time to make sure that we can get the hygiene a across the landscape there so that consumers can expect it.

I mean it's, it's almost like going back to 1998 and you sudden you finally saw a padlock on the browser and you're like, great, I can now buy this item. But it's almost like a, at that point you have no idea if the supply chain is intact. I'm sorry to say one of our Australian colleagues just left the room, but I can tell a little story, which is kind of an interesting comparison between two worlds.

So I've been working on an identity project in the UK a little bit, and I'm hearing from the kind of requirements direction I'm doing elements of the engineering of it that they need all this data for regulator requirements and audit purposes. And it's quite a lot of data being passed backwards and forwards for every transaction. And I'm a little uncomfortable with that, I have to say. But an almost identical business proposition in Australia is happening as well. And they are minimizing to the max.

And the reason there's that difference is there was a humongous breach in Australia about 18 months, two years ago, and the regulators and the implementers have in their minds the enormous risk of our large scale data breach. So I think although we all have a bit of fatigue about those stories of, you know, mountains of data being breached and released on the dark web or ransomware or whatever, sometimes it actually goes into the people that are defining and implementing these systems.

And, and sorry Mark just to, if people in the audience aren't aware of that, that data breach that you refer to, there was a telco telco, they had a directory for an integration. Somebody wrote an API with God access to the directory, it accidentally reached the public internet. And because it was a low and slow attack, it wasn't really a breach, it was, it was a leak. They didn't detect it. 11 million records were exposed, 5 billion of them had passport numbers. They had to pay for the issuance of 5 billion passports in Australia. It was a pretty significant thing.

So the directory was breached from an api. Yeah, just like to, oh, sorry.

No, go. Just briefly emphasize that, you know, just because using a standard doesn't mean it's secure and vice versa.

Yeah, right. So you can do a really shitty job implementing ED connect and still be unsecure, right? So I think it makes things easy in some sense for the developers relying on libraries and all that, but it doesn't mean it's a secure system out of the door. Right. So let's just be clear on that one.

Hey, I'm Mike Schwartz, I'm The founder of Glue. Just to pick up on your point for a minute, actually, the certification test suite that open ID publishes is fantastic, but there's a, you could drive several tanks through the amount of negative tests that are missing from there. So if you really want to, even if you're certified and we, we certified more than anyone, you'll still find that it doesn't give you a level of assurance about security.

But wait, that wasn't my question before you jump in. Well, well let, Just let me jump in there please. You know that guy over there, right? Yeah. So Yeah. Okay. That's fine. Thank you for writing those tests. That's so valuable for us and it's so great for me as a, as a, let's say product owner to have, I mean, we can write our own tests, but having somebody else write tests that it's an extra level of, of, of quality assurance for us. So it's amazing.

But don't rely, I always tell vendors don't rely on that because they're really, like, the amount of negative tests you could write is almost infinite of like stuff that you could do wrong. And so you really need a certain amount of production, deployment and experience. And some of those negative tests you're finding like, oh shit man, we gotta make sure we test for that one next time. There's a lot of them out there.

Sorry, mark, Do you want, do you want your question then? Yeah, yeah, go for it. Sorry.

No, no. My question's more about developers and API because, you know, I feel like we have a lot of standards about how clients get credentials, but there's a disconnect between the API community and the, let's say the identity community, which wrote a lot of stuff about client identity. And so I think end users don't really know about any of this stuff, but I feel like the API developers maybe should, but they don't. And how do we maybe address that? Thank you.

Oh, Michael, thanks. That's a, that's a great question. That's one of the reasons why I sort of moved from Jan Rain into thinking about API security because we, we, we give API developers the keys to the kingdom and you know, one of the, I think one of the challenges you have in an enterprise is there is a clear identity to for own, sorry, there's a clear owner for identity entity, there's a clear owner for security, but who in the enterprise owns APIs? And that's I think where we've got this real problem.

There's not some, there's an emerging jobs title, the products owner for APIs, I think that's starting, but there's just no one championing governance in APIs. And so I, I don't believe that that problems should lie with a developer, but it needs to be like an organizational awareness and the saying that we now have that with cloud. And so cloud has a significant amount of governance within an enterprise where APIs still don't. I think that's where we have to start. Have We've got any Chief API security officers in the room?

No, that was, that was a nice point there. But just back to the conformance testing stuff because, because that's dear to my heart and I, I sometimes like to channel Joseph A. Little bit, that is a super piece of work, but if anybody has negative tests they'd like to donate to the foundation in this space, that would be a great thing for the community at large, not just for the Open ID foundation. So We have around six minutes left so we have some time for questions if anyone from the audience has any question.

If not, I know there are some questions online. So how do companies even find out if their applications, APIs are leveraging their identity investments?

Well, do they actually know what applications they have and what they're running? Right? I think happening inventory of everything that runs is one thing. And then know, knowing all the details about this, quite the other, I think, you know, for larger companies and you know, if you're asking me what is running, what infrastructure do you have, that alone is a hard question to answer for many of them. Yeah. And then diving even deep into that, like, you know, which tenants are they using? And then down to like details, many will be overwhelmed by this, right?

And I think it starts with like, you have to have a practice governance around this to start with. So you never, you don't, don't even reach that stage where like you go like, I don't know. Yeah.

So that's, that's a bigger problem that that's not just for api, that's, you know, application security in general, Unpopular opinion. Do they even want to know? Because as soon as you know, you have to kind of do something about it, right? Yeah. But not knowing doesn't prevent you from being sued. Right. So just because you cannot claim innocent saying like, I don't know. Yeah. And like I cannot be blamed. Yeah. At least in many jurisdictions. Yeah. There might be somewhere. This is the case.

Yeah, no I wasn't, I wasn't gonna go there, but yeah, go for it. Or you want to Mike?

Okay, I I have a question and I think that's fits into to this not knowing may not be sufficient anymore. So did you also experience, it's something we've, I've heard from a couple of CSOs specifically from the German banking space, that auditors start to ask about which APIs do you have in place? How do you have secured them, et cetera. Is this something you're observing as well that an audit pressure start starts to build up requiring these things?

So where, where ignorance doesn't help anymore or ignorance? We're starting to see some market demand for the, from heavily regulated industries. So obviously financial services are the biggest consumers of point API security vendors, but then closely followed by telecommunications and as part of part of their compliance, as you get to a sort of a change in APIs, they have to reissue evidence for risk posture. So we're starting to see some regulatory pressure, but it's not democratized yet.

And so we still have very, very expensive solutions that basically just do discovery that are charging more than you spend on your directory to offer very little value to the business. And so I think we've completely incorrectly priced API security. It needs to be table stakes. And then Martin actually looking at your, your, your keynotes, you, many of the things you talked about in sort of maturity model of identity fabrics, we talked about maturity model of zero trust, we've digital assets are in part of all of this. I think the challenge is that APIs is also part of the application.

And until we know what APIs we have, I feel like we're blocks on all of the other maturity models, not just application security. Okay. Thank you. I'll take a, another kind of dimension into account. I think something that is going to emerge more quite soon because of actions taken in Europe and the US is a link into the kind of supply chain security domain as well.

So we've got legislation coming in in Europe and executive order coming out of the Biden administration requiring people to, or organizations to be able to demonstrate that their, their implementations are compliant with a whole range of best practices. And the ISO specifications behind this 27,001 and 22 3 0 1 are both being applied more rigorously. And I think the audit regime around that is starting to emerge as well. All right. I think that we are right on time now. If you have any other question then we can conclude the panel. Yeah. Thank you so much. Thank you.