Uncompromising Security for Your Compliance Needs

Security

Data Storage

Physical storage

AWS (Amazon Web Services) is responsible for handling the physical security of the infrastructure. AWS is built to not only allow for truly scalable cloud-solutions, but also to meet the highest expectations for security.

The data is stored on servers from a facility that is ISO 27001, ISO 27017, ISO 27018, and SOC 1, SOC 2 & SOC 3 , -certified. To get the full overview of the compliance programs, click here

Location

All data and backups are stored with AWS in Frankfurt. Backups are stored in different availability zones to ensure data availability.

Get an understanding of the data centers perimeter layer, infrastructure layer, data layer and environmental layer, click here

Encryption

All data is encrypted while in transit and at rest. This ensures data integrity as the data cannot be corrupted or modified during transfer, privacy as the data cannot be intercepted by any 3rd party eavesdroppers, and authentication as the end-client can be sure that the site that it’s connected to is actually us.

In Transit

Data moving in transit is encrypted using TLS (Transport layer security). Only TLS versions equal to or above 1.2 are supported, all other versions are blocked.

At Rest

Whenever data is stored on a hard disk, e.g. data stored in a database, then it’s encrypted using AES (256 bit). This prevents data reading in case of a physical hard disk is stolen at a data center.

Patch Management

At Formalize, we prioritize security and high availability by leveraging AWS-managed services wherever possible. These services undergo continuous patching and maintenance by AWS. However, for certain non-AWS-managed services, we implement strict patch management processes to ensure that security remains intact.

Data Backup

Frequency of backups

Periodic backups are made to ensure customer data is not lost. Backups are done in daily intervals (backups expire after 35 days) and weekly intervals (backups expire after 85 days).

For services not managed by AWS, such as our Jump Box, patches are scanned for and applied daily. In addition, our Jump Box is secured on a private network that requires two-factor authentication for access and logs all connections for better monitoring.

Certain services, like our Web Services, are jointly managed by AWS and Formalize. These are scanned and patched continuously to maintain security and performance.

Backup Security

All backups are stored in different availability zones to prevent loss of data. An availability zone is one or more separate data centers with redundant power, networking, and connectivity. All backups are protected to the same standards as the production environment.

Logging

Formalize takes logging seriously and has extensive logging throughout our application, we are continuously improving our logging. Logging is done into four different levels: login events etc., validation errors, error logging, DNS flow logs etc.

System Monitoring and Intrusion Detection

We leverage AWS GuardDuty, an intelligent threat detection service that continuously monitors for malicious or unauthorized activity in our network. It acts as our primary Network Intrusion Detection System (NIDS). Admin activity and DNS query logs are also logged and analyzed for potential misuse. More about GuardDuty can be found here.

To enhance our defenses, we use AWS WAF. This service helps monitor and thwart malicious web requests, offering an additional layer of protection against hacking attempts. For more details click here.

Secure Development Lifecycle

A secure development lifecycle (SDLC) is a process that helps us ensure that security is built into the software from the start. Our SDLC includes various security activities that are performed at each stage of our development process. These activities help us to find and fix potential security vulnerabilities and prevent new ones from being introduced.

Several key lifecycle activities are performed including building and releasing in small increments, technical debt, 3rd party package policy, scanning for leaked secrets, version control, vulnerability checking, cryptography standards, metrics and logging, developer training, testing, and separation of environments.

Vulnerability Management

At Formalize, we take security seriously by employing robust vulnerability management practices to protect our infrastructure and to improve continuously.

Vulnerability Avoidance

To minimize our attack surface, we maintain a single public entry point to our API, which is safeguarded by a Web Application Firewall (WAF). This firewall effectively blocks common threats such as Cross-Site Scripting (XSS) and Remote Code Execution (RCE). Our infrastructure is based on Alpine Linux, providing a minimal and secure operating system footprint. Furthermore, our web servers are designed to operate as read-only containers that are refreshed every 15 minutes or during deployments, ensuring that malware cannot persist in our environment.

In addition to these preventive measures, we rely on managed services to enhance security and reduce the risk of configuration errors. These managed services provide automatic patching, further reinforcing the integrity of our infrastructure. Database access is tightly controlled, requiring two-factor authentication (2FA) and limiting access exclusively to approved users within our network.

Vulnerability Scanning

At Formalize, we employ comprehensive vulnerability scanning practices to proactively identify and address potential security risks across our systems. Our scanning efforts encompass code dependencies, containers and servers, as well as our broader infrastructure and network.

Code dependencies vulnerability scans are done daily. This is done using four different tools: Public CVEs, private vulnerability database, open source dependency with XSS (Cross-site scripting), and open source dependency with RCS (Remote code execution).

Container and server scans are conducted continuously and whenever code is pushed. These scans focus on detecting vulnerabilities in OS packages within our Alpine Linux-based environment. Public CVEs and private vulnerability databases are used for scanning. For instance, they can identify outdated versions of OpenSSL that might pose buffer overflow or RCE (remote code execution) risks.

Our infrastructure and network scans occur every 18 hours and adhere to rigorous standards, including CIS (Center of Internet Security) requirements, PCI DSS v3.2.1 (Payment Card Industry Data Security Standard), and the foundational security best practices of our hosting provider. These scans are designed to identify misconfigurations, such as unencrypted queues or the absence of two-factor authentication for administrative users.