Command-and-control centers are growing in popularity as API Remediation elevates from a technical problem to a business-critical one
According to McKinsey: "In many cases, a rush to build APIs without a thoughtful strategy has created a mess, with redundancies, poor maintenance practices, and limited transparency."
But how big of a problem is this?
According to OWASP, 3-5% of APIs contain security flaws. This figure may be low, but 3-5% suddenly represents a significant risk to the organization when multiplied by the number of known APIs. For example, an enterprise with up to 4,000 APIs could see as many as 200 known API vulnerabilities.
The concept of a known API is important to understand. APIs constantly evolve, priorities frequently change, and developers come and go. This constant flux opens the door for Shadow APIs - undocumented and untracked APIs - to hide in the background, representing a hidden danger as their vulnerabilities go untested.
OWASP has also found vulnerabilities in as many as 55% of the APIs they've tested. Now imagine applying this level of vulnerability to the 4,000 known APIs, and 1,000 shadow APIs: there's could be up to 2,750 vulnerabilities at play.
"Shadow APIs - undocumented and untracked APIs - represent a hidden danger as their vulnerabilities go untested."
Remediation of these APIs is critical. But when it comes to fixing them, development teams are often forced to compromise, balancing technical debt with the pressure to add new features. The constant change involved and the growing complexity keeps the door open for an increasing amount of risk.
The only way to understand the true scope of this problem is to implement a concerted effort to collect, organize and analyze information from each of the systems involved. With the proper perspective, the organization can get a better understanding of the overall risk.
Why an Ad Hoc Approach Just Doesn't Work
Without a program office approach, API vulnerabilities are addressed on an ad-hoc basis. For many organizations, this means transferring ownership of the vulnerability to the API owner to make any necessary fixes. While it may sound logical in practice, this approach generates great concern in it's inability to answer some basic yet necessary questions:
Who actually owns the API?
In some organizations, understanding API ownership can be a challenge. Without a strict protocol in place, answering who owns an API requires a great deal of detective work.
Determining ownership is a manual, tricky, and often lengthy process. Sometimes the person publishing the API may not be the one who created it. Other times, the person who did create the API in question may appear in one part of the org chart, but have a dotted line into another. Or, frequently, the employee who created the API is no longer at the organization.
How long has the vulnerable API sat in the development backlog?
The development team is constantly grappling with a backlog of work, meaning API remediation efforts will always compete with this. Is remedying this API a priority for the group, or just for the individual that owns this problem? Is this technical debt continually kicked to the curb? The length of time that vulnerability stays in a specific state is a KPI worth introspection.
What level of risk does this unresolved issue pose?
Without a protocol to score APIs by risk level and quality, the scale and scope of the problem remain hidden. Different development teams may also define risk and quality in their own ways, further complicating matters.
Is there a conflict of interest?
An old proverb suggests that you cannot leave those who created the problem in charge of the solution. The same is true in this scenario. Given the above concerns, it may make sense to charge this task to a different authority.
Are there incentives in place to fix the problem?
Is the development organization incentivized to place technical debt ahead of the development of new features? How does the organization balance this effort given its competing priorities?
Does the development team have the right tools?
Most (if not all) of the tooling applied to this problem focuses exclusively on identifying the existence of a problem. Cybersecurity tools focus on monitoring network traffic patterns. API vulnerability tooling focuses on testing APIs against predefined standards. Identifying the problem is only half the problem. Fixing APIs can be a strenuous, time-consuming effort. Remediation does not happen overnight. Tracking this effort requires a different approach and a different set of tools.
Does the development team have the right skills?
Developing a data platform to analyze and track remediation efforts takes a variety of skills. The development team could build a solution, but it would require taking them away from their core duties. Additionally, the development team would also have to bring on the skills of project management, architecture, communication, and support desk teams.
Individual or ad hoc attempts at fixing vulnerabilities will almost always be outpaced by the growth in new APIs and the speed at which hackers operate. Given the scope, scale, and threat of the problem, a better approach is warranted.
How A Program Approach Can Help
A program approach establishes a cross-department command and control structure purpose-built to solve the problems around API Remediation. At it's core, the Program Office (or task force) is supported by executive-level sponsorship, generating the right amount of incentive for each of the stakeholders involved, and helping to create a sense of urgency across the groups impacted by this effort.
The Program Office is supported by a number of skilled resources such as data engineers, data scientists, architects, and design experts. These skills augment the organization's efforts by bringing experienced resources from various backgrounds to help solve this problem.
Lastly, the Program Office relies on a central platform designed to house the data necessary to support decision-making and operational transparency. The platform provides a pre-designed metadata model, template dashboards, and reports to accelerate the effort, helping to produce critical analysis far faster than developing from scratch.
Program Capabilities
The goal of the program is to create a single pane of glass perspective so that stakeholders can understand the current state of API vulnerability risk. To make this a reality, the scope of the program includes:
Definition of KPIs related to API quality and risk
API security audits and assessments
The creation of a central API catalog
Integration with API gateways and other API-related systems
Summary and detail level dashboards
Administration and support dashboards
Management of backlogs and work efforts
Feedback collection (surveys, attestations, status updates, etc.)
Communication and outreach
Open office hours support
Additional Benefits
Having a trusted, searchable repository for API-related information creates additional opportunities for the organization, including:
Shorter Development Times
A central API catalog gives developers greater trust in API inventory, allowing them to find up-to-date information and answers faster. Armed with this capability, developers should significantly reduce the number of duplicate APIs produced.
Composable APIs
Product managers can now group APIs to form composable APIs and help provide substantial value to API consumers.
Strategic Reporting
Organizations can map API usage to strategic program goals, fine-tuning how they utilize precious development resources.
Smarter Decisions
With faster access to reliable data, decision-makers will be able to make smarter, data-driven decisions.
Strategic Importance
APIs are becoming critical assets that the organization must effectively manage. Developing greater insight into the use and availability of these assets can become a distinct competitive advantage.
Summary
Establishing a Program Office within your organization helps bring together the required combination of capabilities to appropriately address the risk caused by API vulnerabilities. Instead of merely identifying problems, it tracks the organization's ability to resolve them, providing a command and control structure that delivers the necessary insights and accountability to see each vulnerability move through the remediation process. This program is backed by executive sponsorship, supported by cross-industry experts, and enabled by state-of-the-art technology. If you feel this program approach may be beneficial to your organization, talk to us: