Abstract

Businesses require nimble capabilities to develop, deploy and retire myriad online applications that power their Digital Enterprises, electronic commerce initiatives and deliver significant revenue to the bottom line. Never has this been more prevalent than in the past 20 months, when the COVID-19 pandemic sent millions to the shelter of their own homes and spurred an unprecedented move towards online customer interaction for the acquisition of goods and services. In addition to e-commerce facing applications, the emergent work-from-home culture established an employer-employee relationship that depended as much on the efficacy of enterprise IT applications as it once did on face-to-face contact.

As TechVision Research has been emphasizing for the past several years, a combination of loose-coupling, virtualization and federation are critical characteristics for digital transformation and enterprise IT as a whole. Secure, API-enabled microservices create an ‘abstraction layer’ that can dramatically simplify application development, integration, data security, privacy, and operational support.

Never before was the spectre of legacy application development, deployment and support exposed for its inefficiencies. The traditional approach to application development, often referred to as ‘waterfall’, was naturally seen as too slow, too error prone, and too rigid. Bearing in mind that necessity is the mother of invention, the often-aspired but somewhat rarely achieved adoption of Agile software development techniques became paramount to remaining in business. With this comes the understanding of just how important Application Programming Interfaces (APIs) are to enabling and securing the modern Digital Enterprise.  This highly actionable report provides a context and strategy for effectively embracing the “API economy” as a critical function of an overall enterprise IT strategy. We also describe a few significant vendor offerings in this emerging, but rapidly developing category.

Authors:

Doug Simmons Managing Director, Consulting and Principal Consulting Analyst [email protected]

Gary Rowe CEO and Principal Consulting Analyst [email protected]

 

Executive Summary

The COVID lockdown has exposed core weaknesses in the application development world. Never was the specter of legacy application development, deployment and support exposed for its inefficiencies. The traditional approach to application development, often referred to as ‘waterfall’, was naturally seen as too slow, too error prone, and too rigid. Bearing in mind that necessity is the mother of invention, the often aspired to but somewhat rarely achieved adoption of Agile software development techniques became paramount to remaining in business. With this comes the understanding of just how important Application Programming Interfaces (APIs) are to enabling and securing the modern Digital Enterprise. The importance and flexibility of APIs is sometimes referred to as the API Economy given the role APIs play going forward.

As enterprises continue to embrace digital transformation then, much focus is on the Development and Operations groups responsible for developing, integrating, and maintaining IT services – including identity and access management (IAM), data security and privacy, logging, testing, monitoring and so forth. While traditionally these two groups (Development and Operations) operated in a somewhat isolated fashion, with Development working feverishly in its own silo, releasing new “IT products” (whether developed in-house or integrating commercial-off-the-shelf solutions) to the IT Operations staff – who are then challenged with securing and maintaining these products. This waterfall model for application development has often led to disconnects between Development and Operations, because the process is innately non-iterative and the model makes timely feedback, consistent security and regular cross-functional collaboration difficult.

There are two emerging, synergistic approaches to this dilemma that we detailed in the TechVision Research report titled “How Microservices Can Improve Your IAM Strategy”:

1. Logically combining the Development, Information Security and Operations groups into a single entity referred to as DevSecOps, with a primary focus on agile development (the antithesis of the waterfall model) coupled with,
2. Adopting microservices architecture and deployment strategies that break down business functions into atomic-level IT functions, or “services”, that can be reused, retrofitted and replaced with minimal disruption to the overall IT infrastructure.

One of the most significant results of such a DevOps model is improved accessibility of what might be considered general purpose IT services, such as user authentication and authorization, profile management, customer and employee lifecycle management, data privacy, activity monitoring, input validation, anomaly detection and so forth. Without an effort to move toward a better DevSecOps paradigm, enterprises will continue to suffer from siloed applications and services that will perpetuate the issues of disconnect that largely exist today.

Delivering IT functionality via microservices involves the identification of discrete application functions within a compact, single-purpose code set. Such a specific-purpose microservice can then be easily and securely integrated into multiple, disparate in-house developed or COTS applications. This approach provides an environment for further integration of a related set of microservices as needed by a set of related, callable services.  These related services can include specific IAM services such as ‘authenticate identity’ or ‘create identity’, and so forth.

