Security Score
—
Live posture index
Active Bans
—
Fail2ban across all servers
Failed SSH / 24h
—
Brute force attempts
AIDE Alerts
—
File integrity changes
SELinux
—
Enforcing on all servers
Auditd
—
Immutable on all servers
Security posture — server summary
Loading live data...
Compliance snapshot
| Framework | Coverage | Score | Key Controls | Status |
|---|---|---|---|---|
| CIS Controls v8 | Implementation Group 2 | 100% | IG1 + IG2 fully implemented | Compliant |
| PCI-DSS v4.0 | SAQ A-EP scope | 94% | 47/50 requirements | In progress |
| NIST CSF 2.0 | Identify / Protect / Detect | 78% | Respond / Recover maturing | Partial |
| MITRE ATT&CK | Enterprise v14 | 62% | 19/31 tactics covered | In progress |
| NIST SP 800-53 | Moderate baseline | 71% | AC, AU, CM, IA, SC controls | Partial |
Open risk items
| # | Risk | Severity | Owner | Target | Status |
|---|---|---|---|---|---|
| RSK-001 | No MFA on server SSH access | High | IT Admin | Q2 2026 | Open |
| RSK-002 | PCI 12.1.1 — formal policy sign-off pending | Medium | Director of Cyber Security | Q2 2026 | Open |
| RSK-003 | No network segmentation between server VLANs | High | IT Admin | Q3 2026 | Open |
| RSK-004 | SSO / Okta not yet implemented | Medium | IT Admin | Q3 2026 | Open |
| RSK-005 | No formal vulnerability scanning schedule | Medium | IT Admin | Q2 2026 | In progress |
Greenpeace USA — Threat landscape
Greenpeace USA operates as a high-profile environmental advocacy organization, making it a target for a distinctive range of threat actors motivated by ideology, politics, and data exfiltration. The threat landscape is shaped by our public campaigns, donor data, and relationships with government and corporate targets of our advocacy work.
🌐
Nation-State Actors
APT28 · APT29 · Lazarus · UNC2452
Critical
State-sponsored groups targeting NGOs engaged in political advocacy, particularly those opposing fossil fuel interests aligned with state economies. Primary objectives: intelligence gathering, campaign disruption, donor/contact exfiltration.
Known TTPs: Spearphishing staff, watering hole attacks on activist sites, supply chain compromise of shared NGO tools, persistent backdoors via IT vendor access.
T1566 PhishingT1195 Supply ChainT1078 Valid AccountsCIS 9.1CIS 14.1
🎯
Corporate-Aligned APTs
Fossil fuel · Agribusiness · Logging
Critical
Private intelligence firms and APT groups hired by industries targeted by Greenpeace campaigns. Objective: obtain advance knowledge of campaigns, identify confidential sources, map internal communications and donor relationships.
Known TTPs: Social engineering of staff and contractors, OSINT aggregation, email compromise, physical infiltration attempts at events.
T1591 Gather Org InfoT1598 Spearphish for InfoCIS 6.2CIS 16.1
⚡
Hacktivists
Counter-activist groups · Anti-environmentalist
High
Ideologically-motivated groups opposing environmental advocacy. Attacks spike during high-visibility campaigns. Primary goals: defacement, DDoS, credential leaks, doxing of staff and activists.
Known TTPs: DDoS against web properties, credential stuffing, public data dumps, social media account hijacking.
T1498 DDoST1110 Brute ForceCIS 4.1CIS 12.1
👤
Insider Threat
Malicious · Negligent · Compromised
High
Staff, contractors, or volunteers with legitimate access. Greenpeace's open collaborative culture and frequent use of volunteers creates elevated insider risk. Three vectors: malicious insiders, negligent data handling, and unknowingly compromised credentials.
Key controls: Principle of least privilege, AIDE file integrity monitoring, auditd immutable logging, access reviews, separation of duties.
T1078 Valid AccountsT1552 CredentialsCIS 6.1CIS 18.1
🔗
Supply Chain
SaaS vendors · Open source · IT contractors
High
Compromise via trusted third-party software, vendor access, or shared NGO tooling. Greenpeace relies on numerous SaaS platforms and shared tech infrastructure with other NGOs, increasing supply chain exposure. SolarWinds-style attacks are a credible threat.
Key controls: Vendor access reviews, container image signing, GCS lifecycle controls, Artifact Registry scanning.
T1195 Supply ChainT1199 Trusted RelationshipCIS 2.1CIS 15.1
Attack surface — WDC infrastructure
| Surface | Exposure | Threat Actors | Primary Control | Risk |
|---|---|---|---|---|
| SSH (port 22) | Internal only (VPN) | Insider, nation-state | Fail2ban, key-only auth, auditd | Low |
| DNS (UDP/TCP 53) | Internal + recursive | Hacktivist, APT | DNSSEC, ACLs, rate limiting | Medium |
| DHCP (UDP 67/68) | Internal LAN only | Insider, rogue device | DHCP snooping, failover | Low |
| Prometheus (9090) | VPN only (10.8.0.0/28) | Insider, APT | Firewall ACL, VPN | Low |
| Elasticsearch (9200) | VPN only (10.8.0.0/28) | Insider, APT | Firewall ACL, VPN | Low |
| Cloud Run (HTTPS) | Public internet | All actors | Google WAF, no auth bypass | Medium |
| Cloud VPN | GCP ↔ WDC only | Nation-state, APT | IKEv2, AES-256, PSK rotation | Medium |
| Staff laptops | Internet + VPN | All actors | MDM (pending), full-disk encrypt | High |
Defense layers
1
Perimeter — Firewall & VPN
Cisco Meraki MX100 at WDC boundary. Default-deny egress policy. Cloud VPN IKEv2/AES-256 to GCP. All inter-site traffic encrypted. No direct internet exposure to on-prem services.
2
Host — SELinux + firewalld
SELinux enforcing on all 4 servers. firewalld active with zone-based policy. Only necessary ports open per server role. SSH restricted to key-based authentication only.
3
Identity — Least Privilege + SSH Keys
Dedicated service accounts per role: dnsadmin (SKY/RAIN), monitadmin (SUN/WIND). No shared root passwords. SSH key-only authentication, root login disabled. Sudo rules scoped to minimum required commands per account.
4
Detection — auditd + Fail2ban + AIDE
auditd running in immutable mode (--e 2) on all servers — rules cannot be modified at runtime. Fail2ban blocking brute-force SSH. AIDE file integrity baseline updated after every configuration change.
5
Monitoring — Prometheus + ELK
Prometheus scraping all 4 servers via node_exporter. Grafana dashboards for anomaly detection. ELK stack on WIND ingesting syslogs from all servers. SKY/RAIN queue logs locally if WIND is down.
6
Data Protection — Encryption + Backup
GCS backup pipeline active: NAS (30d) + GCS (90d) for all 4 servers. VPN AES-256 for in-transit. GCS server-side encryption at rest. Terraform state versioned. MkDocs portal source backed up daily.
7
Response — IRP + DRP + Runbooks
Incident Response Plan (IRP v1.0) and Disaster Recovery Plan (DRP v1.1) documented and published on infra.greenpeace.us. Backup & Restore runbook covers all 4 servers with GCS and NAS restore paths.
MITRE ATT&CK coverage — Enterprise v14 (key tactics)
TA0001
Initial Access
✓ Covered
TA0002
Execution
✓ Covered
TA0003
Persistence
✓ Covered
TA0004
Privilege Escalation
◐ Partial
TA0005
Defense Evasion
✓ Covered
TA0006
Credential Access
◐ Partial
TA0007
Discovery
✓ Covered
TA0008
Lateral Movement
◐ Partial
TA0009
Collection
✓ Covered
TA0010
Exfiltration
✗ Gap
TA0011
Command & Control
✓ Covered
TA0040
Impact
✗ Gap
■ Covered — active controls + monitoring
■ Partial — controls present, gaps remain
■ Gap — limited or no coverage
Critical
0
CVSS ≥ 9.0
High
2
CVSS 7.0–8.9
Medium
4
CVSS 4.0–6.9
Low
3
CVSS < 4.0
Remediated
11
Closed findings
Last Scan
2026-03-10
Manual review
Live scan results — Lynis (daily) & OpenVAS (weekly)
Loading scan data...
Vulnerability tracker
| ID | Component | Description | CVSS | Severity | Server | Status | Target |
|---|---|---|---|---|---|---|---|
| VLN-001 | SSH Config | No MFA — password auth disabled but no TOTP/U2F | 7.5 | High | ALL | Open | Q2 2026 |
| VLN-002 | Network | No VLAN segmentation between server roles | 7.2 | High | ALL | Open | Q3 2026 |
| VLN-003 | GCP IAM | Service account key on-disk — no Workload Identity | 6.5 | Medium | GCP | In progress | Q2 2026 |
| VLN-004 | ESXi 6.7 | EOL hypervisor — no vendor security patches since 2023 | 6.3 | Medium | WATER | Open | Q4 2026 |
| VLN-005 | Identity | No SSO — separate credentials per service | 5.4 | Medium | ALL | Open | Q3 2026 |
| VLN-006 | DNS | Recursive resolver accepts queries from all internal hosts | 4.9 | Medium | SKY/RAIN | In progress | Q2 2026 |
| VLN-007 | Logging | No centralized SIEM alerting — manual log review only | 3.8 | Low | WIND | Open | Q3 2026 |
| VLN-008 | Backup | No backup integrity verification — no restore testing schedule | 3.1 | Low | ALL | Open | Q2 2026 |
| VLN-009 | NTP | chronyd not verified — potential for log timestamp skew | 2.6 | Low | ALL | Remediated | 2026-03-10 |
Pentest & assessment history
| Date | Type | Scope | Findings | Conducted by | Status |
|---|---|---|---|---|---|
| 2026-03-10 | Internal review | All 4 servers — CIS hardening verification | 0 critical, 0 high | IT Admin (self) | Complete |
| Q2 2026 | Vulnerability scan | WDC network — Nessus or OpenVAS | — | TBD | Planned |
| Q3 2026 | External pentest | Cloud Run services + VPN perimeter | — | External firm | Planned |
| Q4 2026 | Red team exercise | Full WDC + GCP environment | — | External firm | Planned |
Red Team Exercises
0
Completed to date
Blue Team Drills
0
Completed to date
Tabletops
0
Completed to date
Next Exercise
Q2 2026
Tabletop — ransomware
2026 Exercise calendar
| Quarter | Exercise | Type | Scope | Owner | Status |
|---|---|---|---|---|---|
| Q2 2026 | Ransomware tabletop | Tabletop | All IT + management | Director of Cyber Security | Planned |
| Q2 2026 | DNS failover drill | Blue team | SKY/RAIN + network team | DNS Admin | Planned |
| Q3 2026 | Phishing simulation | Red team | All staff | IT Admin + external | Planned |
| Q3 2026 | Insider threat tabletop | Tabletop | IT + HR + Legal | Director of Cyber Security | Planned |
| Q4 2026 | Full DR drill | Blue team | All 4 servers + GCP | Director of Cyber Security + Full team | Planned |
| Q4 2026 | External red team | Red team | WDC perimeter + Cloud Run | External firm | Planned |
Tabletop playbooks
Tabletop
Scenario 1 — Ransomware attack on WDC infrastructure
Planned: Q2 2026 · Duration: 3 hrs
Scenario: A staff member opens a malicious email attachment. Ransomware executes on their workstation, laterally moves to the WDC network, and begins encrypting file shares on vmstorage. SKY and RAIN continue operating but NAS backups are inaccessible.
- Detection: How is the attack first noticed? (Prometheus alert? Fail2ban? Staff report?)
- Containment: Who authorizes network isolation? Which systems get quarantined first?
- Communication: Internal escalation path. External notification obligations?
- Recovery: Restore from GCS backups. Rebuild order: SKY → RAIN → SUN → WIND.
- Lessons learned: Gap analysis, control improvements, documentation updates.
Key questions: Do we have offline backups? Can we restore within RTO? Who has authority to shut down the VPN tunnel?
Tabletop
Scenario 2 — Insider data exfiltration
Planned: Q3 2026 · Duration: 2 hrs
Scenario: A departing contractor with dnsadmin access on SKY/RAIN copies zone files and DHCP leases to an external USB drive. The action is detected by auditd 48 hours later during log review.
- Detection: auditd log review identifies suspicious cp/scp commands. Timeline reconstruction.
- Scope: What data was accessed? Were credentials also compromised?
- Response: Immediate revocation of SSH keys. Password rotation for service accounts.
- Legal: HR + Legal involvement. Notification to affected parties if PII involved.
- Control gaps: Was offboarding procedure followed? Was access revoked at separation?
Red team
Scenario 3 — Phishing simulation
Planned: Q3 2026 · Duration: 2 weeks
Scenario: External firm sends targeted phishing emails to all GPUS-WDC staff impersonating IT support requesting VPN credential verification. Campaign runs for 2 weeks. Results used to identify training gaps.
- Phase 1: IT Admin coordinates with external firm. Staff not notified in advance.
- Phase 2: Phishing emails sent in batches over 2 weeks. Click rates tracked.
- Phase 3: Results briefing to Director of Cyber Security and HR. Top-click departments identified.
- Phase 4: Mandatory security awareness training for staff who clicked.
- Phase 5: Repeat simulation 90 days later to measure improvement.
Blue team — detection playbooks
Blue team
Detection drill — Brute force SSH
Verify Fail2ban is catching and banning IPs within the configured threshold (5 failures / 10 min).
# Check active bans
sudo fail2ban-client status sshd
# Review ban log
sudo grep "Ban " /var/log/fail2ban.log | tail -20
# Check failed auth attempts
sudo grep "Failed password" /var/log/secure | tail -20
# Verify ban is applied in firewall
sudo firewall-cmd --list-rich-rules | grep -i reject
Pass criteria: IP banned within 60 seconds of 5th failed attempt. Ban persists for configured duration. Alert visible in ELK.
Blue team
Detection drill — Unauthorized file modification
Verify AIDE detects and logs unauthorized changes to monitored files within 24 hours.
# Run AIDE check manually
sudo aide --check
# Review AIDE report for changes
sudo cat /var/log/aide/aide.log | grep -E "changed|added|removed"
# Check auditd captured the write
sudo ausearch -f /etc/named.conf -ts today
# Verify asset log entry was made
tail -10 /var/log/asset-inventory.log
Pass criteria: AIDE detects change within 24h cron cycle. auditd records syscall. No unauthorized changes present in baseline.
Incident response runbooks — click to expand
All runbooks follow P1/P2/P3 severity classification. P1 = immediate response, P2 = same-day, P3 = next business day. Always log to /var/log/asset-inventory.log and notify Director of Cyber Security for P1/P2.
P1
RB-001 — Ransomware / Mass encryption event
▼
1
Isolate immediately
Disconnect affected hosts from network. Do NOT shut down — preserve memory forensics.
sudo firewall-cmd --panic-on # isolate at firewall level
2
Notify Director of Cyber Security
Escalate immediately. Activate IRP. Open incident ticket. Preserve all evidence.
3
Assess scope
Identify affected systems. Check NAS for encryption indicators. Verify GCS backups are intact.
gcloud storage ls gs://gpus-infra-backups-wdc/sky/$(date +%Y-%m-%d)/
4
Restore from GCS
Follow backup-restore runbook. Restore order: SKY → RAIN → SUN → WIND. Verify DNSSEC after SKY restore.
5
Post-incident
AIDE baseline update on all restored servers. Full audit log review. Root cause analysis within 5 business days.
sudo aide --update && sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
echo "$(date) [IR] RB-001 resolved" >> /var/log/asset-inventory.log
P1
RB-002 — Unauthorized access / Active intrusion
▼
1
Identify active session
Check who is logged in. Identify suspicious processes.
who; w; last | head -20
sudo ss -tlnp
sudo ps auxf | grep -v '\[' | sort -k3 -rn | head -20
2
Kill active session and revoke access
Terminate intruder session. Immediately revoke SSH keys.
sudo pkill -KILL -u <username>
# Remove from authorized_keys on ALL servers
sudo sed -i '/suspicious-key-fingerprint/d' /home/*/.ssh/authorized_keys
3
Preserve evidence
Copy logs before any remediation. Ship to secure storage.
sudo cp /var/log/secure /tmp/ir-evidence-$(date +%Y%m%d)/
sudo ausearch -ts today > /tmp/ir-evidence-$(date +%Y%m%d)/auditd.txt
sudo cp /var/log/fail2ban.log /tmp/ir-evidence-$(date +%Y%m%d)/
4
AIDE integrity check
Run AIDE check to identify any files modified during intrusion.
sudo aide --check 2>&1 | tee /tmp/ir-evidence-$(date +%Y%m%d)/aide-check.txt
5
Restore if needed + notify
If files modified, restore from last known-good GCS backup. Notify Director of Cyber Security + Legal if data accessed.
P2
RB-003 — Brute force / Credential attack
▼
1
Verify Fail2ban is active
sudo fail2ban-client status sshd
sudo grep "Ban " /var/log/fail2ban.log | tail -20
2
Identify source IPs and block at firewall
sudo grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -rn | head -10
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<IP>" reject'
sudo firewall-cmd --reload
3
Verify no successful logins from attacker IP
sudo grep "<IP>" /var/log/secure | grep "Accepted"
4
Log and monitor
echo "$(date) [IR] RB-003: Brute force from <IP> — blocked" >> /var/log/asset-inventory.log
P2
RB-004 — AIDE integrity alert
▼
1
Review the AIDE report
sudo cat /var/log/aide/aide.log
sudo aide --check 2>&1 | grep -E "changed|added|removed"
2
Correlate with auditd
Was the change authorized? Check asset-inventory.log for a matching change record.
sudo ausearch -f <changed-file> -ts today
grep "$(date +%Y-%m-%d)" /var/log/asset-inventory.log
3
If unauthorized — restore file from backup
tar -xzf /mnt/nas-backup/<server>/$(ls /mnt/nas-backup/<server>/ | sort | tail -1)/etc-*.tar.gz \
-C /tmp/restore/ <path-to-file>
4
Update AIDE baseline if change was authorized
sudo aide --update && sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
echo "$(date) [AIDE] Baseline updated after authorized change" >> /var/log/asset-inventory.log
P3
RB-005 — Suspicious DNS activity
▼
1
Check BIND query logs
sudo journalctl -u named --since "1 hour ago" | grep -E "query|refused|SERVFAIL"
sudo rndc stats && cat /var/named/data/named_stats.txt | grep -A5 "Incoming Requests"
2
Check for DNS amplification or tunneling
# High query rate from single source
sudo journalctl -u named | awk '{print $9}' | sort | uniq -c | sort -rn | head -10
# Large TXT responses (tunneling indicator)
sudo journalctl -u named | grep "TXT"
3
Apply rate limiting if needed
# Add rate-limit block to named.conf options
# rate-limit { responses-per-second 10; };
sudo rndc reload
4
Verify DNSSEC signatures intact
sudo rndc sign wdc.us.gl3
dig +dnssec sky.wdc.us.gl3 A @192.168.120.1
Live security metrics — refreshes every 60 seconds
Loading live data from all servers...