Transforming Bug Triage into Training: Inside the Making of Immersive AppSec Range Exercises
“We all know the pain of bug reports clogging up a sprint—we thought, what if we could transform that drain on time and morale into a challenge developers are excited to tackle?” Rebecca: Oh, I love that—turning bug backlog dread into bite-sized victories is brilliant. I’m excited to hear more, but first, congratulations on launching Immersive AppSec Range Exercises! This is a BIG deal! No one else does anything like this for developers. Naomi: Thanks! What can I say? My love for cybersecurity goes back to university capture-the-flag events. Pushing yourself outside your comfort zone with hands-on challenges is by far the fastest way to learn. My main goal was to bring that same energy to application security—there are loads of CTFs for pentesters, but not really for developers who need to sharpen their defensive and remediation skills. I also wanted this to be inherently team-friendly. Our individual AppSec labs are built for individual learning, but group dynamics demand different pacing and collaboration tools. Rebecca: Makes total sense. Offensive skills get the headlines, but developers need a solid, team-centric defensive playground too. So how did you translate that vision into the actual structure of our AppSec Range Exercises? Naomi: I anchored everything in the maintenance phase of the software lifecycle: Receive bug → Triage → Fix → Test → Merge. That mirrors real dev workflows, so participants don’t just patch vulnerabilities—they live the ticket management, version control, and testing cadence they’ll face on the job. [Inside scoop: When we build any security exercise, our team maps it to a real-world experience. In Immersive AppSec Range Exercises, a common SDLC workflow—teams learn best when they see exactly how it will play out in their daily sprints. ] Rebecca: I love that you’re training both mindset and muscle memory—jumping through the same process you’d use in production. Once you had that flow, what were the first steps to bring the framework to life? Naomi: Well, I knew that this project was going to need quite a few applications to house the functionality for the exercises, so I audited what we’d need from scratch versus what open source could handle. For ticketing, most OSS Kanban tools were overkill, so I built a lightweight app called Sprinter. Then for version control, we leaned on GitLab—it was quick to stand up and gave a familiar UI for branching and merges. Once those pieces clicked—vulnerabilities surfacing in Sprinter, code pushes in GitLab, and test runs in the Verification view—we had a minimally viable range exercise in action. Rebecca: A smart “build-what-you-must, borrow-where-you-can” approach. Seeing that prototype come together must’ve been so cool. Naomi: Absolutely. It was one thing to design on paper, but watching the pipeline live—tickets flow in Sprinter, GitLab merge requests, automatic test feedback—was a genuine “wow” moment. Rebecca: Speaking of “wow,” let’s talk scenarios. How did you land on “Blossom,” your vulnerable HR app in the Orchid Corp universe? Naomi: Well, we needed something with enough complexity to showcase the framework. HR apps hit three sweet spots: business logic richness, varied user roles, and sensitive data. Tying it into Orchid Corp—our fictional corporation for Immersive Cyber Drills—gave it narrative depth, especially for returning users of our Immersive One platform. Rebecca: And when you designed the actual vulnerabilities inside Blossom, what guided your choices? Naomi: I started with the OWASP API Top 10—that’s our gold standard for spotting the biggest threats. Then I looked at what slips through most scanners and frameworks—nuanced business-logic flaws and edge-case logic bugs—and made those the core of the challenge. To keep things well-rounded, I also added a few classics—things like IDOR, SSRF, and command injection—so every player gets a taste of both modern pitfalls and time-tested exploits. [Inside scoop: Mixing modern, real-world API flaws with a few known “gotchas” keeps Immersive AppSec learners guessing and builds confidence when they spot the unexpected.] Rebecca: I know you’re busy working on the next exercises we’ll release, but before we wrap, how did you test Blossom among developers and engineers? No doubt you wanted to make sure it delivered the right experience! Naomi: Yes, absolutely! We ran a pilot with our own Immersive engineers and a third party, creating a realistic dev team. Watching them collaborate—triaging, patching, merging—validated every piece of the design. Their feedback on pacing and hint levels let us polish the final release. It was one of my favourite days—seeing months of work click into place. After that, we shipped it to customers knowing it was battle-tested. Rebecca: This has been fantastic—thank you for sharing your full planning and development journey, Naomi! From initial vision to a live, collaborative exercise … I’m awed. You certainly put incredible thought and care into developing this revolutionary approach to AppSec training. Final Thought Security is a team sport, and training like Immersive AppSec Range Exercises is the fast track to confident, resilient DevSecOps teams. If you’re a developer or engineer looking to level up your remediation skills, have your team lead reach out to your Account Manager for a demo. In the meantime, watch a sneak peek of what your experience would be like in this demo below:Bad News for Black Hats: Why Our New Dynamic Threat Range Is Bound to Ruin Their Day
Welcome back to our series, “Behind the Scenes of Immersive One”! The following is a conversation with DaveSpencer, Immersive Product Manager for Technical Exercising, and RebeccaSchimmoeller Lead Product Marketing Manager. “Getting your SOC team off their desks for a multi-day drill is tough. Then, having them practice on a generic SIEM when your entire team lives and breathes in Splunk? I mean, practice is supposed to make perfect … That set-up is … flawed.” Rebecca: No kidding, Dave. It sounds like you heard from a lot of SOC Managers that their teams were running straight into what we call the ‘relevance gap.’ Can you break down what that actually means for hands-on analysts? Dave: Think of that 'gap' as the frustrating space between theory and reality. It’s when you force an analyst to practice on a generic, made-up tool, but their actual job is 100% in Splunk. It’s running an exercise on a simple, flat network when your real corporate network is a complex, segmented beast. Rebecca: So, the skills they're learning just don't transfer to the real world. Dave: Exactly. It’s why a team can get a 100% pass rate on a training module and still be completely unprepared when a real incident hits. It’s not just wasted time; it’s a false sense of security. Rebecca: So, how does our new Dynamic Threat Range capability solve that? How do we close that gap for good? Dave: By blowing it up entirely. We built this from the ground up to be hyper-realistic. Dynamic Threat Range is the only capability on the market that lets teams run live-fire exercises in a high-fidelity replica of an enterprise environment, using licensed security tools. At launch this November, we’re talking native support for Splunk and Elastic. This isn't just replaying logs; it's an authentic, full-chain adversary attack, built by our elite C7 threat team, running on the exact tools teams use every single day. Rebecca: Okay, so that’s a game-changer for the hands-on user and, no doubt, from managers too. They’re struggling to prove where their team is at in order to help them improve. How do we help them with this? You know, move beyond a pretty unhelpful "pass/fail"? Dave: Right. That's actually a core pillar we’ve built against. With Dynamic Threat Range, customers move beyond arbitrary scores. Our design is all about objective proof of readiness. We're giving managers the hard data they need to prove their team’s capability and justify their security spend. Rebecca: Oh … tell me more! Dave: At launch, we’re measuring key metrics like Time to Detect, Time to Escalate, and Investigation Accuracy. It’s the only way to get verifiable, evidence-based data on performance. “In a real attack, the platform doesn’t tell you if you’re right or wrong. So why should your exercise?” Rebecca: Running full-chain attacks on a replica of a customer's environment sounds incredibly complex. I can just hear the IT and Ops teams groaning about setup, VPNs, and operational overhead. Dave: (Laughs) Yeah, we heard that, too. And that’s why we made it 100% browser-based. No VPNs. No operational headaches. You get into the exercise and start learning in seconds. We also designed the exercises to be practical. Getting a SOC team offline for a multi-day drill is really hard. So, these default to 4 hours—intense, focused, and easy for a manager to schedule. You can extend it to 24 hours if you want to practice handovers between shifts, but the goal is zero friction. Rebecca: I love that. So, as an analyst, what can I actually do in these 4-hour exercises at launch? Dave: We’re launching with two critical exercise types. First is Digital Forensics and Incident Response (DFIR), where you join after the attack has happened and you have to use your Splunk or Elastic instance to piece together what went wrong. The second is Threat Hunting, which I love. You're in the environment as the attack itself is kicking off, and you have a detailed threat intelligence pack to work from, allowing you to proactively detect the threat before it causes real damage. It’s the difference between being a digital archaeologist and being the hunter on the ground. Rebecca: So cool! This is already huge, Dave. Knowing you, though, the team is just getting started. What’s the long-term vision? Dave: We're moving fast. We’re already working on Microsoft Sentinel support for Q1 2026. After that, we’re building out exercises for the entire security lifecycle—Containment, Recovery, Red Team, and Purple Team drills. The vision is to let you exercise every part of your security function and then benchmark your performance against your industry peers. That’s the real holy grail: knowing exactly where you stand. Rebecca: Dave, this is incredible. The passion you and the team have for solving this real-world problem is clear. Thanks so much for geeking out with me today. Dave: Any time. We're just excited to get it in people's hands. Final Thought The days of generic, classroom-style training are over. Dynamic Threat Range finally bridges the gap between practice and reality, allowing your teams to build muscle memory on the actual technology they are paid to protect. It moves your entire security function from ‘we think we’re ready’ to ‘we know we’re ready’—with the data to prove it. Want to see how it works? Don’t miss this demo.
CVE-2022-26134 (Confluence) – OGNL Injection
For Question 6. Look at the first exploit attempt by this attacker. What command did they run? I am wondering about why when sharing the commands found in the logs, it still outputs wrong. even if typing in "X-Cmd-Response" as the command as well as the entire string found. Wondering if they are exepecting a different format/snippet of the code, or the GET requests instead?
The Human Edge Beyond Pentesting – Building True Cyber Resilience
The Human Edge Beyond Pentesting – Building True Cyber Resilience Pentest vs. Red Team: Understanding the Core Difference Many cybersecurity vendors are rebadging pentesting as attack simulations or red teaming, often at a higher cost. However, there's a clear difference: Pentesting (Penetration Testing): The overarching goal of penetration testing is to find vulnerabilities within an environment in order to create a remediation plan. Reporting focuses on documenting as many vulnerabilities as possible in the allotted timeframe. Red Teaming (Attack Simulation): In contrast, red teaming is used to validate the efficacy of the defensive (blue) team. It is not looking for vulnerabilities per se, it is about achieving the objectives while trying to avoid detection. Reporting focuses on finding defensive gaps and assessing the blue team's response capabilities. The ultimate goal is to simulate real-world adversaries and determine if the defensive team has the telemetry to detect them. The key takeaway is that if the engagement isn't assessing your detection capabilities, it is not a red team. When Does Red Teaming Truly Add Value? While valuable, red teaming isn't always the most cost-effective solution, and really it is usually only effective in these three scenarios: When You Have a Regulatory Requirement: Industries with specific regulations, such as BEST, TIBER, FEER, CORIE, and AASE, often mandate regulatory red teams, which have standardized approaches and qualifications. When You Have a Very Mature Organization: Your organization has addressed all other possible security issues and has limited justification for further spending, a Red Team can provide a level of assurance that few other testing strategies can match. However, if you have known, unaddressed issues, red teaming rapidly loses value as the simulated attackers will typically take the easiest route to compromise and report on issues you are already aware of. When You Need a "Burning Platform": Sometimes, demonstrating the potential severity of a worst-case scenario is necessary to secure critical budget increases. Red teaming can effectively highlight how badly wrong things could go, aiding CISOs in getting the needed resources. However, it's important to note that more cost-effective methods often offer a better return on investment than red teaming outside these specific use cases. Purple teaming offers a more holistic approach to measuring your blue team's capability while also having a much higher knowledge transfer rate. Attack path mapping is far more comprehensive in discovering what attackers can do and what vulnerabilities or misconfigurations can be chained together to achieve compromise. The Pitfalls of Misaligned Red Teaming Several factors can hinder the benefits of red teaming outside the identified use cases: Resource Intensive: Red teaming is both costly and time-consuming. Potentially Divisive: It can sometimes lead to conflict between teams or erode trust within an organization. Weak Follow-Up: Lessons learned from red team exercises are often not translated into actionable steps, or worse completely ignored. Limited Scope: It may fail to explore cascading impacts and real-world disruptions. Insufficient Business Focus: Without an understanding of broader business consequences, the exercise's value can be limited. Increased Risk: Poorly executed red teaming can introduce wasted effort or unnecessary investigations. Often Undetected: A significant number of red team operations do not trigger alerts or go unnoticed by defensive teams. This last point highlights the importance of understanding why an attack wasn't detected, by asking: Was an alert generated? Was it marked as a false positive? Was a process followed? Was the process correct? Enhancing Cyber Resilience: A Holistic Approach Cyber resilience is not just about products or individual tools; it's about the application of skilled and motivated people, understanding and utilizing technology, and implementing reliable and repeatable processes and detections. The focus should be on building a robust, layered defense that understands, anticipates, and mitigates all phases of the attack chain, recognizing that the perimeter is no longer the sole objective for attackers. To truly improve cyber resilience, organizations need to focus on three key areas: Security Posture: Continuously assess and strengthen your foundational security. Detection Capability: Improve your ability to identify and triage malicious activity. Response Capability: Enhance your team's efficiency and effectiveness in reacting to and recovering from incidents. This involves exposing defenders to real-world Tactics, Techniques, and Procedures (TTPs) relevant to their environment. Furthermore, understanding the capabilities and blind spots of both your security team and defensive tooling is crucial for applying and testing effective mitigations and proving resiliency. Practical Approaches to Building Resilience To achieve true benefit from simulations, organizations must prepare individuals and teams before and after the simulation. This involves a cycle of "Prepare & Protect" and "Detect & Respond". Effective training and exercises are vital for different audiences: Individual Preparation: Hands-on labs can provide technical training for various roles, including defensive cybersecurity professionals, penetration testers, developers, application security experts, and cloud & infrastructure security personnel. Technical Team Exercises (Team Sim): These focus on the technical aspects of cyber attack and response using pre-configured cyber range scenarios. Participants investigate or perform simulated attacks using real cybersecurity tools and techniques in a safe environment/sandbox. Executive & Business Exercises (Crisis Sim): Moving beyond traditional tabletop exercises, Crisis Sim puts teams into dynamic crisis simulations with real crises, dynamic storylines, and contextual media. This helps measure and benchmark responses to inform crisis strategies and build muscle memory through regular exercising. By understanding the distinct roles of pentesting and red teaming, strategically applying attack simulations, and investing in comprehensive training across all levels of the organization, businesses can genuinely enhance their cyber resilience and gain the human edge over cyber attacks.
