o vPW/ } }v Z }µPZ>]( Ç o DvP u v - Akana · 2019-06-19 · Abstract: APIs are revolutionizing the world of IT by making it possible for developers to connect myriad applications,

© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy

Accelerating API Adoption through Lifecycle Management

© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy 2page

Contents

Introduction ..... 3

APIs: A Quick Overview ..... 3

API Compliance & Development Risk ..... 4

Sources of API Compliance Risk ..... 5

Mitigating API Compliance Risk with Internal Controls ..... 5

API Lifecycle Management: Balancing API Risk with Business Agility ..... 6

High Level Control Objectives for API Lifecycle ..... 7

The Countervailing Risk of Lock-Down ..... 7

Solution Approach: Managing APIs across the Complete Lifecycle ..... 8

The Need for Integration with Existing Management Systems and IDEs ..... 9

API Planning ..... 10

API Development ..... 10

API Security and Version Control ..... 11

APIs in Production ..... 11

API Community ..... 12 Conclusion ..... 12

Appendix ..... 12

A Note on API Compliance Risk in the Context of COSO and COBIT ..... 12

Sources ..... 14

Accelerating API Adoption through Lifecycle ManagementAPI Lifecycle and the Agile Path to Risk Management in the Fast–Moving Enterprise

Abstract: APIs are revolutionizing the world of IT by making it possible for developers to connect myriad applications, on mobile, cloud and web, to enterprise back-end systems with a minimum of effort. From a business perspective, APIs are an amazing source of agility and novel partnering. However, APIs also create a host of new threats to compliance and security. This paper explores ways that effective API management, in particular the management of APIs throughout their Lifecycles, can help mitigate the compliance risks inherent in APIs without dampening their potential to transform business.


languages such as JavaScript Object Notation (JSON) and representational state transfer (REST) style web resources. In the enterprise setting, RESTful APIs are finding myriad uses, especially as far-flung developers use them to allow mobile apps to tap into corporate back end systems. Growing out of popular use cases, such as mashups and porting photos from image sites to social networks, a new crop of interfaces includes B2B APIs, data APIs and integration APIs. These new API capabilities are making real many of the business agility benefits promised by the industry’s predecessor technology, the Service-Oriented Architecture (SOA).

One important difference, though, from a compliance perspective, is the contrast between the origins of the current API movement and SOA. While SOA was created by the software industry for enterprise and government use cases, Web APIs arose on the Web in a more open community of unrelated developers collaborating on essentially ungoverned interactions. For example, if you visit Tumblr’s API site, you will see that their API is available to virtually any developer who wants access. The site expresses the freewheeling sentiment that pervades the entire Web API movement, stating, “We’ve put a tremendous amount of care into making this API functional and flexible enough for any projects you throw at it. Join us in our discussion group to talk about how to use it, what could be better, and all the amazing things you’re going to build with it.” The site also references a developer’s blog for news and feedback.

Enterprises haven’t typically been set up to think that openly about access to their systems, although that is starting to change. The RESTful approach to APIs is simply too appealing. It can enable rapid-fire implementation of partnerships and operational plans. By convention, nearly all Web APIs use the same structure and rely on a few accepted REST procedure calls: GET, POST, PUT and DELETE. Consider the example of a manufacturing business that sells products through a distributor channel. To increase their sales and cut customer support costs, the company publishes a RESTful API that enables developers at any one of hundreds of distributors to embed order placement instructions in their apps. Figure 1 shows a simple reference architecture for this setup.

INTRODUCTION The technology industry has witnessed numerous advances in messaging and connectivity over the last several decades. From CORBA to the service-oriented architecture (SOA), each evolution in openness and integration capabilities has brought with it gains in agility and reductions in integration complexity. Today, businesses are starting to see the remarkable potential for a new generation of simple, open and flexible application programming interfaces (APIs) to accelerate strategic business execution. APIs are a remarkable breakthrough in connectivity, enabling virtually any application to access the most sophisticated applications and complex data sets with a simple set of standard instructions. A whole industry has emerged around making enterprise systems available to new applications, particularly mobile, using new APIs. Innovations in application-to-application integration create challenges to the software Lifecycle, however, with potentially serious ramifications for security and compliance. Fast, uncontrolled, not properly thought-through rollouts of APIs introduce new risks to data integrity, confidentiality, system reliability, and internal controls. This is not a new issue, but the current generation of APIs, based on JSON and REST standards, takes the openness, agility and risk to new extremes. Organizations with compliance and rigorous software Lifecycle requirements, however, need to catch up and ensure that the introduction of APIs does not create new risks. This paper looks at the benefits of APIs while providing an overview of API compliance risk. IT also discusses ways to mitigate API compliance risk without compromising the very agility and openness that benefits their users.

APIs: A Quick OverviewAPIs are not novel. In use for decades, they consist of libraries and protocols used as interfaces between software components. The APIs that are showing the power to make system connectivity, and hence business agility move so much faster are Web APIs that use simple, standards-based


API Compliance & Development RiskIf you’re involved in enterprise IT, the phrase, “Hey, wait a minute!” might be going through your mind right now. External developers can code their way right into your ERP system and create purchase orders? Whoa! Hold on a second. “Where are the controls?” you might you be wondering, and you’d be right. Other worries might legitimately include, “Are they using the right version? Has it been tested? Will it scale? Has some other developer already written a similar API? Is it following the security standards we mandate in this organization and industry?”

Compliance issues are a great, tangible example of the kind of risks that APIs can bring into an organization. HIPAA! SOX! CFOs doing the “perp walk” on the six o’clock news! But, before panic sets in, it’s helpful to situate compliance risk in the broader subjects of software Lifecycle Management and risk management. There is no one universal definition of risk management, but in general is it is about ensuring that risks to the business are identified and mitigated, including risks associated with compliance.

For every reward one gets in business, taking some sort of risk is required. If the manufacturer in the example wants to sell its products, it must build an inventory that it might not sell. That is inventory risk. It may extend credit to distributors, which creates credit risk. It employs people who might get injured on the job, creating risk in the form of human resources liability, and so forth. Risk management is a field dedicated to identifying risks to a business, specifically to assets owned by shareholders, and figuring out ways to protect those assets from a loss in value. Risk management is only partially a function of the IT department. However, in a modern business, information systems are major vehicles of risk.

Compliance risks arise from running afoul of regulations that govern financial reporting and industry-specific laws. For example, a healthcare business faces compliance risk related to disclosing private patient

Customers

RESTfulAPI

CustomersOrders

Invoices

TransactionsRevenue

Cash Journal

GeneralLedger

ERP

Orders

DISTRIBUTOR

App

OrderChanges

DISTRIBUTOR

App

OrderCancellations

DISTRIBUTOR

App

PaymentConfirmations

DISTRIBUTOR

App

PO Copyto Client

DISTRIBUTOR

App

RefundConfirmation

DISTRIBUTOR

App

PO Info

Payment Info

Order Info

Change Info

Figure 1 Reference architecture for manufacturing company that receives orders from distributors through a RESTful API

Using the RESTful API approach, each distributor can develop an app that enables their customers to place orders that flow through to the manufacturer. The app can call the manufacturer’s API to PUT orders, GET order information, POST changes, and DELETE orders. The ERP system can use the API to transmit changes in purchase orders (POs), refund information, and so forth.

Many business agility benefits arise from using a RESTful API to connect distributors with ERP. Instead of performing a costly, time-consuming integration with each distributor, the API makes is relatively simple and streamlined to connect the distributors’ customers with the manufacturer’s actual ordering system. IT costs and time cycles come down. Revenue goes up. Customer service improves. And, while this type of standards-based integration was possible with SOAP Web Services, the RESTful approach is simpler on numerous levels. For one thing, REST is a much lighter weight protocol so it’s easier for mobile clients to use than the more bulky SOAP message format. The common syntax and community approach also allows for the formation of a community of developers amongst the distributors’ IT departments. As the community grow and shares best practices for using the manufacturer’s API, uses of the API should increase.


is a liability. APIs provide access to internal systems and sensitive, valuable information. They can be provisioned and integrated outside of standard IT department controls that are designed to ensure compliance. And, APIs can function without adequate monitoring, an essential part of compliance. At a high level, API compliance risks include:

• Loss of confidentiality – Enterprise that want to be compliant gen-erally place a premium on keeping their private data private. APIs, which can give access to back end systems to virtually any devel-oper, create exposure to the threat of improper or unauthorized access to private data.

• Compromising of data integrity – Unauthorized access to corpo-rate by developers using APIs carries the threat of disrupting 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 regula-tory schemes that require data integrity for auditing of financial transactions and more.

• Business Continuity/Availability of IT assets – If API access cannot be throttled, entities using APIs to connect to back end systems can flood those systems with a transaction load large enough to cause disruptions to the business and block use of critical IT assets.

Mitigating API Compliance Risk with Internal ControlsWhen risk presents itself in a business, managers want to mitigate it, usually through the means of a countermeasure or internal control. Thus, for instance, if denial of service attacks are a threat, the business implements a firewall to mitigate the risk. There are many ways to do this, including the well-used COSO and COBIT frameworks, which are covered in the Appendix.

information, even if the disclosure is accidental. That would be a violation of the HIPAA law. The consequences for violating HIPAA might include fines, civil litigation, loss of reputation, and even criminal prosecution, all of which can affect business prospects and share price. To mitigate the compliance risk posed by HIPAA, most healthcare companies carefully control access and encryption of patient health data in their information systems.

In reality, there are two forms of compliance. There’s what might be called compliance with a capital “C” and that with a small “c”. Big “C” Compliance refers to clear-cut regulatory regimes, such as Sarbanes Oxley and EU Privacy Laws – rules that a business has to follow or face defined legal consequences. Small “c” compliance includes a lot of what we think of as information security and basic common sense. Keeping data confidential, accurate and available are all part of managing everyday business risk even if these activities do not bear on specific government regulations. They are both equally important when contemplating how to manage the API Lifecycle to remain compliant.

Sources of API Compliance Risk Assuming that the API shown in Figure 1 is not subject to adequate management, it exposes the manufacturer to both small “c” and big “C” compliance risks, By opening an ordering system, a system that is trusted to report the level of incoming sales orders, to a host of third party application developers, the manufacturer has potentially put the accuracy of its financial reporting at risk. On a small “c” basis, the company faces risks that its ERP system might be compromised, with resulting impact on data integrity and availability. For big “C”, the lack of control over the ordering system could throw the company out of compliance with Sarbanes-Oxley, which covers internal controls that ensure accuracy in financial reporting.

API compliance risk flows from the inherent, useful openness of the RESTful API and its community approach to development. From a compliance context, the greatest asset of the API, which is extreme ease of integration,


API Lifecycle Management: Balancing API Risk with Business Agility TThe fundamental challenge in making APIs work for business agility is to keep them lightweight and flexible while ensuring that they can be compliant. This is not a minor feat, but key to solving the problem is to recognize that the main issue one of Lifecycle Management. COBIT recognizes this reality, making Lifecycle one of the IT control framework’s main enabling processes, as shown in Figure 3. In IT asset’s Lifecycle is critical to its ability to be part of a controlled process. In the case of APIs, the way the API is planned, designed, built, implemented, operated, monitored and retired is inextricably linked to realizing the API’s dual objectives of compliance and agility.

Metrics for Achievement of Goals(Lag Indicators)

Are StakeholdersNeeds Addressed

Are EnablerGoals Achieved

Metrics for Application of Practices(Lead Indicators)

is LifecycleManaged?

Are GoodPractices Applied

Enab

ler P

erfo

rman

ceM

anag

emen

tEn

able

r Dim

ensi

ons

• Internal Stakeholders

• External Stakeholders



• Plan

• Design

• Build / Acquire / Create / Implement

• Use / Operate

• Evaluate / Monitor

• Update / dispose



Generic Practicesfor Processes

Stakeholders Lifecycle Good PracticesGoals

Figure 3 - COBIT enabling processes (Source: COBIT® 5, figure 29. © 2012 ISACA®)

In the example described in Figure 1, API compliance risk might surface around the area of revenue recognition. The timing of revenue reporting is sensitive in a public company, as quarterly revenue growth can have an impact on share prices. Reporting Q2 revenue in Q3 can accidentally throw a share price in one direction or another. In some cases, unfortunately, executives might even try to manipulate revenue period reporting to create an artificial “growth” that results in increased bonuses or valuation of option grants.

To prevent both errors and fraud, an internal control for revenue period reporting might involve the establishment of the process shown in Figure 2. Each step of the process is designed to ensure that only legitimate, accurate orders are recorded as revenue in the proper time period. Controls of this kind have existed for many years with traditional ERP and general ledger systems. Authentication and version controls are just two examples of IT-specific processes that are applied to the internal control to ensure that it works.

Distributor places order on ERP

Order confirmed

Distributor creates a

PO on ERPOrder Ships

Invoice SentRevenue

Recognized.

Figure 2 - Process flow for ordering at the manufacturing company.

Uncertainty about who is accessing the back end and whether the right API version is running can wreak havoc on the internal control depicted in Figure 2. For example, if a distributor can access a purchase order through an API and change its date – an act that is theoretically prohibited by the internal control – that control will be rendered deficient. The same risks present themselves across this control procedure. An unmanaged API can disrupt the integrity of revenue data.


4) APIs should be monitored and throttled as per compliance requirements, both at the aggregate API level and also on a consumer-by-consumer (i.e., app-by-app) basis. Based on business policy, some apps may be granted more favorable access (i.e., service level agreement) than others. Again, these policies should be declaratively injected into the API both to enable flexibility and agility and to allow API developers to concentrate on the core functional capabilities of the API.

