Initial Publication Date: 30 September 2019

Abstract

At TechVision Research, we see the management and security of Application Programming Interfaces (APIs) as a core and strategic competence supporting the evolution towards the Digital Enterprise.

APIs are used as part of the glue across almost all types of application development environments supporting the integration of cloud-native, mobile, enterprise, line of business and consumer applications. Done right, API management and security support a well-managed Digital Enterprise and enable the rapid delivery of scalable, integrated and flexible applications. It further allows an enterprise to offer internal and external developers consistent, efficient and secure access to a growing suite of digital capabilities.

This report is an Enterprise level-set on how APIs are used, managed, and secured within, across, and outside organizational and technology boundaries. This report is not a vendor review, focusing rather on the core elements of API management and security as applicable to the enterprise. While traditionally considered a highly technical discipline supporting developers, APIs can now support almost functional requirement or role in an organization, with many useful APIs now widely available.

The movement from monolithic applications to distributed and modular component-based services and the need to integrate/orchestrate these services through APIs, creates large operational and security challenges. These new points of access, controls, real-time signals/metrics, and rapid feedback loops are just a few of the requirements that security teams face in cloud-native environments and the focus of this emerging category of API management and security

This report starts by looking at the basic components and use cases for APIs and then discusses the basics of API management and security. We then describe a reference architecture approach and highlight solutions for common enterprise use cases. Finally, we look at the future of API management and security concluding with a set of recommendations for best practices and next steps.

Authors:

Archie Reed Principal Consulting Analyst [email protected]

Executive Summary

The rise of application programming interfaces (APIs) and their usage across the business landscape has accelerated over the last decade as cloud-based deployments, mobile applications, microservices, and easier consumption of external services have become more standard – usually growing alongside migrations to the digital enterprise and hybrid IT architectures. APIs are certainly not new to most software developers, being the way in which most capabilities within systems are accessed. More recently, APIs are increasingly used to access data or business functions directly from applications used across the business. The rate at which this is occurring means that API Management and Security needs to be an ongoing effort on behalf of your organization.

The rapid rise of cloud architectures has had a profound impact on most organizations’ security posture and operations, increasingly encapsulated under the banner of SecDevOps – short for Secure Development and Operations. This is also widely referred to as DevSecOps. These distributed architectures and the dispersion of security and logical control points can create unpredictable dynamics and unanticipated points of failure. This can be a challenge for organizations operating primarily in a command-and-control manner, and even still dealing with the implications of DevOps itself.

As the usage of internal and external (third-party) APIs dramatically accelerate, the management and security of these environments becomes increasingly more challenging. However, when done well, API management and security allow an organization to move faster and more efficiently to deliver valuable capabilities to their audience. With the move from monolithic applications to distributed and modular component-based services well underway, the need to integrate through APIs creates large operational and security challenges. Simply, these new points of access, controls, real-time metrics, and rapid feedback loops are just a few of the requirements security teams face in cloud-native environments.

It is most likely that you or your partners are offering some services through APIs, and similarly, API vendors are now your partners. The right management and security of API usage in an organization helps deliver and support agility, adaptability, scale, and all the good things organizations need to be successful today.

The fact that the number of APIs offered and consumed in actual use cases has seen such growth means most organizations must consider comprehensive management and security of APIs to reduce risk to their business. Aligning your API security and management with your business priorities in terms of risk, value, and delivery is therefore critical. This is a classic security challenge of managing the CIA triangle of Confidentiality, Integrity, and Access: all of which require a level of balance between the requirements to create business value.

Organizations that wish to speed delivery of digital services, expand their offerings, and succeed with digital modernization programs often fail to recognize the benefits or deliver secure value to their internal teams and external partners by allowing their value (using in data or faster delivery of services) to be made available through some API-like service offerings.  This is a key reason to apply Zero Trust Networking to your approach. Take the stance that every operation via API call, whether for access, query, update or otherwise, is based on a least-privilege model and requires validation throughout the transaction based on validated credentials, and as many contextual data points, for access and authorization. Contextual information ranges from information like time-of-day, location, type of request history, and many more. To learn more about Zero Trust Networking, refer to our report by the same name for a more in-depth discussion.

At the same time, without the proper API management and security, companies that expose or access APIs are vulnerable to malicious or erroneous actions. APIs become a target for bad actors attempting to access and then exploit your data or services. Simply, as your organization grows, so do the number of partners that you are likely to transact with, and that risk also grows and applies to them. Consider the rise of Salesforce.com in many sales groups. Its use and growth were seen as a Shadow IT type initiative, yet today is considered almost a de rigueur choice for sales force automation. Similarly, when embedding online maps, one can pick from Google, Bing, Open Street Maps or otherwise, which we often see in the online presence of most organizations. In these cases, the ownership, accessibility and permissions have changed multiple times over the years, directly impacting the businesses that use them. The use of APIs in applications has risen from a developer-only technical club to an open slather where almost any spreadsheet user, workflow designer, smartphone owning individual can start using them with little effort. Like Salesforce, the initial costs seem minimal. Yet, in the same way, the use and exchange of data through them is often done to gain their immediate benefits, with little IT or security knowledge, while little consideration is given to the long-term costs or potential negative impacts (e.g. whether critical information security may be affected.) The responsibility for secure and appropriate consumption of an API cannot be delegated to the consumer – the provider must ensure their API implements appropriate information security measures.

We find that management at multiple levels is often unaware of which APIs are being used within their organizations. Often viewed as a purely technical area of expertise, APIs can be messy and overly complex. Raise your thinking around the value these APIs provide then the business importance becomes clearer, and concern for the potential security risks associated with that API usage also becomes clear. As such, API Management and Security should be a critical part of your enterprise strategy.

Key Recommendations

Critical undertakings for enterprises today include:

• Incorporate API Management and Security into your standard business processes and functional groups:
  • Security
  • Architecture
  • Development
  • Training
• Audit existing API usage across your organization
  • Internal
  • External/Third-party
• Implement an API Management and Monitoring capability with appropriate tooling
• Apply a Zero Trust security model to API usage for your organization
• Clearly define and publicize your API strategy across the organization

We will explain each of these recommendations in greater detail in this report.

Introduction

Application programming interfaces (APIs) are managed integration points into an otherwise closed and inaccessible software system. They are defined, (hopefully) documented, and published, allowing for the owner of a digital service to enable another party to programmatically consume elements of his system, from within their own.

APIs are essential for executing ideas quickly and seizing new business opportunities. They are the building blocks for digital transformation that enable organizations to deliver exceptional customer experiences, create new revenue streams and connect employees, partners, apps and devices to data—anytime, anywhere.

