orcasecurity

"¿Qué es esta alerta y debería importarme?"

Triaje inteligente de alertas que transforma alertas crudas de Orca en resúmenes amigables para analistas con líneas de tiempo de comportamiento, evaluación de riesgos y divulgación progresiva. Soporta anomalías, vulnerabilidades, malware y configuraciones incorrectas.

Características:

• Resúmenes con veredicto primero y puntuación de confianza (Probablemente Benigno, Amenaza Activa, Riesgo Corregible, etc.)
• Análisis visual de línea de tiempo que muestra el comportamiento de la alerta, cambios de estado y bloqueadores de remediación
• Cálculo del radio de explosión con correlación de activos y alertas relacionados
• Investigación automatizada con Orca primero — consulta CloudTrail, alertas relacionadas, rutas de ataque antes de sugerir pasos manuales
• Selector de formato de remediación — elige Terraform, CloudFormation, ARM/Bicep, Pulumi, CLI o instrucciones paso a paso
• Salida de código escrita a archivos automáticamente (por ejemplo, remediate-orca-3456789.tf)

Uso:

# Triage an alert
/orca-alert-triage orca-1234567

# Or use natural language
triage alert orca-9012345
explain orca-2345678

Comandos de seguimiento (escribe después del triaje):

investigate    # Automated Orca-first investigation with manual steps only for gaps
evidence       # Detailed metadata, hashes, links, MITRE ATT&CK mappings
remediate      # Choose output format, then get remediation written to a file
correlate      # Related alerts and attack pattern analysis

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
ANOMALY DETECTION: Unusual User Agent on EKS Node Role
═══════════════════════════════════════════════════════════════════

VERDICT: Likely Benign | CONFIDENCE: 90% | ACTION: Review & Close | TIMELINE: 48h

WHAT HAPPENED:
  EKS node role used a new AWS SDK version (boto3/1.35.x → 1.36.x)
  during routine cluster operations. Single occurrence, no recurrence.

WHY IT MATTERS:
  Risk Level: Low (Orca Score: 3.0)
  Same tool family, minor version bump, clean 30-day baseline.
═══════════════════════════════════════════════════════════════════

Documentación completa →

"Si arreglo esto, ¿qué se cierra — y qué se rompe?"

Analiza el impacto completo de la remediación al corregir una sola alerta de Orca — tanto las ganancias de seguridad (alertas cerradas, rutas de ataque rotas, cumplimiento aprobado) COMO el riesgo operativo (flujos de trabajo de producción, automatización, servicios que podrían romperse).

Características:

• Análisis de cascada — mapea todas las alertas que comparten la misma causa raíz que la alerta objetivo
• Impacto en rutas de ataque — identifica cadenas de eliminación que se rompen cuando se corrige la alerta
• Cambio en puntuación de cumplimiento — muestra porcentajes de cumplimiento antes/después por marco
• Vista de todo el entorno — encuentra el mismo problema en otros activos y cuentas
• Simulación de roturas — analiza eventos de CloudTrail/CDR y permisos efectivos para identificar dependencias de producción
• Veredicto ejecutivo — recomendación clara de CORREGIR AHORA / CORREGIR CON PRECAUCIÓN / PLANIFICAR CORRECCIÓN / DIFERIR que equilibra la ganancia de seguridad vs. el riesgo operativo
• Lista de verificación de despliegue seguro — pasos para aplicar la corrección sin romper la producción

Uso:

# Analyze impact of fixing an alert
/orca-impact-analysis orca-3456789

# Or use natural language
what's the impact of fixing orca-5678901?
if I fix orca-0123456, what else closes?

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
IMPACT ANALYSIS — orca-3456789
Root Account Without MFA Enabled
"If I enable MFA on root, what closes — and what breaks?"
═══════════════════════════════════════════════════════════════════

┌─────────────────────────────────────────────────────────────────┐
│  VERDICT: FIX NOW                                               │
│                                                                 │
│  Security gain:   HIGH — 2 critical alerts, 3 attack paths      │
│  Breakage risk:   LOW — no automation uses root console login   │
│  Blast radius:    2 alerts, 3 attack paths, 8 frameworks        │
└─────────────────────────────────────────────────────────────────┘

REMEDIATION IMPACT SUMMARY:
  Alerts directly closed:    2 (including this one)
  Attack paths broken:       3
  Compliance frameworks:     8 frameworks improved

  COMPLIANCE SCORE CHANGE:
    Framework              Current    After Fix    Change
    ─────────────────────────────────────────────────────
    PCI DSS v4.0.1          87%   →    89%         +2%
    NIST 800-53             91%   →    93%         +2%

