If you’ve been feeling like your SaaS security knowledge is a bit cloudy (heh!), then you’ve come to the right place.
These 3 questions come up often:
- Who’s really responsible for protecting what?
- How do I actually get started? Where should I start?
- What types of things should I be looking for, and where? And how?
Here’s our two cents.
First things first: Who’s responsible for protecting what?
This is the million-dollar question: When you move to the cloud, who’s responsible for protecting what?
When it comes to security, you’ve got to think about your cloud infrastructure (the systems and workloads you’re running in AWS, Microsoft Azure or Google) and your cloud applications (Office 365, Salesforce, Workday, etc.) as two separate things because each of them comes with different types of security risks and requires different investigation techniques. By the way, we’ve got an entire post filled with Office 365 security best practices for you, which is right here.
And while, in the case of SaaS applications, the security of the infrastructure is the responsibility of your cloud service provider, the security of your data that lives in your cloud applications and the user accounts allowed to access those applications are your responsibility.
Sure, you’re probably using all of those convenient SaaS applications so you don’t have to maintain the physical hardware and networks they run on, but it’s still your data, so it’s your responsibility to know who’s accessing it and whether that access is authorized. #jobsecurity
Monitoring SaaS applications is a different ballgame because you’re not looking for malware on a laptop anymore. Devices are no longer your endpoints–your users are. Monitoring a SaaS environment is about understanding user behavior and that starts with understanding the signals your SaaS provider is sending you and verifying that they’re properly configured.
What are the must-dos when it comes to protecting SaaS applications?
We could answer this question with an entire scroll of to-dos (this is one of our favorite topics, ya know), but 3 seems like a manageable number. So, here are the 3 most important things you can do if you’re just getting started with cloud application security.
- Identify all of your cloud applications. Sounds simple, but trust us—it’s not. There are probably at least a couple (dozen?) SaaS apps running in your environment that you don’t know about. Time to take inventory.
There are a bunch of ways to get started. For example, if you’ve got one of the firewalls or intrusion detection system (IDS) products that inspects traffic, it can give you a report of the cloud applications people are using in your environment. You can also use a cloud access security broker (CASB) to shine a light on the applications being used, and begin to enforce some policies about their use. After you’ve got that list you can use it to audit the different contracts and services that each department has subscribed to within your org.
- Gather the log data from these applications. After you gather the log data from each app, store it in a place where it’s easy to search, so you can write detections based on certain conditions. What should you be looking for, exactly? Watch for common signs of compromise, like logins coming from a VPN provider, a burst of document sharing activity or application-specific signs of misuse and compromise like an email rule that’s created to forward emails to an inbox outside the corporate domain (just to name a few).
- Focus on the users. Say it with me: “Users are the new endpoints.” Here at Expel, our cloud application detections fall into about 5 classes of detections, all of which–you guessed it–examine user behavior. Each class has specific detections for a given application, like authentication, email management, and resource management.
What are some common detections that would require us to alert a customer and perform further investigation, you ask? One example is finding a user who is authenticating from a VPN service provider. This isn’t necessarily a smoking gun, but it’s uncommon enough that we’d want to look more deeply into that user’s activity to see if anything else they’re doing looks fishy.
Another example is a user configuring an inbox rule that auto-forwards all their corporate email to a Yahoo account (or really any external email). Another anomaly we detect is when a user anonymously shares a lot of documents in a short period of time. We alert our customers about user behaviors that present potential risks to their data, and then partner with their security teams to investigate and respond to those threats.
Putting it into practice
We’ve already seen success with our customers in helping them better understand what’s happening with their data in some of these cloud applications. We’ve been able to create detections that are specific to their applications (and even their users)–all of which give us and our customers better signals that help us understand quickly and accurately if there’s a security risk.