Cloud access security brokers (CASBs) are 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.

There are Top CASB use case categories:

Govern usage: Govern your organization’s cloud usage with granular visibility and control. Rather than take a coarse-grained approach by blocking services, govern usage based on identity, service, activity, and data. Define policies based on service category or risk and choose from actions such as block, alert, bypass, encrypt, quarantine, and coach for policy enforcement.

Secure data: Protect and prevent the loss of sensitive data across all of the cloud services in your environment, not just the ones you sanction. Take advantage of advanced, enterprise DLP to discover and protect sensitive data in sanctioned cloud services and en route to or from any cloud service, sanctioned or unsanctioned, whether users are on premises, remote, on a mobile device, or accessing from a web browser, mobile app, or sync client.

Protect against threats: Guard against cloud-based threats such as malware and ransomware. Start with full visibility of all cloud services, even those using SSL-encrypted connections, and use anomaly detection, and threat intelligence sources such as which of your users has compromised accounts. Then layer in static and dynamic anti-malware detections, plus machine learning to detect ransomware. Finally, arm the rest of your security infrastructure with your findings through out-of-the-box integrations and workflows.

 

CASB CS collects information from key enterprise systems: Oracle CASB Cloud Service – Discovery allows you to uncover any apps or plug-ins that does not have explicit organizational approval. These are known as shadow or stealth apps. Oracle CASB Cloud Service discovers app usage in cloud applications it is monitoring.

Currently, automatic discovery is available for Salesforce. Oracle CASB Cloud Service scans the Salesforce login history, Application column, and maintains a list of unique applications that users have logged in to over the last 30 days. Oracle CASB Cloud Service then looks up third party reputation data, and displays business and security details in the administration console. Oracle CASB Cloud Service automatically discovered apps that users have added to Salesforce, and uses a reputation feed to create a risk score and high-level report about each discovered app.

Oracle CASB Cloud Service Discovery can import firewall logs manually. You can upload log files from Palo Alto Networks, Zscaler, or Sophos. Oracle CASB Cloud Service analyzes these logs to determine what external services and plug-ins have been accessed, and it then refers to a reputation feed to determine what risks (if any) each one presents.

These are steps to implement Oracle CASB Cloud Service:

– Use Case 1: Adding a Box instance (monitor-only mode)

1. In the Oracle CASB Cloud Service console, select Applications, Add an app, Register an app instance.
2. In the Select an app type page, click the icon for the type of application you want to register (select Box application instance) and click Next.
3. In the Select an instance page, enter a unique name (OW2_Box) for your application instance. Existing names appear below the name field.
4. Click Next.
5. In the Select monitoring type page, select Monitor only to have Oracle CASB Cloud Service monitor this application using its “stringent” settings.
Oracle CASB Cloud Service generates a security control alert in Risk Events whenever it detects a mismatch of any kind between its “stringent” settings and the actual settings in the Box instance.
6. Click Next.
7. In the Enter credentials page, your selections depend on how users log in to Box (use the following credentials atgwork.casb.oracle@gmail.com/PasswordSecret).
9. When you are done entering your credentials, click Test Credentials. It can take a minute or two for the application to receive and accept your credentials.
10. When testing is done you will see a success message. Click Submit.
11. Click Done. When the registration process is complete, your application instance appears in the carousel at the top of the page. You start to see data for this instance after a few minutes, although a complete synchronization will take longer.

– Use Case 2: Creating a Box policy alert

1. In the Oracle CASB Cloud Service console, select Configuration, Policy Management, click New Policy.
2. Use the following field values and then click Next.
Name: OW2_Box_Policy
Description: OW2_Box_Policy
Priority: High
3. Select the following field values and then click Next.
Application type: Box
Application Instance: OW2_Box
Resource: File
Resource name: Text
Equal to: Report
Action on this resource: Any
4. Select the following field values and then click Next.
Select by user name
Username contains: oracle
5. Click Next. Click Submit. CASB CS start collecting initial data for the newly application instance. More exactly it start to do: Analyzing security controls, analyzing policy alerts and running threat analytics. In terms of time, this can take between 2 and 30 minutes.

– Use Case 3: Unregister a Box instance

1. In the Oracle CASB Cloud Service console, select Applications; click the application instance (select ow1_box application instance).
2. Click Remove.
3. Click OK to unregister “Box: ow1_box” application instance. The process is complete; your application instance does not appear in the application list and in the carousel at the top of the page.

