We frequently post news about data breaches. Sometimes it seems almost too frequently because companies are suffering hacking, data exposure and extortion almost every day. While the news becomes almost repetitive, the frequency of these breaches shows a definite trend.
There are really three main ways that bad actors are getting access to corporate data.
“Phishing” is where you get tricked into thinking that you’re entering your credentials into the right site, but you’re really just handing off your username and password to a hacker. Usually, a notification (email, text, etc.) pretends to be the provider, leads the you to a site that looks very, very much like the real site. Then they get you to enter valid credentials, which they steal and use to access the account themselves.
There are a couple problems that happen when someone grabs your username and password. The obvious is that they get access to your account, but they often get access to a lot of other things too. If you use your email address and repeat a password, the phishers can widen their net and start trying to log into other platforms with that username and password.
At Cloudentity we believe MFA (Multifactor Authentication) is a must. But not just once when you log in – a “one and done” MFA can also be intercepted and relayed (see When 2FA isn’t Enough).
We recommend adding MFA not just to your single login, but to individual services, meaning the consumer of that API has to prove they are who they say they are more often than at login (for example, if I hack into your account and try to change security settings, you might want to get a text message to confirm this kind of change).
See MFA for OAuth? for more details.
Only one Gate/Insufficient Rules
A lot of API security focuses on the entry, but it’s assumed if you were trusted to get into the API you’re trusted to see just about everything. With increasing rules around privacy and consent, the cost in technical recovery, company reputation, and legal fines is rapidly growing.
Many of the breaches we see come from a bad actor getting ahold of a key or an account that has access to everything. In the Capital One hack in July the hacker was able to download 100 million credit card applications with a single credential. It seems that the DoorDash breach was because an application’s keys were compromised and then a bot went in and harvested data through the API. And we’ve heard for over a year about how Cambridge Analytica trolled tens of millions of records on very shaky “permission” grounds.
Personal data needs consent – a single application that hasn’t be explicitly granted access by the individual “subject” (the person the data is about) shouldn’t have access to that data. That consent should have a record of when it was issued, and that consent should have a limit – grant a survey on Facebook access 10 years ago and they still have access.
Cloudentity’s permission service allows you to weave consent and access into individual API endpoints. It keeps a record of when access was granted, and it logs who accessed what and when (which is another problem with this kind of breach – if you don’t know that they weren’t supposed to access data, you often don’t know that they did).
No Security at All
There’s a fundamental problem with trust – when a company releases data to a vendor, it’s simply assumed that the data will be secured. As we’re finding, that’s simply not true. We’ve seen breaches where vendors forget to lock down access to off-the-shelf tools like Elastic Search or mongo dB and we’ve seen where the API security for a web app seems to have been simply turned off.
No one is going to pretend there is an easy way to combat lazy vendors who forget to add security to data provided to them by clients, but public opinion and the law are starting to pressure companies to keep control of data, even when that data isn’t in their hands.
Cloudentity’s MicroPerimeter™ Security provides a path to enforcing security and audit even when data is running on another company’s infrastructure. Enforcement tools like the Edge Gateway or the MicroPerimeter™ Sidecar are lightweight enough that the vendor can run a copy right next to their copy of the data – protect http endpoints for mongo or Elastic or add it to custom APIs.
Then the company that owns the data is able to provide security policies that meet their business requirements (not the vendor’s) and everything is monitored and logged – if you don’t see any traffic, it might be time to call the vendor and ask them if they really secured the data. If you see unauthorized traffic, you can adjust it remotely.
At the end of the day most breaches are avoidable by being diligent and securing everything. But we know we’re all human beings and we’re going to make mistakes, so it’s better to set up security and rules in advance that make it very difficult for those mistakes to end in another data breach.