Glider risk management and security overview

A best practice SaaS platform security framework.

Our company and products

Glider products are offered as Software-as-a-Service (SaaS) solutions. These solutions are available to customers through purpose-built web applications, and application programming interfaces (APIs).

Glider security and risk governance

Glider’s primary security focus is to safeguard our customers’ and users’ data. This is the reason that Glider has invested in the appropriate resources and controls to protect and service our customers.

Our Chief Technology Officer, who reports to the Chief Executive Officer, oversees the implementation of security safeguards across Glider and its products.

Our security and risk management framework

We have developed our security framework using best practices in the SaaS industry. 
Our key objectives include:

• Customer Trust and Protection – consistently deliver superior product and service to our customers while protecting the privacy and confidentiality of their information

• Availability and Continuity of Service – ensure ongoing availability of the service and data to all authorised individuals and proactively minimise the security risks threatening service continuity

• Information and Service Integrity – ensure that customer information is never corrupted or altered inappropriately

• Compliance with Standards – implement process and controls to align with current international regulatory and industry best practice guidance. We have designed our security program around best-of-breed guidelines for cloud security

Glider security controls

To ensure we protect the data entrusted to us, we have an array of security controls which are designed to allow for a high level of employee efficiency without artificial roadblocks, while minimising risk. The following sections describe a subset of controls.

PRODUCT INFRASTRUCTURE

DATA CENTRE SECURITY

Glider outsources hosting of its product infrastructure to the leading cloud infrastructure provider, Amazon Web Services (AWS). Principally, the Glider product leverages AWS for infrastructure hosting. These solutions provide high levels of physical and network security. At present, Glider’s AWS cloud server instances reside in Australian locations. AWS maintains an audited security program, including SOC 2 and ISO 27001 compliance. Glider does not host any product systems within its corporate offices.

This world-class infrastructure provider leverages the most advanced facility infrastructure such as power, networking, and security. Facility uptime is guaranteed between 99.95% and 100%, and the facility ensures a minimum of N+1 redundancy to all power, network, and HVAC services. Access to AWS sites is highly restricted to both physical access as well as electronic access through public (internet) and private (intranet) networks in order to eliminate any unwanted interruptions in our service to our customers.

The physical, environmental, and infrastructure security protections, including continuity and recovery plans, have been independently validated as part of their SOC 2 Type II and ISO 27001 certifications. Certificates are available at the AWS compliance site.

DATA CENTRE SECURITY

The Glider product infrastructure is built with internet-scale security protections in mind. In particular, network security protections are designed to prevent unauthorised network access to and within the internal product infrastructure. These security controls include enterprise-grade routing and network access control lists (fire-walling).

Network-level access control lists are implemented in AWS Virtual Private Cloud (VPC) security groups and address-level protections to each of the server instances in the infrastructure. These fire-walling technologies deny unintended traffic by default, and all network traffic is logged and used to inform our monitoring systems. These network access rules allow for finely grained control of network traffic from a public network as well as between server instances on the interior of the infrastructure. Within the infrastructure, internal network restrictions allow a many-tiered approach to ensuring only the appropriate types of devices can communicate.

Changes in the network security model are actively monitored and controlled by standard change control processes. All existing rules and changes are evaluated for security risk and captured appropriately.

CONFIGURATION MANAGEMENT

Automation drives Glider’s ability to scale with our customers’ needs. The product infrastructure is a highly automated environment that flexibly expands capacity and capability as needed. Server level configuration management is handled using images and configuration scripts when the server is built. Changes to the configuration and standard images are managed through a controlled change management process. Each instance type includes its own hardened configuration, depending on the deployment of the instance.
Patch management and configuration control is typically handled by removing server instances that are no longer compliant with the expected baseline and provisioning a replacement instance in its place.
 
Rigorous and automated configuration management is baked into our day-to-day infrastructure processing.

ALERTING & MONITORING

Not only does Glider fully automate its build procedures, we invest heavily in automated monitoring, alerting and response technologies to continually address potential issues. The Glider product infrastructure is instrumented to alert engineers and administrators when anomalies occur. In particular, error rates, abuse scenarios, application attacks, and other anomalies trigger automatic responses and alerts to the appropriate team members for response, investigation, and correction. As unexpected or malicious activities occur, our systems ensure that the issue is rapidly addressed.

Many automated triggers are also designed into the system to immediately respond to foreseen situations. Traffic blocking, quarantine, process termination, and similar functions kick in at predefined thresholds to ensure that the Glider platform can protect itself against a wide variety of undesirable situations. 

