Trailing Risk Events In Oracle CASB
July 2, 2019 | 6 minute read
Uday Sambhara
Consulting Solutions Architect
Introduction
Oracle CASB Cloud Service's (hereafter referred to as CASB) core functionalities are evaluating user behavior, generating risk-event alerts on policy match and detection of weak security controls of a monitored target among various other features. It is crucial to understand how an event that occurred at source is captured in CASB, whether the event qualifies for CASB's evaluation of security baseline monitoring and/or policy monitoring.
This blog aims to help a CASB administrator get an understanding on tracking down an event occurrence, investigating an alert and taking action or simply understand why an expected alert is not generated and make necessary changes prior to next audit run from CASB. This article is written in context of OCI compartment as monitoring target.
Case Study
My colleague Andre’s blog on OCI compartment organization and delegated administration established by various security policies and security lists is a good reference case study for this blog. When monitoring OCI compartments an administrator should be able to correlate an event occurrence at target OCI compartment and how that event further was evaluated and acted upon in CASB.
Let's consider following 2 events that happened in a CASB monitored compartments of OCI environment.
-
A privileged user created/updated a 'Security List' to allow ports 22, 80, 7777, 3389 to be accessed from anywhere on the internet, CIDR 0.0.0.0/0.
-
A privileged user modified an 'IAM Policy' to now allow all users of group HR-Admins to manage Sales compartment.
The above two changes are avoidable (which is a topic of governance and a diversion from current context), but the aim here is to demonstrate how one can capture such events in CASB. Case-1 generates a security control alert. Case-2 generates a policy alert. Security control alerts are triggered for the resources/actions monitored in security base line. Policy alerts are triggered for operations monitored by Policies.
If you are wondering how to configure CASB to choose between Security Alert or Policy Alert triggers. Security Control baseline is a canned template, pre-configured with best practices monitoring configuration with little or no modification needed. If there is a resource or action that needs monitoring that is not part of Security Control baseline, Policies are the route to go. For more information on this refer to Pulkit’s blog. Now we will trail these 2 cases with an example in detail.
CASE-1
At CASB, make sure the security control baseline for the CASB monitored OCI compartment is set to check for unrestricted traffic (meaning anywhere from internet 0.0.0.0/0). In this example internet traffic to ports 22,80,9999,7777,3389 is considered as deviation from the security baseline.
At OCI, a privileged user made an update to a Security list to allow access to ports 22, 80, 777, 3389 from 0.0.0.0/0. Reasons could be for SSH, allowing http traffic to Webserver, allowing RDP and such, as seen in screenshot below.
Checkpoint: CASB was set to monitor security list changes in security baseline and a privileged user made an update to security list in OCI. CASB should flag this change.
At the next system scheduled iteration, CASB fetches, parses and further sifts through these OCI data events to detect any deviation from the security baseline based on the template definition. A Security Control Alert is a result of a successful detection of a deviation from the security baseline.
To view the security control alerts, select an application and choose 'view details’. This will display all Risk Events for the application. Click Security Controls to display only security base line risk events as seen in screen shot below.
Select/click the event row to display diagnosis details. Optionally click on “view Object Data” to view the OCI resource details, a security list in this example context.
The next activity in this trail is for an administrator to respond to an event. An administrator can choose to either create and assign an incident with specific details for remediation or dismiss the event with applicable comments.
Dismissing an event suppresses the current risk alert, however the deviation from the security baseline is evaluated at every scheduled fetch and risk events are generated accordingly. If a deviation is remedied at the monitoring target, then the risk events are auto closed on detection.
An administrator can create an incident from the Action dropdown or by clicking 'create’ under the incident column (see highlighted boxes in previous image) and assign for manual remediation. Also, an incident can be edited and/or resolved with appropriate comments, as seen in example screen shots below.
Incident Creation example:
Incident Edit example:
Incident Resolve example:
Remediation in this case would be fixing the issue at source by updating the security list to either restrict the ports to be allowed from internet or update the CIDR block to specific range instead of 0.0.0.0/0. It is also possible that CASB did not capture an event that you expected to capture on the baseline, in this case remediation would be to update the baseline monitoring to capture the event. In this example we left out port 443. The fix is to add 443 to monitored ports for alerting.
CASE-2
Trailing for case-2 is similar, except the outcome risk-event is a policy alert instead of security baseline alert.Briefly the steps are:
-
Make sure a policy (Reference blog on Create/Update a policy) is set to monitor any update to IAM Policy on monitored OCI compartment.
-
When there is an update to an IAM Policy, it is captured in audit logs of OCI.
-
CASB parses the audit logs from OCI on the next audit events fetch.
-
CASB generates a policy alert when the audit event matches the condition set in the policy.
-
View the policy-based events from application menu by selecting ‘View Details’ and ‘Policy Alerts’ for the application.
-
Administrator can further view the risk-event details and choose to either create an incident or dismiss the event.
-
Administrator can choose to receive high risk event alerts via email by opting in for notifications from the preferences section.
Conclusion
In this article we have seen how CASB fetches and parses OCI audit data for policy evaluation and baseline monitoring and how an administrator can follow CASB events end-to-end for further action/remediation. Remediation can be fixing the issue at monitoring target itself or updating/tuning a policy/security baseline when expected alerts are not generated. If clients prefer to export all the events from CASB to their preferred control pane for purposes like auto remediation they can do so and this process is outlined in this blog. Happy trailing.
Uday Sambhara
Consulting Solutions Architect
Next Post