CIS Oracle Cloud Infrastructure Foundations Benchmark v3.1.0

Level 1

1. Identity and Access Management

To apply least-privilege security principle, one can create service-level administrators in corresponding groups and assigning specific users to each service-level administrative group in a tenancy. This limits administrative access in a tenancy. It means service-level administrators can only manage resources of a specific service.Example policies for global/tenant level service-administratorsAllow group VolumeAdmins to manage volume-family in tenancyAllow group ComputeAdmins to manage instance-family in tenancyAllow group NetworkAdmins to manage virtual-network-family in tenancy``````A tenancy with identity domains : An Identity Domain is a container of users, groups, Apps and other security configurations. A tenancy that has Identity Domains available comes seeded with a 'Default' identity domain. If a group belongs to a domain different than the default domain, use a domain prefix in the policy statements.Example - Allow group <identity_domain_name>/<group_name> to <verb> <resource-type> in compartment <compartment_name>If you do not include the <identity_domain_name> before the <group_name>, then the policy statement is evaluated as though the group belongs to the default identity domain.Organizations have various ways of defining service-administrators. Some may prefer creating service administrators at a tenant level and some per department or per project or even per application environment ( dev/test/production etc.). Either approach works so long as the policies are written to limit access given to the service-administrators. Example policies for compartment level service-administrators Allow group NonProdComputeAdmins to manage instance-family in compartment devAllow group ProdComputeAdmins to manage instance-family in compartment productionAllow group A-Admins to manage instance-family in compartment Project-AAllow group A-Admins to manage volume-family in compartment Project-A``````A tenancy with identity domains : An Identity Domain is a container of users, groups, Apps and other security configurations. A tenancy that has Identity Domains available comes seeded with a 'Default' identity domain. If a group belongs to a domain different than the default domain, use a domain prefix in the policy statements.Example - Allow group <identity_domain_name>/<group_name> to <verb> <resource-type> in compartment <compartment_name>If you do not include the <identity_domain_name> before the <group_name>, then the policy statement is evaluated as though the group belongs to the default identity domain.

***From CLI:***1) Set up OCI CLI with an IAM administrator user who has read access to IAM resources such as groups and policies.2) Run OCI CLI command providing the root_compartment_OCIDGet the list of groups in a tenancyoci iam group list --compartment-id <root_compartment_OCID> | grep name``````A tenancy with identity domains : The above CLI commands work with the default identity domain only.For IaaS resource management, users and groups created in the default domain are sufficient. 3) Ensure distinct administrative groups are created as per your organization's definition of service-administrators.4) Verify the appropriate policies are created for the service-administrators groups to have the right access to the corresponding services. Retrieve the policy statements scoped at the tenancy level and/or per compartment. oci iam policy list --compartment-id <root_compartment_OCID> | grep in tenancyoci iam policy list --compartment-id <root_compartment_OCID> | grep in compartmentThe --compartment-id parameter can be changed to a child compartment to get policies associated with child compartments.oci iam policy list --compartment-id <child_compartment_OCID> | grep in compartmentVerify the results to ensure the right policies are created for service-administrators to have the necessary access.

Manual

Creating service-level administrators helps in tightly controlling access to Oracle Cloud Infrastructure (OCI) services to implement the least-privileged security principle.

Refer to the policy syntax document and create new policies if the audit results indicate that the required policies are missing.This can be done via OCI console or OCI CLI/SDK or API.Creating a new policy:From CLI:oci iam policy create [OPTIONS]Creates a new policy in the specified compartment (either the tenancy or another of your compartments). If you're new to policies, see Getting Started with Policies You must specify a name for the policy, which must be unique across all policies in your tenancy and cannot be changed.You must also specify a description for the policy (although it can be an empty string). It does not have to be unique, and you can change it anytime with UpdatePolicy.You must specify one or more policy statements in the statements array.For information about writing policies, see How Policies Work and Common Policies.

Level 1

1. Identity and Access Management

There is a built-in OCI IAM policy enabling the Administrators group to perform any action within a tenancy. In the OCI IAM console, this policy reads:Allow group Administrators to manage all-resources in tenancyAdministrators create more users, groups, and policies to provide appropriate access to other groups.Administrators should not allow any-other-group full access to the tenancy by writing a policy like this - Allow group any-other-group to manage all-resources in tenancyThe access should be narrowed down to ensure the least-privileged principle is applied.

**From CLI:**1) Run OCI CLI command providing the root compartment OCID to get the list of groups having access to manage all resources in your tenancy. oci iam policy list --compartment-id <root_compartment_OCID> | grep -i to manage all-resources in tenancy 2) Verify the results to ensure only the Administrators group has access to manage all resources in tenancy. Allow group Administrators to manage all-resources in tenancy

Automated

Permission to manage all resources in a tenancy should be limited to a small number of users in the Administrators group for break-glass situations and to set up users/groups/policies when a tenancy is created.No group other than Administrators in a tenancy should need access to all resources in a tenancy, as this violates the enforcement of the least privilege principle.

**From Console:**1) Login to OCI console.2) Go to Identity -> Policies, In the compartment dropdown, choose the root compartment. Open each policy to view the policy statements. 2) Remove any policy statement that allows any group other than Administrators or any service access to manage all resources in the tenancy. **From CLI:**The policies can also be updated via OCI CLI, SDK and API, with an example of the CLI commands below: * Delete a policy via the CLI: oci iam policy delete --policy-id <policy-ocid> * Update a policy via the CLI: oci iam policy update --policy-id <policy-ocid> --statements <json-array-of-statements>Note: You should generally not delete the policy that allows the Administrators group the ability to manage all resources in the tenancy.

Level 1

1. Identity and Access Management

Tenancy administrators can create more users, groups, and policies to provide other service administrators access to OCI resources.For example, an IAM administrator will need to have access to manage resources like compartments, users, groups, dynamic-groups, policies, identity-providers, tenancy tag-namespaces, tag-definitions in the tenancy.The policy that gives IAM-Administrators or any other group full access to 'groups' resources should not allow access to the tenancy 'Administrators' group.The policy statements would look like -Allow group IAMAdmins to inspect users in tenancyAllow group IAMAdmins to use users in tenancy where target.group.name != 'Administrators'Allow group IAMAdmins to inspect groups in tenancyAllow group IAMAdmins to use groups in tenancy where target.group.name != 'Administrators'Note: You must include separate statements for 'inspect' access, because the target.group.name variable is not used by the ListUsers and ListGroups operations

**From CLI:**1) Run the following OCI CLI commands providing the root_compartment_OCID oci iam policy list --compartment-id <root_compartment_OCID> | grep -i to use users in tenancyoci iam policy list --compartment-id <root_compartment_OCID> | grep -i to use groups in tenancy2) Verify the results to ensure that the policy statements that grant access to use or manage users or groups in the tenancy have a condition that excludes access to Administrators group or to users in the Administrators group.

Automated

These policy statements ensure that no other group can manage tenancy administrator users or the membership to the 'Administrators' group thereby gain or remove tenancy administrator access.

**From Console:**1. Login to OCI Console.2. Select Identity from Services Menu.3. Select Policies from Identity Menu.4. Click on an individual policy under the Name heading.5. Ensure Policy statements look like this -Allow group IAMAdmins to use users in tenancy where target.group.name != 'Administrators'Allow group IAMAdmins to use groups in tenancy where target.group.name != 'Administrators'

Level 1

1. Identity and Access Management

Password policies are used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are at least a certain length and are composed of certain characters. It is recommended the password policy require a minimum password length 14 characters and contain 1 non-alphabeticcharacter (Number or “Special Character”).

1. Go to Identity Domains: https://cloud.oracle.com/identity/domains/1. Select the Compartment your Domain to review is in1. Click on the Domain to review1. Click on Settings1. Click on Password policy1. Click each Password policy in the domain1. Ensure Password length (minimum) is greater than or equal to 141. Under The The following criteria apply to passwords section, ensure that the number given in Numeric (minimum) setting is 1, or the Special (minimum) setting is 1.The following criteria apply to passwords:6. Ensure that 1 or more is selected for Numeric (minimum) OR Special (minimum)**From Cloud Guard:**To Enable Cloud Guard Auditing:Ensure Cloud Guard is enabled in the root compartment of the tenancy. For more information about enabling Cloud Guard, please look at the instructions included in Ensure Cloud Guard is enabled in the root compartment of the tenancy Recommendation in the Logging and Monitoring section. **From Console:**1. Type Cloud Guard into the Search box at the top of the Console.2. Click Cloud Guard from the “Services” submenu.3. Click Detector Recipes in the Cloud Guard menu.4. Click OCI Configuration Detector Recipe (Oracle Managed) under the Recipe Name column.5. Find Password policy does not meet complexity requirements in the Detector Rules column.6. Select the vertical ellipsis icon and chose Edit on the Password policy does not meet complexity requirements row.7. In the Edit Detector Rule window, find the Input Setting box and verify/change the Required password length setting to 14.8. Click the Save button.**From CLI:**1. Update the Password policy does not meet complexity requirements Detector Rule in Cloud Guard to generate Problems if IAM password policy isn’t configured to enforce a password length of at least 14 characters with the following command:oci cloud-guard detector-recipe-detector-rule update --detector-recipe-id <insert detector recipe ocid> --detector-rule-id PASSWORD_POLICY_NOT_COMPLEX --details '{configurations:[{ configKey : passwordPolicyMinLength, name : Required password length, value : 14, dataType : null, values : null }]}'

Automated

In keeping with the overall goal of having users create a password that is not overly weak, an eight-character minimum password length is recommended for an MFA account, and 14 characters for a password only account. In addition, maximum password length should be made as long as possible based on system/software capabilities and not restricted by policy.In general, it is true that longer passwords are better (harder to crack), but it is also true that forced password length requirements can cause user behavior that is predictable and undesirable. For example, requiring users to have a minimum 16-character password may cause them to choose repeating patterns like fourfourfourfour or passwordpassword that meet the requirement but aren’t hard to guess. Additionally, length requirements increase the chances that users will adopt other insecure practices, like writing them down, re-using them or storing them unencrypted in their documents. Password composition requirements are a poor defense against guessing attacks. Forcing users to choose some combination of upper-case, lower-case, numbers, and special characters has a negative impact. It places an extra burden on users and manywill use predictable patterns (for example, a capital letter in the first position, followed by lowercase letters, then one or two numbers, and a “special character” at the end). Attackers know this, so dictionary attacks will often contain these common patterns and use the most common substitutions like, $ for s, @ for a, 1 for l, 0 for o.Passwords that are too complex in nature make it harder for users to remember, leading to bad practices. In addition, composition requirements provide no defense against common attack types such as social engineering or insecure storage of passwords.

1. Go to Identity Domains: https://cloud.oracle.com/identity/domains/1. Select the Compartment the Domain to remediate is in1. Click on the Domain to remediate1. Click on Settings1. Click on Password policy to remediate1. Click Edit password rules1. Update the Password length (minimum) setting to 14 or greater6. Under The Passwords must meet the following character requirements section, update the number given in Special (minimum) setting to 1 or greateror Under The Passwords must meet the following character requirements section, update the number given in Numeric (minimum) setting to 1 or greater7. Click Save changes

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

IAM password policies can require passwords to be rotated or expired after a given number of days. It is recommended that the password policy expire passwords after 365 and are changed immediately based on events.

1. Go to Identity Domains: https://cloud.oracle.com/identity/domains/1. Select the Compartment your Domain to review is in1. Click on the Domain to review1. Click on Settings1. Click on Password policy1. Click each Password policy in the domain1. Ensure Expires after (days) is less than or equal to 365 days

Manual

Excessive password expiration requirements do more harm than good, because these requirements make users select predictable passwords, composed of sequential words and numbers that are closely related to each other. In these cases, the next password can be predicted based on the previous one (incrementing a number used in the password for example). Also, password expiration requirements offer no containment benefits because attackers will often use credentials as soon as they compromise them. Instead, immediate password changes should be based on key events including, but notlimited to:1. Indication of compromise1. Change of user roles1. When a user leaves the organization.Not only does changing passwords every few weeks or months frustrate the user, it's been suggested that it does more harm than good, because it could lead to bad practices by the user such as adding a character to the end of their existing password.In addition, we also recommend a yearly password change. This is primarily because for all their good intentions users will share credentials across accounts. Therefore, even if a breach is publicly identified, the user may not see this notification, or forget they have an account on that site. This could leave a shared credential vulnerable indefinitely. Having an organizational policy of a 1-year (annual) password expiration is a reasonable compromise to mitigate this with minimal user burden.

1. Go to Identity Domains: https://cloud.oracle.com/identity/domains/1. Select the Compartment the Domain to remediate is in1. Click on the Domain to remediate1. Click on Settings1. Click on Password policy to remediate1. Click Edit password rules1. Change Expires after (days) to 365

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

IAM password policies can prevent the reuse of a given password by the same user. It is recommended the password policy prevent the reuse of passwords.

1. Go to Identity Domains: https://cloud.oracle.com/identity/domains/1. Select the Compartment your Domain to review is in1. Click on the Domain to review1. Click on Settings1. Click on Password policy1. Click each Password policy in the domain1. Ensure Previous passwords remembered is set 24 or greater

Manual

Enforcing password history ensures that passwords are not reused in for a certain period of time by the same user. If a user is not allowed to use last 24 passwords, that window of time is greater. This helps maintain the effectiveness of password security.

1. Go to Identity Domains: https://cloud.oracle.com/identity/domains/1. Select the Compartment the Domain to remediate is in1. Click on the Domain to remediate1. Click on Settings1. Click on Password policy to remediate1. Click Edit password rules1. Update the number of remembered passwords in Previous passwords remembered setting to 24 or greater.

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

Multi-factor authentication is a method of authentication that requires the use of more than one factor to verify a user’s identity.With MFA enabled in the IAM service, when a user signs in to Oracle Cloud Infrastructure, they are prompted for their user name and password, which is the first factor (something that they know). The user is then prompted to provide a verification code from a registered MFA device, which is the second factor (something that they have). The two factors work together, requiring an extra layer of security to verify the user’s identity and complete the sign-in process.OCI IAM supports two-factor authentication using a password (first factor) and a device that can generate a time-based one-time password (TOTP) (second factor).See OCI documentation for more details.

