Security Practices at Whooshkaa
We take the security of our platform and the the standard at which we do things very seriously. Here are some of the ways in which we work to protect our customers' data.
Security All The Things
Application
In designing and developing our application and its services, we model the application for security concerns around spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege (STRIDE). Our general development processes follow OWASP methodologies and advice.
Architecture
Our architecture aims to separate functionality to be delivered by individual components and services. Each of these is tasked with being secured independently.
People
Whooshkaa’s people who have access to company systems and customer data must use multi-factor authentication (MFA) via registered devices to add an additional layer of protection beyond just passwords. Team members who are not active for 30 days have their access revoked and we monitor this continuously.
Infrastructure and Network
Both our staff and our application services are granted access to our networks via a layered approach, with zone restrictions in place for our corporate networks and different environments of the applications. Our services communicate with each other only through a white-list of clients, granted access through combinations of network and application firewalls, virtual private clouds (VPC) routing and secret access keys, all across encrypted channels.
Our application has several intrusion detection systems in place to continuously monitor and identify security threats.
Reliability
High availability
Each piece of infrastructure is deployed into multiple, redundant host services on our cloud hosting partner, Amazon Web Services (AWS). AWS data centres have multiple levels of redundancy built-in as part of regular service delivery, making our application highly resilient to interruptions. For more information about AWS Compliance, see this page.
Backups
The pieces of infrastructure that make up the data in our applications are backed up at least once per day and retained for 30 days. Areas that form part of our code customer data support point-in-time recovery. When we store the backups, we store them encrypted in the data regions that we deliver the service.
Our backups are tested twice per year.
Disaster Recovery and Business Continuity
At the core of our resilience is our Business Continuity and Disaster Recovery practice, which ensures that disruption to our service delivery is minimized even in the serious events where our infrastructure is disrupted. We test our processes twice per year and store an individual set of procedures for each component, so that it can be recovered to both an “emergency” level of operation before it is transitioned to “business as usual”.
Core Product Security
Isolating Tenancies
Access to customer data is permitted only by user access controls, specific to the context of their needs.
Each customer’s data is logically isolated on our data stores. Our application code is able to distinguish between customer instances (which we call “tenancies”) and only retrieve data for users that corresponds to their tenancy. Each user gets access to a tenancy through a group that has specific permissions, ensuring that what users see is always what they are entitled to see. We centralize all data access in our application through our API so that the tenant ID is always required and is always retrieved for a user through their user context, identified by a special token that goes along with every request.
Encryption
All customer data is secured at rest by AES-256 encryption, with encryption keys managed by our cloud partner AWS (in AWS KMS). Encryption at rest guards against unauthorized access and ensures that access to the data in the data stores is only available to the right roles with the right key.
Data in transit is encrypted over public networks (e.g. retrieving data via the web or via our Dashboard) via TLS 1.2 to protect it also from unauthorized modification. As part of this, we support strong ciphers with web browser support.
Vulnerability Management
We use several processes to guard against vulnerabilities in our code and the underlying services that are needed to run it. This includes both our repositories being constantly scanned for known vulnerabilities as well as the files that are worked with to deliver the service.
We also publish our Vulnerability Disclosure Policy and value good-faith vulnerability research.
Infrastructure
We aim to model our infrastructure to be compliant with AWS Best Practices and have policies in place to govern it. To ensure that we meet these standards, we have continuous monitoring of our infrastructure via several systems including Trend Micro Cloud Conformity, AWS GuardDuty and anti-malware scanners.
Support and Service Delivery
Customer Data
We only allow a very small group of people to access our customer’s data. This extends to people that have been trained in security policies and processes at Whooshkaa and only for the tasks that require them to perform duties to make our customers successful.
Data retention and destruction
When a customer exits our SaaS service, we generally retain data for a limited period of time in order to continue delivery of specific services to them and support them in their transition. This is usually for a period of 30 days (or as per the agreement with the customer). After this period, we make this data unavailable and perform secure data destruction processes on cloud infrastructure as practised by our hosting partner AWS.
Incident Management
Whooshkaa handles incidents through entry both through advice from a customer (via our support desk or security incident dropbox) or continuous monitoring provided via several systems in place to ensure operations and compliance.
When an incident is detected, a tiered-support process takes care of triage and initial investigation, escalation to specialist support and further escalation to third-party support. We log all incidents for management and future analysis (e.g. to aid in problem management processes) in systems that are secured for access by approved personnel only.
We aim to make it very easy for customers to track issue resolution by providing a centralized ticket for each incident and a single interface for making support as well as service requests.
Privacy and Compliance
Our Commitment
We take privacy seriously at Whooshkaa and have a number of practices to ensure both our customers as well as their customers and users are treated with processes that ensure their privacy is retained by them. This includes how we process and store their data as well as our ability to remove it from our systems when requested.
GDPR
Whooshka makes efforts to be GDPR compliant and we publish our Data Processing Agreement (DPA).
Cloud Security Alliance STAR
We use the CSA STAR as a baseline to which we demonstrate how we comply with industry practices and publish our assessment on our CSA STAR page.
Shared Responsibility Model
Overview
The security of data on our cloud offering is a combination of efforts by us and our customers. We call this our Shared Responsibility Model.
At a high level, we take responsibility for the core operations of the underlying system: the application, the systems it runs on and the environments that they are hosted on. Our customers manage all of the information in their tenancies, access by users and their credentials and any processes that interoperate with that data.
To make this easier for our customers, we allow them choices to decide who has access to their tenancies, how they authenticated (with support for SSO via SAML) and which shows and episodes are made publicly available.
Customers are expected to verify all granted access to their data and continuously monitor that it meets their standards.