Guardicore

---
name: guardicore
description: "Expert agent for Akamai Guardicore micro-segmentation (formerly Guardicore Centra). Covers agent and agentless deployment, real-time visibility map, process-level segmentation policies, deception honeypots, east-west traffic analysis, label-based policy, and Guardicore Centra platform. WHEN: \"Guardicore\", \"Akamai Guardicore\", \"Guardicore Centra\", \"Guardicore micro-segmentation\", \"Guardicore deception\", \"process-level segmentation\", \"Guardicore visibility map\", \"Guardicore policy\"."
license: MIT
---

# Akamai Guardicore

This skill covers Akamai Guardicore (formerly Guardicore Centra), the micro-segmentation and network visibility platform acquired by Akamai in 2021. It has deep knowledge of Guardicore's agent and agentless deployment, real-time visibility map, process-level segmentation, deception capabilities, and label-based security policies.

## How to Approach Tasks

When you receive a request:

1. **Classify** the request:
   - **Visibility** -- Centra map, traffic analysis, dependency mapping
   - **Policy** -- Segmentation rules, label strategy, enforcement
   - **Deception** -- Honeypot configuration and alert analysis
   - **Deployment** -- Agent vs. agentless, platform connectivity
   - **Troubleshooting** -- Diagnostic methodology below

2. **Note "Akamai Guardicore"** -- Since the 2021 acquisition, the platform is sold as "Akamai Guardicore Segmentation" but the underlying Centra platform name is often still used.

3. **Gather context** -- Environment mix (Windows/Linux/cloud/containers), existing network topology, compliance requirements, deception interest.

## Core Expertise

### Guardicore vs. Illumio

Key differences to inform platform choice:

| Feature | Guardicore | Illumio |
|---|---|---|
| Agentless support | Yes (network-based visibility) | Limited (primarily agent-based) |
| Process-level visibility | Yes (process name in policy) | No (workload-level only) |
| Deception/honeypots | Built-in Centra Deception | Separate product required |
| Policy model | Flexible label-based | Structured 4D label model |
| Cloud support | Via agent + cloud sensors | Via CloudSecure (cloud-native) |
| Enforcement mechanism | Agent (OS firewall) or network | Agent (iptables/WFP) only |

### Centra Platform Architecture

**Components:**
- **Management Server** -- Centralized policy, visibility, and management plane
- **Aggregator** -- Collects data from agents and network sensors; scales horizontally
- **Agent** -- Installed on workloads for policy enforcement and detailed visibility
- **Network-based sensor** -- Agentless visibility using network traffic mirroring (SPAN/TAP)
- **Deception server** -- Honeypots for trap-based detection

**Communication flow:**
```
[Workload + Agent] --> [Aggregator] --> [Management Server]
[Network TAP/SPAN] --> [Network Sensor] --> [Aggregator] --> [Management Server]
```

### Agent Deployment

The agent provides the richest visibility and enables process-level policy enforcement:

**Supported platforms:**
- Windows Server 2008 R2 through 2022
- Windows 10/11
- RHEL/CentOS 6-9
- Ubuntu 14-22
- SLES, Debian, Amazon Linux
- Containers (via pod annotation or DaemonSet)

**Agent capabilities:**
- Full flow visibility (src/dst IP, port, process name, user)
- OS firewall enforcement (iptables on Linux, WFP on Windows)
- Process-level policy (block specific process from making connections)
- Deception agent (detect port scans and lateral movement attempts)

**Agent installation:**
```bash
# Linux
curl -s https://guardicore.corp.local/install | sudo bash -s -- \
  --management-url https://guardicore.corp.local \
  --token YOUR_INSTALL_TOKEN

# Verify agent
systemctl status guardicore-agent
gc-agent status

# Windows (PowerShell)
Invoke-WebRequest -Uri "https://guardicore.corp.local/windows-agent.msi" -OutFile "gc-agent.msi"
Start-Process msiexec.exe -ArgumentList '/i gc-agent.msi /qn MANAGEMENT_URL="https://guardicore.corp.local" TOKEN="YOUR_TOKEN"' -Wait
```

### Agentless Deployment (Network Sensor)

For environments where agents cannot be installed (legacy systems, OT/SCADA, network appliances):

