APIセキュリティの準備はできていますか？
Modern systems rely on complex systems that expose APIs over various networks. What is API security? And how is it incorporated into security programs?
Synopsys Cybersecurity Research Center (CyRC) API Security Group ( Travis Biehn , John Tapp , Jamie Boote )
All applications use APIs (calls to kernels, software development kits, crypto libraries, SOAP, etc.). It’s not new. What vendors today call “API security” is a subset of those APIs (those exposed on the network). By their nature, these APIs exposed to the network allow the free flow of information and the interaction between software components. Publishing endpoints to public / cloud / private networks gives attackers a new opportunity to explore these components of the system. We’ve seen high-profile breaches from the exposure and use of insecure API endpoints at some well-known companies ( USPS , T-Mobile , Salesforce, etc.). The question is how to ensure that your software security measures support the controls needed to secure the APIs you use and create. To answer this question, we first need to define “API security”.
What is “API security”?
API security is the protection of APIs that your organization creates, uses, and exposes to your network. Of course, this means taking advantage of common security controls that are closely related to the API (rate limiting and authentication, user, service, and request authentication and authorization). It also means understanding the specific places to look for context during design and review discussions when looking at the configured system by understanding the data history. For readers, it means that the application security program captures and applies activity to the software that exposes or uses the API at the right time. Robust API security comes from a culture of security that involves the activities of software security measures as a whole , rather than just buying new tools .
Dealing with API security
Due to general software development trends such as microservices architecture, SSI-related software units range from “applications” (monoliths) to their own lifecycles and contracts to maintain, and security controls that must exist. It has evolved into many subcomponents that expose APIs. Software security leaders can find opportunities for improvement in the following areas:
API design
The API is used between front-end clients (thick clients, browsers) and back-end systems, and between back-end components. In addition, a single API endpoint can have a mix of front-end and back-end requests. If an individual API endpoint is exposed to a variety of known and unknown callers (used, configured, or wrapped upstream by a gateway or load balancer), the individual API endpoint must apply. It is difficult to determine security controls. One decision that application security leaders can make is to drive an API that explicitly documents the assumed security responsibilities to both providers and consumers.
Designers are also faced with identifying cross-cutting API issues. Security leaders need to pay attention to security measures such as unification of access control and security measures close to business logic such as unification of customer IDs.
Security control
With regard to security controls, within API security, controls within business logic (protection against abuse cases), controls that protect business logic (authentication and authorization), and architectural security controls enabled or defined by the architecture. There are multiple levels of abstraction (API gateway, micro-segmentation).
Security controls enabled by architectural decisions are relatively new in application development in the context of API security. In addition to business logic, security controls also apply to concerns such as speed checks, authentication, and authorization decisions. There is also the issue of the best way to isolate a cluster of APIs that can enable critical security controls by the gateway. For example, does micro-segmentation achieve its purpose? How effective are the controls provided by the service mesh ?
Architectural decisions may seek to provide chokepoints to help security architects gain insights into these distributed systems. Architectural decisions may require a centralized management approach or enable an approach that applies to endpoints. Other than that, it’s free. You also need to discuss and consider the claims of vendors entering the market with new application firewalls and data loss prevention (DLP) mechanisms.
Of course, threat modeling is recommended. Application security leaders tolerate risks to different types of APIs (first-party, third-party, client, consumer), key controls for each API endpoint, and problems caused by API-intensive architectures (microservices, etc.) You need to start the process of deciding whether to accept possible solutions and vendor claims as part of your risk management program.
inventory
Leaders can visualize an organization’s API footprint, measure corresponding efforts with processes and tools, track, record, and prioritize ongoing security activities, and a wealth of different types of security analysis. Context must be provided. Talking to program owners about API security often reveals that existing inventory solutions do not provide this insight. Program owners should carefully consider whether existing inventory solutions can be adapted or new solutions need to be adopted.
Putting accurate information into your inventory is a completely different matter. Information is available from the development group, but you should invest in detecting process omissions. Sources include sensors deployed in the client and service code base (or binary or live instances), network inspection, OSINT technology, and complete black box detection. At the end of the day, you should be able to inventory the detection sensor results and operate APIs you don’t know at all.
Security test
Recent security tests are still good for gaining insights into the effectiveness of upstream software security. API security testing poses new challenges to manual, automated, and hybrid activities. Context is one such gap, and unless the tester receiving the API has the ability to form input and intuition the threat model, it will not be able to find the key issues that pose challenges to improving SSI. .. To be sure, the tools aren’t very effective either.
Static analysis tools are useful for identifying language-specific software security issues and familiar injection attack classes, and are still useful for API-intensive code bases, but for that, You need to model the libraries and platforms that the tool uses to expose the roots of your API. Static code analysis tools are not very useful for finding flaws in business logic. API-intensive projects need cross-codebase inference capabilities that exacerbate this gap. While static analysis tools remain an important tool in the toolbox, readers need to evaluate the ability of tools to detect flaws in code written on particularly popular API platforms. Fortunately, organizations that are adopting static analysis approaches (such as using authentication and authorization libraries) to drive the adoption of security controls find that their strategy is still valid for API security. You should notice.
Can generate an API coverage dynamic analysis in a general approach, tests of the client (or harness), test using an operation test, and test using the specification. The solutions presented here are not intended to require the development team to build and deploy in test tools, but to support as diverse a test preparation as possible. Leaders need to find ways to incentivize their projects and adopt ways to improve testability. There are two good ways to get started: cost and speed.
Modern applications and systems rely on complex API systems exposed on a variety of public and private networks. Understand the impact of these changes on various elements of software security measures, and make sure that the software that exposes or uses the API has security built in at the right place and at the right time. I can.
This post is based on an article published in the BSIMM community. For BSIMM, and for BSIMM how to join the community here please visit.
