How Uplifter Handles Security

Last updated: 28th July 2021 

Summary 

This document shows the information/cyber risk governance processes in place that ensure an understanding of their technology environment and the state of information/cyber security controls, and a security program to protect Uplifter and its customers from information/cyber threats in accordance with good industry practice.  

This document also outlines some of the key steps we take to protect our customers from information/cyber security risk. 

For reference Uplifter is a Software as a Service (SaaS) platform for creating campaign codes and/or web data anomaly detection. The tool does not connect to any Personally Identifiable data (PII) other than our users email addresses. We only capture our users email addresses for login and support purposes.  

Information Security Governance 

 

Revision and approval 

 

This document is reviewed and updated at least once every 12 months, with additional reviews each time a cyber security risk, opportunity (to increase security) or data breach is discovered. 

Ver.	Date	Nature of Changes	Approved By
1.0	16/04/2020	Original issue.	Alexander Holman-Butt
2.0	18/05/2020	Reviewed and updated formatting.	Alexander Holman-Butt
2.1	03/03/2021	Reviewed and updated sections.	Alexander Holman-Butt
2.2	28/07/2021	Reviewed and updated sections.	Alexander Holman-Butt
X

 

Roles and responsibilities 

 

Document and process owner: Alexander Holman-Butt 

 

Responsible for revising this document when required (outlined in Revision and approval) and presenting amends to the Data Protection Officer for approval. 

Data Protection Officer and document owner: Natalie Hill 

 

Responsible for educating the company and its employees about compliance, training staff involved in data processing, and conducting regular security audits. DPOs also serve as the point of contact between the company and any Supervisory Authorities (SAs) that oversee activities related to data. 

• As outlined in GDPR Article 39, the DPO’s responsibilities include, but are not limited to, the following: 

• Educating the company and employees on important compliance requirements 
• Training staff involved in data processing 
• Conducting audits to ensure compliance and address potential issues proactively 
• Serving as the point of contact between the company and GDPR Supervisory Authorities 
• Monitoring performance and providing advice on the impact of data protection efforts 

• Maintaining comprehensive records of all data processing activities conducted by the company, including the purposes of all processing activities, which must be made public on request 
• Interfacing with data subjects to inform them about how their data is being used, their right to have their personal data erased, and what measures the company has put in place to protect their personal information 

 

Information Security Function 

 

As part of the process of implementing ISO27001 we are developing a dedicated Information Security (IS) function.  We are developing a strong governance framework that is maintained, backed and monitored by management. 

 

Internal processes 

 

There are internal structures in place to ensure compliance with GDPR as well as further cyber security best practise.  These are regularly reviewed and updated and this is communicated effectively to all staff. 

We review the sensitivity of the data that has been stored to ensure that we understand and acknowledge the appropriate level of security that is required.  When we seek to extend our products and services we consider whether the data that we capture is appropriate and relevant and give serious consideration to whether it is required and how it should be stored.  ISO27001 will formalise these classification assessments and record the outcome. 

Continual review of systems and assets is a key part of our risk assessment activities to ensure that risk associated with information security is considered and monitored. 

A structure is in place that ensures compliance with GDPR and data security that provides a comprehensive and approved incident management procedure.  The process of implementing ISO27001 will both formalise and ensure that the process is kept updated and relevant. 

 

Breach Notification Procedures 

 

There is a documented data breach process and assessment, that includes notification procedures to those affected and relevant authorities. 

Employee Life Cycle 

 

Staff training 

 

All staff complete mandatory 3rd party training regarding cyber security awareness and GDPR.  This covers essential parts of information security and data protection.   GDPR refresher training is part of the end of year process once the course has been completed. 

 

Non-disclosure agreements 

 

Non-disclosure agreements are part of the employee contract and these are also required to be completed by external contractors.  These protect our intellectual property, IT configuration and business processes. 

 

Background checks 

 

Pre-employment staff vetting checks include a DBS check, and references are actioned by a 3rd party agency. 

 

Joining process 

 

A process is in place that evaluates the level of logical and physical access to data when employees join the organisation.  A similar process is in place to evaluate the level of access required by external contractors when they join the project. 

 

Leaving process 

 

A process is in place that will comprehensively remove access to the organisation’s data and systems when employees and contractors leave the organisation.   

 

Information security staff qualifications 

 

We are currently in the process of implementing ISO27001 and as part of that a suitably qualified lead. 

 

Access Control 

 

Access control policy 

 