The Countervailing Risk of Lock-DownAPI Controls can also be too good. This is where the need for an API to be lightweight and flexible really becomes significant. If an organization locks down the API Lifecycle and makes it difficult to introduce new versions or grant authorization to APIs, the business will suffer. APIs depend on their community orientation. The goal with APIs is to have developers create apps that will drive business objectives forward – just to do so within the boundaries of a reasonable control framework. The key is to achieve a balance. Controls need to be effective, but they cannot be so restrictive that they push developers away.

High Level Control Objectives for API LifecycleAt a high level, it is possible to develop a set of API control objectives – generic API controls, if you will – based on Lifecycle and related factors, such as stakeholders. Any process that is subject to a compliance audit, such as internal controls or data privacy controls, that touches an API, should meet the following objectives:

1) The API’s Lifecycle should be subject to control so that only permissible versions are in production.

a. At the planning stageb. At the development and test phasesc. In productiond. In retirement

2) Key stakeholders, such as line of business people, IT managers, information security staff and compliance staff should have visibility into the state of the API. They should always be confident that they are looking at the correct version, and that the expected workproducts for the API are present as it progresses through the gates established by the organization’s API Lifecycle. Some of these stakeholders may simply be observers and consumers of information, while others will be directly involved in the gating process as the API proceeds from planning through production and eventually retirement as it is versioned or superseded.

