GLU Security

GLU follows Security by Design based Architecture with focus on security from 2 view points …

  1. Ensure GLU.Ware software (GLU.Console and GLU.Engines) adhere to highest standards (such as SAMM).
  2. Ensure the GLU.Ware (GLU.Console and GLU.Engines) provide the features needed for our clients to adhere to the highest security standards based on deep experience of secure integrations and standards set out by OWASP.

Security Architecture

GLU.Ware’s ‘top level’ architecture has been specifically designed with Client Security in mind. It comprises two constructs.

  1. The GLU.Console which is essentially a GUI based configuration console that GLU or Client Analysts use to design / configure the middleware. In the GLU.Console it has a Build Manager tool that is used to compile the actual middleware component which generates the 2nd component.
  2. The GLU.Engine is the component that actually handles the processing of transactions and data. GLU.Engines are deployed within the Customers security domain and within the Customers security controls, protocols and standards.

The GLU.Console has no visibility of Customer production transactional data; no transactional data handled by GLU.Engines is stored by GLU.

Security Principles

GLU.Ware has not been ISO27001 or SOC2 certified however GLU does subscribe to these standards seeking to align all aspects of our operations and software accordingly. A Customer’s use of GLU.Ware should not affect their implementation of security controls towards conforming to or implementing these standards. GLU follows the Trust Service Principles that underpin the Service Organisation Control SOC2 Report standard. A SOC2 report focuses on a business’s non-financial reporting controls as they relate to security, availability, processing integrity, confidentiality, and privacy of a system.

Although GLU is not SOC2 audited (as yet), GLU is working towards the Trust Service Principles which SOC2 is based upon and which are modelled around four broad areas: Policies, Communications, Procedures, and Monitoring. Each of the principles have defined criteria (controls) which must be met to demonstrate adherence to the principles and produce an unqualified opinion (no significant exceptions found during your audit). The great thing about the trust principles is that the criteria businesses must meet are predefined, making it easier for business owners to know what compliance needs are required and for users of the report to read and assess the adequacy.

GLU.Ware Secure SDLC

GLU’s SDLC is based on the OWASP SAMM Project guidelines. It covers the security areas of Governance, Construction, Verification and Operations. Work is currently underway to formalise GLUs detailed SSDLC Process and as part of GLUs Continuous Delivery practice security auto-scanning tools will be utilised where possible.

Security Compliance and Standards

GLU recommends that customers implement ISO17799 / BS7799 security standards. A Customers use of GLU.Ware should not affect their implementation of security controls towards conforming to or implementing ISO17799 / BS7799 standards. GLU.Ware has not been PCI-DSS or PA-DSS certified however use of GLU.Engines within the Customers domain should not affect Customers with requirements related to Payment Card Industry – Data Security Standard (PCI-DSS), or Payment Application – Data Security Standard (PA-DSS).

GLU.Ware’s ‘top level’ architecture has been specifically designed with Client Security in mind. It comprises two constructs: the GLU.Console is used to design and configure the middleware component (called the GLU.Engine) which is the second construct. The GLU.Engine is the component that actually handles the processing of transactions and data. GLU.Engines are deployed within the Customers security domain and within the Customers security controls, protocols and standards. The GLU.Console has no visibility of Customer production transactional data; no transactional data handled by GLU.Engines is stored or made visible to GLU. A Client PCI-DSS status is thus not affected by GLU.Ware, providing that the Client deploys and manages their GLU.Engines, with the same security standards as they do the rest of their PCI-DSS certified domain.

Confidentiality

All Customer interactions with the GLU.Console and all data handled by the GLU.Engine is treated as Confidential as detailed in the Terms of the SaaS agreement. Confidentiality applies equally to all log files and backup records taken by GLU.

Secure Communication

All connections initiated by GLU.Engines built with the Integration builder will utilise the Java Secure Socket Extension (JSSE). Please refer to https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-93DEEE16-0B70-40E5-BBE7-55C3FD432345 for details. This implicitly includes SSLv3 and TLSv1.2 .

GLU.Console – Deployment security

The GLU.Console benefits from the native security features of the AWS Cloud encompassing an end-to-end approach to providing secure, hardened infrastructure, including physical, operational, and software. AWS provides quick configuration of VPN integration into a new client’s network to ensure heartbeat and metrics can be received in GLU.Ware. The AWS infrastructure puts strong safeguards in place to help protect customer privacy. All data is stored in highly secure AWS data centres. AWS meets the Compliance Requirements of ISO 27001. This is a security management standard that specifies security management best practices and comprehensive security controls following the ISO 27002 best practice guidance. All access to GLU’s infrastructure in AWS is through AWS security protocols and Key Management Service.

