Factors driving API growth in industry

This is third in a series of articles that introduces and explains application programming interfaces (API) security threats, challenges, and solutions for participants in software development, operations, and protection.

Explosion of APIs

The API explosion is also driven by several business-oriented factors. First, enterprises are moving away from large monolithic applications that are updated annually at best. Instead, legacy and new applications are being broken into small, independently functional components, often rolled out as container-based microservices. The resulting application components and microservices work together to deliver the same functionality as the monolithic applications.

Holding all of this together, of course, are the APIs that allow for communication between processes, bi-directional sharing of data, and real-time provision of services. By serving as the bridge between applications, components, microservices, and other containerized workloads, APIs can be viewed as integrating large portions of the Internet, including eCommerce, supply chain processing, enterprise business interactions, and other components of the modern digital economy.

At a more technical level, the factors that have helped to make APIs so pervasive in the design and implementation of Internet services include the following:

• Support for DevOps – Iterative development methodologies such as DevOps, DevSecOps, and Agile enable teams to push incremental changes directly to customers instead of using long development and assurance cycles.
• On-Demand flexibility – Modern application hosting requires the ability to scale services up or down, on-demand, and in a cost-effective and efficient manner, to handle changes in usage patterns, such as seasonally-based demand.
• Development frameworks – Technology adoption trends such as increased use of cloud, containers and orchestration (such as Kubernetes), and management frameworks (such as Istio) make it easier to develop and deploy API-based microservices at scale.
• Diverse ecosystem – Partner ecosystem expansion, enabled by API-based microservices enable aggregators, suppliers, and external developers use to grow their business without replicating functionality. These APIs are well-documented and publicly-available, as evidenced by the massive directory of more than 23,000 APIs that one can find on the Internet.

The increased adoption of APIs is thus great news for businesses, but introduces corresponding challenges for security professionals. Enterprise teams who might have been tasked previously, for example, with protecting a handful of applications, might now be suddenly responsible for protecting hundreds if not thousands of public-facing APIs with a range of cyber security risks. As a result, API security has become a top-of-mind issue for most CISOs.

OWASP Top Ten risks

The Open Web Application Security Project (OWASP) Foundation was created to improve the security of software through community-led software initiatives, local chapter work led by members, and many different conferences. Its most famous product is the so-called OWASP top ten risks, which are published to help software developers avoid the most common risks in the creation and use of web applications. A description of the top ten OWASP risks is listed below, and taken directly from the OWASP Website.

1. Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

2. Broken authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

3. Sensitive data exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

4. XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

5. Broken access control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

6. Security misconfiguration. Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

7. Cross-Site Scripting (XSS). XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

8. Insecure deserialization. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

9. Using components with known vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

10. Insufficient logging & monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Security in DevOps

The waterfall model of software development has become a victim of time. That is, the duration between when software requirements are defined and the time functional code is delivered has become too lengthy for most practical environments. In fact, by the time a waterfall project gets around to coding, the requirements have often changed so much as to render the activity irrelevant. Because requirements changes usually originate with end-users, the situation is unlikely to change.

To address this accelerated lifecycle, so-called DevOps processes have emerged in the software community. Designed to address the increasing pace of requirements change, DevOps involves rapidly-organized and quickly-executed tasks designed to produce and deploy new requirements quickly. Integration between coders (the Dev part) and production users (the Ops part) creates a never-ending spiral cycle of software development that is best performed with a maximum of automated support.

Introducing security into DevOps became an obvious concern once DevOps processes were applied to critical system development efforts. Experts saw this as an immediate challenge, because many security tasks have the inherent result of slowing down deployments due to a traditional reliance on change control processes. This produced an immediate collision between security and the obvious DevOps objective of moving as quickly as possible.

The solution to the DevOps security challenge is automation. Only through the introduction of automated controls for tasks such as security testing, code scanning, control monitoring, and activity logging – can the speed of DevOps be maintained, while also ensuring that vulnerabilities are not being introduced as a result of the process. Obviously, buggy code with exploitable breaches will continue to emerge from DevOps, but these should not be introduced as a result of the process.

One interesting and curious note worth mentioning is that the community has not agreed on a standard nomenclature for secure DevOps processes. One might find references to DevSecOps, SecDevOps, and DevOpsSec – and this author has no good advice for identifying the differences. Readers are advised to engage with the security team early in the application development process to foster a tight working relationship.

Contributing author: Matthew Keil, Director of Product Marketing, Cequence.