v0.2.0-draft AI Drafted
Home / Guides / Orca Security

Orca Security Hardening Guide

Security Last updated: 2026-08-08

Cloud security platform hardening for Orca Security including SAML SSO, role-based access, and cloud account integration

Product Docs API Docs
Code Packs: Terraform
View:

Overview

Orca Security is a cloud security platform providing agentless workload protection and cloud security posture management. As a platform with visibility into cloud infrastructure, Orca security configurations directly impact cloud security operations.

Intended Audience

  • Security engineers managing cloud security
  • IT administrators configuring Orca
  • Cloud security architects
  • GRC professionals assessing cloud security

How to Use This Guide

  • L1 (Crawl): Essential controls for all organizations
  • L2 (Walk): Enhanced controls for security-sensitive environments
  • L3 (Run): Strictest controls for regulated industries

Scope

This guide covers Orca platform security including SSO, RBAC, network restriction, cloud account integration, and audit logging.

Orca’s admin knowledge base is region-gated and not publicly citable, so controls here are grounded in Orca’s publicly documented Terraform provider (the authoritative record of what the platform actually exposes) and console steps are described generically. Tier 3/4 sources are out of scope for this guide’s control text.

Table of Contents

  1. Authentication & SSO
  2. Access Controls
  3. Cloud Integration Security
  4. Compliance Quick Reference

1. Authentication & SSO

1.1 Configure SAML Single Sign-On

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 6.3, 12.5
NIST 800-53 IA-2, IA-8

Description

Configure SAML SSO for Orca platform access.

Rationale

Why This Matters:

  • Centralizes Orca authentication in your corporate IdP, enforcing MFA and conditional access on every login to the cloud security console
  • Local password logins bypass IdP controls and are prime targets for credential stuffing and phishing
  • Centralized provisioning and deprovisioning removes access for departed users automatically, eliminating orphaned accounts with standing visibility
  • Orca holds a complete map of cloud assets, vulnerabilities, and misconfigurations — a single compromised login hands an attacker a blueprint of where you are weakest

Attack Prevented: Credential theft, phishing, orphaned-account access, reconnaissance of cloud weaknesses

Prerequisites

  • Orca admin access
  • SAML 2.0 compatible IdP

ClickOps Implementation

Step 1: Access SSO Settings

  1. Navigate to: Settings → Authentication → SSO
  2. Enable SAML authentication

Step 2: Configure SAML

  1. Configure IdP settings:
    • Entity ID
    • SSO URL
    • Certificate
  2. Configure Orca in IdP

Step 3: Test and Enforce

  1. Test SSO authentication
  2. Enable SSO enforcement
  3. Configure fallback access

Time to Complete: ~1-2 hours

Code Implementation

Code Pack: Terraform
hth-orca-1.01-configure-saml-sso.tf View source on GitHub ↗ 
# SSO user group -- assign SSO-authenticated users here for group-based policies
resource "orcasecurity_group" "sso_users" {
  name        = var.sso_group_name
  description = "Group for SSO-authenticated users. Assign this group in SAML IdP attribute mappings to enforce group-based access control."
  sso_group   = true
  users       = var.sso_user_ids
}

1.2 Enforce Multi-Factor Authentication

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 6.5
NIST 800-53 IA-2(1)

Description

Require MFA for all Orca users.

Rationale

Why This Matters:

  • A second authentication factor stops attackers who have already stolen or guessed a valid Orca password
  • Orca’s console exposes the organization’s full cloud risk posture, so a single-factor compromise leaks high-value security intelligence
  • Phishing-resistant methods such as FIDO2/WebAuthn for admins defeat real-time credential-relay and one-time-code interception
  • Enforcing MFA on every account closes the gap left by reused or previously breached corporate passwords

Attack Prevented: Credential stuffing, password reuse, phishing, MFA-bypass via stolen passwords

ClickOps Implementation

Step 1: Configure via IdP

  1. Enable MFA in identity provider
  2. All SSO users subject to IdP MFA
  3. Use phishing-resistant methods for admins

Code Implementation

