5 Security process and routines
Wrepit is built upon security and privacy first principles, practicing “Security By Design” in all levels of product development and employee onboarding. It is our highest priority to safeguard the data of our customers.
While Wrepit handles the platform security, it is important to note that platform users are responsible for their own use of our security and confidentiality features. In practice this means that users are responsible for whom they share their work with and whom they invite into their workspace.
Please notify security@wrepit.net for incidents or to report security issues.
5.1 Security processes
5.1.1 Access and Authorization
- Wrepit practices the principle of least privilege for its employees
- Wrepit enforces the use of strong sign-up mechanisms on employees, including Azure AD SSO, Password Management tools and Multi Factor Authentication.
- Access to critical infrastructure and data is restricted to only 2 key credentialed employees. To access this infrastructure, there are procedures to follow and mechanisms and audit logging in place to ensure that no unnecessary and unauthorized access occurs.
5.1.2 Sub providers
All sub providers are subject to continuous and thorough risk assessments, e.g.:
- Is the sub provider’s product strictly necessary?
- Is the risk assessment satisfactory?
- Does the provider satisfy GDPR requirements?
- Does the provider offer SSO or MFA for identity?
In addition, Wrepit has routines for logging all sub providers and associated risk assessments.
5.1.3 Security training
All new employees are introduced to the threat of cyber attacks, especially through human factors. Security is regularly a topic in staff meetings and all employees go through security training at least once per year.
5.2 Software Development process
The product development at Wrepit is based on a Software Development Lifecycle methodology, with Security and Privacy being central parts along with business requirements.
At the core of all development decisions is the Platform Change Request, and Wrepit has internal tools to manage these requests. Every change request must be evaluated, documented and approved before implementation. This is conducted with an Agile methodology.
Wrepit requires all technical implementations to undergo review before being approved and shipped. The reviewer must ensure that the change request is approved and prioritized before approval can be given. The is appointed during the planning phase, and must consider whether the change, and the implementation thereof, may have security implications beyond the considerations in the change request. The reviewer must consult with the Security team if the change is marked as Security related, deemed high risk, or if the reviewer has any concerns or questions regarding the implementation.
Wrepit has implemented fully automated build and release pipelines (restricting manual deploys), including static code analysis, application security testing, and unit and integration testing in isolated environments. This ensures a repeatable and consistent process with high quality.
The most security critical infrastructure is built using AWS’ infrastructure-as-code services, to ensure consistency and reliability. The infrastructure is built using best practices of separate/isolated layers and using the Well Architected Framework.
5.2.1 Incident Response
Wrepit has in place incident response plans, based on the SANS Insitute’s Incident Handler’s Handbook.