The benefits are many and while not exclusively the vehicle, organizations that use APIs to integrate their applications and services can rapidly deliver on the promises of a Digital Enterprise. Consider Woolworths Australia, who at Google’s Cloud 19 conference stated they offer over 1000 APIs to their developers and partners, with transactions peaking around 480 per second at that time. Their business saw massive benefits being realized through their API management and security, including consistency in how interactions are developed and maintained across its different brands and businesses in the short term, and creating value long term through customer retention with more seamless digital experiences longer term. Of many key takeaways, the business’ digital group known as WooliesX consider APIs as the means for “forming a contract between consumers and services”. As a result, APIs are seen as business critical with a result that “…internally, every contract that we commit to maintains the same level of inputs, outputs and data formats as we once committed to all the way through the lifecycle.”

Some companies are increasingly basing their future-state business models on exposing services via APIs. Twilio, Segment and even Amazon Web Services (AWS), are a few examples, all of which offer APIs to manage and access their offerings. These organizations recognize that in the B2B space, the quicker and easier they are to support their customer or partners integration requirements, the better they are at becoming a part of the critical processes.

There are however clear risks with every use or exposure of an API. Misuse, attacks, abuse and more can occur. Consider the 2017 Blackhat conference where internal Netflix employees detailed how 3-4 requests via their own APIs could take down a entire data center – as reported in Wired[1]. Launching a domino effect across the Netflix microservices, the attack was well thought out and specific – but made via API calls by one of their own engineers, Scott Behrens.

As noted, “Behrens conceived of a different type of DDoS, one that turned Netflix’s application programming interface against itself. Netflix’s API acts as a sort of gateway to a complex array of middle and backend application services—all the stuff that happens under the hood. Behrens realized that an attacker could send a very small number of resource-intensive, carefully chosen requests designed to trigger more and more requests, cascading deep into the system. In this way, an attacker could easily and cheaply cause significant resource burden, and even take Netflix down.”

While management were aware of the staged attack, they did not let their internal ops center know it was coming. They handled it well, but the attack worked for a short time and the point was emphatically made. The reality today for many organizations is that these deep levels of integrations and services – all accessible via APIs, are becoming more complex and potentially open to such conceptually simple yet potentially catastrophic attacks.

A more well-known story is that of Cambridge Analytica, who raised a scandal in 2018 when it was reported that they were abusing their access to Facebook data, all through a standard third-party API, where they could harvest the personal data of millions of people’s Facebook profiles without their consent. Facebook has been forced many times to implement increasing restrictions and lockdowns of their API. This demonstrates the serious nature and value of API access, wherein the results of Facebook’s activities have forced some partners out of business, while others had to scramble to modify their usage of the APIs to move forward, albeit not on a timeline of their own choosing.

These examples show extreme cases that clearly demonstrate how APIs can have a significantly detrimental impact on business. While they are very public cases, they show that even at companies at the forefront of digital and API led services, things can go wrong. APIs act as a doorway to backend systems and data. Just like you lock your door at home and banks lock their doors at night, your systems and data need to have their doorways properly secured.

As such, API security is related to, but unlike security requirements associated with applications themselves. Your internal teams, your partners and customers have different requirements, especially in terms of usage patterns. APIs more often allow direct and rapid access to backend applications and data sources, even complex and critical business processes, and poorly designed APIs will create holes across your security plans.

The Basics

TechVision API Reference Model

TechVision Research details the following key components of an API Management and Security Strategy as detailed in the Figure 1: API Technical Reference Architecture and Figure 2: API Critical Components Reference detailed below:

Figure 1: API Reference Architecture

It is common to code up API Services and add business logic within that code, but at scale this approach can become unstable and non-performant. Splitting the API architecture into these key API components is recommended to optimally secure and mediate API traffic. Ensuring your API strategy includes effective management and control is essential to minimize risk and increase value to your organization. Key elements in API security require understanding the concepts of policy and identity management to ensure that the API management is comprehensive. Concepts of Policy Management, derived from the eXtensible Access Control Markup Language (XACML), also apply, and the core components in enforcing secure policies are architected using the following “points” in your architecture to support policy enforcement, policy decisions, supporting functions and management capabilities. For example:

• Policy Enforcement Point (PEP) – the location in architecture that enforces a policy decision such as whether an API call is allowed, whether by a known user or even anonymously. A PEP will use a PDP to determine what to enforce.
• Policy Decision Point (PDP) – the authorization engine, essentially a device and logic that makes a decision as to whether access is granted to a resource based on contextual data (e.g., time of day, type of call, and other data provided by a PIP).
• Policy Information Point (PIP) – is a resource that provides information to support a policy decision. PIPs are usually focused on name/value attributes, and stored in a database or directory, and the grouping of these attributes alongside any other data relevant and accessible to the PEP’s/PDP’s provides context for a policy decision. These are often also closely associated with a Policy Retrieval Point (PRP)
• Policy Administration Point (PAP) – this is the place where users, administrators or developers define their policies and push them out to the PEP’s and PDP’s

PEP’s and PDP’s are often tightly connected in the same device.

In our API Architecture, the following key API capabilities exist that should be part of your API Management strategy:

• API User(s) – An API User is the entity using or consuming the API. These represent the entities making an API request, such as the end-user, an application, a service, or an API Gateway, and additionally any of those acting on behalf of (legitimately impersonating) another API user.
• API Target(s) or Subject(s) – APIs are in place to call specific data, service, management or security capabilities. These are known as the “targets”. An API may also work on multiple targets – essentially a single call performing, separate, or multiple actions, on behalf of the API user.
  • An API may provide a single call with basic data being returned or be a complex business process that in itself calls and initiates workflows, data operations, administration tasks, and more, oftentimes through other APIs.
• Internal API (aka Private APIs)
  • Internal APIs are owned and managed by your organization to provide internal users and services to access internal resources and services. Internal APIs are created using internally validated, and sometimes custom, business logic.
  • A PDP and PEP may exist as enforcement points within the API code itself. This creates a very explicit control point, generally as a middle line of defense, lying between the caller of the API, and the target of the API execution.
  • It may be that these APIs do not have key or token-based access, however at a minimum, a Zero Trust approach would direct that this should be the case to reduce the risk as attacks are commonly executed from within the organization.