**From Console:1. Go to Identity Domains: https://cloud.oracle.com/identity/domains/1. Select the Compartment your Domain to review is in1. Click on the Domain to review1. Click on Security1. Click Sign-on policies 1. Select the sign-on policy to review6. Under the sign-on rules header, click the three dots on the rule with the highest priority.7. Select Edit sign-on rule8. Verify that allow access is selected and prompt for an additional factor is enabled This requires users to enable MFA when they next login next however, to determine users have enabled MFA use the below CLI.From the CLI: This CLI command checks which users have enabled MFA for their accounts1. Execute the below:tenancy_ocid=`oci iam compartment list --raw-output --query data[?contains(\compartment-id\,'.tenancy.')].\compartment-id\ | [0]`for id_domain_url in `oci iam domain list --compartment-id $tenancy_ocid --all | jq -r '.data[] | .url'`do oci identity-domains users list --endpoint $id_domain_url 2>/dev/null | jq -r '.data.resources[] | select(.urn-ietf-params-scim-schemas-oracle-idcs-extension-mfa-user.mfa-status!=ENROLLED)' 2>/dev/null | jq -r '.ocid'donefor region in `oci iam region-subscription list | jq -r '.data[] | .region-name'`; do for compid in `oci iam compartment list --compartment-id-in-subtree TRUE --all 2>/dev/null | jq -r '.data[] | .id'` do for id_domain_url in `oci iam domain list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | .url'` do oci identity-domains users list --endpoint $id_domain_url 2>/dev/null | jq -r '.data.resources[] | select(.urn-ietf-params-scim-schemas-oracle-idcs-extension-mfa-user.mfa-status!=ENROLLED)' 2>/dev/null | jq -r '.ocid' done done done2. Ensure no results are returned

Automated

Multi factor authentication adds an extra layer of security during the login process and makes it harder for unauthorized users to gain access to OCI resources.

Each user must enable MFA for themselves using a device they will have access to every time they sign in. An administrator cannot enable MFA for another user but can enforce MFA by identifying the list of non-complaint users, notifying them or disabling access by resetting the password for non-complaint accounts.**Disabling access from Console:**1. Go to https://cloud.oracle.com/identity/.1. Select Domains from Identity menu.1. Select the domain1. Click Security1. Click Sign-on polices then the Default Sign-on Policy1. Under the sign-on rules header, click the three dots on the rule with the highest priority.1. Select Edit sign-on rule1. Make a change to ensure that allow access is selected and prompt for an additional factor is enabled

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

API keys are used by administrators, developers, services and scripts for accessing OCI APIs directly or via SDKs/OCI CLI to search, create, update or delete OCI resources.The API key is an RSA key pair. The private key is used for signing the API requests and the public key is associated with a local or synchronized user's profile.

**From Console:**1. Login to OCI Console.2. Select Identity & Security from the Services menu.3. Select Domains from the Identity menu.4. For each domain listed, click on the name and select Users.5. Click on an individual user under the Name heading.6. Click on API Keys in the lower left-hand corner of the page.7. Ensure the date of the API key under the Created column of the API Key is no more than 90 days old.

Automated

It is important to secure and rotate an API key every 90 days or less as it provides the same level of access that a user it is associated with has.In addition to a security engineering best practice, this is also a compliance requirement. For example, PCI-DSS Section 3.6.4 states, Verify that key-management procedures include a defined cryptoperiod for each key type in use and define a process for key changes at the end of the defined crypto period(s).

**From Console:**1. Login to OCI Console.2. Select Identity & Security from the Services menu.3. Select Domains from the Identity menu.4. For each domain listed, click on the name and select Users.5. Click on an individual user under the Name heading.6. Click on API Keys in the lower left-hand corner of the page.7. Delete any API Keys that are older than 90 days under the Created column of the API Key table.From CLI:oci iam user api-key delete --user-id _<user_ocid>_ --fingerprint <fingerprint_of_the_key_to_be_deleted>

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

Object Storage provides an API to enable interoperability with Amazon S3. To use this Amazon S3 Compatibility API, you need to generate the signing key required to authenticate with Amazon S3.This special signing key is an Access Key/Secret Key pair. Oracle generates the Customer Secret key to pair with the Access Key.

**From Console:**1. Login to OCI Console.1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. For each domain listed, click on the name and select Users.1. Click on an individual user under the Username heading.1. Click on Customer Secret Keys in the lower left-hand corner of the page.1. Ensure the date of the Customer Secret Key under the Created column of the Customer Secret Key is no more than 90 days old.

Automated

It is important to rotate customer secret keys at least every 90 days, as they provide the same level of object storage access that the user they are associated with has.

**From Console:**1. Login to OCI Console.1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. For each domain listed, click on the name and select Users.1. Click on an individual user under the Username heading.1. Click on Customer Secret Keys in the lower left-hand corner of the page.1. Delete any Access Keys with a date older than 90 days under the Created column of the Customer Secret Keys.

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

Auth tokens are authentication tokens generated by Oracle. You use auth tokens to authenticate with APIs that do not support the Oracle Cloud Infrastructure signature-based authentication. If the service requires an auth token, the service-specific documentation instructs you to generate one and how to use it.

**From Console:**1. Login to OCI Console.1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. For each domain listed, click on the name and select Users.1. Click on an individual user under the Username heading.5. Click on Auth Tokens in the lower left-hand corner of the page.1. Ensure the date of the Auth Token under the Created column of the Customer Secret Key is no more than 90 days old.

Automated

It is important to secure and rotate an auth token every 90 days or less as it provides the same level of access to APIs that do not support the OCI signature-based authentication as the user associated to it.

**From Console:**1. Login to OCI Console.1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. For each domain listed, click on the name and select Users.1. Click on an individual user under the Username heading.1. Click on Auth Tokens in the lower left-hand corner of the page.1. Delete any auth token with a date older than 90 days under the Created column of the Customer Secret Keys.

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

Users can create and manage their database password in their IAM user profile and use that password to authenticate to databases in their tenancy. An IAM database password is a different password than an OCI Console password. Setting an IAM database password allows an authorized IAM user to sign in to one or more Autonomous Databases in their tenancy.An IAM database password is a different password than an OCI Console password. Setting an IAM database password allows an authorized IAM user to sign in to one or more Autonomous Databases in their tenancy.

**From Console:**1. Login to OCI Console.2. Select Identity & Security from the Services menu.3. Select Users from the Identity menu.4. Click on an individual user under the Name heading.5. Click on Database Passwords in the lower left-hand corner of the page.6. Ensure the date of the Database Passwords under the Created column of the Database Passwords is no more than 90 days **From Console:**1. Login to OCI Console.1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. For each domain listed, click on the name and select Users.1. Click on an individual user under the Username heading.1. Click on Database Passwords in the lower left-hand corner of the page.1. Ensure the date of the Database Passwords under the Created column of the Database Password is no more than 90 days old.

Manual

It is important to secure and rotate an IAM Database password 90 days or less as it provides the same access the user would have a using a local database user.

OCI IAM with Identity Domains**From Console:**1. Login to OCI Console.1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. For each domain listed, click on the name and select Users.1. Click on an individual user under the Username heading.1. Click on IAM Database Passwords in the lower left-hand corner of the page.1. Delete any Database Passwords with a date older than 90 days under the Created column of the Database Passwords.

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

Tenancy administrator users have full access to the organization's OCI tenancy. API keys associated with user accounts are used for invoking the OCI APIs via custom programs or clients like CLI/SDKs. The clients are typically used for performing day-to-day operations and should never require full tenancy access. Service-level administrative users with API keys should be used instead.

**From Console:**1. Login to OCI Console. 1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. Click on the 'Default' Domain in the (root).1. Click on 'Groups'.1. Select the 'Administrators' group by clicking on the Name1. Click on each local or synchronized Administrators member profile4. Click on API Keys to verify if a user has an API key associated.

Automated

For performing day-to-day operations tenancy administrator access is not needed.Service-level administrative users with API keys should be used to apply privileged security principle.

**From Console:**1. Login to OCI console.2. Select Identity from Services menu.3. Select Users from Identity menu, or select Domains, select a domain, and select Users.4. Select the username of a tenancy administrator user with an API key.5. Select API Keys from the menu in the lower left-hand corner.6. Delete any associated keys from the API Keys table.7. Repeat steps 3-6 for all tenancy administrator users with an API key.**From CLI:**1. For each tenancy administrator user with an API key, execute the following command to retrieve API key details:oci iam user api-key list --user-id <user_id>2. For each API key, execute the following command to delete the key:oci iam user api-key delete --user-id <user_id> --fingerprint <api_key_fingerprint>3. The following message will be displayed:Are you sure you want to delete this resource? [y/N]:4. Type 'y' and press 'Enter'.

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

All OCI IAM local user accounts have an email address field associated with the account. It is recommended to specify an email address that is valid and current.If you have an email address in your user profile, you can use the Forgot Password link on the sign on page to have a temporary password sent to you.

**From Console:**1. Login to OCI Console.1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. For each domain listed, click on the name and select Users.1. Click on an individual user under the Username heading.1. Ensure a valid and current email address is next to Email and Recovery email.

Manual

Having a valid and current email address associated with an OCI IAM local user account allows you to tie the account to identity in your organization. It also allows that user to reset their password if it is forgotten or lost.

**From Console:**1. Login to OCI Console.1. Select Identity & Security from the Services menu.1. Select Domains from the Identity menu.1. For each domain listed, click on the name and select Users.1. Click on each non-complaint user.1. Click on Edit User.1. Enter a valid and current email address in the Email and Recovery Email text boxes.1. Click Save Changes

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 1

1. Identity and Access Management

OCI instances, OCI database and OCI functions can access other OCI resources either via an OCI API key associated to a user or via Instance Principal. Instance Principal authentication can be achieved by inclusion in a Dynamic Group that has an IAM policy granting it the required access or using an OCI IAM policy that has request.principal added to the where clause. Access to OCI Resources refers to making API calls to another OCI resource like Object Storage, OCI Vaults, etc.

**From Console (Dynamic Groups):**1. Go to https://cloud.oracle.com/identity/domains/1. Select a Compartment1. Click on a Domain1. Click on Dynamic groups1. Click on the Dynamic Group1. Check if the Matching Rules includes the instances accessing your OCI resources.**From Console (request.principal):**1. Go to https://cloud.oracle.com/identity/policies1. Select a Compartment1. Click on an individual policy under the Name heading.1. Ensure Policy statements look like this :allow any-user to <verb> <resource> in compartment <compartment-name> where ALL {request.principal.type='<resource_type>', request.principal.id='<resource_ocid>'}orallow any-user to <verb> <resource> in compartment <compartment-name> where ALL {request.principal.type='<resource_type>', request.principal.compartment.id='<compartment_OCID>'}**From CLI (request.principal):**1. Execute the following for each compartment_OCID: oci iam policy list --compartment-id <compartment_OCID> | grep request.principal1. Ensure that the condition includes the instances accessing your OCI resources

For an OCI instance that contains embedded credential audit the scripts and environment variables to ensure that none of them contain OCI API Keys or credentials.

Manual

Instance Principal reduces the risks related to hard-coded credentials. Hard-coded API keys can be shared and require rotation, which can open them up to being compromised. Compromised credentials could allow access to OCI services outside of the expected radius.

**From Console (Dynamic Groups):**1. Go to https://cloud.oracle.com/identity/domains/1. Select a Compartment1. Click on the Domain1. Click on Dynamic groups1. Click Create Dynamic Group.1. Enter a Name1. Enter a Description1. Enter Matching Rules to that includes the instances accessing your OCI resources.1. Click Create.

The Audit Procedure and Remediation Procedure for OCI IAM without Identity Domains can be found in the CIS OCI Foundation Benchmark 2.0.0 under the respective recommendations.

Level 2

1. Identity and Access Management

To apply the separation of duties security principle, one can restrict service-level administrators from being able to delete resources they are managing. It means service-level administrators can only manage resources of a specific service but not delete resources for that specific service.Example policies for global/tenant level for block volume service-administrators:Allow group VolumeUsers to manage volumes in tenancy where request.permission!='VOLUME_DELETE' Allow group VolumeUsers to manage volume-backups in tenancy where request.permission!='VOLUME_BACKUP_DELETE'Example policies for global/tenant level for file storage system service-administrators:Allow group FileUsers to manage file-systems in tenancy where request.permission!='FILE_SYSTEM_DELETE'Allow group FileUsers to manage mount-targets in tenancy where request.permission!='MOUNT_TARGET_DELETE'Allow group FileUsers to manage export-sets in tenancy where request.permission!='EXPORT_SET_DELETE'Example policies for global/tenant level for object storage system service-administrators:Allow group BucketUsers to manage objects in tenancy where request.permission!='OBJECT_DELETE' Allow group BucketUsers to manage buckets in tenancy where request.permission!='BUCKET_DELETE'

**From Console:**1. Login to OCI console.2. Go to Identity -> Policies, In the compartment dropdown, choose the compartment. 3. Open each policy to view the policy statements.4. Verify the policies to ensure that the policy statements that grant access to storage service-level administrators have a condition that excludes access to delete the service they are the administrator for.**From CLI:**1. Execute the following command:for compid in `oci iam compartment list --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id'` do for policy in `oci iam policy list --compartment-id $compid 2>/dev/null | jq -r '.data[] | .id'` do output=`oci iam policy list --compartment-id $compid 2>/dev/null | jq -r '.data[] | .id, .name, .statements'` if [ ! -z $output ]; then echo $output; fi done done2. Verify the policies to ensure that the policy statements that grant access to storage service-level administrators have a condition that excludes access to delete the service they are the administrator for.

Manual

Creating service-level administrators without the ability to delete the resource they are managing helps in tightly controlling access to Oracle Cloud Infrastructure (OCI) services by implementing the separation of duties security principle.

**From Console:**1. Login to OCI console.2. Go to Identity -> Policies, In the compartment dropdown, choose the compartment. Open each policy to view the policy statements.3. Add the appropriate where condition to any policy statement that allows the storage service-level to manage the storage service.

Level 1

1. Identity and Access Management

OCI IAM Local users can access OCI resources using different credentials, such as passwords or API keys. It is recommended that credentials that have been unused for 45 days or more be deactivated or removed.

