By Ross Moore

Those who have worked with security policies have experienced one or both of the following frustrations: creating policies from scratch takes a lot of work, and reworking outdated policies takes a lot of work. One might think either one is easier, but it's not. The former takes intense wordsmithing to design proper documentation, and the latter requires scrutiny to ensure the concepts are updated and match actual practice.

Working with APIs is much the same: whether building new APIs or updating existing ones, it takes a great deal of effort.

Whatever the case, here are 5 recommendations to keep API secure and compliant.

Inventory your APIs

Zombie, Rogue, Shadow. Not only are these the creatures of our nightmares, they're also types of APIs - specifically the kinds we don't know about or have gotten out of date. You want to know about all your APIs! You need this info across both public-facing and internal APIs.

The adage, 'You can't protect what you can't see" applies. API sprawl happens quickly, making it necessary to catalog APIs, update those with security gaps, and decommission outdated ones.

Flashback to the 2014 Marriott Hotel data breach. Marriott had, at the time, recently acquired Starwood. Starwood had insecure technology and was already breached at the time of acquisition. We don't know exactly what caused it. Perhaps a faulty API? Phishing? Both? The fact remains that Marriott was held responsible for not vetting Starwood's security posture and being aware of the risks before acquisition. Knowing one's inventory is always the responsibility of the company acquiring and providing the service.

Inspect the attack surface

Once an inventory system is in place, an API security checklist is a good resource to continue with examining how to protect APIs. Clearing up an inventory is also necessary so that no resources are wasted in securing assets that should be removed.

BrewDog released an app version in early 2020 that contained hard-coded bearer tokens. This vulnerability remained for perhaps up to 18 months before it was discovered by security researchers.

This finding by the security consultants is an example of the first two vulnerabilities on the OWASP API Top 10 list - Broken Object Level Authorization and Broken User Authentication. A hard-coded token invalidates or bypasses authentication, and a lack of adequate randomness in the customer IDs gives too much leeway for attackers to figure out customer information.

BrewDog is both a good and a bad example. The API was known (good), but it was untested for a long time (bad). It was eventually discovered, and no evidence of malfeasance was present (good) but was unknown for long enough that one never knows if someone else found it first (bad).

A typical expectation in security and compliance is to have a penetration test performed after a major change (e.g., platform or infrastructure change). With the low barrier to entry in API development, creating and deploying APIs is easy. Knowing what to test and when is another, and more important, matter.

Identify the regulations

As regulations across the world increase in both number and scope, the need to secure APIs increases. While APIs are not yet always called out in a regulation, what is called out is the need to secure the channels over which PII is transferred. If a company's API in any way transfers PII (and that could be as simple as a person's first and last name, depending on the regulation, internal policies, or contract), then that transmission channel needs to be secured. An example of ensuring API compliance for Twilio APIs is following Twilio Bundles REST API documentation for evaluating regulatory guidelines.

In 2019, Facebook received a fine of $5 billion because Cambridge Analytica abused a Facebook API to collect millions of users' sensitive data. While CA abused the API, Facebook was fined because it demonstrated negligence by failing to monitor the application used. Companies need to approach APIs with an end-to-end perspective, including the legal factor called calculus of negligence, or the Hand rule.

Work with other stakeholders and business units, such as Compliance and Design (who may be considered irrelevant to API architecture), to set proper Targets, Tasks, and Metrics that will align with more than just customer and market desires. The sum of the costs of creating the app and the income generated can be dwarfed by the costs of a breach or regulatory fine.

Innovate the product

Balance risk aversion with innovation. Providing services is not an either/or game - either provide award-winning service or secure it. It's a both/and contest, and that contest involves ensuring that customers both have a positive experience and can rest assured that the company is protecting their identities and data. Innovation can go beyond just what customers see. Seek to impress the security and compliance departments of your customers!

Companies should consider if their approach to pushing the newest features to market in rapid fashion is worth more or less than taking what I call a craftsmanship approach to producing a release candidate that combines fewer features with fewer risks and break-fixes.

Take that step of customer-centricity. Customer-centric thinking focuses on the customer experience with using your service. While this is often viewed as just the UX and design, more customers want privacy and security included. This outside-in strategy of including privacy and security in the usefulness and beauty of a service creates extra complexity for a company, but it's necessary.

Improve the process

What's the next step in making your API implementations and architecture better? You've got options.  Consider deploying API fuzzing tools. Look at inserting SAST/DAST/IAST into your CI/CD pipeline. Perhaps your team needs to learn all of the risk factors in the OWASP API Top 10 list. Every company is different, so there's no one-size-fits-all. But creating a plan to improve API security is the next step. What improvement will you make?

##

ABOUT THE AUTHOR

Ross Moore is the Cyber Security Support Analyst with Passageways. He was Co-lead on SOC 2 Type 1 implementation and Lead on SOC 2 Type 2 implementation, facilitated the company's BCP/DR TTX, and is a HIPAA Security Officer. Over the course of his 20 year IT career, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds (ISC)2's SSCP and CompTIA's Security + certifications, a B.S. in Cyber Security and Information Assurance from WGU, and a B.A. in Bible/Counseling from Johnson University.