Code Pack: Terraform
hth-orca-1.02-enforce-mfa.tf View source on GitHub ↗ 
# Alert for IAM misconfigurations related to authentication weaknesses
resource "orcasecurity_custom_sonar_alert" "mfa_not_enforced" {
  name          = "Orca Users Without SSO/MFA Coverage"
  description   = "Detects scenarios where cloud identities connected to Orca may not have MFA enforced, indicating a gap in authentication hardening."
  rule          = "User with MFAEnabled = false"
  orca_score    = 8.0
  category      = "Authentication"
  context_score = true

  remediation_text = {
    enable = true
    text   = "Ensure all users authenticate through the configured SAML SSO provider with MFA enforced. Remove local accounts that bypass SSO. See HTH Orca Guide section 1.2."
  }

  compliance_frameworks = [
    { name = "HTH Orca Hardening", section = "1.2 Enforce MFA", priority = "high" }
  ]
}

2. Access Controls

2.1 Configure Role-Based Access Control

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.4
NIST 800-53 AC-6

Description

Implement least privilege using Orca roles.

Rationale

Why This Matters:

  • Least-privilege roles ensure each user can only see and act on what their job requires, limiting the blast radius of any one compromised account
  • Default broad roles let analysts or viewers reach sensitive findings and configuration controls they should never touch
  • Custom roles scoped to specific accounts prevent lateral visibility across unrelated business units
  • Quarterly access reviews catch privilege creep and remove standing access that accumulated beyond need

Attack Prevented: Privilege escalation, lateral movement, insider misuse, excessive data exposure

ClickOps Implementation

Step 1: Review Roles

  1. Navigate to: Settings → Users & Roles
  2. Review available roles:
    • Admin
    • Security Analyst
    • Viewer
  3. Assign minimum necessary role

Step 2: Configure Custom Roles

  1. Create roles for specific needs
  2. Limit scope to required accounts
  3. Apply asset-level permissions

Step 3: Regular Reviews

  1. Quarterly access reviews
  2. Remove inactive users
  3. Update role assignments

Code Implementation

Code Pack: Terraform
hth-orca-2.01-configure-rbac.tf View source on GitHub ↗ 
# Read-only Security Analyst role -- least privilege for daily operations
resource "orcasecurity_custom_role" "security_analyst" {
  name        = var.readonly_role_name
  description = "Read-only role for security analysts. Permits viewing assets, alerts, dashboards, and compliance reports without modification rights. Per HTH Orca Guide 2.1."

  permission_groups = var.readonly_permissions
}

# Minimal Viewer role -- dashboard and asset visibility only
resource "orcasecurity_custom_role" "viewer" {
  name        = var.viewer_role_name
  description = "Minimal viewer role for stakeholders who need visibility into cloud security posture without operational access. Per HTH Orca Guide 2.1."

  permission_groups = var.viewer_permissions
}

# Alert when users have overly broad permissions
resource "orcasecurity_custom_sonar_alert" "excessive_permissions" {
  name          = "Cloud Identity with Excessive Permissions"
  description   = "Detects cloud identities with overly broad permissions that violate least privilege principles."
  rule          = "User with Permission = '*' or Permission = 'Admin'"
  orca_score    = 7.5
  category      = "IAM misconfigurations"
  context_score = true

  remediation_text = {
    enable = true
    text   = "Review and reduce permissions to the minimum required for the user's role. Use the Security Analyst or Viewer custom roles instead of Admin. See HTH Orca Guide section 2.1."
  }

  compliance_frameworks = [
    { name = "HTH Orca Hardening", section = "2.1 Configure RBAC", priority = "high" }
  ]
}

2.2 Configure Account Scope

Profile Level: L2 (Walk)

Framework Control
CIS Controls 5.4
NIST 800-53 AC-6

Description

Limit user access to specific cloud accounts.

Rationale

Why This Matters:

  • Restricting users to only the cloud accounts they support contains exposure if their credentials are compromised
  • Separating production visibility prevents non-production staff from viewing sensitive production findings and assets
  • Business-unit boundaries enforce the data segregation many compliance regimes require
  • Scoped access reduces the value of any single Orca account to an attacker who obtains it

Attack Prevented: Cross-tenant data exposure, lateral movement, unauthorized production access

ClickOps Implementation

Step 1: Configure Scoped Access

  1. Limit users to required accounts
  2. Separate production visibility
  3. Apply business unit boundaries

Code Implementation