A policy for user access control is in place and documented.  Access to documents and databases is logically and physically separated from the wider organisation group, and access permission levels is enforced.   

Information access is provided on a need-to-know basis, and access is reviewed quarterly to ensure that staff and external contractors have an appropriate level of access to data. 

Privileged access management is managed and monitored using Microsoft Azure Active Directory. 

All devices used outside of our office network connect to systems through VPN and username/password authentication. Access to data and systems held in Microsoft Azure is monitored through Office365 Security and Compliance Centre. 

 

Data storage access 

 

Data is physically and logically stored in such a way that ensures that it cannot be read or made available to other clients.  Access to data storage is restricted.  Data is stored and processed within the UK in Microsoft Azure and Google Cloud Platform data centres.   

Data transfer during processing and whenever the website requests data benefits from end-to-end encryption.  Data in storage is encrypted by Microsoft and Google by default, and we also encrypt sensitive data again to ensure that data at rest cannot be understood if an entity was to gain access to our Microsoft organisational account.  

Data access by clients through the Uplifter product has been designed to prevent any opportunity for clients to see other clients data, through a system of secure JSON web token signing between front end and back end frameworks. 

 

Data removal processes 

 

Automatic processes are in place for deleting and removing data captured by the organisation.  We revoke our access to any 3rd party services (Google Analytics, Adobe Analytics) that we have been granted access to.  We retain data and documents related to billing.   

We can arrange transfer procedures upon request of access for data covered by GDPR.   

 

Projects and Change 

 

Change management 

 

A robust change management process has been implemented, all changes to our standard processes in project or service delivery are reviewed by management and assessed for potential security risks. 

 

Project risk analysis 

 

As part of the project management process risk is assessed prior to project start, a RAID log is maintained throughout the project and risks are reviewed on a weekly basis within the project team.  Any serious risks are escalated up to an including board.  This enables information security to be embedded at all levels in the project lifecycle. 

 

Purchasing hardware/software 

 

Security is taken into account when purchasing new software and hardware.  It is bought only from reputable sources and only serviced by accredited professionals.  Further checks are undertaken when considering access to cloud providers and connecting to external services provided online. 

 

Physical Security 

 

Premises 

 

Physical access controls prevent unauthorised access to the workplace premises.  CCTV covers external access points, cameras and a security alarm are installed within the office.  The office building is securely locked during closed hours. 

Manned security desks are not in place, however the building is locked down via security grilles outside of office hours and access to all floors and stairwells is only available with appropriately coded fobs. 

Confidential waste is destroyed in a secure fashion.  Paper waste is destroyed and shredded, and a procedure is in place to dispose of electronic equipment correctly. 

 

Cloud Storage 

 

Microsoft Azure 

Data is currently processed, stored and monitored in the Microsoft Office 365 cloud and Microsoft Azure cloud.  Extensive and comprehensive documentation regarding security policy and certifications that they hold is available on their website: 

https://docs.microsoft.com/en-us/azure/security/fundamentals/physical-security 

Datacentres managed by Microsoft have extensive layers of protection: access approval at the facility’s perimeter, at the building’s perimeter, inside the building, and on the datacentre floor. 

Microsoft systematically update their procedures and are compliant with the following compliance standards: 

ISO 27001, HIPAA, FedRAMP, SOC 1, and SOC 2. They also meet country- or region-specific standards, including Australia IRAP, UK G-Cloud, and Singapore MTCS. 

Google Cloud Platform 

Data is also processed, stored and monitored in Google Cloud Platform (GCP).  Extensive and comprehensive documentation on security policy and certifications is available on the GCP website: 

https://cloud.google.com/security/overview/whitepaper#operational_security 

Datacentres managed by Google have similar access protocols to Microsoft Azure.   

GCP can demonstrate compliance with the following security standards: 

ISO/IEC 27001/27017/27018/27701, SOC 1/2/3, PCI DSS, and FedRAMP certifications, and alignment with HIPAA, GDPR, and CCPA, among others.  A full list of compliance offerings by region is available here: 

https://cloud.google.com/security/compliance/offerings  

 

System Controls 

 

Hardware protection 

 

All devices that contain sensitive data are encrypted and use up to date anti-virus and malware protection software.  Staff are trained via a third party training platform about how to prevent phishing and similar attacks.  Threats are monitored through the security portal of each platform. 

An authorised 3rd party IT specialist configures and maintains all processing hardware and internal networks according to our security template. 

Laptops are encrypted at the whole disk level using Bitlocker encryption.   

