My team just finished creating a whitepaper on How to build a Cloud Center of Excellence. We were sitting back and contemplating follow-on papers representing deeper dives into each of the topics therein. In our review of the Shadow IT discovery documentation, we threw about funny titles like:
“How to Have a Frank Talk with Marketing about Their Cloud Services Stack”
And other conversation starters for CASB Admins such as,
“Do We Really Need Five Document Sharing Services?”
But after the laughter, I sobered up and looked at what people really don’t have much of a handle on, which is how to use a CASB solution to do Investigation and Incident Response. I come from over a decade of Security Operations Center work, both as an analyst and as senior management. I’m sadly aware that there are few truly gifted SIEM engineers in the world that can write really good Events of Interest across multiple disciplines – most of them are in development, not support or ops.
That doesn’t mean that it doesn’t need doing. But until we get the SIEM discipline to include topics like AppSec and CASB in addition to the standard Network and (in a dream) Vulnerability Management traditions, we need to talk about how to use the data found in CloudSOC CASB.
Data by itself is boring – you have to make it sing out when it’s interesting. Here’s the beginning of some thoughts on how to make your CloudSOC CASB data in Detect sing like a bird.
First step: I’m not making any assumptions about who an organization’s CASB Admin is – what their role, background, experience, etc. It’s likely in many cases that the CASB Administrator and representative on the CCoE is someone with experience in Security (likely Network) and/or Network Operations/IT.
It is equally likely, once one gets out of high tech that the CASB Administrator is going to be an Audit/Compliance specialist or even the Department Secretary who has the spark and drive for learning new systems and reading manuals. (This happened in South Dakota – I’m a witness. Anyone who likes learning about Security can become a Security Analyst, regardless of background and education.)
Therefore I must assume no security knowledge, so here’s some background for the CASB Admin on Network Security.
Intrusion Detection/Prevention Systems (IDS/IPS) and Firewalls (Old School or Next Gen) both work by recording the IP that is the source of an attack as well as the destination. These systems look at Port, Protocols, and (for some) packet/payload. They are fantastic for seeing outside surveillance and attacks against your system, perimeter, etc. The challenge: You can never quickly identify “Who” in a scenario if the source is interior. Or rather, you can, but it’s exceptionally difficult.
Example: Say I’m a disgruntled employee who is downloading all the source code before going to work for a competitor. Because I am legitimately logged in and my sessions are legit, my activity is likely not going to show up on an IDS/IPS as an Event of Interest. Or if it does, it’s going to offer up my IP address. You can map an IP address to a MAC address and then ask IT who is assigned the laptop/computer with that MAC address. If you’re stunningly lucky they might know, but for most organizations that’s going to be pure black magic.
But you, you lucky CASB Administrator, have CloudSOC Detect as a source of truth for What’s Going On in your network. Here’s your first three ideas for getting started on managing incidents and finding out what’s going on. For these illustrations, I’m using scenarios created by my Sales Engineering team, who have done Bad Things to make them easy for you to see.
Dave Coder is a Developer on my team that is looking to find another job. How do I come to suspect this? Here are my warning flags. Dave Coder has a high ThreatScore in Detect. This score is calculated by his behavior online with different events that contribute to high-risk behavior.
I want to see what activities led to this score, so I open up his threat tree:
I see that Dave has policy violations, virus violations, excessive data uploads, excessive data downloads. My first instinct is that this guy may be giving his “Three weeks’ notice” and violating ethics by downloading company IP and uploading them to personal accounts.
As a CASB administrator, I should talk to the owner of my organization’s SalesForce application/instance during our CCoE and ask what Coder Dave’s role is as a user. There are, after all, perfectly legitimate uses of SalesForce which involve large data uploads, including anything PowerPoint or video, or other resource-heavy files. I care if he’s been downloading customer lists and reports outside of the normal time frame for quarterly reports, etc., but what does normal look like for someone on his team?
Let’s look at his activities on SalesForce compared to his team. As you’ll see below, Dave looks reasonably normal in the context of everyone else's activity in his group. Maybe he’s not planning on leaving us.
But do I jump to conclusions that all is well with Dave? No, there’s still some issues and flags that led to a high score. Let’s look at precisely what happened with this credential, sorted by timestamp.
I can see that on April 18, Coder Dave experienced a Brute Force Login attack on his SalesForce credentials. (For those pondering this at home, your average Network device may not be able to see this event as it happened in the cloud at SalesForce.com.) Immediately after that, CloudSOC CASB started to see SalesForce login issues, virus violations, and policy violations. This gives me some data to check with my Network Security team to look at problems.
With specific timestamps and events, they can investigate via Symantec Endpoint Protection administrator to check for infection, or IDS/Firewall logs for network activity to see if there is any corresponding network event with the same timestamp that represents an external attack. But if Dave was working from a coffee shop there may be no other records showing us what happened.
Better safe than sorry: I’m going to suggest that Dave’s manager send him down to IT to take a look at his laptop and see if it’s got a trojan or other virus still on his system. Dave should change his passwords, too, and if the organization has Multi-Factor Authentication in place, I could make a policy for this ThreatScore level or post brute-force attack that forces a secondary authentication to keep out credential thieves.
How fun was that?