Typically, individual, related microservices are ‘packaged’ in such a way using a container structure or an API gateway.  Therefore, API’s become the glue across almost all application development, 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 enables rapid delivery of scalable, integrated, flexible applications. Done right, API management and security allow your enterprise to offer internal and external developers, partners, suppliers, customers, in fact anyone in your value chain to have rapid and secure access to your digital capabilities.

As TechVision Research has been emphasizing for the past several years, a combination of loose-coupling, virtualization and federation are critical characteristics for digital transformation and enterprise IT as a whole.  Secure, API-enabled microservices create an ‘abstraction layer’ that can dramatically simplify application development, integration, data security, privacy and operational support. In this model, IT services and functions that are enabled in a secure, easy-to-consume manner. As new protocols, techniques and infrastructure approaches emerge (e.g., blockchain, distributed ledgers, verified claims), and old techniques fade away the impact on the IT infrastructure will be minimized because of such loose-coupling.

But how does an organization actually support the business with a cavalcade of API-enabled microservices? That is something that takes a bit of structure regarding how actual business-supporting products can be created in such a way as to fully leverage an Agile software development, security and operations ecosystem. What becomes necessary is a paradigm shift whereby enterprise business units think in terms of products that rely on/leverage microservices to support the business logic within their unique applications.

To be clear: applications may be unique in support of specific business units’ use cases, but the services/microservices that are used to build unique applications are themselves more general-purpose and leverageable across many different unique applications. This helps to establish and containerize a common set of services that can be better managed, maintained, secured and monitored. The applications, then, become the Products that the business units develop to support their mission. In parallel, more centrally-governed group functions, which exist at a higher level than the business units, become Products provided by enterprise (non-business unit) groups such as Information Security, Data Management, etc. Because TechVision’s focus is strongly centered on security and IAM, we’ll focus on these areas throughout the rest of this report. However, the principals are identical regardless of the technology focus.

How does this work? Take for example that the enterprise’s Information Security group can develop and maintain Products that enable identity and access management, threat and vulnerability management, application security, and so forth. The business units incorporate aspects of such “group supported Products” into their own business critical Products, reflecting a more general building-block approach to development that facilitates Agile principals and consistency in functionality.

Within Products, then are specific Services that can be cherry-picked by the business units to create the desired applications, or Products. From an Information Security perspective, the Services they might include user authentication, authorization, boundary defense, malware detection, etc.

Once the Services are identified that will comprise the Products, the granularity increases in the establishment of specific Capabilities necessary to support each Service. In essence, Capabilities are the lowest kernel of functionality that is to be provided by Service, to support Products. From an Information Security viewpoint, Capabilities might include multi-factor authentication (MFA), single sign-on (SSO) and user self-service credential management within the Authentication Service, within the Identity and Access Management Product.

From this level of detail, the serious work of identifying APIs that will be enabled and secured across the enterprise Application Development ecosystem so that Capabilities can be embedded within Services, which can then be embedded within Products, which may then be embedded within business unit Products. Typically, this exercise requires the enterprise to take stock of their existing capabilities across the Information Security spectrum to determine whether the capabilities are mature enough – or even exist, so that the creation of Services and Products can commence.

Introduction

The rise of application programming interfaces (API’s) and their usage across the business landscape had been 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. API’s are certainly not new to most software developers, being the way in which most capabilities within systems are accessed. With the global pandemic shifting typical workforce and customer interactions to almost 100% online, API’s 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.

TechVision has produced detailed reports on API management, microservices and DevOps, including “State of Application Programming Interfaces (API) Management and Security”, “How Microservices Can Improve Your IAM Strategy”, “A Practical Guide to DevOps”, “Microservices Enterprise Level-Set” and many more. In essence, we report that the rapid rise of cloud architectures supporting the Digital Enterprise has had a profound impact on most organizations’ development strategy, security posture and operations focus – increasingly encapsulated under the banner of DevSecOps – short for Development, Security and Operations. These distributed architectures and the dispersion of security and logical control and monitoring 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.

Add to this the number of internal and external (third-party) API’s which are becoming a normal way to accelerate and grow organizational capabilities, and the management becomes challenging. However, when done well, API management and security allows 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 API’s 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 of their services through API’s, 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. Digital transformation can be broadly described as a significant overhaul of existing IT infrastructure to adopt a much more flexible, adaptable and scalable set of capabilities that can allow enterprises to quickly deploy or decommission online services with minimal impact to development and operations – which is precisely what we’ve been advocating for IAM transformation.