BREAKAGE RISK:
  [ok] EKS automation — uses access keys (MFA doesn't apply)
  [ok] Orca scanner — uses service role (not affected)
  [x]  Unknown Kali agent — SHOULD break (that's the goal)

BOTTOM LINE: High-leverage, low-risk fix. Apply immediately.
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Quién hizo esto, cómo se desplegó, y qué introdujo el problema?"

Rastrea cualquier alerta de Orca — configuración incorrecta, vulnerabilidad, datos sensibles o anomalía — a través de registros de auditoría en la nube, Orca CodeOrigins (Shift Left) y metadatos de activos para encontrar quién creó el recurso, qué herramienta lo desplegó, qué introdujo el problema específico y una línea de tiempo completa desde el despliegue hasta la detección de la alerta.

Características:

• Clasificación de categoría de alerta — rastrea el origen de manera diferente para configuraciones incorrectas (la configuración ES la causa), vulnerabilidades (el paquete es la causa), datos sensibles (la imagen/script colocó el secreto) y anomalías (el actor ES el hallazgo)
• Integración con CodeOrigins / Shift Left — extrae el código fuente exacto de IaC (repositorio, archivo, números de línea, autor/commit de git blame)
• Rastreo de registros de auditoría vía Orca CDR (CloudTrail, Azure Activity Log, GCP Audit Log)
• Línea de tiempo visual completa desde el commit de código IaC → creación del recurso → introducción del problema → detección de la alerta, con cálculo de la ventana de exposición
• Propiedad dividida — distingue el propietario del recurso (quién desplegó) del propietario del problema (quién debería corregir)
• Detección de deriva de IaC — señala recursos creados por IaC pero modificados posteriormente vía Consola
• Enrutamiento de remediación consciente de la categoría — te dice DÓNDE aplicar la corrección según el tipo de alerta Y el método de despliegue

Uso:

# Trace origin of any alert
/orca-config-origin orca-3456789

# Or use natural language
who created this misconfiguration? orca-3456789
trace back orca-5678901
where did this config come from? orca-3364845

Ejemplo de salida (alerta de vulnerabilidad):

═══════════════════════════════════════════════════════════════════
CONFIG ORIGIN — orca-4567890
Apache Log4j Remote Code Execution Vulnerability (CVE-2021-45046)
═══════════════════════════════════════════════════════════════════

ASSET: web-bastion-host (AwsEc2Instance) in 123456789012
ISSUE: log4j-core v2.3 installed — critically vulnerable to RCE

┌─────────────────────────────────────────────────────────────────┐
│  DEPLOYED BY: Terraform (module "ec2_unpatched")                │
│  OWNER:       Alex Chen (alex@example-corp.com)                       │
│  ROOT CAUSE:  user_data script installs log4j-core-2.3.jar     │
│  LAST CHANGE: 2025-12-01 (137 days ago)                         │
│  METHOD:      Terraform → module "ec2/unpatched_ubuntu"         │
└─────────────────────────────────────────────────────────────────┘

TIMELINE:
  2024-06-23  ● Terraform code committed                  Alex Chen
              │ file: ec2.tf:71-80, commit: abc1234
  2025-12-01  ● Instance created — user_data installs log4j 2.3
              │ ⚠ VULNERABILITY INTRODUCED HERE
  2025-12-01  ● Alert detected by Orca (73 min after creation)
  2026-04-17  ● Today — 137 days exposed, still open

REMEDIATION ROUTING:
  ⚠ The fix is NOT in ec2.tf — the Terraform deploys correctly.
  FIX IN: module.scripts.ec2_unpatched (the user_data script)
  → Update script to install log4j-core ≥ 2.16.0
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Qué pasó mientras estaba fuera, y qué necesita mi atención?"

Informe de seguridad diario de las últimas 24-72 horas. Escanea tu entorno en busca de nuevas alertas críticas, hallazgos escalados, cambios en rutas de ataque, deriva de cumplimiento, cambios de exposición, anomalías de actividad CDR, riesgos de joyas de la corona y alertas antiguas sin acción — y luego lo presenta todo como un panel escaneable con secciones desglosables.

Características:

• Pulso del entorno — evaluación rápida de salud (estable, degradándose, necesita atención)
• Nuevas alertas críticas/altas con clasificación por prioridad
• Alertas escaladas — aumentos de severidad y hallazgos reabiertos
• Deriva de cumplimiento — puntuaciones de marco que bajaron, con desglose por cuenta
• Resumen de actividad CDR — volúmenes de eventos, actores inusuales, patrones sospechosos
• Riesgo de joyas de la corona — nuevas alertas en tus activos más críticos
• Críticos antiguos — alertas sin acción con estado de ticket de Jira
• Divulgación progresiva — panel primero (~20 líneas), profundiza por palabra clave
• Soporte de rango de tiempo — 24h (diario), 72h (lunes por la mañana), semana (regreso de PTO)

Uso:

# Daily briefing (last 24 hours)
/orca-morning-briefing

# Monday morning (last 72 hours)
/orca-morning-briefing 72h

# Weekly review
/orca-morning-briefing week

Palabras clave de profundización (escribe después del informe):

alerts         # Full list of new critical/high alerts
escalated      # Alerts that changed severity or reopened
attack paths   # New/worsened attack paths with stories
compliance     # Framework scores, trends, worst accounts
exposure       # Internet-facing assets with critical alerts
crown jewels   # New alerts on crown jewel assets
aging          # Unactioned critical alerts sorted by age
activity       # CDR event volumes, unusual actors
new types      # Alert types seen for the first time
trends         # Week-over-week comparison, top affected assets
full           # All sections expanded (for reports/handoffs)

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
MORNING BRIEFING — 2026-04-17
Last 24 hours | Account: 123456789012
═══════════════════════════════════════════════════════════════════

PULSE: ⚠ NEEDS ATTENTION — 3 new critical alerts

┌─────────────────────────────────────────────────────────────────┐
│  NEW ALERTS         12 total (3 critical, 4 high, 5 medium)    │
│  ESCALATED          2 alerts changed severity or reopened       │
│  ATTACK PATHS       1 new, 2 worsened                           │
│  COMPLIANCE         PCI DSS dropped 2%                          │
│  EXPOSURE           1 asset newly internet-facing               │
│  CROWN JEWELS       1 new alert on critical asset               │
│  AGING CRITICALS    4 critical alerts open > 7 days             │
│  CDR ACTIVITY       Elevated — 3.2k events (normal: ~1k)       │
└─────────────────────────────────────────────────────────────────┘

TOP PRIORITIES:
  [1] orca-4567890 — Log4j RCE on public bastion (137d open!)
  [2] orca-6789012 — S3 bucket publicly accessible (new today)
  [3] orca-7890123 — SendGrid API key exposed in container
═══════════════════════════════════════════════════════════════════

Documentación completa →

"Dime todo sobre este activo en un solo lugar."

Perfil de seguridad completo de 360° de cualquier activo en la nube — todas las alertas abiertas (agrupadas por categoría), rutas de ataque, violaciones de cumplimiento, permisos, exposición de red, datos sensibles, resumen de actividad CDR, estado de joya de la corona y entidades vinculadas.

Características:

• Identidad completa del activo — nombre, tipo, cuenta, región, IPs, SO, etiquetas, fecha de creación, fuente IaC
• Resumen de riesgo con Puntuación de Orca, estado de joya de la corona y clasificación de exposición
• Alertas agrupadas por categoría — vulnerabilidades, configuraciones incorrectas, malware, datos sensibles, anomalías, IAM
• Mapeo de rutas de ataque — cadenas de eliminación con el rol del activo (punto de entrada, pivote, objetivo)
• Violaciones de marcos de cumplimiento por activo
• Análisis de permisos efectivos (activos IAM de AWS) con desglose de usados vs. no usados
• Resumen de actividad CDR — volúmenes de eventos de 30 días, acciones principales, actores únicos
• Entidades vinculadas — roles conectados, instancias, buckets, bases de datos, balanceadores de carga
• Remediación proactiva — sugiere la corrección de mayor impacto y ofrece generar código en Terraform, CloudFormation, Ansible, CLI, Pulumi o ARM/Bicep

Uso:

# Profile an asset by name, ID, or ARN
/orca-asset-profile web-bastion-host
/orca-asset-profile i-1234567890abcdef0

# Or use natural language
tell me about web-bastion-host
asset risk for vm-chain3-1

Palabras clave de profundización (escribe después del perfil):

alerts         # All alerts by category
attack paths   # Kill chains with this asset
compliance     # Framework violations
permissions    # IAM analysis (used vs unused)
exposure       # Network exposure details
activity       # CDR events (last 30 days)
linked         # Connected assets
code origin    # IaC source mapping
full           # All sections expanded

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
ASSET PROFILE — web-bastion-host
AwsEc2Instance | 123456789012 | us-east-1 | running
═══════════════════════════════════════════════════════════════════

RISK: Orca Score 9.0 (Critical) | Crown Jewel: NO

┌─────────────────────────────────────────────────────────────────┐
│  ALERTS        12 total (3 critical, 4 high, 5 medium)         │
│  ATTACK PATHS  4 active kill chains                             │
│  COMPLIANCE    6 frameworks, 18 failing controls                │
│  EXPOSURE      public_facing | ports: 22, 443                   │
│  SENSITIVE     API keys, credentials                            │
│  PERMISSIONS   overprivileged (via instance profile)            │
│  CDR ACTIVITY  847 events in 30d (elevated)                     │
│  LINKED        9 connected assets                               │
└─────────────────────────────────────────────────────────────────┘

TOP ALERTS:
  [1] orca-4567890 — Log4j RCE (score: 9.0, vulnerability)
  [2] orca-7890123 — SendGrid API key exposed (score: 8.5, sensitive data)
  [3] orca-3456789 — Root account without MFA (score: 8.0, misconfiguration)

RECOMMENDED ACTION:
  The highest-impact fix is orca-4567890 (Log4j RCE on a public
  asset). I can generate remediation code right now.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Dónde estamos fallando, cuál es el camino más rápido para mejorar?"

Análisis profundo de brechas de cumplimiento para cualquier marco — controles fallidos clasificados por radio de explosión, victorias rápidas (controles de una sola corrección), desglose por cuenta, tendencias de puntuación y un plan de remediación por fases con mejoras proyectadas de puntuación. Características:

• Resumen del framework con puntuaciones, tendencias e identificación de lo peor y lo mejor
• Controles fallidos clasificados por impacto entre frameworks y número de activos
• Detección de victorias rápidas: correcciones de configuración única que mejoran múltiples frameworks a la vez
• Desglose por cuenta/unidad de negocio: quién es dueño de las brechas más graves
• Análisis de tendencia de cumplimiento a 30 días: mejorando, estable o degradando
• Plan de remediación por fases: victorias rápidas (días), correcciones sistemáticas (semanas), cambios arquitectónicos (meses)
• Mejoras proyectadas de puntuación por fase
• Remediación proactiva: ofrece generar código de corrección para cualquier control en Terraform, CloudFormation, Ansible, CLI, Pulumi o ARM/Bicep

Uso:

# All frameworks overview
/orca-compliance-gap

# Specific framework deep-dive
/orca-compliance-gap PCI DSS
/orca-compliance-gap CIS AWS

# Or use natural language
how's our PCI compliance?
what's failing in SOC 2?
quick wins for compliance

Palabras clave de profundización (escribir después del análisis):

controls         # All failing controls ranked by impact
quick wins       # Fastest path to score improvement
accounts         # Gap breakdown by account
trends           # 30-day score history
remediation plan # Phased fix plan with projections
full             # All sections expanded

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
COMPLIANCE GAP ANALYSIS — All Frameworks
2026-04-17 | All accounts
═══════════════════════════════════════════════════════════════════

POSTURE: Moderate — 3 frameworks below 85% target

┌─────────────────────────────────────────────────────────────────┐
│  FRAMEWORKS     8 enabled                                       │
│  AVG SCORE      84%                                             │
│  WORST          HIPAA at 71%                                    │
│  BEST           CIS AWS at 94%                                  │
│  TREND (30d)    degrading — PCI dropped 2%                      │
│  QUICK WINS     6 controls fixable with single changes          │
│  WORST ACCOUNT  123456789012 — 76% avg score                   │
└─────────────────────────────────────────────────────────────────┘

TOP FAILING CONTROLS (highest impact):
  [1] Enable MFA for root — failing on 3 accounts, affects 5 frameworks
  [2] Encrypt EBS volumes — failing on 12 assets, affects 4 frameworks
  [3] Restrict SSH access — failing on 8 assets, affects 4 frameworks

RECOMMENDED ACTION:
  The fastest score improvement: enable MFA for root —
  affects 3 accounts across 5 frameworks. I can generate the fix.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Dónde están nuestros datos sensibles, están protegidos y qué está en riesgo?"

Vista DSPM (Postura de Gestión de Seguridad de Datos): descubre datos sensibles en todo el entorno (secretos, PII, credenciales, claves API, datos financieros), identifica almacenes de datos desprotegidos o expuestos, clasifica los riesgos de datos por nivel de exposición y genera un plan de remediación.

Características:

• Escaneo DSPM completo: secretos, PII, credenciales, claves API, certificados, datos financieros
• Clasificación de riesgo: crítico (público + sensible), alto (interno + vulnerable), medio, bajo
• Agrupación por tipo de dato: secretos y credenciales, PII, datos financieros, datos de salud, claves privadas
• Detección de almacenes de datos públicos: buckets S3, bases de datos, recursos compartidos con acceso público
• Identificación de almacenes de datos sin cifrar con recomendaciones de cifrado
• Contexto de cumplimiento: estado de los controles de protección de datos PCI DSS, HIPAA, GDPR, SOC 2
• Desglose por cuenta de la distribución del riesgo de datos
• Plan de remediación por fases: detener la hemorragia, cifrar todo, controles de acceso, gobernanza
• Remediación proactiva: genera scripts de rotación, políticas de bucket, configuraciones de cifrado en Terraform, CloudFormation, Ansible, CLI, Pulumi o ARM/Bicep

Uso:

# Full DSPM report
/orca-data-exposure

# Filter by type or account
/orca-data-exposure secrets
/orca-data-exposure account 123456789012

# Or use natural language
where's our sensitive data?
find exposed API keys
what PII is at risk?

Palabras clave de profundización (escribir después del informe):

secrets          # Exposed secrets & credentials
pii              # PII exposure details
public data      # Publicly accessible data stores
unencrypted      # Data stores without encryption
compliance       # Data protection compliance status
accounts         # Data risk by account
remediation plan # Phased data protection plan
full             # All sections expanded

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
DATA EXPOSURE REPORT — All Accounts
2026-04-17 | Full environment
═══════════════════════════════════════════════════════════════════

DATA POSTURE: At Risk — 3 critical data exposures on public assets

┌─────────────────────────────────────────────────────────────────┐
│  TOTAL FINDINGS    24 data exposure alerts                      │
│  CRITICAL          3 — immediate breach risk                    │
│  HIGH              8 — significant exposure                     │
│  SECRETS           11 exposed credentials/API keys/tokens       │
│  PII               5 assets with personally identifiable data   │
│  PUBLIC DATA       2 publicly accessible data stores            │
│  UNENCRYPTED       6 data stores without encryption             │
│  CROWN JEWELS      2 data findings on critical assets           │
│  COMPLIANCE        PCI DSS, HIPAA gaps on data controls         │
└─────────────────────────────────────────────────────────────────┘

TOP DATA RISKS:
  [1] orca-7890123 — SendGrid API key in container image (score: 8.5)
      web-bastion-host | credential | public-facing
  [2] orca-8901234 — AWS access key in environment variable (score: 8.0)
      ci-build-server | infrastructure secret | internal
  [3] orca-6789012 — S3 bucket publicly accessible (score: 7.5)
      s3-data-lake-prod | PII + financial data | public

RECOMMENDED ACTION:
  Priority #1: Rotate the SendGrid API key on web-bastion-host and
  move to Secrets Manager. I can generate the rotation script.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Qué puede ver un atacante desde fuera?"

Mapeo de superficie de ataque externa: descubre todos los activos expuestos a internet, los clasifica por explotabilidad desde la perspectiva de un atacante, los agrupa por vector de ataque (servicios expuestos, almacenamiento público, aplicaciones web vulnerables, puertos de gestión abiertos) y mapea cadenas de ataque de afuera hacia adentro hasta los activos críticos.

Características:

• Inventario completo de superficie de ataque externa: activos expuestos a internet clasificados por riesgo
• Clasificación desde la perspectiva del atacante: "¿cómo priorizaría un atacante estos objetivos?"
• Agrupación por vector de ataque: victorias fáciles, aplicaciones web, puertos de gestión, datos públicos, puntos de entrada para movimiento lateral
• Mapeo de rutas de ataque de afuera hacia adentro: desde el activo expuesto a través de pivotes hasta los activos críticos
• Interfaces de gestión expuestas (SSH, RDP, paneles de administración) con estado de autenticación
• Detección de almacenes de datos públicos (S3, bases de datos, recursos compartidos)
• Desglose de exposición a nivel de cuenta
• Remediación proactiva: genera reglas de grupos de seguridad, políticas de bucket, configuraciones WAF en Terraform, CloudFormation, Ansible, CLI, Pulumi o ARM/Bicep

Uso:

# Full attack surface map
/orca-exposure-map

# Filter by account or vector
/orca-exposure-map account 123456789012
/orca-exposure-map web services

# Or use natural language
what's exposed to the internet?
show me our attack surface
what can an attacker see?

Palabras clave de profundización (escribir después del mapa):

easy wins      # Immediately exploitable — fix first
web apps       # Exposed web applications
management     # SSH, RDP, admin panels
data           # Public data stores
attack paths   # Outside-in kill chains
accounts       # Exposure by account
all assets     # Complete exposed asset list
full           # All sections expanded

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
EXPOSURE MAP — External Attack Surface
2026-04-17 | All accounts
═══════════════════════════════════════════════════════════════════

SURFACE: Moderate — 4 immediately exploitable targets

┌─────────────────────────────────────────────────────────────────┐
│  EXPOSED ASSETS     18 internet-facing                          │
│  CRITICAL RISK      4 immediately exploitable                   │
│  HIGH RISK          7 exploitable with effort                   │
│  PUBLIC STORAGE     2 buckets/blobs publicly accessible         │
│  EXPOSED MGMT       3 SSH/RDP/admin panels                      │
│  EXPOSED DATABASES  1 database reachable from internet          │
│  CROWN JEWELS       2 exposed critical assets                   │
│  ATTACK PATHS       5 outside-in kill chains                    │
└─────────────────────────────────────────────────────────────────┘

TOP TARGETS (attacker's priority list):
  [1] web-bastion-host — Log4j RCE + public SSH (score: 9.0)
      AwsEc2Instance | 54.210.xx.xx | ports: 22, 443, 8080
  [2] s3-data-lake-prod — public S3 with PII (score: 7.5)
      AwsS3Bucket | public-read | contains financial data
  [3] ci-build-server — exposed admin panel (score: 7.0)
      AwsEc2Instance | 52.90.xx.xx | ports: 8080, 50000

RECOMMENDED ACTION:
  Priority #1: Lock down web-bastion-host — patch Log4j and
  restrict SSH to VPN CIDR. I can generate the fix.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Esta identidad tiene privilegios excesivos y cuál es el radio de explosión?"

Análisis de identidad IAM: compara permisos efectivos frente al uso real en CloudTrail, identifica accesos con privilegios excesivos, mapea el potencial de movimiento lateral (asunciones de roles, alcance entre cuentas) y genera recomendaciones de políticas de mínimo privilegio.

Características:

• Análisis de permisos efectivos: acciones totales en todos los servicios
• Comparación de permisos usados frente a no usados a partir de datos de CloudTrail de 30 días
• Clasificación de privilegios excesivos: severo, alto, moderado o mínimo
• Detección de permisos peligrosos: iam:, sts:AssumeRole(amplio), s3:, kms:Decrypt, etc.
• Mapeo de movimiento lateral: roles asumibles, alcance entre cuentas, acceso a servicios
• Análisis de rutas de ataque: cadenas de ataque que pasan por esta identidad
• Patrones de actividad CDR: IPs de origen, user-agents, patrones de tiempo
• Recomendación de política de mínimo privilegio con reducción de riesgo estimada
• Lista de verificación de despliegue seguro: modo auditoría, pruebas, monitoreo, reversión
• Remediación proactiva: genera políticas IAM actualizadas en Terraform, CloudFormation, Ansible, CLI, Pulumi o ARM/Bicep

Uso:

# Review an identity by name or ARN
/orca-identity-review admin-role
/orca-identity-review arn:aws:iam::123456789012:role/ec2-bastion-role

# Or use natural language
is terraform-deploy overprivileged?
review the permissions on admin-role
what can this role access?

Palabras clave de profundización (escribir después de la revisión):

permissions    # Full permission list (used, unused, dangerous)
usage          # CDR activity details (actions, IPs, agents)
lateral        # Lateral movement analysis
attack paths   # Kill chains through this identity
alerts         # Open alerts on this identity
activity       # 30-day CDR event summary
recommend      # Least-privilege policy recommendation
full           # All sections expanded

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
IDENTITY REVIEW — ec2-bastion-role
AwsIamRole | 123456789012 | arn:aws:iam::123456789012:role/ec2-bastion-role
═══════════════════════════════════════════════════════════════════

VERDICT: OVERPRIVILEGED

┌─────────────────────────────────────────────────────────────────┐
│  PERMISSIONS     312 effective actions across 28 services       │
│  OVERPRIVILEGE   SEVERE — has admin-level access it doesn't use│
│  USED (30d)      47 actions actually used                       │
│  UNUSED          265 actions never used — removal candidates    │
│  DANGEROUS       8 high-risk permissions (iam:*, s3:*, kms:*)  │
│  BLAST RADIUS    28 services, 150+ resources reachable          │
│  LATERAL MOVE    5 roles assumable, 2 accounts reachable        │
│  ATTACK PATHS    3 kill chains through this identity            │
│  ALERTS          4 open (2 critical, 1 high, 1 medium)         │
│  CDR ACTIVITY    847 events in 30d, 47 unique actions           │
│  CROWN JEWEL     NO                                             │
└─────────────────────────────────────────────────────────────────┘

TOP RISK:
  This role has 265 unused permissions including iam:*, enabling
  full privilege escalation if compromised.

RECOMMENDED ACTION:
  Remove 265 unused permissions to reduce blast radius by 85%.
  I can generate the updated least-privilege policy.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Quién puede iniciar sesión sin MFA y cómo cerramos esa brecha sin bloquear a nadie?"

Barrido de brechas de MFA en una cuenta, unidad de negocio o etiqueta en cada nube que Orca soporta: encuentra usuarios cuyo inicio de sesión en consola no está protegido, los clasifica por puntuación de riesgo de identidad y impulsa la remediación mediante inscripción guiada o una ruta de aplicación con restricciones. Un usuario con solo contraseña está a un phishing de convertirse en atacante, y ninguna nube permite que un administrador inscriba MFA en nombre de alguien, por lo que la aplicación significa una política que bloquea al usuario hasta que se inscriba él mismo.

Características:

• Cobertura entre nubes: AWS, Azure (incl. Entra ID), GCP (vía Google Workspace), Alibaba Cloud, OCI, Tencent Cloud
• Matriz de capacidades por proveedor: qué significa MFA en cada nube y qué no puede mostrarte cada una
• Clasificación priorizando el riesgo con incrementos por privilegios, activos críticos y alertas abiertas
• Cuentas raíz manejadas con fallo cerrado en su propio grupo: una señal raíz ilegible escala en lugar de descartarse
• Remediación consciente del uso: una contraseña de consola que nadie usa se elimina en lugar de inscribirse
• Tres rutas con restricciones: guiar (instrucciones + notificaciones al propietario), aplicar (política de requisito de MFA), eliminar-acceso (borrar un perfil de inicio de sesión no usado)
• Confirmación basada en evidencia: la consecuencia se reafirma antes del consentimiento, y una instrucción masiva nunca implica aplicación
• Ejecuciones sin hallazgos publican prueba de completitud en lugar de un "nada encontrado" vacío
• Bucle cerrado: las acciones se comentan y se posponen en las alertas relacionadas, con una verificación posterior al escaneo

Uso:

# Sweep an account, business unit, or tag
/orca-mfa-enforcement 123456789012
/orca-mfa-enforcement "Production"
/orca-mfa-enforcement --tag env=prod

# Or use natural language
who can log in without MFA?
does our root account have MFA?
find console users missing 2FA in the Production BU

Palabras clave de profundización (escribir después del barrido):

detail <user>     # Full evidence for one identity
guide <ids|all>   # Enrollment instructions + owner notifications
enforce <ids>     # Require-MFA policy (passes the confirmation gate)
remove-access     # Delete an unused console password (gated)
recheck           # Post-scan delta: who enrolled, which alerts closed
cloud <provider>  # Re-scope to one cloud

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
MFA SWEEP — acme-production
═══════════════════════════════════════════════════════════════════

8 users can sign in without MFA, including the root account.
2 are privileged. 1 signed in password-only this week.

 #  Identity                                   Provider  Risk      Action
 1  arn:aws:iam::123456789012:user/deploy      AWS       Critical  Guide, then enforce
 2  arn:aws:iam::123456789012:root             AWS       High      Guide only (root)
 3  arn:aws:iam::123456789012:user/analyst     AWS       High      Remove unused password

ROOT ACCOUNT:
  No API can enroll MFA on root — the account owner must do it signed
  in as root. Hardware MFA recommended (CIS).

QUICK WINS:
  6 console passwords were never used. Removing them closes the gap
  with zero user friction, and access keys are untouched.

MFA ENFORCEMENT SUMMARY
  Found: 8   Proposed: 8   Guided: 0   Enforced: 0   Skipped: 0
  Routed: 18 outside Found (14 API-only, 4 dormant — not MFA gaps)
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Qué pasó, quién lo hizo y hasta dónde llegaron?"

Investigación de incidentes impulsada por CDR: rastrea la actividad del actor a través de Orca CDR (registros de CloudTrail/auditoría), construye líneas de tiempo de sesiones, mapea acciones a técnicas MITRE ATT&CK, agrupa sesiones relacionadas, evalúa el radio de explosión y genera un veredicto con recomendaciones de contención.

Características:

• Investigación multi-eje: por actor (identidad IAM), IP de origen, recurso objetivo, cuenta o alerta
• Agrupación de sesiones: agrupa eventos brutos en sesiones coherentes por actor, IP y brechas de tiempo
• Mapeo MITRE ATT&CK: mapea cada acción a técnicas y tácticas con niveles de confianza
• Evaluación de cadena de ataque: cuántas tácticas ATT&CK están cubiertas (parcial, casi completa, completa)
• Clasificación de radio de explosión: contenido, moderado, amplio o severo
• Detección de persistencia: nuevos usuarios, claves de acceso, políticas de rol creadas
• Detección de evasión de defensas: eliminación de registros, cambios en grupos de seguridad, registro deshabilitado
• Marcado de actividad entre cuentas
• Extracción de IOC: IPs, user-agents, identidades, recursos creados (listo para copiar y pegar en herramientas SOC)
• Veredicto con confianza: compromiso activo, compromiso probable, sospechoso, probablemente benigno, no concluyente
• Contención proactiva: genera scripts de revocación, configuraciones de aislamiento, reglas de detección en Terraform, CloudFormation, Ansible, CLI, Pulumi o ARM/Bicep

Uso:

# Investigate by actor, IP, or resource
/orca-investigate arn:aws:iam::123456789012:role/ec2-bastion-role
/orca-investigate 10.0.1.50
/orca-investigate account 123456789012

# Or use natural language
investigate what this role did in the last 24 hours
trace activity from IP 10.0.1.50
who accessed the prod database?

Palabras clave de profundización (escribir después de la investigación):

timeline       # Chronological event timeline
sessions       # Clustered sessions with assessment
mitre          # MITRE ATT&CK technique mapping
blast radius   # Impact assessment
actions        # All actions summary
resources      # Resources touched
alerts         # Related alerts
iocs           # Indicators of compromise (copy-paste ready)
contain        # Containment recommendations
full           # All sections expanded

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
INVESTIGATION — ec2-bastion-role
arn:aws:iam::123456789012:role/ec2-bastion-role | Last 24 hours
═══════════════════════════════════════════════════════════════════

VERDICT: SUSPICIOUS | CONFIDENCE: 72%

┌─────────────────────────────────────────────────────────────────┐
│  EVENTS          156 total, 23 unique actions                   │
│  SESSIONS        3 distinct sessions                            │
│  TIME SPAN       04:12 → 16:47 UTC (12h 35m)                  │
│  SERVICES        7 AWS services touched                         │
│  RESOURCES       34 distinct resources accessed                 │
│  SOURCE IPs      2 unique (1 known VPN, 1 unknown)             │
│  USER AGENTS     2 unique (boto3, aws-cli)                      │
│  BLAST RADIUS    MODERATE — multiple services, same account     │
│  MITRE ATT&CK   5 techniques across 4 tactics                  │
│  ALERTS          4 related alerts on involved assets            │
│  ATTACK PATHS    3 kill chains involving this actor             │
└─────────────────────────────────────────────────────────────────┘

EXECUTIVE SUMMARY:
  ec2-bastion-role had 3 sessions in the last 24h. Session 2 came
  from an unknown IP and performed unusual discovery actions across
  S3 and IAM. No persistence or exfiltration detected yet.

MITRE ATT&CK COVERAGE:
  ■ Initial Access    □ Execution    □ Persistence    □ Priv Esc
  □ Defense Evasion   ■ Discovery    □ Lateral Move   ■ Collection
  □ Exfiltration      □ Impact

RECOMMENDED ACTION:
  Investigate the unknown source IP in Session 2. I can generate
  a containment script to restrict this role's permissions.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Dónde estamos gastando de más y qué deberíamos corregir primero?"

Analiza todos los activos en la nube mediante datos de Orca Security MCP para identificar oportunidades accionables de reducción de costos en cómputo, bases de datos, almacenamiento, redes y recursos serverless. Entrega un informe para dos audiencias: un resumen ejecutivo con rango de ahorro total y un plan de acción por activo con enlaces a la plataforma Orca, enlaces a consolas de nube, comandos CLI y ahorro mensual proyectado por elemento.

Características:

• 10 patrones de optimización: recursos inactivos, ajuste de tamaño, actualizaciones de generación, instancias reservadas, migración a spot, dimensionamiento de bases de datos, Multi-AZ en no producción, EBS gp2→gp3, niveles de S3/objetos, limpieza de red
• Salida para dos audiencias: resumen ejecutivo (arriba y abajo del informe) más pasos de implementación listos para ingenieros
• Cada recomendación incluye enlaces profundos a la plataforma Orca y URLs de consola del proveedor de nube como evidencia
• Descubrimiento de activos en Fase 1 en paralelo en todas las categorías de recursos (EC2, EBS, S3, RDS, Lambda, NAT Gateways, EIPs, balanceadores de carga)
• Hoja de ruta de implementación en 3 fases: victorias rápidas sin tiempo de inactividad, cambios con ventana de mantenimiento, compromisos financieros
• Consultas de precios en vivo (búsqueda web) con respaldo a datos de entrenamiento cuando no están disponibles

Uso:

# Run a cost optimization report
/orca-cloud-cost-optimizer

# Or use natural language
give me a cost optimization report
where are we wasting money on cloud?
how do we cut our AWS bill?
find unused resources
what can we rightsize?

Ejemplo de salida:

# ☁️ Cloud Cost Optimization Report

Generated: 2026-05-01
Environment: AWS (us-east-1, us-east-2, eu-central-1) | Azure (eastus)
Assets analyzed: 450 across 5 AWS accounts

## 📊 Executive Summary

| | |
|---|---|
| Total assets analyzed | 450 |
| Assets with savings opportunities | 150 (33%) |
| Estimated monthly savings | $2,100 – $3,400/month |
| Estimated annual savings | $25,200 – $40,800/year |
| Immediate low-risk savings (this week) | $800/month |

🏆 Top 5 Quick Wins:
1. EBS gp2→gp3 migration (124 volumes) — $430/month — Very Low Risk
2. Disable Multi-AZ on staging RDS (analytics-db-staging) — $438/month — Low Risk
3. m4.2xlarge→m6i.2xlarge generation upgrade (api-staging-01) — $291/month — Low Risk
4. Release idle Elastic IPs (3 unassociated) — $10/month — Very Low Risk
5. S3 lifecycle policies (cloudtrail + log buckets) — $120/month — Very Low Risk

Documentación completa →

"¿Cómo creo un framework de cumplimiento personalizado adaptado a mis necesidades?"

Crea frameworks de cumplimiento personalizados en Orca Security a partir de controles de frameworks existentes, listas de alertas o temas de seguridad. Recopila controles relevantes mediante herramientas de lectura MCP, los organiza en secciones lógicas y envía el framework a Orca mediante la API REST. Cuando existen brechas (controles que el usuario quiere pero Orca no tiene una regla integrada), sugiere crear alertas de descubrimiento personalizadas para llenarlas.

Características:

• 3 modos de entrada: basado en tema ("Seguridad de Cadena de Suministro"), desde-framework ("from:cis_docker") o lista de alertas
• Extrae controles de múltiples frameworks existentes y deduplica rule_ids
• Organiza en secciones temáticas con pesos de prioridad (alto/medio/bajo)
• Crea frameworks mediante la API REST de Orca (POST /api/compliance/frameworks)
• Identifica brechas de cobertura y sugiere alertas de descubrimiento personalizadas (POST /api/sonar/rules)
• Validación posterior a la creación con puntuación de cumplimiento inicial

Uso:

/orca-custom-framework Supply Chain Security Controls
/orca-custom-framework from:cis_docker_v.1.3.1
/orca-custom-framework alerts:orca-1234,orca-5678

# Or use natural language
create a custom compliance framework for supply chain security
build a framework based on CIS Docker + EKS controls
generate a custom framework from these alerts

Ejemplo de salida:

=====================================================================
CUSTOM FRAMEWORK CREATED
=====================================================================

  FRAMEWORK     Supply Chain Security Controls
  ID            3104
  CONTROLS      39 total across 6 sections
  INITIAL SCORE 28%
  CLOUD         aws, azure, gcp, shiftleft

SECTIONS:
  1. Container Image & Registry Security       6 controls
  2. Container Runtime Protection              8 controls
  3. Kubernetes Admission & Policy Controls    8 controls
  4. Secrets & Credential Management           7 controls
  5. Build Pipeline & Artifact Integrity       4 controls
  6. Audit Logging & Monitoring                6 controls

COVERAGE GAPS (suggest custom discovery alerts):
  - SBOM generation and validation
  - Container image signing (SLSA provenance)
  - Dependency vulnerability scanning in CI/CD
=====================================================================

Documentación completa →

"¿Por qué mi Conector Kubernetes no se instala o no se conecta?" Solución de problemas de autoservicio para el Conector de Kubernetes (Cliente de túnel K8s, gráfico de Helm orca-tunnel). Toma la entrada bruta del cliente (un mensaje de error, helm status, kubectl describe o registros de pods) y la asigna a una categoría conocida de fallo en la instalación o en tiempo de ejecución, luego guía paso a paso la remediación liderada por una corrección de una línea antes del detalle técnico. Hace preguntas aclaratorias cuando la entrada es ambigua y produce un traspaso de soporte limpio para cualquier cosa que no pueda resolver, incluidas las limitaciones conocidas de la plataforma que no se pueden solucionar desde el lado del cliente.

Características:

• Clasifica la entrada en tiempo de instalación (el gráfico nunca se implementó) frente a tiempo de ejecución (implementado, el túnel/escaneo no funciona), comenzando con una verificación de cordura sobre si el clúster necesita el Conector en absoluto
• Incluye una tabla de referencia rápida de síntoma → categoría para que un error pegado salte directamente a la corrección en lugar de revisar la lista completa
• Cubre 15 categorías de fallo conocidas: conectividad TLS/red, RBAC, extracción de imágenes, parámetros incorrectos de --set, incompatibilidad de versiones, entradas de clúster duplicadas, restricciones de recursos, espacios de nombres personalizados, tokens de cuenta de servicio caducados (K8s 1.30+), bloqueo de salida del servidor API por NetworkPolicy, caídas de autenticación del túnel, configuración incorrecta del proxy (incluidos proxies con inspección TLS), fallos de DNS, problemas de SCC en OpenShift y "conectado pero sin datos de escaneo"
• Reconoce limitaciones de la plataforma que el cliente no puede solucionar por sí mismo (por ejemplo, las cuentas BYOC no ejecutan escaneo de Kubernetes, objetivos de túnel obsoletos, un error conocido de caída del túnel en AKS) y escala en lugar de repetir el ciclo, mientras señala la API de eliminación de autoservicio para entradas de clúster duplicadas en lugar de escalar ese caso
• Produce un resumen estructurado de traspaso de soporte (tipo de clúster, versión del conector, categoría, IDs, registros) cuando no puede resolver el problema

Uso:

/orca-k8s-connector-troubleshoot <paste error, helm status, kubectl describe, or pod logs>

# Or natural language
the k8s connector pod is stuck in ImagePullBackOff
tunnel keeps disconnecting, logs show TLS handshake timeout
cluster shows connected in Orca but no inventory data is showing up

Documentación completa →

"¿Cuáles de nuestras identidades son peso muerto y cómo las deshabilitamos o eliminamos de forma segura?"

Barre una cuenta o unidad de negocio en busca de identidades inactivas (usuarios, grupos e identidades no humanas) en todos los proveedores de nube que Orca admite: AWS, Azure (incl. Entra ID), GCP (incl. Google Workspace), Alibaba Cloud, OCI y Tencent Cloud. Clasifica los hallazgos por puntuación de riesgo de identidad y dirige la limpieza a través de una ruta no destructiva (deshabilitar) o una ruta destructiva (eliminar) que siempre requiere confirmación explícita.

Características:

• Pregunta por el período de inactividad si no se proporciona (90 días es la convención integrada de Orca; se admiten 30/60/180 o personalizados)
• Cobertura entre nubes: usuarios, grupos y NHI para los seis proveedores admitidos
• Anclado en el veredicto de actividad precalculado de Orca (marcas de tiempo de última actividad), con corroboración de CDR
• Clasificación priorizando el riesgo: administradores inactivos, credenciales expuestas y acceso a activos críticos flotan a la cima
• Flujo de deshabilitación primero: desactivación reversible ahora, eliminación después de un período de gracia
• Puerta de confirmación explícita antes de cualquier eliminación, con vista previa del radio de impacto (qué sigue referenciando la identidad)
• Exclusiones automáticas: cuentas de emergencia, identidades demasiado nuevas para juzgar, casos límite posiblemente humanos
• Artefactos de remediación listos para ejecutar (CLI/Terraform) con los requisitos previos de eliminación ordenados correctamente
• Resumen de limpieza obligatorio: encontradas, deshabilitadas, eliminadas, propuestas, omitidas y una estimación de las alertas que se cerrarán

Uso:

# Sweep an account or business unit
/orca-inactive-identities-cleanup 123456789012
/orca-inactive-identities-cleanup "Production"

# Custom time frame, scope, or action
/orca-inactive-identities-cleanup 123456789012 --inactive 60d
/orca-inactive-identities-cleanup 123456789012 --only nhis
/orca-inactive-identities-cleanup 123456789012 --action disable

# Or use natural language
clean up inactive identities in acme-production
which users haven't been active in the last 60 days?
disable the dormant service accounts in the Production BU

Palabras clave de profundización (escribe después del barrido):

detail <identity>   # Full evidence for one identity
disable <ids|all>   # Generate disable artifacts
delete <ids>        # Delete flow (explicit confirmation required)
window <Nd>         # Re-run with a different time frame
only <bucket>       # users | groups | nhis
cloud <provider>    # aws | azure | gcp | alicloud | oci | tencent

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
INACTIVE IDENTITY CLEANUP — acme-production
Window: 60 days | AWS + Azure + GCP
═══════════════════════════════════════════════════════════════════

62 identities inactive for 60+ days: 41 users, 6 groups, 15 NHIs.
9 carry high or critical risk.

TOP RISK (highest first):
  #  Identity              Type      Provider  Last active  Risk      Action
  1  legacy-admin          IAM user  AWS       142d ago     Critical  Disable now
  2  svc-deploy-old        SP        Azure     never        High      Disable now
  3  ci-runner-2019        Role      AWS       201d ago     High      Disable now

QUICK WINS: 12 identities with zero privileges and zero activity.

CLEANUP SUMMARY  (window: 60 days)
  Found:     62 | Disabled: 0 | Deleted: 0 | Proposed: 55 | Skipped: 7
  Alerts:    ~24 open alerts on these identities close after the next scan
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Cuáles de nuestras identidades tienen mucho más permiso del que usan y cómo las reducimos de forma segura?"

Barre una cuenta o unidad de negocio en busca de identidades con privilegios excesivos utilizando las recomendaciones precalculadas de PoLP (Principio de Mínimo Privilegio) de Orca en AWS, Azure y GCP. Clasifica los hallazgos por puntuación de riesgo de identidad y dirige el ajuste de tamaño a través de una ruta no destructiva (preparar el cambio como artefactos listos para ejecutar) o una ruta destructiva (aplicar) que siempre requiere una verificación de seguridad basada en evidencia más confirmación explícita.

Características:

• Anclado en el motor de recomendaciones de Orca: veredictos por identidad calculados a partir de ~90 días de uso observado
• Correcciones tipificadas por identidad: cambio a solo lectura, reducción de alcance, política de mínimo privilegio generada o conversión JIT
• Clasificación priorizando el riesgo con una columna de "cuán sobre-privilegiado" (servicios usados frente a concedidos)
• Flujo de preparación primero: artefactos con reversión y verificación integradas, nada se aplica automáticamente
• Puerta de aplicación basada en evidencia: reproduce la actividad reciente real de la identidad (CDR) contra el cambio propuesto e informa exactamente qué se rompería
• Confirmación explícita antes de cualquier aplicación, con vista previa del radio de impacto para roles
• Exclusiones automáticas: identidades gestionadas por el proveedor, cuentas de emergencia, roles de proveedor/cuenta cruzada
• Traspasos limpios: las identidades inactivas se enrutan a orca-inactive-identities-cleanup, los candidatos JIT a conversión JIT
• Resumen de ajuste de tamaño obligatorio: encontradas, preparadas, aplicadas, retenidas, omitidas y los permisos permanentes que el plan elimina

Uso:

# Sweep an account or business unit
/orca-overprivileged-identities-rightsizing 123456789012
/orca-overprivileged-identities-rightsizing "Production"

# Scope, provider, or pre-selected path
/orca-overprivileged-identities-rightsizing 123456789012 --only nhis
/orca-overprivileged-identities-rightsizing 123456789012 --cloud aws
/orca-overprivileged-identities-rightsizing 123456789012 --action stage

# Or use natural language
right-size the over-privileged identities in acme-production
which roles have permissions they never use?
who has admin but only ever reads?

Palabras clave de profundización (escribe después del barrido):

detail <identity>   # Full evidence: used vs granted, the recommendation
stage <ids|all>     # Generate right-sizing artifacts (nothing applied)
apply <ids>         # Apply flow (safety check + explicit confirmation)
safecheck <identity># Run the CDR replay on its own
cloud <provider>    # aws | azure | gcp
only <bucket>       # users | nhis

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
OVER-PRIVILEGED IDENTITY RIGHT-SIZING — acme-production
Engine window: ~90 days | AWS + Azure + GCP
═══════════════════════════════════════════════════════════════════

31 identities hold permissions they haven't used in ~90 days:
9 users, 22 NHIs. 7 carry high or critical risk; right-sizing
removes ~840 unused permissions.

TOP RISK (highest first):
  #  Identity        Type     Provider  Uses            Recommendation    Risk      Change
  1  deploy-runner   Role     AWS       3 of 41 svcs    Reduce perms      Critical  Apply least-priv policy
  2  ops-sp-legacy   SP       Azure     read-only use   Read-only swap    High      Swap to Reader
  3  etl-sa          SA       GCP       narrow scope    Scope reduction   High      Re-scope binding

QUICK WINS: 5 identities only ever read; swap to read-only today.

RIGHT-SIZING SUMMARY  (engine window: ~90 days)
  Found: 31 | Proposed: 24 | Staged: 0 | Applied: 0 | Held: 0 | Skipped: 3 | JIT: 4
  Handed off: 12 inactive -> /orca-inactive-identities-cleanup
  Removes: ~840 unused service grants once the staged plan is applied
═══════════════════════════════════════════════════════════════════

Documentación completa →

"¿Cuántas políticas necesitan realmente nuestros administradores y quién va en cada una?"

Lee la agrupación de administradores precalculada de Orca (Optimizador de Políticas IAM) para AWS, Azure y GCP, que ya ha clasificado a la población de administradores de la organización en grupos según lo que cada administrador hace realmente y ha generado una política de mínimo privilegio por grupo. Presenta la agrupación recomendada por el motor, muestra lo que cada grupo obtendría en lugar de AdministratorAccess / Owner generalizados y dirige el intercambio a través de una ruta no destructiva (preparar) o una ruta destructiva (aplicar) que siempre requiere confirmación explícita por grupo.

Características:

• Una llamada MCP a nivel de organización (get_recommended_admin_policies) devuelve cada grupo con cada miembro, sin límite de 50 resultados, por lo que la enumeración es completa en lugar de de mejor esfuerzo
• Se basa en el plan recomendado por el propio motor; otras agrupaciones (políticas más estrictas frente a menos políticas que mantener) disponibles a petición
• Comienza con el grupo inactivo: administradores para los que Orca no encontró acciones observadas, transferidos a /orca-inactive-identities-cleanup
• Expone explícitamente la compensación de la unión: una política de grupo es la unión de las acciones observadas de sus miembros, por lo que cada miembro gana lo que usaron sus compañeros de grupo
• Precisión por proveedor: AWS emite una política IAM (con alcance de acciones, Resource: "*"), Azure un rol RBAC personalizado, GCP un rol personalizado, todos como borradores que necesitan correcciones de alcance y nombres antes de la implementación
• Honesto sobre la población: cubre administradores que ya tienen una recomendación PoLP de Orca, no todos los administradores de la organización
• Enriquecimiento limitado: puntuaciones de riesgo, verificaciones de "sigue siendo administrador" y última actividad solo al profundizar en un grupo
• Puerta de aplicación: reproducción de actividad contra la política propuesta, verificación del radio de impacto para roles / entidades de servicio / identidades gestionadas, confirmación explícita que nombra el grupo
• Resumen de agrupación obligatorio: en alcance, inactivos, agrupados, propuestos, preparados, aplicados, retenidos, omitidos

Uso:

# Default run — engine-recommended grouping, all providers
/orca-admin-access-grouping

# Narrow or re-plan
/orca-admin-access-grouping --cloud aws
/orca-admin-access-grouping --plan 3
/orca-admin-access-grouping --group 2

# Or use natural language
group our admins and show me what each group would get
how many admin policies do we actually need?
replace AdministratorAccess with something scoped

Palabras clave de profundización (escribe después de la ejecución):

group <n>           # Members, risk, still-admin status, and the union delta
plan <n>            # Re-render against a different number of groups
stage <group|all>   # Generate artifacts, apply nothing
apply <group>       # Apply flow (replay + explicit confirmation required)
safecheck <group>   # Run the activity replay on its own
cloud <provider>    # aws | azure | gcp

Ejemplo de salida:

═══════════════════════════════════════════════════════════════════
ADMIN ACCESS GROUPING — acme-corp
Plan: plan_2 (engine recommendation) | AWS + GCP
═══════════════════════════════════════════════════════════════════

61 of the 67 AWS admins Orca can act on show no observed activity
in the last 90 days. The remaining 6 need two policies between them.

GROUPS (biggest standing-risk reduction first):
  #  Group     Members  Granted  Avg used  Instead of
  1  policy_1  5        16       3         AdministratorAccess
  2  policy_2  1        136      136       AdministratorAccess

UNION NOTE: in group 1, three members gain iam:CreateUser and
iam:DeleteUser from a fourth. Review before applying.

INACTIVE: 61 admins → /orca-inactive-identities-cleanup

ADMIN GROUPING SUMMARY  (window: last 90 days; artifact: daily snapshot)
  In scope: 67 | Inactive: 61 | Grouped: 6 | Proposed: 2 | Applied: 0
═══════════════════════════════════════════════════════════════════

Documentación completa →