API Security and Cloud: What you Need to Know

The internet is much like a shopping mall—intended to be open. And because it is designed to be open to the public, there’s little to stop anyone from entering. Security guards and law enforcement are present, but even several officers in 800,000 sqare feet spanning multiple floors are insufficient to protect everyone and everything. Each shop is responsible for maintaining its own security.

The cloud, too, has a bewildering array of “shops” to protect and a dizzying number of criminals trying to find a way in. All the while, the general public is focused on enjoying their time out.

Web applications have similar pros and cons—open to all and a consistent target. And to add to the collection of open targets, we have APIs. Like web apps and all the other endpoints out there, APIs can’t protect the data on their own—they must be protected by layers of security. Unlike web apps, API technology has become so prevalent that it has its own category for protection (more on that later). The days of protecting APIs like web apps are effectively over.

How frequently are APIs targeted? A recent study from Salt Security indicated that API attacks rose 681% in the past 12 months compared to a 321% increase in overall API traffic.

Design With Security in Mind

Getting a new service to market naturally drives business—and business exists to provide solutions. Whether a service is online or physical, some people want to break, disrupt, steal or otherwise cause serious damage to those services. It seems all too obvious, but the dangers need to be amplified due to the constant volley of cyberattacks (as a coworker of mine said, “It’s telling that there’s a website called Data Breach Today!”).

Designing for UI, UX and aesthetics is necessary for visitors to want to return to a website. Designing for security is also necessary for long-term customer retention because it builds trust.

Any security checklist must be tailored to the unique needs of a business, but there are numerous resources available for getting started. Many thanks to all those who work hard to provide these items free of charge so that everyone can benefit.

Incident Response

 “When it comes to dealing with [API] attacks, 34% have no [API security] strategy in place and 27% have just a basic strategy,” according to the Salt Security report. For any business that is regulated or has undergone a third-party assessment for its ISMS (e.g., ISO 27001), one of the primary strategies to implement is an incident response plan. This is not to say that one must be regulated or immediately launch into an audit. Rather, this underscores the importance of incident response. Having a formalized plan that works for one’s business should be considered a cornerstone of one’s plans and procedures.

APIs will be attacked. Other aspects of an API security strategy should focus on preventing and mitigating attacks, but an incident response plan is necessary to prepare for the time when an attack materializes. The attack doesn’t have to be a business-crippling or data-stealing attack to warrant a response.

Detect and Deny

As API use has increased, securing them has necessitated a new protection strategy. In other words, APIs can no longer be protected using the same technologies used to secure web applications. The technologies are different enough to warrant different solutions.

Just as OWASP introduced an API-specific list of top 10 threats complementing its long-standing application threats top 10 list, Gartner has similarly highlighted the need for dedicated API security tooling. Rather than leave API security buried within the web application firewall (WAF) bucket, an updated security reference architecture created a separate and distinct pillar for API security.

Put in ample research to determine the proper tools for your API security needs. As API technology advances and the number of vendors increases, confusion invariably occurs. Any product category, as it gets more crowded, will require more research to separate out the capabilities—customer success stories and technical demos can be a great way to dig into the differences. Be sure to include time and incentive for teams to research properly, including evaluating different platforms.

Testing

“No scanner is adept at parsing business logic, which also leaves organizations exposed to major forms of API abuse,” Salt Security’s API security checklist warned. Use SMEs to examine the code as part of the pipeline, look into code dependencies and fuzz for exploitable code. Security vulnerabilities will vary depending on what your API is doing, who the users are, what things are going to get accessed, etc. While there are a lot of tools that warn about security vulnerabilities, authorization is much more difficult. And remember that static code analysis will get you only so far—you’ll need to see APIs exercised with live traffic to find the business logic flaws that really make APIs vulnerable to exploits.

Inventory

With a world full of automatic updates, hotfixes and zero-day vulnerabilities, you can no longer update internet-facing solutions (and thus, APIs) every now and then. Whatever inventory solution one chooses, the preferred options will, at minimum, provide automated ways of discovery and cataloging. Maintaining a current inventory is vital to proper API and security governance.

Planning

According to the Salt Security report, “A common API issue is future planning, scope changes over time and companies using APIs for different use cases—without considering security implications.“

Ensure developers follow the API documentation. When creating internal APIs, documentation needs to be created, which can be done with tools such as Postman and OpenAPI/Swagger. When using public or partner APIs, stay on top of any changes. Planning involves more than just design and architecture; it involves how often a team needs to review, revisit, update and upgrade. A new project is always exciting, but a few months down the road when the excitement has worn off, having preplanned projects and tasks for performing maintenance functions will prevent what could be disastrous emergency rework. Some popular, even beautiful, existing documentation of well-known APIs include Twilio and Stripe. Even if your API documentation isn’t a work of art, it still needs to exist, be updated and followed.

Runtime Protection

While runtime protection can be considered a component of the testing phase, it’s important enough to call out on its own. Third-party testing, fuzzing and other static analyses are important, but runtime protection enables a business to more properly secure APIs while they’re in action, which is when security truly comes into play. Testing continuously when the API is being used will detect and protect from activities such as credential stuffing and DDoS.

Considerations

APIs are an indispensable part of a business today; they drive innovation by connecting vital data and services and by streamlining developer efforts. Their low barrier to entry can be misleading and make them appear easy to use and maintain. Using the suggestions above and soliciting help from a trusted advisor when needed, proper API use can bolster business, mitigate security risks and prepare your business for the future of the digital economy.