WorkastSecurity at Workast
Last updated March 10, 2022
Cloud infrastructure
All our services and databases are in the us-east-1 region in AWS. AWS have been certified with multiples security certifications like ISO, HiTrust, PCI, SOC (1 and 2) and carry on penetration tests and other vulnerability tests against their infrastructure, Certificates available to download here https://aws.amazon.com/artifact/
Data encryption
In transit
Web connections to Workast service are via TLS 1.2. We support forward secrecy and AES-GCM, and prohibit insecure connections using TLS 1.0 and below or RC4.
At rest:
Our database MongoDB is encrypted at rest (disk encryption)
For key/value data we use DynamoDB with encryption at rest
For files and attachments we use AWS S3 with object encryption using AWS KMS
Tokens and credentials from Cloud Connectors (like Slack, Google Drive) are also stored encrypted using AWS KMS to make it unreadable even for our employees.
About logins and passwords
Workast doesn’t store any kind of users generated password. To authenticate users in our system we implemented Slack Single Sign On https://api.slack.com/docs/sign-in-with-slack If Slack SSO is not available for a particular user, we send a one time unique and time limited code to their email address that they need to validate. The temporary code is stored in the user session and encrypted via AWS KMS
Data access
Workast employees don’t have access to production database except when there is a need to perform migrations or other operations. In case that we need to provide support for a customer, we explicitly ask for authorization from the customer so we can grant our support staff temporary access to the customer account. All this is monitored and logged.
Data backup
We perform a backup of the whole system every 6 hours and stored in a separate region. We keep backup records for up to 30 days.
Customer data segregation
Data is logically segregated. Every customer has its own unique domain (acme.workast.com) and data is always stored using the team (acme) as a primary key and identifier. When users authenticate to our system, the token that they use to interact with our API has this information embedded and encrypted using AWS KMS.
Security awareness program
We have 3 stages as part of our security awareness program:
Onboarding of new employees: all new employees attend a security training session on how to protect the company data and devices, best security practices and the security requirements per employee company wide.
Ongoing: for technical roles we have vulnerability tests and scan as part of our continues integration pipeline and we offer training around security best practices. Every quarter we audit all employees account with external vendors to make sure they have 2FA authentication and that we are still in fact using those services. Our customer support team have strict rules around accessing and sharing customer data.
Post-incident: hasn't occurred yet, but we will communicate this company wide and implement the necessary training to make sure it doesn't happen again.
Patching process for all infrastructure
We use AWS Systems Manager Patch Manager to perform regularly minor and patches updates in our servers. The maintenance window is every Saturday at 11pm UTC. We roll updates one server at a time with no downtime. If issues are detected during the patch, the changes are rolled back and we will perform it manually.
Security hardening guidelines for computing and network infrastructure devices
Production machines are locked down within our production VPN, there is no root or ssh access and all ports are blocked except the necessary ones for our service to run. We use Docker images to control our server machines and AWS Cloudformation to control our infrastructure. Most of our web services actually use AWS Lambda which adds an extra layer of hardening.
Security incident response procedure
In the event of a security incident, we will:
Contain the thread: stop the necessary process or services to stop the incident from spreading
Investigation: determine the affected systems and potentially compromised data 3. Repair: make the necessary changes to avoid this incident to happen again
Report: report the affected customers of the incident with details about the potential data breach (if any)
Training and prevention: train the necessary teams to avoid this to happen in the future and put the necessary tools and process in place to avoid it.
Continuous code inspection
We use Sonar as part of our Continues Integrations pipeline to inspect and detect vulnerabilities in our different applications every time new code is pushed. We keep code dependencies audited and updated.