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 is also a key technical factor for meeting our EU GDPR obligations.
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 with multi-factor authentication), 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 is 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. Backups are retained for a period of 35 days and then destroyed.
To help us maintain regulatory compliance, understand database activity, and gain insight into discrepancies and anomalies that could indicate suspected security violations (another aspect of the EU GDPR), we have deployed three advanced security features on our primary application database servers:
Advanced Database Auditing helps Skedda maintain regulatory compliance, understand database activity, and gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violations. Database audit logs are retained for a period of 90 days and then destroyed.
Advanced Threat-Protection Monitoring detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit the Skedda production database. It continuously monitors the production database for suspicious activities and provides immediate security alerts to the Skedda operations team on potential vulnerabilities, SQL injection attacks, and anomalous database access patterns. In the particular case of the GDPR, this service forms a key part of the technical machinery that enables us to detect data breaches and notify supervisory authorities in the unlikely event that one should occur.
Automated Periodic Vulnerability-Assessment Scans proactively discover and track potential database vulnerabilities, triggering alerts when required so that the Skedda operations team can resolve them quickly. Scans are run on a weekly basis.
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 (strictly enforced to be a minimum of 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. The connection must use TLS 1.2 or higher (i.e. we forbid connections using the outdated TLS 1.1 and TLS 1.0 protocols, and also the outdated and vulnerable SSL 2 and SSL 3 protocols). You can verify the up-to-date configuration of our SSL certificates here, and verify our strict TLS 1.2 or higher policy here. We also support HTTP/2 for improved performance.
The accepted TLS connections are encrypted using an SSL certificate using one of the strongest web standards available. To help ensure that only our trusted Certificate Authorities can issue a certificate for *.skedda.com, and hence to help prevent the misuse of certificates in some circumstances, we have an active DNS Certification Authority Authorization (CAA) record. It's now mandatory for certificate authorities to implement CAA-checking, and our CAA record will prevent unauthorized CAs from issuing certificates for *.skedda.com.
As part of all responses, our application servers include a number of advanced security headers. These include but are not limited to:
Content-Security-Policy: Instructs browsers to take strict measures to prevent cross-site scripting (XSS), clickjacking, and other code injection attacks resulting from the execution of malicious content in the trusted web page context. Specifically, we have deployed a so-called "strict CSP3 policy" using the state-of-the-art "nonce" and "strict-dynamic" options.
Strict-Transport-Security: Also known as HSTS. Instructs browsers to only ever access Skedda using HTTPS (i.e. never using HTTP). We have deployed this header with a long duration/time-to-live (one year), and we're also on the HSTS preload list (see below).
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.
Expect-CT: Tells a web client/browser to enforce Certificate Transparency requirements (i.e. checking that our site certificates appear in public CT logs), which helps prevent the use of misused Skedda certificates.
Referrer-Policy: Allows us to control the value of the "referer" (sic) header for links away from our pages. In our case, we specify that the "referer" header should not be set when the navigation results in a downgrade from HTTPS to HTTP.
X-Frame-Options: Unless explicitly allowed by a venue administrator, this header prevents browsers from rendering Skedda pages in other sites (using e.g. frames and objects). This helps to avoid "clickjacking" attacks.
Skedda receives an "A" grade from the independent, industry-standard security-header-checking service securityheaders.io. You can run the test on demand and view the report for yourself. We also encourage you to run the test against other websites you may be using or you may be intending to use. We have automated tests in place to detect regressions from our "A"-grade state.
Our full domain skedda.com (including all subdomains) is on the HSTS Preload List for direct inclusion as an "HTTPS-only service" in modern browsers. This "hard-coding" of our full domain in browsers ensures that they will never attempt to connect via insecure HTTP. To verify for yourself that skedda.com is included in this list, you can visit (e.g. in Chrome) chrome://net-internals/#hsts and query the HSTS list for "skedda.com".
Our full domain skedda.com has additionally enabled DNSSEC to ensure that DNS records are not tampered with. You can view the security details of our DNS setup here.
Skedda receives 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 the latest state-of-the-art protocol attacks (BEAST, POODLE, Heartbleed, Heartbeat, Robot...).
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.
Authentication in Skedda is secured in numerous ways. Firstly, we support Single Sign-On via SAML 2.0, as well as the ability to use existing popular service logins via OAuth 2.0 (Facebook, Google, Twitter, and Microsoft accounts). Using either of these "external login" options means that Skedda users don't need to create additional credentials for authenticating with Skedda (i.e. users can use their existing authentication mechanisms). This is convenient and secure, supports multi-factor authentication flows, and is the approach we generally recommend.
For users that still wish to use a password-based login approach, we employ various industry-standard techniques to protect our users:
We use a strong password-hashing format/algorithm (PBKDF2 with HMAC-SHA512, 128-bit salt, 256-bit subkey, 100,000 iterations). This format is designed to make it intractable for an original password to be recovered given its hash.
To help prevent dictionary attacks, our login mechanism additionally employs account lock-out functionality if an incorrect login password is entered multiple times.
We also employ a strong password policy: all Skedda passwords must have 1) at least one lowercase character, 2) at least one uppercase character, 3) at least one digit, and 4) at least a length of eight characters.
Skedda of course masks the password when it is entered by the user into the interface.
HTTP cookies sent from the server to the client for authentication and request-verification purposes are always marked with "HttpOnly", "Secure" and "SameSite" 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 an 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. Please reach out to our support team if you would like a copy of our compliance report. 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.
The transactional emails sent by Skedda make use of the latest security features for email validation. These include valid SPF, DKIM, and DMARC policies. In the case of DMARC, our published policy instructs recipient servers to quarantine all messages that don't pass the DMARC test. These features are advanced tools that help to prevent spamming, spoofing, and phishing attacks. Naturally, we also include unsubscribe links on all the emails we send and have implemented rate-limiting to help prevent annoying "mailbombing" attacks.
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. No customer/live/production data exists on these systems in any form (only dummy data is used).
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.
General access to our production hosting environment (for monitoring our hosting resources and diagnosing problems) is only available to specifically-selected and highly-trained members of our operations team, and only after strict authentication requirements have been met (including multi-factor authentication and IP-based firewall checks).
By default, no Skedda staff member has access to customer accounts via the web interface. The trained members of our customer support team do have the ability to request such access in order to perform their job functions (i.e. provide customers with support), however these access requests 1) require multi-factor authentication, 2) are heavily rate-limited, 3) are logged and monitored closely with automated-alerting infrastructure and 4) are only temporary (i.e. the access is automatically revoked after a short period of time).
Our compliance posture against various regulatory standards is automatically monitored through the security center in the dashboard of our hosting provider. Specifically, numerous controls (those that can be automated) for various standards are evaluated in real-time, and alerts are sent to our operations team in the event of any deviations. We are proud to be fulfilling all of these controls for the following regulatory standards, and we are happy to share the corresponding reports with our customers (please reach out to our support team for a copy):
ISO 27001 (2013)
SOC TSP
PCI DSS 3.2.1
Skedda is committed to maintaining a robust cybersecurity posture by promptly addressing zero-day vulnerabilities. Upon identification of a zero-day vulnerability, Skedda's Incident Response Team will be activated within 24 hours. The impact of the vulnerability will be assessed, and appropriate mitigations will be implemented. Patches will be tested and deployed as a priority to minimize any disruption to operations. Continuous training and awareness efforts will be maintained to ensure readiness and compliance with regulatory standards.
In the case of any general service 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 have independent penetration testers evaluate the security at Skedda, and quickly respond to any security-related questions, issues, and reports (e.g. vulnerability reports). We have a dedicated security team composed of full-time security engineers reachable via security@skedda.com.
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.