EP12: Our Quick Hit on How Hard Security Deployment Really Is

Speaker 1: 0:22

Welcome to Making Data Better, a podcast about data quality and the impact it has on how we protect, manage and use the digital data critical to our lives. I'm George Peabody, partner at Lockstep, and joining me is, of course, steve Wilson, founder of Lockstep.

Speaker 2: 0:38

Great to see you, Steve. Good to see you too, George, over the channel, over the signal processing, making podcasts better.

Speaker 1: 0:45

There we go, we're making audio data better.

Speaker 1: 0:48

All right. So, look, this is going to be one of those podcast discussions between Steve and George, so we won't inflict it on you for very long, but we wanted to talk about I guess the topic really is around the distinction between technology and the context that technology has to operate in and that has everything to do with the business incentives and the perceived benefits of a technology adoption and the competition of adopting something. And, of course, we're talking about security here or security-related topics, the tension between implementing those kinds of things versus adding yet another function to the software that you're selling, for example. Right and Steve and I are all about the sharing of metadata, the story of the data of sort of around an identifier like a phone number or a driver's license. We want to know. How long has that been in existence? Where did it come from? There are great examples out there in the world of metadata being shared.

Speaker 1: 2:02

Using existing tools works. We like PKI, digital certificates and cryptography at the edge, so we've got things like chip cards great example of a combination of hardware and software getting rid of plain text presentation We've got now well, it's been a year or so since passkeys have been introduced and here's a hardware and software-based combination to kill passwords. Very exciting. Which phone numbers can be spoofed by a robocaller to make me think I'm getting a call from my next-door neighbor. Indeed, the telecom industry has got one called Stir, stroke, shaken. Of course, stir and Shaken for those of you who may remember James Bond, ian Fleming's spy character.

Speaker 2: 3:02

He took his martini shaken, not stirred. It's terrible. It dissolves the ice. It's one thing James Bond got wrong, I think.

Speaker 1: 3:08

Here is an industry that's trying to go after robocalling In the United States. It's getting some significant pressure from the Federal Communications Commission and yet the fact that the business case for deploying it clearly isn't high enough for what, after a few years, is a flat adoption rate of that technology in the 35% range, I think, which means the impact on robocalls is essentially negligible, which really gets to that preamble I gave around where you've got to have a business reason and you've got to have ubiquity if you're going to be able to put up a barrier to bad actors.

Speaker 2: 3:55

There's so many demands on product developers, software engineers. These days. The product development lifecycle is so tight, the competitive pressures are so high for overt features that basic hygiene, I think, always suffers, which is sad. You know, we've had this capability with the mobile protocols to do much better confirmation of origin. That metadata is available. If developers had time to know about it, implement it, talk to their colleagues. I mean, a lot of this has got to do with co-op petition, doesn't it? You do need to be coordinating across competing telco providers and even handset providers to really leverage some of this technology. So I think in a busy day-to-day life of the developer there's so many demands on their work that it becomes difficult to get what we call a non-functional requirement up on the table. I reflect sometimes.

Speaker 2: 4:49

We've been talking about verifiable credentials, george, for months now. Well, years in the industry, but months on our pod. I always say that one of the original verifiable credentials is actually the SIM card itself. And if you think about it, there's a chip in everybody's handset that protects their mobile phone number. It actually protects their so-called IMSI, the International Mobile Subscriber Identifier, which maps onto your cell phone number. But the irony of all of this is that the world's first verifiable credential is sitting in everybody's handsets. It's a cryptographically signed copy of your definitive IMSI and the handset could make that verifiable credential available to the firmware in the phone so that every single phone call could actually be checked against the EMSI. And the network, of course, does this. The network checks the EMSI because that's how it generates bills. Global roaming depends on the SIM card signing the EMSI and sending it into the network so that a handset identifies itself at the start of a call. So that a handset identifies itself at the start of a call, you know, it kind of frustrates me that that signal is not also available, I guess, at the firmware or the software level in the phone, so that the handset could also identify whether the claimed caller ID actually matches the EMSI or not.

Speaker 1: 6:07

Which I knew more about, the stir-shaken protocol, but it doesn't seem to be going to the hardware at that level. It looks to me like it's a software-only approach.

Speaker 2: 6:18

Yeah, and you mentioned before, George, as we were preparing for this, that there is this sort of cross-protocol problem too, that telephony these days is mostly about IP telephony and not just using the network infrastructure. So we think that what happens is that even if you're using this protocol as a call, as the call data moves between an IP network and a mobile broadband network, a lot of that metadata gets lost. It's just too hard to keep the metadata across those different boundaries, so it disappears. Priority is given to the actual call data and maybe the data, the IP payload and all of that metadata that shows us where it's come from and what it's supposed to be used for and how does the data originate. All of that metadata gets lost. It's dropped on the floor.

Speaker 2: 7:07

It's an important resource, but we just can't maintain it.

Speaker 1: 7:10

So, steve, what have you seen with respect to solving this? It's such an important resource, but we just can't maintain it. So, steve, what have you seen with respect to solving this ubiquity problem? And I'm going to take up some more airspace here.

Speaker 1: 7:20

In the payments world where I come from, apple Pay been around for almost a decade, had a very long time to reach hockey stick level adoption because it required handsets. It required the comfort level to be attained by people to load their phones with payment credentials. That was a new thing. Of course, it took a contactless footprint all around. The convenience factor is way up there, so it's getting used more and more. It's still not ubiquitous Even in that case. The specification on which Apple Pay is based and Google Pay and Samsung Pay all follow it the EMV tokenization specification, framework specification. It specs a lot of data, specifies a lot of metadata types. It's really handy for risk management and the challenge here is that a lot of entities that might use that metadata don't. They don't adjust it and use it for risk management capabilities. Back to my question is how do we get security to be a priority against the functional stuff?