All sensitive documents are backed up to a storage system provided by Microsoft Azure. 

Hardware involved in the running of the uplifter product is located in the Microsoft Azure cloud, within an UK based data centre in London.  Microsoft Azure takes responsibility for patching and securing services the services that they provide that are in use by Uplifter.  Services provided by Google Cloud Platform     

 

Data Location 

 

Services that use the Microsoft Azure cloud platform are located in the UK South availability zone, which is located in London. 

Services that use Google Cloud platform are located in the Western Europe availability zone, where the physical location is listed as either Dublin or London.   

All hosting, processing and storage takes place within GDPR compliant countries within Europe (including the UK). 

 

Internal networks 

 

Two networks are in place in the office. The office secure network is protected by Fortiguard.  The second is a guest network available for other users.  Each network uses separate dedicated ISPs.   

Firewall reviews are undertaken each year as part of penetration testing. 

The secure network is monitored by automatic systems provided by Fortiguard which sends alerts to IT support and the CEO. 

 

Communication networks 

 

Authorised internal communication applications include Microsoft Teams and email using Microsoft Outlook.   

Automated email communication utilises the Sendgrid platform, where access is carefully managed and restricted to key users.   

Helpdesk tickets use the Zendesk platform.  We have a limited number of agent licenses and these are restricted to key users.   

We use Cisco WebEx and Microsoft Teams to connect with external clients for video conferencing.  

 

Security review policy 

 

A penetration test of hardware and policies is undertaken annually by a professional 3rd party provider.  The last test was in December 2019.   

 

Supplier Security 

 

Usage of third party services 

 

Where we use third party services to provide extra functionality to the uplifter product, we endeavour to undertake detailed risk assessments of their services. 

We currently use: 