– Use Case 4: Create new account with limited visibility to a particular cloud application
1. Oracle CASB Cloud Service provides different roles and provides support to limit access to particular cloud applications and functions in the Oracle CASB Cloud Service console.
2. Basically we have three roles that can be assigned to an Oracle CASB CS account: Tenant Administrator, Security Analyst and Compliance Manager.
Tenant Administrator: has all administrator privileges, and adds and manages other administrators. The first Tenant Admin in your organization is known as the root. You cannot delete this user. Only a Tenant Administrator can add and remove other Oracle CASB Cloud Service users, so it is important to always have at least one backup tenant administrator.
Security Analyst: creates policies, reviews threat analytics, monitors the health of your enterprise, and manages incidents. A Tenant Administrator can limit a Security Analyst’s view to particular application instances. This also limits the Security Analyst’s ability to view policies to only those that apply to these application instances.
Compliance Manager: Reviews threat analytics, monitors the health and compliance of your enterprise, and manages incidents. Compliance Managers cannot view policies
3. Let’s create a new Oracle CASB CS account and assign it the Security Analyst role: click Configuration and then click Admin Management. Under Admin List page click New Admin.
Use the following field values and then click Save.
First Name: Oracle
Last Name: Workshop2
Email: oracle.workshop2+dynamite@gmail.com
Role: Security Analyst
Application Instance: Box: OW2_Box
4. Connect to atgwork.workshop2@gmail.com (use the following credentials atgwork.casb.oracle@gmail.com/PasswordSecret) account and navigate to the unique first-time access URL. Access the activation URL and enter the confirmation code to activate the new security analyst Oracle CASB CS account: oracle.workshop2+dynamite@gmail.com. Edit and confirm the password for the new account and click Confirm.
5. Logon to Oracle CASB CS using new account: oracle.workshop2+dynamite@gmail.com. Security analyst. Check the Security Analyst’s ability to view only application instance for which has been granted access to.

– Use Case 5: Reporting Features and Key Security Indicators
1. Let’s look at the risk scores of users that have logged into the registered cloud services along with some of the reasons CASB CS has increased or decreased the risk scores based on recent analytics check.
2. Click Dashboard and then click Key Security Indicators. Under User with most failed logins identify the user with most failed login attempts and click on it to view user detailed report on failed logins.
3. User has X number of failed logins attempts.
4. Check Failed logins report for the user and under LOG DATA click View log data and then click on a record to check the event (check application, browser, login URL, Platform, source IP, Status).
5. Click Users and try to identify your use and his/hers risk score. Check the reasons for that high score on the Reason column.
6. Click on that appropriate user. Check the User Risk Score Trending. Check the Risk Factors under the chart. For a more details we can run the user full activity list by clicking on the detailed activity report button (just on the right side of the screen, under the chart).
7. Inside the user full activity list, by clicking on the gear button we can scroll down and add the log data and look into more details for that person’s activity. Now we can see what the user has specifically been doing in one registered cloud application service or even across multiple services if the user identity has been mapped across them (this is obtained when the enterprise is using an IDaaS solution).
8. Click Dashboard, click Key Security Indicators (are aggregated across multiple registered clouds services, but we can drill down a little bit more). The indicators will change based upon the types of cloud services you register. KSI’s are summaries of underlying report data on the various topics created to identify issues before they become actual full threats to the organization.
9. Click AWS, turn on EC2 Key pair rotation, check unused or key not rotated (this can really shock some customers when they see just how old those keys may be, and that someone may still have and use them) and then click View Report to drill down and check when the keys were first used (when asked whether you want to leave without saving, click Leave).
10. Return using the Back arrow in the top left corner next to Dashboard.

11. Click Box, turn on Files downloaded most often, check the files downloaded and then click View Report to drill down and check when the file was downloaded and by whom (when asked whether you want to leave without saving, click Leave).
12. Return using the Back arrow in the top left corner next to Dashboard.

– Use Case 6: Access Map
1. Click Dashboard and show the Access Map by expanding it using the DOWN CHEVRON next to the All Events dropdown filter. Like the KSI’s, data in this map is pulled from all of the registered cloud services in this tenant.
2. From All Events dropdown filter select normal events and then suspicious events. Notice that are 2 colors and 2 icons in the map:
 Red means a location that has been tagged as “questionable” or “black listed” from which activity or interactions have been seen inside the registered services. Green means a location where activities/interaction was done but the location was NOT set as “blacklisted” or “suspicious” in our threat intelligence feeds.
 The two shapes are a pin or a cluster. Clusters just mean there is more than 1 pin inside it. If one pin is red inside a cluster, we show the cluster red.
