Ensuring the security of your data and the reliability of our services are our top priorities. This document describes our approach to security, and includes details about how we implement that approach for our cloud-hosted services.

Risk Management, Intrusion Detection and Mitigation

We follow several best practices to safeguard the integrity of the systems hosting your data. In managing your server on our cloud infrastructure, our emphasis is on shielding these systems from malware, strengthening their resistance to network-based attacks, and keeping the operating system free of known OS vulnerabilities.  We use CIS Benchmarks and DISA STIGs, as well as common industry guides and internal documents, as references when designing, deploying, and managing our cloud host systems.

The core policy of our hosting architecture is to minimize the “surface area” exposed to potential security exploits.  We install the minimum required software on our servers – practically speaking this means we install the Linux OS, our own software, performance and monitoring tools, and a simple outgoing-only SMTP server.  The underlying OS is a base server configuration, which means no GUI platform is installed, nor are any productivity suites, browsers or other software that might provide an avenue of attack.  We do not install server software like apache, java, or php since these are commonly targeted by attackers due to their popularity.  Our database system is proprietary and inaccessible from the network except indirectly through our own APIs.  Of course, all security patches are applied as they become available, and the system is kept up-to-date with the latest software versions.

Each host server runs a collection of anti-malware processes aimed at discovering potential malware intrusions and the unauthorized changes they might make on the system.  These separate tools cover a broad range of malware, and provide redundancy to improve chances of detecting an intrusion.

We strictly limit the network ports that are available for incoming connections.  The system firewall is configured to allow connections on only three ports:  HTTP (80, 443), and SSH (22).  The two HTTP ports are used for all client, browser, and admin communications.  The SSH port is accessible only by select Sassafras staff who maintain the servers, and uses secure, audited, non-password-based authentication.

On these open ports we implement context-aware monitoring and dynamic blocking of addresses that are actively attacking the server. This detection and mitigation effectively blocks widely used attacks such as brute-force password guessing, distributed denial of service (DDoS), and common vulnerability scans. Other aspects of our architecture make most of these attacks mere annoyances in any case, but by dynamically blocking attackers as we detect them we can reduce network traffic and unnecessary resource usage. In addition to our own efforts, our cloud service provider monitors and prevents a range of attacks aimed at the networking infrastructure.

In support of our primary service, we allow outgoing traffic for services like SMTP and Sassafras’s PRS. Note that this allowance is for outgoing connection only – these services are not enabled for incoming connections. The (outgoing-only) SMTP server is fully configured for DKIM, DMARC, and SPF to ensure reliable and trusted delivery of email sent from your server instance to your organization’s mail accounts. Connections to other external services configured for individual customer servers can only be outgoing – incoming (listening) connections are not possible and would not be allowed through the system firewall.

The bulk of the code (other than the operating system) running on the host systems is developed by Sassafras.  This includes the main KeyServer processes, the tunnel server that acts as a load balancer and first line of defense, and various tools for managing the system and data.  See our Secure Coding Practices for more information on how we develop our software.

Data Security

Each Sassafras Cloud server collects information about individuals in a customer organization. While this information is private and can be considered sensitive, it does not include government IDs, personal health information, credit card numbers, or other individual financial account data.  Servers can also store information about purchases, software install codes, and serial numbers, so maintaining a secure data environment is paramount.

Data In Use

Data that is actively “in use” (whether stored in computer memory or on an active file system) is not encrypted since it must be accessed quickly by the server processes. Each customer’s data runs separately in its own “silo”. All processes that handle customer tenant data operate solely for that customer, and are not shared between tenants (the underlying operating system is shared among the tenants on a host). All processes are restricted by the OS so they can only access their limited set of data. OS-level file permissions and ACLs protect the data from being accessed by unauthorized processes.

Data In Transit

