Cybrary ForgeCYBRARY / FORGE
Back to Cybrary Forge

Cyber ranges powered by emulation

Work the environment. Change what happens next.

Build connected systems, identities, networks and security tools in an emulated estate. Change a configuration, investigate the evidence and see the consequences across the environment.

See how it works See where Forge fits

Build a range — try it here.

1. Add machines

2. Turn on controls

3. Watch the attack

  1. 1. Phishing lands on the laptop — succeeds

    Nothing on the laptop stops it.

  2. 2. Malware calls home — succeeds

    The connection out is allowed.

  3. 3. Spreads to the file server — succeeds

    Users and servers share one flat network.

  4. 4. Data is stolen — succeeds

    The data leaves over the open connection.

Scorecard: 0 / 100 — the attacker got everything.

A simplified demo. Signed-in teams build full ranges in My ranges.

Match the environment to the work.

Use Forge to rehearse “What happens if…?”

  • What if we change segmentation, routes, firewall policy, identity, or trust relationships?
  • How does an attacker path change when a control is added or removed?
  • Can our team recognize, investigate, escalate, contain, and recover from this scenario?
  • What happens when one system, identity provider, control, or analyst is unavailable?
  • How should a playbook or architecture change before we invest in implementation?

Use native software or hardware for “Will this exact implementation work?”

  • Will this exact binary install and run correctly on this exact OS or hardware?
  • Will a specific driver, firmware version, EDR agent, SIEM connector, or appliance behave as expected?
  • Will this exploit work against this exact implementation?
  • What are the true latency, throughput, timing, memory, kernel, or hardware effects?
  • Does this implementation meet a formal test, certification, interoperability, or benchmark requirement?

Match the execution environment to the work. Use Forge for the supported operational workflows in each compatibility profile, and actual software or representative hardware where the objective depends on its specific implementation.

  1. Tabletop
    Do we agree on who decides what?
    • · Escalation and decision rights
    • · Executive crisis communication
  2. Forge emulation
    What happens if…? Can the team perform it?
    • · Team incident-response rehearsal
    • · Attack-path change before rollout
  3. Native-software range
    Do these exact tools and integrations behave this way?
    • · Detection content against native telemetry
    • · Vendor connector behavior
  4. Hardware-in-the-loop
    Does this exact device, firmware or timing hold up?
    • · Appliance or firmware certification
    • · Latency and timing effects

Connect rehearsal with implementation evidence.

Use Forge for supported operational practice. When an objective depends on particular binaries, integrations, hardware or timing, validate that dependency in the appropriate environment and carry the evidence back into the next rehearsal.

  1. 1. Explore in Forge

    Build topology, users, controls, attack paths, injects and team actions; try many variations quickly.

  2. 2. Prove in the range

    Validate the subset that depends on real tools, real binaries, real integrations, hardware, timing or vendor behavior.

  3. 3. Multiply the learning

    Turn one validated exercise into many Forge variations for recurring rehearsal, onboarding and skills practice.

    ↺ back to step 1 with the next question

Extend your exercise program across environments. Use Forge for supported operational practice and connect the lessons with tests performed in your native-software or hardware environments.

Five cases that need a real range.

  1. 1

    Exploit against a specific build

    Whether this exact exploit lands on this exact patch level can only be proven by running it.

  2. 2

    Vendor connector or appliance certification

    Sign-off that a product integration works needs the vendor's own software, not a model of it.

  3. 3

    Performance, latency and kernel effects

    Load, timing and driver behavior come from real execution; Forge does not model them.

  4. 4

    Live malware detonation

    Watching real samples run belongs in an isolated sandbox. Forge never executes malware.

  5. 5

    Firmware and device validation

    Device firmware and industrial controllers need the device itself or a vendor emulator.

One environment. Different reasons to rehearse.

SOC & incident-response team rehearsal

Practice triage, investigation, escalation, containment, recovery, handoffs and communication while the scenario reacts to team decisions.

Security architecture & segmentation

Change networks, trust boundaries, routes, controls and identities; observe how exposure, attacker movement and defender visibility change.

Playbook & process testing

Run procedures against interactive technical scenarios before you discover gaps during a real incident.

Red / blue / purple exercises

Model attacker objectives and defender responses, then vary the environment to create repeatable exercises instead of a single scripted run.

Onboarding & skills validation

Give practitioners a representative environment in which they must perform the job, not simply answer questions about it.

Crisis and cross-functional exercises

Connect technical events to operational injects, decisions and consequences so security, IT and leadership can rehearse the same incident from different roles.