3) While in production, APIs should be subject to authentication and authorization processes to protect enterprise IT assets from misuse, threats to availability or breaches of privacy. Ideally these processes should be declaratively injected into APIs as a result of upstream lifecycle decisions that are themselves subject to review and approval by relevant stakeholders.


After a test Phase, the API is deployed into production and shared with app developers. The process is typically circular, with the community of app developers having advanced knowledge of new APIs that are in the development and launch pipeline.

Each stage of an API’s Lifecycle exposes an organization to specific compliance risks while the bigger picture of systemic risk carries across the complete Lifecycle. For instance, a lack of awareness of updated API versions that are being launched into production aggravates the risk of breakdowns in connectivity with apps or doubts about the integrity of data flowing into enterprise systems. In the example shown in Figure 1, if the manufacturer updates the purchase order API by creating a new version, a problem with accurate financial reporting can result when an outdated app tries to call the prior version. Even worse, if the API developer decides to make changes to the API without considering existing app consumers, deployment of the updated API could break existing apps without giving app developers a chance to adapt to the new interface. To solve this problem, the Lifecycle stages must be united in compliance risk mitigation.

All pieces of the API management process should connect to one another across the API’s Lifecycle. Unfortunately, some API management solutions are relatively piecemeal in their approach, with loose components that can be deployed at various points in the Lifecycle without coherent awareness of the overall process. For example, a solution might make it possible to monitor inbound traffic and conduct authentication for access to an API. However, that solution does not necessarily “know” if the API in question has been replaced or retired.