Over the past decade, an intense transformation of IT has taken place with the widespread adoption of cloud computing, SaaS and PaaS integration, system and infrastructure virtualization, mobility, federation, IoT, IAM, external security/monitoring and more. Add to this the growth in managed IT services supported by 3rd parties and the typical enterprise IT environment now looks nothing like it did even 5 years ago.

As part of this transformation, a renewed focus has been levied on the Development and Operations groups responsible for developing, integrating and maintaining IT services for all constituents, whether internal or external to the organization. Traditionally, these two groups operated in a somewhat isolated fashion, with Development working feverishly in its own silo, releasing new “IT products” (whether developed in-house or integrating commercial-off-the-shelf solutions) to the IT Operations staff – who are then challenged with maintaining these products. Such a waterfall model for application development has often lead to severe disconnects between Development and Operations, because the process is non-iterative and comprises no viable near-real-time feedback loop.

We call these symptoms “DevOps anti-patterns”, which have become prevalent across projects and platforms, typically resulting in infrequent releases with traditional change controls leading to long lead times, and manual, time-consuming, painful, and tedious delivery processes, which act as great inhibitors to digital transformation.

From our perspective, one of the most significant results of a DevSecOps model is improved accessibility of application security and IAM functions, such as user/thing authentication, authorization, lifecycle management and audit readily available to application developers and integrators. Without an effort to move toward a better DevSecOps paradigm, enterprises will continue to suffer from siloed applications and services that will perpetuate the issues of disconnect that largely exist today.

In this report, TechVision Research dives into the architecture and best practices for moving to an API economy supporting DevSecOps. The benefits of adopting this model will enable enterprises to provide more efficient, consistent, seamless and secure application capabilities.  We’ll start with Microservices.

What Are Microservices?

TechVision Research describes microservices and a microservices architecture as simply a way of designing applications as independently deployable services. Microservices start with a focus on business capabilities, not technology. It is an architecture style of developing a single application based on small, self-contained set of services running their own processes and communicating via a lightweight mechanism. There is limited centralized management or governance of these services and they can be written in different languages and use different storage approaches.  Some key takeaways of this approach are:

1. Microservices define clear boundaries, but keep these boundaries small and not corrupted
2. Microservices are independently deployable by fully automated deployment machinery, which is particularly useful in deploying services on cloud-based PaaS environments, such as Amazon Web Services, Google and Microsoft Azure.
3. Microservices may be written in different programming languages and use different data storage technologies
4. Microservices support security, monitoring, and associated hooks to deploy code across multiple services

As mentioned above, TechVision published a report titled “Microservices Enterprise Level-Set” that provides a much deeper explanation of microservices and strategies to broadly leverage this approach. For the purposes of this report, microservices are components that can be thought of as independently replaceable and upgradeable building blocks or services.

Now that we’ve described microservices at a general level, we’ll next focus on describing how microservices and Information Security fit together and the benefits to the enterprise.

Defining API-Driven Architecture and Development

From our vantage point, we see many of our customers struggling with the establishment of Digital Enterprise “products”, “services” and “capabilities” that their DevSecOps, microservices and APIs need to enable in support of the business.  Think of these in a hierarchical fashion, as follows:

• Business Capabilities – describes what a business does to create value to customers and colleagues with a group of interconnected products. Examples of business capabilities include; financial, sourcing, pricing, product design, loyalty, logistics, fulfilment, supply chain. Enterprise Architects use Business Capabilities to illustrate the over-arching needs of the business in order to better strategize IT solutions that meet those business needs.
• Product – something that is created through a process that provides benefits to a customer or colleague and provides value to a business capability.
• Service –something that has a singular function (single responsibility), includes business logic and exposes itself by an API. It can be looked after by a product team. Services are components that can be thought of as independently replaceable and upgradeable building blocks. These components are independently built and managed and are assembled to create the more complex applications as required by the business. A key objective is that a change to one component doesn’t require the entire system to be redeployed, as is the case with legacy, monolithic applications. Services are defined as individual microservices or a small group of bundled microservices that are used to build products.
• Capability – are the individual technical building blocks that need to be integrated in order to establish a service. For example, most applications require authentication of the end user (whether enterprise or consumer). Authentication, therefore is a service, and the capabilities (technical building blocks) needed to enable this Authentication Service would typically include username/password, multi-factor authentication (MFA), single sign-on (SSO), social media login, and so forth.

