There Is No Magic Bullet for Runtime API Security

By David O'Neill, CEO APImetrics

September 2022, every CISO’s nightmare: Optus systems, an Australian telecom, sustains a significant “cyberattack.”???

An attacker managed to access the complete database of Optus’s customers' personal information, including names, dates of birth, phone numbers, and email addresses. They subsequently attempted to hold the company for a $1M ransom.?

The media tends to refer to such breaches as “hacks.” But is it really a hack if a programmer simply calls the API the way it was designed to be invoked? The vector of attack was an API that provided access to the records and personal information of all Optus customers.?

There is a tendency in lots of fields to fall into one of two traps.??

1. Regulate or design away something that has happened in the past.??
2. Jump reactively on a technical solution that falsely promises to solve the problem.?

Reaction in Australia has fallen into two parts.

The first is that there should be better security regulations and standards about the handling of PII through APIs, especially in a country where there is an implicit right to access your own data (link to the CDR). This is a good reaction and correct.??

The second is that we should have better API security. This is also a good reaction and correct––but it’s only part of the problem.?

A recent post on a related API security topic on Nordic APIs mentions that organizations need to think about how they measure their API security “left side or continuous.” But this is both a false dichotomy and, frankly, missing one of the key points about this “hack.”?

Again: it's not a hack if the API functions as designed.?

Sure, you can design security into your API. You should, by the way, get somebody like 42Crunch onto that immediately if you’re not.??

You should also look at your traffic for attempted hacks. There are lots of products for that too. Salt and Noname Security or Netacea are credible solutions depending on your operational needs.?

But in this case, the API did exactly what it was built to do.??

Yes, it was poorly designed. But you can’t design away human factors in the software development and deployment lifecycle. You can have the best car/home security in the world, locks that can’t be picked, doors that can’t be jimmied––but if you leave the car/house and forget to lock up, it’s all for naught.?

We see this with API Security all the time, even in the most regulated of API sectors.

Everybody in the IT industry has a story of something that has worked perfectly for months or years that suddenly stopped working or working in an unexpected way when you haven’t touched it. The nature of the cloud, of distributed API platforms with interactions with many components makes that a certainty. At APImetrics we see it all the time (and not just with client solutions). It’s a feature (bug?) of the IT industry.?

So, by all means, left-shift in better security. That is essential. Have something that will check for people trying to break in and stop them. That is also essential.?

But you have to monitor that everything you have designed is working the way you expect it to 24/7 from everywhere that your customers are calling you.??

Synthetic monitoring isn’t just about performance and functional measurement. It’s a major part of knowing your security model, too.?

Some think that continuous functional monitoring in production is too hard and unnecessary. We reject this. In fact, we built the entire platform out to prove it isn’t. It’s an absolute requirement as part of your security solution and it should go hand in hand with necessary regulatory oversight.?

Like with performance monitoring, SLAs, and other API issues in general, it’s not about doing the job because you have to. It’s about doing the job properly from the start and being able to PROVE to somebody else, including yourself, that you’re doing it properly.?

This is why APImetrics is adding lots of new ways to measure your security in production. It lets you monitor even the most secure API configurations effectively, in a no-code way. And it gives you the data to prove that, in production, everything is working as expected––even if you have a solution with OAuth, JWT signing, and other complexes (expensive to replicate components).?

The real question is this: Can you afford not to have production security monitoring of the run-time in place??