It’s all about patterns.
Long before cybersecurity was on anyone’s radar, defensive intelligence – like catching an enemy spy in your ranks – was about being able to recognize patterns and interpret their meaning correctly.
Security’s reliance on pattern recognition and interpretation is no less true in the age of cyber.
And nowhere is it more true than in the world of SaaS.
In SaaS, you are what you do.
In the SaaS environment, identity is a matter of access credentials.
Anyone who enters your organization’s Vice President of Sales’ access credentials IS the VP Sales. They will be treated as the VP Sales, given the privileges of the VP Sales, and all their actions will be attributed to the VP Sales.
When this VP Sales uses a corporate SaaS app to send you a message with a request or instructions, you can’t really know whether the flesh-and-blood entity sending the message is actually the VP Sales. It could just as easily be the VP Sales’ teenage daughter, a disgruntled employee who’s planning to leave the company and take your best prospects with them, or worst case, a threat actor who’s managed to get their hands on your VP Sales’ access credentials.
Fortunately, you should have all the information you need to reveal the truth about identities and their intentions right there in your SaaS systems, as long as you know how to interpret them.
So where do you find this critical information?
In SaaS data access patterns.
SaaS application audit logs should collect information about all SaaS identities’ interactions with the application and assets therein. After normalization and enrichment, they can be imported into a security tool for cross-application comparisons and analysis. The goal is to find patterns and anomalies that may indicate threats, then confirm, dismiss or address any risk.
The following represent several problematic patterns that might be brought to light by a given user’s data access information. We’ll identify elements of the data access pattern, note the possible conclusions and touch on potential remediations.
Profile 1: The “That’s a problem?” user
One of your biggest SaaS security risks is end users who don’t know enough about SaaS security risks. They’re not trying to cause a data security problem; they just ARE.
What is the data access pattern you’re likely to see among this end user group?
- Excessive sharing (e.g. sharing organization-wide and/or sharing publicly when there is no apparent need for it)
- Logins and logouts from locations that fit other internal users (i.e. indicating sharing of access credentials)
- Updating shared assets with sensitive information (e.g. credit card numbers, AWS keys, other secrets)
- Sharing sensitive assets externally
While many organizations have security education programs, these passive, one-time events often aren’t enough to change participants’ awareness and actions.
In addition to removing shares or data, the long-term mitigation for this problematic user pattern is education in real time, as a risky action is performed. Using this approach, a user attempting to share a sensitive SaaS asset with a personal email address, or to post an encryption key to a Slack channel, would receive a message informing them of and explaining the issue, and requesting them to remediate.
Profile 2: The “Oh, come on – nothing’s going to happen” user
In contrast to the first problematic user described above, there are users who are very well aware of what is considered risky from a SaaS security perspective – and yet they choose to ignore that knowledge and take the risky action anyway. This user’s actions are often driven by convenience, perceived invulnerability or a calculated risk assessment that undervalues the importance of security measures.
Just looking at data access patterns, it’s hard to tell the difference between the user who isn’t aware of SaaS security practices and the one who is aware but careless. Fortunately, mitigation is basically the same – undoing their problematic action and sending a real-time security education message – although the purpose of the message is different:
- In the case of the ignorant user, the message makes the user aware of the security principle.
- In the case of the negligent user, the message makes the user aware that their actions are being monitored for compliance with the safety principle.
Profile 3: The “Let’s take advantage” user
So far, we’ve dealt with users who may be causing you risk, but they don’t actually intend to harm your organization. Now we’re going to move on to your classic malicious threat actor: the one who is out to leverage their data access for personal gain.
Data access patterns you are likely to see among this end user group include copying and/or exporting unusually large numbers of data assets, especially sensitive data assets. Searches for sensitive data types and sharing sensitive assets with private email accounts are also common indicators.
It’s important to combine these data access patterns with business contextual information, such as the user’s HR status or approved involvement with external parties (e.g. M&A teams). This business context reduces the risk of false positives or negatives.
In any of these “let’s take advantage” user cases, the actual actor may be the real owner of the user identity in question, or they may be an external threat actor who has gotten the identity’s access credentials, for example, through social engineering tactics. Business contextual information (as in the case of the departing executive) or SaaS app access information (e.g. password changes or resets) can sometimes give hints as to which one it is. In order to be sure, however, you’ll probably have to take the investigation outside of your SaaS ecosystem.
Profile 4: The “They’ll be sorry” user
Revenge. Retaliation. ‘Righting’ a ‘wrong.’
Users acting out grievances are less common than the other user risk threat types. Which is a good thing, because harm to your organization is not just a byproduct of their risky actions – it’s their goal.
Data access patterns you are likely to see among this end user group include deleting data assets or modifying them in a manner unexpected for that user. They may also export unusually large numbers of data assets and share sensitive data publicly.
Like the “Let’s take advantage” user, business contextual information is also helpful for determining the vengeful user. The following HR data can serve as a red flag to identify users who might be harboring a grievance:
- Low performance reviews
- Termination
When it comes to mitigation, it’s critical to detect and react to this user’s actions rapidly, before they can carry out their intentions. Relevant mitigation actions include holding the implementation of their attempted changes (e.g. asset deletion or modification) until further investigation, revoking their access to sensitive assets or suspending their user account. The InfoSec and HR teams should be alerted as well.
From users who are blissfully ignorant of SaaS security to users who are bent on breaking through your SaaS security – each has a distinctive footprint when it comes to their SaaS data access patterns.
The tools exist to collect data access information, analyze it and pick out those footprints. Use them wisely. Identify the patterns. Respond accordingly. You’ll strengthen your SaaS security posture a hundredfold.
About the Author
Adam Gavish, Co-Founder & CEO, DoControl. Adam is a Cybersecurity Entrepreneur and Product Executive with 20 years of experience. Former member of the Google Cloud Security team. Leading a CrowdStrike portfolio company.
Adam can be reached online at https://www.linkedin.com/in/adamgavish/ and at our company website https://www.docontrol.io/.
