Seven API Security Predictions for 2022
If 2022 is anything like 2021, we’ll see no shortage of API-related events this coming year. In 2021, we saw many issues originating from leaky APIs, misconfigurations, weak or broken access controls, latent vulnerabilities, and poor coding practice. The end result was a laundry list of data exposures, data loss, privacy impacts, privilege escalations, remote code executions, account takeovers, weakened digital supply chains, and more.
Often when we speak of API security incidents, underlying causes map back to the OWASP API Security Top 10. Many API security events include cases of broken object level authorization (BOLA), broken user authentication (BUA), and excessive data exposure. These most common API flaws are the tip of the iceberg though. Attackers find and abuse APIs in many other ways. Organizations also face risks from automated threats including scraping, credential stuffing, and brute forcing. Finally, attackers chain together multiple exploits and abuses in novel ways to form complex attack chains that are more likely to evade detections and protections and improve chances of success for the attacker.
Not to be bound by the trends of 2021 only, these 2022 predictions are also based on undercurrents that have been building for years as a byproduct of initiatives like DevOps programs, cloud-native design patterns, and industry standard practices of outsourcing. These predictions are based on my many years of experience as a systems engineer, application security practitioner, and analyst-advisor to organizations of all shapes and sizes.
In no particular order of likelihood or preference, seven predictions for API security for 2022 are as follows:
1. We will witness another large-scale digital supply chain attack
APIs in isolation are one matter, but as part of most architectures and system design, it is collections of APIs that enable functionality. This reality of system design also means an organization is also working with multiple third parties. Third-party service adoption typically takes the forms of:
- Acquisition of application code that either runs directly as an API or serves as a dependency to infrastructure that powers APIs.
- Active consumption third-party services hosted externally, including SaaS services or partner and supplier integrations.
Two significant examples of these types of supply chain events in 2020 and 2021 included the SolarWinds attack (targeting the Orion product) and Microsoft Exchange Server attack. In both cases, we saw where APIs were either a significant component of the attack chain or the initial attack vector. The Biden administration attempted to call out these risks more explicitly and create greater focus around digital supply chains with the Executive Order on Improving the Nation’s Cybersecurity. We’ve provided separate commentary on this EO, emphasizing the criticality of it and that organizations across industries must pay attention, not just public sector and government entities. The EO falls short only in that it emphasizes dependency chains and zero trust principles over some other security constructs such as machine assistance to stay ahead of the flood of security information most organizations face.
Industry focuses are still too narrowly scoped around traditional definitions of what a “dependency” is or producing a software bill of materials (SBOM). Typically, SBOMs include componentry used in application code, compiled binaries, and installation source files. Commonly used security tooling to identify such dependencies includes dependency analyzers, software composition analysis, and vulnerability assessment tools. Two problems arise with this approach though:
- SBOM formats have yet to be standardized or widely adopted, though SWID and SPDX show some promise.
- SBOMs should cover more than just traditional componentry and should also include APIs as dependencies. API enablement and API integration is how organizations design systems and form modern digital supply chains.
Attackers target infrastructure APIs such as the ones contained in Exchange and SolarWinds offerings, but also other infrastructure elements like Kubernetes. Salt Labs identified two other examples with Elastic Stack and Log4j. Many organizations still struggle to address all customer and partner APIs, let alone these system APIs that ultimately are part of their attack surface. Controlling internet exposure of such system APIs can be difficult. Attackers continuously seek to bypass infrastructure and network security controls to pivot in their attack chain. Organizations seeking to limit the blast radius from such attacks race to adopt workload protection tooling without considering the bigger picture of how all security controls must work together across all layers of their technology stacks, particularly the application layer. Zero trust architecture (ZTA) principles are also being rapidly adopted to limit potential blast radius. ZTA can appear simple at first but is difficult to implement fully when you consider all potential API call sequences, first-party integrations, and third-party integrations.
Complex attack chains are not easy to identify. One particular step of an attack chain may create a visible, anomalous sign, such as a log entry in a given server or environment. However, collecting these events and correlating them to provide useful signals is much more complex. Such subtle signals can quickly get lost in the noise of normal user behaviors and systems operation. Proactive, real-time diagnosis requires machine assistance that can analyze behaviors of both user and machine identities throughout an entire session for anomalous and potentially malicious activity.
2. Organizations will continue to shoot themselves in the foot with authentication and authorization
Authentication and authorization are core components of Identity and Access Management (IAM) and foundational to all security domains. This prediction will hold true for a few reasons:
- IAM by itself isn’t enough to address all aspects of API security, and many attacks occur in authenticated sessions over trusted connections.
- Implementing effective IAM across first-party and third-party services throughout computing environments is anything but trivial.
- User identity is barely solved within most organizations, let alone machine identity and automation (e.g., secrets management) where a machine process can’t be challenged in the same way or interactively like a user can.
Many analyst advisory sessions on API security were deeply rooted in questions about IAM and access control. Fielding such requests often required assistance from colleagues who covered IAM since it’s an incredibly deep topic unto itself. Such advisory sessions often included questions around protocols like OAuth or what API gateway or API management suite is most capable. While finding answers to such questions can be a valuable use of time, an organization that uses IAM as a sole approach to API security will suffer API incidents. It was my duty to advise them that even if they could employ all types of access controls, it would not absolve them from the risks of API attacks. They would need more.
Attackers regularly obtain authentication credentials through sanctioned means, or they target users, endpoints, or application code to achieve the same result. Once they obtain the necessary authentication material, access control approaches often fall over. And authorization mechanisms are almost always fertile ground for abuse, hence why BOLA and broken function level authorization (BFLA) rank as high as they do on the OWASP API Security Top 10. It’s difficult for any organization to implement strong access controls for all its first-party and third-party services. At a minimum, multi-party integrations result in increased complexity and likelihood of misconfiguration. Even if an organization can successfully implement an entire spectrum of conceivable access controls, it will border on excessive, in turn inhibiting user productivity and API availability.
Organizations can make a number of mistakes in the area of IAM despite best efforts. Every organization is unique with respect to its overall architecture and use cases that complicate matters further. Common problem areas include setting OAuth scopes too narrowly (fine-grained) or too broadly (coarse-grained), not accounting for inner APIs as well as outer APIs, limitations of the OAuth protocol itself, unvalidated redirects to malicious third parties, and balancing the trade-offs with session binding and impacts to mobility. Making matters worse, application teams are often tempted to embed API keys in code or configuration or make use of static authentication values to simplify systems integration and automation use cases. GraphQL adoption is also increasing for front-end design, but authentication and authorization are even more complex in GraphQL designs and with nested queries. This aspect in turn raises the potential for BOLA, BFLA, and BUA flaws, as Salt Labs highlighted in another recent threat report on GraphQL. Strong access control requires a combination of adequate authentication and authorization as well as anomaly detection to continuously analyze what users and machines are doing within an authenticated session. Such an approach underpins zero trust architectures that are now promoted heavily in cybersecurity.
3. Another major brand will expose data and suffer significant reputational damage
Incidents have become a regular occurrence for social media services with significant exposure of sensitive data or mistakes made around authorization controls. Data within these services often fits the model of personally identifiable information (PII) or personal data as defined by GDPR. In some cases, some data are designed to be open or public. Anonymous access to data may even be deliberate depending on a given business case, but how that data is in turn by API callers can be undesirable or malicious. Even in cases where data access requires authorization, inherent risk still exists from malicious actors that will aim to scrape, aggregate, and correlate massive data sets. A piece of data by itself may not be strictly PII or privacy-impacting, but grouped together, such data can enable an attacker to uniquely identify an individual or citizen. Erosion of privacy isn’t just a nuisance for employees, customers, and citizens, such an event also leaves hosting organizations subject to penalties and fines under regulations like GDPR.
Leaky APIs resulting from weak access controls and excessive data exposure will continue to persist across verticals. Impacted organizations historically don’t acknowledge the vulnerable APIs and data exposure. The public often hears defenses such as “the attack did not result in a data breach” or “the APIs functioned as intended.” The end result is the same though, attackers sit on troves of data that at best are massively privacy impacting. At worst, attackers use the data to target individuals with phishing, social engineering, pretexting, fraud, and more. LinkedIn, Experian, Peloton, and others have all suffered incidents involving leaky APIs. The regulatory impacts of such events are still being measured, and brand damage is also difficult to gauge.
The definition of data breach is more rigid than some parties would care to admit or as regulation spells out. Traditionally, data breaches are defined as events where servers or networks are infiltrated by attackers, and data in turn is extracted or exfiltrated. The attack landscape has changed and breaking into infrastructure is no longer a prerequisite for attackers because APIs expose functionality and data of value by design. Scraping is just as damaging as a traditional data breach, and such abuse often occurs through legitimate API endpoints, from authenticated callers in authorized sessions and trusted channels.
Companies are effectively dodging bullets and penalties for the time being, but public opinion will shift. Drafting of privacy regulation and updates to existing regulation is also accelerating. Depending on where they do business or citizenship of users, many organizations face restrictions and penalties outlined by CCPA, GDPR, and LGPD with more to come. Privacy requires a different mindset than data security or application security. Organizations are in early stages of hiring for privacy roles. In the meantime, APIs are still being regularly built or integrated that could be exposing personal data.
Get the comprehensive list of best practices to guide your API security journey.
Download Now4. Governance and compliance teams will take a seat at the API security table
With any information security program work, multiple personas handle the array of security processes like defining requirements, documenting designs, classifying assets data, standardizing processes, testing code, and protecting assets in runtime. As part of most security programs, organizations invest significant security manpower or budget into governance, risk, and compliance (GRC) elements.
API security will be further scrutinized outside of the traditional roles like application development, API product, and application security as it stands today. We see these signs already with some Salt customers and mature API programs. Internal GRC teams as well as external auditors are taking a deeper interest in the language of APIs as it ultimately impacts all elements of an information security program. Many standards and regulations already call out specific functionality or data that must be adequately protected to ensure compliance. A common example is citing the OWASP Application Security Top 10. These standards and legislation will continue to see revisions in parallel to call out the language of APIs more specifically, even if it’s as simple as also citing the OWASP API Security Top 10.
The Payment Card Industry (PCI) Data Security Standard (DSS) is sometimes cited as one of the most prescriptive standards with respect to technology and security. Bearing in mind that it is a standard and not regulation, any organization that handles or stores cardholder data is effectively bound by the standard or face fines for violations uncovered as a result of a breach or during periodic audits by a qualified security auditor (QSA). For years, requirement 6.6 has stated with respect to “public-facing web applications,” organizations must either:
- Test annually or after every change using manual or automated review from appropriate security testing tools (separate from network vulnerability scans)
- Deploy “automated technical solutions that detect and prevent web-based attacks” with web application firewalls cited as an example
Many public-facing web applications are constructed of web APIs that power unique business logic and facilitate data exchange. Organizations historically invested in WAFs, API gateways, or even runtime application self-protection (RASP) to satisfy this requirement to protect public-facing web applications. Such controls not only are ineffective against most API attacks, many organizations also leave their instances in passive (or alert only) mode. Efficacy of rules, signatures, and threat protection filters is one matter, but if these security controls aren’t actively blocking, they are little more than an exercise in checkbox compliance.
Matters only get worse if you dig into a data protection regulation like GDPR. To mitigate against attacks that can result in data exposure, data inference, or privacy erosion, traditional security controls do little to satisfy compliance. Protection for data at rest is often achieved with encryption, masking, tokenization, or pseudonymization techniques. Protection for data in motion is often achieved with transport protection like TLS. However, protecting data in use (or misused and abused) is a much greater security challenge.
Auditors will begin to ask more questions around API security and also demand more from nonsecurity and security teams. Security and nonsecurity teams need capabilities that satisfy a range of criteria for API security tooling as part of defensible security programs. While automated security protections from WAFs may have been enough to achieve PCI DSS compliance, API security demands more. Security standards and regulations will begin to call out the need for automated protections throughout the life cycles of APIs and the data they serve. Integrity of a system and the APIs that power it can only be assured through automation and machine-assistance. This requirement will likely be tied to formalized CI/CD build pipelines as systems of record, an effort already underway in must organizations as part of DevOps adoption. Such approaches also benefit (digital) supply chain integrity which was a cybersecurity focus of 2021 that will continue.
5. Security Operations teams will seek more API visibility and context
Security Operations (SecOps) is the core of most cybersecurity programs. Infrastructure security, vulnerability assessment, and vulnerability management are often prevailing focuses. Security teams must identify vulnerabilities (usually as CVE-IDs), prioritize which security issues are most critical or business impacting, and track remediation to closure. In some mature organizations, these teams are embracing newer technological approaches like containers or infrastructure-as-code. For most though, “patching” is often still common vernacular, and worlds collide when it comes to homegrown code or external API integrations. It’s on the owning organization or third-party to fix underlying code or configuration. It’s also not a given that a security vulnerability or weakness will be a matter of updating commercial applications, open-source software, or open-source componentry. SecOps teams often lack expertise in application layer problems, and practitioners rely on application teams for that intelligence. This reality often leads to a backlog of vulnerabilities that are either inconsequential to application teams or siloed communications as each team sticks to their own processes to avoid business interruption.
Security operations center (SOC) analysts must analyze large troves of log data from all networks, systems, and applications to continuously detect a wide spectrum of potential security impacts to an organization, a proverbial needle in a haystack. It’s a monumental task since potential security incidents include phishing, ransomware, malware, vulnerabilities, misconfigurations, and design weaknesses across all the layers of technology stacks and originating from a variety of threat actors that can be external or insider. These teams often lean heavily on their security information and event management (SIEM) tools to aggregate and prioritize all the event data.
SIEMs aren’t built with the necessary capabilities to analyze all event types, translate that information into actionable insights, and help prioritize security efforts accordingly. SIEMs are still firmly rooted in the world of infrastructure security, not application security let alone API security. Too often, organizations dump data into their SIEM instances without consideration for how an issue manifests itself, how best to remediate or mitigate given issues, and what respective workflows exist for affected parties. Many SIEM modernization efforts focus on the converse of reducing the number of log dumps or data feeds to improve false positive rates and responsiveness. Security orchestration automation and reporting (SOAR) was supposed to ease some of this burden, but much of what has materialized is only partial automation of traditional incident response processes. The expectation for many practitioners is that cybersecurity requires a great deal of manual effort with tuning, defining security use cases, and codifying that in some way into SIEM or SOAR.
As API security incidents continue to trend upward, SecOps teams will express interest in proactively identifying API-related flaws that can potentially lead to beaches or exposure for the organization. Practitioners desperately need tooling that can integrate across security technology stacks and provide intelligence in the language of both security and nonsecurity teams. Organizations effectively need a translation service to bridge these worlds and account for different work streams to avoid wasted cycles and impacts to mean time to detect (MTTD) and mean time to repair (MTTR). If application teams care about the OWASP API Security Top 10, and SecOps teams care about MITRE ATT&CK framework, where is the connective security tissue? In reality, effective API security and cybersecurity requires machine assistance to provide critical API context that also works in tandem with SIEM, SOAR, IT service management (ITSM), defect tracking, and other tooling found in most enterprises.
6. Organizations will start recognizing API security as a distinct domain from DevSecOps
Shift-left focus, a big component and focus of most DevSecOps efforts, is too narrow to cover all aspects of API security. API flaws can result from misimplementation, misconfiguration, poor coding, unexpected misuse. While it may be possible to identify some subsets of API issues in design, development, and build stages, business logic flaws will not manifest themselves until after applications and APIs are delivered. Conceivably, delivery can be made to non-production infrastructure to undergo a period of runtime analysis prior to production deployment, but API code still must be running and properly exercised to identify security flaws. The reality for most organizations is that production mirrors are lacking, or security controls aren’t deployed in pre-production environments (where most testing is run) which can skew results.
The pitfalls of most DevSecOps approaches and shift-left will persist. Some organizations quickly realize they can’t test all their own first-party code, let alone have access to third-party code since it’s not their intellectual property. Partner APIs and third-party SaaS are likely hosted entirely external to the organization and obtaining consent to assess such functionality is often a non-starter. Good code coverage and test coverage is difficult to achieve with most automated scanners and linters. Testing complexity is often too much to handle for security practitioners, even for those organizations fortunate enough to fully staff dedicated application security teams.
Organizations often embark on shift-left initiatives with the notion that their production security is “good enough.” Such mindsets result in overconfidence in the security efficacy of network access controls, IAM, API gateway threat protection, and WAF signatures to provide API protection. While these mechanisms are the typical candidates for “shield-right,” API runtime protection needs more. These technologies fail to provide full API context or analysis of API behaviors. Organizations often exhibit a disconnect between application security and network security teams for maintaining production security controls. It’s a given that any of these security controls will not be tuned effectively for a specific application, let alone underlying APIs.
DevSecOps maturity requires DevOps maturity. Purists will argue that security should be inherent, and DevOps “done right” is secure. Pre-requisites of DevOps are many, and few organizations are skilled in all areas for all applications in their portfolio. Some DevOps foundational elements include test automation, codification of infrastructure as well as configuration, containerization, virtualization, git-based version control, formalized CI/CD, and well thought out feedback loops for all IT personas. I have yet to encounter an organization that does it all well, even those companies born in the cloud. Mature CI/CD practices and DevOps-style releases can help with quickly spinning up environments, testing, and tearing down or rolling back if issues are found, but few organizations are this advanced today.
Along with this separation of API security from DevSecOps, application security teams will evolve to assume these responsibilities or API centers of excellence will emerge to help get a handle on their organization's API attack surface. Companies will slowly realize API security requires its distinct security strategy, which in turn can provide some benefits to DevSecOps programs. The pendulum will swing back as more mature companies realize the limitations of shift-left and restore more balance with runtime security. We’ve already seen it in some cases within FinTech. It is a sign of API security maturity to recognize security is not all about testing pre-production, and balance must also be achieved with runtime security. This strategy is sometimes referred to in industry as “shift-left and shield right.” Security must be well thought out (not bolt on) and promoted, integrated, and automated in all phases of the API life cycle, not just existing on the “left side” or “right side.”
7. Security automation gains favor as organizations wrestle with a continuously shifting attack surface
DevOps practices aim to achieve processes and delivery that are codified and repeatable, which in turn benefits automation and accelerated release velocity. Security testing and runtime security must also fit this model. Much like the transition from waterfall to agile methodologies, organizations will start to further embrace integration and automation of security services. Organizations looking to deploy API security tooling will seek those capabilities that are fully API-enabled to fit this paradigm so they can integrate effectively with their existing toolchains and processes.
Rarely does an organization know all the APIs that it’s building, integrating, or consuming. Assembling and continuously updating API inventory is just one critical element of an API security strategy. Knowing all the ways an attacker can potentially target, exploit, or abuse those APIs and deploying appropriate runtime protections or mitigations is another piece of the puzzle. Machine assistance is the only way organizations can get ahead of the API security curve and flood of code changes, partner integrations, third-party code, and data in motion.
Manual security control through manual review or manual configuration of a mechanism like a WAF, slows down application and API releases. Manual process is the death knell of business but also a surefire way to destroy a security program before it can prosper. Slowing or stopping a release for security reasons can result in other business impact, and it also creates the perception that security is not an enabling force for the organization. As many CISOs will attest to, fighting for security budget or headcount is already challenging. Disrupting engineers and workflow is also a surefire way to quickly kill off any security project. Manual security approaches also inhibit the ability of the organization to quickly detect and respond to API incidents, which ties in with the other 2022 prediction that SecOps teams will seek API visibility. Expert intelligence powered by machine-assistance can produce useful signals, in the right language, for a given persona.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
