thebiginterview
amounts of API traffic so that the tooling has the context needed to detect API attacks. Tese 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. Tese 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. Te 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. Tere’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 oſten than any other attribute. Tis 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.
www.pcr-online.biz
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. Tey 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.
April 2022 | 25
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52
