ThreatX today expanded its namesake platform for protecting application programming interfaces (APIs) to provide increased visibility into the size of the attack surface and the scope of the attacks being launched against APIs.
In addition, the latest update identifies API schema compliance gaps that attackers can potentially exploit.
The ThreatX platform employs machine learning algorithms and other forms of artificial intelligence (AI) such as fuzzing to detect anomalous API behavior. It then uses the data it collects to build risk profiles of attackers over time that can be used to stop similar attacks in real-time.
Tom Hickman, chief innovation officer for ThreatX, said that approach makes it simpler to secure APIs regardless of whether cybersecurity teams are aware they exist.
One of the major challenges with API security, in general, is they are usually created by developers that don’t consistently document their existence. It’s also not uncommon for developers to expose an API and then neglect to update it. Those so-called “zombie APIs” present cybercriminals with an opportunity to exfiltrate data via an API that security teams might be unaware of.
The API schema compliance tool added to the ThreatX platform also is critical because it provides a way to centrally manage APIs that adhere to the OpenAPI 3.0 schema, said Hickman. IT and security teams can then compare API traffic to specifications to determine whether compliance gaps exist, he noted. The ThreatX API Dashboard that has been added details API endpoint usage and how it compares to expected behavior as defined in the schema. IT teams can also build custom schemas for APIs that are outdated or those that have no schemas available, added Hickman.
Armed with those insights, it then becomes possible to automatically block API calls, establish geofencing boundaries to block traffic from parts of the globe where there are no clients, or tarpit attacks to prevent overconsumption of backend resources.
The biggest issue when it comes to API security, however, may still be simply determining who is responsible for it. Application security has always required a level of collaboration between IT security teams and application developers that has proven elusive. However, as organizations start to build and deploy more microservices-based applications that are dependent on APIs, Hickman said there is an increased focus on getting application security right before these applications are deployed in a production environment.
Of course, there is no shortage of platforms for securing APIs. The issue that many organizations are now wrestling with is crafting a set of DevSecOps best practices that include API security. In theory, responsibility for securing APIs is shifting left toward developers and DevOps teams. In practice, however, the level of security expertise among application development teams remains uneven, at best. Most IT organizations are going to rely on security teams to make sure APIs—along with the rest of a software supply chain—are secure.
The challenge today is many of those security professionals don’t have a lot of insight into exactly how those software supply chains operate, much less where vulnerabilities are hidden within them.