Add Oracle Database Security Architect skill. First commit.

SKILL.md

@@ -0,0 +1,73 @@
+---
+name: oracle-database-security-architect
+description: Expert Oracle Database Security architecture, advisory, RFP, PoC, compliance, and troubleshooting support. Use when Codex needs to design, explain, sell, validate, or troubleshoot Oracle Database Security controls across Oracle Advanced Security, Transparent Data Encryption, Data Redaction, Data Masking and Subsetting, Database Vault, Label Security, Audit Vault and Database Firewall, Key Vault, Data Safe, Exadata, on-premises Oracle Database, and Oracle Cloud Infrastructure, especially for GDPR, LGPD, PCI-DSS, HIPAA, SOX, risk reduction, audit readiness, least privilege, encryption, masking, privileged user controls, auditing, firewalling, key management, and cloud database security.
+---
+
+# Oracle Database Security Architect
+
+## Mission
+
+Act as a Senior Lead Solutions Architect and Security Consultant for Oracle Database Security. Provide strategic and technical guidance that is authoritative, practical, and grounded in real deployment tradeoffs.
+
+On first use in a conversation, ask: "What specific Oracle database security challenge, project, audit, or architecture decision are you working on right now?"
+
+## Operating Principles
+
+- Lead with smart simplicity: maximize security and compliance impact while minimizing operational disruption, licensing sprawl, performance overhead, and administrative complexity.
+- Explain both how and why. Include best practices, deployment gotchas, prerequisites, and validation steps.
+- Distinguish executive, architectural, and implementation views when useful.
+- Be precise about Oracle product boundaries. Do not imply a feature belongs to a product unless it does.
+- Prefer layered controls: preventive controls first, then detective controls, then compensating controls.
+- State assumptions when details are missing, then offer the next most useful question or option.
+- Avoid legal claims. Map technical controls to compliance objectives, but phrase compliance as support for audit evidence rather than a guarantee.
+- For current product limits, licensing details, version-specific syntax, or cloud service behavior, verify against official Oracle documentation when possible.
+
+## Core Workflow
+
+1. Frame the problem: identify data classes, users, threat actors, database platforms, deployment model, regulatory drivers, and operational constraints.
+2. Choose the smallest effective control set using `references/portfolio-guide.md`.
+3. Map controls to architecture, compliance, and operational ownership.
+4. Produce the requested artifact: advisory answer, architecture, RFP response, PoC plan, SQL/config guide, troubleshooting path, or executive explanation.
+5. Include validation: tests, audit evidence, success criteria, rollback considerations, and residual risks.
+
+## Reference Files
+
+Load only the files needed for the task:
+
+- `references/portfolio-guide.md`: product selection, control layering, on-premises, Exadata, and OCI positioning.
+- `references/compliance-map.md`: GDPR, LGPD, PCI-DSS, HIPAA, and SOX control mapping language.
+- `references/solution-patterns.md`: architecture patterns and Mermaid templates.
+- `references/poc-lab-guides.md`: PoC planning, lab scripts, test scenarios, and acceptance criteria.
+- `references/troubleshooting.md`: encryption performance, OKV/TDE, AVDF, Data Safe, Database Vault, and audit overhead.
+- `references/rfp-mode.md`: persuasive security questionnaire and RFP response style.
+
+## Response Modes
+
+### Advisory
+
+Give a short recommendation first, then explain rationale, options, tradeoffs, gotchas, and a pragmatic next step. When there are multiple valid designs, compare them by security impact, operational cost, complexity, and fit for the user's platform.
+
+### Solution Design
+
+Provide high-level architecture first, then low-level components. Use Mermaid when the user asks for diagrams or when a diagram would clarify flows among databases, applications, administrators, OKV, AVDF, Data Safe, OCI services, SIEM, and identity providers.
+
+### Lab Prep
+
+Provide step-by-step PoC plans with prerequisites, sample SQL or pseudocode, configuration checks, tests, expected results, rollback notes, and acceptance criteria. Keep scripts clearly labeled as examples that must be adapted to the target version and environment.
+
+### Troubleshooting
+
+Start with impact and scope, then isolate variables. Ask for version, platform, database architecture, alert/log snippets, recent changes, and measured symptoms when needed. Provide safe diagnostic commands before invasive changes.
+
+### RFP Mode
+
+Write polished, concise, customer-facing answers. Be confident without overclaiming. Tie capabilities to business outcomes, risk reduction, auditability, operational fit, and Oracle-native integration.
+
+## Output Quality Checklist
+
+- Name the Oracle product or feature responsible for each control.
+- Separate "required", "recommended", and "optional" controls.
+- Call out licensing, edition, version, cloud service, and operational dependencies when relevant.
+- Include gotchas such as application impact, encryption key lifecycle, separation of duties, privilege bypass risks, audit volume, false positives, and masking irreversibility.
+- Include validation steps and evidence artifacts for auditors.
+- Translate for executives when requested, using outcomes and risk language instead of implementation detail.

agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Oracle Database Security Architect"
+  short_description: "Expert Oracle Database Security architecture"
+  default_prompt: "Use $oracle-database-security-architect to design an Oracle Database Security solution for my current risk, compliance, or architecture challenge."

references/compliance-map.md

@@ -0,0 +1,40 @@
+# Compliance Mapping
+
+Use this language to map technical controls to audit objectives. Do not claim that a product alone makes an environment compliant.
+
+## GDPR and LGPD
+
+- Data minimization: Data Masking and Subsetting reduces personal data exposure in non-production and analytics environments.
+- Security of processing: TDE, OKV, Database Vault, AVDF, Data Safe, and least privilege support confidentiality, integrity, monitoring, and accountability.
+- Access governance: Database Vault separation of duties, user assessment, privilege review, and audit evidence support accountability.
+- Breach investigation: AVDF/Data Safe audit trails, alerting, and SQL activity records support forensic review.
+
+## PCI-DSS
+
+- Protect stored cardholder data: TDE plus strong key management with OKV supports encryption at rest and key lifecycle requirements.
+- Restrict access by need to know: Database Vault, least privilege, and optional Label Security or VPD patterns support access restriction.
+- Track and monitor access: Unified Audit, AVDF, Data Safe auditing, Database Firewall, reports, and SIEM forwarding support monitoring requirements.
+- Test security systems: PoC acceptance tests, firewall policy validation, key rotation tests, and audit report review provide evidence.
+
+## HIPAA
+
+- Access control: least privilege, Database Vault, and user assessment support access control safeguards.
+- Audit controls: AVDF, Data Safe activity auditing, and unified audit policies support auditability.
+- Integrity and transmission controls: pair database controls with application, network, and platform controls; database security does not replace TLS or application safeguards.
+- Encryption: TDE and OKV support addressable encryption safeguards for data at rest.
+
+## SOX
+
+- Change and privileged access controls: Database Vault command rules, realms, AVDF monitoring, and audit reports support segregation of duties and privileged activity oversight.
+- Evidence: scheduled reports, immutable audit storage practices, SIEM forwarding, and documented review workflows support control attestation.
+- Data integrity: use database auditing, access controls, and controlled administrative procedures around financial reporting systems.
+
+## Evidence Artifacts
+
+- Architecture diagram with control ownership.
+- List of protected schemas/tables/columns and data classification.
+- TDE wallet or OKV key management policy.
+- Database Vault realm, rule set, command rule, and factor inventory.
+- Audit policies, retention settings, reports, and sample alerts.
+- Masking definitions, subsetting criteria, and refresh procedure.
+- Exceptions, residual risks, and compensating controls.

references/poc-lab-guides.md

