An application’s attack surface is the sum of all the areas of an application which could be attacked by malicious attackers. This includes the application’s APIs, the underlying code, supporting infrastructure, and any other components which could be compromised. The goal for any organization is to reduce the attack surface area by discovering and minimizing potential vulnerabilities.
OpenAPI: The Foundation for Managing the API Attack Surface
One way to help understand and manage an application’s attack surface is to utilize The Linux Foundation’s OpenAPI standard. OpenAPI is specification that gives an organization a framework to discover and document the capabilities of their APIs without delving into the code. It’s a very robust standard, built on years of contributions and experiences represented by the Swagger effort, and SmartBear’s generous donation of the specification to the open source community.
Although it is not primarily focused on security, this framework DOES provide a critical foundation for key attack surface management functions through consistent API discovery and documentation of API capabilities. Utilization of OpenAPI helps organizations more quickly and efficiently apply the following tried-and-proven attack surface management processes to their APIs:
- Discovery
- Classification
- Categorization
- Priority setting
- Attack traffic analysis
- Vulnerability identification
- Creating a comprehensive security plan
Some may argue that gateways and other infrastructure-level solutions enable API monitoring and provide enough information to discover and manage APIs and the related attack surface. However, it’s my view that an infrastructure-based approach lacks a strong standards-based schema upon which organizations can build reliable API attack surface management processes.
Key elements of the OpenAPI schema with important security implications include:
- [info]: Typically includes information that helps security teams identify, classify, and categorize an API, which in turn can provide context as to the priority and/or sensitivity of the API.
- [servers], [paths]: Provides security teams information about resources associated with the API and provides values to correlate the spec to runtime data collection.
- [security]: Can provide insights into which security mechanisms can be used across the API, as well as alternative security requirement objects that can be used.
Additionally, once organizations have adopted and implemented OpenAPI, if an API does not have conforming OpenAPI documentation, there is a higher likelihood that it is a rogue API which represents a net increase in the API attack surface.
Ultimately, successful application security starts with successful management of the application’s attack surface. By utilizing OpenAPI, organizations have a synergistic tool to assist in their efforts to ensure that their APIs are secure and that potential vulnerabilities are identified and addressed. This allows them to focus on the most important aspects of security and ensure that their applications are as secure as possible.
Approaching Attack Surface Discovery
Q: What is the only comprehensive approach to application attack surface discovery?
A: API Runtime Attack Data and Analysis
As organizations increasingly move their applications to the cloud, the importance of API security is becoming increasingly clear. With the rise of mobile and web applications that depend on APIs for data exchange, the attack surface for these APIs is dangerously large and must be carefully managed. But beyond the traditional SAST and DAST approaches, runtime API capture and analysis represents an important tool for understanding the actual attack surface of an organization.
At its core, runtime API capture and analysis is the process of reconciling the actual API traffic at runtime with the APIs that are defined and managed with a standard such as OpenAPI. This helps application security teams identify “rogue” APIs that may not have been previously documented or managed. It is important to identify these rogue APIs because they represent unknown attack surfaces that can be potentially exploited by attackers.
Detecting APIs That Have Gone Rogue
In order to identify and eliminate these rogue APIs, application security teams must first be able to detect them in the runtime environment. To do this, they must have the ability to monitor, detect, and analyze API traffic in the runtime environment. This can be done with the help of tools such as API discovery and monitoring solutions that are designed to provide visibility into the runtime environment and alert security teams of any suspicious or potentially dangerous API traffic.
Once rogue APIs are identified, the next step is to work with the development team to bring them under management using OpenAPI or other standards. This involves defining the APIs that are to be managed, along with the appropriate authentication and authorization requirements. This will help ensure that the APIs are only used for their intended purpose and that access is limited to users with the appropriate credentials.
Ultimately, runtime API capture and analysis is where the “rubber hits the road” for API security. It is the only way to truly understand the actual attack surface of an organization and the only way to be sure that rogue APIs are identified and eliminated. By taking a proactive approach to runtime API capture and analysis, application security teams can be sure that their APIs are safe and secure in the wild.
