Section 4.3 Identity and Access Management (IAM)
As you study this section, answer the following questions:
- Why is identity and access management important to an organization?
- How is role-based access management different from attribute-based access management?
- What role does multi-factor authentication play in identity and access management?
- What are six different design styles that can provide software assurance?
The key terms for this section include:
| Term | Definition |
|---|---|
| Role-based access management | An access management strategy where people are granted privileges depending on their role in the organization. |
| Central policy | A program that checks for the correct attributes in an attribute-based system. |
| Attribute-based access management | An access management strategy where an attribute is created for every element of an organization's operations. |
| Multi-factor authentication | An authentication process that requires two or more steps. |
| Service-oriented architecture (SOA) | A kind of software design that contains several services that communicate with each other over a network. |
| Security Assertions Markup Language (SAML) | An XML-based open standard that facilitates the secure passing of authorization credentials from identity providers to service providers. |
| Simple Object Access Protocol (SOAP) | A messaging protocol that is based on XML. It is used for exchanging information between different computers over the internet. |
| Representational State Transfer (REST) | An architectural style that provides standards between different computer systems on the internet and makes it much easier for systems to communicate with each other. |
This section helps you prepare for the following certification exam objectives:
| Exam | Objective |
|---|---|
| CompTIA CySA+ CS0-003 | 1.1 Explain the importance of system and network architecture concepts in security operations
|
| TestOut CyberDefense Pro | 3.1 Implement security controls to mitigate risk
5.1 Implement identity and access management (IAM)
|
4.3.1 Identity and Access Management
Click one of the buttons to take you to that part of the video.
Identity and Access Management 00:00-00:38 Imagine you're a school principal. You have various departments working under you, from the teaching staff to the janitorial staff to others. In this situation, you'd want to grant different workers different access levels for your building.
As the principal, you'd have the master key that would let you get anywhere, while teachers would have keys to their rooms and other important common areas. The food service staff would be able to access the kitchen, and the janitors would have access to almost anywhere. All staff members would be required to wear employee ID badges to identify their role at the school.
Different Privileges 00:38-01:21 This is basically what happens in an enterprise IT environment. Different network users need specific access privileges and rights. A network administrator needs different privileges than his or her subordinate employees, who in turn have different privileges than customers. It's also important for each person on a network to have a unique digital identity so management can monitor their network activity. This is known as identity and access management, or IAM. The main idea behind IAM is that a system first identifies a user before allowing him or her access to a certain level of information or control. It's like having a security guard outside an office building that only lets people in who have proper identification.
RBAC 01:21-02:22 Let's switch gears and talk a little about different kinds of identity and access management. Some systems have what's called a superuser. No, it's not an employee that can leap buildings in a single bound. The superuser is the person who's allowed to access everything on a network. On this network, at least, they have ultimate power.
The superuser has all privileges and can grant them to others. He or she can grant users privileges based on the company role they're in. So, ideally, each user gets what they need to do their job—no more and no less. This is known as role-based access control, or RBAC, and it helps keep up security because no one has more access than they need for their position. For example, somebody on the Quality Assurance team probably needs access to behind-the-scenes material that isn't available to the public or to other departments. Another user, though, might be in Customer Service. They, most likely, need access to customer records but not to the in-progress material that the QA team needs.
ABAC 02:22-02:54 An alternative to RBAC is attribute-based access control, or ABAC. ABAC is based on creating a set of attributes for every element in your company's system. These attributes can include users, their positions, departments, clearances, and so on. It can also include objects, their kind, author, or required clearance level. There are attributes for actions as well, such as reading, writing, editing, and copying files. And there are also environmental attributes, like time, date, and location.
Central Policy 02:54-03:49 If you want to take a train, you first need to have the right kind of ticket. In this attribute-based system, you give employees their tickets, or the attributes that let them get to where they need to go. To
facilitate this, there's a central policy, which is kind of like a train conductor. The conductor, as it were, decides which combination of user and object attributes an employee needs. If someone doesn't have the proper combination, they're probably going to stay on the platform.
Identity and access management is something you likely encounter in your day-to-day life. For example, the following activities all use IAM: entering a PIN, scanning a fingerprint, and logging onto a website. All these things make you prove you are who you say you are before they grant you access to their service or system. It's a good thing you have to enter your PIN at an ATM, or anyone might be able to access your account and take your money!
Create Strong Security 03:49-04:14 One of the most important aspects of IAM is finding secure ways to identify users. Many IAM systems use passwords. This can cause problems if individual users don't use strong passwords that can't be easily hacked. A lot of times, people use the same password for all their online accounts. That means if a hacker discovers one password, they've got access to almost everything.
Multi-Factor Authentication 04:14-04:49 For an extra layer of security, some programs require two-factor authentication, which means that users have to identify themselves two different ways. For example, they might use a password and then be required to enter a code that's texted to their mobile device. This makes it harder to pretend to be someone else. Most systems monitor which users access the system and when. This creates a log that you can manually review to make sure no unauthorized persons have gained access to the system. Simply reviewing the log can help you or the system admins get to the bottom of any problem.
Summary 04:49-05:28 That's it for this lesson. To recap, companies and individuals want to keep their information safe. In order to do this, they need to be able to set limits on who can access certain information. Identity and access management provides a way for system users to first identify themselves, and then gain access to the information they need. There are different identity management methods you can choose from, including role-based and attribute-based controls. Also, remember that systems keep user activity logs. It's a good idea to keep this in mind in case of an emergency.
4.3.2 Identity and Access Management Facts
In enterprise IT, all network users must be given access privileges and rights. Access privileges and rights are based on the user's role, the resource's attributes, or a combination of the two. Each user on the network must have a unique digital identity. This is known as identity and access management (IAM).
This lesson covers the following topics:
- Role-based access control
- Attribute-based access control
- Identity access management
- Mandatory access control
- System monitoring and network architecture
Role-Based Access Control
Each network user, including each customer and contractor, can be granted network and resource access based on that individual's organizational role. This is known as role-based access control (RBAC).
For example, the network administrator should be granted access to the resources required to perform the job of a network administrator. Each role (such as for a member of the QA team, for a customer service representative, or for a contractor) can be granted privileges appropriate for those specific responsibilities. Each user should get only the access they need, no more and no less.
Attribute-Based Access Control
An alternative to RBAC is attribute-based access control (ABAC). In an ABAC system, each resource in your organization is assigned a set of attributes. These attributes can include:
- User attributes such as job position, department, and clearance level
- Objects attributes such as type, author, and required level of clearance
- Actions such reading files, writing files, editing files, and copying files
- Environmental factors such as date, time, and location
In an attribute-based system, network users (employees, customers, contractors, etc.) are given the attributes (or tickets) that grant them permission to access the necessary resources.
To facilitate this, there is a central policy that determines the combination of attributes needed to perform any given action in the system. If a user does not have the proper combination of attributes, he or she will not have access to the resource.
Identity Access Management
Identity access management (IAM) is something that you likely encounter in your day-to-day life. You use IAM when you:
- Enter a PIN
- Scan a fingerprint
- Log in to a website
All these things are you proving who you say you are before you are granted access. For example, you are required to provide your debit card and enter your PIN at an ATM. Otherwise, anyone might be able to access your account and take your money.
Mandatory Access Control
Mandatory access control (MAC) uses labels for both subjects (users who need access) and objects (resources with controlled access, such as data, applications, systems, networks, and physical space). Every operation performed is tested against a set of authorization policies to determine if the operation is allowed. For example:
- Classification labels, such as Secret or Top Secret, are assigned to objects by their owner, who is usually a managerial or governmental entity.
- Clearance labels are assigned to subjects.
When a subject's clearance lines up with an object's classification, and the user has a need to know (referred to as a category), the user is granted access. Access control is mandatory because access is based on policy (the matching of the labels) rather than identity. Owners can only assign labels; they cannot allow access to specific subjects.
MAC can only be implemented and managed by an administrator, as it is a hierarchical system. Because of its implementation, a user will have rights to any security level equal to or lower than theirs in the hierarchy.
Some of the benefits of using MAC are security. Since users cannot set or change their access control, the administrator always knows exactly what permissions will be granted. For this reason, the government's military systems were one of the fist to adopt this method. Many other implementations (such as SELinux and AppArmor for Linux, along with Mandatory Integrity Control for Windows) are now using the MAC model. The biggest concern with MAC is the fact that since it can only be set up and managed by an administrator, it can quickly become cumbersome as systems become larger and more complex.
System Monitoring and Network Architecture
In the following interview, a cybersecurity expert explains their experience with system monitoring and network architecture.
Video
4.3.3 Federation
Click one of the buttons to take you to that part of the video.
Federation 00:00-01:14 Gone are the days when you just had to memorize a password or two. These days, you have accounts for everything, from social media sites to school assignments. Choosing only one or two passwords for your dozens of accounts is a bad idea.
If a hacker can compromise one of these shared passwords, they can access multiple sites of yours.
It's like the difference between having a key ring full of keys for each door in a building and having a single master key that opens any lock.
One way to keep your passwords secure and under control is called federated identity management, also known simply as federation. It's a type of single sign-on, or SSO. SSO is a process that allows users to sign into a single trusted account, such as Google or Facebook, which will enable them to log into various sites without having to repeat the whole process under different usernames.
Federation is a trust relationship that exists between different organizations or applications. It allows users' credentials to be stored so trusted third parties can authenticate using those credentials without actually seeing them. In other words, one entire system is responsible for authenticating the user.
Federation Components 01:14-02:02 The first part of a federation system is called an identity provider, or IDP. It does the heavy lifting of authentication. The second part is a service provider, or SP. These are the sites or apps that need to have users authenticate. The message that goes back and forth between the IDP and SP is called the assertion.
An assertion is made up of a few components, including the user's account name and all the other attributes the SP needs to start a session for the user. It contains a digital signature so the SP can be sure it came from the correct IDP. The SP doesn't do any authentication. It trusts the IDP to take care of all of that. A single IDP can take care of multiple SPs, simplifying the process even more.
Federation Protocols 02:02-02:30 There are various types of federation protocols that can be used to achieve this. The most common protocols include SAML1.1, WS-Federation, OAuth2, OpenID Connect, WS-Trust, and SAML2. Which protocol you use largely depends on your organization's needs. Today, one of the most common protocols is SAML, which stands for Secure Assertion Markup Language.
Shibboleth 02:30-03:15 Let's look at an example. A very common federated identity method based on SAML is Shibboleth. Many universities and public service organizations use Shibboleth. Let's look at how it works.
In a Shibboleth implementation, a user attempts to retrieve resources from a Shibboleth-enabled website, which then sends SAML authentication information over URL queries. The user is then redirected to an identity provider with which they can authenticate using this SAML information. The identity provider then responds to the service provider (the Shibboleth-enabled website) with the proper authentication information. The site validates this response and grants the user access to certain resources based on their SAML information.
Transitive Trust Model 03:15-04:08 Sometimes federated identity management is part of a transitive trust model. Trust models determine how organizations establish relationships among authentication services to authorize different users access to various resources. In a transitive trust relationship, if resource A trusts resource B, and resource B trusts resource C, then resource A trusts resource C.
For example, let's say you want a gym membership at your local gym. They ask you to go to their website to create an account.
You see that the site gives you the option to sign in with your Google account. In this case, the gym's website trusts Google's authentication.
Now, let's say your gym has a vendor that provides bicycle rentals, and they allow you to have an account through the gym account. In this case, the vendor trusts Google's authentication through the gym's account.
Federation Advantages 04:08-04:51 There are many advantages to setting up a federation arrangement.
A big one is making it easier to onboard new users to various programs. If you have a new employee, they likely need to be able to log into multiple systems, such as company email, the timekeeping system, etc. If you have a federated system, you don't have to set up a separate account for each company's systems.
Another advantage is making things easier for the end user. They only need to know one login process to log into various systems more quickly.
Finally, federation allows for better user management. You don't have to rely on the various applications to take care of authentication for you, so you can keep better track of your users by doing it yourself.
Summary 04:51-05:23 That's all for this lesson. To recap, one way to deal with having too many passwords to remember is federation. It's a single sign-on process allowing companies to set up an identity provider for all user authentication needs. These identity providers send authentication information to service providers, which are the different apps or sites that are part of the federation organization. There are a variety of federation standards, with the most common being SAML. Federation provides a great number of advantages for both the users and the administrators.
4.3.4 Federation Facts
With the number of accounts that require passwords these days, users are tempted to use the same password for multiple accounts. However, it is a bad idea to choose only one or two passwords for all accounts. If one password is compromised, a hacker has to access multiple sites. There are ways to help remediate this problem.
This lesson covers the following topics:
- Federation overview
- Federation protocols
- Advantages of federation
- Shibboleth
- Transitive trust models
Federation Overview
Federated identity management is one way to control the security of passwords. Federated identity management is also referred to as federation. It is a type of single sign-on (SSO).
SSO is a process that allows users to sign into a single trusted account, such as Google or Facebook. The user is then allowed to log in to a variety of sites without being required to log in again. Federation:
- Is a trust relationship that exists between organizations or applications.
- Allows one entity to be is responsible for the authentication of the user.
- Stores a user's credentials so that trusted third parties can authenticate using those credentials without seeing the credentials.
A federation consists of two parts.
- An identity provider (IDP) authenticates users.
- A service provider (SP) is the site or app that needs to authenticate users and trusts the IDP for this authentication.
Key points about how the federation works are as follows.
- An assertion is the message that goes back and forth between the IDP and SP.
- The assertion is made up of a few components, including the user’s account name and all the other attributes the SP needs to start a session for the user.
- The assertion contains a digital signature so that the SP can be sure it came from the correct IDP.
- The SP does not authenticate the user.
- A single IDP can take care of multiple SPs, which simplifies the authentication process.
Federation Protocols
There are various types of protocols that can be used with federation. Some of the most common protocols are:
- Secure Assertion Markup Language (SAML) 1.1
- WS-Federation
- OAuth2
- OpenID Connect
- WS-Trust
- SAML 2
The protocol you use depends on the needs of your organization. Today, one of the most common protocols is SAML.
Advantages of Federation
There are many advantages to setting up a federation arrangement that make a business' operations smoother and more secure. These include:
- Easier employee onboarding
- Simpler end user experience
- Better user management
Shibboleth
Shibboleth is a federated identity method based on SAML and is often used by universities and public service organizations.
A Shibboleth implementation includes the following steps:
- A user attempts to retrieve resources from a Shibboleth-enabled website,
- The Shibboleth-enabled website sends SAML authentication information over URL queries.
- The user is redirected to an identity provider with which they can authenticate using this SAML information.
- The identity provider responds to the service provider (the Shibboleth-enabled website) with the proper authentication information.
- The site validates this response and grants the user access to certain resources based on their SAML information.
Transitive Trust Models
In planning authentication and authorization, a trust model defines the relationships between authentication services so that they may accept each other's assertions of users' identities and permissions, when appropriate. Trust models determine how organizations establish relationships among authentication services to authorize different users' and groups' access to various resources. Active Directory is an example of technology that can implement peer trust between domains.
It is helpful to understand the following about transitive trust models:
- In a transitive trust relationship, if resource A trusts resource B, and resource B trusts resource C, then resource A trusts resource C.
- Peer trust models can avoid a single point of failure, like in a hierarchical model, using a ticketing system, cached credentials, or other technologies (but they are typically more complex and take more time to operate).
- Two domains can implicitly trust one another if they have already established trust with the same additional domains.
4.3.5 Service-Oriented Architecture
Click one of the buttons to take you to that part of the video.
Service-Oriented Architecture 00:00-00:59 In this lesson, we'll focus on service-oriented architecture—or SOA—and the essential software assurance best practices associated with this powerful design style. We'll also explore some fundamental SOA concepts and how they make building robust software systems much easier. SOA is especially helpful for enterprise applications, so let's get started.
At its core, SOA comprises multiple services—better described as modules—that seamlessly communicate with each other over a network using a conceptual design called an enterprise services bus. The beauty of SOA lies in this modular nature. Each service is self-contained, enabling independent maintenance without disrupting other services' functionality. This granularity facilitates easier debugging, thus reducing the complexity of managing large blocks of code. Moreover, SOA promotes code reusability, making it easier to develop and maintain software in the long run.
Microservices 00:59-01:37 Within the realm of SOA, we encounter another fascinating concept: microservices. These are even more granular services designed to fulfill specific business needs. They communicate using protocols like HTTP and Thrift API, providing a loosely connected architecture. The true strength of microservices lies in their fault tolerance and scalability. As each microservice functions independently, the failure of one won't bring down the entire application. This architecture enables the rapid deployment of large applications, allowing companies to expand their offerings with ease.
Security Assertion Markup Language (SAML) 01:37-02:12 Moving on to security measures within SOA, we encounter the Security Assertion Markup Language, or SAML. It's an XML-based open standard that facilitates the secure passing of authorization credentials from identity providers to service providers. SAML enables a convenient feature known as single sign-on, or SSO, where users can employ one set of credentials to log in to multiple websites and applications. This not only enhances security by reducing the need for multiple identities, but also streamlines user access and decreases administrative costs.
OpenID 02:12-03:22 One popular option for SSO authentication is OpenID, an open standard protocol that allows users to authenticate across participating sites using a third-party identity provider. Major companies like Google and Amazon have implemented their own OpenID systems. By registering with OpenID, users can conveniently sign in to websites with their own created credentials. The site verifies the login information through the external OpenID provider. This makes things really secure by adding an extra layer of authentication to OAuth 2.0.
When it comes to SOA communication protocols, two widely used options are Simple Object Access Protocol—or SOAP—and Representational State Transfer—or REST. SOAP, which is also based on XML, facilitates data exchange between applications running on different computers that are written in different programming languages. REST, on the other hand, provides a simpler communication standard for different computer systems on the internet. "RESTful" systems are stateless, separating client and server concerns, giving us greater compatibility and responsiveness.
Summary 03:22-03:48 And that's it for this lesson. We explored the foundations of service-oriented architecture and its vital role in modern software development. We learned about the benefits of microservices, the secure passing of credentials using SAML and OpenID, and the SOAP and REST communication protocols. By implementing these software assurance best practices, organizations can enhance the security, reliability, and scalability of their software systems.
4.3.6 Service-Oriented Architecture Facts
Software assurance refers to the confidence that software is secure and functional. Depending on the software function, there are different styles of software design that can provide software assurance.
This lesson covers design styles.
Design Styles
The following table describes types of design styles.
| Design Style | Description |
|---|---|
| Service-Oriented Architecture (SOA) | SOA is mostly used in enterprise applications. This design style combines multiple self-contained services that communicate with each other over the network to provide the application functionality. SOA services:
|
| Microservices | Microservices are a type of SOA, but the services are more granular. Microservices:
|
| Security Assertions Markup Language (SAML) | SAML is an XML-based open standard that identity providers use to pass authorization credentials to service providers. This means that one set of credentials can be used to login to multiple websites. This is known as single sign-on (SSO) and is widely used over the internet. SAML attestations (or authorizations) are written in eXtensible Markup Language (XML). Communications are established using HTTP/HTTPS and the Simple Object Access Protocol (SOAP). These secure tokens are signed using the XML signature specification. The use of a digital signature allows the relying party to trust the identity provider. As an example of a SAML implementation, Amazon Web Services (AWS) can function as a SAML service provider. This allows companies using AWS to develop cloud applications to manage their customers' user identities and provide them with permissions on AWS without having to create accounts for them on AWS directly. SAML benefits include:
|
| Simple Object Access Protocol (SOAP) | SOAP is an XML-based messaging protocol used for exchanging data over the internet between applications that run on different platforms and are written in different programming languages. It is built to be extensible, protocol neutral, and independent of any programming model. SOAP can be used for:
A SOAP message contains three parts:
|
| Representational State Transfer (REST) | REST is an architectural style that provides simple communication standards on the internet between computer platforms. Systems that use REST are often known as RESTful systems. RESTful systems:
|
| OpenID | OpenID is a method of authenticating users with certain sites that participate in an OpenID system. This enables them to retain a single account for all participating sites. Large companies, such as Google and Amazon, use their own OpenID systems. OpenID Direct adds a layer of authentication to OAuth 2.0, the latest version of the protocol. OpenID uses the following process:
|
4.3.7 Authentication Mechanisms Facts
Almost every website you visit wants you to sign up for an account with a password. Good digital security practices advise you to have a different password for each account, but that can quickly get out of hand.
This lesson covers the following topics:
- Sign in without single sign-on
- Sign in with single sign-on
- Multi-factor authentication (MFA)
- 2-step verification
- Passwordless authentication
- Privileged access management (PAM)
Sign In without Single Sign-On
If a website does not require single sign-on (SSO), it must keep its own database of users and their login credentials. It then goes through the following process:
- The user enters credentials on the home page.
- The website verifies the credentials in its database.
- If the credentials don't match the database, the user is denied.
- If the credentials match the database, the user is granted access.
- Authentication data is passed to web pages.
Sign In with Single Sign-on
With single sign-on, the process is much easier. The website does not have to check its database for user credentials. It relies on a third party, such as Google or Facebook, for authentication. With single sign-on, the process is as follows:
- The user enters credentials on the home page.
- The website checks to see if the logon is SSO.
- If so, the website sends the credentials to an authentication server.
- The authentication server verifies the credentials.
- If the credentials match the authentication server database, the user is granted access.
- Authentication data is passed to the web pages.
- If the credentials don't match the database, the user is denied access.
Multi-Factor Authentication (MFA)
Multi-factor authentication uses two or more factors of authentication, such as a password plus a security code sent to a phone number on file. It can even include authentication attributes such as gait analysis and geo-location to improve its rigor. MFA provides an extra layer of security to an account. It is especially useful when using a single sign-on account to make sure it has not been compromised. For example, a password can be written down, guessed, or shared, or a smart card could be lost or stolen. When using MFA, abusing authentication becomes far more complex. When the requirement for a password is combined with a token-generated PIN or to be combined with a fingerprint scan, abusing authentication becomes many, many factors more complicated. With MFA in place, a username and password can be breached but are unusable without the additional factor.
Authentication Factors
The most common authentication factors fall into one of the following categories:
| Authentication Factor | Description |
|---|---|
| Something you know | A knowledge factor such as a password or PIN. |
| Something you have | A physical factor such as an object in your possession, such as a card or token. |
| Something you are | A physiological attribute or biometric (fingerprint, hand vein, facial recognition, etc.). |
2 -factor authentication (2FA) combines either an ownership-based smart card or biometric identifier with something you know, such as a password or PIN. Three-factor authentication combines all three technologies or incorporates an additional attribute, such as location (for example, a smart card with integrated fingerprint reader). This means that to authenticate, the user must possess the card, the user's fingerprint must match the template stored on the card, and he or she must input a PIN or password.
Description
The login tab is displayed on the MacBook Pro. It reads, verify your identity. A line below reads, check your phone for a push notification. The notification on the smartphone reads, Are you logging into office 365? Below it is the location, time, and email address. There is a deny button on the left and an accept button on the right.
A multifactor authentication (MFA) demonstrating a push-notification sent to a smartphone. (Images © 123RF.com.)
2-Step Verification
2-step verification, or out-of-band mechanism , generates a software token on a server and sends it to a resource assumed to be safely controlled by the user. The token can be transmitted to the device in a number of ways:
- Short Message Service (SMS)—The code is sent as a text to the registered phone number.
- Phone call—The code is delivered as an automated voice call to the registered phone number.
- Push notification—The code is sent to a registered authenticator app on the PC or smartphone.
- Email—The code is sent to a registered email account.
These mechanisms are sometimes also described as 2FA. However, anyone intercepting the code within the time frame could enter it as something you know without ever possessing or looking at the device itself ( auth0.com/blog/why-sms-multi-factor-still-matters ).
In-band authentication describes the use of authentication factors that rely on the same system requesting the authentication; for example, providing username and password credentials on a standalone server .
Passwordless Authentication
Passwordless authentication is a method by which users can access an account without entering a password. This type of authentication relies on biometric authentication, such as facial recognition, fingerprint scanning, voice recognition, or a one-time code sent to a user's email address or phone number. Passwordless authentication methods are gaining popularity as organizations look for methods to improve the quality, reliability, and rigor of authentication. Passwordless authentication offers a method of authentication that cannot be easily shared (unlike a password) and removes the burden of remembering passwords from employees. Passwordless authentication allows devices to recognize authorized users by using their unique physical characteristics instead of their memory of a password.
Privileged Access Management (PAM)
Privileged access management (PAM) is designed to protect against the issues related to credential theft and misuse. PAM refers to the use of people, processes, and technology to control, secure, monitor, and audit all identities used by people as well as services and applications. Using PAM solutions helps security personnel monitor access and ensure credentials are being used in an appropriate way. PAM solutions can store the login credentials of privileged accounts in a secure repository and require additional authentication measures for any entity wishing to use them. Doing so tracks and logs who accessed and used privileged credentials at any time, allowing for greater awareness and visibility into their use. Some examples of PAM software providers include BeyondTrust, Centrify, and CyberArk.
4.3.8 Cloud Access Security Broker
This lesson covers the following topics:
- Cloud access security broker (CASB)
- CASB functions
- CASB implementations
Cloud Access Security Broker (CASB)
A cloud access security broker (CASB) is enterprise management software designed to mediate access to cloud services by users across all types of devices. It monitors activity between cloud service consumers and cloud applications and provides enforcement of security policies.
CASB vendors include:
- CloudSOC CASB ( broadcom.com/products/cybersecurity/information-protection/data-loss-prevention-cloud/cloud-application-security-cloudsoc )
- Trellix ( trellix.com/en-us/products/cloud.html
- Forcepoint ( forcepoint.com/product/casb-cloud-access-security-broker )
- Microsoft ( microsoft.com/en-us/security/business/siem-and-xdr/microsoft-defender-cloud-apps )
- Cisco ( cisco.com/c/en/us/products/security/cloudlock )
CASB Functions
Some functions of a CASB are as follows:
- Enable single sign-on authentication and enforce access controls and authorizations from the enterprise network to the cloud provider.
- Scan for malware and rogue or noncompliant device access.
- Monitor and audit user and resource activity.
- Mitigate data exfiltration by preventing access to unauthorized cloud services from managed devices.
CASB Implementations
In general, CASBs are implemented in one of three ways:
- Forward proxy —This is a security appliance or host positioned at the client network edge that forwards user traffic to the cloud network if the contents of that traffic comply with policy. This requires configuration of users' devices or installation of an agent. In this mode, the proxy can inspect all traffic in real time, even if that traffic is not bound for sanctioned cloud applications. The problem with this mode is that users may be able to evade the proxy and connect directly. Proxies are also associated with poor performance as without a load balancing solution they become a bottleneck and potentially a single point of failure.
- Reverse proxy —This is positioned at the cloud network edge and directs traffic to cloud services if the contents of that traffic comply with policy. This does not require configuration of the users' devices. This approach is only possible if the cloud application has proxy support.
- Application programming interface (API) —Rather than placing a CASB appliance or host inline with cloud consumers and the cloud services, an API-based CASB brokers connections between the cloud service and the cloud consumer. For example, if a user account has been disabled or an authorization has been revoked on the local network, the CASB would communicate this to the cloud service and use its API to disable access there too. This depends on the API supporting the range of functions that the CASB and access and authorization policies demand. CASB solutions are quite likely to use both proxy and API modes for different security management purposes.