• Access APIs
  • These APIs are closely related to Internal APIs and are owned and managed by your organization to offer or act as a wrapper to access external APIs, such as partners, customers, suppliers or even governments.
  • Access APIs are essentially your 3^rd Party API for external parties.
  • Access APIs are often implemented to improve the speed and level of integration you have with external parties, whether new or an existing business opportunity.
  • It is important to understand that any external APIs you provide may also be used by your internal API users too. You can define API Policies that restrict such access however this often complicates your policy management.
  • A PDP and PEP acting as an enforcement point before actions are taken against the API target.
• External or Third-Party APIs
  • External or Third-Party APIs are owned and managed by parties outside your organization. These are provided to the market to allow access to a third-party method or service, whether data access, service delivery, process improvement, or integration.
  • An External or third-party API is a very common way vendors offer access to resources that are deployed internally to your organization such as an internally deployed ERP, CRM, or database services, and today, more commonly to “as a Service” solutions, cloud native applications.
  • It is critical to ensure that these APIs also rely on a known Identity and Access Management (IAM) model that can be managed by your organization, as well as have the enforcement decisions be based on the same model.
• API Gateway, or API edge services – Internal or external, these can provide one or more architectural “points” defined above, often acting as a Policy Enforcement Point, Policy Decision Point and Policy Information Point for all API usage. An API Gateway can also provide any or all of the following functions to optimize the data flow and API usage: caching, routing, abstraction, transformation, compression, transformation, security enforcement, query optimization, prioritization, and audit/common logging. API Gateway capabilities may reside or be enhanced in other parts of the network under more common names such as DNS Services, Firewalls, Routers, Load Balancers, Web Application Firewalls (WAF’s), Application Delivery Controllers (ADC’s) or Content Delivery Networks (CDN’s).
  • Caching & Routing: An API Gateway can provide caching and best-case routing of calls to improve performance and sometimes optimizing for cost containment.
    • APIs can be called repeatedly, and especially at scale are often asked to respond with common or duplicate data. The ability to identify, manage, and optimize cacheable content can decrease load on backend systems/services providing the data services by determining the best way to obtain non-cached and non-cacheable content.
    • Dependent on the usage model, APIs can be called up and down the “stack”.
  • Abstraction & Transformation: An API Gateway can offer the ability to both simplify single or multiple API calls to other services by mapping an incoming API call and minimizing the data transfer across one or more other APIs. For example, a common approach to implementing GraphQL for an organization models multiple data calls from a single query to REST Object Models
    • Changing from one data model to another
    • Changing from one protocol to another
    • Aggregating calls inbound or outbound
  • Compression: An API Gateway can provide protocol translation such as SOAP to REST, XML to JSON, JSON to XML, and XSL Transformation.
    • An often-used model to save on transport time and cost is to compress data during transmission. Most endpoints have enough compute power to handle compression and decompression of data but knowing which data compresses well and when to use compression at all takes a considerable contextual awareness and understanding. Gateways that manage the flow of data, especially for API specific tasks, can determine the optimal timing and compression algorithms.
  • Query Optimization:
    • The gateway can provide and manage quota and rate limiting. The gateway will be a key element in your security posture.
    • Provides for preventing traffic spikes and potentially limit Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks.
    • Policy Enforcement of encryption tunneling e.g. forcing TLS.
    • Ensuring correct use of API security keys and abstraction
  • Audit and Common Logging:
    • The ability to securely capture and effectively interrogate (report) API usage is a critical aspect of supporting good Security Information and Event Management (SIEM). Any existing enterprise SIEM tooling should be integrated with your API strategy.
    • Capturing and analyzing usage and behavior models against an API helps to refine all aspects of your API deployment, from basic data usage through to predication models for better API behavior or new capabilities.
  • API Catalog
    • An API Catalog or API Developer Portal provides a list of APIs, documentation and usage models. Either in part or as the whole, the API Catalog can be internal or external or both. In addition, it is likely that your organization will need to use many of these, which means using third-party API Catalogs.
      • A good API Catalog will offer developers a method to search for APIs, understand their usage, provision access (or consume) them, especially via self-service portals, and manage their credentials.
      • Some APIs provide security management alongside their functional capabilities, and for scaled use, the need to delegated administration is critical, such that other groups can manage the API access. In enterprises this is commonly based on geographical, departmental, or functional groups. For commercial or partner services, the focus is on the customer or partner groups, however when you consume such APIs consider your needs for delegated administration across those user populations too.
      • It should be expected that the API Catalog will have a standard way to publish, document, and even deprecate APIs they catalog.
    • If you plan to offer access to your applications or services to other parties, API Management requirements should include how to best document, publish, version, and support analytics for those consumers, as much as you should expect that of those offering their services to you. You should also consider whether the catalog supports the ability to customize itself to support your organization through branding, and use of your security/IAM services (e.g., Okta, Ping Identity, ADFS, etc.)
  • API Analytics
    • Analytics are often included inside the catalog or gateway services. However, be aware that this can create challenges when attempting to understand your macro API usage. Unless your strategy is to rely on a single vendor, this often results in a requirement to focus on one vendor
    • The benefits of good API Analytics should inform:
      • API Abuse
      • Attacks such as Distributed Denial of Service (DDOS) or intrusion detection
      • Bandwidth issues
      • Opportunities for API or query optimization
      • API failure diagnostics
    • API Testing (and Development)
      • Whether consuming or offering APIs, it is important to be able to model and test them under as much of an automated continuous integration / continuous deployment (CI/CD) model as possible.
      • When planning to offer your own APIs, the complete API lifecycle includes API design, definition, modeling, development and testing, followed by the deployment
    • API Software Development Kit (SDK)
      • Although not specifically called out in the architecture, a good API will be wrapped with a Software Development Kit (SDK).
      • An SDK embodies a set of tools to develop with and in general include some level of documentation, sample code, test definitions, and often pre-written wrappers for multiple APIs.
      • An SDK is usually created to allow for much broader levels of functionality and even applications to be written in a standardized way.
      • The value of a good SDK is that it provides users and developers with those rules for creating within an environment and using the APIs provided.

Figure 2: API Critical Components Reference

In Figure 2 we detail the Business Roles essential to successful API Security and Management. Most new responsibilities are associated with the role known as The API Owner or API Product Manager.

Approaches to API management are different dependent on whether you are looking at internal vs. external consumption. This is primarily around requirements focusing on the ability to version control, flexibility of specifying protocols (esp. for internal consumption), and security requirements (logical or physical).

This also varies depending on the size and age of the company. For instance, startups do not have the legacy systems on which to consider. On the other hand, large organizations often use APIs to create new abstraction layers atop existing APIs, applications and so forth.

The mediation, transformation, and orchestration requirements can also create security risks as complexity is introduced through the tools and gateways being implemented; and, users of the APIs starting to treat API infrastructure as an ESB, which has a history of escalating complexity.

