Introduction

In this blog series we are going to discuss Oracle Cloud Infrastructure (OCI) networking best practices and provide you with some recommendations and tips to help you design, build, secure and manage your OCI network infrastructure.  This is the second blog in this series and will cover OCI network security.  The topics for this blog series are outlined below:

• Part One - OCI Network Design, VCN, and Subnets Best Practices, Recommendations, and Tips
• Part Two - OCI Network Security Best Practices, Recommendations, and Tips
• Part Three - OCI Network Connectivity Best Practices, Recommendations, and Tips
• Part Four - OCI Network Monitoring, Observability, and Management Best Practices, Recommendations, and Tips
• This blog series has also been adapted and published as a Solution Playbook in the Oracle Architecture Center

Leverage The CIS OCI Landing Zone Quick Start Template

Rationale

The Center for Internet Security (CIS) is a community-driven nonprofit organization that has created CIS Controls and CIS Benchmarks to help customers secure their IT systems and data across different vendors and environments.  CIS Benchmarks are best practices for the secure configuration of a target system and are developed through a unique consensus-based process comprised of cybersecurity professionals and subject matter experts around the world.  

We have created a CIS OCI Landing Zone Quick Start Template that enables OCI customers to quickly implement the CIS OCI Foundations Benchmark and overall OCI best practices within their tenancy.

For more information regarding CIS visit www.cisecurity.org/.

Using the CIS OCI Landing Zone Quick Start Template enables customers to quickly deploy the core infrastructure needed for their tenancy while meeting the CIS OCI Benchmarks.  Some of the resources that the CIS OCI Landing Zone Quick Start Template helps you deploy and configure are:

• Compartments
• Identity and Access Management (IAM)
• Networking
• Keys
• Cloud Guard
• Vulnerability Scanning
• Logging
• Events
• Notifications
• Object Storage

For more information on the CIS OCI Landing Zone Quick Start Template see the below links:

https://github.com/oracle-quickstart/oci-cis-landingzone-quickstart

https://www.ateam-oracle.com/post/cis-oci-landing-zone-quick-start-template

https://www.ateam-oracle.com/post/cis-oci-landing-zone-quick-start-template-version-2

https://docs.oracle.com/en/solutions/cis-oci-benchmark/index.html

Recommendation

• Make sure you understand Terraform as the CIS OCI Landing Zone Quick Start Template uses Terraform as the underlying code to deploy the infrastructure
• Start by reading the README.md, FAQ.md, and DEPLOYMENT-GUIDE.md files

Use Network Security Groups 

Rationale

Security lists let you define a set of security rules that applies to all of the VNICs in an entire subnet, whereas Network Security Groups (NSG) provide more granular filtering and control of traffic flowing to and from an individual or group of virtual network interface cards (VNIC) controlled by the NSG.  NSG approach allows customers to implement a microsegmentation strategy inside OCI and reduce the total attack surface of a network security incident. 

As an example, if you allow Secure Shell (SSH) in a security list rule you will end up allowing SSH to all VNICs in that subnet.  Allowing SSH in a NSG will only allow it to the VNICs that are associated with that NSG, if there is no rule in the corresponding security list (NOTE: See the tip below for understanding how security lists and NSGs operate if they are used together).

Oracle recommends using NSGs for components that all have the same security posture. For example, in a multi-tier architecture, you would have a separate NSG for each tier. A given tier's VNICs would all belong to that tier's NSG. Within a given tier, you might have a particular subset of the tier's VNICs that have additional, special security requirements. Therefore you would create another NSG for those additional rules, and place that subset of VNICs into both the tier's NSG and the additional NSG.

Oracle also recommends using NSGs because Oracle will prioritize NSGs over security lists when implementing future enhancements.

More information on Network Security Groups can be found here: OCI Network Security Groups

Recommendation

