Your APIs (application programming interfaces) are a tunnel to your data, and the bad guys know it. In fact, those APIs have become a rather tantalizing target.

“Treat APIs like they have a direct interface into your underlying systems and can bypass security controls – because that is pretty much what they do,” said Peter Liebert, former CISO, state of California and now CEO, Liebert Security.

“APIs are web apps without a browser,” explained Sumedh Thakar, president and chief product officer, Qualys. “Like web apps, APIs must be designed securely and tested for vulnerabilities.”

Whether it’s people, web apps, or APIs, security professionals know that all key attack vectors require a host of mitigations. I reached out to past guests of the CISO Series podcasts and a few other security professionals and asked them for their tips on securing APIs that many of us might be missing.

Thanks to our sponsor, Salt Security

Salt Security protects the APIs at the core of SaaS, web, and mobile applications. By using patented behavioral protection Salt Security automatically and continuously discovers and learns the granular behavior of each unique API and stops attacks. In 2020 Salt Security was named a Gartner Cool Vendor in API Strategy.

Editor’s note: This article is part of CISO Series’ “Topic Takeover” program. While the article sponsor, Salt Security, and our editors agreed on the topic of API security, all production and editorial is fully controlled by our editorial staff.

Join us Friday, June 19th, 2020 for “Hacking API Security” video chat

We’re doing a live video chat on Friday,
June 20th, 2020 at 10 AM Pacific/1 PM Eastern. Topic is “Hacking API Security: An hour of critical thinking on protecting the connective tissue of corporate data”.

These events are a ton of fun. But you only can find out if you REGISTER.

Got feedback? Join the conversation on LinkedIn.

1: K.I.S.S. (AKA “Keep It Simple Stupid”)

“The Protection of Information in Computer Systems” by Jerome Saltzer and Michael Schroeder lists eight design principles for securing information systems. Gary Hayslip (@ghayslip), CISO, Softbank Investment Advisers, notes the value of the third principle, “Economy of Mechanism.” It states that “design should be as simple as possible. All the component interfaces and the interactions between them should be simple enough to understand.”

“The more complex you make the security, the harder it is to understand and you will miss things,” said Hayslip. “When you are securing APIs there are plenty of best practices so don’t make it hard.”

And with that said, here are 24 more recommendations to secure your API. Only use what you need to maintain simplicity.

2: Get an inventory of your APIs… and update it

“In order to have an effective API security strategy, the first step is to inventory all your APIs,” said Roey Eliyahu, CEO, Salt Security.

Queue the advice you’ve heard many times before: “You can’t protect what you don’t know”.

“You’ll also need complete documentation from the host address level, to the endpoint level, and up to the parameter level,” continued Eliyahu who advised that this needs to be done repeatedly with any changes made to the API. “Once your attack surface is known, you’re in a better position to protect it.”

3: Authenticate your data structure – parameterize

“Use parameterization techniques to define the acceptable variable types upfront. Think of it like an IP whitelist, but for variables instead of IPs. If an attacker then throws an unexpected variable type or execution string at you, when you have parameters explicitly defined, it simply fails to execute,” said Joey Johnson, CISO, Premise Health. “So without yet knowing the new attack pattern coming at you, you’ve proactively prevented yourself from being vulnerable to it. This really dramatically reduces your threat exposure and landscape without inhibiting desired API functionality.”

4: Try to break your own API

“Perform some form of API security testing (e.g., fuzz testing or command injection) to make sure it actually is secure,” advised Tom Cornelius, senior partner, ComplianceForge.

Acting as a sort of automated red team, a fuzz test purposely submits random information to see if your code and security can hold up.

5: Don’t rely on your API gateway

“Don’t depend on your API gateway to solve your security problems. API gateways are great at managing scale but aren’t built with security use cases in mind,” said Will Lin (@williamlin), partner, ForgePoint Capital.

6: Yet use your API gateway as your enforcer

While cloud native API gateways have really immature security controls, they are still situated in such a way that makes them a great line of defense.

“Leverage what native API gateway security controls that exist and incorporate a defense in depth approach (where possible) to cover the interim gaps,” said Steve Zalewski, deputy CISO, Levi Strauss & Co.

The purpose, said Zalewski, is to simply set yourself up for developing gateway security controls so you don’t have to re-design your solution in 12-18 months.

7: Authenticate your API

“It may seem silly, but have you authenticated your API,” asked Leon Ravenna, CISO, KAR Global.

“API authentication remains simple, sometimes embedded in the computers they are configured to go to,” said Paul Calatayud (@paulcalatayud), CSO, Americas, Palo Alto Networks.

“[For that reason] API providers need to consider a stronger authentication system in order to validate the source of API because when an API key is compromised then your entire infrastructure and data is compromised,” added Francis Dinha (@francisdinha), CEO, OpenVPN.

Brandon Traffanstedt, global director, solutions engineering, CyberArk, suggested you “look for ways to allow entities calling APIs to authenticate based on attributes—things they are, not things that they know. This could be IAM (identity and access management) roles in AWS, native elements of container identity like namespace or stateful set, or even elements of the node that the API is being invoked from.”

