Our Security Principles
Foundational Security Design
The Omneo solution and system has been designed with Security as a primary and critical concern since the outset. Security continues to be a core part of both our development process and operations.
With multiple integrations with various critical systems in your software stack, in order to reduce error and security vulnerabilities automation is critical.
Where possible, Omneo completely automates all systems and integrations, from infrastructure provisioning through to code deployment.
Our eyes and attention can’t be everywhere at once, so we employ various tools and alarms to monitor activity on our systems, services and resources. This allows us to be alerted and respond to issues as they arise.
People and Process
A system is only as strong as its weakest link, at Omneo we recognise that the security of a system can be undone if it is not supported by well-designed process and mindful operation by validated, trained users and expert developers.
The Omneo CX platform is built in the Laravel PHP framework with a JSON REST API for various integrations and reporting purposes. Scalable Infrastructure is provided as a service by either Amazon Web Services (AWS) or Google Cloud Services (GCS) depending on client choice at implementation.
The Omneo System has been designed from the ground up with security, stability and reliability in mind. From a technology perspective, much of our security rests on proven robust protocols and best practice such as HTTPS, OAuth2, and Transport Layer Security v1.2 (TLS) Encryption.
The implementation of the platform is customised to your brand’s business requirements; however it is in your brand’s best interests to invest time into considering the security of the platform and its interfaces.
This document discusses the key areas which should be considered through planning and development with guidance on the risks and potential impact. It is the responsibility of the implementation partner to judge the level of risk that is acceptable for your brand as all organisations have different requirements.
There are essentially three component types to the Omneo CX platform each with differing security technologies and process. These are:
- Infrastructure and hosting.
- Omneo controlled Web interfaces,
- APIs and App integrations.
Omneo-Controlled web apps.
Omneo has two types of web access points:
- Omneo CX Manager, and Clienteling - Business facing
- Action Portal - Consumer facing
All web apps are protected by:
- HTTPS: Hyper-Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted.
In the case of business-facing (CX Manager and clienteling). Access is controlled by user accounts and permissions. Whereas with Action portal users typically access their preferences or any personally identifiable information via a Magic Link (Temporary secure authentication token)
Omneo provides two hosting options: Google Cloud Service (GCS) and Amazon Web Services (AWS). In both cases, we employ Infrastructure best practices to ensure security, scalability and reliability.
Least Privilege Access & Accountability
Users are granted the minimum privilege to complete the task at hand in the infrastructure management consoles and instances, with regular review of access levels and privileges.
We ensure accountability by strictly enforcing individual user login when accessing infrastructure environments. User privileges are managed centrally from Active Directory, mapping roles, and groups.
Omneo uses monitoring software such as Amazon Cloudwatch monitor all API Activity across AWS instances and accounts. This way our core support and development teams can be alerted to abnormalities in real-time.
Omneo and Its implementation partners enforce strict two-factor authentication for production infrastructure access.
Consistently implement multi-factor authentication (MFA) for AWS service management, on login and privilege elevation for AWS instances, or when checking out vaulted passwords.
Infrastructure Protocols and Certifications
Google Cloud Services Security Guide
The Omneo Platform is designed to support integration with a wide variety of other applications by providing a modern and widely compatible private API which other systems (authenticated clients or ‘Apps’) may use to access the data and functionality contained in the system.
The system is designed primarily to provide back-end functionality between trusted systems, each system or application that has permission to use the API is referred to as an ‘App’. Each App is registered within the system and provided both an ‘Access Token’ and a ‘Data Access Scope’ which the system will use to determine which functions and data the App is authorised to access.
The Access Token can be considered in the same way as an end-user’s password and the Data Access Scope like the permissions on a users account. Each form key controls in ensuring the security of the customers data stored in the Loyalty Platform.
While multiple Apps in your implementation may have common functionality and data access requirements it is expected that each will have it’s own Access Token and Scope defined to compartmentalise the risks associated with each integration.
The Access Token forms part of an authorisation system known as ‘OAuth’ which is a widely implemented standard for API access control across the internet, used by Facebook, Twitter and a range of other well known API-driven platforms. This is discussed further in the next section.
Access tokens are generated through an authentication process known as OAuth2 (https://en.wikipedia.org/wiki/OAuth#OAuth_2.0). This document will not cover the ‘how’ an app obtains an access token - that is covered in our API documentation. For now, understand that all requests to the API need an access token in order for the platform to respond.
Data Access Scope
To enhance security on the platform, every client app is assigned one or more app scopes. Just like Facebook apps, Arkade Loyalty restricts access to platform resources on a per-object-per-method basis; for example, if you wanted to create an app that could only view your list of stores, you would assign the app only the stores_read scope. Requests by this app to any other endpoint or method would return in a “401 Unauthorized” response to the app.
This API-app-scope-access token topology allows your developers to create applications following the principle of least privilege to minimise the risks associated with each app.
Mitigation / Control Measures
Loss or Theft of Access Token
Access to any operations permitted for the token.
Long-lifetime Access Tokens
The longer a token remains valid the greater the amount of time available to potentially exploit a lost or stolen token.
Access Tokens with ‘Master’ scopes
Misuse of these tokens could potentially allow complete loss of the database through theft or damage.
Assuming a master token is necessary;
Access Tokens with ‘Delete’ permissions
- Protection measures have been taken to protect the Access Token and Network Access, especially for any Apps with broad scope access.
- Apps should be scoped to do the required loyalty actions and no more
- The platform should ideally shorten its access token expiry
- Developers should NEVER expose access tokens within readable code
- Developer apps should not leverage the long-term token extension process
- Developers should use in-brand 3rd party Redirect URIs
- Said URIs should actively check a verification code & state with the app itself, and the incoming verification request call
- Consider ‘the sky is falling’ - regularly audit all loyalty apps to ensure security in as many ways as possible.
- Ensure that developers realise that they are building apps that potentially award millions of dollars in rewards to customers.
Want to stay in the loop with any updates? Subscribe to our email here.