Often the purposes or differences between a Cloud Access Security Broker (CASB) like Microsoft's Cloud App Security (MCAS) product and a Security Information & Event Management (SIEM) product like Microsoft's Azure Sentinel can be misunderstood. In this two part blog series, both products will be discussed in terms of their differences and importance for CMMC compliance and an ideal cloud security strategy.
MCAS is a Cloud Access Security Broker (CASB) and provides the following capabilities.
- Discovery of Shadow IT and unapproved applications in your environment, along with governance of discovered apps
- Near-real time and real time traffic analysis and shaping capabilities*
- Security, governance, and analysis of other cloud providers (Azure, AWS, Office 365, Box, etc)
- Real time monitoring in/out of Azure and Office 365 GCC High AND near real-time monitoring of 3rd party cloud providers
- Control on Upload/Download/Access & Sessions in real-time
- Real-time governance (suspend accounts, change file permissions, auto-label document via AIP and a lot more)
- “Auto-governance” and alerting: Very granular down to IP, URL, Port, User, Location, Public/Internal, Application, Device type
- Anomaly Detection (logs in from two countries at the same time, User Behavior Analysis (UBA)
- Threat protection from malware, ransomware, ticket/token spoofing, etc
- Log ingesting from sources such as Proxy Servers and Firewalls
In 2017, Gartner proposed that 60% of enterprises would adopt a CASB product to manage the ever growing and disparate cloud estate. The numbers are much greater in 2020. Many businesses are choosing MCAS to protect CUI via two main variables: CONDITIONS and CONTROLS. The below graphic demonstrates the breadth of monitoring MCAS conducts across a DoD contractor's array of applications, user types, devices, and networks.
MCAS is an active tool looking at user activity across managed (sanctioned or enrolled) and unmanaged (unsanctioned) applications in your cloud estate/network, applying machine learning to identify if an activity meets certain CONDITIONS, and takes action via alerting or CONTROLS. This table provides examples of CONDITIONS and CONTROLS.
|User Type/Role||Allow or block access|
|Trusted or Non-Trusted Device||Limit access|
|Physical and/or Virtual Location||Force MFA or additional authentication|
|Enrolled or Non-Enrolled Application||Force password reset|
|Authentication Method||Block legacy authentication|
There are many tools within the Microsoft Enterprise Mobility + Security suite that can meet CMMC requirements; however, MCAS more effectively deploys and extends these products. For example, MCAS couples with Azure Information Protection (AIP) to control, label, and protect CUI data and documents. Ben Curry at the recent CS2 event discusses this further.
Here are a few more examples of MCAS extending security within the CMMC framework.
AC.3.018 Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
This control is readily met with Azure Active Directory (AAD) and Conditional Access Policies (configured properly) that enforce Multi Factor Authentication (MFA) when accessing Office 365 GCCH and its various workloads. MCAS extends the definition of a "non-privileged" user beyond identity and the ability to MFA. MCAS will check to see if the user is attempting to execute privileged functions or access CUI from a suspect country, non-trusted device, or under suspicious circumstances (i.e. impossible travel).
AC.1.003 Verify and control/limit connections to and use of external information systems.
Cloud SaaS platforms such as Office 365 GCC High are, by their nature, accommodating to the modern worker within the Defense Industrial Base (DIB). Modern users desire to access email and corporate resources from their mobile devices, separate networks (home, coffee shop, etc.), and at all hours of the day. Some of these behaviors are less than ideal, but the fact of the matter is it happens. With MCAS, we can force internal or guest users to proxy* (tunnel) to Office 365 GCC High so we have full inspection capabilities on their activities. Companies can also limit certain access and use of applications when coming from outside allowlisted IP's for instance.
CM.2.062 Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
This control is mostly met in the Azure Security Center elsewhere and AAD, but MCAS goes beyond role based 'least functionality' to assessing Session Risk to determine if functionality or capabilities need to be reduced real time. If a user begins to exhibit odd behavior or access from a new IP address, MCAS will interpret the session differently.
CM.2.063 Control and monitor user-installed software.
CM.3.069 Apply deny-by-exception (denylisting) policy to prevent the use of unauthorized software or deny-all, permit- by-exception (allowlisting) policy to allow the execution of authorized software.
Both of these requirements are met with Microsoft Intune and locally installed administrative policies on individual machines. Nevertheless, MCAS further denies or permits certain behaviors within authorized or unauthorized software. For example, MCAS can stop an individual from downloading, copying, printing, etc from an authorized application. MCAS will also detect new applications users are using, especially applications that access your data. This cuts down on shadow IT activities.
IR.2.096 Develop and implement responses to declared incidents according to pre-defined procedures.
MCAS is "live security" and is constantly looking at all CONDITIONS at all times. The above graphic demonstrates how MCAS will respond to, not only, protect against ransomware and malware from entering cloud storage, but it will also assess cloud threats based upon user behavior. Using machine learning, it will respond to incidents of odd user behavior or chance of compromised accounts/credentials and apply pre-defined controls to individual applications across the cloud estate.
PS.2.128 Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
Microsoft Intune can wipe a device upon termination, and Azure Conditional Access Policies will block access to authentication attempts from terminated employees. MCAS goes beyond checking the box of compliance by logging and alerting administrators of authentication attempts from previous employees or known devices that have been stolen, or tied to a previous employee.
The key benefits that MCAS provides over Sentinel:
Discovers cloud usage and can report on almost anything
Can report on Shadow IT
With some Proxy servers, MCAS can block on-premises traffic to cloud providers both manually and also by risk score
Over 15k Web Services now in MCAS
Provides risk assessment of traffic in/out of Cloud Services like Office 365 in real-time*
Threat protection by adding Malware, Ransomware, and other threat protection to all cloud services, including Azure BLOB Storage
Detects Insider Threats and suspicious user activity
MCAS is not a hard requirement for CMMC, whereas a SIEM tool like Azure Sentinel is. Simply put, it is not required for COMPLIANCE, but for most companies handling sensitive government data - they need MCAS for SECURITY. We have to be sure we understand the difference in ensuring compliance vs. ensuring security. We can be compliant and not secure AND secure and not compliant. Katie Arrington sums it up well in one of her recent talks at the Cloud Security and Compliance Series event in Indianapolis, "If I've created another checklist, then we've failed."
*Pending release of Conditional Access App Control (Proxy Service) for Government (Sovereign Cloud)
Azure Sentinel to come...