A couple of weeks ago I discussed the biggest causes of cloudphobia in the context of SaaS with Paavan Mistry, a fellow contributor to The New Stack. We both agreed there were important security considerations to be made in the context of SaaS adoption. My hope here is to dispel some popular misconceptions that often result in misinvestment, costing companies an edge over their competitors.
Encryption should always be the first priority when considering SaaS, according to popular opinion. But it’s this incorrect belief in encryption that Paavan often hears when IT talks about embracing SaaS apps. “If my data is in the cloud,” the thinking goes, “then it should be encrypted.”
These unfortunate hypochondriacs are misdiagnosing their ailment, a common error motivated by survivorship bias. They believe that, like in the case of physical disks, encryption stops the attackers from getting to protected data. That’s an incorrect assumption, akin to treating heartburn with aspirin, which is a really bad idea.
Measuring the health of your SaaS strategy in the context of what matters is a far better approach. That means utilizing mapping rather than intuition so you can use your security posture as an edge against your competitors and a boon to your corporate agility.
Thinking that encryption is important when using SaaS applications is correct, but if you see that padlock symbol next to the URL in the address bar, then your encryption is officially “good enough.”
Don’t fall prey to misconceptions about the difference between encryption for the purpose of security and encryption for the purpose of privacy. In the case of the latter, if you are a US-based company, you’re pretty much screwed. However, if your interest is in security, read on:
“Advanced” encryption tools are usually given more gravitas than they deserve. In many ways encryption is a handy “checkbox” mechanism that accomplishes the checking of a box, but not much more. The theory is that only authorized personnel and programs see decrypted information, while all others have no access to the data. Encrypting the data ostensibly creates a “clear” attestation trail, because if only users who are allowed to access the data can access the data, then it’s easy to attest for when data was touched and by whom.
However, attackers are shifting from exploits to credentials which is in turn becoming the number one attack methodology, according to the 2014 Verizon Data Breach Investigation Report. That means their attack vector is not the infrastructure or the application, but rather the end user.
Encryption controls are not designed to know if the user’s credentials have been compromised. They can’t tell the difference between the attacker with the user’s credentials and the actual user. From the vantage point of the encryption controls, the attacker and the user are the same entity – ergo, #fail.
Most enterprise SaaS providers encrypt data in transit. It flows between their data centers and user devices as well as at rest on their servers. Those who aren’t doing so are certainly moving in that direction, and can be persuaded to move faster by their customers (a good use of your time!).
Beyond vendor provided encryption, the focus in SaaS should be attestation, not encryption. What’s needed is a clear and actionable audit trail of all user activities in SaaS applications with direct correlation to which data (structured and unstructured) has been exchanged, shared or otherwise interacted with.
Moving on, the use of cloud applications by enterprise users with or without IT’s approval is a second concern Pavaan discussed. He said IT leaders are concerned that these applications are growing rapidly, easily purchased with a credit card over the Web.
I can’t fault anyone for wanting to have purview for what they can’t see. But it’s reminiscent of the “Dropbox problem,” that urban legend passed around CIO dinner tables. According to IT myth, it’s a horror story about a highly privileged file that gets downloaded from the corporate share and uploaded to the cloud where all the baddies can have at it.
In reality, the most strategic way to think about Shadow IT is in the context of a simple attack surface exercise which relies on drawing insights more from what you know than what you don’t. The real question should be: where is the critical mass of your enterprise data in the cloud? Should it be in your corporate managed SaaS applications (like Salesforce, Box, Google Apps, Jive, SuccessFactors, or Office 365) or in Shadow IT applications?
Focusing on Shadow IT is an exercise in managing fears that are largely unknown, perhaps quantified to some extent through tools like Palo Alto Networks’ Applipedia. But these fears are certainly not qualified, because we can assume these so-called Shadow IT apps are accessed by unmanaged devices over non-enterprise networks, thereby outside the purview of endpoint management controls like MDM/EMM and network controls like Firewalls.
What services we know people are using should be the real emphasis. Extending IT visibility and controls to these services makes it possible to manage the critical mass of enterprise data that is flowing in and out of corporate managed cloud services. That’s an approach that actually makes sense, removes the fear factor and far better represents the people and the trust so critical to a successful business.
If you take into account the man hours and dollars that have been poured into so-called advanced encryption controls and Shadow IT risk assessments without any measurable reduction to companies attack surface, imagine all the useful projects you could have otherwise accomplished with those same resources. If you’re just starting along the path to SaaS security, be logical about your ailments, and treat the symptoms that matter. If your concern is liability then invest in attestation, if your concern is exfiltration, invest in anomaly detection. Don’t “go with your gut” because SaaS adoption begets a new operational security model.
Feature image via Flickr Creative Commons
Tal Klein is vice president of marketing at Adallom, a sponsor of The New Stack.