Solution: Managing Lightweight APIs across the Complete Lifecycle API management solutions are the mechanisms by which internal controls are implemented for APIs. API management solutions come in a variety of forms, but most give the organization the ability to provision APIs to developers in a controlled, portal environment, oversee deployment and production, monitor usage, and secure API access. To enable control without affecting agility, however, the API management solutions should ideally touch the complete API Lifecycle.

All IT assets have a Lifecycle. They’re planned, developed, put into production, monitored and eventually retired and replaced. APIs are no different, but the speed with which they are created and deployed, coupled with the vast unknown potential pool of users, make them a special case for Lifecycle Management.

Planning

• Controls designed in at planning stage.

• Compliance policies defined.

• Stakeholder input.

Plan

Development

Build

Operations

• Dev/Test/PRoduciton barriers defined and enforced.

• API launched to production with policy binding.

• Monitoring and reporting on access/audit logging of usage.

Run

Community

• API shared only with authorized developers.

Share

• Develop for controls and security policies.

• Understand dependencies.

• Stakeholder awareness of development progress.

Figure 4 - Management of the API Lifecycle in the context of compliance

Figure 4 shows the four elemental stages of the API Lifecycle that need to be managed for compliance purposes. An API originates in a planning process that precedes development. The API is built by developers who either adapt existing applications and services or code the API from scratch.