Speaker 2: 8:32

It's our old friend regulation, isn't it? I was wondering where you'd go.

Speaker 2: 8:38

Look, it's hardly our lone voice calling for regulation. I mean none other than Bruce Schneier, for example probably the world's most preeminent security commentator and security engineer has said for a long time of things like IoT, the Internet of Things, IoT. Security is such an important thing. It doesn't get a voice at the table in the competitive product engineering landscape. So Bruce Schneier calls for regulation to mandate minimum security on IoT devices, and I think he's right.

Speaker 2: 9:11

I think you get a market failure with safety. I mean, Lord, let's go back to automotive safety. With the best will in the world, competitive businesses don't prioritise safety, especially when it's not a competitive differentiator, and we don't want safety to be thus differentiator and we don't want safety to be thus so. The brutal truth is that capitalism fails to deliver safety when safety is not a competitive differentiator. That's almost like a law of nature. So we do look to regulators, and perhaps that's why these things move so slowly, because regulators are notoriously slow. But I think that the parallels between car safety and internet safety and cyber safety are very strong and very obvious.

Speaker 1: 9:55

Sure, we've seen it with automobiles and, of course, we've seen it in airlines and aircraft.

Speaker 2: 10:01

Faa is very strong, your favorite example, the importance of airline safety and the advances in airline safety are down to regulations. I think everybody would have to agree on that. That's right.

Speaker 1: 10:12

Very rigorous certification requirements for every type of aircraft and every modification to that aircraft.

Speaker 2: 10:19

So we're actually asking politicians, I guess, to regulate things that lead to robocalls, and maybe the political competitive imperative to regulate robocalls is not there. I mean, where do most of our robocalls come from? Politicians?

Speaker 1: 10:35

Do we just stop and weep at this point in frustration? You know, I do think that and we've talked about this a lot amongst ourselves is that how do you build in economic incentives to improve security, incentive to build to improve security and you know, you and I have talked a lot about in our own thinking about a solution is that there are economic models that could actually, in terms of sharing verifiable credentials, there are ways that a party that's consuming those credentials, that has to make a risk decision based on it, has an economic incentive for paying for it.

Speaker 2: 11:07

Paying for better data. You're saying Pay for the quality signals. Maybe they're optional quality signals.

Speaker 1: 11:13

We've got a ton of relying parties who subscribe to services like LexisNexis Risk Solutions and and other data providers because they need to spend money to manage their risks. There's a way you know alternatives that require less storage of data, stronger proofs of data provenance, just to say that there's not an economic engine that's available. That's not the case?

Speaker 2: 11:45

No, it's plainly not the case. We have a free market that has led to a marketplace of data signals. Businesses do pay, and they pay a lot for better data, and in a sense, it's a good thing. I don't think the way that that data is distributed at the moment makes a lot of sense. I think that the market is corrupted by a number of misaligned interests, shall we say, to be politically correct. But clearly, in a sense, information wants to be free. There's so much free information out there and yet businesses do pay a premium to get those risk management signals.

Speaker 1: 12:20

Information wants to be free is just some hippie nostrum call. We have always paid for quality information. We've paid for books for centuries. That's quality information. Just because I don't have to go to a library or a store to buy a book online, there's no reason why it should be free. I think, as an industry looking at systemic economic incentives and getting those aligned around the sharing of data using more broad mechanisms rather than the I have to contract with company A, company B, company C to get the data that I'm looking for and hoping that it's accurate we can do a lot better. All right, we leave it there, steve.

Speaker 2: 13:06

Yeah, it's one of those little conversations that raise more questions than answers, so we always hope that our listeners and our audiences have come here for ways of thinking about problems and unpacking the dimensions of this wicked problem. There's no easy solutions, but I think the principles are becoming clearer. How do you make data quality, signals, metadata, how do you make it available and how do you have a flatter playing field, I guess, on how to access that data and how to pay reasonable?

Speaker 1: 13:38

fees for it. Well, that's it. I think it's this combination of sure regulation when it's feasible, possible. Living in the US regulation is a challenging piece.

Speaker 2: 13:49

How very polite of you.

Speaker 1: 13:58

Politics drives our regulation hugely, of course, and tempt businesses to deploy with a regulatory kick in the back, because I do agree that a regulatory push, it really moves markets. You know, one of the reasons I'm excited to have this conversation with you, steve, is what appears to be happening in Australia is that there's a lot of strong, focused thinking on this topic and what's the role of regulators, what's the role of the market? It's top of mind, so at least I hope our conversation is useful in your neck of the woods.

Speaker 2: 14:40

Definitely so. We could flag another podcast from National Australia Bank, which had me as a guest, on their Digital Next podcast. That's going to be posted next week sometime, and we've got a couple of blogs lined up that you'll also see at the Lockstep website, discussing what we think is shaping up to be Wall's best practice in terms of regulating digital ID and a vision for how this might be extended to regulating all sorts of other data as well. So it is a really interesting time here in Australia. It's been a long time coming. We've got probably the third iteration of what used to be called digital identity legislation third iteration in 15 years. But no, we're absolutely getting there. It's good to see some progress.

Speaker 1: 15:21

Good. Well, on that optimistic note, I'll see you next time. Got to be optimistic, dave. Absolutely. Thanks, my friend. Talk to you later, cheers, thank you.