The power behind Glider’s ability to detect and respond to anomalies is our 24x7x365 monitoring program and extensive logging. Our systems capture and store logs that include all the technologies that comprise our products. At the application layer, all logins, page views, modifications, and other access to Glider portals are also logged. In the infrastructure back-end, we log authentication attempts, horizontal and vertical permission changes, infrastructure health, and requests performed among many other commands and transactions. Logs and events are monitored in real time and events are escalated immediately at any hour of the day to developers, security professionals, and engineers to take appropriate action.

INFRASTRUCTURE ACCESS

Entire categories of potential security events are prevented with a stringent, consistent, and well designed access control model. Along those lines, access to Glider’s systems is strictly controlled. Glider employees are granted access to product infrastructure based on their jobs, using a role-based access control model.

APPLICATION PROTECTION

WEB APPLICATION DEFENSES

As part of its commitment to protecting customer data and websites, Glider implemented an industry recognised Web Application Firewall (WAF). The WAF automatically identifies and protects against attacks aimed at the Glider products or customer sites hosted on the platform. Glider’s WAF protects Glider platform access. Additionally, all customer content hosted on the platform is also automatically protected. Protections from Distributed Denial of Service (DDoS) attacks are also incorporated, helping to ensure that customers’ sites and other parts of the Glider products are available continuously.
 
The WAF is configured with a combination of industry standard and custom rules that are capable of automatically enabling and disabling appropriate controls to best protect our customers. These tools actively monitor real-time traffic at the application layer with ability to alert or deny malicious behaviour based on behaviour type and rate.

DEVELOPMENT & RELEASE MANAGEMENT

One of Glider’s greatest advantages is a rapidly-advancing feature set, and we provide constantly improving products through a modern continuous delivery approach to software development. New code is proposed, approved, merged on a regular basis. Code reviews and quality assurance are performed by specialised teams of engineers with intimate knowledge of the Glider platform as it is developed.

Approval is controlled by designated repository owners. Once approved, code is automatically submitted to Glider’s continuous integration environment where compilation, packaging and unit testing occur. If all tests pass, the new code is deployed automatically across the application tier.

All code deployments create archives of existing production-grade code in case failures are detected by post-deploy hooks. The deploying team manages notifications regarding the health of their applications. If a failure occurs, roll-back is immediately engaged. 

As part of the continuous deployment model, we use extensive software gating and traffic management to control features based on customer preferences (private staging, public UAT, full launch). Major feature changes are communicated through in-app messages and/or product release notes.

Newly developed, built code is first deployed to the dedicated and separate Glider QA environment for the last stage of testing before being promoted to production. Network-level segmentation prevents unauthorised and undesirable access between QA and production environments. Customer data is never used by Glider in the QA environment, nor does any other testing use customer data.

VULNERABILITY SCANNING & PENETRATION TESTING

The Glider Engineering team manages a multi-layered approach to vulnerability scanning, using a variety of industry recognised tools to ensure comprehensive coverage of our technology stack. We perform multiple vulnerability scanning and penetration testing activities against ourselves on a regular basis.

CUSTOMER DATA PROTECTION

CONFIDENTIAL INFORMATION IN THE GLIDER PRODUCTS

The Glider products are an integrated payments management experience. The information collected in our products is data gathered through the request and collection of receivables due. The Glider products are not used to collect or capture sensitive data such as credit or debit card numbers, personal financial account information, Tax related or Social Security numbers, passport numbers, driver’s license numbers or similar identifiers, or employment, financial or health information.

CREDIT CARD INFORMATION PROTECTION

Glider does not store, process or collect credit card information submitted to us by customers. We leverage trusted and PCI-compliant payment gateways to ensure that customers’ credit card information is processed securely and according to appropriate regulation and industry standards.

ENCRYPTION IN-TRANSIT

The Glider products allow users to login to their Glider accounts using built-in Glider login or Single Sign On. Customers who use a Single Sign On (SSO) provider can set up SSO-based login for their users. Instructions for setting up SSO are available on the Glider API documentation, or by request from your Account Manager. Single Sign On users can configure a password policy in their SSO provider.

USER LOGIN PROTECTIONS

Customers can assign finely grained permissions for their accounts and limit access to their data features. Application programming interface (API) access is enabled through either API key or Oauth (version 2) authorisation. Customers have the ability to generate API keys for their portals. The keys are intended to be used to rapidly prototype custom integrations. Glider’s Oauth implementation is a stronger approach to authenticating and authorising API requests. Additionally, Oauth is required of all featured integrations. Authorisation for Oauth-enabled requests is established through defined scopes.
 
For more information about API use, please see the Developers portal at https://docs.gliderpay.com/

GLIDER EMPLOYEE ACCESS

Glider controls individual access to data within its production environment. A subset of Glider’s employees are granted access to production data based on their role in the company through role based access controls or on an as-needed basis.