With this high-level introduction, let’s now dive deeper into the creation of a Reference Architecture for an API-driven DevSecOps environment.

Defining Reference Architecture Patterns

TechVision has published numerous Reference Architecture patterns for our customers’ use in developing their Information Security, Identity and Access Management, Workforce Collaboration, Innovation strategies and many more. The focus of this is help you build an effective, secure API-driven microservices environment. Therefore, let’s briefly review the TechVision Reference Architecture for Information Security, as that will provide a comprehensive view of the security and IAM products, service and capabilities necessary to support most organizations’ business capabilities.

Starting Point: Information Security Reference Architecture

In the TechVision Research document titled “Security Reference Architecture”, we describe the business contextual view of the Reference Architecture (see Figure 1, below), which identifies the business context for an enterprise security program, management security controls, and enterprise security infrastructure required for a Digital Enterprise. This includes:

• The global, multi-cloud and edge IT presence that provides all business IT capabilities for workforce users, business processes, customers, suppliers, partners, and the enterprise IT/OT resources.
• The business strategy, regulatory, risk, and capabilities context within which the organization’s IT environment exists, and the security program operates.
• The enterprise executive, governance, administrative functions that control the security program, or with which the program must align.
• Defined and authorized endpoint management and security program, governance, and risk management processes overseeing security policy, controls, and awareness.

Distributed security capabilities (represented by the dark green squares in Figure 1, below) indicate the logical location of security controls through the hybrid multi-cloud stack (aka “digital estate.”) The enterprise security control systems needed to provide centralized, or logically consistent, management over the distributed endpoint management and security capabilities.

Figure 1: Security Reference Architecture Business View

Taking this further, Figure 2 below depicts the full subset of business IT processes related to information security. These processes are highly inter-related. For example, Risk Management assesses some of the business’s top risks by analyzing risks to its most critical assets as identified in a Business Control Management (BCM) Business Impact Assessment’s (BIA) inter-dependency analysis. The BIA sub-process, in turn, cannot be performed without obtaining input from the Asset Management process or system. Asset management in turn is necessary to maintain the asset inventory required for other processes, such as vulnerability management. Additionally, access management for endpoints relies on IAM life cycle management processes. The point of this is to highlight the levels of dependency that exist among processes managed by different groups.

Figure 2: Security-Related Processes View

The above figure gives the reader a sense of the complexity of the security processes necessary to secure an enterprise. The security related processes will also depend on a variety of underlying mechanisms such as IAM, information protection, vulnerability management and underlying network security controls.

This brief overview of the Security Reference Architecture sets the stage for the identification of specific capabilities that are needed to instantiate the architecture model into software development and operational technology.

Security Capabilities

The Security Reference Architecture is a master template that identifies the information security capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for security functions, which can then be refined over time. ¬¬¬ It starts with a high-level template as follows and then drill deeper and deeper in developing more detailed templates and responding to requirements.

Figure 3: Top Level Security Reference Architecture

These capabilities are described at the highest level as:

• Interact – how end-users, application developers and non-person users interact with the endpoint management and security platform.
• Access and Protect – capability of protecting applications and data from compromise, and the policies and rules that define the conditions associated with accessing protected assets.
• Manage – the capabilities required to manage and upgrade the security solution itself.
• Measure – the capabilities required to audit and improve security platform performance.
• Store – the capabilities required to share identity information and relationships between the components of the security solution.

Each of these capabilities can then be further broken down into a more detailed set of capabilities based on your organization’s unique requirements and future state needs as described below.

Figure 4: Sample Enterprise Security Capabilities

In this corresponding level of detail, we provide an understanding of the types of security capabilities that comprise each layer. This level also illustrates some of the typical “Endpoint Clients”, such as end users (e.g., Employees, Contractors, Application Developers, partners, etc.) and IT services across multiple business units that interface with the Interact Layer. This end user interaction can be via:

• Corporate Owned Devices (COD)
• Personally Owned Devices (POD)
• PC and laptop workstations
• Other mobile devices

This functional Capabilities template is the foundation for the Enterprise Security Reference Architecture.

IAM Capabilities

Similarly, different enterprises use different IAM capabilities in different ways to meet different protection needs. And they do so differently for different content and business functions because of the different risks and potential consequences associated with failures and costs associated with protection. One size does not fit all.

Figure 5: Sample Enterprise IAM Capabilities

