Enable Security Operations
Security is consistently among the top concerns when enterprises begin the process of cloud adoption.
Because cloud development is rapid, your chief information security officer (CISO) and related teams often ask questions about security before your first workload is deployed in the cloud. Questions might include the following examples:
- How do we know if any misconfigurations and risky activities occur in the cloud?
- How do we shorten the response time when an incident happens?
- How do we enforce security best practices?
- How do we integrate cloud operations into our existing security practices?
- How do we stay up to date with new services and best practices?
- How do we stay in compliance?
For more information, see The Mission of the Cloud-Centric CISO.
| Key Design Decisions | Initial SecOps Structure:
|
| Typical Stakeholders |
|
| Related OCI Services and Features | |
| Related Certification | Oracle Cloud Infrastructure (OCI) Certified Security Professional |
| Related Training | Become a Cloud Security Professional |
Enable Security Operations Teams Early
An essential part of onboarding to OCI is collaborating with your security teams at the beginning of your cloud adoption initiative. Work with your platform and operation teams to include cloud security practices within all operations.
For most organizations, cloud adoption involves a high learning curve and a large culture shift that spans multiple teams. Engage your cybersecurity teams early during the planning and architecture phase, instead of later, so that you can help teams shape and align processes with a common understanding of the features and limitations of cloud services. With early feedback from the platform and application teams, security management processes are more likely to be an enabler and protector to your cloud initiative, instead of a late blocker.
Use Cloud Guard
Cloud Guard is a cloud-native service that helps you monitor, identify, achieve, and maintain a strong security posture ind Oracle Cloud. Use the service to examine your OCI resources for security weakness related to configuration, and your OCI operators and users for risky activities. Upon detection, Cloud Guard can suggest, assist, or take corrective actions, based on your configuration.
- Cloud Guard uses Oracle-managed or user-managed detector and responder "recipes." Recipes are combinations of rules that either identify or respond to different conditions.
- You can target OCI compartments with detector recipes so that Cloud Guard can detect misconfigured resources and insecure activity across tenants.
- Cloud Guard provides security administrators with the visibility to triage and resolve cloud security issues.
- Security inconsistencies can be automatically remediated with out-of-the-box security recipes so that you can quickly and efficiently scale security operations.
- You can integrate Cloud Guard event details, such as the problem threshold reached, or the problem detected, with existing processes using the OCI Notifications service. For example, Notifications can send Slack or email messages, or trigger automation using custom OCI functions.
- Oracle-managed recipes provide an excellent baseline because OCI keeps them up to date with the latest rules. Your security policy team (green team) can further adjust these rules to better fit your organization's needs by cloning Oracle-managed recipes to create user-managed recipes, including disabling a rule, revising a risk level, and so on.
Carefully Choose Your Reporting Region
When you enable Cloud Guard, you are asked to choose a reporting region. Consider the following consequences of your reporting region choice:
- The reporting region you select commits your organization to comply with all legal requirements of the country where the reporting region is hosted.
- After Cloud Guard is enabled, you can't change the reporting region without disabling and re-enabling Cloud Guard.
- All customizations, and existing problems, including their history, are lost when you disable Cloud Guard, and you must manually restore those customizations.
- All API calls, except for READs, must be made on the reporting region. Ensure that you make the best decision for your reporting region before you begin the steps to Enable Cloud Guard.
Plan How Targets Map to Compartments
If you need to set up targets to allow different compartments to be monitors differently, keep the following guidelines in mind when mapping targets to compartments:
- All of a target's compartments inherit that target's configuration. The detector and responder rule settings for a target apply to the top-level compartment assigned to that target, and to any subordinate compartments below it in the compartment hierarchy. If you want to exclude some compartments from monitoring, create targets below the root level and don't include the root compartment in any target.
- Target defined within an existing target overrides inherited configuration. Within an existing target, you can assign a compartment below the target's top-level compartment to a new target. You can change the detector and responder rule settings for the new target, and those settings apply to the top-level compartment assigned to that target, and to all the subordinate compartments below it in the compartment hierarchy.
Key Design Decisions
The following information describes key design decision:
- Reporting region of Cloud Guard, which can't be changed without disabling Cloud Guard
- Define initial top-level target and exception strategy:
Is any compartment allowed to be excluded from Cloud Guard monitoring, such as a sandbox or PoC?
If not, define the initial target at the root compartment to ensure that the whole tenancy is under monitor without exception.
If yes, only create the Cloud Guard target at the non-root compartment to allow exception.
- Evaluate the response recipes and applicable scope of enforcement.
- Operational flow of Cloud Guard monitoring, for example:
- Who can modify recipes and targets?
- Who must carry out the corrective actions when auto response is not enforced?
Evaluate and Use Security Zones with Cloud Guard
Cloud Guard detects misconfiguration and security zones help prevent these problems from occurring.
A security zone is created by associating a compartment with a security zone recipe. When you create and update resources in a security zone, OCI validates these operations against the list of policies defined in the security zone recipe. If any security zone policy is violated, then the operation is denied. However, existing resources that were created before the security zone might also violate policies. OCI Security Zones integrates with Cloud Guard to identify policy violations in existing resources.
Oracle manages a single, predefined recipe named Maximum Security Recipe, which includes all available security zone policies. Because the policies of Maximum Security Recipe are relatively strict and not customizable, your organization must consider it for suitable workloads only after jointly evaluating the security zone with the application architect. Create your own security recipes when needed.
Security Principles
In general, security zone policies align with the following core security principles:
- Resources in a security zone can’t be moved to a compartment outside of the security zone because it might be less secure.
- All the required components for a resource in a security zone must also be located in the same security zone. Resources that are not in a security zone might be vulnerable, and resources in a different security zone might have a lower security posture. For example, a compute instance in a security zone can't use a boot volume that isn't in the same security zone.
- Resources in a security zone must not be accessible from the public internet.
- Resources in a security zone must be encrypted using customer-managed keys.
- Resources in a security zone must be regularly and automatically backed up.
- Data in a security zone is considered privileged and can't be copied outside of the security zone because it might be less secure.
- Resources in a security zone must use only configurations and templates approved by Oracle. See Security Zone Policies for details
Relationship with Cloud Guard Targets
- When you create a security zone for a subcompartment whose parent compartment is already in a
security zone, Cloud Guard performs the following tasks:
- Creates a separate security zone target for the subcompartment.
- Adds the default Oracle-managed detector recipes to the new security zone target.
- No changes are made to the existing Cloud Guard target for the parent compartment.
- A single compartment can't be in multiple security zones, and also can't be in multiple Cloud Guard targets.
Key Design Decision
- Evaluate security zone policies.
- Define the applicable scope, such as non internet facing modules, and enforcement processes, such as embedded, early in the development lifecycle to avoid rollout blockage in later stages.
Monitor Vulnerabilities with Regular Scanning
OCI Vulnerability Scanning Service helps improve your security posture in OCI by routinely checking hosts for potential vulnerabilities. The service generates reports with metrics and details about the findings.
The Vulnerability Scanning service can identify several types of security issues in compute instances and container images:
- Ports that are unintentionally left open might be a potential attack vector to your cloud resources, or enable hackers to exploit other vulnerabilities.
- OS packages that require updates and patches to address vulnerabilities.
- OS configurations that hackers might exploit.
- Industry-standard benchmarks that are published by the Center for Internet Security (CIS).
Vulnerability Scanning checks hosts for compliance with the section 5 (Access, Authentication, and Authorization) benchmarks defined for Distribution Independent Linux.
When you create a repository in Oracle Cloud Infrastructure Registry (also known as Container Registry), image scanning is enabled by default on the repository. Every time an image is pushed to the repository, the image is scanned for security vulnerabilities in the Common Vulnerabilities and Exposures (CVE) database. Container Registry automatically rescans any images in the repository that have changed since the previous scan.
The security team can also use the default configuration detector recipe in Cloud Guard to detect and respond to security vulnerabilities identified by the Vulnerability Scanning service.
Vulnerability Sources
Vulnerability Scanning detects vulnerabilities in the following platforms and using the following vulnerability sources.
| Platform | National Vulnerability Database (NVD) | Open Vulnerability and Assessment Language (OVAL) | Center for Internet Security (CIS) |
|---|---|---|---|
| Oracle Linux | Yes | Yes | Yes |
| CentOS | Yes | Yes | Yes |
| Ubuntu | Yes | Yes | Yes |
| Windows | Yes | No | No |
Considerations
- Because Windows scanning doesn’t include OVAL data, we don't recommend you rely solely on OCI Vulnerability Scanning to ensure that your Windows instances are up-to-date and secure.
- We don't recommend using the Vulnerability Scanning service to identify issues in virtual machine (VM) database (DB) systems, and then modifying the OS to address each issue. Instead, follow the instructions for updating a DB system to apply the latest security updates to the OS.
- You can't use the Vulnerability Scanning service on hosts that weren't created directly with the OCI Compute service, such as Oracle Exadata Database Service on Dedicated Infrastructure or the Database service. Use the features provided with those services to ensure that hosts have the latest security updates.
Log Archiving and SIEM Integration
Logging is essential for security analysts to discover potential security breaches or internal misuses of information.
With Oracle Cloud Infrastructure Logging, analysts can access logs from OCI resources, including critical diagnostic information that describes how resources are performing and being accessed. Logging is a highly scalable and fully managed single pane of glass for all the logs in your tenancy.
By default, audit logs are retained for 365 days. With OCI Service Connector Hub, you can archive logs to immutable storage longer to fulfill the compliance requirements for some regulated industries. Using a similar pattern, logs can integrate with third-party security information and event management (SIEM) tools such as Splunk and QRadar using the OCI Streaming service.
Key Design Decision
- Mandatory log archiving period: Is 365 days enough? Or, do you need to further retain it by using immutable storage?
- Need for existing SIEM integration: Is there a need to integrate with any existing SIEM solution?