Several methods exist for enforcement of policies in the API space, and each has its benefits and risks. These are:

• Within the API itself, codifying the rules for data manipulation as part of the code you control. For example, you could choose to perform data aggregation of multiple sources within a limited API call.
• With an API gateway, codifying the rules for data manipulation using the gateway to perform the transformations. For example, a gateway could transform an API call from one standard to another, such as a REST API call to a SOAP API call. In many situations, this means that the gateway represents a border where security elements can also be managed. In these situations, the gateway also needs identity credentials, encryption keys and similar security privileges to perform tasks against API payloads.
• At the networking layer, routing or aliasing can be used. Common network-based solutions such as Content Delivery Network (CDN), load balancing, or proxy routing support optimal access and delivery of results.

Each choice should align with a change to your risk management wherein the associated risks are added.

The API Management Lifecycle

Whether consuming or offering APIs, management of those APIs requires a known process inside your organization. This allows your developers and users to manage their expectations on what they can expect, and what they need to provide in order to effectively and securely use the APIs on offer.

There are many Software Development Life Cycle (SDLC) processes available today, and TechVision Research offers the following outline which should map to any SDLCs already in use. These steps require alignment with your management and security strategy to effectively manage the ongoing API lifecycle – illustrated in Figure 3 as truly a continuous process.

Figure 3: API Management Lifecycle

The API Lifecycle runs through the following standard design steps supported by your management and security strategy:

1. Design – Determine the requirements and model the APIs based on your business requirements and technical strategy.
   1. At this stage you should determine whether or not any APIs already exist to support your requirements and whether direct usage or a wrapper may suffice.
   2. This step includes the effort to define, mockup and test potential API solutions.
2. Develop – Create the API via code or tooling and document the usage of the API.
   1. This step should also include your security requirements, integration and wrappers
   2. This step should also include your management tooling and integration
   3. If updating or wrapping/consuming an existing API, ensure it matches your management and security requirements.
3. Test – Document expected results and undertake functional testing
   1. Testing requires a clear understanding of the security model being used and testing that validates your security implementation.
4. Deploy – deploy or publish the API for usage.
   1. Ensuring your API is ready for publication with all suitable SDK elements.
5. Manage
   1. Monitor – When your API is in production the integration with your monitoring, reporting, and in many cases, your overall SecDevOps processes.
   2. Version – Iterate requirements and where needed, create updates to the API through version controls and then, when ready, retire the API.
      1. Versioning in most Software Development Life Cycle (SDLC) processes commonly uses a well understood semantic versioning scheme as best defined at https://semver.org/
      2. Tracking third party API versioning is critical to ensure you do not create security risks, encounter cost management issues, or loose critical business functionality.
   3. Retire – Closely linked to the management step is a plan to manage the retirement of APIs whether being offered or consumed.
      1. Considering this requirement up-front allows you to plan for a plan:
      2. How to handle communications for the retirements
      3. How to manage applications etc. that continue to request APIs.

Once your API Management Lifecycle is defined and documented, it too should be periodically reviewed for effectiveness. Strategic questions to consider are:

• Is your process current?
• Are the process steps positively supporting your use of APIs?
• Are the process steps negatively restricting your use of APIs?
• Have security issues, risks or understanding changed around how you are using or offering your APIs?
• Have your usage opportunities for alternate API’s changed – for example, due to pricing, availability, capability does an alternate API provide better capabilities?

API Management and Security ModelsAPI Management and Security is about protecting your business while taking advantage of APIs to accelerate delivery of integrated applications and services. APIs themselves, the messages (or content passed through them), and ultimately the services and backends they access are key to the API Lifecycle Management.

Ultimately, because the Digital Economy blends customers, suppliers, government, essentially any and all organizations in business value chains, it is critical that all aspects of your environment are well managed, and APIs are at the core of a majority of new developments. Further, with cloud, mobile, BYOD, IoT and newer technologies creating an increasingly fluid network perimeter, as illustrated in “Figure 4: The Zero Trust Network fluid network perimeter”, it is critical to apply the right IAM approach to APIs. Applying a ZT mindset is required to ensure security of API usage from end to end and it is likely is that this approach will evolve with your maturing of API management. To learn more about Zero Trust Networking, refer to our report by the same name for a more in-depth discussion.

Figure 4: The Zero Trust Network fluid network perimeter

API Types

While APIs in general allow you to programmatically access data and services through queries; the functionality provided, and the method used can differ depending on the goals defined.  Whether you are writing the API and enforcing how it is used, or answering a business requirement using an API, the decisions to make mostly revolve around how to secure the API, and what type of API format you will use.

There are many different “open” protocols that have been developed over the years for APIs, but we are a long way from the days of Electronic Data Interchange (EDI) and its variations, which have been slowly evolving since the 1970s. While the API itself remains as a standard way to transfer or access capabilities, data and services, many of the approaches to defining the standards around them offer different levels of “standardization”, resilience, simplicity, support and so forth. When looking at moving to cloud-native applications, most API usage models are based on one or more of the following standard technical definitions:

The most widespread API standards as of the writing of this report are:

• Simple Object Access Protocol (SOAP)
  • SOAP is a well-defined protocol based on XML along with explicit schemas to offer a “strongly typed” messaging framework. This means that every operation is explicitly defined along with the structure of the request and response for that operation. Within each operation each parameter is bound to an explicit type (e.g. integer, string, object).
  • The SOAP API is codified in the Web Service Description (aka Definition) Language and has extensibility via its use of WS* standards,
• Representational State Transfer (REST)
  • REST, which is a definition rather than a protocol like SOAP, is arguably the most common method to define APIs on the Internet today. REST relies on HTTP for transportation unlike SOAP which is format independent. REST is based on the client-server model, where each call must be considered stateless, cacheable, and scalable.
  • REST APIs often use an Object Request Broker (ORB) to map API operations to objects.
  • REST’s adoption over older standards such as SOAP, and like many Internet standards, was popularized due to its simplicity, closer alignment to open standards, efficiency, and speed.
• GraphQL
  • GraphQL is a query language specification for APIs originally defined and released by Facebook as they dealt with the limitations of the ORB CRUD operations expected of REST.
  • GraphQL offers a more flexible interface than REST in that it allows for queries across data objects, where the front end can define what data it wants returned, rather than the ORB approach of REST that applies CRUD operations to a tightly defined object which returns fixed data structures. Essentially GraphQL allows for a single query to be made to return information across object models rather than REST which supposes separate queries for each object type.
  • GraphQL uses a Schema Definition Language (SDL) to define the contract between the client and the server, defining how a client can access the data
  • GraphQL approaches also tend towards offering a single endpoint to call, which makes setup of calls simpler for developers.
  • GraphQL relies on a server-side runtime for executing its queries based on a strongly typed schema wrapping CRUD operations across defined data objects and fields.
  • The GraphQL runtime transposes operations into data specific queries across the data stores, which ranges from direct database queries through to another REST API.