**Network sensor placement:**
- Deployed as a virtual appliance receiving mirrored traffic
- Connects to SPAN/mirror port on switches or network TAP
- Provides IP-level flow visibility without agents
- Cannot enforce policy (passive observation only)
- Bridges agentless devices into the Centra visibility map

**Agentless limitations:**
- No process-level visibility
- No enforcement capability (observation only)
- No deception capability
- May miss encrypted traffic payload details

**Hybrid approach (recommended):**
- Deploy agents on workloads that support them
- Use network sensor for legacy/IoT/OT devices
- Both appear in the same Centra visibility map
- Policy enforcement applies to agent-based workloads

### Label System and Policy

Guardicore uses labels (key:value pairs) to describe workloads:

**Common label patterns:**
```
App: OrdersApp
Environment: Production
Role: WebTier
Location: AWS-us-east-1
Owner: Platform-Team
Compliance: PCI
```

Labels are flexible -- use as many dimensions as needed. Unlike Illumio's fixed 4D model, Guardicore labels are arbitrary key:value pairs.

**Policy rule structure:**
```
Segmentation Policy Rule:

  Name: Web to App - OrdersApp
  
  Source:
    Label: App=OrdersApp, Role=WebTier
    
  Destination:
    Label: App=OrdersApp, Role=AppTier
    
  Ports/Protocols: TCP/8080
  
  Action: ALLOW
  
  Direction: Both (bidirectional)
```

**Process-level rules (agent-only feature):**
```
Segmentation Policy Rule: Allow only nginx to make outbound 80/443

  Source:
    Label: Role=WebTier
    Process: nginx  (only connections initiated by nginx process)
    
  Destination:
    Label: ANY
    
  Ports: TCP/80, TCP/443
  Action: ALLOW

# Implicit: all other processes on the web tier cannot make outbound HTTP connections
```

**Policy modes:**
- **Monitor** -- Track traffic, do not enforce; alerts generated for policy violations
- **Alert** -- Same as Monitor but with higher-priority alerting
- **Block** -- Enforce; traffic not matching allow rules is dropped

**Rule ordering:**
Guardicore evaluates rules in order. For overlapping rules, more specific rules should be placed before more general rules. The default action (Allow All, Deny All, or custom) applies when no rule matches.

### Real-Time Visibility Map

The Centra Map is a key differentiator -- it shows all workloads and their connections in real time:

**Map features:**
- **Live connections** -- Animated flows showing active traffic
- **Historical playback** -- Replay network activity at any past point in time
- **Label-based grouping** -- Zoom in/out by label dimension
- **Policy overlay** -- Show which connections are covered by policy vs. unmanaged
- **Alert highlighting** -- Flag connections triggering policy violations or deception alerts
- **Process view** -- For agent-based workloads, see which process initiated each connection

**Workflow: Map to Policy**
1. Open Map, filter by application label
2. Identify all connections to/from the application tier
3. Review process names for each connection (verify legitimate processes)
4. Draft policy rules based on observed legitimate traffic
5. Enable policy in Monitor mode
6. Review violations for 1-2 weeks
7. Transition to Block mode

### Deception Capabilities

Guardicore Centra includes built-in deception (honeypot) capabilities:

**Deception server types:**
- **Network decoys** -- Fake hosts with open ports; any connection to decoy = alert
- **Service decoys** -- Fake services (SSH, RDP, SMB, HTTP) that log and analyze attacker interaction
- **Breadcrumbs** -- Fake credentials or tokens planted on workloads to detect theft and use

**How deception catches attackers:**
1. Attacker compromises a workload
2. Attacker scans internal network for lateral movement targets
3. Scan hits a Guardicore decoy (appears as a real server)
4. Deception server logs the connection and generates a high-priority alert
5. Alert includes: compromised workload IP, decoy port targeted, timestamp
6. Security team uses this as pivot point to investigate the compromised workload

**Deception configuration:**
```
Deception Server: Finance-Tier-Decoy

  IP Addresses: [IP addresses that appear as decoys]
  
  Simulated Services:
    SSH (TCP/22): Log auth attempts, capture credentials
    SMB (TCP/445): Log share access attempts
    RDP (TCP/3389): Log connection attempts
    HTTP (TCP/80, 443): Log HTTP requests, headers, payloads
    
  Alert: CRITICAL - Deception Server Contacted
  
  Additional: Breadcrumbs planted on:
    - C:\Users\Administrator\.ssh\known_hosts (fake SSH key)
    - /etc/hosts entry for fake domain (DNS breadcrumb)
```

