Contents:
Cloud Access Security Broker (CASB) is a Gartner-coined cloud-based security-centric profile that proposes an intermediary between cloud service consumers and providers. This intermediary assumes the form of a cloud-native security enforcement point that permits system administrators to better manage cloud-hosted resources. CASB offers a wide range of cloud curation services from visibility to data control, threat analytics, risk assessment, and threat prevention. In this article, we are going to discuss the emergent Cloud Access Security Broker trend, determine its place in the cloud security constellation, and how to deploy such a tool. Enjoy!
Gartner defines CASB as :
(…) on-premises, or cloud-based security policy enforcement points, placed between cloud service consumers and cloud service providers to combine and interject enterprise security policies as the cloud-based resources are accessed. CASBs consolidate multiple types of security policy enforcement. Example security policies include authentication, single sign-on, authorization, credential mapping, device profiling, encryption, tokenization, logging, alerting, malware detection/prevention, and so on.
Based on Gartner’s view on CASB service, we can infer the following facts:
- CASB’s architecture can accommodate both on-prem and cloud-based models. The role of on-prem CASB is to provide an integrated (workflow) experience to your users while maintaining security in key areas such as data warehouses. A great example of on-prem CASB is MCAS’s (e.g., Microsoft Cloud App Security) blending with Azure AD Application Proxy. This integration allows users to access on-prem-hosted resources remotely by using methods such as SSO (i.e., Single Sign-On), secure remote access, conditional access application control, and more. Evidently, the cloud-based CASB model eliminates the need for on-prem brokerage, offering the IT admin better visibility over the assets, increased performance and speed, more security features, additional controls, and more.
- CASB acts as a middleman between end-users (i.e., cloud service consumers) and the cloud service providers. Employing this method adds additional security layers whilst providing the sysadmin with better visibility over the company’s digital assets. There’s a reason why “visibility” pops up so many times – one of CASB’s primary functions is to counter the so-called shadow IT trend. In simple terms, Shadow IT is when a user employs software or hardware without the informed consent of the IT department. So, for instance, if you’re actively using productivity tools like Slack, Trello, or Asana, without your IT’s department informed consent, it means that you’re doing Shadow IT. Why is this an issue? According to a G2 Shadow IT Management study, UK and US companies waste roughly $34 billion each year on licenses (i.e., this is called licensing waste). The very same study points out that 80% of employees will admit that, at some point, they’ve used tools without getting the approval of the IT Department. Last, but not least, 21% of the organizations that participated in G2’s study admitted to not having a clearly defined security policy around applications, for productivity purposes or otherwise.
To recap, Cloud Access Security Broker is an emerging technology that interjects a security policy enforcement point between the cloud consumer and the provider. CASB unlocks new workflow management and security features such as increased visibility over assets, ownership, secure access options, and more.
Up next, we’re going to go over the four pillars of CASB.
The Four Pillar of Cloud Access Security Broker
CASB is built on top of four layers: visibility, data security, threat protection, and compliance. Let’s discuss visibility in CASB.
Visibility
Previously, we’ve talked about how CASB’s take on visibility can decrease the Shadow IT effect. The Visibility pillar can help us answer two important questions: who is using the contracted cloud and what’s it being used for? Here’s a real-life example – say that your company’s cloud has a personal storage feature.
Common sense dictates that this space should be used to store work-related stuff like meeting notes, research papers, articles, performance reviews, screenshots, etc. Bear with me on this on; if there’s no policy in place that regulates the use of personal cloud storage, what would stop an employee from taking up that storage with personal, non-work-related stuff like music, games, or videos? Well, no one for that matter; if the IT department doesn’t have a consolidated policy ruleset on cloud usage, the user cannot be held accountable.
Yes, you’ve guessed it – shadow IT is back into the game. Now, CASB is no miracle remedy against (cloud) user behavior, but it does provide your IT admins with the tools they require to curb or eliminate this trend. Again, why visibility? Well, the very first a CASB service does after deployment is mapping out your cloud – this means it will tell you how many apps are currently running in the cloud, who has ownership over them, how often are they used, and by whom. This bird’s eye view will also provide you with an answer to the question “is my cloud environment currently hosting unsanctioned or potentially unsafe applications?”.
This may very well be the tipping point you were looking for in managing workflows, be them on-prem or remote. And on that note, CASB can also shed some light on what’s happening beyond the borders of your company’s premises. Since most companies have transitioned to a hybrid work model, better visibility is warranted. CASB is integrative by design; once deployed, the service will factor in both on-prem and remote workforce and show you how each category makes use of your company’s resources.
As mentioned, cloud-based asset management and inventory mediated by CASB is the first step to curbing and eliminating Shadow IT or even identifying threats that may have been invisible under traditional SAM (i.e., software asset management). Indeed, CASB may be a viable solution to Insider Threat(s). In a nutshell, the first layer of CASB will help you get a better look at what’s happening inside your cloud. The best analogy, in this case, would be the CASB is the wide-angled lens you’ve been looking for.
Up next, we’re going to talk about the second CASB layer which is data security.
Data Security
When we envision the concept of data security, the first term that pops to mind is – and has to be – Data Loss Prevention (DLP). I won’t go into many details since the topic has been extensively covered in our blog. So, if you’re interested in learning more about what is DLP and how it works, I encourage you to read What Is Data Loss Prevention and How You Can Approach DLP Security and A Technical Approach to Data Loss Prevention (DLP). Now, getting back to the topic at hand, CASB deployment will empower you to further substantiate your data loss plan, while providing additional protection for both data-at-rest and in-transit. There are various methods to reinforce data security, however, before that, the service must determine what type of data is being hosted on the system (i.e., data classification), who has access to that data (i.e., ownership and/or clearance), and, of course, ways to monitor the data, regardless of its classification.
While CASB’s visibility pillar will definitely offer you an edge in that direction, the data security pillar will supply you with the controls required to enforce security-related policies. In CASB, there are two types of approaches to data security controls: contextual access control and data leakage prevention. Context is king and access controls its fiefdom; in this type of approach, the user is granted access to sensitive data if one or more contextual variables are fulfilled. For instance, only users from a certain geographic area, with specific clearance/role assigned to a specific device, may be granted access to sensitive data. As for data leakage prevention, CASB unlocks controls that empower admins to make an educated decision about how the data is actually managed and shared. For instance, the system might be instructed to block materials containing client-related info if the owner decides to share it outside of the company.
With data security covered, let’s now move on to threat protection.
Threat Protection
Threat Protection in CASB is something unique. One would be inclined to believe that this pillar has the same constituency and functions as a malware protection service, but it’s more than that. CASB’s Threat Protection features controls and policies that protect your data from getting accessed by unauthorized devices, users, and applications. In other words, this pillar focuses on user and entity behavior. Some CASBs employ something called UEBA, which is short for User and Entity Behavior Analysis. Something worth mentioning here – although threat protection policies powered by UEBA or other types of threat analytics engines do not focus on malware, this doesn’t mean that the service will not light up as the proverbial Christmas tree if a threat is detected. With this in mind, let’s see what this pillar can do. Imagine the following scenario – your company is running a generic CRM; great tools and very useful if you have tons of customers.
CRM is typically used by salespeople. Now, each time an account is created, the user receives a username, a password, and a role. From now, user X will be able to log into the CRM, access as much data as permitted by his designated role by using his unique username-password combination so far. All good so far; but what happens if user X will use his credentials and role permissions in order to perform unauthorized actions (e.g., delete contacts, create a local copy of the CRM’s database, hide contact details or tamper with them)? Well, this is where CASB leaps into action; by employing a combination of UEBA and conditional access, the sysadmin can superimpose the following rule: under his assigned role, user X may only perform a limited number of actions and sub-actions if he uses his company-issued workstation, is inside business hours, and communicating over an encrypted channel. That’s Threat Protection in a nutshell.
With Threat Protection out of the way, let’s see about Compliance.
Compliance
Compliance is, as they say, a necessary evil. To grow your business, you need customers. And to get more customers or keep the ones you already have you need to build trust. So, to make a very long story short, compliance is how you prove your trustworthiness to your customers. Now, compliance is different for each industry. For instance, healthcare providers need HIPPA, HITECH, and False Claims Act, but don’t necessarily require PCI-DSS. Now, with CASB you can very easily establish your company’s compliance status in regards to data housing and management. Having complete visibility over your assets means that you can quickly gather audit-related data and, why not, apply for another compliance certificate.
CASB Deployment. Pros and Cons.
And we’ve finally arrived at the juicy part – implementing a Cloud Access Security Broker service. So, how do you do it? Well, according to the big book of CASB nuts and bolts, there are three ways to implement/deploy CASB – API Scanning, Forward Proxy, and Reverse Proxy. One thing to keep in mind: there’s no such thing as sticking to just one deployment model. A company looking to implement CASB can use one, two, or all of these methods. This approach is called multimode CASB.
Before we discuss deployment models, we must talk about the difference between in-line CASB and out-of-band CASB. So, when we defined CASB, we said that it sort of acted like an intermediary between cloud consumers and providers. Now, as far deployment’s concerned, the terms “in-line” and “out-of-band” refers to how traffic is rerouted. API Scanning, our first deployment method, is what we call an “out-of-band” since it’s not wedged between the cloud traffic between the consumer and the provider. On the other hand, forward and reverse proxy are in-line CASB because both methods rely on positioning something in the cloud traffic between consumer and provider. Hope this makes sense.
API Scanning
Anyway, API scanning is considered a non-intrusive CASB deployment model mostly because it does not come in between the user-provider cloud traffic. With API scanning you will be able to enforce granular data security policies, easily inspect the data stored in the cloud, and identify and remediate any type of DLP mishaps. Cons-wise, API Scanning cannot offer real-time prevention and only work on sanctioned apps.
Forward & Reverse Proxy
Let’s discuss in-line CASBs and we’ll kick it off with forward proxy(ing). In inline-CASBs, a proxy is placed between the client and the cloud provider. All traffic from the client’s machine is being forwarded to this proxy via SSL man-in-the-middle. The proxy will then transmit the data to the cloud provider. Now, the major difference between forward and reverse proxy is the, well, proximity of the proxy. In the first method, the proxy gets placed closer to the client, while in the second, the proxy stands next to the cloud provider.
There are three ways to route traffic when using the forward proxy model: proxy auto-configuration files, DNS URL redirects, or agents that route traffic through a (secure) VPN tunnel. Forward Proxy(ing) is great for discovering shadow IT, encrypting or tokenizing data transfers, enforcing contextual access controls, or for analyzing the data exchange taking place between the user and the cloud provider. Compared to API scanning, it works wonders on both sanctioned and unsanctioned apps. It also operates in real-time. Unfortunately, it only works with managed devices and it can’t do anything about data-at-rest.
In Reverse Proxy(ing) the proxy will be placed closer to the provider. This comes with all sorts of advantages. First, you don’t need an agent or anything else for that matter to route traffic. Second, it eliminates the security concerns related to SSL man-in-the-middle routing. In terms of features, the Reverse Proxy method allows you to encrypt data-in-transit, identify DLP violations and remediate them in real-time, identify and remediate compromised user accounts by monitoring the user’s behavioral patterns, and enforce security controls for both managed and unmanaged devices. In terms of cons, a reverse proxy cannot help you tackle shadow IT and doesn’t work on unsanctioned applications.
Conclusion
As far as visibility and DLP are concerned, Cloud Access Security Broker is the way forward. This type of technology can provide insight on PEDM or EDR tool. However, as with any emerging technology, the rate of adoption is pretty slow and it will take some time before it becomes an industry standard. Heimdal®’s take on CASB services is a combination of our flagship product Threat Prevention – Endpoint and Threat Prevention – Network, its perimeter-level counterpart. By leveraging advanced, cloud threat analytics, the duo provides the user with powerful UEBA features and unlocks more granular security controls.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.
