Configuring Instance Security
Instance Security is a new Oracle Cloud Guard detector recipe that monitors compute hosts for suspicious activity.
- About Instance Security provides an introduction to concepts that are useful to understand when you're working with Instance Security.
- Enabling Instance Security shows you how to get started with Instance Security by applying an Instance Security detector recipe to a target.
- Instance Security Detector Recipes describes the Instance Security detector recipes.
About Instance Security
Instance Security provides runtime security for workloads in Compute virtual and bare metal hosts. Instance Security expands Cloud Guard from cloud security posture management to cloud workload protection, and ensures that security needs at met in one place and with consistent visibility and holistic understanding of the security state of infrastructure.
Instance Security collects important security information about compute hosts such as security alerts (called problems in Cloud Guard), vulnerabilities, and open ports to provide you with actionable guidance for detection and prevention. You can detect suspicious processes, open port creation, and script execution for workloads, with OS level visibility. Instance Security provides new Oracle-managed ready-to-use detections and the customer managed queries for threat hunting use cases.
Instance Security is natively integrated with OCI Logging so you can easily export logs to your third-party security tooling.
EBPF-Based Security Solution
Instance Security uses Extended Berkeley Packet Filter (eBPF) technology to detect security events at the kernel level. eBPF is a kernel technology that lets programs run without having to change the kernel source code.
You can automatically collect data to detect security anomalies and get deep insights into OS's, without modifying any kernel code and without significantly affecting performance.
Aligned with MITRE Attack Framework
Instance Security provides a suite of Oracle-managed ready-to-use detector rules that are aligned with the MITRE Attack framework aimed at reducing the manual work for your security operations center (SOC) to find known adversary activities.
The information is run through models that are aligned with the MITRE Attack framework to categorize the potential tactics and techniques involved.
Run On-Demand Queries
You can run on-demand queries on Compute instances periodically, or on an on-demand basis to give you real-time visibility into the state of your machine.
Instance Security runs OSquery under the hood which exposes OS data as a high-performance relational database. Osquery is a performant, open source, multi platform host agent to give you visibility and insights to your fleet. It collects and normalizes data independent of the OS and increases visibility across your infrastructure. OSquery comes with support from hundreds of tables covering everything from running processes to loaded kernel extensions. Instance Security supports most of the open source osquery tables in addition to OCI custom-built tables.
Schedule Queries
After you have run a query and are happy with the query result, you can schedule the query to run at a regular frequency. If you have the need to provide evidence of meeting certain security controls as part of the compliance and audit requirements for your compute hosts, you can use scheduled queries. Instance Security is integrated with the OCI Logging service, and you can configure the OCI Logging service to send your raw data to a security information and event management (SIEM) service or third-party data aggregator.
Instance Security Detector Recipes
There are two Oracle-managed Instance Security detector recipes:
- OCI Instance Security Detector Recipe—Enterprise (Oracle managed).
- OCI Instance Security Detector Recipe (Oracle managed).
You can make custom configurations of detector recipes by cloning these recipes and rules. See Cloning an OCI Detector Recipe.
You can only apply one Instance Security detector recipe to a target. If you want to change the recipe, you must first remove the existing one from the target, then apply the other one.
OCI Instance Security Detector Recipe—Enterprise (Oracle managed)
This recipe is a paid offering that provides full service functionality. It gives you alerts based on Oracle ready-to-use detections, and lets you query your fleet using custom and scheduled queries.
This ready-to-use detector recipe uses all the Instance Security detector rules which are detailed in OCI Instance Security Detector Rules.
To find out what it costs, see the Cloud Guard pricing information in the Cloud Price List. You can use the Cost Estimator Tool to help you determine your monthly usage and bill. See Billing and Cost Management Overview.
| Resource | Count per Tenancy |
|---|---|
| Number of instances covered per region | Unlimited |
| Ready-to-use detector rules | Unlimited |
| On-demand queries | Unlimited |
| Scheduled queries | 25 queries per instance per day |
| Size of scheduled query results | 5 MB per instance per day |
This example shows how scheduled query limits work.
The limit for the size of scheduled query results is per instance, so if you have 10 instances in a region your tenant-level regional limit is 5*10 = 50 MB per day
When you reach the limit of scheduled query results in a region, the queries will show a Failed status and you will see the message:
Scheduled query size limit has reached, the limit will reset the next dayOnce the limit is reset the next day, scheduled queries will succeed until the limit is reached again.
OCI Instance Security Detector Recipe (Oracle managed)
If you're not ready to invest in Instance Security but want to get taste of the service, you can try out this free recipe. It will alert you to vulnerability and open port scanning issues, and you can run limited number of queries.
This detector recipe uses the Instance Security detector rules:
| Resource | Count per Tenancy |
|---|---|
| Number of instances covered per region | 5 |
| Ready-to-use detector rules | 2 |
| On-demand queries | 30 per month per region |
| Scheduled queries | 0 |
This example shows how on-demand query limits work by considering two scenarios.
You have a monthly limit of 30 on-demand queries in a region:
- You run your first on-demand query and target 25 active instances and all succeed, giving 25 results.
- You run a second on-demand query and target 25 active instances, but this time you will only get five results on five randomly selected instances because you only had 5 on-demand queries left for the month.
- If you then run a third on-demand query and target just one instance, you'll see the following message:
You have consumed free adhoc units for this month, your limit will reset next month
Expired queries are reimbursed back to the monthly limit after around 15 minutes.
- Your first on-demand query targeted 25 instances (24 active and 1 inactive agent) and the outcome is that it expired with 24 results from the active agents.
- You ran a second on-demand query and target 25 instances (24 active and 1 inactive agent), and this time you only get five results on five randomly selected instances because you only had 5 on-demand queries left for the month.
- If you then run a third on-demand query and target just one instance, you'll see the following message:
You have consumed free adhoc units for this month, your limit will reset next month