access management. Consider what happens when the manufacturer decides to update its existing API for outside distributors. Given that a change in API can throw internal controls out of whack, what is the best approach to ensuring that controls stay in place as the new API is introduced? Assuming that the API management solution has a central console that provides administrators with an overview of all API activity, the following integrations highlight how the right API management solution works with existing systems:

• By integrating with the IDE, all stakeholders in the API Lifecycle can be aware of development activity. Business managers, security staff, operations people, and the outside app developer community will all be kept abreast of its design and development timeline. Tying stakeholders together makes execution faster, adding to the business acceleration capability of the API while ensuring compliance. Community features in the API management platform enable stakeholders to comment and discuss how the development is proceeding. Those tasked with compliance will be able to assess if the new API meets the parameters required for internal controls. For instance, they will be able to ascertain if the new API meets the segregation between development/test/pro-duction environments mandated by most IT general controls.

• Integrating API monitoring with the infrastructure management solution enables IT operations staff to be aware of API perfor-mance through the system they already use to track many other IT assets. For example, if the manufacturer’s API goes down or starts running slowly due to excessive load, the API management solution can send an SNMP alert to the overall infrastructure management system. The administrator can be alerted about the API’s problem through an email or text, just as he or she would notified about a Linux server going down, for example. The advantage of this approach is that it gives the IT department visibility into what’s happening with its production APIs without requiring anyone to consult a separate system.

The Need for Integration with Existing Management Systems and IDEsItmay not be a realistic goal for most IT organizations to implement API management across the full Lifecycle. The problem is that APIs didn’t appear in a vacuum. They are being woven into the complex, thick fabric of enterprise IT, an environment that is replete with established systems for IT asset Lifecycle Management, software development and system monitoring. While unifying management across the API Lifecycle is a practical matter that involves connecting the API management solution with multiple existing systems of record, this is easier said than done. It may not be reasonable to expect IT to adopt new, siloed management tools just because they are working with APIs. Even if IT adopts such tools, connecting the dots from these tools to the existing IT landscape is challenging at best and subject to human error and compliance exposures that result from “swivel chair integration” and other forms of non-automated process handoffs.

What’s needed is an API management solution that functions across the complete Lifecycle but also connects dynamically with various existing development and system management elements. This provides a degree of control over the API without creating complexity that slows down the agility potential of the API. For example, the manufacturing company depicted in Figure 1 has an established integrated development environment (IDE), infrastructure monitoring solution and access management system. These systems have been in place for years and are well understood by the IT department. They are trusted. As APIs are introduced, the IT department will want to continue using them for this new iteration of the application interface.

To mitigate API compliance risk without disrupting established IT patterns, the manufacturer would be well advised to seek an API management solution that connects with its IDE, SCM, infrastructure monitoring and


everyone connected to the API aware of the planning process and able to participate in it. Of course, it’s possible to bring API planning stakeholders together without an API management solution but it’s not an efficient practice. Cobbling an API planning process together from divergent pieces and solution parts can lead to agility-killing slowdowns, control errors, or both. Figure 6 highlights the stakeholders who typically touch API planning.

Planning

• Enterprise architects• Business analysts• API center of excellence• Business managers

(LOB API Owners)• IT dept. management• InfoSec• Compliance managers

