This week, we have articles on how DevOps teams can defend against API attacks, my views on how empathy for API developers can be a driver toward greater security, and eight measures to improve API security. We also have views on why API gateways might not be sufficient for API security, and finally, a report from Approov on the state of mobile application security in 2022.
Article: How DevOps teams can defend against API attacks
First up this week, we have an an excellent article from DevOps.com discussing how DevOps teams can participate in the defense of APIs against attacks. The author offers a novel viewpoint:
“the security practices that DevOps teams already have in place to defend against ransomware can be repurposed to deliver API security, tooโwith a few tweaks.”
The first recommendation for the defense of APIs is to prevent lateral movement: whilst it is impossible to prevent API threats from reaching your perimeter, it is possible to limit their propagation and impact by preventing attackers from pivoting to other internal systems. The key to this approach is the early detection of the initial malicious activity, as early detection allows prevention.
For me, the most salient observation from the author is that DevOps teams focus on data security โ ultimately, the goal of the attacker is to get access to valuable corporate data. Much like the case with ransomware, attackers target data and hold organizations to ransom over access to that data. For APIs, the threats are even greater: the data can be exfiltrated and sold for profit or to damage the reputation of the organization. Data protection practices should be employed, including tight and granular access controls on data, and segmentation of access between internal and external APIs.
The author highlights the ineffectiveness of signature-based detection methods, because these tend to be impervious to zero-day attacks or unknown attacks. By using behavioral security models, defense teams can model standard API behaviors and usage patterns to be able to detect anomalies to this behavior, which may indicate a compromise. APIs tend to be accessed in standard patterns, making it feasible to detect unusual behavior like that of a human adversary.
The author advises against being overly reliant on perimeter-based defenses โ as documented in this newsletter and elsewhere, firewalls and WAFs are notoriously ineffective at preventing focused API attacks.
Finally, the author stresses the importance of looking beyond the surface: using a layered defense mechanism and understanding how an attacker might attack your API assets and, for example, opting to place your APIs behind non-standard ports or protocols.
Some really insightful advice here on how to use your existing protection mechanisms to protect your APIs.
Article: Empathy for the API developer
I was pleased to be featured in DevOps.com this week, discussing the importance of developing empathy for API developers to achieve better API security outcomes. In my two decades of working on both sides of the developer-“versus”-security fence, I believe I have some insights on better ways to work together.
First, let’s understand why insecure code exists in the first place: software development is a complex undertaking fraught with many opportunities for introducing weaknesses and vulnerabilities. Some of the reasons include:
- Developers are overly optimistic โ they are creative problem solvers who don’t always expect the unexpected.
- Overconfidence โ developers often think they have a better understanding of complex software frameworks than is actually the case, leading to unintentionally insecure software.
- Bad things only happen to other developers โ Think of this as a kind of schadenfreude for developers.
- Taking shortcuts โ we’ve all done it, a missing null pointer check, or an unhandled error condition. These can have significant security impacts.
- Technical debt or legacy code โ this is probably the number one cause of insecure software.
- This stuff is difficult โ developers work under pressure on numerous fronts, and security is only one of their considerations.
API security offers some unique opportunities to break down these barriers between developers and security teams.
- Firstly, the positive security model (more on this in the last piece this week) allows a far more precise definition of the expected behavior of an API โ traditional security tools (WAFs, firewalls, SAST) attempt to prevent or detect known badย which can result in both high false positives and high false negatives. This leads to frustration for security teams and developers who feel they are tasked with unnecessary remediation work.
- Secondly, using a design-first approach based on OpenAPI definitions allows security policy to be injected as code in the CI/CD process. No longer do developers need to try and guess the applicable policies, instead these can be expressed concisely in code.
It all comes down to this: “help developers to help themselves by building empathy and working with them rather than against them.”
Article: Eight security measures to improve API security
Next up, we have another good read on security measures that can improve API security. The author identifies the following eight areas for focus in improving API security:
- Build for future users, not present ones: Design APIs with security in mind at the outset โ common pitfalls include not implementing proper access controls in development, only to find the API is released to production without the necessary controls.
- Limit users: Reduce the attack surface by limiting the number of users that have access to APIs (for example, by using tokens with limited scope, or validity periods).
- Limit data: Avoid collecting and aggregating more data than necessary for an API function to minimize the danger of accidentally leaking more data than you intended to expose.
- Encrypt data: An obvious one, but make sure all data is encrypted, both at rest and in transit (use TLS in all cases).
- Enact pagination limits: Excessive data exfiltration can be prevented by using well-designed pagination controls at the API level.
- Use prepared statements in SQL queries: Although over two decades old, SQL injection attacks are still prevalent and can be totally avoided by using prepared statements in SQL queries.
- Strengthen end user and application authentication: Use best practices for authentication, including password and token rotation and revocation, and limited scopes and roles.
- Impose rate limiting: Another obvious one is the judicious use of rate limiting on sensitive API endpoints, such as password reset or registration methods.
There’s no silver bullet toward API security, but a good layered defense approach eliminates many of the basic attack vectors.
Article: Why your API gateway is not enough for API security
A perennial hot topic when discussing API security is the role of the API gateway, and this week HelpNetSecurity provide their thoughts on the topic. The author’s view is that API gateways serve a particular purpose: route API traffic from external interfaces to the corresponding internal services. These API gateways were therefore not designed with API security at the top of the requirement list.
A good example is that of token leaks or theft: once an attacker harvests an API token, the API gateway is powerless to stop attacks that use this token because the attacks are indistinguishable from normal requests. Also, API gateways can provide a false sense of security: not all APIs are routed through the gateway, meaning that additional attack surfaces that are not visible to the gateway do in fact exist. Many API attacks are sophisticated, relying on coding or logic errors in the API backend, and gateways are simply unable to protect from these more complex attacks.
The author recommends using more modern WAAP (Web Application and API Protection) technology to provide API protection; however, these have their drawbacks, being built upon a negative security model. This week’s featured upcoming webinar discusses how a positive security model can overcome these limitations.
Report: The state of mobile application security in 2022
Finally this week comes a report from our friends at Approov on the state of mobile application security in 2022. Unsurprisingly, the report highlights the deleterious effects that poor API security has on the overall security of mobile applications. Frequently, attackers use mobile APIs as the primary attack vector, rather than the mobile application itself.
The full report makes interesting reading, but from an API security perspective the following findings are of interest:
- Run-time attacks against APIs that render mobile applications non-functional prove costly to 75% of organizations.
- Over 60% of organizations lack visibility into runtime threats against mobile applications and APIs.
- Reducing threats that result from hard-coded API keys is a priority โ over half of mobile applications that the report looked at used hard-coded keys embedded in the application.
- Third-party APIs create pathways for threat actors โ typically mobile applications depend on more than 30 third-party APIs!
The report provides a nice illustration of how API security underpins the security of higher layers of the application stack โ attackers simply do not bother attacking the application layer when they can go directly at the API layer.
Webinar: Benefits of a Positive Security Model
Positive Security is a model that enables access to known trusted resources, rather than trying to determine what activity or entities have hostile intent. Applying a positive security model when protecting your APIs can offer direct benefits, such as reducing false negatives and lowering reliance on constantly adding to the characteristics of what constitutes hostile traffic. It also has indirect benefits for the working groups on your DevSecOps team, allowing them to focus and be more efficient in their individual roles.
Join Michael Farnum (CTO at Set Solutions) and me on August 2, 2022, at 10:00 CDT / 16:00 BST as we dig into both the direct and indirect benefits of a positive API security model, and explain how 42Crunch can apply that model to your APIs.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
