Skip to main content
Security Policies extend the Myrmex RBAC system 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:

Effect

Deny or Allow. Determines what happens when conditions are (or aren’t) met.

Conditions

Environmental attributes to evaluate: source IP, time, day of week, MFA status, device type, or user agent.

Targeting

Which permissions, roles, devices, or integrations this policy applies to. Empty targeting means “applies to all.”

Priority

Numeric value that determines evaluation order. Higher priority policies are evaluated first.

​
Deny vs. Allow Policies

Understanding the two policy effects is critical:
“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
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.

​
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.

​
Targeting Fields

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.

​
Evaluation Flow

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

RBAC Check

The system first verifies the user has the required permission through their assigned roles. If not, access is denied immediately — no policies are evaluated.
2

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).
3

Condition Evaluation

For each matching policy, the system evaluates all conditions. All conditions within a policy must pass (AND logic).
4

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.

​
Real-World Examples

Goal: Restrict SOC Analyst access to business hours only.Result: Analysts can only access the platform Monday–Friday, 8 AM to 6 PM. Outside these times, all their requests return 403.
Goal: Require MFA for any action on production devices.Result: Any device whose name matches .*prod.* requires the user to have an active MFA session. Users without MFA are blocked.
Goal: Allow firewall integration management only from the corporate VPN.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.
Goal: External auditors (Viewer role) can only access the platform on weekdays.Result: Users with the Viewer role are blocked on weekends. Other roles (Admin, Analyst) are unaffected.

​
Next Steps

Available Conditions

Explore all six condition types with syntax, operators, and examples.

Managing Policies

Step-by-step guide to creating, editing, and organizing policies in the interface.