[BreachExchange] Countering threats: Steps to take when developing APIs

[Destry Winant]

https://www.helpnetsecurity.com/2018/11/06/developing-apis/

High profile data breaches resulting from faulty APIs continue to make
headlines. In the last few months alone, T-Mobile’s data breach
resulted in hackers stealing personal data of more than two million
customers while Google shutdown the consumer version of Google+,
citing a bug that exposed the personal profiles of up to 500,000
users, with the API at fault used by up to 438 applications.

Privacy and security issues stemming from API development have
continued to rise over the last year, with Gartner predicting that it
will be the largest source of data breaches by 2022. But without a
deliberate, focused effort to protect these systems, even that
timeline seems optimistic. To counter this threat, businesses need to
follow these three steps when developing APIs.

1. Only store the data you need

Storing data on customers and employees provides benefits from both a
marketing and functionality perspective. But, for too long,
organisations have collected unnecessary amounts of data, which if
compromised, can result in damaging financial implications. According
to IBM and Ponemon’s 2018 Cost of a Data Breach Study, the average
cost for each lost or stolen record containing sensitive and
confidential information increased by 4.8 percent year over year to
$148. With millions of records compromised in each breach, the total
becomes astronomical.

This year’s Facebook and Cambridge Analytica scandal is a clear
example of this data misuse. The social media giant collected and
shared large volumes of redundant data, which led to a third party
having the ability to take action on information that they should not
have had access to.

Match.com’s glitch this year is another example. A high number of old
profiles, some that had been inactive for over 10 years, were
reactivated on the dating website. With so much unnecessary
information still stored, we can only assume they still have every
message between those and every other user. If Match.com was hacked,
it would compromise confidential data it should no longer have.
Businesses need to learn from the fallout of these two issues,
otherwise any API hack would result in dramatic consequences.

2. Make security the number one priority

Developers have often built with a feature-driven mindset, where
functionality has taken precedence over security. Unfortunately, in
today’s security landscape, vulnerabilities and threats lurk at every
corner and have ever-growing consequences, so we have to turn this on
its head. It has become even more of an issue in the race to comply
with new legislation, which has left holes where hackers can exploit
potential data.

This is counterproductive and can cause additional issues for
organisations. Most recently, the Financial Conduct Authority (FCA)
announced it will force UK banks to publicly reveal the number of IT
outages they have via an API, showing the importance of open and
reusable data provided via APIs. We’ve also seen the implementation of
GDPR, where data breaches will now result in major financial fines on
top of the reputational damage they cause. As other jurisdictions
consider similar rules, the legal and financial consequences will only
grow.

3. Take a unified approach

There are myriad approaches to API security that businesses currently
take. They need to move away from unqualified trust and API Keys,
which expose sensitive data. If you have an API, you must assume that
others will find it and try to abuse it. Using an API gateway is a
useful and valuable step but, when used alone, they do not give
businesses the full context of the user, their session, and the
connecting device. They lack the ability to differentiate between a
user on the trusted computer at their office versus a suspicious
mobile device on the other side of the world.

There is another approach that businesses should be following – the
industry standard, OAuth 2.0. It works like a hotel check-in
experience, where key cards provide select access to portions of an
application depending on your permissions. Specifically, access
tokens, granted by an Authorisation Server upon proof of identity,
allow access for the specified user to a specific set of resources,
with an automatic expiration.

OAuth is a more complex approach but allows far greater flexibility
through structured consistency – an unquestionable benefit in the
world of security. It’s important to remember, however, that OAuth 2.0
is still not a complete solution for securing APIs because it does not
address how to protect the API itself. Just like any other system in
our infrastructure, we have to defend our API from malicious users and
poor software regardless of how they approach it. A great lock on the
front door isn’t enough if we leave the windows open.

To make APIs as secure as possible, it’s important to combine API
gateways with OAuth. The two technologies complement each other to
create a powerful API Access Management solution that can limit
particular OAuth scopes to specific devices, a specific network or
group membership. They also have the added benefit of enabling a
security team to manage policies like this outside the API Gateway,
while centrally logging access requests, grants and policy changes.

Hackers are sophisticated and are constantly looking into new ways to
break down defences and access valuable data. There is no silver
bullet to stop them but organisations can start by limiting the data
they are storing. If the organisation isn’t storing it, it can’t be
leaked. When it comes to developing APIs, businesses need to make
security the number one priority and ensure that they’re combining API
gateways with OAuth 2.0 to strengthen API security.