Our Take on the Okta Security Incident
While the recent Okta security incident did not impact Skyflow or our users, it does present a great opportunity to share our thoughts – and a few reminders – about security practices.
The recent disclosure of an Okta security incident involving the breach of an Okta customer support analyst account has been the source of security concerns for many companies. We’re pleased to report the incident did not affect Skyflow or any of our customers. This post outlines how we handled the incident and explains our approach to security in general. It also includes a few reminders on things we can all do to ensure the security of all of our systems.
Skyflow’s Incident Response
As soon as we learned of the incident, our security team began following it closely and launched our own investigation. We use Okta, but Okta support access to our systems is disabled by default, so after Okta’
s disclosures about the incident, we were confident we were unaffected. In addition, our use of Okta is just one part of our multi-layered approach to security. Nevertheless, our incident response policy is to investigate every threat.
After thoroughly checking for (and not finding) any signs of unusual application activities and support-initiated activities, working with our contacts at Okta to ensure we had all the relevant details about the incident, and determining that all the other elements in our security system were sound and working as expected, we sent a notice to customers reassuring them that all was well.
Skyflow’s Security Philosophy
At Skyflow we know that data security is critical to the success of our customers. That’s why we go above and beyond industry security requirements to ensure that customer data is secure. Our core philosophy is to take a defense-in-depth approach to security, so we think about security at multiple levels, the first of which is our product.
Skyflow’s Data Privacy Vault lets you protect sensitive data while still using it. Each vault is isolated, so data is never co-mingled. Data in Skyflow vaults is not only encrypted but also protected using tokenization and redaction. And with customers being able to use their own encryption keys, not even Skyflow employees with the highest level of access can view data in a customer’s vault.
At the infrastructure and systems level, we invest in multi-layered security so that no single point of failure can compromise our systems, and we work to prevent, detect, and respond to any potential security threat:
- Prevent: We use strong authentication, access control, encryption, and fault isolation to protect vaults and the data that they contain. Stringent multifactor authentication (MFA) is also an important aspect of our prevention strategy. To restrict access control, we also use the principle of least privilege — that everyone only has the permissions that they need to do their job. This means that almost no one has full permissions. It also means that only selected applications have access to sensitive data. We also use a privilege management technique called “separation of duty” where account administration and data administration are two separate roles by default. At the infrastructure level, each vault has its own dedicated database, storage, and encryption keys. Additionally, vaults, networks, and resources are isolated from each other to contain the impact of any failures.
- Detect: To detect security threats and incidents, we employ a range of monitoring tools, including tools that provide real-time alerting. And we not only use audit logs, we back them up to locations that aren’t accessible to malicious actors so that we can detect if they try to cover their traces by editing the source audit logs. With this robust approach to monitoring and auditing, we’re able to do end-to-end tracing of potential security incidents when we become aware of them.
- Respond: In the event of a security incident that does impact Skyflow, we have plans in place to work quickly to isolate the impact, and minimize damage. Doing this well means having effective forensics tools to pinpoint incidents and correlate what might seem like unrelated events. It means using our alerting systems so we can monitor the effectiveness of our response in real-time. It means that we’re quick to lock, quarantine, or terminate sessions and service accounts associated with any suspicious activity. And finally, it means that we’re prepared to suspend specific services as-needed until we’ve completed our response.
At Skyflow, we continuously reflect on what we could do in the case of future security incidents to prevent and remediate those. Many of the practices that we have in place are ones that any company can implement to protect itself from threats posed by malicious actors.
Service Security Tips and Best Practices
Of course, we take security very seriously at Skyflow, so the data and parts of your infrastructure that you entrust to us are in very good hands. Among the many security practices we follow, key examples are listed below (and we recommend that you ensure all of these are applied across everything you build or use):
- Avoid single points of failure. When building your infrastructure, create a resilient system that does not have a single point of failure, even a trusted service. For example, you can avoid a single point of failure with a trusted authentication service by using additional factors like network IP, time of day, geolocation, etc. so your multifactor authentication provides a strong assurance of identity.
- Implement the principle of least privilege across roles and accounts. As described above, you use access control to give each person only the access they need, and use service accounts whenever possible so that you can terminate sessions and cancel accounts as part of your threat response — with minimal impact to your organization.
- Audit, periodically and heavily. Auditing starts with getting a good sense of the baseline behavior and configuration of your systems. Using audit logs, you can establish this baseline so that you know what resources and network configurations are normal for your infrastructure. With this baseline established, it becomes easier to detect suspicious activity. One way to make audits more effective is to have your baseline be as precise as possible, including all available details, so that you can better detect even the most subtle anomaly. And, it makes sense to protect this baseline by separating audit log servers from production servers and periodically copying audit logs to a secure server not used for any other purposes. This prevents malicious actors from deleting an audit trail.
- Configure active monitoring — and monitor it actively. It should go without saying that setting up active monitoring, including real-time alerts, is only part of the solution when monitoring for threats. You also need to have security personnel whose top priority is to investigate any signals from that active monitoring system. Monitoring is only meaningful if the signals it generates are appropriately monitored.
- Investigate, even when an impact seems “impossible”. We have a simple rule that guides our approach to investigations: If we use it, and there’s a hack, we investigate. Skyflow investigates security incidents related to any technology that we use, even in cases where the nature of the incident as we understand it means that there should be no impact to Skyflow. In the case of the Okta security incident, for example, we conducted a thorough investigation to look for potential activities from Okta support accounts, even though those accounts had access disabled. We also worked with Okta to analyze the incident for potential impact on Skyflow. And despite finding no evidence of impact to Skyflow, we continue to monitor this incident.
This might seem like a lot of effort to set up, but it’s very much worthwhile when you consider the existential threat that malicious actors pose to your company.
Conclusion
As part of our standard security practice, we recently notified customers of our investigation of the Okta security incident to inform customers and reassure them that Skyflow was not impacted. We also want to reassure customers that we are doing everything possible to prevent and detect any future security incidents that could impact Skyflow, and have plans in place to respond quickly and effectively if those should occur.
We wrote this post out of a desire to expand on what we communicated to Skyflow customers, and also because we think that sharing the best ways to protect your services and infrastructure is useful to all companies as we work to protect our customers and their data.