5 myths of API security

It’s been a busy week for breaches. On Monday, Krebs on Security revealed that over an eight-month period, Panera Bread ignored the leak of more than 37 million customers’ data. Then Wednesday night, news broke of a September breach at customer interface provider [24]7.ai. Its full extent is still unknown, but as of this writing, [24]7 customer Delta Airlines says “several hundred thousand customers” may have been exposed, and fellow client Sears Holdings says under 100,000 customer credit card numbers were accessed.

In an official statement, Delta explains the [24]7.ai leak came from malware in the program, but at Panera, an unauthenticated API endpoint was to blame. Panera learned about the breach on August 2, 2017, but the company seems to have ignored it.

For those who are looking to prioritize API security — or to learn more about it — we’d like to share this list of the top 5 API security myths. What’s the real story on API vulnerability?

Myth #1: API security is a feature, not a technology

According to Jason Macy, chief technology officer at API security management provider Forum Systems, “Many vendors in the API product landscape talk about having features of API security.” In reality, he says, “claiming to have features that provide aspects of API security” is just like “claiming to have features that provide firewall or antivirus security.”

Protection comes from products — not features, he claims: “Just as you wouldn’t trust your applications to provide real firewall or malware protection, you shouldn’t expect your API management platforms to provide real API security protection.”

Keith Casey, co-author of A Practical Approach to API Design (Leanpub, 2016), says API security is a process mindset. Casey works as solver of API problems at authentication provider Okta — yes, that’s his real title — and points to the five pillars of API management: lifecycle, interface, access, consumption, and business.

The five pillars, he explains, are “how we look at the world. Any good API management platform is going to cover all five aspects (and probably others).” Security software will “only cover that center pillar”: Access.

While Casey says a security-specific tool like that from Forum Systems can be “complementary to everything else,” that doesn’t mean protection can’t come from tools that address full lifecycle management.

Keith Casey

Myth #2: Software-based API security solutions are secure

If you think this isn’t a myth, Macy asks, “How many vulnerabilities does it take to convince otherwise?” Granted, we’re still learning more about what happened at Panera, but for more proven examples, Macy points to Spectre, Meltdown, ShellShock, and Heartbleed. Spectre and Meltdown, he explains, “allow third-party code running on your security system to compromise the system. However, API security solutions based on security products have locked-down operating systems, which do not allow third-party code,  and thus are not — and never have been — susceptible to vulnerabilities.”

Myth #3: API security is simple 

The concept of an API in of itself is simple: Really, an application program interface just connects two programs. That doesn’t mean securing one is. “APIs represent an evolution of technologies that have led the way to cloud and mobile technologies and an ever-increasing complexity in interconnected systems,” Macy says. But “the simplicity of the connection,” he contends, is what creates complexity. He says the information coming across it is “where the actual threat vectors emerge. The simpler your API security solution approach is, the less secure you can expect it to be.”

Casey says Macy is right, in part, but he disagrees on why: “The problem isn’t just the ever-increasing complexity, but the fact that the boundaries have moved.” In security’s good old days, he explains, users “had to physically be on the network — or within the firewall.” By default, data was restricted to those inside.

“What APIs have done is create these places where we want to let people into our internal systems, data, or functionality to use in ways we describe,” Casey continues. The marriage of sharing data while protecting it is difficult by default. On top of that, he adds, “Since most people haven’t thought through ‘this is outside my firewall, now what?,’ we have new vulnerabilities and attacks hitting us.”

Myth #4: An API gateway provides the same protection as an API security gateway

Mike Cook is a governance, risk and compliance (GRC) specialist for cybersecurity nonprofit (ISC)². He says API security gateways “should be used more than they are…. APIs come in and can read all your data or they read the data from another application that you have.” Without one, he asks, “Can you make sure that that API, that other party, the information going out there is just the information they need and that they’re allowed to have? Or that…the company on the other end of the API is really that company?”

So why not get that security from a basic API gateway? Macy says, “If the API gateway product itself can be compromised, it does not matter what API security feature it touts. API gateways are not based on cybersecurity technology; they are based on integration platforms that run as software applications on insecure operating systems.” Because security gateways are expressly designed to protect you, they use secure policy storage and integrity assurances, Macy says, “to prevent the products themselves from being able to be compromised.”

Myth #5: API identity is separate from API security 

Macy says this myth comes from “years of divergent industry practice resulting from identity and access control being a separate practice from cybersecurity. Cybersecurity products are not built to support identity, and API identity products are not built to enforce security.” Best practice API security requires identity access and cybersecurity work together. “API security is dynamic and based on many criterion,” he explains, “The user and the user behavior are critical aspects of the decision and enforcement.”