Code Pack: Terraform
hth-orca-2.02-configure-account-scope.tf View source on GitHub ↗ 
# Business unit for scoped access -- limits visibility to specific cloud accounts
resource "orcasecurity_business_unit" "scoped_environment" {
  count = var.profile_level >= 2 ? 1 : 0

  name          = var.business_unit_name
  global_filter = false

  filter_data = {
    cloud_providers = var.business_unit_cloud_providers
    cloud_tags      = length(var.business_unit_cloud_tags) > 0 ? var.business_unit_cloud_tags : null
  }
}

# Restricted production business unit (L3) -- strictest scoping for regulated environments
resource "orcasecurity_business_unit" "restricted_production" {
  count = var.profile_level >= 3 ? 1 : 0

  name          = var.restricted_business_unit_name
  global_filter = false

  filter_data = {
    cloud_tags = var.restricted_cloud_tags
  }
}

2.3 Limit Admin Access

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.4
NIST 800-53 AC-6(1)

Description

Minimize and protect admin accounts.

Rationale

Why This Matters:

  • Admin accounts can modify integrations, roles, and platform settings, so each one is a high-value target and fewer admins means fewer paths to full control
  • Limiting admins to a small set and requiring MFA shrinks the attack surface for takeover of the security platform itself
  • Monitoring admin activity provides early detection of misuse or a hijacked admin session
  • An attacker controlling an Orca admin could disable monitoring or alter integrations to hide an active cloud compromise

Attack Prevented: Admin-account takeover, privilege escalation, tampering with security monitoring

ClickOps Implementation

Step 1: Inventory Admins

  1. Review admin accounts
  2. Document admin access

Step 2: Apply Restrictions

  1. Limit admins to 2-3 users
  2. Require MFA
  3. Monitor admin activity

Code Implementation

Code Pack: Terraform
hth-orca-2.03-limit-admin-access.tf View source on GitHub ↗ 
# Dedicated admin group -- limit membership to 2-3 trusted users
resource "orcasecurity_group" "platform_admins" {
  name        = var.admin_group_name
  description = "Restricted admin group. Membership should be limited to 2-3 users maximum. All members require MFA via SSO. Per HTH Orca Guide 2.3."
  sso_group   = true
  users       = var.admin_user_ids
}

# Alert when admin count exceeds recommended limit
resource "orcasecurity_custom_sonar_alert" "excessive_admins" {
  name          = "Excessive Admin Accounts Detected"
  description   = "Monitors for an excessive number of admin-level accounts in the Orca platform, which increases attack surface."
  rule          = "User with Role = 'Admin'"
  orca_score    = 7.0
  category      = "Access control"
  context_score = false

  remediation_text = {
    enable = true
    text   = "Reduce admin accounts to 2-3 users maximum. Assign the Security Analyst or Viewer custom role to users who do not require admin privileges. See HTH Orca Guide section 2.3."
  }

  compliance_frameworks = [
    { name = "HTH Orca Hardening", section = "2.3 Limit Admin Access", priority = "high" }
  ]
}

2.4 Restrict Console Access by Network and Automate Access Review

Profile Level: L2 (Walk)

Framework Control
CIS Controls 5.1, 12.5
NIST 800-53 AC-3, AC-17, CA-7

Description

Restrict where the Orca console can be reached from using the platform’s trusted IP range capability, and use the Orca Terraform provider’s RBAC surface to codify and continuously review who holds what access.

Rationale

Why This Matters:

  • Orca holds a complete inventory of your cloud assets, vulnerabilities, and misconfigurations, so limiting console reachability to known corporate egress ranges removes the open-internet login surface entirely
  • Network restriction is a control that survives credential compromise: a valid stolen password or token is useless from an untrusted source address
  • Access reviews performed by hand drift; expressing groups, roles, and per-user access as Terraform makes every grant reviewable in version control and detectable when it changes
  • Reading the platform’s own RBAC state programmatically turns “quarterly access review” from a screenshot exercise into a diffable, repeatable check

Attack Prevented: Console access from attacker-controlled networks, credential replay from outside the corporate perimeter, undetected privilege creep, unreviewed standing access

ClickOps Implementation

Step 1: Enable Trusted IP Range Restriction

  1. In the Orca console settings, locate the trusted IP range configuration
  2. Enable the restriction and register the egress ranges your administrators and analysts use
  3. Verify a login attempt from outside those ranges is rejected before enforcing broadly

