thebiginterview
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 soſtware. 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. Tese 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. Tey 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
24 | April 2022
www.pcr-online.biz
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 shiſt-leſt tactics are falling short. Shiſt leſt 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. Tey 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. Tese security measures include the need to capture significant
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
