Improve the Security of Application Integration by Focusing on Identity
Application integration involves connecting applications across cloud and on-premises, requiring systems to expose data and functionality, raising privacy and security risks. Application leaders must improve access control, data security and API protection in their application integration strategy.
Overview
Key Challenges
· It is difficult to deliver secure application integration as a whole when citizen integrators in digital marketing, sales or line of business (LOB) teams are independently creating many simple integrations between applications.
· Exposing data from systems of record as part of application integration, as well as connecting data between on-premises and cloud applications, increases privacy risks for data both in transit and at rest.
· Attackers have begun to discover and exploit unsecure APIs to access applications and data, representing a major threat because today, application integration often involves creating APIs to open up access to applications and data.
· Integration tools such as integration platform as a service (iPaaS) products, enterprise service bus (ESB) products, and API gateways are complex and may be configured incorrectly or unsecurely, or may contain unpatched security vulnerabilities.
Recommendations
As an application leader responsible for application integration, you should:
· Work with your enterprise security team to apply identity management to integrations across your organization, not just integrations performed by a central integration team.
· Avoid passing sensitive data in integration flows by first assessing risk, then applying techniques such as data masking, tokenization and encryption.
· Apply API security to protect APIs across your entire integration architecture, including usage of software as a service (SaaS) APIs.
· Assess vendors on the security of their integration offerings, such as iPaaS and ESBs, by taking certifications, vulnerability assessments and platform operations into account.
Strategic Planning Assumption
By 2023, 65% of large organizations will enable their non-IT personnel to perform integration tasks.
Introduction
Application leaders responsible for integration are pressured to enable new technology investments driven by business objectives; such as improved customer experience and remote employee enablement. These new investments are increasingly cloud-based, driving requirements for on-premises and cloud systems to exchange data, or, increasingly, for cloud-to-cloud integration.
However, application integration brings with it security risks, such as the risk of a data breach when integrations involve opening up access to systems of record. Data breaches can have a devastating financial and reputational impact and often lead to those responsible losing their jobs. How can application integration be secured? The answer is to first identify where application integration occurs within the organization, then identify which tools are used, and finally apply security best practices.
Analysis
Work With Your Enterprise Security Team to Apply Identity Management to Integrations Across Your Organization
42% of organizations report that integration flows are being created by LOB staff (e.g., application administrators, analysts or engineers) and 39% report that integration flows are being created by business users. This trend of “democratization” of integration is likely to continue, with the central integration team taking on a role of enabling “citizen integrators”.
This proliferation of application integration across the organization leads to a risk that security of integration is overlooked. When integrations are built by individuals to “just work,” without regard for security, this can lead to exposing infrastructure to unauthorized access or data leaks. To avoid this risk, it is vital to apply security to integration flows built by multiple individuals and teams in the organization, not just by a central integration team. How can this be done? The key is to make use of enterprisewide identity and access management (IAM), and apply to outbound, cloud-to-cloud and inbound integration flows. Let’s first look at the case of outbound and cloud-to-cloud integration flows.
Securing outbound and cloud-to-cloud integration flows
A key decision factor in securing integrations is to choose where credentials such as user passwords and keys to access SaaS services are stored. There are two choices:
1. Hardcode user passwords and keys into application integrations themselves
2. Connect integration tooling to identity and access management infrastructure
When deciding between the two options, assess the risks if passwords or keys are compromised. Consider these two scenarios:
1. An integration to a cloud service which uses a user’s username and password to access the service. For example, when a business user puts their Salesforce credentials into an integration tool.
2. An integration to a cloud service or on-premises system which uses an administrator or “system” account for access. For example, when an application administrator in an LOB team wishes to connect to a database or to an infrastructure as a service (IaaS) cloud service such as Amazon AWS.
In the first scenario above, if the integration flow is compromised then anything which this user (and this user alone) can access will be available to the attacker. However, in the second scenario, if this integration flow is compromised then the impact is potentially much greater.
This risk assessment directs the choice of whether to link application integration flows to enterprisewide identity and access management (IAM). You may ask: “Why not just link all integration flows to IAM, regardless of risk?” The reason is because it can add complexity, especially where technologies such as SAML and OAuth are used. A risk-based approach allows the choice to be made based on the impact of a security breach.
Using IAM with integration flows takes a number of forms:
· Creating user IDs specifically for integration flows, so that end-user, administrator credentials, or “system accounts” do not have to be used.
· Applying role-based access control (RBAC) to application endpoints so that access is limited based on user entitlements. For example, enforcing that LOB users may only have access to a subset of customer data.
· Using single sign-on between integration tools and applications, instead of hardcoding passwords.
Work with your organization’s application security team to enable these IAM integrations.
Securing inbound integration flows
Integration scenarios often involve cloud applications, which need access to on-premises data and applications. In many cases, this is secured using the capabilities of the cloud service, such as Amazon’s VPC (Virtual Private Cloud) or an Azure Virtual Network (VNet).
Avoid Passing Sensitive Data in Integration Flows Without First Assessing Risk
Data security needs must balance risk with the business requirements of application integration. A continuous adaptive risk and trust assessment (CARTA) model should be applied to data security.
· Data redaction is a data masking technique that replaces data with a chosen redaction character such as “X.” It is an important technique for protecting elements of unstructured data, such as sensitive parts of a document.
· Data masking involves generating fictitious, yet syntactically valid data, to obscure sensitive data used in data integration. For example, a customer phone number may be data-masked with a generated phone number that matches the data format requirements for a field in a SaaS application.
· Data tokenization and format preserving encryption (FPE) are designed to be reversible, unlike data masking. This enables data to flow to a destination as part of an integration flow; with sensitive data such as patient records selectively tokenized or encrypted. Then, in a separate integration flow or later in the same integration flow, the original plaintext data can be replaced.
Apply API Security to Protect APIs Across Your Entire Integration Architecture
The top business goal of API strategy is to enable integration. This often involves “API-enabling” systems of record to open up access to data. However, there have been many examples of APIs being exploited.
Securing APIs typically involves the usage of multiple tools, including API gateways and web application firewalls. A key step is to create API security policies which describe the security steps applied to API access. However, avoid creating many different API security policies e.g., one for each API used by your organization. Doing so creates complexity and is difficult to manage. Instead, create reusable security policies, which can be applied to different integration scenarios.
In scenarios where anomaly detection of API traffic used for integration is required, specialized API security products may be used. Two specialist API security vendors, Salt Security and Data Theorem. Others include Imvision, which applies a natural language processing (NLP) approach to detecting unusual API usage, 42Crunch which enables API definitions to be analyzed for security, and CloudVector which detects API traffic using its “API Shark” tool.
When securing APIs for integration, also consider the APIs your organization uses, not just the APIs your organization provides. Access to third-party APIs such as these must also be managed and secured.
Assess Vendors on the Security of Their Integration Offerings
The trend in application integration platforms is toward cloud and hybrid. This means that even when an organization wishes to deploy an on-premises application integration platform, it is likely to have a cloud dependency. This cloud “tethering” may take the form of a cloud-based control plane, which is where integration flows are defined and managed, and where analytics may be accessed. The runtime component, used to implement the integration flows themselves, may be deployed on-premises.
