We have focused heavily on security and permissions to address the needs of businesses.


Encryption in Transit

All communication from client to the cloud infrastructure is over SSL/TLS with adherence to latest security best practices. We actively keep track of the latest security guidelines and implement recommendations as soon as practically possible such as enforcing latest ciphers and deprecating older ciphers. Servers refuse connections for older SSL versions such as SSLv2 and SSLv3 which are now deemed to be insecure, INGBOX™ utilises TLS v1.2 Our servers require valid SSL certificate and enforce strict Server Name Identification (SNI). Servers accept connections explicitly whitelisted endpoints; all other connections are declined minimizing attack surface.

Encryption at Rest

All stored files are encrypted at rest with AES256 which is consistent with current security best practice recommended by the and UK Communications Electronic Security Group (UK CESG) and US National Institute of Standards and Technology (US NIST) for encryption of data at rest.

Passwords

A strong password policy is enforced by INGBOX™ with a minimum length of 8 characters, including special characters, numbers and upper/lower case letters. New passwords are validated prior to being accepted and cannot contain user's first or last name. Passwords are not stored within INGBOX™ in clear text they are stored with one-way encryption. The application does not and cannot decrypt passwords. Forgotten passwords cannot be retrieved. They have to be reset either by the user or by authorised administrator When administrators create passwords for end users, they auto-expire. After successful login users are required to change their password.

New User Creation

When new users are created an email to verify the user's email address is sent. Administrators do not have access to the verification. Users can then click on the verification email to confirm they have access to that mailbox. After successful login, users can setup security question to add additional layer of protection.

Disable INGBOX™ Support Login access to user data

INGBOX Support have no access to customer data unless specific permission is requested and given to INGBOX When INGBOX consultants create a new customer account, once the customer has taken control of the account, we have processes in place to remove the ability for INGBOX to access the customer data. The only way to access customer data is if the customer gives access. System maintenance by INGBOX is accomplished without accessing our customers data.

Robust Permissions Model

The level of permissions control provided by the application meets the needs of the most demanding and security conscious customers. We support a robust permissions model where you can control access down to an individual file level. Each user has very granular permission and the use of INGBOX™ Cabinets, Folders and User Groups prevent the need to give permissions to every file (unless you want to).

Audit History

Trust but verify INGBOX™ logs actions such as file download, upload, user creation, and file access by all user including support admin users. If a user downloads a file or uploads a file, the activity is logged with the user information and timestamp. Administrators can view historic logs for specific users over a date range.

Infrastructure Security

Physical Security

Our main data centre is based in Germany in a secure and secret location. All our servers are in dedicated locked cabinets with only designated personnel allowed authorised access. Authorized personnel are required to show government issued photo identification such as passport before being allowed entry into the datacentre. All personnel or contractors go through a rigorous security backgrounds checks and are trained on INGBOX™ technology, policies and procedures, to ensure they comply with INGBOX™ standards.

Server Access

We follow lights out management philosophy for cloud operations and most of the server management is automated. Only IT Operations personnel are allowed access to production servers.

Disaster Recovery

We have built-in to our architecture redundancy, which means if any device fails, service will fail over to redundant hardware so we can fix the failure and ensure there is no data loss or disruption in service. We take care of performance, data back-ups, and availability, so as part of our service, we have SLA around availability and unscheduled.