- CIS OCI Benchmark Logging and Monitoring Workload
- SIEM (Security information and event management) Workload
- Updates/Fixes to the CIS Compliance Script
- Documentation Updates
The CIS OCI Benchmark Logging and Monitoring Workload adds the following to an existing OCI tenancy:
- Logging Monitoring and Alerting Events and Notifications as recommended by the CIS OCI Foundation Benchmark
- Enables Cloud Guard as recommended by the CIS OCI Foundations Benchmark
- Enables Budgets for Cloud Governance
The workload can be used to partially set up SIEM integration from the OCI side for integration with SIEMs like Stellar Cyber, Splunk, or SIEMs that read from OCI Streams.
Fixes
- Fixed issue on 4.15, “Ensure a notification is configured for Oracle Cloud Guard problems detect” check, which defaulted to True
Updates
- Updated CIS recommendation 4.3 - 4.12 to ensure event notifications are created in all OCI subscribed regions.
- Logo Updated.
- Updated README.md, CONTRIBUTING.md, and LICENSE.txt files.
- Added SECURITY.md file.
- Cloud Guard Detector and Security Zones Rules Mapped to CIS OCI Benchmark 2.0.0
- Updates/Fixes to the CIS Compliance Script
- Updates/Fixes to the Terraform
The CIS OCI Benchmark mapping in the compliance-script.md now maps to Cloud Guard Detectors and Security Zone Rules.
Fixes
- Fixed numbering issue for Logging and Monitoring checks 4.3 - 4.12.
- Fixed to Auditor policy documented in the compliance-script.md to support running OBP checks.
- Fixed language for observations and error messages.
Updates
- Reduced code associated with ADB collection function.
- Added additional debugging statements.
Updates
- Updated to Auditor policy to align with the compliance-script.md update.
- Updated Network and Database Admins with permissions to include repo management.
- New OBP for Certificate Service Certificate Expiration
- OCI CIS Landing Zone Oracle Access Governance Support
- Updates/Fixes to the Terraform
- Updates/Fixes to the CIS Compliance Script
A new Oracle Best Practice (OBP) check scans certificates stored in the OCI Certificate Service and finds those that will expire in under 30 days. This check will help customers prevent unintended outages for OCI Services using certificates stored in the certificate service that expires before causing connectivity errors.
The OCI CIS Landing Zone enables accelerated Oracle Access Governance (OAG) deployment. The policies and groups required for OAG are created and aligned with the OCI CIS Foundations Benchmark. To deploy OAG using the CIS Landing Zone, review the Oracle Access Governance section under Governance in the Deployment Guide.
Fixes
Updates
- Added support to override
https://cloud.oracle.comin deep link URLs in CSV reports with a customer provided deep link URL using the--deeplink-url-overrideargument. This provides support for other realms. The following--deeplink-url-override https://console.us-langley-1.oraclegovcloud.comwill support OC2's Ashburn region. - Added new actions attribute to OCI Event records.
- Added new compliance checking script FAQ item.
Updates:
- Added flag
--report-prefixto allow unique files for better baseline comparison. - Improved performance in querying Identity Domains users’ API keys.
- Improved Identity Domains checking for federated users by using is_federated flag.
- Added Deep Link with Identity Domain name to user, group, and dynamic group records.
- The audit configuration check has been removed because it is no longer in the benchmark.
- Boot Volume resources were added to the check 6.2 resources in the root compartment.
Fixes:
- Handling KMS keys with date issues.
- Removed duplication of Identity Groups for Identity Domains.
- Consistency and commenting updates.
- Updates for CIS OCI Benchmark 2.0.0
- Compliance Checker Script Update for Identity Domains
- Updates/Fixes to the CIS Compliance Script
- Readme Updates
On January 4th, 2024 the CIS Oracle Cloud Infrastructure Foundations Benchmark 2.0.0 was published. To align to this new release the compliance checking script has updated the numbering and added the following new checks:
- Compute checks for secure boot, IMDSv2, and in-transit encryption enabled
- Logging and Monitoring Check added to ensure there is a notification for Cloud Guard events
- IAM check for Database Password rotation In addition, the CIS OCI Benchmark to CIS Landing Zone Architecture Mapping table and architecture where updated to align to the updated benchmark.
To align with the migration from OCI tenancies to those without Identity Domains to those with Identity Domains. All IAM checks have been updated to search all Identity Domains in a tenancy. Checks that were updated are:
- 1.4 Ensure IAM password policy requires minimum length of 14 or greater
- 1.5 Ensure IAM password policy expires passwords within 365 days
- 1.6 Ensure IAM password policy prevents password reuse
- 1.7 Ensure MFA is enabled for all users with a console password
- 1.8 Ensure user API keys rotate within 90 days or less
- 1.9 Ensure user customer secret keys rotate within 90 days or less
- 1.10 Ensure user auth tokens rotate within 90 days or less
- 1.11 Ensure user IAM Database Passwords rotate within 90 days
- 1.12 Ensure API keys are not created for tenancy administrator users
- 1.13 Ensure all OCI IAM user accounts have a valid and current email address
- 1.14 Ensure Instance Principal authentication is used for OCI instances, OCI Cloud Databases and OCI Functions to access OCI resources.
Fixes:
- Check Ensure customer created Customer Managed Key (CMK) is rotated at least annually. was updated to check current key version instead of key creation date.
- Updated checks 1.6, 1.5, 6.2 totals to prevent negative numbers.
- Resolved case sensitivity issue relating to policy check for "PSM-root-policy".
Updates:
- Added a new item to the FAQ.
The README.md was updated to add a click to deploy option for the EU Sovereign regions. Closing issue 136
Links have been added to README.md allowing the initiation of Terraform deployments in non-commercial regions through OCI Resource Manager service. The existing "Deploy to Oracle Cloud" button is unchanged, initiating deployments to commercial regions only. Use the links when deploying to Gov cloud.
config module
- tenancy_ocid, user_ocid and region variables are now hidden in generic_workload_compartments RMS UI.
- IAM policies have been added to allow OKE clusters deployment with NPN (Native Pod Networking) and split compartment topology (i.e., networking in Network compartment and cluster in AppDev compartment).
- Tenancy wide audit logs for Service Connector Hub are now collected using "_Audit_Include_Subcompartment" construct instead of explicitly looping through all tenancy compartments.
pre-config module
- Auditor grants in pre-config module aligned with auditor grants in config module.
- Fixes:
- Added additional error handling in
__search_resources_in_root_compartmentto resolve issue 134.
- Added additional error handling in
- CIS Compliance Script Gets Network Topology
- CIS Compliance Script Gets All Resources
- Landing Zone Architecture to CIS OCI Benchmark Documentation
- Terraform Updates
The CIS compliance Script now queries the OCI Network Visualizer to download a text version of the tenancy's network topology in JSON and PKL file format. This feature is run using the --obp --raw flags or the all-resources flag.
The CIS compliance Script now uses the Search service to query all available resources in a tenancy. The data returned is in a JSON file and is limited to resource types supported by Search and the fields for each resource are limited to the additional details available to the Search service. This feature is run using the --all-resources flag.
The CIS OCI Benchmark to CIS Landing Zone Architecture Mapping document details how the OCI CIS Landing Zone configuration aligns with the CIS Benchmark v1.2.
config module
- Existing dynamic groups can now be selected in Resource Manager UI.
- All IAM remote modules have been pinned to version 0.1.7. If you are managing the Landing Zone with terraform CLI, make sure to run terraform init -upgrade when adopting this release.
- Bug fix: when extending Landing Zone to another region, groups were being processed and an "invalid index" error generated during terraform plan. With this fix, groups are no longer processed when extending the Landing Zone.
- Bug fix: when running Landing Zone config as a user with limited permissions, service policies were being processed and failing during terraform apply due to insufficient permissions. With this fix, service policies are no longer processed when running config as a user with limited permissions.
pre-config module
- Storage admin group has been added.
- Existing provisioning group can now be selected in Resource Manager UI.
- Policies for dynamic groups have been removed, as they can be managed in the config module.
- Ability to use existing dynamic groups has been removed, as the feature is already present in the config module.
- deploy_dynamic_groups variable added, set to true by default. If reusing existing dynamic groups is needed, set this variable to false and select the existing dynamic groups in the config module.
Updates: - Added debugging Identity Groups collection
Updates:
- Compartments management has been pinned to Compartments module v0.1.6.
Updates: - Generic Workloads outputs compartments created Fixes:
- Dynamic Group AppDev
- CIS Compliance Script Adds Identity Domains
- Updates to the CIS Compliance Script
- Workload Expansion Terraform for Quick Start
CIS compliance checking scripts adds collection of Identity Domains password policy. This allows the compliance checking script to access CIS recommendation 1.5 Ensure IAM password policy expires passwords within 365 days and recommendation 1.6 Ensure IAM password policy prevents password reuse.
- Updates:
- Improved navigation for CIS Summary Report HTML
- Added
error_report.csvfor errors when collection OCI resources
- Fixes:
- Improved OCI logging error handling
- Fixed compliance for Storage Admin policies for CIS recommendation 1.14 Ensure storage service-level admins cannot delete resources they manage
The terraform code in this folder expands an existing CIS Landing Zone deployment. It does this by adding one or more workload compartment(s) in the AppDev compartment and, optionally, the associated OCI IAM groups, dynamic groups, and OCI IAM policies to manage OCI resources in the workload compartment. For more information please see the readme.md
- Fixes to the CIS Compliance Script
- Updates to the CIS Compliance Script
- Updates to Terraform Template
Fixes:
- Index of out range exception in obp checks for subnets and buckets in some exceptional cases.
- No budget returned if script executed from non-home region in Cloud Shell. Budgets are now returned in all cases.
Updates:
- Event types added to remediation in HTML report for check 3.13.
- All OCI groups are now returned in raw output, including groups with no users.
- Databases in "UNAVAILABLE" state are no longer returned in check 2.8.
Updates:
- Existing groups can now have spaces in their names. Useful when referring to synchronized groups from external identity providers, where spaces are allowed in group names.
- Variables for existing groups (existing_xxxxx_admin_group_name) can be assigned multiple groups. Feature only available through Terraform CLI. Not available in OCI Resource Manager.
- network_admin_email_endpoints and security_admin_email_endpoints variables now enforce non-emptiness in Terrafom CLI.
Updates:
- Added Service Connector Hub ID and Name to OBP Best practices for VCN Flow Logs and Object Storage Buckets
- Alert users when the cis_reports.py is not run in home region which can impact budgets collection
Fixes:
- Updated CIS 2.8 check updated to exclude ADB-S that are in a VCN but not attached to Network Security Group. Closes issue #105
- Cleaned up 1900+ Flake8
Updates:
- Removed team section
- Added the CIS Terraform Modules Section
Fixes:
- Fixed a defect where missing exainfra admin group name in grants was causing policies creation to fail.
Updates:
- Set Terraform version upper bound to < 1.3.0 in provider.tf.
Updates:
- Added link to CIS Landing Zone Quick Start Live Lab in README.md.
Fixes:
- CIS check 2.8 now skips autonomous database in the UNAVAILABLE state
Updates:
- IAM resources, including compartments, groups, dynamic groups and policies are now managed with new remote modules, available in https://github.com/oracle-quickstart/terraform-oci-cis-landing-zone-iam. The old local IAM modules are still kept in this repository.
- IAM policies can now be created based on metadata associated to compartments. This is an alternative way of managing policies, enabled by the new IAM policy module. In this approach, the grants to resources belonging to a specific compartment are combined into a single policy that is attached to the compartment itself. This differs from the existing approach, where grants are combined per grantee and attached to the enclosing compartment. This alternative way is enabled by Enable template policies? checkbox (if using OCI Resource Manager) or by the enable_template_policies variable (if using Terraform CLI). The existing approach of deploying policies remains the default.
- Some policy grants have been updated, allowing admin groups to manage keys in their own compartments using the OCI Vault in the Security Compartment and deploy private endpoints in Network compartment. Additionally, some grants have been consolidated into a single grant with a comma-separated list of group principals. Service policies have been consolidated into a single policy with the new name ${var.service_label}-services-policy.
- Deploying with an enclosing compartment becomes the default. Users who deploy without an enclosing compartment should unset Use an enclosing compartment? checkbox (if using OCI Resource Manager) or set use_enclosing_compartment variable to false (if using Terraform CLI).
- Quick Start release number added to cis-landing-zone freeform tag.
- Application Information tab is now enabled in OCI Resource Manager, displaying basic information about the stack and outputs of latest Terraform apply.
Fixes:
- Fixed a logic issue for Security Lists and Network Security Groups with source ports but no destination ports
- Removed Deeplink from Exception handling when reading object storage buckets
- OBP check for budgets now verifies that there is budget with an alert for the root compartment
- Performance update to the CIS Compliance Script
- Summary Data update to the CIS Compliance Script
- Fixes to the CIS Compliance Script
Migrate the querying of resources to Resource Search (a module within Oracle’s API). By using Resource Search, compartment iterations for listing items are ignored. For items that require more detailed information than Resource Search returns, only those compartments are queried. This migration reduces script execution time by 8 times.
The CIS Summary report CSV adds two new columns Compliant Items, which represents the number of resources that are aligned to that recommendation, and Total which is the total number of that resource in tenancy. The Total column is also in the screen output.
Fixes
- Updated the CIS checks 2.1, 2,2, 2.3, and 2.4 to detect Security Lists and Networks Security Groups that allow egress access to ports 22 or 3389 via allowing all protocols, all ports, or using port ranges.
- Updated CIS Check 2.5 to only look at Default Security Lists.
New:
- Added support of Security Tokens for script authentication courtesy of Dave Knot (dns-prefetch). For usage example, go to the compliance-script.md and review the Executing on a local machine via Security Token (oci session authenticate) example. For more information on security tokens: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/clitoken.htm
Fixes:
- Security rule added for ICMP in Exadata CS security lists, allowing for the initiation of ICMP requests to hosts in the VCN. Changes in net_exacs_vcns.tf.
- VSS targets are now created when the Landing Zone is extended to a new region. Changes in vss.tf.
Updates:
- Security Zone is enabled only if an enclosing compartment is used. Changes in security_zones.tf.
- Network event types updated for local peering gateway and service gateway: only event types ending with ".end" are captured. Changes in mon_notifications.tf.
Updates:
- Updated CIS rule 1.7 to exclude OCI IAM Local Users that are service accounts. A service account is a OCI IAM Local user that does not have Local Password as a User Capabilities.
- Support validated on OCI SDK 2.97.0. Fixes:
- Improved error handling for Event Rules with no conditions.
- Compartment level service policies no longer created when extending Landing Zone to new region.
- VSS and Vault resources now dependent on service policies.
- Exadata events handled with jsonencode function in mon_notifications.tf.
Updates:
- Added optionality to the NSG deep_link incase the link is less than 254 characters.
- Updated Release version and date.
Fixes:
- Fixed console output formatting for CIS Summary report.
Updates:
- Added egress rules to Security Lists and Network Security Groups.
- Added DRG Upgrade status as Upgrade_status to the
raw_data_network_drgs.csvfile.
Fixes:
- For CIS Recommendations 1.5 and 1.6 now show Not Applicable instead of Yes or No as this is not yet checked by the script.
- Removed filenames for findings with zero findings from the
cis_summary_report.csvandcis_html_summary_report.htmlreports.
- OCI IAM Policy Fix for Database Admin Group
- OCI IAM Service Policy Update
- Enhanced HTML CIS Summary Report
- Compliance Checking Script Updates
Updated OCI IAM policies attached to the Database Admin Group to support deploying ADBs in private subnets. Policy is based on documentation here.
Added an OCI IAM policy to allow OCI services File Storage Service, Object Storage Service, Oracle Kubernetes Engine, Streaming and Block Storage to encrypt data using keys in the OCI Vault in the Security Compartment.
The HTML CIS Summary report from the CIS compliance checking script has a significantly updated look and feel.
- The CIS compliance checking script has added user capabilities to OCI IAM user collection. These attributes are only available in the
raw_data_identity_users.csvfile. - Enhanced exception handling for Oracle Best Practice checks.
The CIS Compliance checking script checks for Logging and Monitoring 3.7: Ensure a notification is configured for IAM policy changes and Logging and Monitoring 3.13: Ensure a notification is configured for changes to route tables has been improved to reduce false positives.
The CIS Compliance checking script now outputs an HTML summary report. The summary report includes additional information from the CIS OCI Benchmark v1.2 plus a link to the finding's CSV file.
The CIS Compliance checking script CSV reports have a new field deep_link which contains a clickable link to the resource in the OCI Console.
The CIS Compliance checking script check for Identity and Access Management 1.1: Ensure service level admins are created to manage resources of particular service has been improved to reduce false positives.
Service Connector Hub functionality has been improved with the following:
- Audit logs from all tenancy compartments are now captured.
- Support for Logging Analytics as target. With this update, the following targets are supported: Object Storage, Streaming, Functions and Logging Analytics.
Following updates were made regarding the CIS Level setting (cis_level variable):
- Setting cis_level variable to "2" is enough for OCI Vault creation. Previously, the OCI Vault creation would also require a bucket and no provided existing vault.
- Write logs for buckets are only created if cis_level variable is set to "2". Previously, bucket write logs were not impacted by CIS Level setting.
The CIS Compliance Checking script .cis_reports.py has had the following fixes:
- Fixed consolidated xlsx file generation on Windows command line and Powershell.
- Converted from positional arguments in OCI API calls to named arguments.
Fixed support for deploying terraform via Windows. Closes Issue.
The CIS Compliance Checking script .cis_reports.py has had the following enhancements:
-
CIS compliance checking script has added checking for OCI Best Practices (OBP). The following OCI Best Practices in your tenancy:
- Aggregation of OCI Audit compartment logs, Network Flow logs, and Object Storage logs are sent to Service Connector Hub in all regions
- A Budget for cost track is created in your tenancy
- Network connectivity to on-premises is redundant
- Cloud Guard is configured at the root compartment with detectors and responders
-
Redaction of OCIDs before data is written to CSVs using the
--redactflag. This uses a sha256 hashes of OCID to maintain OCID consistency across files. -
Reduced script runtime by synchronously reading OCI resources.
-
CSV files will be consolidated into a single XLSX file if the python3 environment has
xlsxwriterinstalled.
See compliance-script.md for usage.
Cloud Guard module has been updated with the following features:
- Cloud Guard resources creation made optional, based on enable_cloud_guard input variable. Cloud Guard is enabled by default.
- Support for cloned detector and responder recipes, based on enable_cloud_guard_cloned_recipes input variable. By default, for keeping backwards compatibility, the module uses Oracle managed recipes.
- Support for customer provided reporting region. If reporting region is not provided, the module defaults to home region.
- Resource Manager user interface reflects above changes.
See Cloud Guard variables for details.
- Arch Center tag module conditioned to Landing Zone not being extended. Fix in mon_tags.tf.
- CIS Compliance checking script was looking for attributes not available in list analytics and list integrations instances API calls.
- Compliance Checking Supports Custom OCI Config File Location
- Custom Security Zone policies support for all OCI realms
- Bug fixes
The Compliance checking script adds a new flag -c that takes the location of an OCI config file. This flag allows users to specify which OCI config file to use instead of using the one in the default location (~/.oci/config).
Custom Security Zone policies are now supported by CIS Landing Zone in all OCI realms where Custom Security Zones are available.
- Incorrect backups resource-type replaced by db-backups for database admin grants in iam_policies.tf.
- Event types fixed for Exadata Cloud Service in mon_notifications.tf.
Until this update, a user in the CIS Landing Zone Auditor group would not have been able to successfully run the compliance checking script in tenancies with Identity Domains. The reason is tenancies with Identity Domains require elevated privileges to check the tenancies password policy. With release 2.4.1 if the user doesn't have permissions to check password policy the script will continue running and just print an alert.
- Terraform Requirements
- CIS OCI Benchmark Configuration Profiles
- Custom Security Zones
- Service Connector Hub Improved Configuration
- Vulnerability Scanning Improved Configuration
- Application Bucket Improved Configuration
- Data Safe Permissions
The Terraform features in this release and future releases of the CIS Landing Zone will require Terraform binary 1.1.0 or higher, where the moved block feature is available. The moved block provides a transparent way for preserving backwards compatibility in face of required code changes. We have consolidated all moved blocks in moved.tf. For details on this feature, please see: Terraform's documentation on refactoring.
CIS Landing Zone introduces the ability to choose the CIS OCI configuration profile defined in the Benchmark.
When deploying CIS Landing Zone, users can now specify the CIS configuration profile level using the variable cis_level and it defines the configuration of some Landing Zone managed resources. For this release, the affected resources are Object Storage Buckets and Security Zones. The cis_level setting drives how buckets are encrypted and the minimum set of policies in a Security Zone.
CIS Landing Zone adds to the overall tenancy security posture with the support for Security Zones. Landing Zone users can now enable Security Zones for Landing Zone managed compartments and specify which policies to apply. These policies are the preventive controls that make sure a tenancy stays within the defined track as it evolves over time.
Aligning with the CIS OCI Benchmark Configuration Profile feature, if cis_level is set to 1, the provided Security Zone policies are aligned to the CIS OCI Benchmark configuration profile Level 1. If cis_level is set to 2, the provided Security Zone policies are aligned to the CIS OCI Benchmark configuration profile Level 2. Below are the Security Zone policies to configuration profile level.
| CIS Recommendation | CIS Level | Security Zone Policy Name | Security Zone Policy Description |
|---|---|---|---|
| 4.1.1 | 1 | deny public_buckets | Object Storage buckets in a security zone can't be public. |
| 2.8.0 | 1 | deny db_instance_public_access | Databases in a security zone can't be assigned to public subnets. They must use private subnets. |
| 4.2.1 | 2 | deny block_volume_without_vault_key | Block volumes in a security zone must use a customer-managed master encryption key in the Vault service. They can't use the default encryption key managed by Oracle. |
| 4.2.2 | 2 | deny boot_volume_without_vault_key | Boot volumes in a security zone must use a customer-managed master encryption key in the Vault service. They can't use the default encryption key managed by Oracle. |
| 4.1.2 | 2 | deny buckets_without_vault_key | Object Storage buckets in a security zone must use a customer-managed master encryption key in the Vault service. They can't use the default encryption key managed by Oracle. |
| 4.3.1 | 2 | deny file_system_without_vault_key | File systems in the security zone must use a customer-managed master encryption key in the Vault service. They can't use the default encryption key managed by Oracle. |
The Service Connector Hub module as announced in Updated Logging Architecture has been updated to optionally deploy Service Connector Hub related resources. As a result, existing users need to set enable_service_connector and activate_service_connector variables to true for Service Connector Hub resources to be created and to activate the service. For details, look at enable_service_connector and activate_service_connector variables in VARIABLES.md.
When deploying an Object Storage bucket as Service Connector target, users can now bring an existing key for bucket encryption. For details, look at existing_service_connector_bucket_vault_compartment_id, existing_service_connector_bucket_vault_id and existing_service_connector_bucket_key_id variables in VARIABLES.md. Aligning with the CIS Profile Levels feature, if cis_level is set to 1, the bucket is encrypted with an Oracle-managed key; if cis_level is set to 2, a customer-managed key (either provided or managed by Landing Zone) is used for bucket encryption.
Users have more control on Landing Zone Vulnerability Scanning recipes. It is now possible to specify the levels for port scan, agent-based scan and CIS setting for agent-based scans. Additionally, users can enable file scanning for Linux systems and specify the folders to scan. Variables are described in VARIABLES.md.
Vulnerability Scanning is now disabled by default in CIS Landing Zone. Moving forward, the intent is enabling by default only those services that are required by CIS Benchmark. Existing users who are managing Vulnerability Scanning resources with Landing Zone should simply enable it back, by setting vss_create variable to true.
A bug preventing Vulnerability Scanning target creation in default enclosing compartment has been fixed.
Previous to this release, CIS Landing Zone would manage a sample bucket in the Application compartment (a.k.a AppDev) and encrypt it with a customer-managed key. This has changed. Now the bucket creation is optional, and when deployed, the user has a choice to bring an existing key for encryption. Aligning with the CIS Profile Levels feature, if cis_level is set to 1, the bucket is encrypted with an Oracle-managed key; if cis_level is set to 2, a customer-managed key (either provided or managed by Landing Zone) is used for bucket encryption.
In the config directory, management permission for the Data Safe family has been added to the Database Administrators and Exadata Infrastructure Administrators groups. Read permission for the Data Safe family has been added to the Auditors group.
In the pre-config directory, read permission for the Data Safe family has been added to the Database Administrators and Auditors groups.
- Cloud Guard Events
- Updated Logging Architecture
- Terraform OCI Provider Moved to oracle/oci
- Architecture Center Tag
- CIS Compliance Checking Script Update
Cloud Guard events have been added to Landing Zone notifications framework. Now users can be notified about Cloud Guard problems that exceeds a user provided criticality threshold. To support this two new variables have been added to the Cloud Guard Section: cloud_guard_risk_level_threshold and cloud_guard_admin_email_endpoints. The risk_level_threshold determines what problems will trigger the event rule and send an email to the subscription in the new topic. A level of 'High' will include any problems with a risk level of High or above. This would include High and Critical problems. The event rule looks at any of the 3 Cloud Guard events: Problem Detected, Problem Dismissed and Problem Remediated.
The Service Connector Hub module has been updated to align with the best practice architecture for third-party SIEM tools. Now there is a single Landing Zone Service Connector that ingests three log sources (Audit logs, VCN flow logs and Object Storage logs) into a target resource of choice: Object Storage Bucket, Stream or Function. Landing Zone creates the Bucket and can either create the Stream or use an existing one. If a Function is the target, it must be provided as an input.
Landing Zone has been updated with the new home for Terraform OCI provider. It has moved to oracle/oci from hashicorp/oci.
-
Existing Landing Zone customers who use Terraform CLI are required to replace the provider in the state file. To update the state file, run the command below in the folder where the state file is present:
> terraform state replace-provider hashicorp/oci oracle/oci -
Existing Landing Zone customers who use OCI Resource Manager do not need to do anything, as Resource Manager will update the state file based on the new Landing Zone configuration.
As part of this move, we have introduced provider requirements expressed in provider.tf:
- Terraform required version >= 1.0.0
- OCI provider version >= 4.78.0
A defined tag to track Landing Zone deployments through OCI Architecture Center has been added.
The CIS Compliance checking script now consolidates regional output. There is a single directory which contains the summary report and findings reports in a directory, the name includes the tenancy name and datetime ex. <tenancy-name>-2022-MM-DD_HH-MM/. The findings CSV in that directory now have a region column to tell you which region the resource is located.
In addition two new flags have been added:
--region- pass an OCI region name(s) ex.--region us-ashburn-1,eu-frankfurt-1and the script will check that region's resources for CIS compliance--raw- will output all OCI resource data collected into CSV files with the OCI Service name
For more details on these flags compliance-script.md
- CIS Compliance Checking Script 1.2 update
- CIS 1.2 OCI IAM Policy Updates and Storage Admin
- Connectivity Section Usability Improvements in Resource Manager
- Removed Public RDP Access
The CIS reports script (cis_reports.py) has been updated to check a tenancy’s compliance with the CIS OCI Foundations Benchmark 1.2.0. In addition to the new compliance checks, we have streamlined the checks in non-home regions to exclude the IAM since it is redundant. We also added a new flag --level which allows you to run all the CIS OCI Foundations Benchmark 1.2 checks or only those checks associated with Level 1. The documentation for the CIS reports script has been updated to reflect this release.
You can learn about what was added to version 1.2 of the benchmark here.
We have introduced a group for storage management, entitled to delete OCI storage resources across Landing Zone compartments. The feature implements the recommendation 1.14 of CIS OCI Foundations Benchmark v1.2.0 that states Ensure storage service-level admins cannot delete resources they manage, ensuring segregation of duties from service-level administrators, who cannot delete resources they are managing.
Our recommendation for using this group is to place users in it when they must delete an OCI storage resource and then remove their access once that resource is deleted.
In addition we reviewed our policy for consistency.
The Connectivity variables group in schema.yml for OCI Resource Manager UI have been split for improved usability. Now we have separate sections for Hub/Spoke, Public Connectivity, Connectivity to on-premises and DRG. Some section titles and variables descriptions have also been updated.
We no longer grant RDP access to the bastion NSGs for public_src_bastion_cidrs CIDR addresses thus preventing public access to RDP.
- Configurable Cloud Guard Alerting
- Advanced Options Check Preservation in Resource Manager
- Notification Endpoints not Required by CIS Not Shown By Default
- ExaCS VCN Route Table Fix
Cloud Guard Alerting can optionally be configured by the Landing Zone. Two new variables have been added to the Cloud Guard Section: cloud_guard_risk_level_threshold and cloud_guard_admin_email_endpoints. A new topic and new Event rule will be created only if a valid Email Endpoint is provided. The risk_level_threshold determines what problems will trigger the event rule and send an email to the subscription in the new topic. A level of 'High' will include any problems with a risk level of High or above. This would include High and Critical problems. The event rule looks at any of the 3 Cloud Guard events: Problem Detected, Problem Dismissed and Problem Remediated.
CIS Landing Zone interface for Resource Manager has check boxes allowing for advanced input options, hiding or showing groups of variables. The state of these options used to be reset when users needed to update the variables in the UI, hiding options chosen previously. Now the state is saved and no longer reset. Changes made in config/variables.tf.
Except for Security and Network notifications, all other endpoints are no longer displayed by default in config/schema.yml for OCI Resource Manager. A new Additional Notification Endpoints check box displays them when checked.
A fix in the route table of the Client subnet allows for proper on-premises routing with or without a DMZ VCN. If a DMZ VCN is deployed, traffic to an on-premises IP address goes through the VCN. Otherwise, traffic goes to on-premises directly through the DRG.
- Cloud Guard policy has been simplified with Allow service cloudguard to read all-resources in tenancy. This way no policy changes are needed as new services are integrated with Cloud Guard.
- Cloud Guard enablement and target creation logic have been updated, but still based on cloud_guard_configuration_status variable. When the variable is set to 'ENABLE', Cloud Guard is enabled and a target is created for the Root compartment. Customers need to make sure there is no pre-existing Cloud Guard target for the Root compartment or target creation will fail. If there is a pre-existing Cloud Guard target for the Root compartment, set the variable to 'DISABLE'. In this case, any pre-existing Cloud Guard Root target is left intact. However, keep in mind that once you set the variable to 'ENABLE', Cloud Guard Root target becomes managed by Landing Zone. If later on you switch to 'DISABLE', Cloud Guard remains enabled but the Root target is deleted.
Policy update allowing Vulnerability Scanning Service (VSS) to scan containers in OCI Registry: Allow service vulnerability-scanning-service to read repos in tenancy.
An examples folder has been added showcasing input variables for the various deployment samples provided in the deployment guide. The examples follow Oracle documentation guidelines for acceptable company name.
A compreehensive deployment guide for CIS Landing Zone is now available. It covers key deployment considerations, the architecture, major deployment scenarios, customization guidance, detailed steps how to deploy using Terraform CLI and with Resource Manager UI/CLI as well as various deployment configuration samples.
IAM admin policy has been updated to not allow IAM administrators to manage compartments and policies at the Root compartment, thus avoiding privilege escalation.
- Configurable Spoke Subnet Names and Subnet Sizes
- Updated Compute Dynamic Group to support OS Management
- Fixed Internet Gateway Creation in ExaCS VCN
- Updated Bastion NSG to include RDP
- Tagging Support
The names and the size of subnets created in spoke VCN(s) can now be configured using the variables: subnets_names and subnets_sizes. Ex. ["front", "middle", "back"] and ["12","8","10"]. Additional customization of spoke VCNs can be done in net_vcn.tf or with using Terraform Override Files.
Check Known Issues section for an issue affecting custom subnets sizes in Resource Manager UI.
Added IAM policy statements to the compute agent dynamic group policy to include support for OS Management.
Disabled creation of Internet Gateway in ExaCS VCNs.
Added port 3389 to the Bastion Network Security Group (NSG) to support Remote Desktop Protocol (RDP) for Windows based instances.
The Landing Zone fully supports definition and usage of defined_tags and freeform_tags for all resources. In this release there is no additional variable to be set in the quickstart-input.tfvars. Tag definition and usage can be set using Terraform Override Files.
Usage Overview:
- Defined tags - At the moment, using Defined Tags is a two step process.
- Create the defined tags.
- Use the defined tags.
- Freeform tags - Freeform tags can be used at any time. You simply assign a map of freeform tags, to a predefined local variable in an override file, for example
all_keys_freeform_tags = {"cis-landing-zone" : "${var.service_label}-quickstart"}.
Please note that space characters (' ') in the tag names are not supported by OCI.
- Cross Region Landing Zone
- Bring Existing Dynamic Groups
- CCCS Guard Rails
- Landing Zone Logo
- Customized VCN and Subnet deployment option
When you run Landing Zone's Terraform, some resources are created in the home region, while others are created in a region of choice. Among home region resources are compartments, groups, dynamic groups, policies, tag defaults and an infrastructure for IAM related notifications (including events, topics and subscriptions). Among resources created in the region of choice are VCNs, Log Groups, and those pertaining to security services like Vault Service, Vulnerability Scanning, Service Connector Hub, Bastion. The home region resources are automatically made available by OCI in all subscribed regions.
Some customers want to extend their Landing Zone to more than one region of choice, while reusing the home region resources. One typical use case is setting up a second region of choice for disaster recovery, reusing the same home region Landing Zone resources. A more broad use case is implementing a single global Landing Zone across all subscribed regions. These use cases are now supported via the newly introduced extend_landing_zone_to_new_region. When set to true, compartments, groups, dynamic groups, policies and resources pertaining to home region are not provisioned, but reused instead.
As with groups, Landing Zone now supports reusing existing dynamic groups. These dynamic groups are thought to be used by OCI Functions, Compute's management agent and databases for calling out other services.
The Compliance Checking script's summary report now includes a column for CCCS Guard Rails.
Landing Zone has been gifted with a logo. A courtesy from our colleague Chris Johnson.
This release provides the option to easily customize your VCNs and Subnets in terms of cidr ranges and naming using a map resource called custom_vcns_map. Please note as part of this release we have also updated the default Database subnet to include a routing rule for sending traffic destined for 0.0.0.0/0 to the NAT Gateway. However the default Network Security Group will still prevent any egress to the internet until it is changed by you.
- Updated Topics and Subscription Module (Impacts existing deployments)
- Enablement of Operational Events and Alarms Specific to Compute, Storage, Database and Governance
- Compliance Checking Script Runs in All Regions
- Click to Deploy button
- Added SVG versions of Core Architecture Files
- Added an optional Budget and Budget Alert Rule
In previous versions of the Landing Zone Topics and Subscriptions were a single module. Going forward there will be a Topics Module and a Subscription Module. Due to this change upgrading an existing Landing Zone deployment will cause the Security Topic and Subscriptions as well as the Network Topic and Subscriptions to be deleted and recreated. This will require users receiving these email notifications to re-accept their subscriptions.
Customers can now deploy events and alarms specific to operational areas including Compute, Storage, Database and Governance as part of the default Landing Zone deployment. Operational alarms and events can be enabled by entering an email address in. This includes following alarms:
- AppDev Compartment
- Instance based monitoring and alerting of high cpu and high memory usage for instances deployed in the AppDev compartment.
- Bare metal unhealthy and VM maintenance alarms are also part of the new core compute alarm set.
- Database Compartment
- Databases deployed in the Database compartment operational events and alerts have been enabled for for high ADB CPU and high ADB Storage usage.
- Autonomous Database Critical Events and ExaData CS Infrastructure events are now tracked in this release.
- Network Compartment
- Up/Down status for VPN and FastConnect services in the Network compartment of the Landing Zone.
The compliance checking script now runs checks on all available regions in the tenancy and has improved handling of Oracle PSM policy statements.
Resource Manager stack can be created directly from GitHub repository through a single button click. The zip file with the source code is passed directly to Resource Manager Create Stack API.
Added SVG versions of Core Architecture Files so users can modify the architectures using Draw.io.
Customers can now choose to deploy a budget at the root or enclosing compartment level to track monthly spending and be alerted if a forcasted spending breaches a defined threshold.
A Cost Managment Admin group is also created that grants permission to Create,Update,Delete budgets and also review Cost Data in the UI or by downloading the detailed Cost Reports. Cost Data View Only permissions have been added to the policies for: Auditor, Database Admin, AppDev Admin, Network Admin and Security Admin allowing members of these groups to review spending.
CIS Compliance checking script will now prepend the OCI tenancy's display name to the output directory it creates if no directory is specified. An example output directory tenancy_display_name-20211013.
Now [OCI Bastion service] (https://docs.oracle.com/en-us/iaas/Content/Bastion/Concepts/bastionoverview.htm) is enabled when one or more public_src_bastion_cidrs are provided and a single VCN deployment is selected. In the previous version it was enabled by default in a single VCN deployment.
- Ability to Provision Infrastructure for Exadata Cloud Service Deployments
- OCI Bastion Service Integration
- Individual Security Lists for Subnets
- Ability to Rename Compartments
- Updates to NSGs and Route Rules Descriptions
- Input Variable for SSH Connectivity from On-premises Network
- Updates to Resource Manager Interface
Landing Zone can now provision VCNs, compartment, group and policies for Exadata Cloud Service (ExaCS) deployments. The provisioned resources are deployed in tandem with the overall Landing Zone configuration. VCNs are provisioned with client and backup subnets. If a Hub & Spoke network architecture is being deployed, the ExaCS VCNs are configured as spoke VCNs. A compartment is by default created for the ExaCS infrastructure and an extra group and policies are configured accordingly. Optionally, users may opt for deploying ExaCS infrastructure in the database compartment with appropriate permissions granted to database administrators.
Customers can now leverage OCI Bastion Service in Landing Zone. A Bastion resource is provisioned into a VCN if a single VCN or a single ExaCS VCN is being deployed. Customers can later on create a Bastion session using the provisioned Bastion resource. The Bastion resource is not provisioned for Hub & Spoke architecture or if the Landing Zone VCNs are connected to an on-premises network. In these cases, SSH inbound access is expected to be provided by Bastion servers in the DMZ (Hub) or hosts in the on-premises network.
Individual security lists are now created for all subnets. This is useful for customers planning on deploying services that require Security Lists instead of Network Security Groups.
Landing Zone creates compartments with auto-generated names, prefixed by the service_label variable value. Landing Zone compartments can be renamed at any point in time with all policies adjusted accordingly.
The descriptions of rules in NSGs and route tables have been updated aiming at more clarity and verbiage standardization.
Variable onprem_src_ssh_cidrs is introduced. It is a list of on-premises CIDR blocks allowed to connect to Landing Zone over SSH. It is added to network security rules for ingress connectivity to Landing Zone networks. The on_prem_ssh_cidrs must be a subset of the onprem_cidrs variable, which are used for routing between on-premises and Landing Zone networks.
With the introduction of Exadata Cloud Service support, Landing Zone schema.yaml has been updated for better usability in OCI Resource Manager. A new variable group named 'Connectivity' has been introduced, containing variables for defining properties that control the sources and destinations for Landing Zone connectivity.
- Ability to use existing Dynamic Routing Gateway (DRG) v2 with the Landing Zone
- Consolidated Network and IAM Notifications
- Database Customer Managed Key Support
- Compliance Checking supports free tier tenancy
Customers that have an existing DRG v2 (a DRG created after April 15, 2021) can now use that existing DRG v2 instead of having the Landing Zone create a new DRG v2. This is useful for customers that have connected a FastConnect to an existing DRG.
In previous versions of the Landing Zone notification event rules were created for each CIS benchmark monitoring recommendation. To help reduce the number of event rules created all the IAM recommendations are combined into a single event rule and all the network recommendations are combined into another event rule.
Database Administrators now have the ability to use keys from OCI Vaults in the security compartment to encrypt databases in the database compartment.
Compliance Checking script can now be run free tier OCI tenancy.
- Ability to provision the Landing Zone with narrower permissions
- Ability to provision Landing Zone within an enclosing compartment at any level in the compartment hierarchy
- Ability to reuse existing groups when provisioning the Landing Zone
- Hub and Spoke Network Architecture plus networking enhancements
Before this release, the Landing Zone required a user with wide permissions in the tenancy in order to be provisioned. Typically, but not necessarily, this user was a member of the Administrators group. That has changed. Now the Landing Zone can be provisioned by a user with narrower permissions. However, some pre-requisites need to be satisfied. Specifically, the Landing Zone requires policies created at the tenancy level and broad permissions at the compartment where it is going to be provisioned.
The Landing Zone handles these requirements with a new Terraform root module that's expected to be executed by a user with wide permissions (typically a member of the Administrators group). The module is available in the pre-config folder and provisions the following:
- An enclosing compartment for the Landing Zone compartments.
- Optionally, a group with the required permissions to provision the Landing Zone in the enclosing compartment.
- Optionally, Landing Zone required groups for segregation of duties. These groups can then simply be reused when provisioning the Landing Zone.
- Optionally, required permissions at the tenancy level granted to Landing Zone groups, like permissions granted to Security and IAM administrators.
The variables controlling the pre-config module behavior are described in Pre-Config Module Variables section.
2. Ability to provision Landing Zone within an enclosing compartment at any level in the compartment hierarchy
This can be done by a wide-permissioned user or a narrower-permissioned user. If done by the wide-permissioned user, the steps described in the previous section MUST be skipped. If done by a narrower-permissioned user, the steps in the previous section are required. A narrower-permissioned user is only allowed to provision the Landing Zone in a enclosing compartment previously designated by a wide-permissioned user.
The existing Landing Zone config module has been extended to support this use case. The module keeps backwards compatibility, i.e., the new variables default values keeps the module current behavior unchanged. In other words, if you execute the config module as-is, the four Landing Zone compartments are created directly under the root compartment with all policies created at the root compartment.
The module behavior is controlled by variables described in the Enclosing Compartment Variables section.
Previously, every Landing Zone execution would create groups. However, it's acknowledged that a customer may want to create multiple Landing Zones but only one set of groups, reusing them across the Landing Zones.
The module behavior is controlled by variables described in the Existing Groups Reuse Variables section.
Before this release, the Landing Zone would deploy a single VCN with three subnets designed for a 3-tier application with DRG if on-premises connectivity was required. In this new release we enhanced the networking and network security modules to can support the creation of multiple VCNs (spokes or stand-alone) and the following Hub and Spoke network architectures:
- Access to multiple VCNs in the same region: This scenario enables communication between an on-premises network and multiple VCNs in the same region over a single FastConnect private virtual circuit or Site-to-Site VPN and uses a DRG as the hub.
- Access between multiple networks through a single DRG with a firewall between networks: This scenario connects several VCNs to a single DRG, with all routing configured to send packets through a firewall in a hub VCN before they can be sent to another network.
In addition to the above architectures, you can choose if want to allow the creation of Internet Gateways and NAT Gateways to provide a more isolated network. Lastly, we have also added support for various network variables to take lists of CIDR ranges instead of a single CIDR.
The module behavior is controlled by variables described in the Networking Variables section.
The Landing Zone enables/collects logs for a few services, like VCN and Audit services. From a governance perspective, it's interesting that these logs get consolidated and made available to security management tools. This capability is now availabe in the Landing Zone with the Service Connector Hub, that reads logs from different sources and sends them to a target that the user chooses. By default, this target is a bucket in the Object Storage service, but functions and streams can also be configured as targets. As the usage of a bucket, function or stream may incur in costs to our customers, Landing Zone users must explicitly activate Service Connector Hub by setting variables in the Terraform configuration, as described in Logging Variables section.
To delete or change a Service Connector that has an Object Storage bucket as a target, you must manually remove the target from the Service Connector and manually delete the bucket. A bucket with objects cannot be deleted via Terraform.
The Landing Zone now enables scanning through the Vulnerability Scanning Service (VSS), creating a scan recipe and scan targets by default. The recipe is set to run every week on sundays and the targets are set to all four Landing Zone compartments. Running the Landing Zone as is, weekly scans are automatically executed for any instances deployed in any of the Landing Zone compartments. The scan results are made available in the Security compartment and can be verified in the OCI Console.
Scanning can be disabled in the Landing Zone, and the scan frequency and targets can be changed as well. Disabling scanning and changing the frequency are controlled by setting variables in the Terraform configuration, as described in Scanning Variables section, while targets can be changed in the vss.tf file. The Vulnerability Scanning Service is free.