Perform the following to determine if unused credentials exist:**From Console:For Passwords:1. Login to OCI Console.2. Select Identity & Security from the Services menu.3. Select Domains from the Identity menu.4. For each domain listed, click on the name 5. Click Reports6. Under Dormant users report click View report7. Enter a date 45 days from today’s date in Last Successful Login Date8. Check and ensure that Last Successful Login Date is greater than 45 days or emptyFor API Keys:1. Login to OCI Console.2. Select Observability & Management from the Services menu.3. Select Search from Logging menu4. Click Show Advanced Mode in the right corner5. Select Custom from Filter by time6. Under Select regions to search add regions7. Under Query enter the following query in the text box:search <tenancy-ocid>/_Audit_Include_Subcompartment | data.identity.credentials='<tenancy-ocid>/<user-ocid>/<key-fingerprint>' | summarize count() by data.identity.principalId8. Enter a day range - Note each query can only be 14 days multiple queries will be required to go 45 days9. Click Search10. Expand the results11. If results the count is not zero the user has used their API key during that period12. Repeat steps 8 – 11 for the 45-day periodFrom CLI:**For Passwords:1. Execute the below:oci identity-domains users list --all --endpoint <identity-domain-endpoint> --attributes urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User:lastSuccessfulLoginDate --profile Oracle --query '.data.resources[]|.user-name + + .urn-ietf-params-scim-schemas-oracle-idcs-extension-user-state-user.last-successful-login-date'2. Review the output the that the date is under 45 days, or no date means they have not logged inFor API Keys: 1. Create the search query text:export query=search \<tenancy-ocid>/_Audit_Include_Subcompartment\ | data.identity.credentials='*<key-finger-print>' | summarize count() by data.identity.principalId2. Select a day range. Date format is 2024-12-01- Note each query can only be 14 days multiple queries will be required to go 45 days3. Execute the below:oci logging-search search-logs --search-query $query --time-start <start-date> --time-end <end-date> --query 'data.results[0].data.count' export query=search \<tenancy-ocid>/_Audit_Include_Subcompartment\ | data.identity.credentials='*<key-finger-print>' | summarize count() by data.identity.principalId4. If results the count is not zero, the user has used their API key during that period5. Repeat steps 2 – 4 for the 45-day period

Automated

Disabling or removing unnecessary OCI IAM local users will reduce the window of opportunity for credentials associated with a compromised or abandoned account to be used.

**From Console:**1. Login to OCI Console.2. Select Identity & Security from the Services menu.3. Select Domains from the Identity menu.4. For each domain listed, click on the name and select Users.5. Click on an individual user under the Username heading.6. Click More action7. Select Deactivate**From CLI:**1. Create a input.json:{ operations: [ { op: replace, path: active,value: false} ], schemas: [urn:ietf:params:scim:api:messages:2.0:PatchOp], userId: <user-ocid> }2. Execute the below:oci identity-domains user patch --from-json file://file.json --endpoint <identity-domain-endpoint>

This audit should exclude the OCI Administrator, break-glass accounts, and service accounts as these accounts should only be used for day-to-day business and would likely be unused for up to 45 days.

Level 1

1. Identity and Access Management

API Keys are long-term credentials for an OCI IAM user. They can be used to make programmatic requests to the OCI APIs directly or via, OCI SDKs or the OCI CLI.

**From Console:1. Login to OCI Console.2. Select Identity & Security from the Services menu.3. Select Users from the Identity menu.4. Click on an individual user under the Name heading.5. Click on API Keys in the lower left-hand corner of the page.6. Ensure the has only has a one API KeyFrom CLI:**1. Each user and in each Identity Domainoci raw-request --http-method GET --target-uri https://<domain-endpoint>/admin/v1/ApiKeys?filter=user.ocid+eq+%<user-ocid>%22 | jq '.data.Resources[] | \(.fingerprint) \(.id)'2. Ensure only one key is returned

Deletion of an OCI API Key will remove programmatic access to OCI APIs

Automated

Having a single API Key for an OCI IAM reduces attack surface area and makes it easier to manage.

**From Console:**1. Login to OCI Console.2. Select Identity & Security from the Services menu.3. Select Domains from the Identity menu.4. For each domain listed, click on the name and select Users.5. Click on an individual user under the Name heading.6. Click on API Keys in the lower left-hand corner of the page.7. Delete one of the API Keys **From CLI:**1. Follow the audit procedure above.2. For API Key ID to be removed execute the following command:oci identity-domains api-key delete –api-key-id <id> --endpoint <domain-endpoint>

Level 1

2. Networking

Security lists provide stateful and stateless filtering of ingress and egress network traffic to OCI resources on a subnet level. It is recommended that no security list allows unrestricted ingress access to port 22.

**From Console:**1. Login to the OCI Console.2. Click the search bar at the top of the screen.3. Type Advanced Resource Query and hit enter.4. Click the Advanced Resource Query button in the upper right corner of the screen.5. Enter the following query in the query box:query SecurityList resources where (IngressSecurityRules.source = '0.0.0.0/0' && IngressSecurityRules.protocol = 6 && IngressSecurityRules.tcpOptions.destinationPortRange.max >= 22 && IngressSecurityRules.tcpOptions.destinationPortRange.min =<= 22) 6. Ensure the query returns no results.**From CLI:**1. Execute the following command:oci search resource structured-search --query-text query SecurityList resources where (IngressSecurityRules.source = '0.0.0.0/0' && IngressSecurityRules.protocol = 6 && IngressSecurityRules.tcpOptions.destinationPortRange.max >= 22 && IngressSecurityRules.tcpOptions.destinationPortRange.min <= 22) 2. Ensure the query returns no results.Cloud GuardEnsure Cloud Guard is enabled in the root compartment of the tenancy. For more information about enabling Cloud Guard, please look at the instructions included in Recommendation 3.15.**From Console:**1. Type Cloud Guard into the Search box at the top of the Console.2. Click Cloud Guard from the “Services” submenu.3. Click Detector Recipes in the Cloud Guard menu.4. Click OCI Configuration Detector Recipe (Oracle Managed) under the Recipe Name column.5. Find VCN Security list allows traffic to non-public port from all sources (0.0.0.0/0) in the Detector Rules column.6. Select the vertical ellipsis icon and chose Edit on the VCN Security list allows traffic to non-public port from all sources (0.0.0.0/0) row.7. In the Edit Detector Rule window find the Input Setting box and verify/add to the Restricted Protocol: Ports List setting to TCP:[22], UDP:[22].8. Click the Save button.**From CLI:**1. Update the VCN Security list allows traffic to non-public port from all sources (0.0.0.0/0) Detector Rule in Cloud Guard to generate Problems if a VCN security list allows public access via port 22 with the following command:oci cloud-guard detector-recipe-detector-rule update --detector-recipe-id <insert detector recipe ocid> --detector-rule-id SECURITY_LISTS_OPEN_SOURCE --details '{configurations:[{ configKey : securityListsOpenSourceConfig, name : Restricted Protocol:Ports List, value : TCP:[22], UDP:[22], dataType : null, values : null }]}'

For updating an existing environment, care should be taken to ensure that administrators currently relying on an existing ingress from 0.0.0.0/0 have access to ports 22 and/or 3389 through another network security group or security list.

Automated

Removing unfettered connectivity to remote console services, such as Secure Shell (SSH), reduces a server's exposure to risk.

**From Console:**1. Follow the audit procedure above.2. For each security list in the returned results, click the security list name3. Either edit the ingress rule to be more restrictive, delete the ingress rule or click on the VCN and terminate the security list as appropriate.**From CLI:**1. Follow the audit procedure.2. For each of the security lists identified, execute the following command:oci network security-list get --security-list-id <security list id>3. Then either: - Update the security list by copying the ingress-security-rules element from the JSON returned by the above command, edit it appropriately and use it in the following command:oci network security-list update --security-list-id <security-list-id> --ingress-security-rules '<ingress security rules JSON>' or - Delete the security list with the following command:oci network security-list delete --security-list-id <security list id>

Level 1

2. Networking

Security lists provide stateful and stateless filtering of ingress and egress network traffic to OCI resources on a subnet level. It is recommended that no security group allows unrestricted ingress access to port 3389.

**From Console:**1. Login into the OCI Console2. Click in the search bar at the top of the screen.3. Type Advanced Resource Query and hit enter.4. Click the Advanced Resource Query button in the upper right corner of the screen.5. Enter the following query in the query box:query SecurityList resources where (IngressSecurityRules.source = '0.0.0.0/0' && IngressSecurityRules.protocol = 6 && IngressSecurityRules.tcpOptions.destinationPortRange.max >= 3389 && IngressSecurityRules.tcpOptions.destinationPortRange.min <= 3389) 6. Ensure query returns no results.**From CLI:**1. Execute the following command:oci search resource structured-search --query-text query SecurityList resources where (IngressSecurityRules.source = '0.0.0.0/0' && IngressSecurityRules.protocol = 6 && IngressSecurityRules.tcpOptions.destinationPortRange.max >= 3389 && IngressSecurityRules.tcpOptions.destinationPortRange.min <= 3389) 2. Ensure query returns no results.Cloud GuardTo Enable Cloud Guard Auditing:Ensure Cloud Guard is enabled in the root compartment of the tenancy. For more information about enabling Cloud Guard, please look at the instructions included in Recommendation 3.15. **From Console:**1. Type Cloud Guard into the Search box at the top of the Console .2. Click Cloud Guard from the “Services” submenu.3. Click Detector Recipes in the Cloud Guard menu.4. Click OCI Configuration Detector Recipe (Oracle Managed) under the Recipe Name column.5. Find VCN Security list allows traffic to non-public port from all sources (0.0.0.0/0) in the Detector Rules column.6. Select the vertical ellipsis icon and choose Edit on the VCN Security list allows traffic to non-public port from all sources (0.0.0.0/0) row.7. In the Edit Detector Rule window find the Input Setting box and verify/add to the Restricted Protocol: Ports List setting to TCP:[3389], UDP:[3389].8. Click the Save button.**From CLI:**1. Update the VCN Security list allows traffic to non-public port from all sources (0.0.0.0/0) Detector Rule in Cloud Guard to generate Problems if a VCN security list allows public access via port 3389 with the following command:oci cloud-guard detector-recipe-detector-rule update --detector-recipe-id <insert detector recipe ocid> --detector-rule-id SECURITY_LISTS_OPEN_SOURCE --details '{configurations:[{ configKey : securityListsOpenSourceConfig, name : Restricted Protocol:Ports List, value : TCP:[3389], UDP:[3389], dataType : null, values : null }]}'

For updating an existing environment, care should be taken to ensure that administrators currently relying on an existing ingress from 0.0.0.0/0 have access to ports 22 and/or 3389 through another network security group or security list.

Automated

Removing unfettered connectivity to remote console services, such as Remote Desktop Protocol (RDP), reduces a server's exposure to risk.

**From Console:**1. Follow the audit procedure above.2. For each security list in the returned results, click the security list name3. Either edit the ingress rule to be more restrictive, delete the ingress rule or click on the VCN and terminate the security list as appropriate.**From CLI:**1. Follow the audit procedure.2. For each of the security lists identified, execute the following command:oci network security-list get --security-list-id <security list id>3. Then either: - Update the security list by copying the ingress-security-rules element from the JSON returned by the above command, edit it appropriately, and use it in the following commandoci network security-list update --security-list-id <security-list-id> --ingress-security-rules '<ingress security rules JSON>' or - Delete the security list with the following command:oci network security-list delete --security-list-id <security list id>

This recommendation can also be audited programmatically using REST API https://docs.oracle.com/en-us/iaas/api/#/en/iaas/20160918/SecurityList/ListSecurityLists

Level 1

2. Networking

Network security groups provide stateful filtering of ingress/egress network traffic to OCI resources. It is recommended that no security group allows unrestricted ingress to port 22.

From Console: 1. Login into the OCI Console. 2. Click the search bar at the top of the screen. 3. Type Advanced Resource Query and hit enter. 4. Click the Advanced Resource Query button in the upper right corner of the screen. 5. Enter the following query in the query box:query networksecuritygroup resources where lifeCycleState = 'AVAILABLE' 6. For each of the network security groups in the returned results, click the name and inspect each of the security rules. 7. Ensure that there are no security rules with direction: Ingress, Source: 0.0.0.0/0, and Destination Port Range: 22.**From CLI:**Issue the following command, it should return no values.for region in $(oci iam region-subscription list | jq -r '.data[] | .region-name') do echo Enumerating region $region for compid in $(oci iam compartment list --include-root --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id') do echo Enumerating compartment $compid for nsgid in $(oci network nsg list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | .id') do output=$(oci network nsg rules list --nsg-id=$nsgid --all 2>/dev/null | jq -r '.data[] | select(.source == 0.0.0.0/0 and .direction == INGRESS and ((.tcp-options.destination-port-range.max >= 22 and .tcp-options.destination-port-range.min <= 22) or .tcp-options.destination-port-range == null))') if [ ! -z $output ]; then echo NSGID: , $nsgid, Security Rules: , $output; fi done done done**Cloud Guard:**To Enable Cloud Guard Auditing:Ensure Cloud Guard is enabled in the root compartment of the tenancy. For more information about enabling Cloud Guard, please look at the instructions included in Recommendation 3.15. **From Console:**1. Type Cloud Guard into the Search box at the top of the Console .2. Click Cloud Guard from the “Services” submenu.3. Click Detector Recipes in the Cloud Guard menu.4. Click OCI Configuration Detector Recipe (Oracle Managed) under the Recipe Name column.5. Find NSG ingress rule contains disallowed IP/port in the Detector Rules column.6. Select the vertical ellipsis icon and chose Edit on the NSG ingress rule contains disallowed IP/port row.7. In the Edit Detector Rule window find the Input Setting box and verify/add to the Restricted Protocol: Ports List setting to TCP:[22], UDP:[22].8. Click the Save button.**From CLI:**1. Update the NSG ingress rule contains disallowed IP/port Detector Rule in Cloud Guard to generate Problems if a network security group allows ingress network traffic to port 22 with the following command:oci cloud-guard detector-recipe-detector-rule update --detector-recipe-id <insert detector recipe ocid> --detector-rule-id VCN_NSG_INGRESS_RULE_PORTS_CHECK --details '{configurations:[ {configKey : nsgIngressRuleDisallowedPortsConfig, name : Default disallowed ports, value : TCP:[22], UDP:[22], dataType : null, values : null }]}'

For updating an existing environment, care should be taken to ensure that administrators currently relying on an existing ingress from 0.0.0.0/0 have access to ports 22 and/or 3389 through another network security group or security list.

Automated

Removing unfettered connectivity to remote console services, such as Secure Shell (SSH), reduces a server's exposure to risk.

From Console: 1. Login into the OCI Console. 2. Click the search bar at the top of the screen. 3. Type Advanced Resource Query and hit enter. 4. Click the Advanced Resource Query button in the upper right corner of the screen. 5. Enter the following query in the query box: query networksecuritygroup resources where lifeCycleState = 'AVAILABLE' 6. For each of the network security groups in the returned results, click the name and inspect each of the security rules. 7. Remove all security rules with direction: Ingress, Source: 0.0.0.0/0, and Destination Port Range: 22.**From CLI:**Issue the following command and identify the security rule to remove. for region in `oci iam region list | jq -r '.data[] | .name'`; do for compid in `oci iam compartment list 2>/dev/null | jq -r '.data[] | .id'`; do for nsgid in `oci network nsg list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | .id'` do output=`oci network nsg rules list --nsg-id=$nsgid --all 2>/dev/null | jq -r '.data[] | select(.source == 0.0.0.0/0 and .direction == INGRESS and ((.tcp-options.destination-port-range.max >= 22 and .tcp-options.destination-port-range.min <= 22) or .tcp-options.destination-port-range == null))'` if [ ! -z $output ]; then echo NSGID=, $nsgid, Security Rules=, $output; fi done done done- Remove the security rulesoci network nsg rules remove --nsg-id=<NSGID from audit output>or- Update the security rulesoci network nsg rules update --nsg-id=<NSGID from audit output> --security-rules='[<updated security-rules JSON (without isValid and TimrCreated fields)>]'eg: oci network nsg rules update --nsg-id=ocid1.networksecuritygroup.oc1.iad.xxxxxxxxxxxxxxxxxxxxxx --security-rules='[{ description: null, destination: null, destination-type: null, direction: INGRESS, icmp-options: null, id: 709001, is-stateless: null, protocol: 6, source: 140.238.154.0/24, source-type: CIDR_BLOCK, tcp-options: { destination-port-range: { max: 22, min: 22 }, source-port-range: null }, udp-options: null }]'

