Monitoring and attestation

To verify the security state of the COTS device, the operating system, the POS application, our SDK, and the card reader when mobile payments take place, we created a monitoring and attestation (M&A) system. This system monitors for security issues at runtime. When an issue is detected, a threat policy kicks in automatically. The threat policy can involve stopping transactions and preventing further transactions.

This chapter provides the details of our M&A system.

Topics to cover (temporary section)

• Attestation policy: how we configure, deploy, and operate the M&A system.
• Process to deliver updates.
• Baseline COTS platform (refer to Architecture overview?) including enforcing a mandatory access control framework; a trusted boot mechanism that validates the OS authenticity; validation of an application cryptographic signature upon installation of applications; isolation of the interfaces and memory spaces used by different applications.
• Procedure for managing the COTS platform baseline: roles and responsibilities, acceptance/removal of COTS platforms + communication about that.
• Security review process; detection, classification, and mitigation of threats and vulnerabilities.
• Operational monitoring procedure (done)

M&A architecture

Update text for own solution; create new diagram with new name (same for Android and iOS?)

The Android mobile payments SDK includes an security module that scans for threats and protects transactions. To scan for security issues at runtime, the security module includes an M&A component that uses zDefend Monitoring. This third-party SDK works both with and without network connectivity, and includes zDefend Console. The console records devices and real-time threats, and enables managing threat policy levels. The attestation is taken care of by combining the zDefend Console with the attestation design that we implemented on the Adyen backend.

The following diagram illustrates the relationship between the SDK, our backend, and the merchant-facing /sessions API for establishing a secure session.

At Checkout POS, we use the session token from the merchant server to validate and authenticate transaction authority. Then, before a payment transaction is started, we make a call to the /configuration/resources endpoint to retrieve a configuration snapshot, which contains the keys needed to initiate the M&C component in the SDK's security module. This component captures any new detected threats, and also performs synchronous checks during the use of the SDK, to stop transactions if needed. For details of the M&A component, see Prevention of further processing.

The data we collect for monitoring and attestation can be traced back to the specific COTS device from which it originates based on the installation ID. The installation ID is collected in the mutual authentication flow.

Attestation mechanism

Update text for own solution; create new diagram with new name (same for Android and iOS?)

To understand how zDefend and the backend attestation work together, it is important to know that transactions are completed over Adyen’s stateless cloud server in a series of API calls:

1. To start the transaction, the SDK calls the /nexo endpoint.
2. Depending on the transaction flow, the SDK makes /callback calls to progress the transaction.
3. To get the end status of the transaction, the SDK makes a /complete call.
4. When applicable, the SDK sends aggregated local logs to the backend by making a call to the /logs endpoint.

Any threat detected at any point in this transaction process is recorded in zDefend Console. The backend ThreatRuleEngine pulls the zDefend logs and calculates if the transaction must be stopped.

The attestation flow is as follows:

1. Every minute or so, the Checkout POS web app pulls any reported device threats from zConsole.
2. Checkout POS maps these threats by installation ID to the incoming API request in the transaction flow (like a /nexo call or /callback call).
3. The ThreatRuleEngine calculates if the set of detected threats is safe or unsafe.
4. If unsafe, an Attestation failed exception is thrown and the current payment progress stops.

Coverage

Check if still up-to-date

Our M&A system covers the following information:

• If the COTS device is rooted, jailbroken, or operating in developer mode.
• Any modification or tampering attempts of the MPoC SDK, MPoC application, and COTS execution environment.
• The version of the MPoC SDK, MPoC application, and COTS OS, including detection of any rollback attempts.
• The status of COTS-native interfaces that the SDK uses for account data collection.
• The status of COTS-native interfaces that can be used for account data collection, but are not implemented by the MPoC SDK.

COTS checks

The following table shows the threats we check for, with their severity per environment.
If a threat check is not enabled for a particular environment, the severity is show as -. For enabled threat checks, the severity can be:

• Normal
• Low
• Elevated
• Critical

The environment can be:

• Live environment

  The list of threat checks and severity for the live environment is currently under revision.

• Merchant development
• Adyen development

M&A configuration

Update for own solution, if needed

The M&A system is configured and operated securely, using the following parts:

• Configuration in the Adyen backoffice
• Configuration inside the SDK
• Configuration of detectors

Backoffice configuration

The Backoffice is an Adyen user interface that is accessible to Adyen operational personnel. They can use it to configure M&A for a merchant by setting the following properties:

