Over a year ago we first published our series on Tidal Forces: The Trends Tearing Apart Security As We Know It. We called out three megatrends in technology with deep and lasting impact on security practice:
- Endpoints are different, often more secure, and frequently less open. If we look at the hardening of operating systems, exemplified by the less-open-but-more-secure model of Apple’s iOS, the cost of exploiting endpoints is trending much higher. At least it was before Meltdown and Spectre, but fortunately those are (admittedly major) blips, not a permanent direction.
- Software as a Service (SaaS) is the new back office. Organizations continue to push more and more of their supporting applications into SaaS – especially capabilities such as document management, CRM, and ERP which 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 of most new applications, and a large number of organizations are shifting existing application stacks to IaaS – even when it doesn’t 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 as we get closer – until we are ripped apart because some parts of the organization move more quickly while others are left behind, but teams like infrastructure and security are must attempt to support both ends of the spectrum simultaneously.
Since publication, nothing has dissuaded us from believing these trends will only continue to accelerate and increase internal pressures.
This migration of the back office into an ever-growing menagerie of remote services has many practical security implications. It’s more than just losing physical control – different services have different capabilities, and they all demand new security management models, tools, and techniques. The more you try to 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, but we need to translate them before we can provide security in the new environment.
This short paper will highlight some of the top ways security operations are being affected, then offer recommendations for managing 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 any more. But the shift doesn’t absolve you of overall security accountability. The transition creates both advantages and challenges, with a wide range of variability depending on how you manage it.
The biggest challenge with Software as a Service is the sheer range of capabilities across even similar-seeming providers. Some top-notch SaaS providers understand that major security incidents are existential threats to their business, so they invest heavily in security capabilities and features. Other companies are fast-moving startups which care more about customer acquisition than customer safety – but eventually they will learn, painfully. Aside from their inherent security, these services are all effectively remote applications, each with its own internal security models and capabilities which need to be managed. Risk assessment and platform knowledge are high priorities for security teams managing SaaS.
It doesn’t help that these platforms are all inherently Internet accessible. Which mean your data can be too, if you fail to configure them properly. Nearly all the services default to secure options, but the news is filled with examples of… exceptions.
Existing tools and techniques rarely apply directly or cleanly to the cloud. You don’t manage a firewall – instead you need to federate for identity management – and just about every traditional monitoring tool breaks. For example consider log management for monitoring and incident response. You generally only have access to the logs provided by your cloud platform, if any, and they are most likely in a custom format and are only accessible via API calls within the cloud provider’s user interface, or as data dumps.
Planning on just sniffing ‘your’ traffic? Aside from having almost no context for it, ongoing adoption of TLS 1.3 forces you to drop to less secure encryption options (if they are even available) to capture traffic. Or you can engage in a man-in-the-middle attack against your own users, reducing security to improve monitoring.
Last, and for some of you most important, is compliance. You are fully reliant on your SaaS provider’s compliance, and then need to ensure you configure and use everything correctly. With IaaS we can get around some of these restrictions, but with SaaS that usually isn’t an option. When a provider offers baseline compliance with a regulation or standard we call that compliance inheritance, but that only means their baseline is compliant – if you decide to make all your PII records publicly shareable… good luck with the auditors.
Every new technology comes with tradeoffs. In the end our job as security practitioners is to decide whether any decision produces a net improvement or loss in risk, and how to best mitigate that risk to the level our organization desires. The cloud comes with tremendous potential security benefits – particularly outsourcing our applications and data to providers with far stronger incentive to keep it secure – but we need to select the right provider, determine the right configuration, and use the right security processes and tools to manage it all.
Comments