**Deception placement strategy:**
- Place decoys in every VLAN/subnet
- Decoys should look like real production servers (correct IP range, sensible hostnames)
- Do not advertise decoy IPs in any legitimate DNS (prevents false alerts from monitoring tools)
- High-value segments (finance, HR, PCI) should have multiple decoys
- Refresh decoy configurations regularly to avoid attacker learning

### East-West Traffic Analysis

Guardicore's traffic analysis capabilities for threat hunting:

**Built-in queries:**
```
# Connections from a specific workload
Filter: Source IP = 10.1.2.3
Time range: Last 24 hours
Show: All outbound connections, with process names

# New connections not seen before
Filter: First seen > 24 hours ago
Group by: Destination IP
Sort by: Connection count

# SMB connections (lateral movement indicator)
Filter: Destination port = 445
Exclude: Known file servers
Sort by: Source IP

# Large data transfers (potential exfiltration)
Filter: Bytes transmitted > 100MB
Source: Internal networks
Destination: External IPs
```

### Container and Kubernetes Support

**Kubernetes segmentation:**
- Guardicore DaemonSet deploys agent on each K8s node
- Pod labels automatically mapped to Guardicore labels
- Pod-to-pod flows visible in Centra Map with K8s namespace context
- Policy can target specific K8s workloads by namespace/label

**Container deployment:**
```yaml
# DaemonSet for Guardicore agent on Kubernetes
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: guardicore-agent
  namespace: guardicore
spec:
  selector:
    matchLabels:
      app: guardicore-agent
  template:
    metadata:
      labels:
        app: guardicore-agent
    spec:
      hostNetwork: true
      hostPID: true
      containers:
        - name: guardicore-agent
          image: guardicore/agent:latest
          env:
            - name: GC_MANAGEMENT_URL
              value: "https://guardicore.corp.local"
            - name: GC_INSTALL_TOKEN
              valueFrom:
                secretKeyRef:
                  name: guardicore-token
                  key: token
          securityContext:
            privileged: true
```

## Troubleshooting

### Agent Connectivity Issues

```bash
# Check agent status
gc-agent status

# Verify connectivity to management server
gc-agent connectivity-test

# Agent logs
journalctl -u guardicore-agent -n 100
tail -f /var/log/guardicore/agent.log
```

### Policy Not Enforcing

1. Check agent is in Enforcement mode (not Monitor/Alert only)
2. Verify workload labels match policy rule labels exactly (case-sensitive)
3. Review policy rule ordering -- earlier rules take precedence
4. Check for conflicting rules -- a more general ALLOW rule before a specific DENY
5. Use Map to click on specific flow and see which policy rule matched (or didn't)

### False Positive Deception Alerts

- Review the process that connected to the decoy -- monitoring tools (network scanners, SIEM agents) may legitimately reach decoy IPs
- Add known-good scanners (Nessus, Qualys) to a Deception Exclusion list
- Adjust decoy IP range to avoid conflicts with monitoring tool scan targets

## Common Pitfalls

1. **Deploying deception without excluding monitoring tools** -- Network scanners hitting decoys generates false alerts. Create exclusion rules for known scanner IPs/tools before enabling deception.

2. **Using Monitor mode indefinitely** -- Monitor mode generates no enforcement. Teams often stay in Monitor mode too long. Set a timeline for transitioning to Block mode after dependency mapping is complete.

3. **Over-relying on agentless for enforcement** -- Network sensors provide visibility but cannot block traffic. For enforcement, agents are required. Agentless-only deployments are visibility, not segmentation.

4. **Not reviewing process-level data** -- One of Guardicore's key advantages over other tools is process-level visibility. Review which processes are making connections to validate that observed traffic is from legitimate processes, not malware.

5. **Label sprawl** -- Guardicore's flexible label system can lead to too many label keys or inconsistent naming. Establish a labeling taxonomy (maximum 5-8 label keys) before deployment.