Data transmitted between the server and any external system is sent on a network connection using TLS (SSL) based protocols like HTTPS and secure SMTP. This includes data sent to or from browsers, endpoint computers (KeyAccess), administrator sessions (KeyConfigure), and backup storage servers. When an on-premise server is being migrated to a cloud host, data is transmitted over a secure HTTPS connection directly to the cloud host.

If a server is configured to use external services such as an OIDC authentication provider, an LDAP server, or other integrated products, the customer is responsible for using secure protocols that ensure the safety of any data transmitted. For example, when an external service uses HTTP as its underlying protocol, the configuration should use an “https://…” URL so data is encrypted in transit.

Data At Rest

Part of data security is preventing data loss. All customer data is backed up daily both locally and to a separate system. Off-system backups are maintained in three sets: daily, weekly, and monthly. Backups are stored in customer-specific containers which can only be retrieved with secure access tokens.

This backup data is considered “at rest” since it is not being used actively by any server processes. It is encrypted in transit, as above, and is further stored in encrypted form. Even if the access token is known, there is a separate encryption key that must be known in order to decrypt the data.

Authentication & Access Control

Legitimate access to your data must be secure and customizable. Our role-based access model provides a fully configurable mechanism for granting access, so authenticated clients can only view, modify, and manipulate the data that they are allowed to.

Accounts can be locally managed, where identity information is stored locally. For these “internal” accounts, plaintext passwords are not stored. Instead a secure one-way hash is stored in order to facilitate authentication. Internal accounts can be configured to require strong passwords. There is a small number of internal accounts pre-configured on each server. These accounts, which are used by local processes in order to access the core data engine, have secure random 128-bit passwords that are unique to each server. It is important to note that all access to the core data engine – even access by the sub-components of the server software – require proper authentication before they will be permitted.

Accounts can also be managed by external identity providers such as Azure AD, Google Workspace, and many other services. Authentication with these services uses standard security protocols like OIDC, and can augment security via mechanisms like Multi-factor authentication (MFA).

All administrator access, including data creation, modification, and deletion, is logged by default. Full change histories are maintained and easily viewable (by those with the required permissions).

Operations Access

In order to manage cloud services, Sassafras staff must access the host systems directly. Most such access is done via SSH connections. Our SSH configuration requires authentication via secure one-time tokens, as opposed to passwords. All access is audited, and only select staff are authorized to connect via SSH. The SSH service is constantly monitored for intrusion attempts, and uses the same dynamic detection and blocking policy that we use for the primary services.

Additional access, mainly for system monitoring, is done over HTTPS connections.  Such access is authenticated against Sassafras’s company identity service provider using standard security protocols, including MFA.

Compliance

Read about security at our cloud provider Linode, and view their compliance information at these links:

Sassafras has not pursued third party certifications of compliance with security standards. We understand that some customers place a high value on such certifications when evaluating any software they will use in the cloud. For this reason we fully support running our entire software platform on-premise. This option provides customers with complete control over their data and security environment, removing the questions about what access third parties might have to private information.

Sassafras has made great efforts to ensure that the initial setup and ongoing operation of our software is simple and streamlined. Because we do not require any additional software products (other than the operating system of your choice), installation of our software can be completed in a matter of minutes. Furthermore, the components of the platform have been optimized to work efficiently, and thus have comparatively low computing resource requirements. The server software can run on basic hardware, even older desktop hardware that might otherwise be discarded.

For customers who wish to run the software themselves, we openly share the tools and practices we use in our own cloud hosting operations. With this information customers choosing an on-premise installation can benefit from our experience and add their own knowledge to implement a customized security policy.

Technical Details

Cloud Provider:  Akamai / Linode (Dedicated CPU virtual machines, Object Storage, DNS)

Cloud Host OS:  Ubuntu Server (22.04 LTS)

Sassafras Identity SP:  Google Workspace (MFA enabled for all accounts)

Secure Key Management:  Hashicorp Vault (private, self-hosted)

SSL Certificate Authority:  Let’s Encrypt

Visual Overview