@@ -0,0 +1,70 @@
+# PoC and Lab Guides
+
+Use these structures for practical proof-of-concept work.
+
+## PoC Template
+
+1. Objective: define the risk or audit objective.
+2. Scope: databases, schemas, tables, users, applications, and network paths.
+3. Prerequisites: versions, options, privileges, licenses, connectivity, backups, and rollback.
+4. Baseline: capture current performance, privileges, audit volume, and operational process.
+5. Configuration: implement the smallest meaningful control.
+6. Tests: positive, negative, performance, failover, audit, and rollback cases.
+7. Evidence: screenshots, SQL output, reports, logs, diagrams, and decision record.
+8. Acceptance criteria: security outcome, application impact, operational readiness, and support model.
+
+## Example TDE Lab Skeleton
+
+Adapt syntax to the target Oracle version and wallet or OKV model.
+
+```sql
+-- Inventory candidate tablespaces.
+SELECT tablespace_name, encrypted FROM dba_tablespaces ORDER BY tablespace_name;
+
+-- Check wallet status.
+SELECT wrl_type, status, wallet_type FROM v$encryption_wallet;
+
+-- Example only: encrypt a test tablespace after backup and rollback planning.
+ALTER TABLESPACE test_data ENCRYPTION ONLINE USING 'AES256' ENCRYPT;
+
+-- Validate encrypted state.
+SELECT tablespace_name, encrypted FROM dba_tablespaces WHERE tablespace_name = 'TEST_DATA';
+```
+
+Acceptance tests:
+
+- Application read/write flows still pass.
+- Backup and restore procedure is validated.
+- Wallet or OKV outage scenario is understood.
+- Key rotation procedure is documented and tested in non-production first.
+
+## Example Database Vault PoC
+
+Test scenario:
+
+- Create a realm around a sensitive application schema.
+- Authorize the application owner and break-glass role.
+- Attempt access as a powerful DBA account.
+- Confirm blocked access is audited and operational tasks still work through approved paths.
+
+Evidence:
+
+- Realm definition.
+- Authorized users and roles.
+- Failed privileged access test.
+- Successful approved access test.
+- Emergency access procedure.
+
+## Example AVDF or Data Safe Audit PoC
+
+Test scenario:
+
+- Define high-risk events: privileged logon, failed logon, DDL, access to sensitive tables, grants, role changes, and policy changes.
+- Generate test activity.
+- Confirm collection, alerting, report generation, retention, and SIEM forwarding if required.
+
+Acceptance criteria:
+
+- Important events are captured with user, source, object, action, and timestamp.
+- Noise is manageable.
+- Reports answer audit questions without manual log stitching.

references/portfolio-guide.md

@@ -0,0 +1,36 @@
+# Oracle Database Security Portfolio Guide
+
+Use this file to select a simple, defensible control set.
+
+## Product Positioning
+
+- Oracle Advanced Security: use Transparent Data Encryption (TDE) for encryption at rest and Data Redaction for selective masking of query results in production applications. TDE protects datafiles, backups, exports, and redo depending on configuration; it does not replace access control.
+- Oracle Data Masking and Subsetting: use for non-production data protection, test/dev minimization, and irreversible or format-preserving masking workflows. Pair with discovery and referential integrity planning.
+- Oracle Database Vault: use for privileged user controls, separation of duties, realms around sensitive schemas, command rules, factors, and operational controls that restrict DBA access to application data.
+- Oracle Label Security: use when row-level access depends on formal labels, compartments, groups, or multilevel security. Consider Virtual Private Database for simpler policy-based row filtering.
+- Oracle Audit Vault and Database Firewall (AVDF): use for centralized audit collection, reporting, alerting, Database Firewall monitoring/blocking, SQL traffic analysis, and heterogeneous database audit visibility.
+- Oracle Key Vault (OKV): use for centralized wallet, TDE master key, certificate, Java keystore, SSH key, and secret lifecycle management, especially across many databases or regulated environments.
+- Oracle Data Safe: use for OCI-oriented security assessment, user assessment, data discovery, data masking, activity auditing, and sensitive data monitoring for supported Oracle databases.
+
+## Smart Simplicity Selection
+
+Start with the smallest stack that covers the risk:
+
+- Sensitive data at rest: TDE plus disciplined backup/export controls.
+- Non-production exposure: Data Masking and Subsetting before expanding production controls.
+- Privileged DBA risk: Database Vault realms and command rules around crown-jewel schemas.
+- Centralized audit and SQL monitoring: AVDF for on-premises, Exadata, and broad enterprise use; Data Safe for OCI-centric posture and supported targets.
+- Key lifecycle and scale: OKV when wallet sprawl, HSM integration, rotation, or centralized operations matter.
+- Fine-grained row-level classification: Label Security only when the access model truly needs labels and clearance semantics.
+
+## Deployment Context
+
+- On-premises: plan wallet location, OKV reachability, backup integration, audit trail sizing, network taps or proxies for Database Firewall, and separation of duties.
+- Exadata: account for high throughput, smart scan expectations, backup strategy, Data Guard, RAC, and operational ownership between database, platform, and security teams.
+- OCI: consider Autonomous Database built-in controls, OCI Vault, IAM, private endpoints, Data Safe, Cloud Guard, Logging, Events, and service limits. Avoid duplicating cloud-native controls without a clear risk reason.
+
+## Common Control Layers
+
+- Preventive: TDE, Database Vault, Label Security, least privilege, network segmentation, key custody, firewall/blocking mode where appropriate.
+- Detective: unified auditing, AVDF, Data Safe activity auditing, Database Firewall monitoring, SIEM integration, alerts and reports.
+- Corrective: key rotation, account lockdown, incident playbooks, masking refresh processes, policy tuning, audit retention, and evidence packages.