Step 2: Review Access

  1. In the Orca console settings, review users, groups, and role assignments
  2. Remove standing access that no longer matches a current job function
  3. Repeat at least quarterly (see 2.1)

Code Implementation

Orca’s Terraform provider is the verified automation path for both halves of this control. The orcasecurity_dynamic_trusted_ip_range resource manages the platform’s trusted IP range enforcement (enabled plus org_id). For access review, the provider exposes the orcasecurity_rbac_roles and orcasecurity_rbac_users data sources for reading current state, and the orcasecurity_group_access, orcasecurity_user_access, orcasecurity_custom_role, and orcasecurity_business_unit resources for declaring it — see the provider documentation. Managing these in Terraform makes every access grant a reviewable, version-controlled change rather than a console action.

3. Cloud Integration Security

3.1 Configure Cloud Account Security

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 3.11
NIST 800-53 SC-12

Description

Secure cloud account integrations.

Rationale

Why This Matters:

  • Orca’s cloud integrations grant it standing access into your cloud accounts, so least-privilege, read-only roles limit what a compromise of that trust relationship could reach
  • Following Orca’s recommended IAM policies avoids over-permissioning that an attacker could abuse for write or delete actions
  • Regular permission reviews catch scope creep and stale grants that widen the integration’s blast radius
  • A misconfigured integration role is a direct pathway from the security platform into the production cloud environment

Attack Prevented: Cloud integration abuse, privilege escalation into cloud accounts, supply-chain pivot

ClickOps Implementation

Step 1: Review Integrations

  1. Navigate to: Settings → Cloud Accounts
  2. Review connected accounts
  3. Verify permissions

Step 2: Apply Least Privilege

  1. Use read-only roles where possible
  2. Follow Orca’s recommended IAM policies
  3. Review cloud permissions regularly

Code Implementation

Code Pack: Terraform
hth-orca-3.01-configure-cloud-account-security.tf View source on GitHub ↗ 
# Register trusted cloud accounts used by Orca integrations
resource "orcasecurity_trusted_cloud_account" "trusted" {
  for_each = { for idx, acct in var.trusted_cloud_accounts : acct.cloud_provider_id => acct }

  account_name      = each.value.account_name
  description       = each.value.description
  cloud_provider    = each.value.cloud_provider
  cloud_provider_id = each.value.cloud_provider_id
}

# Alert for cloud accounts with overly permissive IAM roles
resource "orcasecurity_custom_sonar_alert" "overprivileged_integration" {
  name          = "Cloud Integration with Excessive Permissions"
  description   = "Detects cloud accounts connected to Orca with permissions exceeding read-only access, violating least privilege for security tooling."
  rule          = "CloudAccount with PermissionLevel != 'ReadOnly'"
  orca_score    = 8.0
  category      = "IAM misconfigurations"
  context_score = true

  remediation_text = {
    enable = true
    text   = "Review cloud account IAM roles and reduce to read-only where possible. Follow Orca's recommended IAM policies for each cloud provider. See HTH Orca Guide section 3.1."
  }

  compliance_frameworks = [
    { name = "HTH Orca Hardening", section = "3.1 Cloud Account Security", priority = "high" }
  ]
}

# Discovery view to inventory all connected cloud accounts
resource "orcasecurity_discovery_view" "cloud_accounts_inventory" {
  name               = "HTH - Connected Cloud Accounts Inventory"
  organization_level = true
  view_type          = "discovery"
  extra_params       = {}

  filter_data = {
    query = jsonencode({
      "models" : ["CloudAccount"],
      "type" : "object_set"
    })
  }
}

3.2 Configure API Security

Profile Level: L2 (Walk)

Framework Control
CIS Controls 3.11
NIST 800-53 SC-12

Description

Secure Orca API access.

Rationale

Why This Matters:

  • Orca API keys can read findings and drive automation, so an exposed key gives an attacker programmatic access to your cloud risk data
  • Storing keys in a secrets manager rather than in code or config prevents accidental leaks through repositories and logs
  • Regular rotation limits the useful lifetime of any key that does leak
  • Monitoring key usage surfaces anomalous access that signals a stolen or misused credential

