> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myrmex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Policies Overview

> Understand how ABAC security policies add contextual conditions on top of RBAC to enforce time-based, network-based, and device-based access restrictions.

import {
  CardGroup,
  Card,
  Steps,
  Step,
  Note,
  Warning,
  Accordion,
  AccordionGroup,
  Tabs,
  Tab,
} from "@mintlify/components";

Security Policies extend the Myrmex [RBAC system](/pt/documentation/management/access-control) with **Attribute-Based Access Control (ABAC)**, allowing you to enforce environmental conditions on user access. While RBAC controls *who* can do *what*, security policies add *when*, *where*, and *how*.

***

## How Security Policies Work

Every policy has four key elements:

<CardGroup cols={2}>
  <Card title="Effect" icon="circle-check" color="#10b981">
    **Deny** or **Allow**. Determines what happens when conditions are (or aren't) met.
  </Card>

  <Card title="Conditions" icon="sliders" color="#f59e0b">
    Environmental attributes to evaluate: source IP, time, day of week, MFA status, device type, or user agent.
  </Card>

  <Card title="Targeting" icon="crosshairs" color="#3b82f6">
    Which permissions, roles, devices, or integrations this policy applies to. Empty targeting means "applies to all."
  </Card>

  <Card title="Priority" icon="arrow-up-1-9" color="#8b5cf6">
    Numeric value that determines evaluation order. Higher priority policies are evaluated first.
  </Card>
</CardGroup>

***

## Deny vs. Allow Policies

Understanding the two policy effects is critical:

<Tabs>
  <Tab title="Deny Policies">
    **"Block access if conditions are NOT met."**

    The most common type. A Deny policy defines requirements that must be satisfied — if the user's request does *not* meet the conditions, access is blocked.

    **Example: Business Hours Only**

    * Effect: `deny`
    * Condition: `time_of_day` between `08:00` and `18:00`
    * Meaning: *"Deny access if the request is NOT between 08:00–18:00"*
    * Result: Access outside business hours is blocked

    **Example: Corporate VPN Required**

    * Effect: `deny`
    * Condition: `source_ip` in `203.0.113.0/24`
    * Meaning: *"Deny access if the request is NOT from the corporate VPN public IP range"*
    * Result: Access from outside the corporate VPN is blocked
  </Tab>

  <Tab title="Allow Policies">
    **"Grant access ONLY if conditions ARE met."**

    Allow policies are more restrictive — they define the only acceptable conditions. If the conditions are *not* met, the permission is not granted, even if the user has the RBAC role.

    **Example: Emergency Override**

    * Effect: `allow`
    * Condition: `mfa_status` equals `true`
    * Target Permissions: `devices.execute`
    * Meaning: *"Allow device execution only when MFA is verified"*
    * Result: Even Super Admins must have MFA active to execute commands
  </Tab>
</Tabs>

<Warning>
  **Deny policies are evaluated before Allow policies** (when they have the same priority). Always test policies in a non-production context before applying to critical roles.
</Warning>

***

## Targeting: Controlling Policy Scope

Policies can target specific permissions, roles, devices, or integrations. When a targeting field is left empty, the policy applies to **all** items in that category.

```mermaid theme={null}
graph TD
    P[Security Policy] --> TP[Target Permissions]
    P --> TR[Target Roles]
    P --> TD[Target Devices]
    P --> TI[Target Integrations]

    TP -->|Empty| TP_ALL[All Permissions]
    TP -->|Specific| TP_SPEC["devices.read, integrations.execute"]

    TR -->|Empty| TR_ALL[All Roles]
    TR -->|Specific| TR_SPEC["Viewer, Analyst"]

    TD -->|Empty| TD_ALL[All Devices]
    TD -->|Name Regex| TD_NAME[".*prod.*"]
    TD -->|OS Filter| TD_OS["Windows, Ubuntu"]

    TI -->|Empty| TI_ALL[All Integrations]
    TI -->|Name Regex| TI_NAME[".*firewall.*"]
    TI -->|Base Type| TI_BASE["Fortigate, AWS"]
```

### Targeting Fields

| Field                        | Description                                                                                         | Example                                |
| ---------------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------- |
| **Target Permissions**       | Which [permissions](/pt/documentation/management/rbac/permissions-reference) this policy applies to | `devices.read`, `integrations.execute` |
| **Target Roles**             | Which [roles](/pt/documentation/management/rbac/native-roles) this policy applies to                | Viewer, Analyst                        |
| **Target Device Names**      | Regex patterns for device names                                                                     | `.*prod.*`, `srv-db-.*`                |
| **Target Device OS**         | Operating system filter (case-insensitive)                                                          | Windows, Ubuntu, Darwin, Amazon Linux  |
| **Target Integration Names** | Regex patterns for integration names                                                                | `.*firewall.*`, `aws-.*`               |
| **Target Integration Bases** | Integration type/vendor                                                                             | Fortigate, AWS, Palo Alto              |

<Note>
  **Smart Visibility:** In the policy form, device targeting fields only appear when device-related permissions are selected. Integration fields only appear when integration permissions are selected. This keeps the form clean and focused.
</Note>

***

## Evaluation Flow

When a user makes a request, the system evaluates policies in this order:

<Steps>
  <Step title="RBAC Check">
    The system first verifies the user has the required [permission](/pt/documentation/management/rbac/permissions-reference) through their assigned [roles](/pt/documentation/management/rbac/native-roles). If not, access is denied immediately — no policies are evaluated.
  </Step>

  <Step title="Policy Matching">
    The system finds all **active** security policies that match the request based on targeting (permissions, roles, device, integration). Policies are ordered by **priority** (highest first).
  </Step>

  <Step title="Condition Evaluation">
    For each matching policy, the system evaluates all [conditions](/pt/documentation/management/security-policies/conditions). All conditions within a policy must pass (AND logic).
  </Step>

  <Step title="Effect Application">
    * **Deny policy:** If conditions are NOT met → access is **blocked** (HTTP 403).
    * **Allow policy:** If conditions ARE met → access is **granted**.
    * If no policies match or all pass → access follows the RBAC result.
  </Step>
</Steps>

***

## Real-World Examples

<AccordionGroup>
  <Accordion title="SOC Business Hours Policy" icon="clock">
    **Goal:** Restrict SOC Analyst access to business hours only.

    | Setting      | Value                                                           |
    | ------------ | --------------------------------------------------------------- |
    | Name         | SOC Business Hours                                              |
    | Effect       | Deny                                                            |
    | Priority     | 10                                                              |
    | Target Roles | Analyst                                                         |
    | Condition 1  | `time_of_day` between `08:00` and `18:00`                       |
    | Condition 2  | `day_of_week` in `monday, tuesday, wednesday, thursday, friday` |

    **Result:** Analysts can only access the platform Monday–Friday, 8 AM to 6 PM. Outside these times, all their requests return 403.
  </Accordion>

  <Accordion title="Production Device MFA Requirement" icon="lock">
    **Goal:** Require MFA for any action on production devices.

    | Setting             | Value                      |
    | ------------------- | -------------------------- |
    | Name                | Production MFA Required    |
    | Effect              | Deny                       |
    | Priority            | 20                         |
    | Target Device Names | `.*prod.*`                 |
    | Condition           | `mfa_status` equals `true` |

    **Result:** Any device whose name matches `.*prod.*` requires the user to have an active MFA session. Users without MFA are blocked.
  </Accordion>

  <Accordion title="VPN-Only Firewall Management" icon="shield-halved">
    **Goal:** Allow firewall integration management only from the corporate VPN.

    | Setting                  | Value                                         |
    | ------------------------ | --------------------------------------------- |
    | Name                     | VPN-Only Firewall Access                      |
    | Effect                   | Deny                                          |
    | Priority                 | 15                                            |
    | Target Permissions       | `integrations.update`, `integrations.execute` |
    | Target Integration Bases | Fortigate, Palo Alto                          |
    | Condition                | `source_ip` in `198.51.100.0/24`              |

    **Result:** Editing or executing commands on Fortigate and Palo Alto integrations is only allowed from the corporate VPN IP range (`198.51.100.0/24`). Access from other IPs is blocked.
  </Accordion>

  <Accordion title="Viewer Weekday Restriction" icon="calendar">
    **Goal:** External auditors (Viewer role) can only access the platform on weekdays.

    | Setting      | Value                                                           |
    | ------------ | --------------------------------------------------------------- |
    | Name         | Viewer Weekdays Only                                            |
    | Effect       | Deny                                                            |
    | Priority     | 5                                                               |
    | Target Roles | Viewer                                                          |
    | Condition    | `day_of_week` in `monday, tuesday, wednesday, thursday, friday` |

    **Result:** Users with the Viewer role are blocked on weekends. Other roles (Admin, Analyst) are unaffected.
  </Accordion>
</AccordionGroup>

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Available Conditions" icon="sliders" href="/pt/documentation/management/security-policies/conditions">
    Explore all six condition types with syntax, operators, and examples.
  </Card>

  <Card title="Managing Policies" icon="list-check" href="/pt/documentation/management/security-policies/managing-policies">
    Step-by-step guide to creating, editing, and organizing policies in the interface.
  </Card>
</CardGroup>