• mobile.monitoringAttestation.enable: indicates if attestation (stopping transactions) from the SDK is enabled.
• mobile.monitoringAttestation.enableBackend: indicates if attestation (stopping transactions) from the backend is enabled. The default setting is true.
• mobile.monitoringAttestation.config: indicates the device threat policy being used. The threat policy is linked to the zDefend license key being used.

SDK configuration

During the initialization of a transaction, the SDK retrieves its M&A configuration by making a call to the /configuration/resources endpoint. Here is an example response:

{
    ...
    "monitoringAttestationEnable":true,
    "monitoringAttestationConfig":{
        "z_defend":{
        "license_key":"<zDefend_License_Key>"
        }
    }
}

The configuration resources response includes the following parameters:

• monitoringAttestationEnable: indicates if the SDK is enabled to react to threats.
• monitoringAttestationConfig: an object showing which detectors are enabled and how they are configured.

In combination, these two parameters can cause the SDK to behave in four different ways:

Detector configuration

Update text for own solution

zDefend reports threats to zConsole. Adyen monitors zConsole to trigger actions in the backend. What threats are reported by zDefend depends on the zDefend license key specified in the M&A configuration:

• Adyen development zDefend license key: for internal development. Activates a threat policy that can be changed and tested. Not for use by merchant development.

• Baseline development zDefend license key: for merchant development. Activates the threat policies for a live environment except the policies that make development impossible.

• Baseline production zDefend license key: for live environments.

Automated response to threats

Update the text for own solution and create new detection architecture diagram

If data collected by the M&A system indicates that the SDK, the application, or the COTS device is potentially compromised, the SDK automatically takes appropriate action as shown in the following table. The M&A configuration determines which action the SDK will take.

Prevention of further processing

The SDK will prevent the payment from being processed in the following situations:

• Critical/Elevated threat detected: the in-progress transaction is canceled and future transactions are blocked until the threat is resolved.
• Failed attestation threat detected: if after 60 minutes of continuous operation there is still no "passing response" from the M&A backend, transactions are blocked. A "passing response" means the M&A system has performed and validated all attestation checks.

The following diagram and steps illustrate the time line of threat detections during a transaction.

1. At startup, when the merchant initiates a transaction, ADefend runs local checks using the local configuration. For example, checks of the certificate root and the security patch. Any threats detected in the SDK are stored in ThreatDetectionEngine.

2. Then the authentication process starts, to ensure that the merchant is who they say they are. A hardware-backed certificate chain is retrieved from the Android KeyStore system. Using the generated key for the setup token, the certificate chain is verified, to attest the validity of the execution environment.

   If this step fails, the transaction process stops here.

3. If authentication passes, MonitoringManager retrieves the configurations.

4. zDefend starts and ADefend performs additional checks based on the retrieved configurations.

5. Any threats are evaluated and a threat snapshot is retrieved from ThreatDetectionEngine before the transaction starts with a /nexo call.

   The presence of critical/elevated threats in the threat snapshot will prevent the transaction from starting.

The following diagram shows the structure of the M&A component, including the elements mentioned in the threat detection time line.

Incident response procedure

As described, the SDK serves as the first layer of security protection. In addition to that, there are monitoring procedures in place: general monitoring for larger-scale incidents, and M&A alerts monitoring.

General monitoring

For Adyen-wide, 24/7 monitoring, the following scenarios automatically trigger a notification:

• Drop in authentication rates
• Drop in processing volume
• Spikes in error messaging

In these scenarios, a notification is sent automatically to the 24/7 monitoring duty team. The team reviews the notification to assess whether the issue is critical or low-impact.

• If the issue is not critical, a notification is sent to the technical support team.
• If the issue is critical, a notification is sent to the development duty team. To track the resolution of the issue, a ticket is created in our project management tool YouTrack.
• If escalation is needed for security reasons, there is a 24-hour number we can reach and a YouTrack ticket is created to help keep track of the incident. All this takes place as soon as possible, and is covered 24/7.

M&A alerts monitoring

In addition to the general monitoring procedure, we set up an IPPM M&A Alerts messaging channel which the M&A team actively tracks. For every transaction that failed for M&A reasons, a message is created with:

• The environment: test or live.
• The merchant.
• A link to logging.
• Information about why the transaction was blocked, such as threat detection details, additional details, and an indication whether it was the backend or the SDK that blocked the transaction.