Security Best Practices Guide for existing OCI Tenancy

Purpose

This blog is a continuation of our overview blog, and the purpose is to provide a detailed process and easy steps to follow to ensure your existing Oracle Cloud Infrastructure (OCI) tenancy is configured to have a high security posture and it is aligned with cloud security best practices as provided by the Center for Internet Security (CIS) OCI Foundations Benchmark and Oracle. 
You will learn how to discovery the configuration of the tenancy, the assessment of the security posture, how to remediate any findings and how to periodically assess the tenancy to detect potential configuration drift.

Throughout the blog we will reference our Security Guide Github repo that hosts a wealth of links to blogs, integration guides and Oracle documentation. 
 

Steps to secure your OCI tenancy.

For an existing tenancy the high-level process we recommend is:
 

Discover:

When working with a tenancy that already contains resources, we need to go through a discovery process to determine how the tenancy has been configured from a security perspective. To assist in this process, we will use the CIS Compliance Checker script and Network Visualizer.

1. The CIS Compliance Checker  script has additional features that can help us in collecting information and evaluating the tenancy against the Oracle Best Practices and the OCI CIS Benchmark. Run the CIS Checker script following these instructions.
   
   This will produce multiple CSV files, divided into 3 categories, that can be distinguished by way of their filename prefix:
   • Files starting with “cis_”, contain information about compliance with the CIS Benchmark.
   • Files starting with “obp_” contain information about compliance with the Oracle Best Practices.
   • Files starting with “raw_”, contain additional information about select OCI resources that will be used during the assessment phase. 
     
      
2. For discovery of existing network resources and how they may be interconnected we recommend using the “Network Visualizer”, that is available via the OCI Console.
   For each region select the root compartment and select “Include child compartments”, as this will give you a complete regional view of all network resources.

Assess:

We will use the information gathered as part of the discovery phase to assess the security posture of the tenancy and how it aligns with our highly recommended security controls. The outcome will be a list of identified security controls that will need to be remediated or handled by an exception process.

1. OCI Audit Log SIEM Integration:
   SIEM integration typically relies on the Service Connector Hub functionality to send Tenancy wide audit logs to a stream or buckets for the SIEM to then pull.
    
   • To assess this integration, we will review the file called “raw_data_service_connectors.csv”. 
   • If this file doesn’t exist, then we know that no Service Connectors have been provisioned in the tenancy and it is very unlikely that any SIEM integration has been setup.
   • If the file exists, we need to validate that there is a Service Connector for each subscribed region and that the source data is Audit data from the root compartment and across all sub-compartments. The file "raw_data_regions.csv" will show all subscribed regions.
      
2. CSPM Integrated with your Tenancy:
   For the OCI native CSPM tool we can validate the configuration by reviewing the files “obp_OBP_Summary.csv" and “obp_Cloud_Guard_Config_Findings.csv”. 
    
   • In the “obp_OBP_Summary.csv” file we can review the row called “Cloud_Guard_Config” and in the “Compliant” column we can at a high-level see if this security control has been met. 
     
   • If we want to drill into the reason behind the non-compliance, we can review the file “obp_Cloud_Guard_Config_Findings.csv”. To be compliant, we need the following criteria met:
     • Cloud Guard is enabled.
     • Cloud Guard has a target defined at the root level.
     • Cloud Guard has an Activity, Configuration and threat detector recipe attached to the target.
     • A responder recipe is attached to the target.
     • An event rule defined that triggers on Detected, Remediated or Dismissed problems.
     • The correct people/teams are notified when the event rules fires.
   • For 3rd party CSPM integration you would need to ask the appropriate team responsible, to assess if the integration is complete.
      
3. OCI Console integrated with your Enterprise IDP
   This Security Control can be assessed by reviewing the login process when accessing the OCI Console. 
   Users should have the option to select the Enterprise IDP or autmatically be redirected to the IDP when accessing the OCI Console.
    
4. Centralized User/Group lifecycle Management
   This security control can be assessed by asking the appropriate team responsible for Identity Governance. Often the Enterprise IDP used will also provide the Centralized User/Group lifecycle Management functionality by using SCIM as the mechanism.
    
5. Ensure MFA is enforced for OCI Console access:
   To assess this security control, you will have to validate that MFA is enforced at the Enterprise IDP level and for any OCI users not managed by the IDP.
    
   • Reviewing the file “cis_Identity_and_Access_Management_1-7.csv” will provide a list of OCI users that do not have MFA enabled.
      
6. Compartment Structure supports access controls and grouping:
   The assessment of this security control will depend on an understanding of your organization and how teams work with OCI. Full-stack developer teams will use a different compartment structure compared to individual Network and Database teams.
    
   • The file “raw_data_identity_compartments.csv” contains a list of all compartments and their parent-child relationship. This can be used to map out the existing compartment structure.
      