3. From All Events dropdown filter select suspicious events.
4. Zoom in to see which pin is red. Pick the RED pin/cluster over Jacksonville, FL. Drill into that data set to show the report of activities from that red pin (identify the suspicious activity type registered in this location).
5. Return using the Back arrow in the top left corner next to Dashboard.

– Use Case 7: Users hopping over different IP addresses
1. Click Risk Events and sort by CATEGORY to display Anomalous activity first.
2. Identify the events containing the “IP hooping risk”.
IP hooping risk is identified when a user has accessed a cloud application from multiple IP addresses in a relatively short amount of time.
This activity is usually also associated with traveling long distances in the same time frame. This type of risk can indicate account hijacking, sharing of account credentials, or other suspicious behavior.
3. Type “IP hopping” in the Search field, and then click Search to view all users at risk of account hijacking due to IP hopping.
Identify an account that generated alerts for IP hopping risk. User X has generated IP hooping alerts on different occasions during this reporting window for different apps.
Click to expand an IP hopping risk.
4. In the Action column of the risk details, select View threat, and then click the different views in the threat chart for details about each attack.
For this event the recommended actions would be the following:
Verify that the activity is from a legitimate user with a business need.
Confirm that the user’s account or device was not compromised.
Confirm that the user did not share credentials.
Give the user VPN access with endpoint verification.
Consider limiting access using an Access Control List (ACL), IP whitelist access to the service from only known networks, or applying stronger authentication requirements.

– Use Case 8: Brute force login attack threat
1. Click Risk Events and sort by CATEGORY to display Anomalous activity first.
2. Identify the events containing the “Brute force attack risk”.
Oracle CASB CS detected a significant number of failed attempts to log in the registered cloud accounts. This sort of activity can indicate a brute force attack, password guessing, or end user login issues.
3. Type “Brute force” in the Search field, and then click Search to view all users at risk of account hijacking due to Brute force attack.
Identify an account that generated alerts for brute force attack on different occasion during the current reporting window for different apps.
4. Click to expand a Brute force attack risk.
5. In the Action column of the risk details, select View threat, and then click the different views in the threat chart for details about each attack.
For this event the recommended actions would be the following:
First, determine whether the end user is having login issues.
Provide technical assistance in selecting good pass phrases, using a password safe and/or MFA/2FA for additional compensating controls.
Make sure that users change their passwords on a periodic basis.

– Use Case 9: Application Health Analysis
1. Click Applications, and then click Acme_AWS.
2. Check the TOP RISK ACTIVITIES listed: here we have Security controls, Incidents and Threats reported, and also we have a number of policy alerts fired by CASB CS.
3. Click View Details.
4. Check DATA PROCESSED IN THE LAST 90 DAYS: in terms of Data Size, Records, and IP Addresses.
5. From the RISKS BY CATEGORY area select Policy Alerts and show details for the alerts (Users assigned admin privileges, user stopping an instance) and moreover from this area we can raise an incident that can be assigned to an ACME_AWS security analyst.
6. From the RISKS BY CATEGORY area select Treats and show details for the threats (suspicious IP addresses – which can be blacklisted IP addresses for instance, user behavior risk). From the user behavior risk we can drill down and check the details of the threat. Click Actions, and then click View Threat. Check Anomalous activity such Unique OSs, change of source networks access in Network Prefixes and Unique Browsers and dates of these activities.
7. From the RISKS BY CATEGORY area select Security Controls and show details for the security controls that are drifting from the baseline values: such as network ACLs, MFA authentication for AWS root which is not enabled, polices that forbid users to change their own passwords and other password policy drifts (Require at least one uppercase letter, Require at least one number, etc.). From this area we can raise an incident as well, incident that can be assigned to an ACME_AWS security analyst, by click Actions and then Create Incident.

– Use Case 10: Blacklist an IP address and check the risk event generated
1. Check your internet browser proxy settings.
2. Go to https://www.whatismyip.com to identify your public IP address. Copy your public IP address.
3. In the CASB CS, click Configuration and click Manage IP Addresses.
4. Click Blacklist tab and click Add IP Address.
5. Select individual address and paste your public IP address. In the Description field edit a short description. Under Application and instances field select OW2_box account. Click Save.
6. Open a new tab in your internet browser and go to https://account.box.com/login.
7. Use the following Box credentials oracle.workshop2+box@gmail.com/ENG_2016 to logon to the box account form the newly blacklisted public IP address.
8. Logout from the box account.
9. In the CASB CS, click Risk Events and from the App Instance select only OW2_box application instance. After a complete synchronization that can take longer a new anomalous activity is visible in the Risk Event that is generated by the access from the suspicious/blacklisted IP address.