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: Plattform and Patching Overview, Default Hardening
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, a patch or a complete new image that 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 is writeable. The system always boots from a default image. A 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 needs 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 a verification of the image PGP signature to ensure that it is an official StoredSafe release
StoredSafe's image-based platform includes only packages which are required for the platform and products. No unnecessary packages are installed, in order to minimize the number of attack vectors and patching needed.
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.
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:
To assure confidentiality over time all StoredSafe products can easily change crypto algorithms and modes on the fly as needed, without putting current data at risk. Furthermore you won’t have to do any complex data migration, as soon as you handle your stored information it will be encrypted with your most resent crypto algorithms.
StoredSafe utilizes 4096 bit RSA Keys for asymmetric encryption and AES-128 in OFB mode for symmetric operations.
StoredSafe uses TLS/SSL for protection of data in transit. The idea is to have as strong encryption as possible without breaking too many browsers and also mitigating attacks similar to BEAST etc.
Note: We plan to change the OFB mode in the future to a list of choices with preferred mode set to GCM or similar when ready for production.
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.
Note: The system user is not able to read or decrypt information stored in StoredSafe Secure Platform.
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 passwords.
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 optionally more YubiKeys in static mode. The private key and password of the escrow user will be exported and transferred to a 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).
StoredSafe is designed to store your most sensitive information. That’s why two factor authentication is required and included as part of StoredSafe Secure Platform.
Our preferred, recommended and currently supported implementation are Google Authenticator and Yubico’s YubiKeys as client-side hardware token in addition to a strong passphrase.
To further improve security, YubiHSM (Hardware Security Module) is incorporated in the platform to store cryptographic keys for all YubiKey hardware tokens and secret keys for Google Authenticator. This provides an excellent authentication server for YubiKeys and Google Authenticator . This enables our customers to be independent of Internet, and critical networking services when in need of access to critical data during a disaster.
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 Logging chapter of StoredSafe System Administration Guide.
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 StoredSafe System Administration Guide, chapter: Backup Management