Posted under: Research and Analysis
Over a year ago we first published our series on Tidal Forces: The Trends Tearing Apart Security As We Know It where we identified three key mega-trends in technology with deep, lasting impact on the practice of security:
- Endpoints are different, often more secure, and frequently less open. If we look at the hardening of operating systems, especially exemplified by the less-open-but-more-secure model of Apple’s iOS, the cost of exploiting endpoints is trending towards being much higher. At least it was before Meltdown and Spectre, but fortunately those are (big) blips, not a permanent destination.
- Software as a Service (SaaS) is the new back office. Organizations continue to push more and more of their supporting applications into SaaS, especially things like document management, CRM, and ERP that aren’t core to their mission.
- Infrastructure as a Service (IaaS) is the new data center. The growth of public IaaS has exceeded even our aggressive expectations. It’s the home for most new applications being developed, and a large number of organizations are shifting existing application stacks to IaaS even when it doesn’t necessarily make sense.
The fundamental precept of the “Tidal Forces” concept is that these trends act like gravity wells. We are all pulled inexorably towards them, at a rate that increases the closer we get, until we are internally ripped apart as some parts of the organization move more quickly, others are left behind, and teams like infrastructure and security are forced to support both ends of the spectrum.
Since publication nothing has dissuaded us from believing these trends will only continue to accelerate and increase internal pressures.
There are practical security implications of this migration of the back office into an ever-growing menagerie of remote services. It’s more than losing physical control; different services have different capabilities and all demand new security management models, tools, and techniques. The more you try and force the lessons of the past into the future, the more painful the transition. It isn’t that we throw all our knowledge and skills away, it’s that we need to translate them to apply security to the new environments.
This short paper will highlight some of the top ways security operations are affected, then highlight recommendations to manage the problem over time.
How the SaaS transition impacts security
Moving your most sensitive data to an outside provider quickly shatters the illusion that physical control matters anymore. But such a shift also doesn’t abrogate you of overall security accountability. Depending on how you manage the transition you create both advantages and challenges.
The biggest challenge with Software as a Service is the sheer range of capabilities across even similar-looking providers. There are some top-notch SaaS providers that recognize major security incidents are potentially existential events for their business, and thus invest heavily in both security capabilities and features. Other companies are fast-moving startups that care more about customer acquisition than customer safety (they’ll learn, painfully). Aside from inherent security, these are effectively remote applications and each has their own internal security models and capabilities that need to be managed. Risk assessment and platform knowledge become high priorities for security teams managing SaaS.
It also doesn’t help that, by nature, these platforms are all Internet accessible. Meaning so is your data, potentially, if you fail to configure them properly. Nearly all of the services default to secure options, but the news is filled with examples of… exceptions.
Existing tools and techniques rarely apply directly to cloud. You don’t manage a firewall, you need to use federation for identity management, and pretty much every traditional monitoring tool breaks. Take, for example, log management for monitoring and incident response. You generally only have access to the logs the cloud platform provides, if they offer them at all, and they are most likely in a custom format and are only accessible as API calls, within the cloud provider’s user interface, or as data dumps.
Planning on just sniffing the traffic? Aside from that providing you nearly no context, ongoing adoption of TLS 1.3 forces you to drop to less secure encryption options (if they are even supported) to capture the traffic. Or you engage in a man-in-the-middle attack against your own users and reduce security to improve monitoring.
Lastly, and for some of you most importantly, is compliance. You are fully reliant on the SaaS provider’s compliance, and then need to ensure you configure and use everything correctly. With IaaS we can sometimes get around some of these restrictions, but with SaaS that usually isn’t an option. When a provider has baseline compliance with a regulation or standard we call it compliance inheritance, but that only means they provide a compliant baseline, and if you decide to make all your PII records publicly shareable… good luck with the auditors.
Every new technology comes with tradeoffs. And, in the end, our job as security is to decide if we have a net gain or loss in risk, and how to best mitigate that risk to the level our organization desires. Cloud comes with tremendous potential security benefits; outsourcing our applications and data to a set of providers with far more incentive to keep it secure than we have, but this is only true if we select the right provider, and use the right configure, and the right security processes and tools to manage it.
This is a Security Bloggers Network syndicated blog post authored by email@example.com (Securosis). Read the original post at: Securosis Blog