APIs are everywhere these days. You can hardly have a conversation about IT without talking about them. However, this ubiquity also means that APIs become targets for attackers. So how do you make sure your APIs are secure and stay secure? At Noname Security, they claim to have an answer to this question. We discussed this with Steven Duckaert, EMEA Solutions Architect at this provider of API security software.
The API has become a small but indispensable component within many organizations. If you want different environments, systems, applications or workloads to communicate and integrate with each other, you generally do that by means of an API. Modern software solutions support APIs almost without exception. That is, you can connect virtually any application and process. This provides many opportunities to streamline things within your organization. In this way you can combine your ERP data and your CRM data, for example, to gain even better insight into your supply chain.
The market for APIs is obviously enormous, because the advantages of integrating systems and solutions are obvious. You save a lot of time and can get much more and better insights from your data, to name a few benefits. On top of that, APIs are very easy to use. “The code of an API has very little substance,” in Duckaert’s words. “You can very easily expose services through APIs and thus put integrations live very quickly,” he further explains.
Strength of APIs is also their weakness
The simplicity of APIs in terms of the code is without a doubt a plus when you start working with them as a developer. After all, you can work nice and fast. That is especially nice when you work in sprints, where you have to deliver new functionality every few weeks. The code is also fairly stateless, so you don’t have to take much account of dependencies. That also helps to achieve a relatively high development speed.
The simplicity of the code of APIs is, however, also a weakness, Duckaert points out. You often use APIs to expose data from a process, system or application in the back-end to a client or other service. This happens quickly and most likely on a regular basis without thinking it through. Then there is also the risk of forgetting about APIs over time or not managing them properly from the beginning. According to Duckaert, the latter is the case for an average of 30 percent of API traffic with customers who use the public cloud. That means that 30 percent is not handled by an API Gateway or Web Application Firewall (WAF). Without an API Gateway or WAF, you have no visibility into what’s happening and you can’t provide protection.
It should be obvious that it is important to secure APIs properly. You are potentially at great risk if bad actors can get in through those APIs. They can get into the core or back-end of your organization through APIs relatively easily. It is generally believed that APIs will very quickly become the primary attack vector, if they are not already.
New approach needed
Protecting your APIs, however, is easier said than done. Existing (security) solutions such as a Web Application Firewall or API Gateway cannot protect you, Duckaert points out. According to him it is often code in your back-end that is not up to scratch. A WAF or API Gateway doesn’t give you any insights into that. In other words, you need a security solution that focuses specifically on the security of APIs. That’s where Noname Security comes in.
Noname Security may have a name that seems to have been coined in a jolly mood, its API security offerings are robust and comprehensive. Noname uses the acronym DART to make clear what it is doing. DART stands for Discover, Analyze, Remediate and Test.
Discover and Analyze
Within the Discover section, you can map all APIs in real time. You can also use this to map out zombie APIs and unmanaged APIs. It enables you to see whether the API contains/handles PII information, for example. With AWS, you can also immediately link any issues to an instance and infrastructure. These features are a nice segway into the Analyze part of the acronym. That is aimed at detecting misconfigurations or policy violations. The latter is very useful in relation to regulation such as GDPR. APIs that handle PII information are treated differently than APIs that do not. You can immediately create a ticket within Noname’s platform if it discovers a policy violation.
Remediate and Test
Within the Remediate portion of Noname Security’s approach, integrations come into play. For example, if a user excessively sends out API requests, you obviously need to be able to take action on that. Noname can’t do that itself, because their solution operates out-of-band. (See the aside elsewhere on this page for more information on how this works.) As such, it needs to leverage integrations with other components. An API Gateway can intervene in the case of overuse and cut off the API.
Within the Remediate part of Noname’s approach, you also get a clear indication of the company’s target audience. If you can’t use in-house integrations with other API components, you fall outside the target group. That’s why Noname specifically targets customers with a substantial number of in-house developers. Duckaert mentions 50+ developers during our conversation as the number an ideal customer for Noname has. If an organization meets that criterion, it probably also uses tools and technologies that Noname can integrate with, he indicates. Companies that opt for the standard SaaS or on-prem tooling, without further in-house development, are not the best match for Noname.
Returning to the DART acronym again, only Test remains. This indicates that organizations can use the Noname solution to produce reports. Apart from insights into the health of your API landscape, these reports also contain recommendations to improve API security. Furthermore, this component can also help with pen testing. This includes fuzzing, i.e. bombarding applications/APIs with nonsensical and deliberately incorrect data, in order to discover possible bugs. Finally, you can also use this feature to test an API when developing an application with or without an integration with your DevOps Tools.
Agentless and Out-of-band
Noname Security’s tool is designed to be deployed relatively quickly and to place as little burden on organizations’ infrastructure as possible. First of all, it is agentless. That means it looks for APIs on its own and you don’t have to install agents scattered throughout your environment. As already indicated in the body of this article, it allows you to map all APIs in real time, including zombie APIs and unmanaged APIs. They cannot guarantee 100 percent visibility of all APIs at Noname Security either, Duckaert indicates. The reason for this is that the tool partly depends on the completeness of the input they receive from customers. They indicate what they use in their environment. Based on that, the tool of Noname goes to work. If that input isn’t complete, the tool can’t make it complete.
In order not to burden the day-to-day operations of organizations, Noname Security’s tool works out-of-band. This means it does not use the bandwidth that employees use, and does not slow down processes. It uses features like AWS Traffic Mirroring to receive a copy of the network packets. These packets, both incoming and outgoing, are copied to the Noname engine. So you are then outside the so-called API data path (and don’t need agents either). The APIs in production continue to perform as they always do. You don’t create extra latency by adding an extra stop. Something you would do if you were working in-band.
Broad relevance APIs make focus difficult
It is clear that both APIs and Noname Security’s solution have many different facets. APIs touch many parts of an organization, which sometimes makes it difficult within organizations to determine who the product owner of API security is. Noname Security also runs into this in practice. Indeed, part of the broad applicability of APIs is reflected in the solution the company has developed. “The tool allows you to set up things like governance properly, but it’s also part of the CI/CD pipeline,” summarizes Duckaert. You can even use it for awareness purposes, if you want to train your people to keep security in mind when working with APIs.
This broad applicability makes it quite a challenge for Noname at times to appeal to the right people within organizations. Add to this the fact that API security doesn’t get the attention it deserves in the first place at the moment, and Noname has a significant challenge on its hands. As a security tool, Noname’s tool will obviously have a place within an organization’s security team. In general, that’s where the budget will have to come from. A second owner is generally the team or person with final responsibility for APIs within an organization.
Noname, however, also focuses on application in the CI/CD pipeline. More specifically the right side of the pipeline, the feedback part after the developer has finished developing features or applications. So the developer himself does not use the tool of Noname Security and is therefore not the target group of Noname Security. However, DevOps teams are, Duckaert emphasizes. They have to check whether everything works as it should. And they are usually not aware that an API Gateway is not a security platform and that you should look at another tool for API security.
Does Noname Security bridge the gap between security and IT/operations?
At the end of the day, an API security supplier like Noname Security will have to discuss the topic primarily with the security team of organizations. After all, that’s where the budget comes from. They have to be convinced that it’s worth the additional investment, on top of the existing security tooling. However, API managers and DevOps must also be convinced of the importance of API security. That’s not easy, because those teams don’t usually work closely with the security team. In other words, this is about bridging the gap between security and IT/operations. That is a hard nut to crack.
You can also see it the other way around, however. Noname Security could cause those parts within organizations to talk to each other more and work together. That would at least be an interesting by-product. Based on what we know about the vulnerability of APIs, doing nothing does not seem to be an option, and not using APIs at all is not an option either. The issue needs to be tackled someday, so it may be wise to look into it sooner rather than later.
21 minutes ago
