About Imvision

The only automated NLP-based API security platform that protects enterprise applications at scale

Learn More »

This is the third and final article in a series that looks at application security in the API-first era. These articles summarize a 3-part webinar focusing on the adjustments that leading global executives are making to their organizations’ security posture in response to changes brought about by the API-first era.

The first session looked at how security leaders are integrating the broader business perspective of the organization within their security posture. The second dug into the security standards being adopted to secure organizational APIs and how organizations are gaining greater visibility and control by restructuring their application security programs. 

This third and final article summarizes discussions surrounding the challenges confronted by today’s application security leaders. It examines the steps they can take to ensure that their organizations adopt secure API development practices, and how they can become more relevant by doing so. 

AppSec and API security: same same, but different

During the past decade, the use of APIs within development has steadily increased. According to Moshe Zioni, Director of Threat Research for Akamai, we see a 1:8 ratio of API to normal HTTP attacks, disproportionate to the population of APIs. As the use of APIs increases, so do attacks against them. 

In the past year, 60% of security leaders reported they’ve slowed down deployment to production (or considered to do so) due to API security concerns.

Credentials abuse attempts image

Source: Akamai's State of the Internet report for 2020

This raises the issue of inventory control: While many IT specialists may think that they have an accurate mapping of the APIs used in their organization, our experience shows that more often than not, this isn't the case. APIs are so prevalent within third-party packages, libraries, and testing processes that they often go unnoticed by IT. This poses a serious problem for enforcing security over those APIs: you can't secure assets you don't know you have. 

A second issue is that of functionality. By definition, APIs are intended to expose a functionality, enabling first or third party access to data and functionality. This creates a level of complexity that is more prone to vulnerabilities, especially as developer education towards API security is less common than general Web Application security.

These issues -- discoverability and functionality -- make APIs especially attractive to attackers, challenging them to detect APIs before defenders do and to devise creative ways to access the data that lies behind them. It’s even more troubling when you think about how the sophistication of API attackers has evolved. 

While only a few people knew how to attack APIs 5, 10, or even 15 years ago, today it's common practice in pen-testing, reflecting the adaptations cyber defenders are making in order to deal with API attacks. Hackers' shared knowledge of API attack vectors is growing by the day, giving them an advantage over defenders in this specific war game. 

Complexity is here to stay and you need to manage it

APIs are creating a highly complex environment that challenges organizations to identify all of their endpoints. Many enterprises have to deal with hundreds and even thousands of internal and external APIs impacting their applications. With so many teams working independently from each other, the only way to manage it all is to introduce automation. 

According to Laura Heritage, VP Product for API, Microservices, and Mesh Governance at  Axway, attacks may come from different directions, as many enterprises use complex API hierarchies: There are system APIs, process APIs, experience APIs and multiple gateways that require protection and enforcement. 

This complexity challenge will only grow as APIs continue to proliferate. According to Laura, the average organization having over 650 unmanaged APIs, ways to automate their detection and protection must be leveraged. The average enterprise currently uses three API management platforms and gateways, making it hard for security professionals to gain a full understanding of which endpoints might be vulnerable. 

Organizations need to bring all of the disparate APIs used within an organization into a centralized interface that enables the identification of possible attack vectors. The only way forward is to adopt automated solutions that embrace this complexity in a way that supports fast, secure scaling. 

 

Select your API vendors using our RFP template
Mailer 4 image

Collaborating our way to a secure API development culture

When looking at API security from the perspective of the individual developer, APIs are a window into the application, and if the application isn’t built with security in mind, there will eventually be a price to pay. According to Eoin Fleming, CISO at Leveris, There are three key activities that organizations can take with their individual developers to increase API security:

Align developer incentives towards greater security. Developers are incentivized to develop features and ship code, not to ensure that their code is secure. Organizations should change the way developers are incentivized to encompass secure code. Specifically, enhancing management visibility into the security efforts of developers, to make developers security champions. Gifts, prizes, prestige and involvement are all great incentives that will help developers focus more on security in their day-to-day work. 

Implement advanced training methodologies that enable a true DevSecOps approach.  By definition, most developers see themselves in terms of their specialization. Frontend, backend, full stack, Java, PLC, Kotlin - it really doesn’t matter; the fact is that they usually see security through the lens of their specialization instead of from a broader perspective. The OWASP API Top 10 is a great starting point to drive basic knowledge of security threats among developers. It enhances general awareness of best practices for securing applications against the more well-known vulnerabilities. 

Advanced language-specific training can be provided to developers working in specific projects that require very high security codes, like authentication schemes in Java. 

And you don’t have to train the entire team either. Providing high-level training to 20-30% of the team is usually sufficient for you to start seeing return on the investment. These early champions of security practices can act as mentors to the rest of the team, helping to cultivate stronger security practices within the dev team. For example, in pair programming you only have to train one of the pairs. In scaled agile environments, training should be provided to the cross-functional leads and maybe one or two team members. 

When it comes to rolling out the training plan, you should start with the low-hanging fruit - those teams developing the high threat, high risk aspects of the application. Start with authentication, authorization, access control, data management and data discovery teams. Then move on to the testing teams, as the more they understand about the process the better it’ll be for the entire team. 

Once you’ve got those teams trained, slowly get more and more teams onboard. Get ready for a lengthy process, it can take up to 4 years to onboard the entire development organization but note that you’ll become effective after around 30% of the team has undergone training. 

Raise developer security awareness and capabilities up a notch. Getting developers to understand the importance of security is essential. Implementing privacy and security impact assessments into the requirements phase empowers secure/privacy/security by design thinking. During the design phase, look at the tools, models and approaches and help raise awareness toward optimizing security across those aspects.

The collaboration between dev and sec teams is highly important as a way to better secure applications. A truly collaborative team effort complements each other’s work. While developers focus on how machines work and how to code software, sec teams can complement by teaching devs how attackers think. The teams must work together to enable an optimal security posture. 

One way to do that is by cultivating an attacker mindset among your dev team. Provide them with real hacker tools and turn them into a red team for security testing purposes. By looking at their code from an attacker perspective, dev teams will better understand how hackers detect and penetrate them, enabling them to better write more secure code during the initial development phases.

It’s time to bullet-proof your APIs from potential attacks