Security

Overview of approach

Our approach to data security is driven by our ongoing ISO27001:2013 and ISAE 3402 accreditations, we have a multi-layered approach to security across physical, application and network, and where we leverage the inherent security features of Google Cloud Platform. Our platform is hosted in Google Cloud, and with that comes data encryption in transit over the Google network. Traffic is handled over SSL to our load balancers. Once the SSL is decrypted, the communication to the server is encrypted. At rest, data is encrypted on disk using Google managed keys. All access to data downloads via API services is controlled and authenticated through API credentials (client IDs and associated secrets) and IP whitelisting. Access to data by end users is controlled through role-based permissions and the user's position in the client organisation hierarchy and access by Eagle Eye personnel is strictly controlled on the basis of least privilege. Cross site scripting and SQL injection are prevented by escaping all user inputs and validating that those inputs match the expected data. We also deploy web application firewalls through Google Cloud Armour web-application-firewall (WAF) that monitors and prevents attacks from the OWASP Top-10, and known attack signatures, with additional web protections using CloudFlare. Google Cloud Armour also provides in-built IDS and DDoS protection to further protect our applications. Anti-virus and malware checks are automatically applied across all environments with tools built-in to Google VM images, with agent-less scanning taking place hourly to detect any unwanted or dangerous processes on disk, and in memory. Monitoring of our environments security is handled 24/7/365 by Sep2, a Google Cloud security partner. Using Native Google tooling, Sep2 are able to get a real-time view of our security posture, with the ability to react and remediate any threats that may occur. We also engage cyber-security specialist, JumpSec who sit outside our networks, to monitor the wider threat landscape, and provide us continual attack-surface monitoring of all our web-assets.

Data security

Encryption (in-transit / at rest)

Our platform is hosted in Google Cloud, and with that comes data encryption in transit over the Google network. Traffic is handled over SSL to our load balancers. Once the SSL is decrypted, the communication to the server is encrypted. At rest, data is encrypted on disk using Google managed keys. We support a range of protocols and encryption standards including SSL, SFTP, PGP, HMAC, RSA, 3DES, SHA256 and AES and these are described in the separate Encryption Policy document.

Where data is being transferred between systems, we use a Managed File Transfer system, which requires individual accounts for each customer, and access using public/private SSH key pairs. Where possible access is also whitelisted to known IP addresses for our customers.

Data Access and Control

Within the Eagle Eye platforms, a number of different database technologies are deployed to provide our functionality.

Self Hosted MySQL

For our core transaction engine, which requires extremeley high levels of I/O, we build and maintain our own MySQL clusters that consist of MySQL nodes (primary and secondary), ProxySQL servers that act as a caching and routing layer, and MySQL orchestrator for managing the cluster. These are all run on Compute Engine VMs, built and managed with Chef. We have a 24/7/365 support contract with Percona, who monitor all our clusters globally, and can remediate and fix any issues that arise.

Applications that write to this cluster each have their own set of users and permissions with the right level of permissions. Engineers that require access to the cluster each have their own accounts for access, with a very restricted number of users who have admin privileges on these clusters. Internal access to the cluster is controlled by firewall access, and only services and VMs that require access to the cluster have access.

CloudSQL

For micro-services that don't require such as high level of performance and throughput, we use Google’s CloudSQL product. This is entirely managed by Google, where they manage the security, backup and maintenance of these databases. Using Private Service Access, these databases are only available within pre-defined subnets, and firewall access controls which services and VMs can access these databases. Management access is controlled through Cloud SQL Auth Proxy, which requires a user to be authenticated to their Google account, and on our VPN.

Aiven Kafka

For some of our Data processing functions, we use a hosted version of Kafka, managed by Aiven. Employee access to Aiven is controlled by SSO and multi-factor authentication. Access to Kafka clusters for servers is done through a peered VPC connection which is controlled using firewall rules to restrict access to only servers that require read/write access to the clusters. Typically this is done through our Dataproc clusters, and access to individual topics through notebooks.

Access to the clusters is done over TLS, and data is encrypted at rest within the Kafka infrastructure.

Big Query

For our transactional data-warehouse, we use Google’s Big Query product to store data for reporting, analytics, and if subscribed EagleAI functionality. As with all Google products, data is encrypted at rest, and access is controlled through fine-grained IAM permissions, for both employees and service accounts.

Big Query data is either used within the platform internally, or exposed in reports through our front-end applications, which is controlled by SSO and multi-factor authentication.

AI/ML Data Access