Remember, the Reference Architecture is not focused on the actual implementation of things that carry out these controls. Rather it is a model of what the controls are, how they work, and how they interact to assure the utility of content. Now, let’s investigate how to take atomic level Capabilities and incorporate or package them as discrete Services, to be then integrated into myriad Products.

Product, Service and Capability Patterns

As TechVision Research has been emphasizing for the past several years, a combination of loose-coupling, virtualization and federation are not only critical elements in ‘the future of identity management’ – but also for enterprise IT as a whole. Secure, API-enabled microservices create an ‘abstraction layer’ that can dramatically simplify application development, integration, and operational support. In this model, IT services and functions that are enabled in a secure, easy-to-consume manner. As new protocols, techniques and infrastructure approaches emerge (e.g., blockchain, distributed ledgers, verified claims), and old techniques fade away the impact on the IT infrastructure will be minimized.

But how does an organization actually support the business with a cavalcade of API-enabled services or microservices? That is something that takes a bit of structure regarding how actual business-supporting products can be created in such a way as to fully leverage an API-enabled microservice ecosystem. What becomes necessary is a paradigm shift whereby enterprise business units think in terms of products that rely on/leverage microservices to support the business logic within their unique applications.

To be clear: applications may be unique in support of the specific business unit’s use cases, but the microservices that are used to build unique applications are themselves more general-purpose and leverageable across many different unique applications. This helps to establish a common set of services (microservices) that can be better managed, maintained, secured, and monitored. The applications, then, become the Products that the business units develop to support their mission. In parallel, more centrally-governed group functions, which exist at a higher level than the business units, become Products provided by enterprise (non-business unit) groups such as Information Security.

For instance, the enterprise’s Information Security group can develop and maintain Products that enable identity and access management, threat and vulnerability management, application security, and so forth. The business units incorporate aspects of such “group supported Products” into their own business critical Products, reflecting a more general building-block approach to development that facilitates Agile principals. Below, an example of a hypothetical organization’s Information Security Product/Service/Capability portfolio is shown in Figure 6.

Figure 6: Information Security Products and Services

As illustrated above, within Products are specific Services that can be cherry-picked by the business units to create the desired applications, or Products. From an Information Security perspective, the Services they might include user authentication, authorization, boundary defense, malware detection, etc.

Once the Services are identified that will comprise the Products, the granularity increases in the establishment of specific Capabilities necessary to support each Service. In essence, Capabilities are the lowest kernel of functionality that is to be provided by Services, to support Products. From an Information Security viewpoint, Capabilities might include multi-factor authentication (MFA), single sign-on (SSO) and user self-service credential management within the Authentication Service, within the Identity and Access Management Product.

From this level of detail, the serious work of identifying APIs that will be enabled and secured across the enterprise Application Development ecosystem so that Capabilities can be embedded within Services, which can then be embedded within Products, which may then be embedded within business unit Products. Typically, this exercise requires the enterprise to take stock of their existing capabilities across the Information Security spectrum to determine whether the capabilities are mature enough – or even exist, so that the creation of Services and Products can commence. A sample of this type of exercise is illustrated below in Figure 7.

Figure 7: Capabilities Maturity

Note the sample show above uses the standard “red/amber/green” color key to indicate the organization’s current level of maturity. This exercise is extremely important because it quickly tells you where you need to invest resources in order to bring the level of Capabilities up to where they can be incorporated into robust Services.

Creating User/Developer Stories

From a Product perspective, it is imperative to develop the User Stories that describe what the user (in most cases, a Corporate or Business Unit Developer) wants. From these Developer Stories, we can determine if Infosec can develop/integrate, maintain and make available (principally via APIs) the Services and Capabilities that comprise each Product. Examples of such Developer Stories are as follows:

