At Forty4Hz, we take data security very seriously. We have incorporated multiple steps to ensure your data's privacy, confidentiality, availability, and integrity.

All interactions with INSIA occur only over secure TLS connections on the latest recommended secure cipher suites. We use industry-standard P-256 ECC digital signatures or an optional P-386 up to RSA 2018. The application modules are regularly audited by the team and routinely patched. Access to the platform can be isolated to whitelisted IPs only.
​
Once deployed, the application and databases are virtually air-gapped and can’t be accessed on the network. User-level logging can be done on the lowest granularity. Multi-Factor- Authentication ensures no single point of failure. Moreover, INSIA works on a microservice architecture. The applications are containerized and isolated so that communication can be blocked entirely from one service to another.
​
INSIA upload application is configured with a one-way flow and an optional approval relay. This makes it impossible for one data uploader to view any sensitive data related to another data uploader. Any data uploaded can optionally be scanned on the relay server to be approved before reaching its destination.
​
On top of this, we are encrypting the end-to-end data flow using best-in-class data security and governance framework. Our servers run on stable, regularly patched versions of Amazon Linux with carefully configured security groups, isolated VPC environments with well-defined network segmentation, role-based access control, and advanced web application firewall protection. We do not have in-house data centers. Amazon Web Services (AWS) manages our data centers' physical and environmental security. Our internal security program covers physical security at our offices.
​
Please refer to AWS security measures here: https://aws.amazon.com/compliance/data- center/controls/
​
Our applications run on the latest stable version of Node.js. We reduce the attack surface by isolating our processes via hardened containerization technology. Our security team sets architectural guidelines, conducts code reviews, and deploys every software system that can interface with customer data.
​
All customer application data is stored in Amazon RDS's databases, configured securely. Data is stored with at least dual redundancy, with 15-day backups, and is accessible only within the private cloud. We have also instituted per-service access protection and isolation of data.
​
We maintain all internal testing and validation data in a production-stack equivalent internal stack populated with fictitious data. Forty4Hz does not distribute actual customer data for internal testing or validation purposes.
​
All communication and responses strictly follow no intermediate cache rules. Data is not allowed to be cached in any un-reliable caching middleware.
​
​

Data Isolation

The client data server cluster is managed by its own security parameters. The server has no outgoing or incoming internet access. The server has no public IP address and is impossible to access directly.
​
Access to the server is possible only through a private IP available to the system admin. The server is accessible only after three layers of authentication, where each layer has its own secure password policy, and each password is updated frequently as per internal guidelines. Access to the relay server is always granted to system admins on a 1-1 basis where no access is presented on an IP block.
​
Forty4Hz maintains a high standard of client-to-client data isolation, which is hardcoded during deployment. All the application or client data is virtually isolated from one another. Strict policies ensure no data overlap takes place.
​
​

Firewall

SQL Injection and XSS: Rules designed to protect against common SQL injection or cross-site scripting (XSS) patterns in the URI, query string, or body of a request.
​
HTTP flood: This component protects against attacks consisting of many requests from a particular IP address, such as a web-layer DDoS attack or a brute-force login attempt.
​
Scanners and Probes: This component parses application access logs searching for suspicious behavior, such as an abnormal amount of errors generated by an origin. It then blocks those suspicious source IP addresses for a customer-defined period.
​
Bad Bots: This component automatically sets up a honeypot, a security mechanism intended to lure and deflect an attempted attack.
​
White and Black Lists: The client can configure access control to only specific IP addresses where the application will be available. For example, the client office has a range of IP addresses that could be in the firewall white list. Which would ensure that the platform can be accessed only using the office network and no other connection.
​
Geography Level Access: The product can be isolated to a particular country where the application can be accessed using a connection that originates from a specific country.
​
​

Logging

Logging on the platform is done on different levels. Every request to the API is logged immediately with the response's status. The Front-end application also has the same logging and monitoring features as the API. Error logging on API or server failure is handled and stored for effective and efficient bug fixes.
​
​

Granular role-based access control (RBAC)

INSIA is configured with a very dynamic and versatile RBAC that admins can control. The admins can control precisely what individual users can access. Access can be granted or restricted on the table, column, and entity levels.
​
​

HTTPS all the way

All application client communication takes place over Amazon-provided SSL, which is always up-to-date. SHA RSA 256 – industry standard signature algorithm used. No option for an HTTP-only connection.
​
​

Minimal Downtime

Forty4Hz API and Deployments are configured in the most optimal production environments with fail-safe policies. The platform is configured to auto-restart if there is any failure in the server or code. This ensures downtime protection for every user.
​
​

Authentication