8: Move beyond basic authentication

“Many still rely upon basic authentication for API endpoint access, which is essentially just a username and password,” said Mike D. Kail (@mdkail), CTO, Everest. “Instead, I highly recommend always implementing HMAC (hash-based message authentication code) authentication which uses cryptographically secure hashes to auth to an API endpoint. There are added benefits as this allows access to only a specific resource at the URI (universal resource indicator), and because it includes a timestamp, access is only granted for a reasonably short time window.”

9: Don’t manage identity within the API call

“When handling identity passing though APIs, especially in a container/cloud context, don’t manage the identity within the API call – manage it through proper session management,” said John Meakin, CISO, Equiniti. “It’s a pain and makes the code less modular and slightly less scalable but it’s worth it. Otherwise you end up being subject to attacks such as brute-force ID/credential insertion and or your IDs get easily exposed for abuse via another route.”

10: Don’t leave secrets in source code

“All too often people will include tokens, secrets, or credentials in source code. I’ve worked on numerous key hunts over the years, looking for places where developers left them in code. This is a recipe for disaster. It’s hard to know who’s seen these values, who has a copy, or if former employees still ‘remember’ them,” said Mike Wiacek, former CSO/co-founder of Chronicle. “Most often encryption isn’t broken because of flaws in an algorithm, but because keys were mismanaged. The same rule applies to API credentials. Come up with a consistent way, that’s also developer friendly, to safely store, protect, and audit access to these values, preferably using an HSM (hardware security module). “

11: Audit to see what the heck the bad guys are trying to do

“A dedicated attacker will try to reverse engineer the API build to determine what they can do. If you’re logging appropriately you have a better chance to correlate this activity. If they’re being sloppy and doing early recon and API fuzzing from a single IP, you could see through failed event logs how they’re trying to do different things to test how the API responds,” said Premise Health’s Johnson.

12: Validate open source APIs

“The ‘many eyes’ principle that excuses use of open source as potentially more secure than proprietary is a lie,” said Equiniti’s Meakin who has unfortunately seen this from experience. “You need to test, test, test (or scan, scan, scan) – your code and the community code.”

13: Aw heck, review all APIs for vulnerable code

It’s not just open source APIs that are vulnerable.

“ALL APIs should go through a code review to ensure that the developers didn’t recycle known vulnerable code into the API,” said Nick Espinosa (@NickAEsp), chief security fanatic, Security Fanatics. “I can’t tell you how many times we’ve reviewed developed software for clients and their dev team used, for example, a menu framework from about a decade ago that has more holes in it than swiss cheese. They just copy/paste from their own personal library not realizing the creator of the original code has either updated that code multiple times over the years to harden it or simply abandoned it and therefore they should too.”

14: Validate your API against a schema

“Your schema is basically the LEGO diagram for how your API should look,” explained Kelly Shortridge (@swagitda_), vp, product management and product strategy, Capsule8. “Download a library in the language of your choice and describe your schema as an object, then perform validation on it.”

15: Who has access and rights to my API?

“API security is all about access control and privilege level. An API being accessible is not inherently bad,” said Brendan O’Connor, CEO, AppOmni.

What’s bad is when you can’t answer questions to its behavior around access and data.

“Once you’ve mapped an API and understand its attack surface, regularly scan and monitor that API to validate it’s only exposing what you intend,” continued O’Connor. “Back end changes to configuration or privilege level can turn a safe API into a major exposure.”

16: Newer doesn’t mean more secure

“There is a temptation to assume recent API technologies, [such as GraphQL,] will handle security better via more fine grained permissions, a consolidated view of data, or just cleaner abstractions,” said Ben Walther, principal security engineer, Atlassian, who argued that is simply not the case. “It’s not just ‘same due diligence’ but ‘update your entire approach from first principles.’”

“Security teams must evaluate their readiness to secure this new technology stack (GraphQL),” said Ahsan Mir (@ahsanmir), CEO, Rapticore.

What was not a problem before with an older technology, all of a sudden becomes a problem with a newer technology. For example, nested mutations with GraphQL, which has bit Walther multiple times, wasn’t even a possible issue with REST. 

17: Keep hounding vendors to improve their APIs

“Just placing a load balancer, web application firewall, or API security appliance on top of code with issues doesn’t resolve the issues,” said Mitch Parker (@mitchparkerciso), CISO, Indiana University Health. “Make sure that vendors address root causes of vulnerabilities.”

18: Privileged machine access management

“Even though machines/robots/scripts/processes are the main consumers of APIs, they should be secured just like they were people,” said CyberArk’s Traffanstedt, who advised the same principals of least privilege placed on humans in a PAM (privileged access management) environment should be applied to machines as well.

19: Think creatively about “least privilege”

There’s more to least privilege than applying basic PAM principles.

“In the context of an API, least privilege means three things: access within the API, access to the API, and access to an API key,” said April C. Wright (@aprilwright), security consultant, ArchitectSecurity.org.