Level 1

2. Networking

Network security groups provide stateful filtering of ingress/egress network traffic to OCI resources. It is recommended that no security group allows unrestricted ingress access to port 3389.

**From CLI:**Issue the following command, it should not return anything. for region in $(oci iam region-subscription list | jq -r '.data[] | .region-name') do echo Enumerating region $region for compid in $(oci iam compartment list --include-root --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id') do echo Enumerating compartment $compid for nsgid in $(oci network nsg list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | .id') do output=$(oci network nsg rules list --nsg-id=$nsgid --all 2>/dev/null | jq -r '.data[] | select(.source == 0.0.0.0/0 and .direction == INGRESS and ((.tcp-options.destination-port-range.max >= 3389 and .tcp-options.destination-port-range.min <= 3389) or .tcp-options.destination-port-range == null))') if [ ! -z $output ]; then echo NSGID: , $nsgid, Security Rules: , $output; fi done done done**From Cloud Guard:**To Enable Cloud Guard Auditing:Ensure Cloud Guard is enabled in the root compartment of the tenancy. For more information about enabling Cloud Guard, please look at the instructions included in Recommendation 3.15. **From Console:**1. Type Cloud Guard into the Search box at the top of the Console.2. Click Cloud Guard from the “Services” submenu.3. Click Detector Recipes in the Cloud Guard menu.4. Click OCI Configuration Detector Recipe (Oracle Managed) under the Recipe Name column.5. Find NSG ingress rule contains disallowed IP/port in the Detector Rules column.6. Select the vertical ellipsis icon and chose Edit on the NSG ingress rule contains disallowed IP/port row.7. In the Edit Detector Rule window find the Input Setting box and verify/add to the Restricted Protocol: Ports List setting to TCP:[3389], UDP:[3389].8. Click the Save button.**From CLI:**1. Update the NSG ingress rule contains disallowed IP/port Detector Rule in Cloud Guard to generate Problems if a network security group allows ingress network traffic to port 3389 with the following command:oci cloud-guard detector-recipe-detector-rule update --detector-recipe-id <insert detector recipe ocid> --detector-rule-id VCN_NSG_INGRESS_RULE_PORTS_CHECK --details '{configurations:[ {configKey : nsgIngressRuleDisallowedPortsConfig, name : Default disallowed ports, value : TCP:[3389], UDP:[3389], dataType : null, values : null }]}'

For updating an existing environment, care should be taken to ensure that administrators currently relying on an existing ingress from 0.0.0.0/0 have access to ports 22 and/or 3389 through another network security group or security list.

Automated

Removing unfettered connectivity to remote console services, such as Remote Desktop Protocol (RDP), reduces a server's exposure to risk.

**From CLI:**Using the details returned from the audit procedure either:- Remove the security rulesoci network nsg rules remove --nsg-id=<NSGID from audit output>or- Update the security rulesoci network nsg rules update --nsg-id=<NSGID from audit output> --security-rules=<updated security-rules JSON (without the isValid or TimeCreated fields)>eg: oci network nsg rules update --nsg-id=ocid1.networksecuritygroup.oc1.iad.xxxxxxxxxxxxxxxxxxxxxx --security-rules='[{ description: null, destination: null, destination-type: null, direction: INGRESS, icmp-options: null, id: 709001, is-stateless: null, protocol: 6, source: 140.238.154.0/24, source-type: CIDR_BLOCK, tcp-options: { destination-port-range: { max: 3389, min: 3389 }, source-port-range: null }, udp-options: null }]'

Level 1

2. Networking

A default security list is created when a Virtual Cloud Network (VCN) is created and attached to the public subnets in the VCN. Security lists provide stateful or stateless filtering of ingress and egress network traffic to OCI resources in the VCN. It is recommended that the default security list does not allow unrestricted ingress and egress access to resources in the VCN.

**From Console:**1. Login into the OCI Console2. Click on Networking -> Virtual Cloud Networks from the services menu3. For each VCN listed Click on Security Lists4. Click on Default Security List for <VCN Name>5. Verify that there is no Ingress rule with 'Source 0.0.0.0/0'6. Verify that there is no Egress rule with 'Destination 0.0.0.0/0, All Protocols'

For updating existing environments Ingress rules with a source of 0.0.0.0/0, ensure that the necessary access is available through another Network Security Group or Security List.For updating existing environments Egress rules with a destination of 0.0.0.0/0 for an existing environment, ensure egress is covered via another Network Security Group, Security List, or through the stateful nature of the ingress rule.

Automated

Removing unfettered connectivity to OCI resource, reduces a server's exposure to unauthorized access or data exfiltration.

**From Console:**1. Login into the OCI Console2. Click on Networking -> Virtual Cloud Networks from the services menu3. For each VCN listed Click on Security Lists4. Click on Default Security List for <VCN Name>5. Identify the Ingress Rule with 'Source 0.0.0.0/0'6. Either Edit the Security rule to restrict the source and/or port range or delete the rule.7. Identify the Egress Rule with 'Destination 0.0.0.0/0, All Protocols'8. Either Edit the Security rule to restrict the source and/or port range or delete the rule.

Level 1

2. Networking

Oracle Integration (OIC) is a complete, secure, but lightweight integration solution that enables you to connect your applications in the cloud. It simplifies connectivity between your applications and connects both your applications that live in the cloud and your applications that still live on premises. Oracle Integration provides secure, enterprise-grade connectivity regardless of the applications you are connecting or where they reside. OIC instances are created within an Oracle managed secure private network with each having a public endpoint. The capability to configure ingress filtering of network traffic to protect your OIC instances from unauthorized network access is included. It is recommended that network access to your OIC instances be restricted to your approved corporate IP Addresses or Virtual Cloud Networks (VCN)s.

**From Console:1. Login into the OCI Console2. Click in the search bar, top of the screen.3. Type Advanced Resource Query and hit enter.4. Click the Advanced Resource Query button in the upper right of the screen.5. Enter the following query in the query box:query integrationinstance resources6. For each OIC Instance returned click on the link under Display name7. Click on Network Access8 .Ensure Restrict Network Access is selected and the IP Address/CIDR Block as well as Virtual Cloud Networks are correct9. Repeat for other subscribed regionsFrom CLI:**1. Execute the following command:for region in `oci iam region list | jq -r '.data[] | .name'`; do for compid in `oci iam compartment list --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id'` do output=`oci integration integration-instance list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | select(.network-endpoint-details.network-endpoint-type == null)'` if [ ! -z $output ]; then echo $output; fi done done2. Ensure allowlisted-http-ips and allowed-http-vcns are correct

When updating ingress filters for an existing environment, care should be taken to ensure that IP addresses and VCNs currently used by administrators, users, and services to access your OIC instances are included in the updated filters.

Manual

Restricting connectivity to OIC Instances reduces an OIC instance’s exposure to risk.

**From Console:**1. Follow the audit procedure above.2. For each OIC instance in the returned results, click the OIC Instance name3. Click Network Access4. Either edit the Network Access to be more restrictive From CLI1. Follow the audit procedure.2. Get the json input format using the below command:oci integration integration-instance change-network-endpoint --generate-param-json-input3.For each of the OIC Instances identified get its details.4.Update the Network Access, copy the network-endpoint-details element from the JSON returned by the above get call, edit it appropriately and use it in the following commandOci integration integration-instance change-network-endpoint --id <oic-instance-id> --from-json '<network endpoints JSON>'

Level 1

2. Networking

Oracle Analytics Cloud (OAC) is a scalable and secure public cloud service that provides a full set of capabilities to explore and perform collaborative analytics for you, your workgroup, and your enterprise. OAC instances provide ingress filtering of network traffic or can be deployed with in an existing Virtual Cloud Network VCN. It is recommended that all new OAC instances be deployed within a VCN and that the Access Control Rules are restricted to your corporate IP Addresses or VCNs for existing OAC instances.

**From Console:**1 Login into the OCI Console2. Click in the search bar, top of the screen.3. Type Advanced Resource Query and hit enter.4. Click the Advanced Resource Query button in the upper right of the screen.5. Enter the following query in the query box:query analyticsinstance resources6. For each OAC Instance returned click on the link under Display name.7. Ensure Access Control Rules IP Address/CIDR Block as well as Virtual Cloud Networks are correct.8. Repeat for other subscribed regions.**From CLI:**1. Execute the following command:for region in `oci iam region list | jq -r '.data[] | .name'`; do for compid in `oci iam compartment list --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id'` do output=`oci analytics analytics-instance list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | select(.network-endpoint-details.network-endpoint-type == PUBLIC)'` if [ ! -z $output ]; then echo $output; fi done done2. Ensure network-endpoint-type are correct.

When updating ingress filters for an existing environment, care should be taken to ensure that IP addresses and VCNs currently used by administrators, users, and services to access your OAC instances are included in the updated filters. Also, these changes will temporarily bring the OAC instance offline.

Manual

Restricting connectivity to Oracle Analytics Cloud instances reduces an OAC instance’s exposure to risk.

**From Console:1. Follow the audit procedure above.2. For each OAC instance in the returned results, click the OAC Instance name3. Click Edit next to Access Control Rules4. Click +Another Rule and add rules as requiredFrom CLI:**1. Follow the audit procedure.2. Get the json input format by executing the below command:oci analytics analytics-instance change-network-endpoint --generate-full-command-json-input3. For each of the OAC Instances identified get its details.4. Update the Access Control Rules, copy the network-endpoint-details element from the JSON returned by the above get call, edit it appropriately and use it in the following command:oci integration analytics-instance change-network-endpoint --from-json '<network endpoints JSON>'

Level 1

2. Networking

Oracle Autonomous Database Shared (ADB-S) automates database tuning, security, backups, updates, and other routine management tasks traditionally performed by DBAs. ADB-S provide ingress filtering of network traffic or can be deployed within an existing Virtual Cloud Network (VCN). It is recommended that all new ADB-S databases be deployed within a VCN and that the Access Control Rules are restricted to your corporate IP Addresses or VCNs for existing ADB-S databases.