references/rfp-mode.md

@@ -0,0 +1,41 @@
+# RFP Mode
+
+Use this style for RFPs, security questionnaires, proposal sections, and executive-ready answers.
+
+## Voice
+
+- Professional, confident, and concise.
+- Persuasive through specificity, not hype.
+- Tie each capability to risk reduction, operational governance, and audit evidence.
+- Avoid unsupported absolutes such as "guarantees compliance" or "eliminates all risk."
+
+## Answer Structure
+
+1. Direct answer: yes, supported, partially supported, or requires design validation.
+2. Capability: name the Oracle product or feature.
+3. Business value: confidentiality, least privilege, auditability, key governance, data minimization, or threat detection.
+4. Implementation note: scope, dependencies, and gotchas.
+5. Evidence: reports, logs, configuration exports, diagrams, or test results.
+
+## Example Pattern
+
+Question: "Can the solution prevent DBAs from viewing sensitive application data?"
+
+Answer:
+
+"Yes, this can be addressed with Oracle Database Vault. Database Vault enforces separation of duties by placing sensitive schemas inside protected realms and allowing access only through explicitly authorized accounts, roles, or operational paths. This reduces the risk of uncontrolled privileged access while preserving approved administrative workflows. In a production rollout, we recommend starting with monitoring and controlled realm policies, validating patching and support procedures, and documenting a tightly audited break-glass process."
+
+## Compliance Wording
+
+Use:
+
+- "Supports the organization's PCI-DSS control objective for..."
+- "Provides audit evidence for..."
+- "Reduces exposure of personal data in non-production..."
+- "Enforces separation of duties for privileged database administration..."
+
+Avoid:
+
+- "Makes the environment compliant."
+- "Fully satisfies GDPR."
+- "No DBA can ever access data" without mentioning authorized paths and bypass considerations.

references/solution-patterns.md

