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 Database on Dedicated Exadata Infrastructure performs external and internal vulnerability scans (which include the discovery of end-of-support systems) frequently using commercial vulnerability scanning tools. Identified vulnerabilities are investigated and tracked to resolution by the Cloud Compliance Standard for Vulnerability Management. It uses various technical measures to evaluate and identify updates for third-party and open-source libraries. Authenticated vulnerability scans of systems deployed into the environment, as well as scans of pre-deployment system images, have been implemented to identify such libraries and determine whether security fixes are needed. Corporate policies and business unit procedures govern these programs and evaluate them annually.

Autonomous Database uses a mechanism to aggregate security findings from multiple sources (including vulnerability scans) and assign findings to the appropriate service team. This system lets service teams manage their findings and integrate with ticketing systems for automated queuing of remediation work, including notification and automatic escalations as necessary. The system also summarizes remediation work across the organization and drives day-to-day vulnerability management efforts.

Oracle Software Security Assurance (OSSA) defines Oracle's methodology for building security into its products' design, build, testing, and maintenance, whether used on-premises by customers or delivered through Oracle Cloud. Oracle Corporate Security policies (including policies that address threat and vulnerability management) are reviewed annually and updated as needed. At least annually, independent third parties conduct a system penetration test.

To provide the best security posture to all Oracle customers, Oracle fixes significant security vulnerabilities based on the likely risk that they pose to customers. The issues with the most severe risks are fixed first. In general. the fixes for security vulnerabilities are produced in the following order:

• Main code line first—that is the code line being developed for the next major release of the product.
• For each supported version that is vulnerable, create a Critical Patch Update patch and apply the fix in the next patch set if another patch set is planned for that supported version.

Patches and updates are implemented through continuous integration/continuous deployment (CI/CD) tools. Except where dependencies exist across multiple availability domains (for example, updates to domain name services), changes are implemented separately in each region and availability domain. The Oracle Patching and Security Alerts Implementation Policy requires the deployment of the Oracle Critical Patch Update and Security Alert updates and associated recommendations. This policy also includes requirements for remediating vulnerabilities in non-Oracle technology using a risk-based approach. For more information, see Critical Patch Update and Security Alert programs.

Oracle schedules and performs a monthly infrastructure security maintenance activity alongside quarterly maintenance. However, these security patches are applied only in those months with critical security updates, including fixes for vulnerabilities with CVSS scores greater than or equal to 7.

• Any Exadata Infrastructure provisioned before Oracle schedules the security maintenance will be eligible for security maintenance.
• The monthly security maintenance process updates database servers to fix critical security vulnerabilities and product issues. They also update storage servers to an Exadata Storage Software image that resolves known security vulnerabilities and product issues.

Oracle regularly performs penetration and vulnerability testing and security assessments against the Oracle Cloud infrastructure, platforms, and applications to validate and improve the overall security of Oracle Cloud services. However, Oracle does not assess or test any components (including non-Oracle applications, non-Oracle databases or other non-Oracle software, code or data, as may be applicable) that you manage through or introduce into – including introduction through your development in or creation in - the Oracle Cloud services (the "Customer Components").

Oracle Customer Security Testing Policy describes the security testing activities such as penetration testing and vulnerability scanning that Oracle customers can perform against their Oracle On-Premises Products and Oracle Cloud Services ("Security Tests" or "Security Testing"). It is collectively referred to as "Testing Policy" and included in the Service Specifications for Oracle Cloud Services. This policy does not address or provide any right to conduct testing of any third-party materials included in the Customer Components. Only customers with an Oracle Account with the necessary privileges to file service maintenance requests and who are signed in to the environment that will be the subject of such testing may conduct any vulnerability or penetration testing.

Except as otherwise permitted or restricted in your Oracle Cloud services agreements, your service administrator who has system-level access to your Autonomous Database service may run penetration and vulnerability tests for the Customer Components included in your Autonomous Database service in accordance with the restrictions outlined in Security Testing in the Oracle Cloud.

You can also refer to the Security testing FAQ to find answers to questions you may have about your Security Testing.

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.