ICYMI: Get caught up on Part I
PART 2: INTERNAL THREATS
According to Gartner, by 2022, APIs will become the most frequent attack vector, causing data breaches for enterprise web applications. The shift to the API as a prime target has occurred for a several reasons that can be categorized into either external or internal threats. In this blog, we'll take a closer look at some of the internal ones, including:
APIs Designed Without Security In Mind
Many organizations harbor a security next mindset, encouraging policies that "get to the problem later", or are reactive vs. proactive ("We don't have that problem yet, therefore we're not taking steps to prevent it now").
When it comes to API vulnerabilities, the problem already exists, and a security next mindset puts the organization at risk.
In the early stages of API development, there is often a greater focus on functionality over security. Developers are usually buried in backlogs that prioritize the development of new features or functions over remediating security concerns.
Strict deadlines for production also force development teams to make compromises, negatively impacting proper documentation.
These are example areas of where the security next mindset begins to manifest itself.
To determine how pervasive a security next mentality is within an organization, it's important to understand how long certain issues have persisted within the development backlog. The greater the timeframe, the more apparent the security next mindset is. In the context of API Remediation, organizations should strive for a clearer overview of these timeframes, and seek to reduce them as much as possible.
Lack of Confidence in API Inventory
Lack of confidence in the organization’s API inventory is widespread, with a fifth of survey respondents having absolutely no confidence in or knowledge about the completeness of their API inventory whatsoever.
A lack of confidence creates mistrust and uncertainty for developers. If developers do not have full access to or a complete understanding of existing APIs, they are more likely to unnecessarily create a new API when an existing one could be used for the same purpose.
Extra or duplicate APIs that are created in this manner make the attack surface for hackers even larger. It increases the surface area for bugs, security issues, performance problems, and increases work for the product team.
With backlogs and work already at a high, it's in the best interest of development teams to avoid unnecessary duplicate work where possible and simultaneously lower risk in the process.
Shadow, Zombie, and Misconfigured APIs
Shadow APIs
Shadow APIs are a category of backend APIs often hidden from the views of traditional security tools and API gateways. These undiscovered APIs often run on ephemeral infrastructure in the public cloud. They can be hard to find and legacy security tools don't provide insight or protection. Typically, they represent a significant risk because they often expose PII or other sensitive data and put a company at risk of data breaches.
For each well-defined API, there are potentially dozens of shadow APIs that represent a growing cybersecurity nightmare. If left unchecked, it's merely a matter of time before these APIs are compromised.
Zombie APIs
Similar to Shadow APIs, Zombie APIs are often hidden from the views of traditional tools and methods. Zombie APIs are deprecated APIs that are assumed to have been disabled. Instead, they lurk in the background uncontested and under the radar. Any undocumented API can pose a threat to the organization and increase the odds of a vulnerability being exploited.
Misconfigured APIs
Misconfigured APIs are APIs that function or operate in a manner not fully intended by the development team. Misconfigured APIs accounted for the vast majority of security incidents in the cloud last year.
Traditional security solutions have a hard time offering protection in a world of cloud APIs. Standard WAF technology has not been able to keep course with innovation in this area, especially when it comes to organizations that are operating in complex, multi-cloud setups across multiple cloud environments.
There are plenty of challenges that need to be addressed in this area. Ideally - with a growing number of threats on the landscape — efforts need to be doubled.
Broken and Inefficient Processes
APIs represent an intersection between two or more applications but they can also represent the intersection of two or more business processes. If this intersection is not well-designed it can create a weak point in the architecture and generate increased risk to the business.
For example: if a consuming application does not get 100% of what it needs from an API, the owner of that application will make an adjustment and look for other APIs that can help fill this gap. Here, a need is created for additional APIs, adding to complexity and to the available attack surface.
Challenge: A Lack of API Ownership
Another challenge is the constant movement of individual employees in and out of the organization and the constant reorganization of individual business units. This flux makes it very difficult to maintain a clear definition of API ownership.
Without an individual having a specific mandate to track the usage of a specific API the API is theoretically left unguarded.
Challenge: A Lack of Standardization
In order to develop a complete picture of risk the organization needs to adopt a number of standards. By standardizing the definition of risk, conformance, adoption, etc. the organization can allocate the proper resources in a manner which is more organized and thoughtful.
The effort to adopt these challenges can face several hurdles. This is especially true if the development organization is highly fragmented or has grown through merger or acquisition.
If the overall data collection effort is inefficient or fragmented the cause is likely broken or inefficient business processes. This forces those involved to find work arounds which can also increase risk. If this is the case, these broken processes need to be closely examined and if necessary remediated.
Coming Soon: Addressing API Vulnerabilities in 2022: Part III
Introducing ReactFirst: Security for the new API Economy and the pace of modern business. ReactFirst is an award-winning, comprehensive API threat remediation solution that goes beyond technology to help minimize the threat caused by API security vulnerabilities. Learn more at reactfirst.io
Comments