Detailed Technical Specification


  • 1U Rack server
  • Chassis with tamper detection
  • Intel CPU with multiple cores and hardware random number generator support
  • Redundant power supplies
  • 12 TB RAID5 Storage
  • YubiHSM

Operating System and Application Standards

  • OS: ISO-Image based on Ubuntu
  • Database: MySQL
  • CLI-GUI: Perl

As part of SDLC (System Development Lifecycle) StoredSafe plan to fully adopt and implement the OWASP top ten awareness document, to mitigate risk of security flaws in our applications as well as to establish a company standard and culture of secure coding.

Read More: Default Hardening

Platform and Patching Overview

  • Our OS is an image-based Linux installation. This image is maintained and updated in line with our SDLC (System Development Lifecycle) as well as our “Product Roadmap”, usually about 4-6 times a year.
  • At each release we evaluate what needs to be updated to keep the platform up to date and secure. In cases where there is a need for separate security patches due to security vulnerabilities that could potentially affect our platform (e.g. poodle/shell shock, etc.) StoredSafe will update our image for testing, distribution and installation at the customer site. Thus, we use the same procedure whether it is a release update or a patch, a new complete image replaces the old one.

The image is read only and only customer-specific parts such as host name, IP address and of course database content are writeable. The system always boots from an default image, change of default image is done easily and intuitively through our system console gui (please see our StoredSafe System Administration Guide). When satisfied, just set the new image to permanent boot image.

ISO-image based solutions also facilitates an easy “roll back”, the system administrator just need to set the old image to permanent boot image and reboot the system.

  • In case of an upgrade to a new major release, the roll back procedure may require a restore of latest backup.
  • Before an image can be installed, the system performs verification of the image PGP signature to ensure that it is an official StoredSafe release

Default Hardening

StoredSafes image-based platform includes only packages which are required for the platform and products. No unnecessary packages installed, in order to minimize the number of attack vectors and patching needs.

As a part of StoredSafes SDLC, we have decided to implement AppArmor for critical services. This update will be released in line with our roadmap.

Local Firewall

StoredSafe secure platform includes a local firewall that is configurable from the System Console gui. All incoming access is denied by default.

See list below for configurable ports:

  • Web-access 80/443 (port 80 is a redirect to 443)
  • RADIUS Sync for HA (High Hvailability)
  • SNMP v3
  • SSH


StoredSafe Secure Platform includes only one “user” account, this account is used during installation and configuration, maintenance and upgrades. This account has no direct privileges in the application or database rights, only privileges for system maintenance. The account password is 64 characters long and is set by the customer at the time of installation. This password is divided into two YubiKeys configured in the “static mode”. This is to assure segregation of duty. To log in as system user the system administrator needs access to both keys as well as access to the console (optional SSH-access not recommended)

The system user can not access the system through the web interface.

This account has no permissions in the application, however the system user has indirect privileges in the database, as the database also partly is used by the system console gui.

The overall system, uses a few other system accounts, upon delivery all passwords are changed by the customer according to a checklist. This is to ensure that no accounts have default password.

Escrow User Account

In case the optional escrow functionality is enabled, an escrow user will be enabled. The password of the private key of the escrow user will be distributed to two or optional more YubiKeys in static mode. the private key and password of the escrow user will be exported and transferred to USB memory stick as part of the checklist procedure. The key and password is also printed on paper to be stored in a safe, this is to ensure the ability to restore critical information in case the usb stick fails when needed.

We strongly recommend that escrow YubiKeys are not stored together but distributed to two persons (e.g. CSO and Compliance officer).

Logging Overview

StoredSafe Secure Platform currently supports forward of syslog to an external syslog server over UDP or TCP.

The audit log is not a part of syslog and is accessed via StoredSafe web gui. It can also be exported in CSV format. The audit log contains no encrypted information but only information about who saw what, when, etc.

Please read more about logging and how to configure in our Syslog Settings chapter of StoredSafe System Administration Guide.

Backup and Restore

Backup is scheduled in accordance with the customer’s existing backup policy and/or requirements.

All data, encrypted as well as unencrypted, is backed up in a PGP encrypted file for distribution to one or more destinations. Starting with version 2.1.0, normal procedure is that one log destination is a StoredSafe Warm Standby server to ensure rapid recovery of critical data without dependency to external back-up sources.

Transport of back-up files are encrypted using SSH/SCP.

Restore of backup is managed through StoredSafe Secure Platform System Console Gui. Please read more about back-ups and configuration in Stored Safe System Administration Guide, chapter: Backup Management