**From Console:**1. Login into the OCI Console2. Click in the search bar, top of the screen.3. Type Advanced Resource Query and hit enter.4. Click the Advanced Resource Query button in the upper right of the screen.5. Enter the following query in the query box:query autonomousdatabase resources6. For each ABD-S database returned click on the link under Display name7. Click Edit next to Access Control List8. Ensure Access Control Rules’ IP Address/CIDR Block as well as VCNs are correct9. Repeat for other subscribed regions**From CLI:**1. Execute the following command:```for region in oci iam region list | jq -r '.data[] | .name'; do for compid in oci iam compartment list --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id'do for adbid inoci db autonomous-database list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | select(.nsg-ids == null).id' do output=oci db autonomous-database get --autonomous-database-id $adbid --region $region --query=data.{WhiteListIPs:\whitelisted-ips,id:id} --output table 2>/dev/nullif [ ! -z $output ]; then echo $output; fi done done done```2. EnsureWhiteListIPs` are correct.

When updating ingress filters for an existing environment, care should be taken to ensure that IP addresses and VCNs currently used by administrators, users, and services to access your ADB-S instances are included in the updated filters.

Manual

Restricting connectivity to ADB-S Databases reduces an ADB-S database’s exposure to risk.

**From Console:**1. Follow the audit procedure above.2. For each ADB-S database in the returned results, click the ADB-S database name3. Click Edit next to Access Control Rules4. Click +Another Rule and add rules as required5. Click Save Changes**From CLI:**1. Follow the audit procedure.2. Get the json input format by executing the following command:oci db autonomous-database update --generate-full-command-json-input3. For each of the ADB-S Database identified get its details.4. Update the whitelistIps, copy the WhiteListIPs element from the JSON returned by the above get call, edit it appropriately and use it in the following command:oci db autonomous-database update –-autonomous-database-id <ABD-S OCID> --from-json '<network endpoints JSON>'

Level 2

3. Compute

Compute Instances that utilize Legacy MetaData service endpoints (IMDSv1) are susceptible to potential SSRF attacks. To bolster security measures, it is strongly advised to reconfigure Compute Instances to adopt Instance Metadata Service v2, aligning with the industry's best security practices.

**From Console:**1. Login to the OCI Console2. Select compute instance in your compartment.3. Click on each instance name.4. In the Instance Details section, next to Instance metadata service make sure Version 2 only is selected.**From CLI:**1. Run command:for region in `oci iam region-subscription list | jq -r '.data[] | .region-name'`; do for compid in `oci iam compartment list --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id'` do output=`oci compute instance list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | select(.instance-options.are-legacy-imds-endpoints-disabled == false )'` if [ ! -z $output ]; then echo $output; fi done done2. No results should be returned

If you disable IMDSv1 on an instance that does not support IMDSv2, you might not be able to connect to the instance when you launch it.IMDSv2 is supported on the following platform images:- Oracle Autonomous Linux 8.x images- Oracle Autonomous Linux 7.x images released in June 2020 or later- Oracle Linux 8.x, Oracle Linux 7.x, and Oracle Linux 6.x images released in July 2020 or laterOther platform images, most custom images, and most Marketplace images do not support IMDSv2. Custom Linux images might support IMDSv2 if cloud-init is updated to version 20.3 or later and Oracle Cloud Agent is updated to version 0.0.19 or later. Custom Windows images might support IMDSv2 if Oracle Cloud Agent is updated to version 1.0.0.0 or later; cloudbase-init does not support IMDSv2.

Automated

Enabling Instance Metadata Service v2 enhances security and grants precise control over metadata access. Transitioning from IMDSv1 reduces the risk of SSRF attacks, bolstering system protection.IMDv1 poses security risks due to its inferior security measures and limited auditing capabilities. Transitioning to IMDv2 ensures a more secure environment with robust security features and improved monitoring capabilities.

**From Console:**1. Login to the OCI Console2. Click on the search box at the top of the console and search for compute instance name.3. Click on the instance name, In the Instance Details section, next to Instance Metadata Service, click Edit.4. For the Instance metadata service, select the Version 2 only option.5. Click Save Changes.Note : Disabling IMDSv1 on an incompatible instance may result in connectivity issues upon launch.To re-enable IMDSv1, follow these steps: 1. On the Instance Details page in the Console, click Edit next to Instance Metadata Service.2. Choose the Version 1 and version 2 option, and save your changes.**From CLI:**Run Below Command,oci compute instance update --instance-id [instance-ocid] --instance-options '{areLegacyImdsEndpointsDisabled :true}'This will set Instance Metadata Service to use Version 2 Only.

Level 2

3. Compute

Shielded Instances with Secure Boot enabled prevents unauthorized boot loaders and operating systems from booting. This prevent rootkits, bootkits, and unauthorized software from running before the operating system loads.Secure Boot verifies the digital signature of the system's boot software to check its authenticity. The digital signature ensures the operating system has not been tampered with and is from a trusted source.When the system boots and attempts to execute the software, it will first check the digital signature to ensure validity. If the digital signature is not valid, the system will not allow the software to run.Secure Boot is a feature of UEFI(Unified Extensible Firmware Interface) that only allows approved operating systems to boot up.

**From Console:**1. Login to the OCI Console2. Select compute instance in your compartment.3. Click on each instance name.4. In the Launch Options section,5. Check if Secure Boot is Enabled.**From CLI:**Run command:for region in `oci iam region-subscription list | jq -r '.data[] | .region-name'`; do for compid in `oci iam compartment list --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id'` do output=`oci compute instance list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | select(.platform-config == null or platform-config.is-secure-boot-enabled == false )'` if [ ! -z $output ]; then echo $output; fi done doneIn response, check if platform-config are not null and is-secure-boot-enabled is set to true

An existing instance cannot be changed to a Shielded instance with Secure boot enabled. Shielded Secure Boot not available on all instance shapes and Operating systems. Additionally the following limitations exist:Thus to enable you have to terminate the instance and create a new one. Also, Shielded instances do not support live migration. During an infrastructure maintenance event, Oracle Cloud Infrastructure live migrates supported VM instances from the physical VM host that needs maintenance to a healthy VM host with minimal disruption to running instances. If you enable Secure Boot on an instance, the instance cannot be migrated, because the hardware TPM is not migratable. This may result in an outage because the TPM can't be migrate from a unhealthy host to healthy host.

Automated

A Threat Actor with access to the operating system may seek to alter boot components to persist malware or rootkits during system initialization. Secure Boot helps ensure that the system only runs authentic software by verifying the digital signature of all boot components.

Note: Secure Boot facility is available on selected VM images and Shapes in OCI. User have to configure Secured Boot at time of instance creation only.**From Console:**1. Navigate to https://cloud.oracle.com/compute/instances1. Select the instance from the Audit Procedure1. Click Terminate.1. Determine whether or not to permanently delete instance's attached boot volume.1. Click Terminate instance.1. Click on Create Instance.1. Select Image and Shape which supports Shielded Instance configuration. Icon for Shield in front of Image/Shape row indicates support of Shielded Instance.1. Click on edit of Security Blade.1. Turn On Shielded Instance, then Turn on the Secure Boot Toggle.1. Fill in the rest of the details as per requirements.1. Click Create.

Level 1

3. Compute

The Block Volume service provides the option to enable in-transit encryption for paravirtualized volume attachments on virtual machine (VM) instances.

**From Console:**1. Go to https://cloud.oracle.com/compute/instances2. Select compute instance in your compartment.3. Click on each instance name.4. Click on Boot volume on the bottom left.5. Under the In-transit encryption column make sure it is Enabled**From CLI:**1. Execute the following:for region in `oci iam region-subscription list | jq -r '.data[] | .region-name'`; do for compid in `oci iam compartment list --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id'` do output=`oci compute instance list --compartment-id $compid --region $region --all 2>/dev/null | jq -r '.data[] | select(.launch-options.is-pv-encryption-in-transit-enabled == false )'` if [ ! -z $output ]; then echo $output; fi done done2. Ensure no results are returned

In-transit encryption for boot and block volumes is only available for virtual machine (VM) instances launched from platform images, along with bare metal instances that use the following shapes: BM.Standard.E3.128, BM.Standard.E4.128, BM.DenseIO.E4.128. It is not supported on other bare metal instances.

Automated

All the data moving between the instance and the block volume is transferred over an internal and highly secure network. If you have specific compliance requirements related to the encryption of the data while it is moving between the instance and the block volume, you should enable the in-transit encryption option.

**From Console:**1. Navigate to https://cloud.oracle.com/compute/instances1. Select the instance from the Audit Procedure1. Click Terminate.1. Determine whether or not to permanently delete instance's attached boot volume.1. Click Terminate instance.1. Click on Create Instance.1. Fill in the details as per requirements.1. In the Boot volume section ensure Use in-transit encryption is checked.1. Fill in the rest of the details as per requirements.1. Click Create.

Level 1

4. Logging and Monitoring

Using default tags is a way to ensure all resources that support tags are tagged during creation. Tags can be based on static or computed values. It is recommended to set up default tags early after root compartment creation to ensure all created resources will get tagged.Tags are scoped to Compartments and are inherited by Child Compartments. The recommendation is to create default tags like “CreatedBy” at the Root Compartment level to ensure all resources get tagged.When using Tags it is important to ensure that Tag Namespaces are protected by IAM Policies otherwise this will allow users to change tags or tag values.Depending on the age of the OCI Tenancy there may already be Tag defaults setup at the Root Level and no need for further action to implement this action.

**From Console:**1. Login to OCI Console.2. From the navigation menu, select Identity & Security.3. Under Identity, select Compartments.4. Click the name of the root compartment.5. Under Resources, select Tag Defaults.6. In the Tag Defaults table, verify that there is a Tag with a value of ${iam.principal.name} and a Tag Key Status of Active.Note: The name of the tag may be different then “CreatedBy” if the Tenancy Administrator has decided to use another tag.**From CLI:**1. List the active tag defaults defined at the Root compartment level by using the Tenancy OCID as compartment id.Note: The Tenancy OCID can be found in the ~/.oci/config file used by the OCI Command Line Tooloci iam tag-default list --compartment-id=<tenancy_ocid> --query=data [?\lifecycle-state\=='ACTIVE'].{name:\tag-definition-name\,value:value} --output table2. Verify in the table returned that there is at least one row that contains the value of ${iam.principal.name}.

There is no performance impact when enabling the above described features.

Automated

In the case of an incident having default tags like “CreatedBy” applied will provide info on who created the resource without having to search the Audit logs.

**From Console:**1. Login to OCI Console.2. From the navigation menu, select Governance & Administration.3. Under Tenancy Management, select Tag Namespaces.4. Under Compartment, select the root compartment.5. If no tag namespace exists, click Create Tag Namespace, enter a name and description and click Create Tag Namespace.6. Click the name of a tag namespace.7. Click Create Tag Key Definition.8. Enter a tag key (e.g. CreatedBy) and description, and click Create Tag Key Definition.9. From the navigation menu, select Identity & Security.10. Under Identity, select Compartments.11. Click the name of the root compartment.12. Under Resources, select Tag Defaults.13. Click Create Tag Default.14. Select a tag namespace, tag key, and enter ${iam.principal.name} as the tag value.15. Click Create.**From CLI:**1. Create a Tag Namespace in the Root Compartmentoci iam tag-namespace create --compartment-id=<tenancy_ocid> --name=<name> --description=<description> --query data.{\Tag Namespace OCID\:id} --output table2. Note the Tag Namespace OCID and use it when creating the Tag Key Definitionoci iam tag create --tag-namespace-id=<tag_namespace_ocid> --name=<tag_key_name> --description=<description> --query data.{\Tag Key Definition OCID\:id} --output table3. Note the Tag Key Definition OCID and use it when creating the Tag Default in the Root compartmentoci iam tag-default create --compartment-id=<tenancy_ocid> --tag-definition-id=<tag_key_definition_id> --value=\${iam.principal.name}

'- There is no requirement to use the “Oracle-Tags” namespace to implement this control. A Tag Namespace Administrator can create any namespace and use it for this control.

Level 1

4. Logging and Monitoring

Notifications provide a multi-channel messaging service that allow users and applications to be notified of events of interest occurring within OCI. Messages can be sent via eMail, HTTPs, PagerDuty, Slack or the OCI Function service. Some channels, such as eMail require confirmation of the subscription before it becomes active.

**From Console:**1. Go to the Notifications Service page: https://console.us-ashburn-1.oraclecloud.com/notification/topics2. Select the Compartment that hosts the notifications3. Find and click the Topic relevant to your monitoring alerts.4. Ensure a valid active subscription is shown.From CLI: 1. List the topics in the Compartment that hosts the notificationsoci ons topic list --compartment-id <compartment OCID> --all2. Note the OCID of the monitoring topic(s) using the topic-id field of the returned JSON and use it to list the subscriptionsoci ons subscription list --compartment-id <compartment OCID> --topic-id <topic OCID> --all3. Ensure at least one active subscription is returned

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Creating one or more notification topics allow administrators to be notified of relevant changes made to OCI infrastructure.

**From Console:**1. Go to the Notifications Service page: https://console.us-ashburn-1.oraclecloud.com/notification/topics2. Select the Compartment that hosts the notifications3. Click Create Topic4. Set the name to something relevant5. Set the description to describe the purpose of the topic6. Click Create7. Click the newly created topic8. Click Create Subscription9. Choose the correct protocol10. Complete the correct parameter, for instance email address11. Click Create**From CLI:**1. Create a topic in a compartmentoci ons topic create --name <topic name> --description <topic description> --compartment-id <compartment OCID>2. Note the OCID of the topic using the topic-id field of the returned JSON and use it to create a new subscriptionoci ons subscription create --compartment-id <compartment OCID> --topic-id <topic OCID> --protocol <protocol> --subscription-endpoint <subscription endpoint>3. The returned JSON includes the id of the subscription.

'- The console URL shown is for the Ashburn region. Your tenancy might have a different home region and thus console URL.- The same Notification topic can be reused by many Events. A single topic can have multiple subscriptions allowing the same topic to be published to multiple locations.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when Identity Providers are created, updated or deleted. Event Rules are compartment scoped and will detect events in child compartments. It is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles Identity Provider Changes (if any)4. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Identity and Event Types: Identity Provider – Create, Identity Provider - Delete and Identity Provider – Update5. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.From CLI: 1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-id>3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:com.oraclecloud.identitycontrolplane.createidentityprovidercom.oraclecloud.identitycontrolplane.deleteidentityprovidercom.oraclecloud.identitycontrolplane.updateidentityprovider4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