Which environment does the objective need?

  • Team incident-response rehearsal
    Fits: Forge
  • Segmentation and attack-path design changes
    Fits: Forge
  • Onboarding and repeat skills practice
    Fits: Forge
  • Playbook and escalation testing
    Fits: Forge
  • Ransomware exercise with a new EDR rollout
    Fits: Both
  • Pre-range rehearsal before a live-fire event
    Fits: Both
  • Exploit behavior against a specific build
    Fits: High-fidelity range
  • Vendor connector or appliance certification
    Fits: High-fidelity range
  • Performance, latency or kernel effects
    Fits: High-fidelity range
  • Live malware execution and sandbox analysis
    Fits: High-fidelity range
  • Firmware or hardware-device validation
    Fits: High-fidelity range

Build the environment you want to reason about.

  • Windows and Linux systems and representative host behavior
  • Networks, subnets, routes, segmentation and firewall rules
  • Users, identities, permissions and trust relationships
  • Security controls, monitoring and defensive configuration
  • Attacker actions, attack paths, scripted campaigns and changing conditions
  • Files, processes, logs, alerts and other simulated evidence
  • Human actions, team roles, exercise injects and scoring criteria

Actions change the emulated estate. Compatibility profiles identify supported behavior, execution details and boundaries.

One base environment. Many exercises.

Ransomware and incident response

Base · A mid-size company with a file server, backups and a SOC on shift.
  • Foothold through a phished workstation
  • Backups already encrypted
  • EDR console unavailable for the first hour

Identity compromise

Base · Directory, SSO and a cloud tenant with privileged service accounts.
  • Help-desk account taken over
  • MFA fatigue on an administrator
  • Stale trust between two domains

Segmentation change

Base · Flat office network being split into user, server and OT zones.
  • One firewall rule left too wide
  • Jump host removed
  • Attacker starts in the OT zone

More reps. More variation. Less environment management.

Change the scenario, not the infrastructure

Move a server, remove a control, compromise a different identity, alter the attack path or change the starting condition without rebuilding a fleet of VMs.

Repeat without making the exercise predictable

Keep the learning objective constant while varying traffic, attack surface, identities, timing and conditions.

Connect rehearsal with implementation evidence

Use Forge to rehearse supported workflows, then validate implementation-specific dependencies in the appropriate native or hardware environment.

Keep learning between major exercises

Use the same scenario model for individual practice, onboarding, team drills and follow-up exercises.

Use the execution environment the objective requires.

Forge emulates the supported operations declared by each compatibility profile. When success depends on a particular binary, kernel, firmware version, appliance, protocol implementation, integration, hardware device, performance characteristic or malware sample, use the appropriate native software, isolated sandbox or hardware environment.

Choose the exercise by the outcome you need.

SOC / Security Operations

Team readiness, incident response, threat hunting, escalation and defensive workflows.

Security Engineering / Architecture

Segmentation, identity, control placement, attack paths, resilience and design-change rehearsal.

Training / Workforce Development

Role-based onboarding, performance practice, assessment and repeatable hands-on exercises.

Range / Exercise Program Owners

Rapid scenario prototyping, pre-range rehearsal, between-exercise practice and scenario variation around an existing high-fidelity range.

Questions evaluators ask

Is Forge a “real” cyber range?
Forge is a cyber range powered by emulation. The important question is whether the selected profile covers the workflow, behavior and evidence your exercise requires.
Does Forge replace our existing cyber range?
Not necessarily. If you already have a high-fidelity range, Forge can sit around it: prototype and rehearse quickly in Forge, validate the subset that requires real tools or implementation behavior in your range, then use Forge for additional repetitions and variants.
Can Forge mirror our production environment?
Forge recreates supported parts of an estate from approved inventory, identity, network and security-tool information. The profile and source details show what is covered, how fresh it is and what remains outside scope.
Can we test an actual security product or custom application?
Forge can model workflows, configuration choices and expected effects. If the objective is to prove that an exact binary, integration, device, driver, firmware version, exploit or detection behaves correctly, that validation belongs in the real system or a high-fidelity range.
Why not just do everything in the high-fidelity range?
Because fidelity has a cost in provisioning, customization, maintenance and exercise time. Many training and rehearsal objectives are about decisions, procedures, architecture and consequences rather than exact implementation behavior. Forge is optimized for those repetitions and variations.

Rehearse in Forge. Prove it in the range.

Start with the scenario you cannot afford to learn in production.

Show us the environment, decision, incident, or architecture change your team needs to rehearse. We will help identify what Forge can emulate and where native software or hardware evidence should remain part of the plan.

See how it works Talk through a use case

Why fidelity matters: NIST / NICE — The Cyber Range: A Guide (2023) · Carnegie Mellon SEI — Foundation of Cyber Ranges (2021) · ENISA — Cybersecurity Exercise Methodology