Development

• Service developers• Service consumers• API publishers• DevOps managers• Compliance managers

Operations

• Platform admins• Server support• Cloud hosting managers• Compliance managers• InfoSec• ESB/Middleware

Community

• API developers• Development

community managers• App developers

API MgmtAPI MgmtAPI Mgmt

Figure 6 Stakeholders that need to be connected across the API Lifecycle by the API management solution, starting with API planning.

API Development Plan Build Run Share

The API management solution will ideally be integrated with the development platform of choice. As each API is “registered at birth” so to speak, compliance outcomes are best when the following capabilities exist within the IDE itself as a result of the API management solution’s automated integration with the underlying SCM and over the runtime stack used to deploy and test the API:

• Show what APIs are available. This helps avoid the wasteful pro-cess of developing APIs that already exist.

• Create APIs with multiple interfaces using different standards including REST/XML, REST/JSON and SOAP with no extra develop-ment effort.

• Document APIs - Define and document APIs so developers can use them without burdening support resources.

• Integrating with the access management system makes the API management solution a seamless part of the manufacturer’s infor-mation security function. With most organizations treating outside apps that seek to access APIs as “zero trust” entities – meaning that there can be no assumption of trust when an app calls on a backend system through an API, API access control is a critical ele-ment of security and compliance. However, managing an access system is hard work. Creating a separate silo for API security is a waste of resources and likely to create new security risks. As APIs get provisioned to outside developers and apps, it makes the most sense to use the existing access management system. The API man-agement solution should be able to pass security credentials and tokens back and forth between the access control system and the production environment where the API is hosted. Figure 5 summa-rizes the connections.

Enterprise DevelopmentBuild your API Development tools, Database servers, Enterprise Service Buses (ESBs)/middleware API Managment

Solution

OperationsRun your APISystem management tools, application servers, cloud hosting API Managment

Solution

API Driven AppsShare your API API community portal

Figure 5

The stages of the Lifecycle and the systemic elements that need to be integrated with the API management solution.

API Planning Plan Build Run Share

For an API to enable its desired qualities of agility and strategic business outcomes, its planning needs to be efficient and inclusive of all stakeholders, balancing business needs with IT strategy and capabilities. Compliance outcomes are also dependent on such multi-participant planning. The API management solution therefore ought to make


APIs in Production Plan Build Run Share • APIs in production present a number of challenges to IT opera-

tions managers. Unknown external users create unpredictable load management and quality of service issues. At the same time, the fast-moving version updates inherent in APIs make it difficult for ITOps to stay on top of what’s happening – a big negative for API compliance. The API management solution can address these challenges:

• Monitor APIs, keeping an eye on traffic from individual Apps. Get visibility into how an API or App is behaving understand how it’s being used.

• Troubleshoot and quickly identify and fix problems with APIs.

• Manage quality-of-service (QoS) for APIs, managing quotas and service-levels for individual Apps. The management solution should be able to ensure a promised level (SLA) of performance of scale while protecting internal applications for excessive load.

• Manage which applications can use APIs, and how much traffic they can consume.

• Provision App to API in an organized, traceable workflow - Walk developers through a simple process with easy to understand ap-provals for getting access to APIs.

• Support intermediation - Convert existing SOAP or Plain-old-XML (POX) over MQ or JMS services into RESTful APIs with XML and/or JSON content.

• Provision and Test - Expose sandbox (test) and production endpoints for APIs with an intuitive approval process for granting Apps access to each of the endpoints.

• Manage App to API connections - Automate and control the connec-tions between Apps and APIs.

• Map and manage API dependencies – Show where APIs are depen-dent on other system resources.

API Security and Version Control Plan Build Run Share Security issues pervade API compliance in every phase of the API Lifecycle. They are particularly relevant at the build and run stages, especially when multiple versions of APIs are propagated to a diverse developer community. The API management solution needs to secure APIs, protecting sensitive data while allowing access to authorized apps and users. The API management solution needs to make security policy definition and enforcement easy throughout the process, including:

• Authentication Policy Options - Choose from multiple authentication schemes, standards and token types to ensure that only valid users and applications get access to the APIs.

• Enterprise OAuth - Use existing enterprise security systems to create an OAuth authorization server so users can manage access rights for their own data.

