Redpen

Marker-based detection validation for modern security teams

Redpen is a modular security validation framework for validating how detection systems respond to controlled, marker-based test traffic across HTTP, GraphQL, WebSocket, and gRPC endpoints.

What Is This

Redpen is designed for defensive validation, not exploitation.

It helps security teams verify that WAFs, SIEM pipelines, runtime monitoring, and incident response workflows correctly detect, correlate, and report benign test events in realistic environments. The framework uses marker-based probes and environment-aware execution to validate coverage without sending harmful or real-world exploit payloads.

Redpen does not test exploitation paths. It tests detection coverage, response quality, and operational readiness in a safe, controlled manner.

Features

• Multi-protocol validation across HTTP, GraphQL, WebSocket, and gRPC
• Environment-aware behavior for staging, production-safe, and gated testing workflows
• CI/CD friendly execution for pull requests, scheduled checks, and pipeline gates
• Structured reporting in CSV, JSONL, HTML, and summary formats
• MITRE ATT&CK-aligned telemetry tagging and detection validation
• Grafana and SIEM annotation support for operational visibility
• Vault-backed secret handling for restricted live test scenarios
• Kubernetes-ready deployment manifests and monitoring integrations

Quick Start

Clone and install

git clone https://github.com/your-org/redpen.git
cd redpen
npm install

Run a safe validation pass

node detection_harness/send_probes.js --mode=safe --delay 1000

Generate a report

node detection_harness/reporting.js --results detection_harness/reports/staging/results.jsonl

Optional smoke check

npm run smoke

Test Modes

Redpen supports a small set of explicitly scoped validation modes:

• Safe mode

  • Sends benign marker traffic only
  • Intended for normal CI and pre-deployment validation
  • Best default for most teams

• Blocking mode

  • Exercises prevention and blocking policies against configured guardrails
  • Validates whether WAF or edge controls reject suspicious traffic as expected

• Ratelimit mode

  • Produces bursts of low-risk probe traffic to validate rate limiting and alerting logic
  • Useful for surge detection and anti-abuse controls

• Bypass mode

  • Validates detection coverage against common evasion-like transformations while still using safe markers
  • Focused on defensive detection fidelity rather than bypass techniques themselves

• Live mode

  • Restricted to explicitly authorized environments and requires ENABLE_LIVE_TESTS=1
  • Requires a controlled payload source and policy approval
  • Disabled by default for safety

Architecture

flowchart LR
    A[Config / Environments] --> B[Redpen Runner]
    B --> C[HTTP / GraphQL / WS / gRPC Adapters]
    C --> D[Target Systems]
    D --> E[WAF / Edge / App]
    D --> F[SIEM / Log Pipeline]
    D --> G[Runtime / Metrics / Alerts]
    B --> H[Reports]
    F --> I[Grafana / Slack / GitHub Actions]
    H --> J[Compliance + Summary + Artifact Upload]

Loading

Safety Model

Safety is a core design principle in Redpen.

• Marker-only traffic: all probes are benign and intentionally synthetic
• No exploit payloads or real-world malicious content are stored in the repository
• Live mode is gated behind ENABLE_LIVE_TESTS=1 and environment policy checks
• Payloads for gated workflows should live in secure secret stores such as Vault, not in source control
• The harness supports explicit exercise markers such as X-Exercise: true to distinguish testing traffic from live traffic
• Safe mode is the default mode for CI and routine validation

Reports and Outputs

Redpen produces structured evidence suitable for CI and review workflows.

Typical outputs include:

• detection_harness/reports/<env>/results.csv — tabular probe results
• detection_harness/reports/<env>/results.jsonl — machine-readable event stream
• detection_harness/reports/<env>/summary.json — pass/fail totals and pass-rate summary
• detection_harness/reports/<env>/summary.html — human-readable summary page
• detection_harness/reports/<env>/verify_report.json — SIEM validation evidence
• detection_harness/reports/<env>/debug.log — request and response diagnostics

These artifacts help teams evaluate whether detections, alerts, and prevention policies are firing as expected across different environments.

Integrations

Redpen is built to integrate with common operational stacks:

• SIEM: correlation checks and event validation for detections
• Grafana: dashboard annotations and operational visibility
• GitHub Actions: automated safe validation on pull requests and scheduled checks
• Slack: result notifications and alerts for response teams
• Vault: secure retrieval of gated live-test configuration and payload references
• Kubernetes: manifests and job-based execution for cluster-integrated validation

MITRE ATT&CK Mapping

Redpen aligns telemetry and validation results to relevant ATT&CK stages to support detection coverage reviews.

ATT&CK Stage	Example Technique	Typical Defensive Validation
Reconnaissance	T1595, T1589	Validate detection of enumeration and discovery-like traffic
Initial Access	T1190	Confirm WAF or edge protections catch suspicious entry patterns
Execution	T1059	Validate runtime alerting for command execution indicators
Persistence	T1547	Verify logs and process-monitoring coverage for persistence-related behavior
Privilege Escalation	T1068, T1078	Check identity and authorization monitoring coverage
Defense Evasion	T1027, T1562	Validate detection of obfuscation and control tampering
Lateral Movement	T1021	Review network and log correlation for movement patterns
Exfiltration	T1048	Confirm data-loss monitoring and outbound transfer alerts

This mapping is used for reporting and alignment rather than for malicious activity guidance.

Documentation

• detection_harness/README.md
• docs/automation_runbook.md
• docs/detection_simulation.md
• docs/detection_rules_and_remediation.md
• docs/disaster_recovery.md
• docs/pr_pipeline.md
• docs/training_guide.md
• monitoring/README.md

Contributing

Contributions are welcome.

1. Fork the repository and create a feature branch.
2. Keep changes focused, well-documented, and safe by default.
3. Run the relevant validation commands locally before opening a PR.
4. Update or add documentation when behavior changes.
5. Submit a pull request with a clear summary of what changed and why.

Please avoid checking in live payloads, secrets, or unsafe test content. Use secure secret management and environment-based controls for any gated test scenarios.

License

This project is licensed under the MIT License.

See the LICENSE file for full details.

---