Are You Prepared For When Your *aaS's Environment Is Hacked?
Snowflake environments are being compromised left and right. Have you set yourself up for *aaS success, or is your company ready to be breached in a similar fashion?
LendingTree. Ticketmaster. Advance Auto Parts. Santander Bank. These are just some of the biggest names we're already aware of having been compromised through their Snowflake environments here in Q2, 2024. Multi-Factor Authentication (MFA) - or the lack thereof - is being scapegoated here, and may well be the issue. Clearly Snowflake offers MFA support, so why were so many companies not using it? Is there a technical issue with the implementation? Is it just too difficult to configure properly? Or did companies just overlook the capability?
At this point in our communal online journey, MFA should be considered not just best practice, but minimum viable practice for authentication that takes place on at publicly exposed entry points on the Internet, at least for corporate systems. Rather like three-point seat-belts in passenger vehicles, it should just be included and available for use. Indeed, Snowflake seems to offer this, so good for them. But is offering MFA enough? Does the provider have no further responsibility beyond making security tools available?
One could certainly argue in the case of Snowflake that when more than 150 customers have had to be notified of a data breach that perhaps there is a bit more they could have been doing. Lawyers, judges, and juries may tell us more about that at some time in the future, let's proceed with the expectation that you are ultimately responsible for the security of your *aaS (<anything> as a Service) environments, though you want to be sure to choose a responsible partner in that endeavor. Here are a handful of cybersecurity related topics I'd suggest responsible business partners would want to ask of each other before they enter in to an *aaS arrangement.
Access Controls and Restrictions
As an enterprise, the first think I'd like to do with y *aaS provider is to connect to them via my single sign-on (SSO) solution, where I already control MFA and other features. But in doing so, I'd also like the ability to flat out deny any other access (well, perhaps with a few exceptions, like APIs, but let's not go too far down that rabbit hole today). I'd also be very interested in API security - how are these locked down to prevent spoofing or unauthorized access.
If I'm not an enterprise with SSO, I'd want to explore the other authentication restrictions. For example, can I force MFA for all accounts accessing my instance, or is it up to each account to decide for themselves if they want MFA? What are my options for geo-fencing logins since my employees only work from the US, for example? Can I set password complexity, length, and reset requirements? What does the password reset process look like and how do I control that for my users? Given the breadth of this Snowflake customer breach I'd hazard a guess that many companies took these settings for granted and didn't investigate fully enough, or never got around to deploying any countermeasures to protect themselves from these gaps.
Logging and Monitoring
"Remember kids, the only difference between screwing around and science is writing it down." - Adam Savage
What is true for Mythbusters is true for cybersecurity as well, if there's no log of what happened you don't know what happened. How is your *aaS partner providing you with visibility into what is happening in your environment? Are you able to ingest and make sense of those logs? Do they tell you critical things like when someone transfers large volumes of data out of the environment? Do they raise a flag when a pattern of failed login activity occurs? Are they just sending you "raw" logs, or are they interpreting those raw events and sending you validated, enriched "meta-logs" indicating a concern? Are they monitoring for patterns across their customer base and alerting you to those? If the answer to these is "we'll send you an email," well, that's better than nothing, but you're going to probably need a lot more than that.
Lest you think I'm making a big deal about something that can be assumed, it wasn't that long ago that Microsoft was charging more for access to your Cloud Exchange related security logs, a change they made only after some significant breaches. There are undoubtedly others who feel they should charge more for security, keep an eye out for bad assumptions around these topics.
Incident Support
So when a bad day happens - when your *aaS environment gets compromised - how is your *aaS supplier going to help? Some "simple" items like forcing password resets if there's indications of a mass of compromised credentials available on the "dark web," or temporarily blocking access from known malicious systems are a few good starts. Do they have documented processes for interfacing with your response team or DFIR provider? Do they have their own response team that you have access to?
Other Data Exposures
As people are becoming more aware in their personal lives, many *aaS solutions include agreements that allow the service providers to use their customers data for their own purposes as well. Whether that is to train AI, or just to run meta-data related analysis to ensure proper performance, your data is in their hands. Knowing how your *aaS provider is protecting that data outside of your specific environment is worth spending some time on.
As with all cybersecurity situations, there is no one "right answer" for everyone and every situation. Cybersecurity isn't free, and there are many *aaS suppliers who charge more for security features that perhaps shouldn't be. Your risk appetite should guide your decision, this blog just points out a few of the details to consider as you're making that evaluation.