Most API functional requirements focus on the following:

• Data – data management and manipulation, usually CRUD (Create, Read, Update, Delete) in form across the data and data management.
• Service – service manipulation to initialize, utilize and customize a service being used, physical or digital.
• Management – allowing for the management of the configuration, the service
• Security – tightly aligned with management, supporting the protecting the API and service provider, along with the lifecycle of access and identities for API services.
• Bulk – a variation on the functional requirements defined above, but used to optimize and perform actions in bulk with simple (usually single) calls (e.g. creation of new data, or creation of multiple accounts)

Some providers include all the above functions in a single API model definition and through a common endpoint, others such as SFDC and Microsoft provide multiple versions of APIs and a variety of endpoints depending on their own requirements.

Many API providers also provide wrappers for their APIs as part of a Software Development Kit. These might include Java, JavaScript, Python, C++, C# and other languages.

Similarly, tools that help define, test, manage and validate APIs also have SDK like components to include in your own tooling.

Core to applying Identity and Access Management principles to API Management and Security is to observe the entire Identity Lifecycle Management (ILM) process.

• Allowing your API users to be able to request, register and manage their authentication and authorization credentials (usernames/passwords or tokens) is critical to support speed and scale and is a fundamental aspect of IAM.
• The core element of APIs remains focused on who has access to what, when and why. This essential part of any API strategy from the ground up. The requirement for IAM to be in place to support account management, token management and lined up with security and policy management.
• There are many critical links between API Management and Security with Identity and Access Management. The TechVision Research Reference Architecture for IAM is a starting point; a master template, shown in Figure 5 below, identifies the IAM capabilities (not technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. [[See our report on IAM for in depth understanding of the TVR IAM Reference Architecture beyond our discussion around API

Figure 5: The TechVision Research Reference Architecture

Align your API Management and Security approach within this overarching architectural context or link to your existing security framework. This high-level template starts the journey at  the Interfaces Level (top), where applications use APIs to authenticate both the application and the user of the application through program calls that invoke Time of Access Operations such as Adaptive Authentication, Adaptive Authorization and in some cases, Federation and Privileged Access Management (recall the importance of using service account authentication and strong authentication within applications that access sensitive information or network resources).  

Critical IAM features in API Security:

• Providing secured, centralized and automated management of accounts, tokens and access for administrative, service and application accounts that are allowed to perform operations against your APIs. These types of functions are provided within the Time of Administration and Time of Change Operations illustrated above.
• Strong policy definition and enforcement of account/password and token policies – or, Time of Access Operations.
• Abstracting actual service/system passwords using time-limited/one-time use and role constrained tokens, such as from the Privileged Access Management function within Time of Access Operations.
• Control access to shared or delegated accounts (Time of Access).
• Maintaining a comprehensive view of privileged accounts – including application or ‘service accounts’ and their usage in the system environment through dashboards and reporting.
• Integrating with existing IT service management (ITSM) systems and change management workflows for tighter control of administrative access (i.e., Time of Access).

Ensuring the right policies are enforced:

As just described, critical elements of IAM in relation to APIs are credentials and permissions management, and include many of the same elements as Privileged Access Management, specifically:

1. Application-to-Application Privileged Management (AAPM) is focused on what are often referred to as ‘service accounts’ associated with application identities and credentials used for system-to-system communications, such as a web application that interacts directly with a backend database. This is the most common usage of API based Identity Management. Service accounts typically have a username and password that is programmatically sent on the network when connecting to the target system (e.g., the backend database). The passwords associated with service accounts are often not managed in accordance with the Enterprise Password Policy that is focused on end users (i.e., people, including SysAdmins) and are all too often simple or factory default passwords, such as “password” that are not even rotated periodically in line with the Policy.
2. System Administrator Privileged Management (SAPM), which is focused on system administration (SysAdmin), such as Windows Server or Azure Service administration, database administration, etc. The privileges associated with SAPM are usually restricted to administration and configuration services related only to the server, application, database, network device or platform to which the administrative account is associated. Any of these capabilities can be applied to AND managed through APIs. In other words, a Windows SysAdmin should only be able to run with administrative privileges on the associated Windows environment – he or she should not be able to use Windows SysAdmin credentials to configure other hosts or environments. Here, APIs must be given credentials and permissions that
3. Privileged Session Management (PSM) involves establishing and monitoring sessions to multiple systems. Authenticating users (e.g., using two-factor authentication) and then providing the users access to shared accounts from which all actions will be monitored. This is critical when managing transactions across systems via multiple APIs.
4. Super User Privileged Management (SUPM) is focused on “root” accounts (e.g., root is the superuser on Linux systems). Root / superuser accounts are most often used to make system configuration changes and can override user file protection. These are very powerful, often-human-associated privileged accounts that provide the basis for configuring almost everything deployed in the enterprise IT infrastructure, including in the cloud. Additionally, these accounts are also commonly utilized when using APIs, especially early in development when organizations have not implemented adequate credential management. See our report on Privileged Access Management for more details PAM

As noted in the PAM report, it is important to align ILM and PAM deployments, and it is critical that you consider the system and service credentials being managed in that, especially from and API usage perspective. It is also important to add the consideration of external accounts and credentials being used to access third party APIs and services by your user base, from developers through to any color collar workers.

Security and Audit Management

• Security and Audit Management tooling is focused around the Policy Administration Point(PAP), where the process is defined to ensure that the PDP and PEP elements have the right security policy in place to enforce the correct access controls, along with the monitoring elements of those elements.
• Integrating security and audit management with IAM and Identity Governance and Administration (IGA) is the point at which credentials are managed, from creation to distribution, throughout their lifecycle, and disabled, temporarily or permanently, or ultimately revoked.
• API Policy management is provided through methods across the digital chain from OAuth and API token/key models, access controls (from low level IP whitelisting and blacklisting through to behavior analysis), all the way to data analysis during transit.
• Behavioral analysis can also be used to determine bad actors, intentional or otherwise, and with identity management in place, we can ensure the right behaviors are allowed. This is what is meant when defining “adaptive authentication” and “adaptive authorization” operations.

Regardless of using a border security model or ZT approach, the decisions made by the PDP require context. This is the subject of the request, the resource, and the data points that can be applied to the decision. APIs are often not considered resources being used by organization and therefore not included in IAM or Service Access Management (SAM) initiatives or given appropriate levels of authentication and authorization commensurate with the risk associated with the applications’ functions. This, unfortunately, is a major reason why APIs have been so poorly implemented and secured. Lax API security can enable hacking APIs via credential hijacking, man in the middle attacks and misconfiguration are common. Any IAM effort should not just consider how you want the policies to be enforced, but also how to handle the situation where a bad actor, an attacker, the uninformed or others who don’t respect a security mode will work around those policies.

While the concepts of managing access is conceptually simple, understand that complexity ramps as the number of API calls and API usage scales. This is why it is so important to integrate your API strategy with your IAM strategy and Reference Architecture.

Why is it Critical to include API Security and Management in your Risk Model?

From the business perspective you are increasing the risks to the business with any API usage because use of APIs creates exposure to potentially invalid data, while exposing data and services via APIs creates, by definition, potential attack points.

Both internal and external attacks can occur as illustrated in Figure 6, with upwards of 80% of breaches having an internal security component, whether through malware (spyware, works, viruses etc.), bad actor, or unintentional breach.

Figure 6:  Internal and External Threat Vectors

Given both TechVision Research’s API and IAM Reference Architectures,  along with these statistics, common security approaches such as North/South security (as shown in diagram Figure 7) or perimeter based models are no longer suitable to manage these environments, and the Zero Trust model is recommended. IAM plays a central role in the Zero Trust model, so coupling your API and IAM strategies with this in mind better positions you for a network and infrastructure centered on Zero Trust.

Figure 7:  North/South Security Model

Put another way, once it is understood where and how API usage is being undertaken, you can model the requirements for managing and securing that access. In this we see not only the services sometimes available in the enterprise data center (whether on-premise, in-cloud or hybrid), but also the protocols and the API models to those services that commonly are in place. To assume API usage will only be from one origin, or to one destination, would be a mistake.

BENEFITS

Key benefits when defining an API management solution relate to the following:

Business Benefits:

• Speed
  • Fast iteration of APIs allows for a business to provide rapid delivery of new services and new data, supporting business development when needed. The former approach of ‘building everything from scratch per application’ fades away, which brings us additional business benefits, including:
    • Faster value chain creation
    • Faster delivery of digital data, services, and products.
  • Agility
    • The right model of API usage in your organization should allow for the creation and evolution of APIs at speed but allowing for changes in the business requirements.
  • Compliance
    • Ensuring specific types of data and data types are kept in a specific locale, a data store and policy management must come into play
    • Ensuring data security regulations are met through repetitive use of standard functions such as user, application and device authentication, authorization and so forth dramatically reduces the risk of non-compliant, stove pipe application development.
    • Ensuring specific types of data and data types are encrypted and secured according to policy supports compliance requirements.
  • Cost Management
    • Closely related to technical benefits, cost management can be gained by maximizing API caching, rate limiting, routing and similar optimization techniques.
    • When using APIs that use surge pricing or similar techniques, scenarios occur where your usage model can capitalize on understanding the patterns and triggers for those scenarios. For example, when choosing the best ride sharing company to book your staff into, you could first query the vendor for their current usage to determine which will offer a discount.
  • Citizen Support
    • For citizens or organizations outside the government, offering API’s enables them the potential to build their own value add or versions of online government services.

Technical Benefits:

• Logging
  • generating standard error messages allows for simple analysis of failures
  • logs are critical for aggregating usage patterns/trends
  • misuse is obvious and specific versions of that are: overuse, underuse, and outright abuse
  • API takeover attack where hacker plays with the FE, and through the service to the data, can manipulate things as an authorized and authenticated user, finding out how to pretend to be another
  • Logs as a data source for ingestion into AI and Machine Learning capabilities, paving the way for advanced threat analysis & prediction
  • Moves to support Multi-Factor Authentication MFA by allowing for observing and actions to be taken from specific requests or events via the API
• Mediation / Transformation
  • for transforming between data formats where the API provider is unable to support requirements.
• Security
  • Provide easier, usually centralized policy management
  • Abstraction to remove underlying complexity and associated risk of that complexity
  • Managing authorization code using OAuth and API key verification
  • Implementing threat protection and avoidance code.
  • Licensing management to ensure legal and compliant use of APIs
• Optimizing API usage
  • Cost management
  • Rate limiting
  • Caching

RISKS

Business Risks

• Consuming external APIs
  • There is a risk of pushing critical data outside the organization
  • Using external data creates a risk of
  • Allows third parties to identify usage patterns that can be aggregated outside the organization
  • Using external APIs creates a dependency on that API and the third party that provides it. If that party changes the API without warning, changes the terms of its usage, shuts it down, suffers a failure or many other possible scenarios then the risk to your organization is as great as the value of that API.
• Offering APIs to others
  • Makes your organization responsible for the security, support and evolution of your API offerings, including the upkeep of documentation.
  • creates a commensurately increased potential attack surface and complexity
  • You must ensure that your Terms and Conditions, legalese and any contractual language all agree when dealing with external parties.
• Privacy Breaches
  • The risk of exposing data via APIs is that you can expose more than intended, regardless of any contractual agreement. Earlier we referenced the Facebook / Cambridge Analytica scandal. In that situation the business risk created by Facebook allowing third parties to use their data was abuse of their data along with what can be construed as failures in securing their API, which allowed Cambridge Analytica to make use of more data than they were allowed to by contractual limits.
  • This scenario demonstrates both sides of the risk
• Regulation and Compliance
  • Government and Industry groups can create regulatory and compliance requirements relating to data access, use and storage. Knowing the complete audit history and genealogy of your API usage, and the data that is exchanged may be required by such requirements.
  • Such regulations usually come within contracts – commonly user agreements, terms of service, usage conditions,
  • Certain Terms and Conditions as well as Regulations require you secure specific information after a certain time or event for example:
    • Most organizations that provide data and services require you to delete such data when the relationship ends.
    • The EU PSD2 (Payment Service Directive), similar to the Payment Card Industry Data Security Standards (usually abbreviated to PCI-DSS or PCI standards) require you secure all information about a person yet allow access to approved third parties for financial transactions. These types of regulatory requirements can lead to byzantine trust agreements across multiple provider APIs – and such complexity can lead to unintended holes in coverage.
    • The EU General Data Protection Regulation (GDPR) requires you delete information when the owner requests it.
    • OAuth contracts usually have a specific timer set requiring reauthentication after that time, and along with the “contract” do not allow use of the authentication and related data without that authentication.

Technical Risks

• Complexity
  • APIs often include logic, as described earlier there are many logical and security decisions that are maintained in and API and API gateway, however, the mediation and transformation that takes places can make troubleshooting errors or failures quite complex too.
  • Adding multiple gateways can increase resilience, but also increases the number of pathways requiring management.
• The Disappearing Perimeter… to Zero Trust.
  • Management of a ZT environment is also quite difficult as many management tools cannot scale or support the mass of data involved. Ensuring that your API Management solutions support clear scale is important.
• Increased Business Risks from Technical debt: All the business risks are increased when they are hit by the common technical risks when offering and utilizing APIs include:
  • SQL/script injection
  • authentication vulnerabilities
  • middleman
  • DDoS
• Access/Service Theft
  • APIs that do not rely on some level of authentication are immediately risks.
  • APIs that rely on authentication run risks in several dimensions:
    • The issuance of credentials, whether username – password combinations, tokens or otherwise.
    • The theft of those credentials, with the risk increasing over time and also heavily dependent on the user who received those credentials and their ability to manage and secure their own environment.
  • Interception of data if the channel is not secure e.g. http vs. https

For further reference, The Open Web Application Security Project (OWASP) maintains a list of common API vulnerabilities, focused on REST APIs, that provides a good set of technical risks to consider. In September 2019, OWASP also published their API Security Top 10 list. Based on a timely analysis of common security issues associated with APIs, these include most of the elements we have detailed in this document as critical to well managed and secure API usage.

Despite all these potential risks, APIs can provide immense value as illustrated in the benefits section. It is critical however to ensure the right management and security approach is employed as we’ll explore in the remainder of this document. The right tools can improve your security posture, but without the right education and approach in mind, the risks will continue to increase.

APPROACHES TO API RISK MANAGEMENT

Choosing which approach is best for your organization is dependent on a number of factors as follows:

1. Is your usage dependent on an existing standard?
   1. If your source is already using a standard? (you may have no choice in the actual endpoint standard.)
   2. Internally, if you already have specific API tooling in place, this may define a better choice for your implementation.
2. What is your user base familiar with?
   1. Is there a cultural reason to choose an approach? If they already have skills with a particular API approach, consideration must be given to the cost of re-factoring on a different API or set of APIs.
   2. Have you ensured appropriate evangelism and adequate supporting documentation are in place?
3. Are you using Internet Protocols across your entire deployment?
   1. Because REST and GraphQL rely entirely on Internet protocols, they are not suitable for deployments that cross transport boundaries, and SOAP may be more suitable. Of course, there is any custom networking, there may be more esoteric choices or even forced options that are in play.
4. How complex is your API usage?
   1. If you are expecting to create a large complex set of API interactions, the overhead of defining them may end up as significant as the management. In this case SOAP has an advantage in terms of facilitating more complete framework.
   2. If you are creating simple object-based services with less than 100 interaction types, REST is a good choice.
   3. Are you aligned with your architectural models, whether SOA, Microservices, or otherwise?
5. What scale is your API usage?
   1. When considering millions of transactions and millions of users the requirement to minimize the amount of data and “chattiness” of the API is critical. REST is more lightweight than SOAP in these cases, but GraphQL was developed to avoid issues with REST and its ORB type models requiring multiple round trips for queries related to multiple objects. In these situations, the security overhead of validating every call can sometimes be greater than expected. This is regardless of a ZT approach or not, as every API call should be validated against security credentials at some point in its execution.

Managing APIs

• Microservices
  • Microservices, usually a Microservices Architecture (MSA), focus on a functional, parallel, resilient and scalable way to deploy functionality with a focus on self-contained services – in principle, able to operate independently of each other. MSA is an architecture akin to Service Oriented Architectures (SOA) with some key differences such as MSA defines services as entirely independent, being reliant on simple protocols, essentially REST. It is not the scope of this document to go in depth on Microservices Architecture, however it is important to understand the links to APIs.
  • Like APIs Microservices can be scoped to specific functional capabilities, whether object, data, service or, just purely functional in nature. For example, one type of microservice may offer capabilities to manage user accounts or access data related to a specific data source, while others may focus on triggering a workflow, or validating security calls from inside or outside an organizational security layer.
  • Microservices are popular in SaaS solutions as they create a boundary for cost management and security which often offer a single API, or at worst a small group of functionally related API calls.
  • Perhaps most critically, Microservices themselves are accessed and communicate through APIs.
  • As noted earlier, many microservices are using GraphQL as the model for deployment.
• API Gateways/Proxies
  • API Proxies decouples the API frontend from the backend services and filters all traffic (inbound and outbound). Allows changes to back-end services without impacting the API.
  • API Gateways provide the same decoupling, but offer a broad suite of advanced and more comprehensive services such as request routing, protocol translation, advanced security functions, caching and load balancing
  • A potential area of concern is whether you can manage your API usage at scale in real-time. A scalable API gateway, or a complete logging and monitoring solution may be required to ensure that real-time decisions can be made by pushing the right information to the right PEP.

THE SECURE API LIFE CYCLE

API usage can be abused for malicious use by external forces as much as internal to your organization. Whether for fun, profit, control, espionage, and even revenge, APIs and access to their capabilities are now as much a risk as any website you provide.

Like account management, API access can be managed through address schemes, credentials such as user/password combinations or tokens, or some element of signed and secured payloads. In addition, access may also be multi-layered allowing for or requiring a level of Privileged Access or impersonation. In these cases, the use of the API is increasingly at risk due to the value of its ability to impact the data or service being provided.

Here the concepts of Identity and Access Management come to the fore, and common methods for managing access to applications translate easily to API management models. Understanding the requirements from the perspective of a user, and application and the administrator may help understanding why this is a critical set of requirements for your organization.

API Security Design Principles

With so many external APIs now being accessed, there are potentially gaping holes in your perimeter when using third-party APIs. Because most APIs are accessed through standard ports and protocols you will also face challenges on managing the security of the channel. Some of the common risks associated with poor API security design principles include:

• Allowing outside access to your organizations APIs immediately creates an attack point, risk of misuse and potential for failure.
• Providing an interface for account and API access management is an additional source of risk as it provides another attack vector, and when compromised can allow the creation of improper credentials.
• APIs that allow for automated token renewal require constant monitoring to avoid attack and misuse to ensure that the right access is granted to the right sources at the right time.
• See our “Zero Trust” Research Paper for details on how to more completely apply ZT thinking in your organization.
• If an account, credential or secret that provides API access is compromised, it can result in costly business and security compromises. Therefore, the ability to quickly remove access via a management process and tooling is critical.

Monitoring for bad behavior and having processes to deal with such activity, whether malicious or unintentional is also critical. In the case of Netflix, we saw the impact of overloading APIs causing a companywide outage is a real threat. Tooling of the Security and Management layers of your organization require new links to the API logs and audit capabilities.

To ensure ease of implementation, the following principles should be top of mind:

• APIs should be as simple as possible.
• APIs will grow in complexity.
• Never request login credentials through public APIs
• Align API security and management with a ZT approach.
• Each API request should come with authentication credentials which must be validated on the server for each and every request.

PROGRAM GOVERNANCE

As detailed in Figure 2: API Critical Components Reference, there are multiple groups in your organization likely to be critical to your management and security of API’s, alongside multiple types of groups potentially consuming or offering APIs from outside your organization.

Inside your organization, key roles that are usually related to APIs are:

• Line of Business Users represent those that define key business requirements to be met through their application usage, which can be translated at times into APIs requirements. The same is true
• Developers represent the most common core audience for API usage, as well as those that will develop the APIs.
• API administers are responsible for the deployment, monitoring, reporting and general management tasks around APIs, often sharing that responsibility with other roles
• Enterprise Architects are responsible for ensuring that the overall use of APIs, within and outside the organization, meet the architectural requirements, especially those defined by the security architects within that role.
• Security Architects and Administrators are responsible for the security posture within the enterprise, across the architecture and where is crosses to external service usage.

Externally, Government, Customer and Partner users represent those who consume your APIs, and potentially APIs outside your control, through applications (mobile, web, even traditional types) or intermediaries such as web services (XaaS or Microservices). These “constituents” may ultimately be end-users, but usually initial usage is through developers. As such the value of good documentation principles will ensure greater ease of adoption as well as increasing the likelihood of good self-service usage.

the management of APIs requires assigning the right responsibilities for managing your API architecture and identifying the right team members to take these on. Within these defined roles will reside the bulk of your API governance capabilities, and the responsibility for the following functional areas:

• API Design – the overall standards and methods you will use to define and maintain your APIs
• API Security – the critical elements around which you will require security elements to be in place according to API security standards, critically, aligned with your enterprise security architecture, and ultimately aligned with your overall enterprise architecture. This will include elements such API Token Management, Transport security, Data Protection, and related security elements.
• User Management – aligning with IAM, this responsibility ranges across the roles internal to your organization through to external constituents, such as customers, partners and government. Further this should take into account consumption of external APIs and the potential for alignment with internal IAM solutions.

STANDARDS

There are multiple efforts to create standards across the API market. While not within the scope of this paper, there are still a couple of industry specific initiatives that you should be aware of in this space. Key initiatives include:

• The OpenAPI Initiative: The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how REST APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor neutral description format. SmartBear Software is donating the Swagger Specification directly to the OAI as the basis of this Open Specification.
• The OWASP org: “the free and open software security community”. The organization is a non-profit dedicated to sharing best practices in software security, and also acting as an advocate for open standards to improve software security.

FUTURE STATE OF APIs

There is increasing activity around the API market and it will continue to evolve rapidly, and as such this paper serves as a point-in-time reference. As the market evolves, we see the following likely outcomes:

• More organizations will define a “API First” approach to their development and architectures
• Expect many more tools and vendors to appear in the API Management and Security space.
• The use of Artificial Intelligence, most commonly Machine Learning solutions, to identify and manage API issues, especially at scale.
• The tools to find and APIs become common in all levels of the organizations
• Integration tools such as Zapier, IFTTT and Flow will drive further API developments and usage models
• Tools to provide initial and ongoing security checks will evolve and become integrated to API development and management solutions.

RECOMMENDATIONS FOR TECHVISION CLIENTS

This report focused on the API standards and approaches in common use today. We offer the following recommendations:

API Management Recommendations

• Implement Identity and Access Management that supports API management and security requirements.
  • Implement a “deny all” policy, with a whitelist that is integrated with the identity and access management systems.
  • Integrate your critical applications with Privileged Access Management AAPM functionality.
• Create a Zero Trust approach to your own internal and external API offerings. Zero Trust means that nothing on the network, resource, or application is trusted.
• Consider AI/ML where possible and use anomaly detection to alert when something abnormal is occurring.
• Log all activity and audit traffic for API usage. Whether you have this in place today or not, the effort needs to be put in place so that you can continuously monitor API usage, internally and externally. This is not a simple task and many of the management tools available today can assist in building this capability and a good Security and Identity Management architecture will ensure that these capabilities are aligned.
• Allocate an API Security Test budget of around 5-10% of the overall application cost.
• Raise Awareness.
  • It is likely that there is API usage in your organization that you will remain unaware of without individuals informing on that usage.
  • Developers can use and deploy APIs without taking all risks into consideration.

API Technical Recommendations

• Ensure all API communications, internal or external, rely on strong encryption.
  • Any data, whether at rest, in transit or in use should be encrypted as soon as it is available until the last possible moment before use. Minimally request your vendor, or when deploying your own, rely on 256-bit or greater TLS.
• Ensure all API communications incorporate identity management principles including credentialing, tokens and access controls.

CONCLUSION

APIs are the glue for the evolution of the digital enterprise. As a result of this shift, the use of APIs across and between organizations is increasing at a precipitous rate, regardless of industry, department, group or geography. API management and security are critical to business success, as APIs become core capabilities. All aspects of an adaptive security strategy are applicable to APIs including applying the right IAM approach to ensure security of API usage. Finally, a Zero Trust “mindset” is the required to ensuring security threats are minimized, whether offering or consuming APIs.

In conclusion, we offer the following advice:

• Understand and audit your organizations API consumption and management strategy
• Understand what API services are available to accelerate your digital enterprise goals
• Define what API services would accelerate your ability to work better with your value chain – partners, suppliers, regulators, advisors and customers.

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors:

Over 25+ years, Archie Reed has a career spanning many evolutions of the technology industry, from identity management to cloud computing, from machine learning to DevOps security. He worked on the early development of standards in OASIS, IETF and other standards groups, he introduced the early concepts of “Context Based Identity Management” which formed the basis of many identity-based security solutions and was engaged in the early evolution of the Cloud Security Alliance. Archie has authored a number of well-referenced books including “The Definitive Guide to Identity Management” and “Silver Clouds, Dark Linings: The Executive Guide to Cloud Computing”

[1] https://www.wired.com/story/netflix-ddos-attack/