In today’s complex and regulated environment, our users entrust us to protect their data using industry-standard tools and practices. This article gives an overview of the multi-layer, "defense in depth" efforts made by Skedda to meet these requirements.
We begin with the persistence layer. We encrypt the storage of our entire primary application database, its associated backups and its transaction log files "at rest". This security feature involves the use of so-called "Transparent Data Encryption". The encryption uses an industry-standard, FIPS 140-2 validated, AES-256 symmetric encryption key. This key is protected by a certificate that is rotated at least every 90 days. This approach is a requirement of many industry standards (e.g., HIPAA, PCI). It also a key technical factor for our compliance with the EU GDPR (applicable from May 2018).
We further secure our persistence layer by limiting access to our primary application database to the application layer and a fixed set of known Skedda-owned IP addresses. This access-limitation is achieved using a combination of firewall rules, authentication mechanisms (requiring users to prove their identity), and authorization through role-based memberships and permissions.
We address the possibility of a catastrophic application data-loss (e.g. as a result of a natural disaster) by automatically creating database backups using a geo-redundant approach. We create full, differential and transaction-log backups, each of which are encrypted as discussed above. Full database backups happen weekly, differential database backups generally happen every few hours, and transaction log backups generally happen every 5 - 10 minutes. In the event of data-loss, we are able to restore our database to a specific point in time to minimize lost information.
Between our persistence layer and the application layer, we secure your "in flight" data by providing encryption using the industry-standard Transport Layer Security cryptographic protocol (TLS 1.2). The database server's certificate is validated in this process (the server name of the database SSL certificate must exactly match the server name specified by the application layer, otherwise the connection attempt is aborted).
At the application layer, we force all inbound requests to use secure HTTPS (HTTP over TLS) connections. Depending on the client device, the connection may use TLS 1.0, TLS 1.1 or TLS 1.2. We forbid connections using the outdated and vulnerable SSL 2 and SSL 3 protocols.
The accepted TLS connections are encrypted using an SSL certificate using the strongest web standard (SHA-2 & 2048-bit encryption) for the RSA key pair. The signature algorithm is based on SHA-256 with RSA encryption.
As part of all responses, the server includes a number of security headers. These include but are not limited to:
- X-XSS-Protection: Instructs modern browsers to abort communications when they detect reflected cross-site scripting (XSS) attacks.
- Strict-Transport-Security: Instructs browsers to only ever access Skedda using HTTPS (i.e. never using HTTP).
- X-Content-Type-Options: Instructs browsers to strictly follow the MIME types ("Content-Type") specified in server responses, and not to try to "sniff" the content type. This helps to defend against MIME content-sniffing attacks.
The Skedda application-hosting servers receive an "A" grade from the independent, industry-standard Qualys SSL Labs server test. You can run the test on demand and view the report for yourself. The report notes that we're not vulnerable to some of the more recent vulnerabilities like BEAST, POODLE and Heartbleed.
On the client layer, we use industry-standard techniques to help prevent phishing and hacking attacks. For example, we use the Synchronizer token pattern to fight cross-site request forgery, and validate all user-input for HTML/script and injection.
The cookies sent from the server to the client for authentication and request-verification purposes are always marked with "HttpOnly" and "Secure" attributes, and have their domain and path values appropriately set for use with Skedda.
We prevent the forgery of authentication and request-verification cookies by using an advanced data-protection mechanism. The default payload protection algorithm used is AES-256-CBC for confidentiality and HMACSHA256 for authenticity. A 512-bit master key, rolled automatically every 90 days, is used to derive the two sub-keys used for these algorithms on a per-payload basis. The key store is only accessible through a HTTPS connection using a connection string that is configured directly on and only visible by the production Skedda web application.
With respect to online payments, Skedda is PCI compliant. In practice, all payments are processed directly with your chosen payment gateway. As such, no sensitive payment details ever make contact with Skedda-owned systems (it is instead transparently redirected to your gateway and then managed through a token-based approach). Our primary payment-gateway provider Stripe has further details on their security page: https://stripe.com/docs/security/stripe.
At the organizational layer, Skedda employees have restricted access to your data based on the "need to know" and "least privilege" security principles. Development and test systems exist on an in-house network that is not externally accessible. Our application source code is managed in a private repository and includes no sensitive information (like API keys, passwords or connection strings) - all such information is stored securely in a key vault within the hosting environment.
In the case of any incidents (e.g. application outages, degraded performance or similar), we provide real-time updates at status.skedda.com. General application news and updates are provided at updates.skedda.com.
Finally, we regularly contract independent penetration testers to evaluate the security at Skedda, and quickly respond to any security-related questions and issues.
We hope that this article has helped you to understand the security mechanisms in place at Skedda. We continuously review our security procedures, so this article may well change in the future as we respond to the evolving security landscape. As always, we invite you to reach out to our support team if you have any questions.