Recently we had the Optus “hack.” Now we have the T-Mobile “hack.” It bears repeating what we’ve been saying all along about API security: We should stop calling these “hacks.”
This reminds me of an old story:
You’re walking home at night and see somebody looking around for something under a streetlamp. Turns out they’ve lost their keys and need help. You ask where they last saw the keys. They point at the dark woods off the sidewalk; over there, they say. Why are you looking here? Well, they say, It’s dark over there, but there’s a light here.
So it is with many so-called API “hacks.” Time and time again, what looks like a hack really isn’t.
The problem isn’t a hack.
The API is doing what the API was designed to do, the way it was designed to work. The problem isn’t a hack, so having the best API security solution on earth isn’t going to help.
It’s like having the best home alarm system designed and not turning it on – or leaving the window open with your wallet and car keys on the sill.
You’re protecting the wrong things in the name of API security.
Security is a part of the API supply chain. Enterprises need to see security as part of a holistic view of their API Supply Chain, just like they would with anything else they buy, use, or supply.
As a banking client said to us recently on this topic. “It is not enough to think you do something. You need to be able to prove that you are doing it too.” That means taking all reasonable steps to ensure you’re not going to have regulatory or security fallout.
The difference between a fine from a regulator for a breach and having a defensible position is having an audit trail of actionable proof that you are looking for the things that potentially led to the breach.
If you have a requirement that data is updated daily, do you check that the data is, in fact, updated daily?
If resources should be protected by API security, do you check to make sure that you cannot, in fact, access them? We see situations where, for operational reasons, security was disabled temporarily to fix a problem. But then, for whatever reason, it did not get turned back on.
Do you check the payloads of key scenarios for data that shouldn’t be there?
Could you prove to a third party that you are making checks for PII leaks? That check could be the difference between a fine from the EU or CA government and no fine.
These are critical actions that can be very easily done with APImetrics – but they aren’t being done by people right now who can’t afford not to do them.
Start at the very beginning…
Starting from design, you include the policies and governance of how the APIs should work (look at our partners Stoplight and 42Crunch), what they do, and what they shouldn’t. You test those policies before going live.
…and keep going.
But it doesn’t stop there.
After go-live you keep checking that your design and your policy are still in effect. Does the API allow access to resources? Are you doing positive and negative checking of your security setup?
API security and governance demand a holistic approach that includes your security tools, your APM stack, and your design tools – and gives you a fully independent view you can trust.
Let us show you how, and let’s stop these so-called “hacks” in their tracks. Setting up your calls is much easier and quicker than you probably think it is.
And we can guarantee it is a LOT cheaper.
Book a Demo
Why not have a demo? We’ll show you how APImetrics can have functional governance and API security checks up and running in a matter of minutes.