APIcon: How can we help ensure better security in open source software, either as contributors or as developers using it?

Ilkka Turunen: This is a complex problem, both on the producer and the developer sides. Part of the reason open source is popular is in the core ethos of sharing, and making it easy enough to share your work. By keeping this barrier of entry as low as possible for publishers, the open source community has flourished. From a publisher point of view, this puts a huge amount of responsibility to ensure contributions are legitimate – and the code contributed by others conforms to standards. We have seen an increase in friendly strangers turning bad and introducing malicious code after a few legitimate contributions.

From the perspective of a developer consuming open source – taking steps to understand what your software supply chain looks like and where it originated from is a key step. Putting checks and policies in place that describe what we should be downloading, and making deliberate calls on what open source you are downloading can help increase the security and management overhead. Introducing automated tools to your supply chain and treating vulnerability checks as a part of your everyday routine helps.

Muzaffer Pasha: From a contributor’s perspective, developers are focused on delivering features and are not necessarily focused on security vulnerabilities. At its root, software bugs that impair feature functionality and security vulnerabilities are the same – they are software flaws. Open source initiatives need a security advocate to help ensure that security vulnerabilities have the same level of attention as feature bugs. Helping to identify security vulnerabilities can help to build awareness and focus attention on narrowing down critical vulnerabilities (CVEs) that need to be remediated before they flow across the open software ecosystem.

From a developer’s perspective, open source cuts down on development time, ensuring software is delivered faster. Modern software often follows the 20/80 rule where 20% of actual software stems from actual development and 80% is incorporated into open source software. However, the drawback to utilizing open-source software is that you can inherit security vulnerabilities. In 2017, the Apache Struts vulnerability led to the massive Equifax data breach, which is one example of how unscrutinized use of open-source software can lead to the exploitation of sensitive data. Developers need to identify potential vulnerabilities, ensuring that they are properly patched before being released into production or, ensure that their application security is able to mitigate any exploit in the runtime of a deployed application.

Increasingly, APIs have become a common attack vector. Cybercriminals have expanded their campaigns from targeting an organization’s web application to include attacking their APIs. This means that when using or contributing to open source software, or any software for that matter, the security of the APIs must be scrutinized closely. Developers should ensure that their application security testing understands and can scan for API vulnerabilities in addition to the known web application vulnerabilities. Ideally, an organization should capture API vulnerabilities during the development process, but often, due to pressures to innovate quickly, software flaws, including security flaws, escape into production. To protect themselves from this eventuality, all organizations should ensure that in addition to security testing in their development phases, they also have a run-time application security solution that can detect and block malicious API attacks.

APIcon: How has security changed in the past 20 years? What trends have you noticed, and have we gotten better overall, or worse?

Ilkka Turunen: Software production has undergone a silent industrial revolution in the last few decades. The promise of modularised and portable software has been redeemed with the advent of dependency management and easier than ever to use supply chains. This has made development higher quality, more effective and every single developer simply more expressive compared to their peers even 10 years ago. We’ve gotten better at the basics, by reusing the top-of-line frameworks for authentication and authorization for example. Or using the same infrastructure to run our code as google does. This has enabled us as an industry to raise the quality of the software we write. With this new ability, new threats have emerged now needing new ways of thinking and management to endure and change. The pace of vulnerability and exploitation has increased, so automation is an absolute necessity.

Muzaffer Pasha: Networks used to consist of a warehouse of servers and stationary desktop computers. There was an obvious network perimeter – security teams knew which users were trusted because they only logged in from trusted computers and accessed servers locally. But now, with widespread remote work, BYO devices, and an explosion of applications and microservices, the perimeter is simply nonexistent, and security teams cannot rely on antiquated methods to establish trust with users.

Organizations have shifted from developing monolithic applications to microservices-based applications deployed in the cloud. Microservices-based architectures use APIs as the connective tissue in order to facilitate communication with different parts of the application. Often, originally internal APIs get released externally to create new business models such as smartphone apps or 3rd party business relationships. The rapid release of external APIs often overlooks API-focused security vulnerabilities that actually can compromise sensitive data stored in the application.