OCI Identity Providers allow management of User ID / passwords in external systems and use of those credentials to access OCI resources. Identity Providers allow users to single sign-on to OCI console and have other OCI credentials like API Keys.Monitoring and alerting on changes to Identity Providers will help in identifying changes to the security posture.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Identity in the Service Name Drop-down and selecting Identity Provider – Create, Identity Provider - Delete and Identity Provider – Update6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition:{\eventType:[\com.oraclecloud.identitycontrolplane.createidentityprovider,\ com.oraclecloud.identitycontrolplane.deleteidentityprovider,\ com.oraclecloud.identitycontrolplane.updateidentityprovider],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when Identity Provider Group Mappings are created, updated or deleted. Event Rules are compartment scoped and will detect events in child compartments. It is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles Idp Group Mapping Changes (if any)4. Ensure the Rule is ACTIVE5. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Identity and Event Types: Idp Group Mapping – Add, Idp Group Mapping – Remove and Idp Group Mapping – Update6. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.From CLI: 1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<displa-name>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-id>3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:com.oraclecloud.identitycontrolplane.addidpgroupmappingcom.oraclecloud.identitycontrolplane.removeidpgroupmappingcom.oraclecloud.identitycontrolplane.updateidpgroupmapping4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

IAM Policies govern access to all resources within an OCI Tenancy. IAM Policies use OCI Groups for assigning the privileges. Identity Provider Groups could be mapped to OCI Groups to assign privileges to federated users in OCI. Monitoring and alerting on changes to Identity Provider Group mappings will help in identifying changes to the security posture.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Identity in the Service Name Drop-down and selecting Idp Group Mapping – Add, Idp Group Mapping – Remove and Idp Group Mapping – Update6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition:{\eventType:[\com.oraclecloud.identitycontrolplane.addidpgroupmapping,\com.oraclecloud.identitycontrolplane.removeidpgroupmapping,\com.oraclecloud.identitycontrolplane.updateidpgroupmapping],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when IAM Groups are created, updated or deleted. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles IAM Group Changes4. Click the Edit Rule button and verify that the Rule Conditions section contains a condition for the Service Identity and Event Types: Group – Create, Group – Delete and Group – Update5. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.**From CLI:**1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCID````oci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table```2. List the details of a specific Event Rule based on the OCID of the rule.```oci events rule get --rule-id <rule-id>```3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:```com.oraclecloud.identitycontrolplane.creategroupcom.oraclecloud.identitycontrolplane.deletegroupcom.oraclecloud.identitycontrolplane.updategroup```4. Verify the value of the is-enabledattribute istrue5. In the JSON output verify that actionTypeis ONS and locate thetopic-id`6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

IAM Groups control access to all resources within an OCI Tenancy. Monitoring and alerting on changes to IAM Groups will help in identifying changes to satisfy least privilege principle.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Identity in the Service Name Drop-down and selecting Group – Create, Group – Delete and Group – Update6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition: {\eventType:[\com.oraclecloud.identitycontrolplane.creategroup,\com.oraclecloud.identitycontrolplane.deletegroup,\com.oraclecloud.identitycontrolplane.updategroup],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when IAM Policies are created, updated or deleted. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles IAM Policy Changes (if any)4. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Identity and Event Types: Policy – Create, Policy - Delete and Policy – Update5. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.From CLI: 1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-id>3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:com.oraclecloud.identitycontrolplane.createpolicycom.oraclecloud.identitycontrolplane.deletepolicycom.oraclecloud.identitycontrolplane.updatepolicy4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

IAM Policies govern access to all resources within an OCI Tenancy. Monitoring and alerting on changes to IAM policies will help in identifying changes to the security posture.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Identity in the Service Name Drop-down and selecting Policy – Change Compartment, Policy – Create, Policy - Delete and Policy – Update6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition:{\eventType:[\com.oraclecloud.identitycontrolplane.createpolicy,\com.oraclecloud.identitycontrolplane.deletepolicy,\com.oraclecloud.identitycontrolplane.updatepolicy],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when IAM Users are created, updated, deleted, capabilities updated, or state updated. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.

**From Console:**1. Using the search box to navigate to events2. Navigate to the rules page3. Select the Compartment that hosts the rules4. Find and click the Rule that handles IAM User Changes5. Click the Edit Rule button and verify that the Rule Conditions section contains a condition for the Service Identity and Event Types: User – Create, User – Delete, User – Update, User Capabilities – Update,User State – Update 6. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.**From CLI:**1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCID````oci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table```2. List the details of a specific Event Rule based on the OCID of the rule.```oci events rule get --rule-id <rule-id>```3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:```com.oraclecloud.identitycontrolplane.createusercom.oraclecloud.identitycontrolplane.deleteusercom.oraclecloud.identitycontrolplane.updateusercom.oraclecloud.identitycontrolplane.updateusercapabilitiescom.oraclecloud.identitycontrolplane.updateuserstate```4. Verify the value of the is-enabledattribute istrue5. In the JSON output verify that actionTypeis ONS and locate thetopic-id`6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Users use or manage Oracle Cloud Infrastructure resources. Monitoring and alerting on changes to Users will help in identifying changes to the security posture.

**From Console:**1. Using the search box to navigate to events2. Navigate to the rules page3. Select the compartment that should host the rule4. Click Create Rule5. Provide a Display Name and Description6. Create a Rule Condition by selecting Identity in the Service Name Drop-down and selecting:User – Create, User – Delete, User – Update, User Capabilities – Update,User State – Update 7. In the Actions section select Notifications as Action Type8. Select the Compartment that hosts the Topic to be used.9. Select the Topic to be used10. Optionally add Tags to the Rule11. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition: {\eventType:[\com.oraclecloud.identitycontrolplane.createuser,\com.oraclecloud.identitycontrolplane.deleteuser,\com.oraclecloud.identitycontrolplane.updateuser,\com.oraclecloud.identitycontrolplane.updateusercapabilities,\com.oraclecloud.identitycontrolplane.updateuserstate],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when Virtual Cloud Networks are created, updated or deleted. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles VCN Changes (if any)4. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Networking and Event Types: VCN – Create, VCN - Delete and VCN – Update5. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.**From CLI:**1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-id>3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:com.oraclecloud.virtualnetwork.createvcncom.oraclecloud.virtualnetwork.deletevcncom.oraclecloud.virtualnetwork.updatevcn4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Virtual Cloud Networks (VCNs) closely resembles a traditional network. Monitoring and alerting on changes to VCNs will help in identifying changes to the security posture.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Networking in the Service Name Drop-down and selecting VCN – Create, VCN - Delete and VCN – Update6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition:{\eventType:[\com.oraclecloud.virtualnetwork.createvcn,\com.oraclecloud.virtualnetwork.deletevcn,\com.oraclecloud.virtualnetwork.updatevcn],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when route tables are created, updated or deleted. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles Route Table Changes (if any)4. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Networking and Event Types: Route Table – Change Compartment, Route Table – Create, Route Table - Delete and Route Table - Update5. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.**From CLI:**1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-id>3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:com.oraclecloud.virtualnetwork.changeroutetablecompartmentcom.oraclecloud.virtualnetwork.createroutetablecom.oraclecloud.virtualnetwork.deleteroutetablecom.oraclecloud.virtualnetwork.updateroutetable4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Route tables control traffic flowing to or from Virtual Cloud Networks and Subnets. Monitoring and alerting on changes to route tables will help in identifying changes these traffic flows.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Networking in the Service Name Drop-down and selecting Route Table – Change Compartment, Route Table – Create, Route Table - Delete and Route Table – Update6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition:{\eventType:[\com.oraclecloud.virtualnetwork.changeroutetablecompartment,\com.oraclecloud.virtualnetwork.createroutetable,\com.oraclecloud.virtualnetwork.deleteroutetable,\com.oraclecloud.virtualnetwork.updateroutetable],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when security lists are created, updated or deleted. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles Security List Changes (if any)4. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Networking and Event Types: Security List – Change Compartment, Security List – Create, Security List - Delete and Security List – Update5. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.**From CLI:**1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-ocid>3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:com.oraclecloud.virtualnetwork.changesecuritylistcompartmentcom.oraclecloud.virtualnetwork.createsecuritylistcom.oraclecloud.virtualnetwork.deletesecuritylistcom.oraclecloud.virtualnetwork.updatesecuritylist4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Security Lists control traffic flowing into and out of Subnets within a Virtual Cloud Network. Monitoring and alerting on changes to Security Lists will help in identifying changes to these security controls.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Networking in the Service Name Drop-down and selecting Security List – Change Compartment, Security List – Create, Security List - Delete and Security List – Update6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic-id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition:{\eventType:[\com.oraclecloud.virtualnetwork.changesecuritylistcompartment,\com.oraclecloud.virtualnetwork.createsecuritylist,\com.oraclecloud.virtualnetwork.deletesecuritylist,\com.oraclecloud.virtualnetwork.updatesecuritylist],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when network security groups are created, updated or deleted. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles Network Security Group Changes (if any)4. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Networking and Event Types: Network Security Group – Change Compartment, Network Security Group – Create, Network Security Group - Delete and Network Security Group – Update5. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.**From CLI:**1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display name used>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-id>3. In the JSON output locate the Conditions key value pair and verify that the following conditions are present:com.oraclecloud.virtualnetwork.changenetworksecuritygroupcompartmentcom.oraclecloud.virtualnetwork.createnetworksecuritygroupcom.oraclecloud.virtualnetwork.deletenetworksecuritygroupcom.oraclecloud.virtualnetwork.updatenetworksecuritygroup4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Network Security Groups control traffic flowing between Virtual Network Cards attached to Compute instances. Monitoring and alerting on changes to Network Security Groups will help in identifying changes these security controls.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Networking in the Service Name Drop-down and selecting Network Security Group – Change Compartment, Network Security Group – Create, Network Security Group - Delete and Network Security Group – Update6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> } ] }, condition:{\eventType:[\com.oraclecloud.virtualnetwork.changenetworksecuritygroupcompartment,\com.oraclecloud.virtualnetwork.createnetworksecuritygroup,\com.oraclecloud.virtualnetwork.deletenetworksecuritygroup,\com.oraclecloud.virtualnetwork.updatenetworksecuritygroup],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

It is recommended to setup an Event Rule and Notification that gets triggered when Network Gateways are created, updated, deleted, attached, detached, or moved. This recommendation includes Internet Gateways, Dynamic Routing Gateways, Service Gateways, Local Peering Gateways, and NAT Gateways. Event Rules are compartment scoped and will detect events in child compartments, it is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Compartment that hosts the rules3. Find and click the Rule that handles Network Gateways Changes (if any)4. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Networking and Event Types: DRG – CreateDRG – DeleteDRG – UpdateDRG Attachment – CreateDRG Attachment – DeleteDRG Attachment – UpdateInternet Gateway – CreateInternet Gateway – DeleteInternet Gateway – UpdateInternet Gateway – Change CompartmentLocal Peering Gateway – CreateLocal Peering Gateway – Delete EndLocal Peering Gateway – UpdateLocal Peering Gateway – Change CompartmentNAT Gateway – CreateNAT Gateway – DeleteNAT Gateway – UpdateNAT Gateway – Change CompartmentService Gateway – CreateService Gateway – Delete EndService Gateway – UpdateService Gateway – Attach ServiceService Gateway – Detach ServiceService Gateway – Change Compartment5. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.**From CLI:**1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id <compartment-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-id>3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:com.oraclecloud.virtualnetwork.createdrgcom.oraclecloud.virtualnetwork.deletedrgcom.oraclecloud.virtualnetwork.updatedrgcom.oraclecloud.virtualnetwork.createdrgattachmentcom.oraclecloud.virtualnetwork.deletedrgattachmentcom.oraclecloud.virtualnetwork.updatedrgattachmentcom.oraclecloud.virtualnetwork.changeinternetgatewaycompartmentcom.oraclecloud.virtualnetwork.createinternetgatewaycom.oraclecloud.virtualnetwork.deleteinternetgatewaycom.oraclecloud.virtualnetwork.updateinternetgatewaycom.oraclecloud.virtualnetwork.changelocalpeeringgatewaycompartmentcom.oraclecloud.virtualnetwork.createlocalpeeringgatewaycom.oraclecloud.virtualnetwork.deletelocalpeeringgateway.endcom.oraclecloud.virtualnetwork.updatelocalpeeringgatewaycom.oraclecloud.natgateway.changenatgatewaycompartmentcom.oraclecloud.natgateway.createnatgatewaycom.oraclecloud.natgateway.deletenatgatewaycom.oraclecloud.natgateway.updatenatgatewaycom.oraclecloud.servicegateway.attachserviceidcom.oraclecloud.servicegateway.changeservicegatewaycompartmentcom.oraclecloud.servicegateway.createservicegatewaycom.oraclecloud.servicegateway.deleteservicegateway.endcom.oraclecloud.servicegateway.detachserviceidcom.oraclecloud.servicegateway.updateservicegateway4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Network Gateways act as routers between VCNs and the Internet, Oracle Services Networks, other VCNS, and on-premise networks.Monitoring and alerting on changes to Network Gateways will help in identifying changes to the security posture.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Networking in the Service Name Drop-down and selecting:DRG – CreateDRG – DeleteDRG – UpdateDRG Attachment – CreateDRG Attachment – DeleteDRG Attachment – UpdateInternet Gateway – CreateInternet Gateway – DeleteInternet Gateway – UpdateInternet Gateway – Change CompartmentLocal Peering Gateway – CreateLocal Peering Gateway – Delete EndLocal Peering Gateway – UpdateLocal Peering Gateway – Change CompartmentNAT Gateway – CreateNAT Gateway – DeleteNAT Gateway – UpdateNAT Gateway – Change CompartmentService Gateway – CreateService Gateway – Delete EndService Gateway – UpdateService Gateway – Attach ServiceService Gateway – Detach ServiceService Gateway – Change Compartment6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create Rule**From CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and `Compartment OCID````oci ons topic list --compartment-id <compartment-ocid> --all --query data [?name=='<topic_name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> } ] }, condition:{\eventType:[\com.oraclecloud.virtualnetwork.createdrg,\com.oraclecloud.virtualnetwork.deletedrg,\com.oraclecloud.virtualnetwork.updatedrg,\com.oraclecloud.virtualnetwork.createdrgattachment,\com.oraclecloud.virtualnetwork.deletedrgattachment,\com.oraclecloud.virtualnetwork.updatedrgattachment,\com.oraclecloud.virtualnetwork.changeinternetgatewaycompartment,\com.oraclecloud.virtualnetwork.createinternetgateway,\com.oraclecloud.virtualnetwork.deleteinternetgateway,\com.oraclecloud.virtualnetwork.updateinternetgateway,\com.oraclecloud.virtualnetwork.changelocalpeeringgatewaycompartment,\com.oraclecloud.virtualnetwork.createlocalpeeringgateway,\com.oraclecloud.virtualnetwork.deletelocalpeeringgateway.end,\com.oraclecloud.virtualnetwork.updatelocalpeeringgateway,\com.oraclecloud.natgateway.changenatgatewaycompartment,\com.oraclecloud.natgateway.createnatgateway,\com.oraclecloud.natgateway.deletenatgateway,\com.oraclecloud.natgateway.updatenatgateway,\com.oraclecloud.servicegateway.attachserviceid,\com.oraclecloud.servicegateway.changeservicegatewaycompartment,\com.oraclecloud.servicegateway.createservicegateway,\com.oraclecloud.servicegateway.deleteservicegateway.end,\com.oraclecloud.servicegateway.detachserviceid,\com.oraclecloud.servicegateway.updateservicegateway],\data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <compartment-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 2

4. Logging and Monitoring

VCN flow logs record details about traffic that has been accepted or rejected based on the security list rule.

**From Console (For Logging enabled Flow logs):**1. Go to the Virtual Cloud Network (VCN) page (https://cloud.oracle.com/networking/vcns)2. Select the Compartment 3. Click on the name of each VCN4. Click on each subnet within the VCN5. Under Resources click on Logs or the Monitoring tab6. Verify that there is a log enabled for the subnet7. Click the Log Name8. Verify Flowlogs Capture Filter is set to No filter (collecting all logs)9. If there is a Capture filter click the 'Capture Filter Name'10. Click Edit11. Verify Sampling rate is 100%12. Click Cancel13. Verify there is a in the Rules list that is: Enabled, Traffic disposition: All, Include/Exclude: Include, Source CIDR: Any, Destination CIDR: Any, IP Protocol: All**From Console (For Network Command Center Enabled Flow logs):**1. Go to the Network Command Center page (https://cloud.oracle.com/networking/network-command-center)2. Click on Flow Logs3. Click on the Flow log Name4. Click Edit5. Verify Sampling rate is 100% 6. Click Cancel7. Verify there is a in the Rules list that is: Enabled, Traffic disposition: All, Include/Exclude: Include, Source CIDR: Any, Destination CIDR: Any, IP Protocol: All

Enabling VCN flow logs will not affect the performance of your virtual network but it will generate additional use of object storage that should be controlled via object lifecycle management.By default, VCN flow logs are stored for 30 days in object storage. Users can specify a longer retention period.

Automated

Enabling VCN flow logs enables you to monitor traffic flowing within your virtual network and can be used to detect anomalous traffic.

**From Console:**First, if a Capture filter has not already been created, create a Capture Filter by the following steps:1. Go to the Network Command Center page (https://cloud.oracle.com/networking/network-command-center)2. Click 'Capture filters'3. Click 'Create Capture filter'4. Type a name for the Capture filter in the Name box.5. Select 'Flow log capture filter'6. For Sample rating select 100%7. Scroll to Rules8. For Traffic disposition select All9. For Include/Exclude select Include10. Level Source IPv4 CIDR or IPv6 prefix and Destination IPv4 CIDR or IPv6 prefix empty11. For IP protocol select Include12. Click Create Capture filterSecond, enable VCN flow logging for your VCN or subnet(s) by the following steps:1. Go to the Logs page (https://cloud.oracle.com/logging/logs)2. Click the Enable Service Log button in the middle of the screen.3. Select the relevant resource compartment.4. Select Virtual Cloud Networks - Flow logs from the Service drop down menu.5. Select the relevant resource level from the resource drop down menu either VCN or subnet.5. Select the relevant resource from the resource drop down menu.6. Select the from the Log Category drop down menu that either Flow Logs - subnet records or Flow Logs - vcn records.7. Select the Capture filter from above7. Type a name for your flow logs in the Log Name text box.7. Select the Compartment for the Log Location8. Select the Log Group for the Log Location or Click Create New Group to create a new log group8. Click the Enable Log button in the lower left-hand corner.

Level 1

4. Logging and Monitoring

Cloud Guard detects misconfigured resources and insecure activity within a tenancy and provides security administrators with the visibility to resolve these issues. Upon detection, Cloud Guard can suggest, assist, or take corrective actions to mitigate these issues. Cloud Guard should be enabled in the root compartment of your tenancy with the default configuration, activity detectors and responders.

**From Console:1. Type Cloud Guard into the Search box at the top of the Console.2. Click Cloud Guard from the Services submenu.3. View if Cloud Guard is enabledFrom CLI:**1. Retrieve the Cloud Guard status from the consoleoci cloud-guard configuration get --compartment-id <tenancy-ocid> --query 'data.status'2. Ensure the returned value is ENABLED`

There is no performance impact when enabling the above described features, but additional IAM policies will be required.

Automated

Cloud Guard provides an automated means to monitor a tenancy for resources that are configured in an insecure manner as well as risky network activity from these resources.

**From Console:**1. Type Cloud Guard into the Search box at the top of the Console.2. Click Cloud Guard from the Services submenu.3. Click Enable Cloud Guard.4. Click Create Policy.5. Click Next.6. Under Reporting Region, select a region.7. Under Compartments To Monitor, choose Select Compartment.8. Under Select Compartments, select the root compartment.9. Under Configuration Detector Recipe, select OCI Configuration Detector Recipe (Oracle Managed).10. Under Activity Detector Recipe, select OCI Activity Detector Recipe (Oracle Managed).11. Click Enable.**From CLI:**1. Create OCI IAM Policy for Cloud Guardoci iam policy create --compartment-id '<tenancy-id>' --name 'CloudGuardPolicies' --description 'Cloud Guard Access Policy' --statements '[ allow service cloudguard to read vaults in tenancy, allow service cloudguard to read keys in tenancy, allow service cloudguard to read compartments in tenancy, allow service cloudguard to read tenancies in tenancy, allow service cloudguard to read audit-events in tenancy, allow service cloudguard to read compute-management-family in tenancy, allow service cloudguard to read instance-family in tenancy, allow service cloudguard to read virtual-network-family in tenancy, allow service cloudguard to read volume-family in tenancy, allow service cloudguard to read database-family in tenancy, allow service cloudguard to read object-family in tenancy, allow service cloudguard to read load-balancers in tenancy, allow service cloudguard to read users in tenancy, allow service cloudguard to read groups in tenancy, allow service cloudguard to read policies in tenancy, allow service cloudguard to read dynamic-groups in tenancy, allow service cloudguard to read authentication-policies in tenancy ]'2. Enable Cloud Guard in root compartmentoci cloud-guard configuration update --reporting-region '<region-name>' --compartment-id '<tenancy-id>' --status 'ENABLED'

Level 1

4. Logging and Monitoring

Cloud Guard detects misconfigured resources and insecure activity within a tenancy and provides security administrators with the visibility to resolve these issues. Upon detection, Cloud Guard generates a Problem. It is recommended to setup an Event Rule and Notification that gets triggered when Oracle Cloud Guard Problems are created, dismissed or remediated. Event Rules are compartment scoped and will detect events in child compartments. It is recommended to create the Event rule at the root compartment level.

**From Console:**1. Go to the Events Service page: https://cloud.oracle.com/events/rules1. Select the Compartment that hosts the rules1. Find and click the Rule that handles Cloud Guard Changes (if any)1. Click the Edit Rule button and verify that the RuleConditions section contains a condition for the Service Cloud Guard and Event Types: Detected – Problem, Remediated – Problem, and Dismissed - Problem1. Verify that in the Actions section the Action Type contains: Notifications and that a valid Topic is referenced.**From CLI:**1. Find the OCID of the specific Event Rule based on Display Name and Compartment OCIDoci events rule list --compartment-id=<compartment OCID> --query data [?\display-name\=='<display name used>'].{id:id} --output table1. List the details of a specific Event Rule based on the OCID of the rule.1. In the JSON output locate the Conditions key-value pair and verify that the following Conditions are present: com.oraclecloud.cloudguard.problemdetected,com.oraclecloud.cloudguard.problemdismissed,com.oraclecloud.cloudguard.problemremediated1. Verify the value of the is-enabled attribute is true1. In the JSON output verify that actionType is ONS and locate the topic-id1. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id=<topic id> --query data.{name:name} --output table

There is no performance impact when enabling the above described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Cloud Guard provides an automated means to monitor a tenancy for resources that are configured in an insecure manner as well as risky network activity from these resources. Monitoring and alerting on Problems detected by Cloud Guard will help in identifying changes to the security posture.

**From Console:1. Go to the Events Service page: https://cloud.oracle.com/events/rules1. Select the compartment that should host the rule1. Click Create Rule1. Provide a Display Name and Description1. Create a Rule Condition by selecting Cloud Guard in the Service Name Drop-down and selecting: Detected – Problem, Remediated – Problem, and Dismissed - Problem1. In the Actions section select Notifications as Action Type1. Select the Compartment that hosts the Topic to be used.1. Select the Topic to be used1. Optionally add Tags to the Rule1. Click Create RuleFrom CLI:**1. Find the topic-id of the topic the Event Rule should use for sending Notifications by using the topic name and Compartment OCIDoci ons topic list --compartment-id=<compartment OCID> --all --query data [?name=='<topic_name>'].{name:name,topic_id:\topic-id\} --output table1. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic id> }] }, condition:{\eventType\:[\ com.oraclecloud.cloudguard.problemdetected\,\ com.oraclecloud.cloudguard.problemdismissed\,\ com.oraclecloud.cloudguard.problemremediated\],\data\:{}}, displayName: <display name>, description: <description>, isEnabled: true, compartmentId: compartment OCID}1. Create the actual event ruleoci events rule create --from-json file://event_rule.json1. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- Your tenancy might have a different Cloud Reporting region than your home region.- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

4. Logging and Monitoring

Oracle Cloud Infrastructure Vault securely stores master encryption keys that protect your encrypted data. You can use the Vault service to rotate keys to generate new cryptographic material. Periodically rotating keys limits the amount of data encrypted by one key version.

**From Console:1. Login into OCI Console.2. Select Identity & Security from the Services menu.3. Select Vault.4. Click on the individual Vault under the Name heading.5. Ensure the date of each Master Encryption key under the Created column of the Master Encryption key is no more than 365 days old, and that the key is in the ENABLED state6. Repeat for all Vaults in all compartmentsFrom CLI:**1. Execute the following for each Vault in each compartmentoci kms management key list --compartment-id '<compartment-id>' --endpoint '<management-endpoint-url>' --all --query data[*].[\time-created\,\display-name\,\lifecycle-state\]2. Ensure the date of the Master Encryption key is no more than 365 days old and is also in the ENABLED state.

Automated

Rotating keys annually limits the data encrypted under one key version. Key rotation thereby reduces the risk in case a key is ever compromised.

**From Console:**1. Login into OCI Console.2. Select Identity & Security from the Services menu.3. Select Vault.4. Click on the individual Vault under the Name heading.5. Click on the menu next to the time created.6. Click Rotate Key**From CLI:**1. Execute the following:oci kms management key rotate --key-id <key-ocid> --endpoint <management-endpoint-url>

Level 2

4. Logging and Monitoring

Object Storage write logs will log all write requests made to objects in a bucket.

**From Console:**1. Log in to the OCI Console.2. Go to Object Storage Buckets.3. Click on a bucket's name.4. Select Monitoring from the Resource menu.5. Scroll to Logs and ensure the Status for Write Access Events is Active.**From CLI:**1. List all buckets in the compartment:shoci os bucket list --compartment-id <compartment-id>2. Find the Log Group OCID:shoci logging log-group list --compartment-id <compartment-id> --query "data[?\display-name=='<log-group-name>']"3. List logs associated with the specific bucket:shoci logging log list --log-group-id <log-group-id> --query "data[?configuration.source.resource=='<bucket-name>']"4. Ensure a log entry exists for the target bucket's name.

Enabling object storage write logging does not impact object storage performance, but will consume additional storage for the logs themselves. By default, logs are retained for 30 days, but users may configure longer retention periods. To manage costs, implement object lifecycle policies to remove unneeded logs as appropriate.

Automated

Enabling Object Storage write logging ensures the requestAction property will show values like PUT, POST, or DELETE, providing increased visibility into changes made to objects within buckets.

**From Console:**1. Log in to the OCI Console.2. Go to Object Storage Buckets.3. Click the name of the bucket to configure.4. In the Resource menu, click Monitoring.5. Scroll to the Logs section.6. Find Write Access Events and click the three dots ... at the end of the row.7. Click Enable Log.8. Choose an existing log group or select Create new group.9. Configure the log name.10. Set a desired log retention period (in months).11. Click Enable log.**From CLI:***If a log group does not exist:*1. Create a log group:shoci logging log-group create --compartment-id <compartment-id> --display-name <display-name> --description <description>2. Check work request status:shoci logging work-request get --work-request-id <work-request-id>Wait until status is SUCCEEDED.*To enable write logging for your bucket(s):*3. Get the Log Group OCID:shoci logging log-group list --compartment-id <compartment-id> --query "data[?\display-name=='<display-name>'].id" --raw-output4. Create config.json with the following content (update all placeholders):json{ "compartment-id": "<compartment-id>", "source": { "resource": "<bucket-name>", "service": "ObjectStorage", "source-type": "OCISERVICE", "category": "write" }}5. Create the service log:shoci logging log create --log-group-id <log-group-id> --display-name <display-name> --log-type SERVICE --is-enabled TRUE --configuration file://config.json6. Confirm creation with work request id:shoci logging work-request get --work-request-id <work-request-id>Look for status SUCCEEDED.

Level 1

4. Logging and Monitoring

It is recommended that an Event Rule and Notification be set up when a user in the via OCI local authentication. Event Rules are compartment-scoped and will detect events in child compartments. This Event rule is required to be created at the root compartment level.

From Console:1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Root Compartment that hosts the rules3. Click the Rule that handles Identity SignOn Changes (if any)4. Click the Edit Rule button and verify that the RuleConditions section contains a condition Event Type for the Service Identity SignOn and Event Types: Interactive Login 5. On the Action Type contains: Notifications and that a valid Topic is referenced.From CLI:1. Find the OCID of the specific Event Rule based on Display Name and Tenancy OCIDoci events rule list --compartment-id <tenancy-ocid> --query data [?\display-name\=='<display-name>'].{id:id} --output table2. List the details of a specific Event Rule based on the OCID of the rule.oci events rule get --rule-id <rule-id>3. In the JSON output locate the Conditions key value pair and verify that the following Conditions are present:com.oraclecloud.identitysignon.interactivelogin4. Verify the value of the is-enabled attribute is true5. In the JSON output verify that actionType is ONS and locate the topic-id6. Verify the correct topic is used by checking the topic nameoci ons topic get --topic-id <topic-id> --query data.{name:name} --output table

There is no performance impact when enabling the above-described features but depending on the amount of notifications sent per month there may be a cost associated.

Automated

Users should rarely use OCI local authenticated and be authenticated via organizational standard Identity providers, not local credentials. Access in this matter would represent a break glass activity and should be monitored to see if changes made impact the security posture.

From Console:1. Go to the Events Service page: https://cloud.oracle.com/events/rules2. Select the Root compartment that should host the rule3. Click Create Rule4. Provide a Display Name and Description5. Create a Rule Condition by selecting Identity SignOn in the Service Name Drop-down and selecting Interactive Login6. In the Actions section select Notifications as Action Type7. Select the Compartment that hosts the Topic to be used.8. Select the Topic to be used9. Optionally add Tags to the Rule10. Click Create RuleFrom CLI:1. Find the topic-id of the topic the Event Rule should use for sending notifications by using the topic name and `Tenancy OCID````oci ons topic list --compartment-id <tenacy-ocid> --all --query data [?name=='<topic-name>'].{name:name,topic_id:\topic-id} --output table2. Create a JSON file to be used when creating the Event Rule. Replace topic id, display name, description and compartment OCID.{ actions: { actions: [ { actionType: ONS, isEnabled: true, topicId: <topic-id> }] }, condition:{\eventType:[\com.oraclecloud.identitysignon.interactivelogin,data:{}}, displayName: <display-name>, description: <description>, isEnabled: true, compartmentId: <tenancy-ocid>}3. Create the actual event ruleoci events rule create --from-json file://event_rule.json```4. Note in the JSON returned that it lists the parameters specified in the JSON file provided and that there is an OCID provided for the Event Rule

'- The same Notification topic can be reused by many Event Rules.- The generated notification will include an eventID that can be used when querying the Audit Logs in case further investigation is required.

Level 1

5. Storage

5.1 Object Storage

A bucket is a logical container for storing objects. It is associated with a single compartment that has policies that determine what action a user can perform on a bucket and on all the objects in the bucket. By Default a newly created bucket is private. It is recommended that no bucket be publicly accessible.

From Console:1. Login into the OCI Console2. Click in the search bar at the top of the screen.3. Type Advanced Resource Query and click enter.4. Click the Advanced Resource Query button in the upper right of the screen.5. Enter the following query in the query box:querybucket resourceswhere (publicAccessType == 'ObjectRead') || (publicAccessType == 'ObjectReadWithoutList')6. Ensure query returns no resultsFrom CLI:1. Execute the following command:oci search resource structured-search --query-text query bucket resourceswhere (publicAccessType == 'ObjectRead') || (publicAccessType == 'ObjectReadWithoutList')2. Ensure query returns no resultsCloud GuardTo Enable Cloud Guard Auditing:Ensure Cloud Guard is enabled in the root compartment of the tenancy. For more information about enabling Cloud Guard, please look at the instructions included in Recommendation 3.15. **From Console:**1. Type Cloud Guard into the Search box at the top of the Console. 2. Click Cloud Guard from the “Services” submenu.3. Click Detector Recipes in the Cloud Guard menu.4. Click OCI Configuration Detector Recipe (Oracle Managed) under the Recipe Name column.5. Find Bucket is public in the Detector Rules column.6. Verify that the Bucket is public Detector Rule is Enabled.**From CLI:**1. Verify the Bucket is public Detector Rule in Cloud Guard is enabled to generate Problems if Object Storage Buckets are configured to be accessible over the public Internet with the following command:oci cloud-guard detector-recipe-detector-rule get --detector-recipe-id <insert detector recipe ocid> --detector-rule-id BUCKET_IS_PUBLIC

For updating an existing bucket, care should be taken to ensure objects in the bucket can be accessed through either IAM policies or pre-authenticated requests.

Automated

Removing unfettered reading of objects in a bucket reduces an organization's exposure to data loss.

**From Console:**1. Follow the audit procedure above. 2. For each bucket in the returned results, click the Bucket Display Name3. Click Edit Visibility3. Select Private4. Click Save Changes**From CLI:**1. Follow the audit procedure2. For each of the buckets identified, execute the following command:oci os bucket update --bucket-name <bucket-name> --public-access-type NoPublicAccess

Level 2

5. Storage

5.1 Object Storage

Oracle Object Storage buckets support encryption with a Customer Managed Key (CMK). By default, Object Storage buckets are encrypted with an Oracle managed key.

**From Console:1. Go to https://cloud.oracle.com/object-storage/buckets1. Click on an individual bucket under the Name heading.1. Ensure that the Encryption Key is not set to Oracle managed key.1. Repeat for each compartmentFrom CLI:**1. Execute the following commandoci os bucket get --bucket-name <bucket-name>2. Ensure kms-key-id is not nullCloud GuardTo Enable Cloud Guard Auditing:Ensure Cloud Guard is enabled in the root compartment of the tenancy. For more information about enabling Cloud Guard, please look at the instructions included in Recommendation 3.15. **From Console:**1. Type Cloud Guard into the Search box at the top of the Console. 2. Click Cloud Guard from the “Services” submenu.3. Click Detector Recipes in the Cloud Guard menu.4. Click OCI Configuration Detector Recipe (Oracle Managed) under the Recipe Name column.5. Find Object Storage bucket is encrypted with Oracle-managed key in the Detector Rules column.6. Verify that the Object Storage bucket is encrypted with Oracle-managed key Detector Rule is Enabled.**From CLI:**1. Verify the Object Storage bucket is encrypted with Oracle-managed key Detector Rule in Cloud Guard is enabled to generate Problems if Object Storage Buckets are configured without a customer managed key with the following command:oci cloud-guard detector-recipe-detector-rule get --detector-recipe-id <insert detector recipe ocid> --detector-rule-id BUCKET_ENCRYPTED_WITH_ORACLE_MANAGED_KEY

Encrypting with a Customer Managed Keys requires a Vault and a Customer Master Key. In addition, you must authorize Object Storage service to use keys on your behalf.Required Policy:Allow service objectstorage-<region_name>, to use keys in compartment <compartment-id> where target.key.id = '<key_OCID>'

Automated

Encryption of Object Storage buckets with a Customer Managed Key (CMK) provides an additional level of security on your data by allowing you to manage your own encryption key lifecycle management for the bucket.

**From Console:**1. Go to https://cloud.oracle.com/object-storage/buckets1. Click on an individual bucket under the Name heading.1. Click Assign next to Encryption Key: Oracle managed key.1. Select a Vault1. Select a Master Encryption Key1. Click Assign**From CLI:**1. Execute the following commandoci os bucket update --bucket-name <bucket-name> --kms-key-id <master-encryption-key-id>

Level 2

5. Storage

5.1 Object Storage

A bucket is a logical container for storing objects. Object versioning is enabled at the bucket level and is disabled by default upon creation. Versioning directs Object Storage to automatically create an object version each time a new object is uploaded, an existing object is overwritten, or when an object is deleted. You can enable object versioning at bucket creation time or later.

**From Console:1. Login to OCI Console.2. Select Storage from the Services menu.3. Select Buckets from under the Object Storage & Archive Storage section.4. Click on an individual bucket under the Name heading.5. Ensure that the Object Versioning is set to Enabled.6. Repeat for each compartmentFrom CLI:**1. Execute the following command:for region in $(oci iam region-subscription list --all | jq -r '.data[] | .region-name')do echo Enumerating region $region for compid in $(oci iam compartment list --include-root --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id') do echo Enumerating compartment $compid for bkt in $(oci os bucket list --compartment-id $compid --region $region 2>/dev/null | jq -r '.data[] | .name') do output=$(oci os bucket get --bucket-name $bkt --region $region 2>/dev/null | jq -r '.data | select(.versioning == Disabled).name') if [ ! -z $output ]; then echo $output; fi done donedone2. Ensure no results are returned.

Automated

Versioning object storage buckets provides for additional integrity of your data. Management of data integrity is critical to protecting and accessing protected data. Some customers want to identify object storage buckets without versioning in order to apply their own data lifecycle protection and management policy.

**From Console:**1. Follow the audit procedure above.2. For each bucket in the returned results, click the Bucket Display Name3. Click Edit next to Object Versioning: Disabled4. Click Enable Versioning**From CLI:**1. Follow the audit procedure2. For each of the buckets identified, execute the following command:oci os bucket update --bucket-name <bucket name> --versioning Enabled

Level 2

5. Storage

5.2 Block Volumes

Oracle Cloud Infrastructure Block Volume service lets you dynamically provision and manage block storage volumes. By default, the Oracle service manages the keys that encrypt block volumes. Block Volumes can also be encrypted using a customer managed key.Terminated Block Volumes cannot be recovered and any data on a terminated volume is permanently lost. However, Block Volumes can exist in a terminated state within the OCI Portal and CLI for some time after deleting. As such, any Block Volumes in this state should not be considered when assessing this policy.

**From Console:**1. Login to the OCI Console.2. Click the search bar at the top of the screen.3. Type 'Advanced Resource Query' and press return.4. Click Advanced resource query.5. Enter the following query in the query box:query volume resources6. For each block volume returned, click the link under Display name.7. Ensure the value for Encryption Key is not Oracle-managed key.8. Repeat for other subscribed regions.**From CLI:**1. Execute the following command:for region in $(oci iam region-subscription list --all| jq -r '.data[] | .region-name')do echo Enumerating region: $region for compid in `oci iam compartment list --compartment-id-in-subtree TRUE 2>/dev/null | jq -r '.data[] | .id'` do echo Enumerating compartment: $compid for bvid in `oci bv volume list --compartment-id $compid --region $region 2>/dev/null | jq -r '.data[] | select(.kms-key-id == null).id'` do output=`oci bv volume get --volume-id $bvid --region $region --query=data.{name:\display-name\,id:id} --output table 2>/dev/null` if [ ! -z $output ]; then echo $output; fi done done done2. Ensure the query returns no results.

Encrypting with a Customer Managed Key requires a Vault and a Customer Master Key. In addition, you must authorize the Block Volume service to use the keys you create.Required IAM Policy:Allow service blockstorage to use keys in compartment <compartment-id> where target.key.id = '<key_OCID>'

Automated

Encryption of block volumes provides an additional level of security for your data. Management of encryption keys is critical to protecting and accessing protected data. Customers should identify block volumes encrypted with Oracle service managed keys in order to determine if they want to manage the keys for certain volumes and then apply their own key lifecycle management to the selected block volumes.

**From Console:**1. Follow the audit procedure above.2. For each block volume returned, click the link under Display name.3. If the value for Encryption Key is Oracle-managed key, click Assign next to Oracle-managed key.4. Select a Vault Compartment and Vault.5. Select a Master Encryption Key Compartment and Master Encryption key.6. Click Assign.**From CLI:**1. Follow the audit procedure.2. For each boot volume identified, get the OCID.3. Execute the following command:oci bv volume-kms-key update –volume-id <volume OCID> --kms-key-id <kms key OCID>

Level 2

5. Storage

5.2 Block Volumes

When you launch a virtual machine (VM) or bare metal instance based on a platform image or custom image, a new boot volume for the instance is created in the same compartment. That boot volume is associated with that instance until you terminate the instance. By default, the Oracle service manages the keys that encrypt this boot volume. Boot Volumes can also be encrypted using a customer managed key.

**From Console:1. Login into the OCI Console2. Click in the search bar, top of the screen.3. Type Advanced Resource Query and click enter.4. Click the Advanced Resource Query button in the upper right of the screen.5. Enter the following query in the query box:query bootvolume resources6. For each boot volume returned click on the link under Display name7. Ensure Encryption Key does not say Oracle managed key8. Repeat for other subscribed regionsFrom CLI:**1. Execute the following command:for region in `oci iam region list | jq -r '.data[] | .name'`; do for bvid in `oci search resource structured-search --region $region --query-text query bootvolume resources 2>/dev/null | jq -r '.data.items[] | .identifier'` do output=`oci bv boot-volume get --boot-volume-id $bvid 2>/dev/null | jq -r '.data | select(.kms-key-id == null).id'` if [ ! -z $output ]; then echo $output; fi done done2. Ensure query returns no results.

Encrypting with a Customer Managed Keys requires a Vault and a Customer Master Key. In addition, you must authorize the Boot Volume service to use the keys you create.Required IAM Policy:Allow service Bootstorage to use keys in compartment <compartment-id> where target.key.id = '<key_OCID>'

Automated

Encryption of boot volumes provides an additional level of security for your data. Management of encryption keys is critical to protecting and accessing protected data. Customers should identify boot volumes encrypted with Oracle service managed keys in order to determine if they want to manage the keys for certain boot volumes and then apply their own key lifecycle management to the selected boot volumes.

**From Console:**1. Follow the audit procedure above.2. For each Boot Volume in the returned results, click the Boot Volume name3. Click Assign next to Encryption Key4. Select the Vault Compartment and Vault5. Select the Master Encryption Key Compartment and Master Encryption key6. Click Assign**From CLI:**1. Follow the audit procedure.2. For each boot volume identified get its OCID. Execute the following command:oci bv boot-volume-kms-key update --boot-volume-id <Boot Volume OCID> --kms-key-id <KMS Key OCID>

Level 2

5. Storage

5.3 File Storage Service

Oracle Cloud Infrastructure File Storage service (FSS) provides a durable, scalable, secure, enterprise-grade network file system. By default, the Oracle service manages the keys that encrypt FSS file systems. FSS file systems can also be encrypted using a customer managed key.

**From Console:1. Login into the OCI Console2. Click in the search bar, top of the screen.3. Type Advanced Resource Query and click enter.4. Click the Advanced Resource Query button in the upper right of the screen.5. Enter the following query in the query box:query filesystem resources6. For each file storage system returned click on the link under Display name7. Ensure Encryption Key does not say Oracle-managed key8. Repeat for other subscribed regionsFrom CLI:**1. Execute the following command:for region in `oci iam region list | jq -r '.data[] | .name'`; do for fssid in `oci search resource structured-search --region $region --query-text query filesystem resources 2>/dev/null | jq -r '.data.items[] | .identifier'` do output=`oci fs file-system get --file-system-id $fssid --region $region 2>/dev/null | jq -r '.data | select(.kms-key-id == ).id'` if [ ! -z $output ]; then echo $output; fi done done2. Ensure query returns no results

Encrypting with a Customer Managed Keys requires a Vault and a Customer Master Key. In addition, you must authorize the File Storage service to use the keys you create.Required IAM Policy:Allow service FssOc1Prod to use keys in compartment <compartment-id> where target.key.id = '<key_OCID>'

Automated

Encryption of FSS systems provides an additional level of security for your data. Management of encryption keys is critical to protecting and accessing protected data. Customers should identify FSS file systems that are encrypted with Oracle service managed keys in order to determine if they want to manage the keys for certain FSS file systems and then apply their own key lifecycle management to the selected FSS file systems.

From Console:1. Follow the audit procedure above.2. For each File Storage System in the returned results, click the File System Storage3. Click Edit next to Encryption Key4. Select Encrypt using customer-managed keys5. Select the Vault Compartment and Vault6. Select the Master Encryption Key Compartment and Master Encryption key7. Click Save Changes**From CLI:**1. Follow the audit procedure.2. For each File Storage System identified get its OCID. Execute the following command:oci bv volume-kms-key update –volume-id <volume OCID> --kms-key-id <kms key OCID>

Level 1

6. Asset Management

When you sign up for Oracle Cloud Infrastructure, Oracle creates your tenancy, which is the root compartment that holds all your cloud resources. You then create additional compartments within the tenancy (root compartment) and corresponding policies to control access to the resources in each compartment. Compartments allow you to organize and control access to your cloud resources. A compartment is a collection of related resources (such as instances, databases, virtual cloud networks, block volumes) that can be accessed only by certain groups that have been given permission by an administrator.

**From Console:1. Login into the OCI Console.1. Click in the search bar, top of the screen.1. Type Advanced Resource Query and hit enter.1. Click the Advanced Resource Query button in the upper right of the screen.1. Enter the following query in the query box:query compartment resourceswhere (compartmentId='<tenancy-id>' && lifecycleState='ACTIVE')6. Ensure query returns at least one compartment in addition to the ManagedCompartmentForPaaS compartmentFrom CLI:**1. Execute the following commandoci search resource structured-search --query-text query compartment resourceswhere (compartmentId='<tenancy-id>' && lifecycleState='ACTIVE')2. Ensure items are returned.

Once the compartment is created an OCI IAM policy must be created to allow a group to resources in the compartment otherwise only group with tenancy access will have access.

Automated

Compartments are a logical group that adds an extra layer of isolation, organization and authorization making it harder for unauthorized users to gain access to OCI resources.

**From Console:**1. Login to OCI Console.1. Select Identity from the Services menu.1. Select Compartments from the Identity menu.1. Click Create Compartment1. Enter a Name1. Enter a Description1. Select the root compartment as the Parent Compartment1. Click Create Compartment**From CLI:**1. Execute the following commandoci iam compartment create --compartment-id '<tenancy-id>' --name '<compartment-name>' --description '<compartment description>'

Level 1

6. Asset Management

When you create a cloud resource such as an instance, block volume, or cloud network, you must specify to which compartment you want the resource to belong. Placing resources in the root compartment makes it difficult to organize and isolate those resources.

**From Console:**1. Login into the OCI Console.2. Click in the search bar, top of the screen.3. Type Advance Resource Query and hit enter.4. Click the Advanced Resource Query button in the upper right of the screen.5. Enter the following query into the query box:query VCN, instance, bootvolume, volume, filesystem, bucket, autonomousdatabase, database, dbsystem resources where compartmentId = '<tenancy-id>'6. Ensure query returns no results.**From CLI:**1. Execute the following command:oci search resource structured-search --query-text query VCN, instance, volume, bootvolume, filesystem, bucket, autonomousdatabase, database, dbsystem resources where compartmentId = '<tenancy-id>'2. Ensure query return no results.

Placing a resource in a compartment will impact how you write policies to manage access and organize that resource.

Automated

Placing resources into a compartment will allow you to organize and have more granular access controls to your cloud resources.

**From Console:**1. Follow audit procedure above.2. For each item in the returned results, click the item name.3. Then select Move Resource or More Actions then Move Resource.4. Select a compartment that is not the root compartment in CHOOSE NEW COMPARTMENT.5. Click Move Resource.**From CLI:**1. Follow the audit procedure above.2. For each bucket item execute the below command: oci os bucket update --bucket-name <bucket-name> --compartment-id <not root compartment-id>3. For other resources use the change-compartment command for the resource type: oci <service-command> <resource-command> change-compartment --<item-id> <item-id> --compartment-id <not root compartment-id> i. Example for an Autonomous Database:oci db autonomous-database change-compartment --autonomous-database-id <autonmous-database-id> --compartment-id <not root compartment-id>