Engineers and members of Operations may be granted access to various production systems, as a function of their role. Common access needs include alert responses and troubleshooting. Access to the product infrastructure is limited by network access and user authentication and authorisation controls. Access to networking functions is strictly limited to individuals whose jobs require that access, and access is reviewed on a continual basis.

PRIVACY

The privacy of our customers’ data is one of Glider’s primary considerations. We never sell your Personal data to any third parties. The protections described in this document and other protections that we have implemented are designed to ensure that your data stays private and unaltered. The Glider products are designed and built with customer needs and privacy considerations in the forefront. Our approach incorporates best practices, customers’ and their contacts’ needs, as well as regulatory requirements.

DATA RETENTION POLICY

Customer data is retained for as long as you remain an active customer. Former customers’ data is removed from live databases upon a customer’s written request or after an established period following the termination of all customer agreements. Information stored in replicas, snapshots, and backups is not actively purged but instead naturally ages itself from the repositories as the data lifecycle occurs. Glider retains certain data like logs and related metadata in order to address security, compliance, or regulatory needs.

BUSINESS CONTINUITY & DISASTER RECOVERY

Glider maintains business continuity and disaster recovery plans focusing both on preventing outage through redundancy of telecommunications, systems and business operations, and on rapid recovery strategies in the event of an availability or performance issue. Whenever customer-impacting situations occur, Glider’s goal is to quickly and transparently isolate and address the issue.

SYSTEM RELIABILITY & RECOVERY

Business continuity testing is part of Glider normal processing. Glider recovery processes are validated continuously through normal maintenance and support processes. We follow continuous deployment principles, and create or destroy many server instances daily as part of our regular maintenance and growth. We also use those procedures to recover from impaired instances and other failures, allowing us to practise our recovery process every day.

Glider primarily relies on infrastructure redundancy, real-time replication and backups. All Glider product services are built with full redundancy, server infrastructure is strategically distributed across multiple distinct availability zones and virtual private cloud networks within our infrastructure providers, and all web, application and database components are deployed with a minimum of N+1 supporting server instances or containers.

BACKUP STRATEGY

Glider ensures data is replicated and backed up in multiple durable data-stores. The retention period of backups depends on the nature of the data. Data is also replicated across availability zones and infrastructure locations in order to provide fault-tolerance as well as scalability and responsive recovery, when necessary.
 
Customer (production) data is backed up leveraging multiple online replicas of data for immediate data protection. All production databases have no less than 1 primary (master) and 1 replica (slave) copy of the data live at any given point in time. Seven days worth of backups are kept for any database in a way that ensures restoration can occur easily. Snapshots are taken and stored to a secondary service no less often than daily and where practicable, real time replication is used. All production data sets are stored on a distributed file storage facility like Amazon’s S3.
 
Because we leverage private cloud services for hosting, backup and recovery, Glider does not implement physical infrastructure or physical storage media within its products. Glider does also not generally produce or use other kinds of hard copy media (e.g. paper, tape, etc.) as part of making our products available to our customers.
 
By default, all backups are protected through access control restrictions on Glider product infrastructure networks, access control lists on the file systems storing the backup files and/or through database security protections.

ORGANISATIONAL SECURITY

EMPLOYEE AUTHENTICATION & AUTHORISATION

Glider enforces an industry-standard corporate password policy. That policy requires changing passwords at least every 90 days. It also requires a minimum password length of 8 characters and complexity requirements including special characters, upper and lower case characters, and numbers. Glider prohibits account and password sharing by multiple employees.

Employees generally authenticate to Glider product infrastructure using SSH keys. Where passwords are allowed, the password policy requires 12 character passwords. Additionally, all of the tools we use to build the Glider products leverage multi-factor authentication or are protected by single-sign on solutions that enforce multi-factor authentication.

EMPLOYEE AUTHENTICATION & AUTHORISATION

Glider provides 24x7x365 coverage to respond quickly to all security and privacy events. Glider’s rapid incident response program is responsive and repeatable. Pre-defined incident types, based on historical trending, are created in order to facilitate timely incident tracking, consistent task assignment, escalation, and communication. Many automated processes feed into the incident response process, including malicious activity or anomaly alerts, vendor alerts, customer requests, privacy events, and others.
 
In responding to any incident, we first determine the exposure of the information and determine the source of the security problem, if possible. We communicate back to the customer (and any other affected customers) via email or phone (if email is not sufficient). We provide periodic updates as needed to ensure appropriate resolution of the incident. Our CTO reviews all security-related incidents, either suspected or proven, and we coordinate with affected customers using the most appropriate means, depending on the nature of the incident.