Latest update: May 03, 2018
Access to Storyblok is monitored and reviewed by automated tools to identify abnormalities and to inform the responsible authorities. The monitoring includes mitigation of brute force attacks.
Every content change is logged and can be reviewed by your developers in the user activity event stream.
The solution is hosted on Amazon AWS. Amazon AWS provides physical data center access only to approved employees. All employees who need data center access must first apply for access and provide a valid business justification. These requests are granted based on the principle of least privilege, where requests must specify to which layer of the data center the individual needs access, and are time-bound. Requests are reviewed and approved by authorized personnel, and access is revoked after the requested time expires. Once granted admittance, individuals are restricted to areas specified in their permissions.
Access to the solution’s internal network is only possible using a public/private key pair via Secure Shell (SSH).
Storyblok applies a systematic approach to managing change so that changes to customer-impacting services are thoroughly reviewed, tested, approved, and well-communicated. The Storyblok change management process is designed to avoid unintended service disruptions and to maintain the integrity of service to the customer. Changes deployed into production environments are:
- Reviewed – Peer reviews of the technical aspects of a change are required.
- Tested – Changes being applied are tested to help ensure they will behave as expected and not adversely impact security.
- Approved – All changes must be authorized in order to provide appropriate oversight and understanding of business impact
The solution is hosted on Amazon AWS in Frankfurt/Germany which has various security certificates like:
- SOC 1/SSAE 16/ISAE 3402 (formerly SAS 70)
- SOC 2
- SOC 3
- FISMA, DIACAP, and FedRAMP
- DOD CSM Levels 1-5
- PCI DSS Level 1
- ISO 9001 / ISO 27001
- FIPS 140-2
- MTCS Level 3
The solution only uses secure HTTPS connections to communicate with other systems. There are access controls in place to only allow access to systems that are whitelisted.
Unusual and malicious traffic is automatically detected by Amazon CloudWatch Alarms and notifications are sent to the responsible Storyblok employee.
Data is backuped to a second physical location using a read replica with automatic failover. Additionally the data is backuped daily to Amazon S3 with a change log for a retention period of 30 days. Restoring is possible at any point in time within 30 days.
APIs of Storyblok are using HTTP with the TLSv1.1 protocol for communication.
Storyblok uses a web application firewall (Amazon WAF) for it’s APIs to mitigate cross site scripting, brute force and sql injections attacks. If an attack is detected a rule is added to the WAF to deny access for the attacker.
Storyblok performs continuous automatic security tests through Detectify as well as manual periodical DDOS tests on the API.
Storyblok performs monthly recovery tests that include point in time database recovery and recovering of static assets through the version control feature of Amazon S3.
Data is protected by design and by default. Policies are in place to ensure that personal data is only processed when necessary for each specific purpose.
To address information security requirements during a major crisis or disaster impacting business operations, we maintain a disaster recovery plan. The Storyblok Infrastructure Team reviews this plan annually and tests selected elements at least annually. Relevant findings are documented and tracked until resolution.
Client Data retention and data destruction
The automated backup feature of Amazon RDS enables point-in-time recovery for your DB Instance. Amazon RDS will back up your database and transaction logs and store both for a user-specified retention period. This allows us to restore our DB Instance to any second during our retention period, up to the last 5 minutes. Your automatic backup retention period can be configured to up to 35 days.
Storyblok has established formal policies and procedures to delineate the minimum standards for logical access to Storyblok platform and infrastructure hosts. Storyblok conducts criminal background checks, as permitted by law, as part of preemployment screening practices for employees and commensurate with the employee’s position and level of access. The policies also identify functional responsibilities for the administration of logical access and security.
In case of a data disclosure we will analyse all logs and close the security issue with an hotfix.
Storyblok is following the OWASP code review guide https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf to ensure that the enterprise security policy is fullfilled. Storyblok´s SDLC uses an agile security methodology which includes following steps:
- Planning (Identify Security Stakeholder Stories, Identify Security Controls, Identify Security Test Cases)
- Sprints (Secure Coding, Security Test Cases, Peer Review with Security)
- Deployment (Security Verification with Penetration Testing and Security Code Review)
Storyblok’s quality assurance follows secure software development best practices, which include formal design reviews by the Storyblok security team, threat modeling, and completion of a risk assessment. Static code analysis tools are run as a part of the standard build process, and all deployed software undergoes recurring penetration testing performed by carefully selected industry experts. Our security risk assessment reviews begin during the design phase and the engagement lasts through launch to ongoing operations.
Storyblok´s development environment has security controls in place that make sure that no sensitive data is used. Only authorized developers can access the development environment and the codebase of the applications is protected by two factor authentication. Every change to the codebase must go through a process of security review following the best practises of the OWASP code review guide. Changes are tracked and every authorized developers gets notifications about code changes which ensures control over movement of data. Backups of the codebase are stored at secure offsite locations periodically.
Storyblok´s testing standards begin in the coding phase with automated security unit and acceptance tests which are executed as part of our build process for every new feature. The developers of the applications are making sure that third-party libraries and executable files are security assessed for potential vulnerabilities before being integrated in the application build. When going to the QA stage security testers are going to test the features with the information provided by feature scope documents. The testers simulate real attack scenarios that can be potentially executed by a malicious external or internal user of the application. The objective of these tests is to test the application in a operational environment. The target is the application build that is representative of the version of the application being deployed into production. After passing the tests in QA testers document the result of their tests and potential security issues. Storyblok´s developers review the documents and approve it if no further security issues have been found.
Storyblok follows the Git Flow standard and doesn’t allow any change to the code that didn’t pass the Git Flow steps.
There are security reviews done by carefully selected security experts. Security reviews are done by developers with at least 10 years of experience of software development and security.
Storyblok follows the OWASP secure coding best practices guidelines V2 which contains a checklist of following topics:
- Input Validation
- Output Encoding
- Authentication and Password Management
- Session Management
- Access Control
- Cryptographic Practices
- Error Handling and Logging
- Data Protection
- Communication Security
- System Configuration
- Database Security
- File Management
- Memory Management
- General Coding Practices
Storyblok does quarterly secure coding workshops internally from our most experienced developers and security experts to keep the whole team up to date.
By the infrastructure design access to the live data is not allowed in development and testing environments. Instead a dedicated database is in place.
The following data will be processed:
- Contact details
- Communication data
- Billing details
- Address details
- Analysis data
- Order and billing details
- Contractual details
The following categories of people shall be subject to the processing:
- Clients of the Storyblok platform
- License holders
- Interested parties
- Website visitors
The data processor undertakes to process data and processing results exclusively pursuant to the data controller’s written orders. If the data processor receives an official order to disclose the data of the data controller, they are obliged to - if legally allowed - inform the data controller immediately and refer the official authority to them. Also, data processing for the data processor’s own purposes requires a written order.
In a legally binding manner, the data processor declares that all the contracted persons had been obliged to maintain confidentiality or that they are subject to an appropriate legal duty of confidentiality prior to taking up their activity. In particular, the duty of confidentiality shall remain in force for the persons involved in the data processing also after their employment and services for the data controller have ceased.
In a legally binding manner, the data processor declares to have taken all necessary measures to guarantee the security of data processing in accordance with Art 32 GDPR.
The data processor shall take the technical and organisational measures to enable to data controller to fulfil the rights of the person concerned pursuant to Chapter III of the GDPR (information, disclosure, correction and deletion, data portability, objection, as well as automated decision making in individual cases) within the statutory deadlines at any time and shall provide the data controller with all the necessary information. If a request is submitted to the data processor and they indicate to have been mistakenly considered the processor of the data operated, the data processor shall immediately forward the request to the data controller and inform the requesting body accordingly.
The data processor shall assist the data controller in complying with the obligations within the Articles 32 to 36 of the GDPR (data security measures, reports to supervisory authorities concerning violation to the personal data protection, notification of the person affected by a violation to the personal data protection, data protection impact assessment, prior consultation).
The data processor shall be informed about the obligation to establish and update a processing list according to Art 30 GDPR for the present order processing.
The data controller or a third-party contracted by them, shall be granted the right to inspect and control the data processing systems at any time. The data processor undertakes to provide the data controller with the information necessary to review the compliance with the obligations determined in this agreement.
After termination of this agreement, the data processor is obliged to forward all the processing results and documents containing data to the data controller or to remove them on their behalf. If the data processor processes the data in a specific technical format, they are obliged, after termination of this agreement, to provide the data either in the same format or at the request of the data controller in a format, in which they had received the data from the data controller or in a different common format.
The data processor shall immediately inform the data controller if they consider an instruction from the data controller as violating the data protection regulations of the EU or the Member States.