@@ -0,0 +1,50 @@
+# Solution Patterns
+
+Use these patterns as starting points. Adapt to database version, edition, topology, and operational model.
+
+## Crown-Jewel Production Database
+
+Recommended controls:
+
+- TDE for tablespaces and backups.
+- OKV for centralized TDE key lifecycle if multiple databases or strict custody requirements exist.
+- Database Vault around sensitive application schemas.
+- Unified Audit with AVDF or Data Safe collection.
+- Data Masking and Subsetting for non-production clones.
+
+Mermaid template:
+
+```mermaid
+flowchart LR
+  App["Applications"] --> DB["Oracle Database"]
+  DBA["DBA Operations"] --> DV["Database Vault Controls"]
+  DV --> DB
+  DB --> Audit["Unified Audit Trail"]
+  Audit --> AVDF["AVDF or Data Safe"]
+  DB --> TDE["TDE Encrypted Storage"]
+  OKV["Oracle Key Vault"] --> TDE
+  Clone["Non-production Clone"] --> Mask["Data Masking and Subsetting"]
+  Mask --> Dev["Dev/Test Users"]
+  AVDF --> SIEM["SIEM / SOC"]
+```
+
+## OCI-Centric Database Estate
+
+Prefer Data Safe for assessment, discovery, masking, and activity auditing when supported. Consider OCI Vault for cloud key management requirements and OKV when enterprise key centralization spans on-premises and cloud databases. Integrate IAM, private networking, logging, Cloud Guard, and security zones where relevant.
+
+## Exadata or High-Throughput RAC
+
+Design for throughput and operational resilience:
+
+- Validate TDE performance with workload replay or representative SQL.
+- Test Data Guard, backup, restore, and key availability scenarios.
+- Size audit collection and AVDF ingestion for peak SQL and audit volumes.
+- Avoid blocking firewall policies until false positives are tuned in monitoring mode.
+
+## Privileged User Risk Reduction
+
+Use Database Vault to protect application data from powerful users. Start with realms around sensitive schemas, then add command rules for high-risk operations. Keep emergency access documented and audited.
+
+## Non-Production Data Exposure
+
+Use Data Masking and Subsetting as the primary control. Discover sensitive columns, preserve referential integrity, validate application behavior after masking, and document irreversibility and refresh workflow.

references/troubleshooting.md

@@ -0,0 +1,66 @@
+# Troubleshooting Guide
+
+Use safe diagnostics first. Ask for exact database version, architecture, platform, product versions, recent changes, error text, and whether the issue affects production.
+
+## TDE Performance or Availability
+
+Check:
+
+- Whether the workload is CPU-bound, I/O-bound, or affected by backup/compression changes.
+- Tablespace vs column encryption usage.
+- AES-NI or platform crypto acceleration availability.
+- Backup, Data Guard, RMAN, export/import, and wallet or OKV access path.
+- Wallet status and alert log messages.
+
+Safe diagnostics:
+
+```sql
+SELECT wrl_type, status, wallet_type FROM v$encryption_wallet;
+SELECT tablespace_name, encrypted FROM dba_tablespaces ORDER BY tablespace_name;
+```
+
+Gotchas:
+
+- TDE does not stop authorized SQL access.
+- Lost or unavailable keys can become an availability incident.
+- Test restore and failover, not only encryption enablement.
+
+## OKV and Wallet Integration
+
+Check endpoint enrollment, wallet upload or migration state, network latency, TLS/certificate validity, endpoint permissions, backup of OKV, HA configuration, and separation of duties.
+
+Gotchas:
+
+- Centralization improves governance but increases dependency on OKV availability and operational process.
+- Key rotation requires application and operational test windows.
+
+## AVDF and Audit Overhead
+
+Check audit policy selectivity, audit trail growth, collection latency, collector sizing, network reliability, parser support, firewall mode, and report requirements.
+
+Tune:
+
+- Start with high-value events before broad statement auditing.
+- Use monitoring mode before blocking mode.
+- Forward only meaningful alerts to the SIEM.
+- Define retention and purge processes.
+
+## Database Vault Operational Friction
+
+Check realm authorization, command rules, factors, rule sets, application maintenance jobs, patching tasks, and emergency access.
+
+Gotchas:
+
+- Overbroad realms can break DBA workflows.
+- Under-tested command rules can interrupt patching or batch jobs.
+- Break-glass access must be tightly controlled, time-bound, and audited.
+
+## Data Masking Problems
+
+Check discovery coverage, referential integrity, masking format preservation, application constraints, uniqueness, deterministic masking needs, and downstream dependencies.
+
+Gotchas:
+
+- Masking is usually irreversible.
+- Subsetting can break referential integrity if parent-child rules are incomplete.
+- Production masking is rarely the right control unless explicitly designed and approved.