API Attacks on the increase but what does this mean for SME’s?

According to a report conducted by Salt Security, API Attacks increased 681% in the last 12 Months. Key findings from the report show API attack traffic grew at more than twice the rate of non-malicious traffic, and API security concerns are inhibiting innovation for two-thirds of organisations. We speak to Michelle McLean, lead author of the report and VP of product marketing at Salt Security to find out more.

Salt Security’s recently released State of API Security Report Q1 2022 found that 95% of surveyed organisations have experienced an API security incident in the past 12 months. Despite the dramatic increase in attacks and incidents, these organisations, all of which are running production APIs, remain unprepared for API attacks, with 34% of respondents lacking any kind of API security strategy. This lack of defence presents significant business risk to enterprises in the form of slowed business innovation, compromised consumer confidence, and disruption to modernisation efforts.

What is the current state of the security market in the channel?
Security is a persistently effective industry area for channel providers to focus their energies. First, security is always a pressing concern for corporations. From risk of financial loss to reputational harm to compliance violations, companies face a growing list of security issues to defend against. Second, the ongoing pandemic has only heightened the needs. Every company has gone through drastic changes in how and where people get work done, and many of these changes will persist even when COVID becomes an everyday annoyance vs. a grave immediate threat. Third, every wave of technical innovation – e.g., cloud migration, new application development technologies, adoption of cloud-native architectures, and so on – disrupts existing security technologies and requires new protections. Consider the move to containers and Kubernetes – suddenly companies were grappling with a broad set of new security concerns with misconfigurations in the infrastructure of those technologies. Similarly, the increased use of APIs has upended application threat vectors, creating an urgent need for new protections.

Can you tell us more about the key findings of the company’s recent API Security Report?
The most disturbing finding in the edition of the report was the level at which malicious API traffic growth outpaced the rise in overall API traffic. Malicious traffic grew 681% in the past 12 months, while overall traffic grew 321%. Bad actors target APIs because APIs consistently share valuable data and because, frankly, they’re not that hard to compromise. Other key findings include:

95% of the more than 250 survey respondents said they’ve experienced an API security incident in the past 12 months. 34% lack any security strategy at all for APIs. 40% of respondents are grappling with APIs that change at least every week, with 9% saying their APIs change daily.

Where, what and whom have recent cyber attackers been targeting?
Companies of all sizes and industries are targets for cyber attackers. Just within the arena of publicised API attacks in the past year, we’ve seen: the Microsoft Exchange Server attack, coordinated by Hafnium, a Chinese state-sponsored hacking group to gain access to environments and data.

There was the Experian hack, in which an independent security researcher was able to garner extensive personal data, including credit scores, in a manipulated API response.

The John Deere incident, in which a whitehat hacker was able to fraudulently push device updates affecting farming automation and GPS auto-steer.

The Peloton incident, in which a security researcher was able to use a Peloton API to pull back customer PII including user IDs, location, weight, gender, age, and more.

Two cases of LinkedIn data scraping, including information on roughly 500 million individuals at first that eventually ballooned to 700 million.

The globally disrupting “Log4Shell” or “LogJam” vulnerability; It was discovered to impact services across Amazon.com, Apple iCloud, Cloudflare, Twitter, and many other victim organisations, with bad actors able to manipulate log files to insert malicious code.

How can companies look to develop a robust API security strategy?
Companies can take a number of steps to improve their API security strategy. One early step is to teach developers about API attacks. Our survey found that only 61% of organisations are using the OWASP API Top 10 list as a focus area for their security programs. Explaining to developers how these attacks happen can help them harden APIs against these exploits. Second, we need to take the inverse approach and teach security teams about API incidents. We’ve seen SecOps teams that are reluctant to admit they don’t know what they’re looking at when they’re trying to parse an API security incident. Having developers explain how APIs are written, what the call and response pairs look like, and how attack patterns differ from normal traffic would help these teams respond faster and more effectively to attacks. ” vs. “attack” traffic looks like. And ultimately, as with other new waves of infrastructure build out and application development, organisations need to adopt security tooling dedicated to API security. Existing technology, such as API gateways and WAFs, continue to serve a purpose, but you need big-data based context with ML and AI to spot the reconnaissance activities of an API hacker.

Why do APIs present an attractive attack vector?
APIs are attractive to bad actors for two main reasons. First, APIs are specifically designed to share valuable data and services, so bad actors understand their efforts in finding an API vulnerability will likely be well rewarded. Second, API vulnerabilities are not that hard to find. We routinely work with our prospects while they’re evaluating our software. We ask their permission to hack their APIs to see what vulnerabilities we might uncover. About 80% of the time, we’re able to find a significant vulnerability, one that could easily result in account manipulation or data stealing, within just a couple days of researching their APIs. Because the companies’ existing security tooling isn’t built to detect API attacks, our efforts always get past their protections, and we’re able to share our findings in days.

How are attackers targeting API security? What methods are they using to gain control or breach security measures?
With API attacks, the point of the attack is rarely to gain control of a system. These attacks are usually designed to enable a bad actor to pull out valuable data and/or gain access to accounts that are not theirs. Attackers first use public documentation, Git repositories, and mobile app inspection, among other tools, to build their understanding of the landscape of APIs available for a given company. Next, they use public, intercepting proxy and debugging tools to understand the APIs themselves – they can use these tools to manipulate API calls to see what happens when they change certain parameters such as the user authorisation level or a User or Account ID. They watch how the API responds to different manipulations to look for gaps in business logic that they can exploit. Ultimately, they turn to automation to run these attacks at scale, being careful to stay under the radar in terms of traffic volume and not trigger traditional security tools.

