Security operations · 5 MIN READ · MATT PETERS AND PETER SILBERMAN · JUN 20, 2019 · TAGS: CISO / Cloud security / How to / Managed security / Planning
You can’t set foot in any conference or read an article in your go-to tech trade without hearing about cloud. And we totally get the fandom. The cloud offers businesses of all shapes and sizes plenty of benefits, with the biggest one being that you can move faster to accomplish a business outcome. Cloud is the perfect example of a technology where you can pour money into it to achieve scale.
But how exactly do you “do security” in the cloud? Your IT team isn’t racking and stacking servers like they used to … and it’s much harder to see the endpoints you’re now responsible for protecting.
But please let us be the bearers of some good news: securing your data in the cloud is much easier to do than you think, as long as you’re thinking about the cloud in the right way.
The security challenges of cloud
With the cloud comes some fundamental shifts in how companies do business and how IT and security think about tech. Here are the ones you need to care about, because they impact how you need to protect your org’s data.
- Things move (a lot) faster. Sure, being able to go from nothing to a fully stood-up application in minutes is awesome, but it also puts a new burden on the security team (or your security “person” if you don’t have a full team). Specifically, traditional change control processes are easily outgunned, which means you don’t have those as an easy way to get visibility into the changes your developers are making since they may no longer need permissions to spin up new databases.
- You still have visibility in the cloud, but that view is different than what you’re used to. The types of visibility available in the cloud are not always the same — understanding what telemetry data is available from your cloud provider will help you find commensurate controls. For example, it may not be easy to get full Packet Capture (PCAP) but you can get flow logs from most cloud providers.
- You’ll probably have a new/different pivot point. When you think about infrastructure, you usually pivot based on hostname, IP and sometimes the user. But in looking at detection and response for cloud applications like Office 365 and G-Suite the logs usually only contain a username. In these cases, the user identity becomes the new thread to follow. (Speaking of Office 365, we’ve got an entire post right here about how to keep Office 365 secure.)
Our simplified 3-part take on cloud security
We think about ‘cloud’ in three distinct parts. Each part corresponds to a pattern we see that implies certain business goals, and brings with it specific complexities and advantages. By understanding which ‘cloud’ you’re talking about, you’ll have a much better handle on what controls you’ll be able to use effectively to protect your data.
Part 1: Infrastructure
Then …
In the old world, your infrastructure was contained in a data center. There were physical walls around it with man-traps and guards. The network was similarly segmented, with (usually) well-understood ingress and egress points. Only a few people had permissions to make changes to the physical or logical infrastructure. As a result, concentrating visibility and control in a change control board (CCB) that met infrequently and authorized changes was pretty easy (and effective).
Now …
In the new world your data center is, at best, a logical construction. Physical walls are replaced with VPC configuration and your cohort of sys admins with root passwords are now replaced by API access and keys. Given that a team can spin up an entirely new infrastructure overnight with no real controls, it might seem like all hope to regain control and have oversight is lost. But it’s not.
With the new world of configuration-driven infrastructure, you’ve got an opportunity to implement a new change control process. Your new process can rely on — gasp — automation to review configuration changes against your org’s best practices, conduct vulnerability scanning for new software and enforce security policies before changes are made. Now instead of periodically reviewing a spreadsheet to make sure your controls are still applicable and useful, you can now build controls right into your CI/CD pipeline.
This visual from The New Stack is a great representation of how you’re able to build these controls right into a product or service in the development process:
Part 2: Cloud apps
Then …
Back in the day you delivered software services the old-fashioned way — you ran those things yourselves! You had a cluster of Microsoft Exchange servers and an Oracle database running your CRM. You had on-call rotations and people who knew the way to the datacenter. Oh, and remember those Friday nights near the end of a quarter when you were frantically swapping out hard drives to get database clusters back online? Also, Limp Bizkit was a thing.
Back then, you had all the control in the world to monitor whatever and however you wanted. But the costs were high. You were buying drives, constantly training people, triaging networking failures, dealing with power outages … all that stuff was your problem. You were optimizing for the cost of running and maintaining critical software with specific controls — and those controls were really the people who could upgrade and access running servers. You probably also had controls that required employees to physically be in an office to get work done (yeah, I’m talkin’ about pre-VPN days).
Now …
Enter SaaS applications. And lots of them. Today, email’s delivered via Office 365 or G-Suite through servers you’ll never see. There’s no physical boundary you can monitor or control, no server to instrument. You’ve gotta rely on built-in application and audit logs to monitor these applications.
The good news is that (for the most part) these applications come with excellent application logging built right into them. For example, SalesForce has extensive audit logging built in as a button-click. On top of that, advances in data science have taken user-based anomaly detection from something you read about in academic papers to something that’s now built right into many platforms in SIEM products like Exabeam and Sumo Logic.
Sure, there’s a little bit of a learning curve here — you’ll have to spend some time understanding these new application logs and how to instrument them to monitor for unusual or malicious activity. Even though this new world requires some learning up front, there’s more value for you and your org in the long run, because you’re able to spend time focusing on the security of the application, not on keeping the lights on. Want more specific recommendations on how to get started with protecting your cloud apps? Then you need to read this post: “Three tips for getting started with cloud application security.”
Part 3: Custom apps
Then …
In the past, rolling out new apps was a long and painful process — developers spent time testing, sys admins were deploying and then there were bumps in the road. Developers then had to patch in production (“It’s the last time we’ll do this, I swear!”) and then finally the system worked.
Now …
With the cloud, app development and deployment happens much faster — if developers and the operations team work together to build an environment with the right balance between controls, processes, velocity and automation, that is.
Custom applications require that the security and operations team understand the application in order to secure it. If you don’t have a topological control-point like a fixed network egress this can feel daunting, but the same configuration-as-code that makes your developers more effective also let your security team understand the application and monitor changes. The focus in modern DevOps on solid application logging is a good thing because it means that security signals are already built into your custom app when it gets deployed. And most modern deployment pipelines take advantage of configuration checking, image scanning and compliance checking — and they’re usually (easy) click-to-enable type features.
As with infrastructure and SaaS, the promise of infrastructure-as-code and application logging requires a partnership with the development team, as well as some expertise in modern DevOps tool chains (we’re fans of several infrastructure-as-code tools such as Terraform and Ansible).
What now?
The cloud has plenty of benefits — when it comes to security, we just need to re-evaluate the contents of our bag of tricks. Some tried-and-true methods from our “rack and stack” days are no longer relevant. But if you approach cloud security from the three vantage points described above, you’ll be well on your way to building a solid security foundation.
Have more questions about cloud? Drop us a note. We’d love to chat.
