Sounil Yu on FCC Consent Decrees and API Security

Jeremy Snyder (00:02.422)
All right, welcome back to another episode of Modern Cyber. We've got something a little bit different today, a little bit of a rapid reaction and explainer discussion today with Sunil Yu. I won't take the time to go through Sunil's background on today's call. Suffice it to say he's a member of the Cybersecurity Hall of Fame. We've had him on the podcast before. He's graciously taking the time to walk us through a little bit of understanding what we've seen in a consent decree that came out yesterday between the FCC and an affected company. Sunil.

First, thanks for taking the time. Second, to the extent that you can, help us understand what is a consent decree or what are generally this type of agreement between a regulator and a company that's experienced a data breach or an incident.

Sounil Yu (00:44.619)
Yeah, so consent decrees come from regulators and so these are really only mostly pertinent to those types of industries or companies that are regulated. And the consent decree is essentially a very formal sort of declaration of, hey, you are out of compliance in these specific ways and you need to basically, you consent to these actions that you need to remediate within a certain timeframe.

If you fail to remediate them, well, actually, you'll still get fined either way. But if you fail to remediate them, then it could go as far as shutting you down. I mean, that's what a regulator can do. So it's a pretty serious. One should consider a consent decree to be a very, very serious matter.

Jeremy Snyder (01:33.116)
And does it mean also that, let's say, like, current investigation into the company's current cybersecurity practices probably stops at this point, the fine gets paid, and then in the consent decree, it seems to be that there is some description of what the company needs to do moving forward. Is that kind of a way also to think about it? It's like, OK, draw a line in the sand. Everything that's in the past is in the past. Here's what you need to do better moving forward.

Sounil Yu (01:59.504)
That's right. And so as a regulator company, to get out of the consent decree, to indicate that I have consented to whatever actions that you've asked me to do, I would want very precise, very explicit set of do exactly these sort of things. I wouldn't want ambiguity on those things. And if there's any ambiguity, then it makes it really difficult to know if I've accomplished whatever the regulator wants me to

Jeremy Snyder (02:26.695)
Well, that actually leads into my next question, because in reading this consent decree, and we'll post a link to the decree in the show notes, I don't want to call out any companies by name on the podcast here. in reading this out, there was a mix that I saw around kind of general

requirements around improving the cybersecurity program of the organization, coupled with some specifics around API security in this case, as it seems to be that APIs were the primary breach vector for a lot of the incidents that have been called out in this company. So it seems like that would actually also be kind of typical, you need some kind of, you know, some kind of checkboxes that a regulator could come in and measure to see whether you've complied with the conditions of the decree.

Sounil Yu (03:10.182)
Yes, and when there's ambiguity, especially when it comes to certain types of security practices that may be emergent, I'll honestly say that I'd have trouble with a regulator trying to enforce emergent practices on me because if they're emergent, then how do we know that's a practice that everyone should follow, right? But if it's a well -established set of practices, then they should also have a well -established set of actions or things that we can

Actually, to put Firetail as a specific example, if there are things that we know we should do to address common flaws and problems in APIs, well, we know that there exists a well -known, well -established practice because there's technology that actually helps us do that. Almost by definition, the fact that technology exists to help us do that means that there's a well -defined set of things that we need to do. I would say if there aren't technologies that help us do

then it's either usually because of a process that needs to be implemented. And, you know, there's ways that we can affect those, but also maybe it's just because we don't actually have a best practice defined for it

Jeremy Snyder (04:22.15)
Yeah, it's interesting, know, specifically coming to APIs and obviously it's a space that we spend pretty much all our waking hours working on over here at Firetail. They call out two things. One is NIST standards and the other one is OWASP API top 10. And on the NIST side, there is no standard relative to APIs. And, you know, it kind of led me to speculate with somebody and I'd be curious to get your take as well. If there is no NIST standard around a topic,

you kind of default to the cybersecurity framework as a lens to use to evaluate a set of practices. That was my inclination. Is that where you would lie as well? If somebody said to you, do NIST for this, and there isn't a specific regulatory framework that you apply, is the CSF like the

Sounil Yu (05:07.989)
I'm not sure what fallbacks you might refer to. mean, CSF in many ways is maybe a very generic fallback, but it gets even more ambiguous in terms of what specific actions one needs to take if you're just saying we're going to rely upon this or we're going to fall back to this. I think the other consideration is where there's ambiguity, one will hope that the regulator sides on the company or entity that's being subject to the decree.

in terms of their interpretation of how they've achieved it. But again, where there's ambiguity, it's gonna create this sort of concern around, we actually meet what was intended? If I were recipient of it, I would definitely have my lawyers and have my, have folks work through that with the regulators to make sure that we have a clear understanding of what done looks

Jeremy Snyder (05:58.774)
Yeah, because to that point, otherwise it leaves a lot of room for interpretation. it's entirely possible that companies, through their own reviews and their own process design, can come up with a reasonable explanation for why they've done what they've done, but it may not actually, let's say, sufficiently mitigate some of the threats that are out there.

One of the other areas that got called out here is the OWASP API top 10, which interestingly, when you look at it and you read it, it's a risk model. It's not a set of controls. And it's something that we hear at FireTail. We've actually been hearing this a lot. We hear from people that they're getting started on an API security process, and it is kind of the default. It's what they look at. And it's great in the sense that it guides you to where,

these are the techniques that, or these are the areas where vulnerabilities may exist, where attackers might come at you. But it doesn't give you, let's say, line item controls and checks to put in place to know whether you've sufficiently mitigated against those threats. So that's something that we see as a little bit of a weakness on the API side. And by the way, stay tuned for more on that, that we're working on something there.

By way of kind of like one maybe final question to close things out because I know we're tied on time here as someone who's worked in a regulated industry in the past if you see something like this happen to a company in an adjacent regulated space What does that indicate to you? Is that kind of an okay? Just keep an eye out or is that more of like we need to start thinking about this because The day that some company in our industry gets compromised similar regulations are going to be coming for

Sounil Yu (07:31.588)
Sure. Yeah. I would think of this as like judges in different jurisdictions, right? You have a judge in a particular jurisdiction and they make, they weigh in on something and that's, that's a precedent. So these regulators are different judges and a precedent has been set. If this precedent is something that's can be broadly applied to anyone like API security, I would say that is, it's it's a wake up call to anybody who's using APIs.

Jeremy Snyder (07:56.925)
Yep. Yep.

Sounil Yu (07:58.712)
regardless of what industry you're in, that, hey, regulators are starting to pay attention to this. So I would say, we all know API security has been a concern for a long time, but now it becomes a higher priority concern because regulators now have a precedent to go after people for not paying attention.

Jeremy Snyder (08:18.459)
Awesome. Well, we're out of time. Thank you for jumping on at such short notice to go into this. I know a lot of people in the audience will greatly appreciate your perspective as somebody as a long time practitioner in a regulated space, also with the perspective you bring from all the analysis work that you've done. Sunil, thank you for taking the time to walk us through your thoughts on this consent decree and what it means for API security. All right, we'll talk to you next time on another episode of Modern Cyber. Bye bye.

Sounil Yu (08:38.83)
Thanks for having

‍