• Paddle for payment management (https://paddle.com/) 
• Google Datastudio for reporting (https://datastudio.google.com/) 
• Usabilla for capturing client feedback (https://usabilla.com/) 
• Sendgrid to manage automated email delivery (https://sendgrid.com/) 
• Sentry for application error monitoring (https://sentry.io/) 

• Zendesk for managing help desk scenarios (https://www.zendesk.co.uk/) 
• The Microsoft Office 365 suite for storage of documents including document back up services provided by Microsoft OneDrive and Microsoft Sharepoint (https://www.office.com/) 

Detailed information on the security standards and certification is available on their websites.   

We regularly review the services that we use to ensure to ensure each supplier processes data in a way that respects GDPR and meets our standards for data security. 

Access keys to these services are strictly controlled and only available to relevant staff.  This is managed by Azure Key Vault, a secure service from Azure which is only accessible using an internal Microsoft account.  Keys can be rotated quickly as required.  

We will never transmit unencrypted passwords from our servers to third party services.   

 

Web Application Security 

 

Password policy 

 

To register for a user account with uplifter, we store a hashed and salted password that must contain at least 6 characters, made up of at least one letter, number and special character.   

Passwords are hashed using the industry-standard SHA-256 algorithm, salted appropriately and stored as the hashed format.  The password stored can never be reversed to plain text, and extensive efforts are made to ensure that it will not appear in server log files.   

We will never store passwords in plain text. 

 

Coding practises 

 

We endeavour to follow OWASP (Open Web Application Security Project) standards for secure coding practises in regards to a web application design.  

 

OWASP Coding Standards 

 

Some examples of how we follow general OWASP principles are as follows: 

• Input Validation 

We examine all data input into the system and check that it only contains data that we expect. 

Where users can upload files to the site, we restrict the file data and extensions that can be uploaded. 

Whenever a user makes a contribution to our anomaly action recommendation engine, this goes through an approval process before it can be shared with the wider community using the product. 

• Authentication and password management 

Access to the uplifter product is only available through a password protected portal.  Users added to the product must first accept our terms and conditions and provide a password.   

Users added to the site must sign up through a link containing a time-delimited token which is specific to the account that they gain access to and their email. 

• Session management 

Sessions are managed through secure JSON web tokens.  These are time delimited and specific to the user and their account.    

• Access control 

Signed authorization tokens are required on all requests to the backend where the user is in a logged in state. 

HTTPS is required and enforced throughout the product.   

• Error handling 

All errors are logged.  Serious errors, where the application fails, are sent to Sentry where they raise an email alert immediately.  Sensitive data is filtered automatically. 

Analytics and event logging is enabled in all areas of the product.  We store errors in Sentry.io, general logs in an Azure database and analytics is managed by Google Analytics. 

 

General coding practises 

 

Internally we use an Agile framework for developing code.   

Development work is split into frontend and backend teams to develop the web application.  Issues are managed in Trello boards and as Git Issues to ensure that progress on features and bugs is tracked effectively. 

There is an extensive build process during deployment from development to the production version.  This covers errors in the code base as well as ensuring that code has consistent standards.  This process mitigates against common cyber security attacks. 

 

Web application network security 

 

Traffic and data flow networks are all managed by the Microsoft Azure platform.  This platform regularly scans our implementation and we review the security recommendations that it makes. 

 

Service access points (sealed and secure open) 

 

Services in the  Azure platform can be stopped or suspended, which will prevent access immediately.   

Access restrictions can be applied to the backend service to ensure or prevent access. 

Appropriate rules can be applied to the frontend CDN to prevent access, or ensure that it comes from assigned domains.   

 

Distributed Denial Of Service (DDOS) protection 

 

DDOS protection is enabled by default within the stack of Microsoft Azure services that are in use by all services used by Uplifter.  For more information: 

For the frontend framework: 

https://docs.microsoft.com/en-us/azure/cdn/cdn-ddos 

Every property in Azure is protected by Azure's infrastructure DDoS (Basic) Protection. The scale and capacity of the globally deployed Azure network provides defence against common network-layer attacks through always-on traffic monitoring and real-time mitigation.   

For the backend framework: 

https://docs.microsoft.com/en-us/azure/security/fundamentals/ddos-best-practices#azure-offerings-for-ddos-protection 

Basic DDoS protection in Azure consists of both software and hardware components. A software control plane decides when, where, and what type of traffic should be steered through hardware appliances that analyze and remove attack traffic. The control plane makes this decision based on an infrastructure-wide DDoS Protection policy. This policy is statically set and universally applied to all Azure customers. 

 

Protecting against common security risks: OWASP Top Ten 

 

The OWASP Top Ten (https://owasp.org/www-project-top-ten/) is a globally recognised standard for developers to follow about the most critical security risks that can affect modern web applications.  Here are some examples of how we  eliminate or mitigate these risks. 

 

Injection 

• An injection attack occurs when untrusted data is sent to an interpreter as part of a command or query.  If the attacker is able to insert malicious code into the data they are able to execute unintended commands or access unauthorised data from the database. 

When data is sent to the backend to be used in queries, it is carefully formatted and checked for correct typing.   

Any additions to our database of anomaly causes and recommended next actions are validated manually before they are made available to the wider community to ensure that the content is not malicious or contain scripts that could affect the application. 

All requests to the backend contain a time-limited secure token.  This token is personalised to the user that logged in, and all interaction with the backend is based off this secure token.  Identity is based off this token rather than data stored in cookies or passed in requests.  This effectively limits access to data to only the logged-in user.   

 

Broken Authentication 

• Applications that have been implemented incorrectly can allow users to assume other user’s identities temporarily or permanently. 

Our password policy follows the industry standard.  Passwords are transmitted over HTTPS.   

Our token framework ensures that interaction with the client is limited to data accessible by their account.  This is a secure time limited token that is used as a session identifier that has high entropy.  This is not transmitted in the URL but within the headers of the request body.   

We intend to implement multi-factor authentication to perform secure actions regarding billing, and as a general option when requested.  

We offer logging in or registering using SSO services from Microsoft and Google.  In these cases we do not store the password hash, but instead follow the best practise for secure authentication using OpenID Connect from these providers.  We do not currently offer SAML authentication as OpenID Connect is more modern and secure, and is an alternative that any organisation is able to use.  

Our public API is only available on request, and tokens generated to access the API will only allow access to that organisation’s data.  The public API is hosted alongside the backend. 

 

Sensitive Data Exposure 

• When applications do not properly protect sensitive data, particularly at rest or in transit, this allows attackers a potential access point. 

The database is encrypted at rest and in transit by Microsoft, and we further encrypt the value stored by Microsoft and decrypt it when it is required to be accessed.  All fields referring to an individual or the organisation can only accessed by their encrypted value within the database and this enables encryption in transit and at rest.   

We regularly review the data that we store about individuals and organisations to ensure that we only keep data for as long as necessary that it remains relevant. 

Encryption methods for passwords and data encryption use industry standards.  The encryption method for encrypting passwords is different to the encryption method for other data. 

We store encryption keys in a secure store provided by the Azure Key Vault service.  This is a central location where keys can be rotated quickly. 

 

XML External Entities 

• This is an attack that mostly affects older web applications - poorly configured XML processors on a site can run code from an attacker’s file by making the site run scripts that are local to the attackers machine.  This allows them access to data about the file system that the site is running on. 

Our frontend and backend framework do not permit the upload of XML documents.   

Data is typically transferred between the front end and backend as either JSON or GET parameters, and not with more complex formats. 

 

Broken access control 

• This exploit takes advantage of how user permissions is managed by an application.  When an application’s user management system has been poorly configured it allows attackers to access other users accounts, change files, alter user permissions.   

Our user management system has been carefully configured to only allow access to accounts where users have been added by an authorised user that is relevant to an account.  Only ‘admin’ level users can make changes to an account, and when these changes are made it they are made in respect to the account and their level of permission within that account.   

‘Billing’ users act as ‘super-admin’ users and only they have access to subscription level billing data. 

Users from the Uplifter organisation have full access to any account and act as global application administrators.  This access is strictly controlled and can only be given manually to internal users.    

 

Security Misconfiguration 

• This is the most common attack vector – if the infrastructure where the code is running has not been configured in a way that respects security, then  there are many exploits that attackers can take to compromise an application 

The application runs securely on Microsoft Azure infrastructure.  We use a container architecture for our build process that allows us to minimise and reduce access to the site and it means that we run the site using a minimal operating system that only contains the necessary features, components and documentation required to run the site.  Only necessary programs are installed to facilitate the running of the site, the rest of the operating system is clean.  

We do not return stack traces to users when the application fails.  Minimal logging occurs on the backend and detailed logs are sent securely to our account on sentry.io.   

Common ways of interacting with running containers are disabled (such as SSH) and ports that are open are not disclosed and are limited.   

The back end has CSRF protection enabled and this is tied to the front end. 

 

Cross Site Scripting (XSS) 

• Cross site scripting occurs when an application includes untrusted data on a web page without validation or accesses an API that is able to create HTML or Javascript that is run on the page.  This allows attackers to hijack user sessions, deface websites or redirect the user to malicious sites. 

Components on the front end are set up to only communicate with the backend server or a local instance of the back end server.  Great care has been taken to minimise dependency requirements for the front end and these always come from popular trusted sources and never from untrusted CDN sources. 

The front end is written in React JS that automatically escape XSS attacks by design. 

 

Insecure Serialisation 

• This is where attackers attempt to tamper with messages as they pass between the front end server and the back end server.  This can lead to changes in application logic on the server that can lead to attackers code being run from the system. 

This is mitigated by the front end by the use of Typescript.  Input data is validated by the backend from GET parameters or as JSON objects. 

Communications with the backend make use of a timed secure token which contains the data about the user and their account that is not communicated through parameters in API requests between the front end and the backend.   

The secure token prevents tampering, and any action taken by the user is limited to their user profile and account and is not able to be altered. 

 

Using components with known vulnerabilities 

• Components, libraries, frameworks that have been installed or are being run on the server have the same privileges as the application.  If one of these libraries is taken over by a malicious entity then this can fundamentally undermine application defences and enable various attacks.  For example, Adobe Flash player is known to include a series of vulnerabilities and is often blocked as such by browsers when it is included on a page. 

The front end framework makes minimal use of external dependencies, and when they are being considered they are carefully vetted for their impact on security. 

The backend framework only uses dependencies from popular trusted sources, and the usage is closely monitored to reduce the impact of this attack. 

Installed packages and software is frequently updated. 

Our application code is stored privately in a secure remote repository and our container images are stored in a private repository on Microsoft Azure.  

 

Insufficient Logging and Monitoring 

• This is where a security breach goes unnoticed due to a lack of sufficient logging and monitoring methods.  Most breach studies show the time to detect an anomaly is over 200 days. 

We log all application and coding errors securely in our account on Sentry.io.  Every time this occurs, an email alert is sent to relevant developers.  This system allows us to classify the different errors that occur and track issues over time and enables delayed forensic analysis.  Logs captured by sentry.io contain enough data about the interaction to determine suspicious or malicious accounts, but sensitive data (usernames, emails, passwords) is not stored by default.   

Logs from the server are not stored permanently and contain minimal data which is never sent to the client.  We log user activity (logins, password reset requests, account creation, account deletion) in a secure database.   

 

Intent 

The following are features that are on the roadmap for completion: 

• 2 factor authentication for enterprise clients 

• Re-authenticating users when performing important actions