Are you ready to deploy API security?

Modern systems rely on complex systems of APIs (application programming interfaces) exposed through various networks. Many companies use APIs to transfer data and connect services to provide convenience. However, at the same time, some serious data leaks in recent years have been caused by API attacks and destruction, resulting in sensitive information being used by criminals.

So what is API security, and how does it fit into your overall security plan?

All applications use APIs (e.g., calls into the kernel, software development kits, cryptographic libraries, and the SOAP protocol). Today, when vendors refer to “API security,” they are referring to a subset of these APIs — those exposed over the network.

Essentially, these network-exposed APIs enable information to flow freely and interact between software components. Attackers have the opportunity to compromise components of a system through exposed endpoints across public, cloud, and private networks. Major breaches at some well-known companies, including USPS, T-Mobile, and Salesforce, stemmed from the exposure or use of insecure API endpoints. So how do you know if your software security program is meeting the security controls your organization needs to ensure that the APIs you use and create are secure? First, you need to define what “API security” is.

What exactly is “API security”?

API security is the protection of the APIs that are created and used by an enterprise (exposed to the network). Of course, this means using the common security controls that are closely related to APIs: rate limiting and authentication and authorization of users, services, and requests. It also means understanding the source of data and looking at the systems that make up it, and exactly where to look for context when designing or reviewing discussions. For software security leaders, this means that application security programs can capture activities at the appropriate time and apply them to the software that exposes or uses APIs. Strong API security is not just about buying some new tools, it also comes from a security culture that involves activities across the entire software security program.

Solving API security challenges

Popular software development trends such as microservices architecture have expanded the software unit associated with software security initiatives (SSI) from "applications" (or monoliths) to many subcomponents of the API. These subcomponents have their own lifecycles and contracts and must comply with security controls. Software security companies can improve security by:

Designing APIs

APIs are used between front-end clients (fat clients or browsers) and back-end systems, as well as between back-end components. Consider further that a single API endpoint may end up handling both front-end and back-end requests. It is difficult to determine which security controls must be enforced for individual API endpoints when they are exposed to a variety of known and unknown callers (upstream consumption, composition, or wrapping of gateways or load balancers). One decision that application security leaders can make is to promote the use of APIs to clearly document the security responsibilities that should be assumed by providers and consumers.

Architects also face the trouble of identifying cross-cutting issues with APIs. Security leaders should pay attention to some security activities, such as unified access control, and those that are close to business logic, such as unified customer authentication.

safely control

With regard to security controls, there are multiple levels of abstraction in API security: controls within the business logic (preventing abuse); controls that protect the business logic (authentication and authorization); and finally architectural security controls that are enabled or defined by the architecture (API gateways and micro-segmentation).

Security controls, enabled by architectural decisions, are relatively new to application development in the context of API security. Beyond security controls applied to business logic, this extends to things like velocity checks, authentication, and authorization decisions. We need to know how to best isolate a set of APIs and enable important security controls there through gateways. For example, does micro-segmentation make the cut? How effective are the security controls provided by a service mesh?

Some architectural decisions attempt to provide choke points so that security architects can gain deeper insight into these distributed systems. While some architectural decisions require a centrally managed approach, others enable an endpoint-enforced approach.

Of course, threat modeling is recommended. Application security organizations must begin to identify the risks of various types of APIs (first-party, third-party, customer, or consumer), the key controls for each API endpoint, acceptable solutions to issues caused by architectures that use many APIs (such as microservices), and whether to include vendor claims as part of the risk management plan.

Bill of Materials

Application security organizations need to understand their API footprint; measure the efforts to cover that footprint using processes and tools; track, log, and prioritize ongoing security activities; and provide rich context for various types of security analysis. When discussing API security with program owners, we often find that existing inventory solutions do not provide these. Security program leaders should carefully examine whether existing BOM solutions can be adopted or whether a new solution must be adopted.

Safety test

Security testing today is as important as ever to gain insight into the effectiveness of upstream software security practices. API security testing presents new challenges for manual, automated, or hybrid testing. One of these challenges is context. If testers do not have the ability to input or perceive threat models, high-risk issues that are detrimental to SSI cannot be found and fixed in a timely manner.

Static analysis tools can effectively identify language-specific software security issues or well-understood injection attacks, and they are still effective for code bases that use a lot of APIs, but the premise is that these tools must model the libraries and platforms used to expose these API routes. Some enterprises have already adopted static analysis to drive security controls (for example, using authentication and authorization libraries) and can be used for API security.

Dynamic analysis can generate API coverage, and its typical approach includes testing the client (or tool), behavior, and usage specifications. The solution is not to build a tool and force the development team to use a test tool, but to support a variety of possible tests.

Modern applications and systems rely on a complex system of APIs exposed over a variety of public and private networks. There are steps we can take to understand how these changes affect the various elements of our software security programs and ensure that security is built into software that is exposed to or uses APIs at the right time and place.