Attack Prevented: API key leakage, unauthorized data access, automation abuse, credential replay

ClickOps Implementation

Step 1: Review API Keys

  1. Navigate to: Settings → API Keys
  2. Review all API keys
  3. Document key purposes

Step 2: Secure Keys

  1. Store keys securely
  2. Rotate regularly
  3. Monitor usage

Code Implementation

Code Pack: Terraform
hth-orca-3.02-configure-api-security.tf View source on GitHub ↗ 
# Custom alert to detect stale or unused API keys in connected cloud accounts
resource "orcasecurity_custom_sonar_alert" "stale_api_keys" {
  count = var.profile_level >= 2 ? 1 : 0

  name          = var.api_alert_name
  description   = "Detects API keys that have not been rotated or used recently, indicating stale credentials that should be revoked."
  rule          = "AccessKey with LastUsedDate before_days 90"
  orca_score    = var.api_alert_score
  category      = "IAM misconfigurations"
  context_score = true

  remediation_text = {
    enable = true
    text   = "Rotate or revoke API keys that have not been used in 90+ days. Store active keys in a secrets manager. Document the purpose of each key. See HTH Orca Guide section 3.2."
  }

  compliance_frameworks = [
    { name = "HTH Orca Hardening", section = "3.2 API Security", priority = "medium" }
  ]
}

# Automation to email security team when stale API keys are found (L2+)
resource "orcasecurity_automation_v2" "api_key_alert" {
  count = var.profile_level >= 2 && var.enable_api_automation && length(var.api_alert_emails) > 0 ? 1 : 0

  name        = "HTH - API Key Security Notifications"
  description = "Sends email notifications when stale or unused API keys are detected. Per HTH Orca Guide section 3.2."
  status      = "enabled"

  # Matches open alerts raised by the stale-API-key sonar alert defined above.
  filter = {
    sonar_query = jsonencode({
      models = ["Alert"]
      type   = "object_set"
      with = {
        type     = "operation"
        operator = "and"
        values = [
          {
            key      = "Status"
            type     = "str"
            operator = "in"
            values   = ["open"]
          },
          {
            key      = "AlertType"
            type     = "str"
            operator = "in"
            values   = [var.api_alert_name]
          },
          {
            key      = "OrcaScore"
            type     = "float"
            operator = "range"
            values   = [var.api_alert_score, 10]
          }
        ]
      }
    })
  }

  email_template = {
    email        = var.api_alert_emails
    multi_alerts = true
  }
}

# Discovery view for API key inventory (L3) -- strict tracking of all API credentials
resource "orcasecurity_discovery_view" "api_key_inventory" {
  count = var.profile_level >= 3 ? 1 : 0

  name               = "HTH - API Key Inventory (All Cloud Accounts)"
  organization_level = true
  view_type          = "discovery"
  extra_params       = {}

  filter_data = {
    query = jsonencode({
      "models" : ["AccessKey"],
      "type" : "object_set"
    })
  }
}

4. Compliance Quick Reference

SOC 2 Trust Services Criteria Mapping

Control ID Orca Control Guide Section
CC6.1 SSO/MFA 1.1
CC6.2 RBAC 2.1
CC6.7 Integration security 3.1

NIST 800-53 Rev 5 Mapping

Control Orca Control Guide Section
IA-2 SSO 1.1
AC-6 RBAC 2.1
SC-12 API security 3.2

Appendix B: References

Official Orca Security Documentation:

Compliance Frameworks:

Security Incidents:

  • No major public incidents identified

Changelog

Date Version Maturity Changes Author
2026-08-08 0.2.0 draft Add 2.4 network restriction and automated access review; annotate the region-gated Knowledge Base link and add the public Terraform provider docs; drop the Trust Center from Official Documentation; fix the Terraform pack provider constraint (~> 0.5 was unsatisfiable — provider ships 0.0.x only) and rewrite the 3.2 automation onto the current orcasecurity_automation_v2 schema Claude Code (Opus 4.8)
2026-06-29 0.1.1 draft Add cheat-sheet Description and Rationale for all controls Claude Code (Opus 4.8)
2025-02-05 0.1.0 draft Initial guide with SSO, RBAC, and integration security Claude Code (Opus 4.5)

Contributing

Found an issue or want to improve this guide?