The GLU.Console is installed on a hardened operating system within GLU’s secure AWS environment. The GLU.Console application architecture spans 2 physical tiers. In the Perimeter zone, behind our perimeter Firewall resides the GLU Reverse Proxy. This provides a number of benefits including the ability to load balance the GLU.Console; hiding the topology and characteristics of the GLU back-end servers by removing the need for direct internet access to them; handling of incoming HTTPS connections, decrypting the requests and passing unencrypted requests on to the GLU.Console server and providing for centralised logging of HTTP traffic. The Business zone hosts the core of the GLU.Console – handling all User Management and associated configuration Business activity.

GLU has been certified as AWS Well Architected – see the Case Study.

GLU.Ware – Transport security

SSL is used to access the GLU.Console. Transport security responsibility for the GLU.Engine resides with the Customer. GLU recommends to SSL encrypt or VPN tunnel all communications between 3rdParty Systems and the GLU.Engine. In the consumer channel context, some channels in particular USSD however do not support encryption. GLU recommends to Customers to apply transport layer security to such data communications at the earliest opportunity upstream of the GLU.Engine.

GLU.Ware – Secure Hash Algorithms

GLU uses a SHA when encrypting passwords, so the server only needs to keep the specific user’s hash value, not the actual password. Any breach of the database will find only the hashed values and not the actual passwords. SHAs can also be used to detect the tampering of data by attackers, preventing “Man in the Middle” attacks. GLU.Ware supports SHA-256, SHA-384 and SHA-512. GLU recommends clients avoid / do not use SHA-1 and MD5 as these have been compromised however GLU.Ware is able to support these in exceptional circumstances. This can be configured with select or all parameters in a request or a response to ensure its authenticity. The SHA mechanism uses data from the message, which it validates as input to the Hash Algorithm. For example, a request with parameters “accountID”, “amount”and “reference” can be configured to use a single parameter or all parameters as input to the Hash Algorithm. The input parameters are specified in the Hash Expression. To use “accountID” and”amount” from the example above, the expression should be set to: ${accountID}+${amount}. A Salt Key can also be inserted for additional safeguarding. The salt value provides an external input to the Hash that isn’t present in the message being validated.

GLU.Console – Authentication & Authorisation

GLU uses Spring Security to provide a flexible framework for authentication and authorisation requirements. Users of the GLU.Console are authenticated against an LDAP server hosted within the GLU.Console using a Unique Username and Password. Users are assigned permissions and are associated with roles. These permissions are configurable to enable alignment of functional roles to the Customers role / resource context. Password Security complexity rules as well as password reuse limits are enforced.

GLU.Console – Spam and Abuse Protection

The GLU.Console access is further controlled via reCAPTCHA ‘I am Human’ validation – a free service from Google that helps protect websites from spam and abuse. It uses advanced risk analysis techniques to tell humans and bots apart. As a GLU Admin on the GLU.Console, a Variables option enables this feature to be activated or deactivated. It also enables the reCAPTCHA Key to be updated when needed. The site key is stored in the Variables table in the GLU.Console Database. When GLU generates the Login page we retrieve the value and pass it to the HTML Login page, reCAPTCHA V2 is being used. For further details see: https://developers.google.com/recaptcha/intro

GLU.Console – Data at rest encryption

All configuration and Customer specific data that is stored in the GLU.Console database is being encrypted using native database encryption. There is no data at rest within the GLU.Engine. Transaction data from API Requests and Responses passes through the GLU.Engine to Connectors and is not stored in any database. GLU.Engine – Network security: The GLU.Engine components are deployed by the Customer into their own network. These components can be deployed into any security zone providing all applicable routing and firewall rules (sources, destinations, ports etc.) are correctly configured by the Customers’ DevOps engineers. GLU recommends the use on the front-end of a reverse proxy, to act as an intermediary for all incoming connections.

GLU.Ware – Code security

