Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Securely Managed API Technologies Key to Fostering Market Innovation

Securely Managed API Technologies Key to Fostering Market Innovation

Lire ce contenu en français

Web services are relatively standard approaches enabled by Application Programming Interfaces (APIs) that allow the capabilities of one company’s website, application, or internal system to be accessed and used by another company or multiple entities by connecting directly to the underlying data. This approach offers distinct go-to-market velocity in terms of real-time innovation, but requires new standards in the way APIs are secured and managed and the nature in which APIs communicate between organizations at the B2B enterprise gateway level.

How do APIs foster business model innovation? The most obvious way is through a mashup that leverages an already well-established API platform, such as Google Maps and location-based services. Another, perhaps not so obvious way, is for enterprise companies to create a handful of uber-APIs allowing enterprise applications to perform net-new functions, such as expanding market reach through new channels. Two examples of the most popular enterprise APIs spawning new mashups are and DocuSign.

In all situations, the APIs must be managed, governed, and secured with essentially the same policies across technology platforms and domain entities, and must take into account the connectivity and transport protocols related to messaging of the relevant applications. The benefits of APIs are even more dramatic when organizations need to share applications and data via cloud or mobile platforms. However, leveraging corporate data through APIs in public/private cloud environments without proper identity, access, vulnerability, and risk management controls in place exposes those sources of data to potential exploits (see also How to Manage and Secure APIs with Unified Services Gateways).

Here are several examples of technology-driven innovation that also require the most rigorous standards of automated API security and compliance:

Retail marketing services: Near-Field Communications (NFC) allow for smartphone interaction with physical products via RFID; for example, Coke can generate a rewards coupon on the fly in the beverage aisle to a consumer who taps the smartphone’s NFC function. The ability to personalize that interaction is dependent upon the consumer’s profile consent and security authentication – that and many other NFC functions will be enabled by securely managed APIs; additionally, NFC APIs deployed in retail channels will need to adhere to Payment Card Industry Data Security Standards (PCI DSS).

Digital video services: WebRTC, or Real Time Communications, is an emerging open source video standard being developed by the World Wide Web Consortium (W3C). WebRTC enables browser-to-browser applications for video chat, voice calling and peer-to-peer file sharing without third party media players or plug-ins. These video apps threatening existing real-time collaboration and communications standards, such as WebEx and Windows Media Player, will require secure transport and authentication, which will happen in APIs. For meeting-based applications, the API will have to provide for proper authorized use and reuse, privileged executive communications by segmentation of duties, and real-time code controls.

Electronic medical records services: EMR mandates by the government and necessitated by business demands are well-known; digitizing medical data universally will also create the opportunity for API-based services. For example, the API can interface with an individual’s medical profile to enhance both the business and service aspects to healthcare delivery, i.e., a scheduling app matching a patient’s personal medical needs with available services and specialists, or a SMS app alerting the patient to new information or test results available. The APIs that interface with EMR will need to incorporate the highest thresholds of data privacy and regulatory compliance.

Financial cloud services: more than 60 percent of securities and commodities trading is now comprised of so-called high-frequency trading or HFT; the analytics data in terms of volumes of trades, successful algorithms, volume pricing, and comparative analysis are valuable sets of information to the industry. For example, a very large institution may have up to 10,000 professionals who use HFT technologies requiring visibility into the same data at the same time. The ultimate benefit of this type of data-as-a-service platform is to model risk management analysis for future trading opportunities, thus the API must safeguard the underlying data as robustly as any other financially-regulated technology.

Data sharing encryption services: A growing trend among both mid-market and large enterprises is to allocate certain aspects of their IT infrastructure to a public cloud provider, such as Amazon Web Services. The interaction between enterprise compute, storage and networking clusters and the Amazon Elastic Cloud (EC2) is an enterprise API that communicates with the EC2 API. However, the underlying storage topology, often formed in an open-standard such as Hadoop, doesn’t always conform to the individual enterprise’s data storage or data-in-motion standard, and thus enterprise API gateways are required to orchestrate the proper acceptable use and data encryption standards in the cloud as if the service were being brokered by the enterprise itself.

API business agility is both a management and security issue. API managers must consider how much API governance can be automated to reduce potential for coding errors. On the flip side, security issues related to governance policies, date protection, compliance adherence all need mitigation to achieve optimal business agility. (for more in depth analysis, see The Reality of API Management Challenges).

Data Protection: Unauthorized access to corporate files by developers using APIs carries the threat of corrupting data integrity. Whether it is malicious or accidental, an entity accessing corporate data through an API can potentially change that data and render the business out of compliance with any number of regulatory schemes requiring data integrity for auditing of financial transactions and more.

Compliance Adherence: Let us use an example from a global manufacturer. This manufacturer develops an ordering system that is trusted to report the level of incoming sales orders to a host of third party application developers.By doing this, the manufacturer has potentially put the accuracy of its financial reporting at risk. On a small “c” basis – compliance with internal controls and API governance – the company faces risks that its ERP system might be compromised, with resulting impacts to data integrity and availability. For big “C” or external pressure Compliance, the lack of control and API governance over the ordering system could throw the company out of compliance with Sarbanes-Oxley, which covers internal controls that ensure accuracy in financial reporting.

Risk Mitigation: Keeping with the global manufacturer example, uncertainty about who is accessing the backend ERP system and whether the right API version is running can wreak havoc on internal controls. For example, if a distributor can access a purchase order through an API and change its date – an act theoretically prohibited by an internal control – that control will be rendered deficient. The same risk presents itself across this control procedure. An API lacking proper governance can disrupt the integrity of revenue data.

Thus, proper governance involves developing a set of API control objectives based on Lifecycle and related factors, such as key stakeholders cutting across business and IT roles (just as with ITIL for services and COBIT for processes). Any process that touches an API and is subject to a compliance audit, such as internal or data privacy controls should meet the following three key governance objectives:

  1. The API’s Lifecycle should be subject to control so only permissible versions are in production: at the planning stage, development and test phases, in production and retirement.
  2. Key stakeholders, such as lines of business executives, IT managers, information security staff, and compliance auditors should have visibility into the dynamic, current state of the API. They should always be confident they are looking at the correct version within the proper lifecycle context.
  3. APIs should also be subject to authentication and authorization processes to protect enterprise IT assets from misuse, threats to availability, or breaches of privacy, while ensuring monitored and throttled governance mandates are fulfilled.

About the Author

Atchison Frazer is a networking and services strategist with enterprise market management experience ranging from start-ups Gnodal, ServGate and Fortinet to industry leaders Cisco and HP.

Rate this Article