What other concerns did the report uncover in regards to API programmes?
Security continues to top the list of concerns that respondents have in their API programs. Nearly half of the respondents, when offered 6 different areas to consider cited security as the biggest gap in their current API strategy. Almost a quarter, 22%, noted that their API programmes did not invest enough in pre-production security. And another 18% highlighted that their programs did not adequately address runtime or production security. Concerns about not fleshing out requirements or documentation also ranked high, with 19% of respondents citing that gap as their top concern. A second interesting area within the report is the recognition that shift-left tactics are falling short. Shift left refers to the desire to solve more security problems during development vs. runtime. However, with more than 50% of respondents saying developers, DevOps, or DevSecOps teams are responsible for API security, it’s very telling that 85% of these respondents say their existing tools are not very effective in stopping API attacks.

Can you tell us more about the concern with many enterprises unprepared for an API attacks?
Awareness about the challenges of API security runs high in this report. Nearly everyone (95%) in the study had experienced an API security incident in the past year, and security topped the list of concerns about API strategies. However, when asked to evaluate the robustness of their API security strategies, respondents revealed very low preparedness. More than a third (34%) have no API security strategy in place at all. Another 27% characterised their strategy is just “basic,” with some risk assessment and manual reviews in place. Another 29% described their security plans as “Intermediate,” with some app sec testing and gateways in place. Only 11% had dedicated API testing and protection in place. When you consider that every API incident we’re reading about is happening to companies with strong appsec teams, it’s clear that new levels of protection are needed.

Can you tell us how companies can look to implement effective API security protections?
Companies need to develop API security that covers the entire API lifecycle. Companies need to adopt testing, scanning, and fuzzing during the development phase. They should also look to API-focused security platforms with the ability to launch API attacks in test environments, so they can check for business logic gaps as well as coding vulnerabilities. Next, they need to apply runtime protections. These security measures include the need to capture significant amounts of API traffic so that the tooling has the context needed to detect API attacks. These attacks unfold over days, weeks, and even months, so companies need cloud-scale big data – not simply big data you can store within a company’s own environment, on a VM for example – to have the scope sufficient for seeing API attacks. Finally, they need to apply AI and ML to discern attack traffic from normal traffic and controls from inline devices to block attackers.

Can you explain more about why WAFs and API Gateways continue to miss API attacks?
WAFs and API gateways are not designed to correlate traffic over time, so they cannot identify the subtle probing of an attacker performing reconnaissance on a company’s APIs. These devices look at API traffic one transaction at a time, compare the traffic to rules that block known attacks, and then allow or deny the transaction based on that ruleset. API attacks do not follow any known pattern. The bad actors must learn the unique properties of each company’s APIs and then must propagate unique attacks in an effort to exploit business logic gaps in those APIs. There’s no amount of advancement or additional features a WAF or gateway can have that will get over this architectural limitation of seeing transactions one at a time – dedicated API security tooling is essential to defending APIs.

Can you tell us more about how stopping API attacks remains top criterion for an API security platform?
For the past three reports in a row, we have asked respondents to rate which features are critical to them in an API security platform. We ask them to rank seven different capabilities on a scale of 1 to 5, with 5 being highly important. For the third year in a row, respondents cited the ability to stop attacks as highly important more often than any other attribute. This finding makes sense, considering that the greatest risk comes from runtime attacks, which could successfully result in data exfiltration or account takeover. When you combine the figures for rating a capability as a 4 or 5, then the ability to identify which APIs expose PII or sensitive data takes top billing.

Can you tell us more about the risk of “zombie” or outdated APIs and how this has topped the list of API security concerns?
We also ask our respondents to rate their concerns about a variety of API risks, including unknown APIs, accidental exposure of sensitive data, and outdated or “zombie” APIs. Once again, the results are consistent across all three times we have run this survey. Nearly half (43%) of respondents cite concerns over zombie APIs as their top worry. Interestingly, the next biggest worry – account takeover – comes in as the top concern for just 22% of respondents, about half the number most worried about zombie APIs. Every other risk comes in at between 5% and 11% of respondents.

How is API security improving how security teams work?
Despite the lack of preparedness among the organisations in this survey, we do take heart from the discussion around the impact that API security is having on how security teams operate. More than a third of respondents (34%) noted that their security teams are collaborating more with DevOps teams, and another 30% say DevOps is asking for the Security team’s input on API guidelines. We also find it encouraging that security engineers are getting embedded with DevOps teams at 25% of organisations. Perhaps most promising is the fact that only 2% of the more than 250 respondents said API security was not changing how Security teams operate.

What role does education and staff training have to play in regards to API Security and how is Salt Security helping to provide training through its API Security Summit?
On the heels of asking respondents to discuss the sophistication of their API security strategy, we also ask what’s getting in the way of building out a robust plan. Nearly a quarter of respondents (22%) cite expertise as their biggest obstacle, followed by another 20% who say budget constraints are the most limiting factor. Time and resources/people tie for third, at 13% each. Salt puts significant effort into educating the industry on API security, API attacks, and strategies for defending against those attacks. Our Salt Labs blogs detail API vulnerabilities discovered in public and private incidents. They share what happened in the incident as well as the real or potential impact of the vulnerability, depending on whether a bad actor propagated an attack or a researcher discovered the vulnerability first. Most importantly they also share how to mitigate the attack. Salt also hosts events like our recent API Security Summit where whitehat hackers and CISOs share their learnings from building their own defences as well as a game plan other organisations can use to build their own API security strategy.

Read the latest edition of PCR’s monthly magazine here:

Like this content? Sign up for the free PCR Daily Digest email service to get the latest tech news straight to your inbox. You can also follow PCR on Twitter and Facebook.