For customers who have subscribed to EagleAI functionality, data is processed internally within the network using Dataproc, Airflow and Vertex AI. All these systems are secured using Google IAM, Identity Aware proxies, firewall rules and require users to be on our VPN for access through front-ends.

Cloud Storage

For the storage of data objects outside of the database, we use Google Cloud Storage. As with all Google’s data products, the data is encrypted before storage. Uniform bucket-level access is enabled on all buckets, meaning ACLs are disabled and rights are only managed through IAM. Public access prevention is enforced, and access to buckets is managed bucket-by-bucket, only allowing users if they have the right IAM roles.

Network security

We utilise the built in security functionality of Google Cloud’s Security Command Centre Premium, along with the support from Sep2 to ensure our networks are secure 24/7/365. All our environments are connected to Sep2’s Security Operations Centre (SOC) where our networks are continuously monitored for suspicious activity.

Sep2 carries out weekly and monthly “hunts” on our network, looking for any weaknesses, or exploitations of known security issues.

Our Cloud Firewalls are configured to only allow external traffic on configured ports, and from whitelisted countries. Internal administration access is provided by Google Identity Aware Proxies. Communication within our networks is tightly controlled with firewalls, to ensure correct traffic flows are adhered to. Access to infrastructure such as Virtual Machines and Google managed services are restricted using the built-in controls Google provide such as Identity Aware proxy (IAP) and restricting access to sensitive ports (such as port 22 for SSH) from traffic that has not originated from our VPN or internal to the cloud networks.

Application security

Eagle Eye AIR manages access to functions and data for named users based on the underlying organisation hierarchy, the users assigned position within that hierarchy and the configurable role based permissions that the user is assigned. Such roles are configurable for each AIR client and define the AIR Dashboard functionality access permissions for users allocated to each role.

Remote access by Eagle Eye systems engineers is restricted on a least privileges basis and secured using multi-factor authentication.

Physical security

As our platform is fully hosted within Google Cloud, they are responsible for physical security, which is detailed on their website

Penetration and vulnerability testing

As part of our commitment to run a secure and reliable platform, we conduct nightly vulnerability tests and quarterly penetration tests. On top of this, our codebase is continually scanned for known vulnerabilities. We utilise the services of a cyber security company Jumpsec who conducts our penetration tests, and provide continual assurance of our security posture.

Identity & Access Management (IAM)

Employee access to our Google Cloud environments is controlled using IAM, using custom roles for each type of user, and is based on the principle of least privilege. IAM permissions are controlled by Terraform, and the roles are assigned directly to their Google account as part of the onboarding process.

Auditing

All events and transactions, both system generated and those performed by Dashboard application users and support users, are logged and audited in various ways as part of the ongoing AIR service provision, and to support our Tech Services team in the resolution of incidents and raised issues. Application audit reports are also available within the Dashboard for clients to see change history and approval workflow decisions associated with promotional campaigns and transactions undertaken by contact centre support through Dashboard e.g. goodwill points awarded or discounts issued.

Anti-fraud checks

Eagle Eye AIR is a real-time, omni-channel platform able to prevent most fraud instances by applying the usage rules defined for offers and rewards in real-time across all redemption channels and associated API calls. Fraud prevention measures include unique codes to prevent re-use of offers, locked accounts on validation to prevent double redemption, manual adjustment agent restrictions and reporting, outlet reporting by campaign (offer) to see unusual levels of usage/redemption, audit reports available within the AIR Dashboard and event feeds to third party data analytics applications for modelling suspicious usage patterns. Every program is different in terms of purchase frequency/value, and we work with clients to agree events notifications of interest and/or custom reports to monitor program usage within tolerances. All of the above approaches are valid and can be applied to specific client instances due to the multi-tenanted nature of the AIR platform.

Corporate Security

To maintain our security posture, we have a number of policies and controls in place to manage access to systems and services used by our Employees.

Google SSO & Multi-factor Authentication

We use the single sign-on capability from Google to access corporate accounts. Where SSO is not possible, multi-factor authentication is enforced to protect accounts. As an extra layer of protection for employees Google accounts, we require a hardware key to be present when attempting to login to the account. This offers an additional layer of protection above standard multi-factor authentication, requiring a physical piece of hardware to be present in the users device to gain access.

VPN Access

For all our internal applications and infrastructure tools, we require users to be logged into our VPN, which provides a secure transport layer for data, and allows us to whitelist known IP addresses for access. Access to the Google Cloud console, and command-line tools is also restricted to VPN access only. Along with the multi-factor authentication described above, this provides a number of layers of protection for the critical parts of our business and platform.