Wright offers up a host of alternative least privilege solutions such as having a separate API key for each client accessing, a different key for the different levels of access, or different applications, whitelisting IP addresses, or even a separate API by function, such as an API for web, one for mobile, and one for administrative tasks.  

“Implementing API security in this way does create increasing complexity,” said Wright. “It’s important to balance function and security.”

20: Red team the S@&T out of your API

“Use your threat models to identify API endpoints that might disclose sensitive information,” said Will Gregorian (@willgregorian), CISO, Addepar.

“Then, bring in a red team and let them have at it,” said Yaron Levi (@0xL3v1), CISO, Blue Cross Blue Shield of Kansas City.

A common vulnerability in API development is password reuse. Once a supposedly strong password is reused it can have a domino-like effect.

“Many APIs are using service accounts and often these service accounts are shared or their password never expires. So if one API is compromised others are likely exposed as well,” said Levi.

21: What’s the API owner going to do with my data?

“When we start ramping up APIs we usually dedicate our security mindset to authentication, authorization, rate limiting, validation, and encryption. But we overlook the most basic asset – our data,” said Yaniv Bar-Dayan, co-founder and CEO, Vulcan Cyber. “Specific calls hold specific datasets which are great for internal processes, but are not so great for external consumers.”

“You need an architecture diagram with data flow and a clear understanding of what data is being transmitted or exchanged,” said Nina Wyatt, svp, CISO, Sunflower Bank. “Without a clear understanding of all of those things – you cannot be sure that the security controls applied are sufficient and sustainable.”

22: Get yourself API sensitive talent

“You have to attract and retain talent that comprehends the value of network and data flow mapping to a degree that will enable your team to understand the API, thus enabling them to secure it appropriately by design,” said Sunflower Bank’s Wyatt.

23: Limit API usage

“Many don’t have traffic or bandwidth limits enforced for their APIs. This leaves them open to DDoS (distributed denial of service), brute force attacks, and more,” said Security Fanatics’ Espinosa.

Kip Boyle (@kipboyle), founder and CEO, Cyber Risk Opportunities advised using rate limiting by API key and IP address to reduce opportunity for API abuse.

“Just because your bandwidth could handle one thousand users doesn’t mean that level of bandwidth should be available,” said Espinosa. “Every API in use should be put through a calculation process to understand just how much bandwidth and session traffic is required to sustain its estimated user base and then give it that bandwidth, or slightly more, to help offset these kinds of attacks which also helps identify attacks more quickly.” 

24: Monitor for suspicious activity

“The other thing I see organizations miss is continuous monitoring and alerting for suspicious activity that might be affecting the API,” said Security Fanatics’ Espinosa. “A lot of people don’t realize that many next generation firewalls out there don’t inspect SSL/TLS traffic and are blind to the secure traffic that your users and applications are generating. Also many organizations are not applying security analysis tools that utilize machine or deep learning AI to constantly inspect the behavior of the API. Many types of bot attacks can therefore fly under the radar, even if you’re bandwidth limiting.”

25: Reduce attack vector with serverless architecture

“Traditionally, APIs have been built on top of one or more web servers that live for a long time (sometimes weeks, months, or even years). The risk with this approach is that it makes it easier for an attacker to get into your network and explore,” said Alen Puzic, CTO, SpyCloud.

A serverless architecture has a temporary lifespan that increases and decreases to meet demand. If you deploy APIs across a serverless architecture, advised Puzic, you can avoid long-lived resources and reduce your attack vector. Plus, if an attacker does manage to get into your network, their time window of effectiveness has dramatically shrunk.

CONCLUSION: The API vulnerability problem is persistent

“These things (API vulnerabilities) are like bed bugs in a shady motel without a cleaning crew. They will always be there and they will always come back once they are smoked out,” warned Sunflower Bank’s Wyatt. “A forceful and continued reckoning is necessary to keep the risk at an acceptable level.”

Hope is not lost and this is where security professionals need to lean on artificial intelligence and self-remediation. Security Fanatics’ Espinosa looks to solutions now and in the future that let AI monitor APIs. When it detects an issue, in the code or as an external threat, it would be intelligent enough to fix or mitigate.

The volume of API issues is so overwhelming. The options to secure them are also apparently endless. Even if you implemented the last 24 of these tips, you would probably run afoul of the first tip, K.I.S.S. Security APIs is not easy. Find your balance, and look for ways that security implementations can greatly reduce your attack vector.

Don’t forget to join us Friday, June 19th, 2020 for “Hacking API Security” video chat

We’re doing a live video chat on Friday,
June 20th, 2020 at 10 AM Pacific/1 PM Eastern. Topic is “Hacking API Security: An hour of critical thinking on protecting the connective tissue of corporate data”.

These events are a ton of fun. But you only can find out if you REGISTER.

Creative Commons photo attributions to Hey Paul Studios, Pablo Viojo, Dave Gingrich, and Chad Elliott.