1. As a Developer, my data must be protected from unintentional disclosure to other customers or external parties.
2. As a Developer, I need the application to allow passphrases and/or difficult passwords.
3. As a Developer, I need all connections to an application that contains my user data to be authenticated.
4. As a Developer, I need password entry and other fields containing sensitive information to disallow caching or auto-complete.
5. As a Developer, I need the ability to securely change or reset user password without worrying that my account(s) can be hijacked by a malicious party.
6. As a Developer, I want my account credentials to be created, stored and transported securely so that they can’t be guessed, intercepted or reused by an attacker.
7. As a Developer, I need an additional factor of authentication to protect my users’ accounts from unauthorized access. I want step-up authentication for risky transactions and changes to accounts.
8. As a Developer, I want a user logout feature. I need user sessions inactivated after logout and timed out after inactivity or a time limit set by an administrator.
9. As a Developer, application sessions must be unique and resistant to hijacking by a malicious actor.
10. As a Developer, accounts must only be able to perform those actions or access resources explicitly granted to them.
11. As a Developer, I want the application to validate input to be correct and fit for the intended purpose.
12. As a Developer, I need access to application secret keys managed securely.
13. As a Developer, I need a suitable level of entropy in generating keys to prevent attacks.
14. As a Developer, I want the ability to collect logs in a standard format for a SIEM or other security tool, which contain information such as user and administrative access, but not sensitive information such as passwords or PII.
15. As a Developer, I want the ability to specify retention policies for certain RESTRICTED or sensitive data so that this data can be deleted at the end of the retention period.
16. As a Developer, I want the application to detect and alert when there are unauthorized attempts to access my data, login or make changes.
17. As a Developer, I want the application to provide an audit trail of administrative actions, user modifications or accessing PII.
18. As a Developer, I need web applications to be resistant to attacks by malicious actors that would impact availability or extract user data and/or credentials.
19. As a Developer, if an application component is vulnerable, I want the malicious activity against it to have minimal or no impact on the rest of the application.
20. As a Developer, I want the application to be free of back doors, Easter eggs, and logic flaws, which could be abused by an attacker.
21. As a Developer, I want the application to handle untrusted data securely.
22. As a Developer, I want the application to enforce the Same-Origin Policy for content.
23. As a Developer, I want my mobile client to enforce the same level of security controls as other Software company applications.
24. As a Developer, I want the mobile client to protect user data.
25. As a Developer, I want the mobile client to use secure authentication methods.
26. As a Developer, I want the mobile client to observe the principle of “least privilege.”
27. As a Developer, I want the mobile client to use secure coding techniques.
28. As a Developer, I want the web service to implement proper authentication, authorization and session management.
29. As a Developer, I want the web service to validate input.
30. As a Developer, I want the web service to ensure confidentiality and integrity of the communication.
31. As a Developer, I want a REST service protected from Cross-Site Request Forgery (CSRF) attacks.
32. As a Developer, I want all components of the application to have up-to-date libraries and platforms.
33. As a Developer, I want the application configuration to be “secure by default.”
34. As a Developer, I want the application secured and hardened by default so that user changes do not expose security vulnerabilities or flaws with underlying systems.

 

Of course, many of these Developer stories are fungible depending on your business requirements, but you get the idea. Product applications should not be developed without user stories, and Information Security Products should not be developed without Developer Stories – if they truly want to support Developers and facilitate a stronger security posture throughout the development and operations processes.

Defining the Services

The next step involves “connecting the dots”.  All of the Products, Services and Capabilities are useless if they do not satisfy any requirements.  As will be illustrated in the following diagrams, this procedure involves identifying the specific Capabilities, Services and Products that will be needed to support the story (i.e., requirement(s)).

The first example, below, is Identity Management-centric and the developer would need access (e.g., via API) to the services/capabilities indicated by the red dots in order to satisfy this user story #7 “As a Developer, I need an additional factor of authentication to protect my accounts from unauthorized access. I want step-up authentication for risky transactions and changes to accounts”.

Figure 8: Authentication Developer Story Mapped to Capabilities/Services/Products

In the next example, the business unit developer would need access (e.g., via API) to the services/capabilities indicated by the red dots in order to satisfy the developer story # 12 “As a Developer, I need access to application secret keys managed securely”.

Figure 9: Key Management Developer Story Mapped to Capabilities/Services/Products

In the following example, the developer would need access (e.g., via API) to the services/capabilities indicated by the red dots in order to satisfy this user story # 34 “As a Developer, I want the application secured and hardened by default so that user changes do not expose security vulnerabilities or flaws with underlying systems”.

Figure 10: Key Management Developer Story Mapped to Capabilities/Services/Products

The key takeaway here is to understand that by making these standard cyber security capabilities available as microservices, DevSecOps can make incremental, regular changes (as simple as a single change or patch to one line of code) without disturbing the entire IT infrastructure. This sets the stage for the continuous development and continuous deployment models that are a core part of the DevSecOps approach.

Granular Solutioning: Containers and API Gateways

