# API Security Is the New Black
Source URL:     https://www.darkreading.com/dr-tech/api-security-is-the-new-black
Date:           20221230T1700

There are a few reasons that the topic of API security has been popping
up more and more as 2022 comes to a close.

Back in July 2021, Gartner predicted that by 2022, application
programming interface (API) attacks would become the most frequent
attack vector, causing data breaches for enterprise Web applications.

Was the analyst firm right? It's too early to know for sure since [OWASP
is still tallying the results][1].

API attacks are back in the news. It turns out the likely ingress point
for the [Optus breach][2] was a lowly REST API. And someone has leaked
all of the data stolen from the [Twitter breach][3] — which also
involved an API.

When we talk about [API security][4], we're referring to the measures
and practices that we use to secure APIs and the data they transmit. We
might be worried about unauthorized access, an adverse reaction to a
distributed denial-of-service (DDoS) — more than one API has fallen
over and left the underlying system wide open and completely insecure
— or other malicious attacks.

There's an art to securing APIs; a light touch and a delicate
combination of technical and organizational skills are required to do it
right.

On the technical side, we’re looking at measures such as
authentication and authorization, encryption, automated testing, and
monitoring. On the organizational side, you need to know exactly who on
the org chart the API was designed to serve, and tailor access
accordingly. For external APIs, you need to know how much data should be
available to the outside world and how that data needs to be curated and
presented.

## How Are APIs Protected?

There's a sane order of operations when you're trying to secure your
company's APIs.

First, find and catalog every API. The number of companies that actually
do this and keep their API inventory up to date is small indeed.
Developer convenience, rapid website development, and the increasing
push toward federated services all contribute to mystery APIs popping up
out of the blue without any kind of compulsory registration structure in
place.

To avoid this kind of API creep, every single one of them should be
registered centrally with the following information:

 * Name
 * Tools and packages used to build the API
 * Servers that it runs on
 * Services that rely on that API
 * Documentation of all valid uses and error codes
 * Typical performance metrics
 * Expected uptime or downtime windows

All of this information goes into a repository run by the cybersecurity
team.

Second, set up security and performance automation for every API. This
is why you asked for all of that information, and this is how you keep
everything secure. Using the data provided by the developers (and DevOps
team, the Web team, etc.), the cybersecurity and/or testing team can put
together automation that tests the API regularly.

Functional tests are important because they make sure that everything is
working as expected. Nonfunctional tests are important because they
probe the reliability and security of the API. Remember that APIs must
fail securely. It isn't enough to know that one has fallen over — you
need to know the consequences of that failure.

Finally, add the API to the normal threat prevention suite. If any of
the tools or packages used to build the API are found to be buggy, you
need to know. If any of the protocols that it uses are deemed insecure
when you do detect trouble, you need to have the team shut the APIs down
until they can be examined and rebuilt.

Taking these actions once is great; creating a programming and security
culture that allows you to maintain fully cataloged and documented APIs
is the long-term goal.

## Specific API Behaviors to Note

When pen testing and securing an API, some techniques are more useful
than others.

 1.  **Start with behavioral analysis.** This tests whether reality matches the documentation in terms of the level of access granted, the protocols and ports used, the results of successful and unsuccessful queries, and what happens to the system as a whole when the API itself stops functioning.
 2.  **Next is service levels.** This involves the priority of the process itself on the server, rate limiting for transactional APIs, minimum and maximum request latency settings, and availability windows. Some of these details are important for DDoS prevention (or blunting). Others are useful to monitor whether there are any slow memory leaks or garbage collection issues that might be a long-term threat to the integrity of the server itself.
 3.  **Authentication and sanitation issues** speak directly to the level of trust you have for the API's users. As you would with any service, queries need to be sanitized before they're accepted. This prevents code injection, buffer overflows, and the like.

There needs to be some level of authentication with APIs that are
designed for a specific user base. However, this can get complex.
Federation is one issue that you need to deal with, determining which
central identification and authentication servers you'll accept. You
might want to have two-factor authentication for particularly sensitive
or powerful APIs. And, of course, authentication itself isn't
necessarily a password these days; biometrics is a valid way to wall off
an API. To make a long story short: Apply the standards that you find
reasonable and test the limitations that you've set on a regular basis.

Finally, encryption and digital signatures need to be part of the
conversation. If it's on the Web, then we're talking about TLS at
minimum. (Repeat the mantra: We don't REST without TLS!) Other
interfaces also need encryption, so pick your protocols wisely. Remember
that static information, be it a database or a pool of files somewhere,
also needs to be encrypted. No flat text files anywhere, no matter how
"innocent"; salt and hash should be the standard. And checksums are a
must when providing or receiving files that are known entities (size,
contents, etc.).

Finally, key management can be difficult to get right. Don't expect
every DevOps person to have perfect digital key implementation when a
decent portion of the cybersecurity folks are half-assing it themselves.
When in doubt, [go back to the OWASP Cheat Sheet][5]! That's what it's
there for.

## Responding to an API Attack

The cardinal rule is: If your API is going to fail, pinch off access.
Under no circumstance should services fail in an open or accessible
state. Remember to rate-limit and keep error messages short and generic.
Don't worry about honey pots or API jails — worry about survival.

Custom-crafted API attacks on an individual basis need to be treated
like any other breach attempt. Whether you caught the attempt yourself
or via AI/ML analysis, follow your SOP. Don't cut corners because it's
"just" an API.

API security separates the mediocre CISO who focuses solely on
infrastructure from the masterful CISO who addresses actual business
threats and ensures survivability. Create a system for API security,
create reusable interface testing automation, and keep your API
inventory up to date.

  [1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/
  [2]: https://www.darkreading.com/attacks-breaches/fbi-helping-australian-authorities-investigate-massive-optus-data-breach-reports
  [3]: https://venturebeat.com/security/twitter-breach-api-attack/
  [4]: https://www.darkreading.com/application-security/expect-api-breaches-to-accelerate
  [5]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html

You are viewing proxied material from tilde.team. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.