• Advanced Cryptography - Ensure the privacy of customer data with sophisticated encryption and signature capabilities.


an incoherent way that invites lapses in control. Stakeholders connected to the API have to be able to communicate with one another through the platform, including people and entities that are external to the organization that is publishing the API. API Lifecycle Management, as embraced by the complete organization, is inextricably linked to attaining the strategic outcomes promised by APIs while ensuring that compliance risks remain minimized.

Appendix

A Note on API Compliance Risk in the Context of COSO and COBIT

Making an enterprise compliant can be a complex business. A multitude of frameworks and processes can be applied to compliance – far too many to discuss in a paper such as this. Indeed, whole books have been written about just a single aspect of individual control frameworks. To keep things simple and focused, this notes reviews how API compliance risk can be managed using the COSO Internal Control Integrated Framework and COBIT, two approaches that are prevalent in American financial compliance.

COSO, which stands for “Committee of Sponsoring Organizations [of the 1980s Treadway Commission]” is considered the primary standard for internal controls by the major accounting firms and organizational bodies that oversee compliance with the Sarbanes-Oxley Act. Sarbanes-Oxley was enacted in 2002, an expansion of the 1930s era securities laws, in the wake of the Enron scandal. Section 404 of the Act requires a publicly-traded company to certify that its internal controls over financial reporting are adequate to support accurate financial reporting. Potentially serious penalties loom if the external auditor judges the controls to be deficient.

API Community Plan Build Run Share

API management solutions typically make some sort of community portal for use by API managers as well as app developers. The community is a connecting point where an organization can manage, share and promote its APIs in a secure, scalable environment. For ideal compliance effect, the community should integrate with all the other phases of the API Lifecycle. It enables the organization to control which applications can use the APIs, and how much traffic they can consume:

• App to API provisioning workflow – The community portal can walk developers through a simple process with easy to understand approvals for getting access to APIs.

• Manage Sandbox and Production Access - Allow easy access to sandbox endpoints for testing, with a more rigorous process for getting approval to use a production endpoint.

• Facilitate Legal agreement management - Require developers to accept legal terms for each API before their App is granted approval to access the API.

• Allow developers to negotiate a QoS policy for their Apps with the API administrator.

Conclusion Managing the API Lifecycle and achieving compliance while realizing their agile business potential form a single subject. It’s all about making sure that lightweight APIs serve business needs are built right and run with controls that are compliant but not overly restrictive. Making this happen involves selecting the right API management solution. That solution needs to work across and connect each stage of the complete API Lifecycle. If it can’t, the organization risks working on compliance in


Distributor places order on ERP

Order confirmed

Distributor creates a

PO on ERPOrder Ships

Invoice SentRevenue

Recognized.

Figure 7 - Process flow for ordering at the manufacturing company.

This is a fairly straightforward order process, but from the perspective of the revenue period control, there are a number of vulnerabilities that can appear when orders flow through ungoverned APIs. Consider two potential control breakdowns that can occur with an API:

• Management overrides – If a user can access the ERP system through the API and use a management override to change the shipping date of an order, that user can manipulate revenue recognition dates.

• Segregation of roles – Keeping duties separate is one of the essential practices of internal controls. To ensure that revenue is reported in the correct period, one person should not be able to enter an order into the ERP system, confirm it, and issue an invoice. If an a single API user can do all three of these process steps, a salesperson could theoretically move orders and invoices around to meet a bonus target without anyone knowing any better. At the very least, there is the potential for error, which is also problematic when reporting financial results at a public company.

The point here is not that employees are dishonest. Though that is sometimes the case, what’s more important is for a business to be able to control processes that affect financial reporting. Internal controls need to be robust and ready for auditing. Given that virtually all business transactions now take place on computer systems, COSO has, not surprisingly, focused a great deal of guidance on the application of internal controls in I.T. Broadly, COSO provides two sets of controls for I.T.:

• I.T. General Controls – I.T. General Controls bear on realizing secure access to systems and data, including password management and access logging. These controls also cover change management, including issues such as separation of development/test/production

What is an internal control? Technical, opaque definitions abound. To keep it simple, an internal control is a business process that provides reasonable assurance that financial reporting is accurate and that the business is in compliance with regulations. Internal controls also often deter employee fraud. A cash register tape is perhaps the most basic example of an internal control. The tape shows how much money went into the register during the day. It can be used to reconcile that amount with the actual cash on hand at the end of the day. Of course, today most internal controls are rooted in information systems.