Delivering security (and IAM) functionality via microservices involves the identification of discrete Capabilities such as user authentication within a compact, single-purpose code set.  This single-purpose security Service can then be more straightforwardly and securely integrated into an in-house developed or COTS application. Typically, individual, related Services are ‘packaged’ in such a way using a container structure or an API gateway.

Containers

In many cases, applications may be ‘containerized’, so that once a business function (e.g., Product) is successfully enabled through a series of interconnected Services, that business function can be easily and quickly leveraged across the enterprise as a cloud service – whether an internal, external or hybrid cloud. A container is the bundling of an application’s code, configuration, and dependencies into a single object. It can be thought of as operating system-level virtualization in that they are designed to run anywhere and therefore are independent of the external environment.

Containers are intended to be very lightweight and function as a unit of software delivery in support of Services or microservices. Containers, therefore, are typically comprised of one or more microservices that taken together perform discrete business IT functions in the form of easy to use building blocks that deliver environmental consistency, operational efficiency, developer productivity, and version control.

In the world of IAM, a container called “Authenticate Identity” may be deployed with the contents of this particular container being three or four independent microservices.  Each of these microservices will perform one specific function within a typical authentication event, such as password authentication, MFA, SSO/federation and so on.  For more detailed information regarding containers, please see the TechVision Research reports titled “Microservices Enterprise Level-set” and “A Practical Guide to DevOps”.

API Gateways

API gateways are used to integrate multiple related Capabilities into a logically discrete and addressable Service. An API gateway functions as an “API wrapper” such that individual Capabilities behave as a single Service to the client. An API gateway is often referred to as a “façade” that provides simple API interfaces to a complex subsystem (e.g., the Information Security and IAM infrastructure). It essentially decouples the interface that developers see from the underlying implementation. In addition, the API gateway can perform several additional tasks such as API limit throttling, logging, security, etc.

API gateways provide consistent RESTful application programming interfaces (APIs) for mobile and web applications to access backend services, whether on-premise or in the cloud.

Figure 11: API Gateway Servicing IAM Functionality

As shown in Figure 11, API gateways provide consistent access to identity services for mobile, web, service account and IoT devices. All client requests go through the API gateway via a RESTful interface. The API gateway then routes requests to the appropriate Service. These requests are often handled by invoking multiple Services and aggregating the results, as illustrated by multiple connections (e.g., lines) emanating from a single Service to multiple underlying infrastructure Capabilities. Since this gateway provides client specific APIs, it reduces the number of round-trips between the client and application which reduces network latency and it also simplifies the client code.

There are a number of vendors that offer API gateways; IBM, Akana, Apigee, and CA all have  strong solutions. Additionally, Amazon provides an API Gateway within AWS that handles the tasks involved in accepting and processing large pools of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management. Google offers Google Cloud Endpoints with similar functionality, while Microsoft offers Azure API Management as a solution for publishing APIs to external and internal customers. The combination of API gateway vendors and the big three clouds (Amazon, Google and Microsoft) provide a strong set of services for enterprises moving towards microservices and DevOps.  For a much more detailed discussion on API gateways, please consult the TechVision Research report titled “State of Application Programming Interfaces (API) Management and Security”.

Whether using containers or API gateways, the message here is that the DevSecOps model requires a viable means of integrating discrete Information Security functionality into a set of unique but consistently applied callable Services. This starts with breaking down security and IAM functionality into atomic-level Capabilities and then re-assembling them into a series of callable Services. This type of approach supports the true essence of what we characterize as loose-coupling and flexibility to support Agile development. DevSecOps allows necessary and regular changes to production code to regularly refresh the enterprise security capability. This is in stark contrast to searching for and replacing logic in multiple siloed instances of redundant security functionality that may take years to deploy.

Recommendations and Best Practices

By acknowledging that application development is shifting toward leveraging API-enabled microservices based architectures, enterprises need to understand that this evolution involves information security in a not-so-minor way. Security microservices can simplify how applications interact with identity information and security functions while improving security and consistency across applications. This approach can take the enormous burden of complexity off the application developers’ shoulders. These services can also be readily updated and consistently available to any appropriate service consumer (e.g., Product/application).

Key enterprise recommendations and best practices for an API-driven architecture and deployment strategy include:

