Autonomous Database Virtual Machine (Autonomous VM) images, also known as client VMs, are security-hardened. As outlined in Oracle Software Security Assurance, their configurations are secured via Oracle software development and assurance practices. Autonomous VMs have suitable anti-virus and anti-malware software configured to detect unauthorized software and malware. Oracle’s Asset Endpoint Protection and Configuration Management software, installed on client virtual machines, ensures configuration changes are made only through secure, approved processes. Linux OS audit logs are collected and transferred to a central OCI Security Information and Event Management (SIEM) system for security incident detection and auditing by OCI's security incident Detection And Response Team (DART). Logs are retained for 13 months from the date of generation.

DART is responsible for manning SIEM dashboards, assessing incident alerts and initiating remediation actions on true positives by opening tickets on internal service teams. When a security event demands a customer update, DART works with Global Information Security and service teams to issue a customer update.

All Oracle Autonomous VMs are DISA STIG (Defense Information Systems Agency Security Technical Implementation Guide) compliant and are hardened according to Oracle Linux Security Technical Implementation Guide, which addresses issues around user access controls, open ports, unwanted packages, and daemon configurations, among others. You can find a complete list of Oracle Linux DISA STIG controls here.

Manual access to Autonomous VMs is restricted to a core cloud operations team thoroughly vetted by the company. Operations team members are required to be on the Oracle Cloud Network Attach (a private, secure cloud network) from a company-provided device to access Exadata Infrastructure. Access credentials are dynamically generated in response to valid support tickets. Any configuration change to the Client VMs undergoes strict internal security review and a change management process. All tools, scripts or software are installed or modified only after going through the approved software life cycle and change management process.

Integration with Operator Access Control service for both infrastructure and Autonomous VMs further restricts this access and puts access permission and notification in your hands. Operator actions are logged in near real-time and sent to a customer-configured SIEM and the Oracle logging service for download by the customer as desired. You can download the logs to customer SIEM/Storage or archive them indefinitely in OCI object storage. See Operator Access Control service for more details.

OCI security architecture further defines OCI’s unique multi-layered gen2 hardware and virtualization security. You can refer to Oracle Cloud Infrastructure Security Architecture for more details.

Autonomous Database service development and Autonomous VM image build are part of the scope of Oracle corporate security practices. This implementation is carefully controlled in the Oracle Software Security Assurance process, published here.

Autonomous VM image configurations are controlled via code and undergo multiple code reviews and quality assurance (QA) cycles before a configuration change makes it to a production release. Please refer to the Secure configurations section of the Oracle Software Security Assurance documentation for Oracle’s posture and standard practices for securing software configurations.

An Oracle-built agent, Asset Endpoint Protection and Configuration Management (AEP/CM) software is installed on control plane servers to collect and transfer Linux audit logs and Linux Advanced Intrusion Detection Environment (AIDE) logs from infrastructure and Autonomous VM instances. These logs are transferred to an OCI central SIEM for audit purposes. SIEM rules specific to tampering with log files, downloading external content, disabling security tooling, and others generate alerts that DART assesses and responds to as described Autonomous Virtual Machine Hardening.

Autonomous VM instances are secured from direct ssh access except from approved Oracle operators and automation. All operator activity can be monitored via Operator Access Control.

Autonomous VMs are configured with a file intrusion and monitoring utility that maintains the count and integrity of files in a specific build. Any change in file count or change in a file checksum is flagged. AIDE and HIDS logs are also collected and sent to OCI SIEM and scanned for threats via the DART process explained in Autonomous Virtual Machine Hardening.

All software artifacts deployed to an AVMC, including tooling, are deployed via a secure change management method employing checksums and digitally signed using SSL certificates. This is called certificate-signed code deployment.

All Autonomous VM images are built using Oracle’s secure development practices as documented in Oracle Software Security Assurance. The Corporate Security Solution Assurance Process (CSSAP) is a security review process developed by Oracle’s corporate security architecture, Global Information Security (GIS) and Oracle’s IT organizations to provide comprehensive information security management review. GIS and CSSAP operate independent of OCI service teams to protect Customer and Oracle’s information and software assets. Every service feature with a potential security impact undergoes a CSSAP review and approval process. In addition, quality assurance (QA) testing cycles use appropriate scanning tools to ensure images adhere to STIG, meet service security guidelines, and are ready for CSSAP review.

Forensic tooling on AVMCs plays a prominent role in vulnerability management. Linux audit logs from each Autonomous VM host are uploaded to a central OCI SIEM where alert rules capture and surface potential threats. DART responds to these alerts as explained in Autonomous Virtual Machine Hardening. HIDS and anti-virus logs are also processed similarly. A Common Vulnerabilities and Exposures (CVE) scanner sends its findings to a central automation tool where vulnerability findings are categorized, and tickets are opened for service teams to patch systems on a timescale proportional to the severity of the finding. All CVEs with a score greater than 7 must be patched within 30 days.

You can schedule infrastructure patch bundles comprising Hypervisor, Grid Infrastructure, Storage and Client Operating systems and Firmware quarterly. Database Release Updates and Release Update Revisions may also be scheduled separately each quarter. All patches are staged and applied using cloud automation tooling and Autonomous Cloud Operations, as the specific patch update requires.

Software patch development follows Oracle’s secure software development practices, QA testing, and CSSAP reviews as necessary. Separation of duty between patch developers, QA testers, release management and patching operations ensures multiple personnel are involved before a patch makes it to the customer’s hardware.

When possible, updates are applied to the running system without downtime using tools like Linux ksplice. If an update requires a component restart, Oracle performs the component restart in a rolling fashion to ensure service availability during the update process. You may schedule patching start times to align with your business SLAs. Patching may be scheduled separately for infrastructure components (GI, OS) and each DBMS home.

Autonomous VM client machines are built with endpoint, malware, and ransomware protection as discussed below:

• Suitable anti-virus and anti-malware tools are installed and updated regularly.
• ssh / sftp access on the client network is closed.
• Named user accounts on client VMs are extremely limited to required processes only.
• Autonomous VMs are hardened to DISA STIG standards to ensure no unused ports are open or daemons run on the system.
• Oracle operator access is via a secured, outbound connection to Oracle’s management network in a customer-chosen OCI region.
• Oracle operator actions may be controlled and audited through Operator Access Control service integration.

A dedicated team of security analysts from the security incident Detection and Response Team (DART) is responsible for manning the security event dashboards 24 / 7 and processing alerts to filter true positives. If a true positive is detected, a suitable response is initiated based on the severity and impact of the event. This can include further analysis, a root cause assessment and fix with the service teams and customer communication.

Oracle’s security incident response policies are outlined in Security Incident Response.