Trust, Security, and Compliance
Audits, Certifications and Standards, Regulations
To enhance the cybersecurity of 1E by identifying and reducing risk, protecting against potential cyber-attacks, detecting when they do occur, responding rapidly, and recovering quickly.
1E helps IT teams improve end user experience, tighten security, reduce costs, and evolve operations from cost center to strategic enabler. Customers receive digital experience analytics, IT automation, asset intelligence, and endpoint management in a single platform.
1E is dedicated to protecting data confidentially, integrity, availability, privacy, and service continuity. We take many steps to ensure secure coding practices, a secure platform, organization compliance.
System and Organization Controls (SOC 2) Type 2
Report on controls placed in operation at 1E Ltd relevant to Security, Availability and Confidentiality and the suitability of the design and operating effectiveness of its controls.
For the Period December 1, 2022 to February 28, 2023
Vendor Cyber-Risk Profile
Responsible Disclosure Policy
Please include the following information:
- The platform component or website page affected.
- The class of the vulnerability identified.
- A non-destructive proof-of-concept of the vulnerability, or instructions on how to reproduce it.
Please note* that we do not offer a paid bug bounty program.
- Do not exploit or take advantage of the vulnerability more than strictly necessary for us to be able to reproduce it.
- Do not disrupt the service or intentionally perform any change to a production system.
- Do not communicate to any third-party information about the vulnerability without our explicit consent. Similarly, do not share with anyone potential data that you might have accessed to demonstrate the impact of the vulnerability.
- Do securely delete all data retrieved as part of your vulnerability report as soon as it is no longer required.
- We will get back to you within 72 hours. If you need a faster response, please contact our Customer Support.
- We will keep you up to date about the investigation we perform regarding the reported vulnerability.
- We will not pursue any legal action against you for reporting and demonstrating the vulnerability if you follow the guidelines above.
- We will handle your report as confidential and will not share it outside 1E unless we are legally required to do so.
Security Contact Details
Mon – Fri 9am – 5pm
India +91 120 402 4001
UK +44 20 8326 3351
US +1 917 339 2364
Calls received out of hours may be forwarded to our 1E Support Group
Many of you may have heard about the recent security incident involving MOVEit, a file transfer software that was compromised by a ransomware attack. Some of our customers and partners have asked us if 1E is affected by this breach and what steps we are taking to ensure our security.
We want to assure you that 1E is not impacted by the MOVEit breach. We do not use MOVEit as a part of our products and services. None of our software contains any MOVEit components or dependencies.
Furthermore, our production cloud environment is also safe and secure. Our security team has verified that we do not have any exposure to MOVEit within our Azure architecture and service offering. We follow the best practices and standards for cloud security and compliance.
We take security very seriously at 1E and we are constantly monitoring the situation and other vulnerabilities as a part of our normal security operations. We will keep you updated if there are any changes or developments that may affect you. Thank you for your trust and confidence in 1E.
OpenSSL is an open-source software library used to secure communications using SSL and TLS protocols.
Two vulnerabilities have been recently identified in certain versions of this component when a malformed certificate can cause a buffer overrun in the certificate verification process. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.
OpenSSL is used within the 1E Client and Tachyon Platform as part of the Tachyon Switch.
OpenSSL is not used in any other 1E product.
The risk here is very low due to the servers it connects to.
The 1E Client will use OpenSSL for TLS connections to:
- 1E Tachyon Switch – very low risk, because the server cert presented by the Tachyon Switch is under the control of 1E (for SaaS deployments) or our customers (for on-premises deployments)
- 1E Platform infrastructure (e.g. 1E Platform Background Channel) – no risk, because this does not use OpenSSL (it uses IIS)
- Internet/intranet-based HTTPS endpoints to download content via SCALE – this is low risk. The 1E Client is vulnerable to parsing a malicious certificate if a web server presents it (and a trust chain can be built for that certificate). However, we and our customers have control of the content of the instruction payloads, and therefore the URLs of websites therein from which the 1E Client will download content.
Due to the above, 1E will update the OpenSSL component in the next release of the 1E Client
1E Tachyon Platform
Our engineering team are currently investigating the impact to the 1E Tachyon Switch if a client tried to connect with a maliciously malformed certificate. Initial information suggests the impact is limited to causing the Switch to crash.
A hotfix will be issued where required, for each release of 1E Tachyon to update the OpenSSL component to a new patched release.
Table last updated 30th November 2022
|Tachyon 5.2||Tachyon Switch||Not Vulnerable|
|Tachyon 8.0||Tachyon Switch||Not Vulnerable|
|Tachyon 8.1||Tachyon Switch||Fix Required||Q22645|
|Tachyon 8.2 (SaaS)||Tachyon Switch||Fix Required||Updated|
|Tachyon||1E Client||Fix Required||Next Release|
Please ensure you are signed up for Tachyon updates under Knowledge Article Subscriptions within your profile page on the Support Portal to get the latest updates when hotfixes are available.
The Log4NET open source component, provided by the Apache Software Foundation, is used by multiple 1E software components for logging and is affected by a vulnerability in a early version of this component.
The Log4NET component is configured using an XML file.
The vulnerability can be exploited by configuring the XML file with URL’s using the ‘file://’ string to point at files locally on the server. The contents of any file could then be returned by the Log4NET component which might return it to an external user in the form of an error message output.
An attacker would have to already have file system access to change the contents of the XML configuration file of Log4Net, so the attack has a low probability as other mechanisms would need to be exploited to gain access to the XML file in the first place. However, the Log4NET component may be running in a process that has different permissions and therefore access to more privileged parts of the file system , and thus the impact of the vulnerability being exploited could be high.
We therefore recommend customers to apply these hotfixes as soon as possible to remediate this vulnerability.
The vulnerability has the CVE code of CVE-2018-1285 and the type of attack has the CWE code of 611CVE-2018-1285CWE 611
This page will continue to be updated with the latest status for each product.
*The links take to you the hotfix section so you can download the latest accumulated hotfix as they will include the specific hotfix listed here in addition to any later fixes.
Last Updated – 17th March 2022
Tachyon Platform 8.0
|1E Client||All Modules||Not Affected|
On 9 December 2021 a security vulnerability was found in Apache’s Log4J component which is commonly used in Java products for logging. The vulnerability utilises the JNDI feature to cause malicious code to be downloaded and executed on a remote server. This has also been called Log4Shell
Further details can be found under CVE-2021-44228
1E have determined that none of our software products or associated subsystems utilise the affected components highlighted by these security advisories.
Consequently this issue does not affect our software products and we do not believe that customers need take any further action with regard to our products.
The following refers to ServiceNow and MID servers which is used when connecting ServiceNow to Tachyon
After a thorough investigation, ServiceNow has confirmed that instances of the Now Platform are running a version of Java that,
by default, implements settings to prevent this vulnerability.
More clearly, these settings are set as follows:
Additionally, MID Servers have log4j turned off for third-party libraries. Moreover, the Java versions that are shipped with the
MID Servers are not vulnerable, and have the same settings as listed above.
Further details from ServiceNow can be found here
Further Reading which maybe of interest
Frequently Asked Questions
General use of personally identifiable information
1E uses customer Personally Identifiable Information (PII) to respond to requests and to provide, enhance and secure the platform. Generally, PII includes first name, last name, phone numbers, email addresses, and data provided by customers to use the platform.
PII collected by the 1E platform
PII collected by the platform for use by customers within the platform is as follows:
- Process executions: Whenever a process starts on the device, the name of the process.
- Username: The name of the user in whose session the process was launched (or blank if it is a system-launched process)
- DNS queries: Whenever a DNS address is resolved.
- FQDN: The Fully Qualified Domain Name (FQDN) that is being resolved.
- Process stabilization: The time taken for a process to be considered stable. This is captured when a process starts on a device, but only if that process is in a list of processes selected for monitoring.
- Username: The name of the user in whose session the process was launched (or blank if it is a system-launched process)
- ARP cache entries: Translations between IP addresses and MAC (physical) addresses, known as ARP (Address Resolution Protocol).
- IP address: The IP (v4) address
- MAC Address: Hardware Media Access Control(MAC) address
- User usage: Details about user sessions from login to logout.
- Username: Domain-unique readable username. Note this value may be unique to an individual device.
- SID: Windows Security Identifier (SID) of the user. Note this value may be unique to an individual device.
- Email: Soon to be implemented. The email address that is cached in the system for this user. This may not necessarily be the email address to use to contact the user via corporate email.
- First name: Forename that the system has cached for the user.
- Last name: Surname that the system has cached for the user.
- Device inventory: Inventory data for each device.
- SMBOID GUID: Allows system administrators to remotely identify and manage these systems.
- 1E client GUID: Unique key used by 1E platform to identify the device.
- Time zone: Can be used to identify the location of the device.
- OS-locale: Can be used to identify the location of the device.
- IP addresses: IP addresses appear in log files that may be sent back to our SaaS support team for diagnostics.
- Log files capture device names and IP Addresses for troubleshooting purposes. These files are stored in an encrypted disk volume and can only be accessed by 1E support engineers.
- Except for log files used by 1E support, no other customer data stored within the platform can be accessed by 1E employees.
The following Azure regions are supported in SaaS. If you need support in another region, please reach out to your CSM team so they can a investigate if we can support that region.
Customers should be aware that data is never stored outside of the region that they select when signing up for the platform.
- For customers in the UK, this means all data is stored in London.
- For customers in the EU, this means all data is stored in Amsterdam.
- For customers in the US, this means all data is stored in Virginia.
- For customers in Canada, this means all data is stored in Toronto.
Where new regions are added in the future, the location of the corresponding data center will be announced to allow customers to make appropriate decisions when reviewing concerns such as the Data Protection Directive.
All 1E employees and contractors must undergo background screening prior to employment where local legislation allows.
All 1E employees must read and agree to the 1E employee handbook covering company policies, code of business conduct and ethics, and acceptable use policies. Our acceptable use policy outlines requirements around,
- Hardware, software, mobile device, e-mail, and network use
- Social media
- Data classification, handling and ownership
All employees and contractors must sign a Non-Disclosure Agreement (NDA) prior to employment. Third-party services must sign an NDA before use.
All 1E employees and contractors attend mandatory information security training during the on-boarding process, as well as annual training thereafter. Training is tracked and monitored to ensure compliance.
1E’s Secure Software Development Lifecycle (SDLC) standard defines the process by which we create secure products and the activities that must be performed at each stage of development.
Change and release management
All changes to 1E production software follow 1E’s change management process. 1E performs code reviews for internally developed software and services. Code changes must be approved via pull requests before they are merged into master branches, automated unit testing, automated functional testing, automated integration testing, and automated security testing.
All developers are trained on software vulnerabilities, including the Open Web Application Security Project (OWASP) Top 10. These are taken into consideration during the development of features. All code is housed in source control where engineers are granted access based upon least-privilege. Training in handling sensitive data is included in the required annual security training.
1E’s monitoring processes and procedures provide continuous proactive and detective capabilities. 1E uses several sources and tools for identifying, tracking, responding to, and remediating vulnerabilities. We subscribe to security mailing lists for our OS, Datastores, Web Frameworks, Languages as well as to industry and government mailing lists.
Vulnerability management and penetration testing
1E performs regular and continuous scans of our systems to identify vulnerabilities. When a vulnerability is discovered, corresponding tickets are filed in our internal ticketing system and prioritized according to 1E’s support SLA. In addition, 1E performs annual penetration testing of our networks and services, as well as regular application penetration testing. All penetration testing is performed by independent third parties.
Patches and upgrades are applied based upon the severity level of vulnerability according to our patch management policy. Critical severity patches are applied within 7 days of patch release, High severity patches within 2 weeks.
Platform infrastructure1E platform operates on resources hosted within Microsoft Azure. These resources exist and span several different Azure Regions to provide increased performance for customers around the globe. The 1E platform functionality is separated into several customer-facing services as follows:
- Web portal: For customer users of the platform.
- Switch: A permanent connection established with all connected devices to facilitate low latency event and command communication.
- Background channel: Used for downloading large data out-of-band of normal switch communication.
- API: A REST API for programmatic interaction with the platform.
Server instances1E platform uses Windows Server 2022 Core Long Term Servicing branch and Ubuntu for the base operating systems of the server instances, hosted within Azure IaaS. These operating system images have been specially prepared and hardened for use in Azure by 1E. Server instances are launched from prebuilt and tested machine images to ensure 100% consistency. These virtual machines are backed up by Azure recovery services vaults.
DatabaseAll data sent to the 1E platform is uploaded to SQL databases. The SQL instance is separate from the rest of the 1E platform components and is held entirely separate from any other customer data.
FirewallsThe 1E platform is only accessible through an Azure firewall instance that provides network Intrusion Detection and Prevention Services (IDPS). All Azure resources for each customer are also secured by a dedicated Azure Network Security Group. All access to the 1E platform is via encrypted TLS over port 443.
Information classification1E has a formal information classification policy. Each information classification has specific requirements regarding the handling (i.e., access, storage, use, identification) of that data. Data deletion and destruction 1E customer data resides in the Microsoft Azure cloud. Ninety days after service termination (or earlier upon request) 1E deletes all customer data using the API’s provided by Microsoft.
Data encryptionEncryption in transit All data transmitted to and from 1E over public networks is secured via HTTPS Transport Layer Security using TLS 1.2 or above. Encryption at rest All data at rest is encrypted using AES-256
Platform monitoringIn addition to the instance monitoring services provided by Azure Data Explorer, the 1E platform uses several services to provide effective monitoring of platform health and metrics. For example, core platform services are monitored for health and throughput using custom metrics that are then pushed to Azure Data Explorer and DataDog. Custom metric and log gathering code is deployed to each server. Azure Data Explorer and DataDog provide near real-time feedback on platform load and other potential issues that may occur, alerting regarding problems or service outages. 24/7 response is ensured through PagerDuty and a robust and well-practiced escalation procedure within 1E support. By monitoring the platforms in this fashion, 1E can identify, pinpoint, and resolve potential customer issues before they become apparent to the end user.
1E platform architecture
Web portal security
All access to the 1E platform web portal occurs over TLS v1.2 encrypted HTTPS using standard RSA 2048-bit certificates.
Access control is provided by the customer’s own OAuth based Identity provider (IdP) via Single Sign-On (SSO). 1E currently supports Azure Active Directory and Okta directly, but other IdP’s may be accommodated providing they follow OAuth 2.0 standards.
1E recommends that customers configure their IdP to enforce multi-factor authentication.
The platform is entirely API driven, and the web portal is simply an extension of the API, the API is therefore secured in the same way as the Web Portal. Non-interactive API access can be configured through the customer’s own IdP by using certificates as outlined in the online documentation.
1E client and switch security
The 1EClient.exe executable code is digitally signed with a certificate from 1E.
All communication from the 1E client to the switch is encrypted using mutual TLS 1.2 RSA encryption over WebSockets on TCP port 443. Customers must provide a valid PKI root certificate upon service creation, and only clients with a valid client certificate from that PKI instance will be allowed to communicate with the customer’s switch instance.
This ensures that there can be no accidental data contamination between customers of the platform and ensures no data leakage can occur through an unauthenticated client gaining access to a customer’s switch.
There is also communication between the client and the ‘background channel’ which is encrypted using mutual TLS over HTTPS on TCP port 443.
The 1E platform uses the IPv4 protocol. IPv6 is not currently supported.
Stateful packet inspection
Communications between clients and the switch and clients and the background channel cannot use stateful packet inspection as this would break mutual TLS and platform components would deny connectivity.
Supported TLS cipher suites
The 1E platform only supports one of the following TLS Cipher Suites
The 1E platform runs on hardened Windows Server and Ubuntu Linux operating systems, with all instances launched from a patched and maintained Microsoft provided image. This image is then further hardened by using Packer and PowerShell scripts. This ensures consistency across all servers in the 1E platform and provides a base level of security. All server instances are then patched on a regular basis. All critical and security patches are applied weekly. All other patches are applied monthly. This includes all operating system and SQL patches.
Identity and access management
Each 1E platform instance is hosted within a separate Azure resource group and virtual network, with no shared access. Administration of the service is performed using both the Azure console and Azure API services for programmatic access.
Only essential staff within 1E have access to these services, with access configured using Azure Identity and Access Management (IAM). All logins to the console are required to have a secure pass phrase of at least twenty characters in addition to the use of multi factor authentication using Azure Active Directory and Microsoft Authenticator. Programmatic access to the Azure API is controlled through security principles stored within the 1E Azure Active Directory.
Each user has no direct access to any customer servers or data, and any such access must be requested through Microsoft Privileged Identity Management (PIM), is time limited, and must reference an open support ticket or authorized change control. All requests must be approved before being granted, and all approvals and subsequent elevation of privileges are audited. Privileges are automatically removed once the time limit is reached.
1E requires National Institute of Standards and Technology (NIST) best practices for passwords and mandates the use of Single Sign-On (SSO) with multi-factor authentication.
All access to server instances is performed using Microsoft Azure Bastion, which can only be used through the Azure portal, following a log on via Azure AD and MFA. User login credentials must be retrieved from Azure Key Vault storage for a particular instance. Access to the key vault can only be provided by Privileged Identity Management approval and is audited.
The 1E platform undergoes periodic penetration testing, both application and infrastructure, via external approved companies at least annually.
The platform is continually tested for vulnerabilities via the use of automated tooling in the Microsoft Defender suite.
The web interface and APIs are also tested daily using Microsoft Azure External Attack Surface Monitoring (EASM).
1E’s cloud engineering team constantly monitors the availability and performance of each customer instance through Azure data explorer and DataDog, and any alerts are raised through PagerDuty.
All security events and metric data across all 1E resources are streamed in real time to 1E’s Security Information and Event Monitoring (SIEM) system which is an instance of Microsoft Sentinel. This is monitored 24/7/365 by 1E’s Security Operations Center (SOC), and incidents are raised directly with 1E’s security engineers.
1E maintains multiple monitoring systems to detect and alert incidents. Incident severity is classified based upon customer impact and duration of incidents. 1E will notify affected customers of any security incident in line with our incident management plan.
1E performs regular testing of our business continuity plans, and disaster recovery tests at least annually.
Recovery Time Objective (RTO) / Recovery Point Objective (RPO)
RTO = In the event of the VM being lost we will restore service by recovering the VM from backup within 4 hours.
RPO = The service is backed up every 24 hours at midnight local time.
All backup data is encrypted in transit and at rest and written to geographically replicated data stores.
1E has a formal third-party security review process for assessing third-party vendors at the point of engagement and annually thereafter. During this process we compare the classification of data stored and accessed by the third party with the data handling procedures outlined in our Information Classification policy. 1E’s security team performs a technical assessment to determine if the vendor meets these requirements.
All third-party libraries used by our platform are scanned for vulnerabilities daily and updated appropriately.
All 1E employees are required to use key cards to access our physical offices. Physical access is logged. Key cards are centrally managed by our business support team. All Business Technology infrastructure is secured in a separate climate-controlled room with fire suppression systems and limited access rights.
Clean desk policy
Employees are required to ensure that all restricted / confidential information (customer, vendor, employee, or intellectual property) is secure and stored in locked areas and out of sight when they are not in use or when the workspace is vacant. All such printed documentation must be stored and locked within secured containers. All computers must be (logically) locked when the workspace is unoccupied.
Data center security
Data center physical security for our hosting provider (Microsoft Azure) can be found here: https://docs.microsoft.com/en-us/azure/security/fundamentals/physical-security