As a result, cybercriminals have adjusted their attack vectors from monolithic applications run in physical data centers to target cloud-based applications. The exponential growth of sensitive data stored in cloud-based applications and the growth of the APIs used to access it has made the task of securing sensitive data much more difficult.

As API traffic dwarfs web application traffic, it has created a blind spot for organizations that don’t have a modern application and API security solution. Cybercriminals have seen the shift in traffic to APIs and have implemented cyber-attack campaigns that probe weakness in APIs such as poorly written business logic or API vulnerabilities. A more modern application and API security approach is required that addresses the inability of WAFs, RASPs, and API gateways to sufficiently protect an organization’s APIs. Today’s WAFs and RASPs do not understand the language of APIs as they are unable to take apart complex API interactions to understand if they pose a threat or not.

In this sense, although we have gotten better by shifting security practices left in the development pipeline, overall we are now dealing with increased complexities in securing our applications which our development practices and runtime protection tools have not yet caught up with.

APIcon: Many times, when we talk about security, we weigh dangers in terms of downtime or lost revenue. But there is also a human component here and leaked personal data can put people in harm. What should more organizations be aware of when it comes to ensuring security for the sake of people?

Ilkka Turunen: Simply put, GDPR and comparative legislation across the world puts a huge amount of pressure on organisations to react quickly to findings. In the recent White House executive order on improving the nation’s cybersecurity, the US government is mandating breach disclosure timelines that are aligned with GDPR to 3 days in most severe cases.

This means organisations have to think hard about the protection of data, and how it is accessed. From a development perspective, this will require employing industry best practices at a fast enough pace – which the software supply chain allows them to do.

Muzaffer Pasha: Absolutely – even a simple leaked email and password combination can be devastating for consumers who aren’t security-aware, from account takeovers to spam and phishing messages. When PII (personally identifiable information) is involved, it can be even more devastating. A leaked social security number can lead to manipulation, illegal transactions, or even something as severe as identity theft or a variety of other types of fraud.

Organizations often collect and store sensitive data from their customers and employees in order to run their business. As data is collected, the expectation by most organizations is that this sensitive data they’ve collected will never be misused or exfiltrated by anyone who shouldn’t have it. The reality is that data breaches happen and there aren’t many major companies who haven’t been affected by a sensitive data exposure.

The impact of sensitive data being leaked or stolen can be wide-ranging, from a person’s PII and PHI being resold on the digital black market to an advanced account takeover where money, frequent flyer miles, or other units of value such as cryptocurrency, can be stolen from a person’s account. Organizations that are responsible for storing sensitive data should implement stringent security corporate policies that ensure company-wide security best practices are followed. Security solutions should be evaluated and updated as IT applications and infrastructure are changed within the organization – ensuring the right security solution to protect sensitive data. A single weak security control can circumvent an organization’s entire investment in a range of deployed security solutions that are simply thwarted by cybercriminals bypassing weak control mechanisms.

Ideally, security solutions should be able to track interactions from user to data. In this way, they can separate out malicious interactions with sensitive data, ensuring only legitimate transactions occur. This would in turn enable organizations that store customer-sensitive data to do a better job of monitoring sensitive data and who interacts with it, preventing damaging data breaches.

APIcon: How does a more secure network improve efficiency?

Ilkka Turunen: Security is a layered process, network security being among one basic tenant. Today the prevailing wisdom is that we should not trust networks, we should work on a basis of zero trust. To do this, organisations need to develop automation and a muscle to react quickly to their findings. The good news, doing this improves efficiency of operations and delivery speed – as it turns out building the skill to react to automation fast also improves the ability to react to findings fast.

Muzaffer Pasha: A more secure network used to mean that a strong perimeter enabled employees to freely collaborate and communicate within the enterprise. However, as enterprises and their applications have become more distributed, with more employees working outside the enterprise perimeter than inside, and application components spread beyond the data-center walls, this concept no longer applies.

It is still important to keep networks secure, however, it’s equally important not to miss the other attack surfaces above the network layer which also need to be secured. According to Gartner the attack surface now responsible for the majority of enterprise data breaches is the newer API attack surface.