In the manufacturing company depicted in Figure 1, an internal control might be introduced to ensure that revenue reporting is accurate within a given time period. Using the COSO framework, the control would have three components, a control objective, a risk and a set of control activities. For example:

Control Objective

Be reasonably sure that revenue is reported in the correct period.

Risk

Risk of material misstatement of financial results if revenue numbers are not reported in the correct period.

Control Objective

Establish and maintain policies to ensure that revenue figures are reported in the correct period: • Password and

authentication controls • Segregation of duties • IT General Controls • Application Controls

The timing of revenue reporting is sensitive in a public company, as quarterly revenue growth can have an impact on share prices. Reporting Q2 revenue in Q3 can accidentally throw a share price in one direction or another. In some cases, unfortunately, executives might even try to manipulate revenue period reporting to create an artificial “growth” that results in increased bonuses or valuation of option grants. To prevent both errors and fraud, an internal control for revenue period reporting might involve the establishment of a process that look like this:


Sources• http://apievangelist.com/2012/12/09/some-thoughts-for-the-enterprise-

embracing-web-apis/ • http://www.sec.gov/rules/interp/2007/33-8810.pdf • http://smallbusiness.chron.com/internal-controls-accounting-43168.html • http://www.isaca.org/knowledge-center/cobit/Pages/Overview.aspx • COBIT 5 Introduction (ISACA 2012)

• Forrester Wave: API Management Platforms, Q1 2013

environments, acceptance testing, and version control. APIs in their natural state are highly deficient to meet the requirements of I.T. General Controls.

• I.T. Application Controls –I.T. Application Controls cover informa-tion processing done by software applications. Typical Application Controls include data validation, numerical sequencing of transac-tions and comparing sums with control accounts. APIs that are not managed also fail the basic tests of I.T. Application Controls. They possess none of the inherent data validation, numerical sequenc-ing, and so forth.

When IT people talk about compliance and controls, they invariably mean the IT General Controls and IT Application Controls under COSO. And, their frame of reference is almost always Control Objectives for Information and related Technology (COBIT), an IT governance framework that connects control requirements with IT itself. COBIT is the way that IT professionals implement IT General and Application Controls. Like COSO, COBIT is an immense topic. In the context of API compliance risk, however, the area that deserves the most attention is Lifecycle, depicted in Figure 3 as being a key part of the COBIT Enabling Processes. APIs need to be subject to Lifecycle controls in order to be a good compliance citizen in the corporate I.T. ecosystem.

© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy

Disclaimer: The information provided in this document is provided “AS IS” WITHOUT ANY WARRANTIES OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF INTELLECTUAL PROPERTY . Akana may make changes to this document at any time without notice . All comparisons, functionalities and measures as related to similar products and services offered by other vendors are based on Akana’s internal assessment and/or publicly available information of Akana and other vendor product features, unless otherwise specifically stated . Reliance by you on these assessments / comparative assessments are to be made solely on your own discretion and at your own risk . The content of this document may be out of date, and Akana makes no commitment to update this content . This document may refer to products, programs or services that are not available in your country . Consult your local Akana business contact for information regarding the products, programs and services that may be available to you . Applicable law may not allow the exclusion of implied warranties, so the above exclusion may not apply to you .

© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy

About Akana Akana is a leading provider of API Security and Management products that help businesses plan, build, run and share APIs, through comprehensive cloud and on-premise solutions that encompass API lifecycle, security, management and developer engagement. The world’s largest companies including Bank of America, Pfizer, and Verizon use Akana solutions to transform their business. For more information, please visit http://www.akana.com

Akana, API Gateway, Community Manager, Lifecycle Manager, Policy Manager, Portfolio Manager, Repository Manager, Service Manager, and SOLA are trademarks of Akana, Inc . All other product and company names herein may be trademarks and/or registered trademarks of their registered owners.

12100 Wilshire Blvd, Suite 1800Los Angeles, CA [email protected]

Documents

o vPW/ } }v Z }µPZ>]( Ç o DvP u v - Akana · 2019-06-19 · Abstract: APIs are revolutionizing the world of IT by making it possible for developers to connect myriad applications,