1. Organizations committed to a digital transformation strategy should spend time focusing on the DevSecOps paradigm discussed earlier in this report. An iterative process from design, development, production, and retirement should better fit with an Agile development model than the traditional waterfall model. You should start by examining your own development and operations processes and determine whether to embark upon an Agile Development program. If you move forward with Agile/DevSecOps you should:
   • Ensure the program is governed properly. Solidify stakeholder buy-in from the top-down (key executives and application ‘owners’) as well as the bottom-up (application developers and operations).
   • If the organization is already embarking on an agile DevOps model, ensure that information security Capabilities and Services are considered key building blocks to this strategy – and this includes IAM.
2. Develop a Product/Service/Capability model as discussed here to better establish the necessary guardrails for embracing the Agile software development paradigm. Applications should be inventoried to understand the current, inherent complexity (assuming there is) of security integration and to begin the process of disentangling security and IAM functions from siloed code supporting these existing applications. Specific steps include:
   • Identify commonality across the many ways existing applications perform security functions such as identity authentication, authorization, lifecycle management, code testing, patching, vulnerability management and so forth.
   • The commonalities identified will lead to a smaller subset of key security Capabilities that would be better served as API-enabled microservices that are easily and securely callable from these applications – business unit Products.
   • Understand that in some cases, existing applications will be very difficult – if not impossible, to refactor to remove the siloed security functionality. Applications that fall into this category should be risk-ranked to fully capture and assess the risk of leaving them as-is rather than assuming the cost to re-write the applications.
   • Develop a roadmap for application refactoring to prioritize and resource the DevSecOps effort, understand the residual risk while in the process of refactoring and identify possible mitigation approaches (e.g., increasing application activity monitoring for high-risk applications that remain further down in the roadmap for reasons such as complexity, budget, resourcing, etc.)
3. Thoroughly assess your existing information security and IAM infrastructure to determine its ability to enable all necessary services to be called via RESTful endpoints from within applications.
   • Request that your current security vendors provide information regarding their ability to function in an API-enabled microservices oriented IT ecosystem.
   • Request that your security vendors (or systems integrator(s)) provide contact with other customers of theirs who have embarked on a similar journey, to fast-track your own deployment.
4. Start with a smaller, well-contained deployment strategy to avoid the pitfalls of the boil-the-ocean ‘strategy’:
   • Pick a few lower-risk applications to begin with, establishing a proof-of-concept with an eye on operationalization.
   • Once the concept has been proven, identify the higher risk applications from your deployment roadmap to transition first to bring immediate value and risk reduction.

Summary

What does it mean to be an Agile development shop? Many of the organizations that TechVision Research works with on an ongoing basis have adopted an Agile strategy over the past several years – with the number growing more rapidly day-by-day. But becoming an Agile shop should indicate that your organization has taken a deep and focused look at digital transformation and has determined that the place to start this transformation is to leverage APIs that can be packaged as Products and Services across multi-tenant, elastic cloud infrastructure delivery platforms.

It also means that your organization has inherently taken on a more loosely-coupled, federated and dynamic (e.g., virtualized) application integration and delivery model. As TechVision Research has been expounding for the past three years, loose-coupling, virtualization and federation are the keys engendering the Digital Enterprise.

We have described a path toward evaluating current security services in a digital transformation context, breaking up monolithic services into smaller capabilities and leveraging these to provide more scalable, dynamic, and available security Products that are API-enabled to facilitate Agile development.  To walk the walk, an organization must consider the importance of information security Services and Capabilities that are enabled in a secure, easy-to-consume manner. In this way, as new protocols, techniques, and infrastructure approaches emerge and old techniques fade away, the impact on the enterprise security infrastructure will remain minimal. Doing so is the surest way to ‘future proof’ your security and IAM posture.

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 it. 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 when they carry out a product and strategy review and assessment, a requirement analysis, a target market assessment, a technology trend analysis, a go-to-market plan assessment, or a gap analysis.

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

About the Authors

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM.  Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. He was President of Burton Group from 1999 to 2010, the leading technology infrastructure research and consulting firm through the sale of Burton to Gartner.

Mr. Rowe has personally led over 100 consulting engagements, 50+ educational seminars, published over 50 research reports/articles and led three significant technology industry initiatives. His combination of business skills and his deep understanding of technology provide a balanced perspective for clients. Core areas of focus include identity and access management, directory integration, cloud computing, security/risk management, digital transformation, IT business model changes, privacy and blockchain/distributed ledger.”