What has resulted in recent years is that security has been required to be incorporated at multiple layers – such as at the user-level, device-level, application layer, and now the API layer, in order to ensure that anyone component does not become the weakest security link in an IT enterprise infrastructure. An organization that doesn’t focus on securing the layers above the network layer won’t have a good security posture and opens itself to more cyber-attacks. A data breach can distract management, security teams, and employees, and can be the cause of imposing even more stringent security controls that can greatly slow down organizational efficiency.

APIcon: What are some of the current alarm bells and security red flags that require immediate attention?

Ilkka Turunen: Developers and development infrastructure under an unprecedented volume of attacks. Many of the recent major security incidents can be traced to poisoning the supply chain upstream from the victim, for example by compromising a company’s software build infrastructure and poisoning proprietary code.

Muzaffer Pasha: The red flags we are all hearing the most about are the recent software supply chain attacks heard all over the news, such as SolarWinds, Accellion, and Codecov. These attacks highlight how security risk can pass through a highly interconnected software ecosystem. They are telling us that the industry needs to put more focus on security in the software development life cycle, such as maintaining software bill of materials (SBOMs) and using more application signing.

However, supply chain attacks are not the only red flag we should be paying attention to. With the rapid growth of cloud-native, microservices based, and API-driven applications, the API attack surface of applications has drastically broadened and become the number one attack target for bad actors. APIs provide an attacker the ability to directly talk to the back-end where sensitive data such as PII and PHI data is stored. If you look at OWASP Top 10 API attacks, Broken Object Level Authorization (BOLA) is one of the most common unaddressed API vulnerabilities that face most organizations. With API traffic growing at rates that will dwarf web traffic, API security vulnerabilities will need to be addressed with a higher level of priority by the wider development community in order to ensure that deployed software is safe and secure.

Making the red flag even more alarming is that these vulnerable APIs that are pushed into production often aren’t being protected at run-time by the right security tools that understand the newer sophisticated API vulnerabilities, such as those on the OWASP API Top 10 list. This can be a blind spot for organizations that store customer data that could be potentially exfiltrated through vulnerabilities in their APIs and web app focused run-time security solutions.

APIcon: Are we sitting on major security vulnerabilities right now, and if so, when will they implode?

Ilkka Turunen: Yes, we are – over 90% of modern software infrastructure is built using the supply chain, or to say it another way, outside of developers’ organisations. This growing complexity leads to new threat scenarios where it’s becoming increasingly easy to target known security vulnerabilities. Over half of the organisations we know of don’t have any policy or enforcement around consumption. Worse yet, the growing complexity in the software supply chain makes it easier for bad things to slip by unnoticed. Solarwinds is a good example of these sorts of issues and how it played out with their customers. This is a growing concern for the profession at large and we should continue to work on it.

Muzaffer Pasha: As an industry (anyone creating, operating, or using software), yes we have some serious blind spots that are widespread. API vulnerabilities which include sophisticated business logic level attacks are not getting the needed level of attention. Are they imploding on us? Yes. The last few years have been fraught with stories of major software or tech companies getting burned by API vulnerabilities, such as Uber, Facebook, T-Mobile, USPS, Shopify, and Peloton.

To improve our overall API security posture the industry should do two things:

1. Shift API security education left – Better educate developers about common API vulnerabilities and how they can be potentially exploited by cybercriminals. The root cause of most successful API attacks is that software developers are generally not yet trained enough in developing security into their APIs or in how security vulnerabilities can lead to the compromise of sensitive data. In general, the hackers have discovered the value of these relatively new API vulnerabilities, and Dev, Sec, and Ops teams are still catching up.
2. Shield production with API-capable security solutions – You can bet that these big tech companies who were victims of API attacks had investments in good security technology and teams, but yet they still got hacked. Why is that? Because the industry is relying on security solutions such as WAF and RASP and API gateways that are not designed for, and incapable of, detecting and blocking these newer more sophisticated API business logic attacks. The industry needs to evolve our defenses.