• Create NSGs for specific groups of resources that have the same traffic flow requirements, such as NSG for each tier of an application
• Take a whitelist approach to all security list and NSG rules and only allow the specific sources, protocols, and ports that is required by your application or workload
• Resist the urge to allow large sources, protocols, and ports because you are unsure what is specifically required
• If you do allow large sources, protocols, and ports, only do so temporarily (such as for troubleshooting) and lock them down later

Tip: When mixing both NSG and security lists together, the most union of the two is enforced.  This means that a packet in question is allowed if any rule in any of the relevant security lists or NGS allows the traffic.  For example, if your security list allows SSH from all sources (0.0.0.0/0) but your NSG does not, the VNICs in that subnet and associated with that NSG will permit SSH from all sources because the security list rule allows it.      

Tip: When allowing traffic in an NSG or security list temporarily, such as allowing Internet Control Message Protocol (ICMP) for troubleshooting, make a note in the rule description when you create it that this is temporary and can be deleted later.  I have seen customers often forget to remove the rule when they are done, and when reviewing the rules in the future they are hesitant to remove them because they are unsure if it's required or not.  

Tip: Take a look at the network security section of the Oracle Cloud Foundation

 Utilize the OCI Bastion Service

Rationale

The OCI Bastion Service provides an alternative method to securely access your resources compared to the traditional method of deploying a bastion host in a public subnet.  The OCI Bastion Service has the following benefits:

• Lower cost
• Integrates with IAM for seamless control and restrict access
• Less complexity (no public subnet or host needed)
• Bastion sessions are time-limited
• OCI managed service
• Administrative actions like who/when/created/deleted/updated/fetched are recorded and logged in OCI Events and Audit service

More information on the OCI Bastion Service can be found here: OCI Bastion Service

Recommendation

• Familiarize yourself with OCI Bastion Service and utilize it instead of provisioning a bastion host in a public subnet
• Lock down access to the Bastion Service via IAM policies

Restrict Access to OCI Network Resources with IAM Policies

Rationale

The OCI IAM service lets you control who has access to your cloud resources.  You can control what type of access a group of users has and to which specific resources.  Network resources that you provision inside of OCI are typically part of the core building blocks in your architecture that your applications and workloads depend on.  Restricting access to these network resources is an important part of your OCI security and IAM design to help prevent unauthorized users from creating or changing these resources that could lead to downtime or security holes.

Recommendation

• Start with the simplest approach by creating a policy to let network admins manage a cloud network
• For a more advanced approach, create policies to restrict access to individual network resources.  For example, creating separate policies to let one group of admins manage the Dynamic Routing Gateways (DRG), another group of admins manage Virtual Cloud Networks (VCN), etc. 
• Consider read-only policies that are necessary for non network admins to have access to, such as:
  • Network Visualizer
  • Network Path Analyzer
• Limit the usage of the 'use' and 'manage' verbs in your IAM policies for the virtual-network-family
• See IAM Policies for Networking for more information
• Your OCI network IAM policies and design should be one piece of your overall OCI IAM policy and design

Tip: Oracle documentation has many common IAM policies documented here.

Consider Deploying the OCI Network Firewall or a 3rd Party Firewall for More Network Security Capabilities

Rationale

Many customers have network security requirements that require more functionality, features, and capabilities than what the native Security Lists or Network Security Groups in OCI provide.  To meet those requirements, the OCI recommendation is to deploy either the OCI Network Firewall or a 3rd party firewall.  These firewalls typically bring next-generation firewall capabilities such as intrusion detection and prevention (IDPS), url filtering, and Secure Socket Layer (SSL) inspection.

Recommendation

• Check with your preferred 3rd party firewall vendor to see if they support their platform on OCI
• Investigate if using the native OCI Network Firewall will meet your requirements
• Use the hub and spoke VCN design and place the firewall(s) in a hub VCN and use the DRG to route the traffic through the firewalls
• Understand the impact to network performance by routing traffic through a firewall in OCI, such as throughput and latency

Tip: Try out the OCI Network Firewall using Oracle Live Labs here.

Stay tuned for Part Three of this blog series which will focus on OCI Network Connectivity Best Practices, Recommendations, and Tips