Skip to main content

More Info:

Ensure Event Rules track changes to Internet, NAT, and Service Gateways. Gateway modifications directly impact the ingress and egress routing perimeters of your secure networks.

Risk Level

Medium

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Well Architected Framework
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS AWS
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • Cloudanix Best Practice
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • HIPAA
  • HITRUST CSF
  • ISO 27001
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST CSF
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

Below are the exact steps in the OCI Console to ensure you have an Event Rule that alerts on network gateway changes (e.g., Internet Gateways, NAT Gateways, DRGs) using Events + Notifications.

1. Create (or verify) a Notifications Topic

  1. In the OCI Console, open the menu and go to:
    Developer Services → Application Integration → Notifications
  2. Click Topics (left side) → Create Topic.
  3. Enter:
    • Name: e.g., network-gateway-changes-topic
    • Description: e.g., Alerts for OCI network gateway changes
  4. Click Create.

Add a subscription (email example)

  1. Open the topic you just created.
  2. Click Create Subscription.
  3. Protocol: Email
    Endpoint: enter your email address.
  4. Click Create.
  5. Confirm the subscription via the email you receive (must click the confirmation link).

2. Create the Event Rule for Network Gateway Changes

  1. From the main menu go to:
    Observability & Management → Events Service → Rules
  2. Click Create Rule.

Rule Details

  1. Name: e.g., network-gateway-change-rule
  2. Description: e.g., Triggers when OCI network gateways are created, updated, or deleted
  3. Compartment: select the compartment that contains the gateways you want to monitor.
  4. Rule Status: ensure it is Enabled.

Define the Events (Conditions)

  1. Under Rule Conditions, choose:
    • Rule Type: Event Rules (when an event occurs)
  2. In Event Type, filter by Service = Virtual Cloud Network (or similar naming; varies slightly by console version).
  3. Select all event types relevant to network gateways, for example (names may vary slightly by region/tenancy, but look for): For Internet Gateway:
    • CreateInternetGateway
    • UpdateInternetGateway
    • DeleteInternetGateway
    • (sometimes prefixed as com.oraclecloud.virtualnetwork.createinternetgateway, etc.)
    For NAT Gateway:
    • CreateNatGateway
    • UpdateNatGateway
    • DeleteNatGateway
    For Dynamic Routing Gateway (DRG), if desired:
    • CreateDrg
    • UpdateDrg
    • DeleteDrg
    • AttachDrgRouteTable, UpdateDrgRouteTable, etc. (if you want route change alerts as well)
    Include all gateway types you require according to your policy.
If the UI only offers a generic filter builder, choose:
  • Service: virtualnetwork
  • Event Type: then select the specific gateway events from the dropdown.

3. Add the Action (Send to Notifications)

  1. In Actions, choose Notifications.
  2. Compartment: same compartment where the topic exists.
  3. Topic: select the topic you created earlier:
    network-gateway-changes-topic
  4. (Optional) Add tags for governance.
  5. Click Create Rule.

4. Verify

  • Perform a test change in a non‑production compartment (e.g., update the display name of an Internet Gateway).
  • Confirm that:
    • An Event is visible under Events Service → Events.
    • You receive an email notification (or whatever subscription you configured).
This completes remediation for: “OCI Monitoring Should Have Event Rule For Network Gateway Changes” using the OCI Console.
Below is a minimal end‑to‑end approach using OCI CLI to:
  1. Create a Notifications topic
  2. (Optionally) add an email subscription
  3. Create an OCI Events rule that fires on network gateway changes and sends alerts to the topic
You can adjust to your tenancy/compartment as needed.

0. Prerequisites

  • OCI CLI configured (oci setup config)
  • Your compartment OCID
  • A region where Events and Notifications are enabled
  • IAM policy that allows Events service to publish to Notifications, for example at tenancy or target compartment level:

1. Create a Notifications Topic

Capture the returned topic-id (OCID). For convenience:

2. (Optional) Add an Email Subscription

Confirm the subscription from the email you receive.

3. Prepare the Event Rule Condition

Create a JSON file gateway-events-condition.json:
You can add/remove specific event types as required.
(Full list is in the Events service docs for Virtual Cloud Network / gateway resources.)

4. Create the Event Rule

This rule:
  • Listens for the specified network gateway events (Internet Gateway, NAT Gateway, Service Gateway, Local Peering Gateway, DRG, etc.)
  • Sends a notification to the specified Notifications topic when any of them occur

5. (Optional) Verify the Rule

List rules in the compartment:
Get rule details:
You now have OCI monitoring/alerting for network gateway configuration changes via Events + Notifications, created entirely with OCI CLI.
Below is a minimal, step‑by‑step way to ensure OCI Events raises alerts when Network Gateway resources change, using Python + OCI SDK.You will:
  1. Create a Notifications topic (if you don’t already have one).
  2. (Optionally) Add a subscription (email, Slack via HTTPS, etc.).
  3. Create an Event Rule that listens for Network Gateway changes and sends them to the topic.

0. Prerequisites

  • oci SDK installed:
  • ~/.oci/config correctly set up with:
    • tenancy
    • user
    • fingerprint
    • key_file
    • region
    • a profile name (e.g. DEFAULT)
  • Have your compartment OCID ready: compartment_id = "ocid1.compartment.oc1...."

1. Decide Which Gateways / Events You Want

Common network gateway types in OCI:
  • Internet Gateway (com.oraclecloud.virtualnetwork.internetgateway)
  • NAT Gateway (com.oraclecloud.virtualnetwork.natgateway)
  • Dynamic Routing Gateway, DRG (com.oraclecloud.virtualnetwork.drg)
  • Service Gateway (com.oraclecloud.virtualnetwork.servicegateway)
  • Local Peering Gateway, LPG (com.oraclecloud.virtualnetwork.localpeeringgateway)
Common event types:
  • com.oraclecloud.virtualnetwork.create*
  • com.oraclecloud.virtualnetwork.update*
  • com.oraclecloud.virtualnetwork.delete*
You can match all events under the Network service or only specific ones with eventType.

2. Example Python Script (End‑to‑End)

This script:
  • Creates a Notifications topic (if not present).
  • Adds an email subscription.
  • Creates an Event Rule for Network Gateway changes.
  • Routes Events → Notifications topic → your email (or other endpoint).

3. How This Satisfies “Monitoring / Alerting”

  • Monitoring: OCI Events listens for control‑plane events (create / update / delete) on gateway resources.
  • Alerting: Events rule sends those events to an OCI Notifications topic.
    • Subscriptions (email, HTTPS, Slack via Webhook, PagerDuty etc.) receive alerts on each event.
If you want to integrate with OCI Monitoring service alarms instead, you would typically:
  • Use Events → Notifications → Function (optional) to write metrics.
  • Or directly set up Monitoring metrics + alarms for data‑plane metrics (e.g., gateway traffic) — which is separate from “config change” events.
If you tell me your exact gateway types and where you want alerts (email, Slack, webhook, etc.), I can adjust the event pattern and action code accordingly.
This change is an in-place update if the rule already exists; it does not force replacement of the rule or any gateway resources.For verification, terraform plan should show either:
  • a new oci_events_rule.network_gateway_changes to be created, or
  • an update to the existing rule where the condition (and possibly actions) argument changes to match the configuration above.