A security framework developed using best practices in the SaaS industry.
Glider risk management
& security overview
- Our company and products
- Glider security and risk governance
- Our security and risk management objectives
- Glider security controls
- Document scope and its use
Our company and products
Glider’s technologies and processes have been developed, refined and tested over 12 years.
While Glider as a brand is relatively new, since the company’s incorporation in 2008, the technology and practices underpinning the payments communication platform has been proven through many deployments for leading enterprises, across the Finance, Government, Health, Utility, Insurance, Media and Entertainment sectors.
We are committed to delivering excellence in every aspect of our business and take the security of our products and platform seriously.
We will continue to evolve and look for improvements wherever possible through the ongoing training of our people and investment in our security practices.
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.
We are focused on defining new and refining existing controls, implementing and managing the Glider security framework as well as providing a support structure to facilitate effective risk management.
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
In order to ensure we protect data entrusted to us, we implemented an array of security controls.
Glider’s security controls 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.
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.
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.
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.
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.
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.
All sensitive interactions with the Glider products (e.g., API calls, login, authenticated sessions to the customer’s portal, etc.) are encrypted in-transit with TLS 1.0, 1.1, 1.2, or 1.3 and 2,048 bit keys or better.
USER LOGIN PROTECTIONS
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 AND API AUTHORIsATION
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 www.gliderpay.docs.apiary.io
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.
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 been 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 practice 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.
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.
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.
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.
Document scope and its use
Glider values transparency in the ways we provide solutions to our customers. This document is designed with that transparency in mind. We are continuously improving the protections that have been implemented and, along those lines, the information and data in this document (including any related communications) are not intended to create a binding or contractual obligation between Glider and any parties, or to amend or alter any existing agreements between the parties.
Document last updated September 2020.