7. Secure and Scalable networks
   When assessing this control, it is important to understand business requirements and future growth plans. We recommend evaluating the topology with the following criteria in mind:
    
   • If multiple VCNs are used, are they connected or isolated? If they are connected is this done using Local Peering Gateways(LPG) or a Dynamic Routing Gateway(DRG) in a Hub and Spoke topology? Using a DRG provides flexibility in terms of adding additional VCNs and controlling the routing of traffic between VCNs and routing to external destinations.
   • If LPGs are used, is the initial limit of 10 per VCN close to being reached?
   • It is recommended to review the need for isolated VCNs vs. having them attached to a DRG as part of a Hub and Spoke topology. Especially, if the VCNs have Internet ingress.
   • Is there a “Hub” VCN that shared services and Virtual Firewalls use? 
   • How is traffic separated? Is Prod and Non-Prod traffic segmented?
   • Is traffic inspected during ingress to OCI from the Internet or during egress to on-premises /other clouds?
   • Is the DRG upgraded to the latest version and providing additional functionality?
   • Are Network Security Groups used to allow/deny access to resources?
   • If Security Lists are used, have custom lists been created vs. using the Default Security Lists
   • Are there unused resources that should be deprovisioned?
      
8. Resilient Connectivity: 
   When assessing this control, it is important to understand business requirements for connectivity and redundancy. If there is no need for connectivity to on-premises or other cloud providers then this control becomes not applicable. To assess this control, we can use the network CSV files provided by the CIS Compliance Checker to review Fastconnects (FC), IPSec connections, DRGs and Oracle Best Practice compliance.
    
   • Fastconnect Review: use the file “raw_data_network_fastconnects.csv”:
     • How many FCs have been setup in the tenancy?
     • In what regions are the FCs provisioned?
     • What provider is used? 
     • What is the state? Is BGP up or down?
     • What is the bandwidth? and does it match the business requirements?
     • Are multiple FCs attached to the same DRG or different DRGs?
        
   • IPSec Review: use the file “raw_data_network_ipsec_connections.csv”:
     • How many IPSec connections have been setup in the tenancy?
     • In what regions have they been provisioned?
     • Are they attached to the same DRG or different DRGs?
     • For each IPSec connections what is the status of the tunnels?
     • Is BGP routing used or is it Static routing?
        
   • DRG review: use file “raw_data_network_drgs.csv” and “obp_Networking_Connectivity_Findings.csv”:
     • How many DRGs have been provisioned and in what regions?
     • Have they been upgraded?
     • How many FCs or IPSec connections have been attached to each DRG?
     • Any unused DRGs or FCs/IPSec connections that are not attached?
     • Using the OCI Console review the DRGs and their redundancy status (Green/Red)
        
   • Additionally, we recommend to assessing the following:
     • Are periodic  Fail-over/Fail-back tests executed?
     • If IPSec is used as a backup for a FC, is the available bandwidth sufficient?
     • Does every region with on-premises connectivity have redundant connections? 
     • Are FCs and IPSec connection status monitored using either the OCI Monitoring Service or a 3rd party tooling?
        
9. Visibility into unexpected OCI Cloud Spending:
   The control we want to assess is if a forecast-based budget has been defined at the root level with a sensible spending threshold and the right people will get alerted in case spending is forecasted to exceed the threshold.
    
   • We can assess this control partially by reviewing the files: “obp_OBP_Summary.csv” and “obp_Cost_Tracking_Budgets_Best_Practices.csv”.
     This will show if the Oracle Best Practice for cost tracking has been met and provide details on the defined budget threshold and budget alert rule. However, assessing if the defined spending threshold is correct will require a review of spendings over a period of time and understanding if the tenancy is in a steady state.
   • Note: This control can also be met by using 3rd party tooling that pulls cost information from the tenancy. One point to evaluate is the time it may take to react to unexpected spendings. E.g. the control is not met if once a month a report is generated and reviewed.
      
10. Database Security:
    We want to ensure that the security posture of all Oracle Databases in the tenancy is periodically reviewed by the native Data Safe Service (or another 3rd party tool) Assessing this security control consists of three main steps:
     
    • Create an inventory of all Oracle Databases in the tenancy.
    • Checking if there is a Data Safe target defined for each Database.
    • Validate that a scheduled security assessment has been defined.
      These steps can be executed via the OCI Console.
       

Besides assessing the highly recommended security controls we also suggest reviewing the 
generated  “cis_” files as this will provide information on how the tenancy aligns to the OCI CIS Benchmark.

1. Review the “cis_summary_report.csv” or "cis_html_summary_report.html" files to get an overview of non-compliant CIS controls.
   
2. Review the individual cis_<domain>_<control number>.csv files to identify the specific non-compliant resources. E.g. the file “cis_Identity_and_Access_Management_1-7.csv” will list any users that don’t have MFA enabled.

Remediate:

The list of remediation will depend on the individual issues found and if 3rd party tooling is used. Please review the list of remediations within each domain and use the instructions provided for the remediation.

Some remediations can have an impact on running workloads or access to functionality within the OCI Console and it is therefore strongly recommended to evaluate each remediation and any impact it may have before making any changes.

Test and Verify Compliance:

An important part of the process is to verify that any identified issues have been remediated.
Besides verifying the individual remediations like SIEM or IDP integration we also recommend rerunning the CIS Compliance Checker and reviewing the output as configuration drift often happens.

Next Steps on your OCI Cloud security journey

• Establish a 6-month or yearly process for running the CIS Compliance checker and assessing compliance with the CIS OCI Benchmark.
   
• Review our solution playbook about incorporating Cyber-Resilience capabilities into your OCI tenancy.