GLU follows a secure coding discipline. Periodic static and dynamic code reviews are performed against a Test GLU.Engine. The test GLU.Engines are also periodically subjected to independent Penetration Tests. Some vulnerable components (e.g. framework libraries) can be identified and exploited with automated tools. These types of issues are not always easy to exploit; however, some sites publish plugins and scripts to automate attacks of this kind. GLU pro-actively scans for such exploits using the “Using Components with Known Vulnerabilities” category of OWASP Top 10 of 2013 as well as reviewing the types of licenses used in all the libraries within the GLU.Engine. The GLU.Engine only makes use of libraries that are licensed with Open Source licenses which only requires the Copyright and License be placed in the binary distribution. Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocols or accessing and maintaining distributed directory information services over an IP network

GLU.Console Session Timeouts

One of the most authoritative web application security standards organisations is OWASP (Open Web Application Security Project). Here’s what OWASP says about session timeouts: “Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active. The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring…Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.”

For this reason any pages that handle potentially sensitive information have a Timeout setting of 2 minutes, whereas other pages have a timeout setting of 30 mins. 30 Seconds before your session times out you’ll be presented with a ‘pop-up’ dialogue box saying ‘Your session is about to expire. Do you want to stay connected and extend your session?’ and you’ll be given the opportunity to retain your session. If you don’t your session will expire and you’ll be logged out of the GLU.Console.

GLU.Ware Security product features

The GLU.Ware product provides many mechanisms to secure all transactions and associated Customer Data which flows through GLU’s Engines. The mechanisms and features within the product are described below.

CORS Configuration

Support for Cross-Orgin Resource Sharing Header options.

API access controls

Access control is enforced in trusted server-side code (GLU.Engine), where it is not possible to modify the access control check or metadata. Deny access is basic premise for GLU Engines.

We implement access control mechanisms once and re-use them throughout the application.

Rate limit API and controller access is available through throttle type 1 & 2 controls to minimise the harm from automated attack tooling.

[Throttle Type 1]

[Throttle Type 2]

WCF Security

GLU provides support for Windows Communication Foundation – WCF Security. Windows Communication Foundation (WCF) has two major modes for providing security (Transport and Message) and a third mode (TransportWithMessageCredential) that combines the two.

GLU.Ware currently offers Message level Security only. Should Client require either of the other two modes, please raise a Support Desk Ticket. Message security uses the WS-Security specification to secure messages. The WS-Security specification describes enhancements to SOAP messaging to ensure confidentiality, integrity, and authentication at the SOAP message level (instead of the transport level).

In brief, message security differs from transport security by encapsulating the security credentials and claims with every message along with any message protection (signing or encryption). Applying the security directly to the message by modifying its content allows the secured message to be self-containing with respect to the security aspects. This enables some scenarios that are not possible when transport security is used.

Detailed Logging & Monitoring

GLU.Engines provide for rich set of logging and monitoring functionality.

[Logging Features]

[Logging Levels]

[Monitoring APIs]

[Monitoring Dashboard]

Masking Sensitive Data & Parameters in the Logs

It is possible to set up masks for all data and parameters in the logs.

[Masking log data]

Secure Hash Algorithms

GLU uses a SHA when encrypting passwords, so the server only needs to keep the specific user’s hash value, not the actual password. Any breach of the database will find only the hashed values and not the actual passwords. SHAs can also be used to detect the tampering of data by attackers, preventing “Man in the Middle” attacks.

GLU.Ware supports SHA-256, SHA-384 and SHA-512. GLU recommends clients avoid / do not use SHA-1 and MD5 as these have been compromised however GLU.Ware is able to support these in exceptional circumstances. This can be configured with select or all parameters in a request or a response to ensure its authenticity. The SHA mechanism uses data from the message, which it validates as input to the Hash Algorithm. For example, a request with parameters “accountID”, “amount”and “reference” can be configured to use a single parameter or all parameters as input to the Hash Algorithm. The input parameters are specified in the Hash Expression. To use “accountID” and”amount” from the example above, the expression should be set to: ${accountID}+${amount}. A Salt Key can also be inserted for additional safeguarding. The salt value provides an external input to the Hash that isn’t present in the message being validated. hash

Hash Paramter configuration

ENCODINGSTRING Function

There is a FUNCTION that can be used to encode a string to either Base32 or Base64.

[ENCODESTRING]

SSL Security

GLU.Ware supports SSL encryption – see SSL Functionality

Was this article helpful?

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill the form and we’ll contact you shortly

    I agree with

    cookies
    We uses cookies to make your experience on this website better. Learn more
    Accept cookies