Introduction to Elastic: Ep.9 - ES|QL
I’m stuck on question 18 i need this to complete the lab. The question says ‘Perform a final query using all of the techniques used in the previous questions. What is the average speed per hour for ALL trips that start in the borough of “Brooklyn” and end in the borough of “Manhattan”? Provide your answer to at least three decimal places. any ideas?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:Why Drills Are the Future of Cybersecurity: Insights and Reflections on the Critical Role of Drills
My background After two decades in the world of penetration testing and offensive security, I joined Immersive as the Director of Technical Product Management. This new role represented more than just a career shift – it was an opportunity to leverage my deep-rooted experience of cybersecurity to make a tangible difference in how organisations prepare for the cyber threats of today and tomorrow. Throughout my career, I’ve had the joy of working on the front lines of cybersecurity, testing the defenses of organisations of all sizes, from startups to multinational corporations. I worked my way up from a junior consultant in a boutique company to the global head of attack simulation for one of the largest pure-play security consultancy firms in the world. I’ve seen firsthand how attackers operate, exploiting weaknesses not just in technology but in processes and human behavior. I’ve also seen the other side of the coin – what happens behind the scenes when a company identifies a breach and needs to investigate, contain, and recover from it. This journey has given me a unique perspective on the intricacies of cyber incidents – how they unfold, how they escalate, and how they can be mitigated if handled correctly. Over the years, I’ve come to understand that offensive security isn’t just about finding vulnerabilities; it’s about understanding the broader context of how security failures can impact an entire organisation and, most importantly, how to get back to business as usual. One of the key lessons I’ve learned from my time in offensive security is that real-world cyber incidents are rarely straightforward. They’re messy, unpredictable, and often involve a complex web of factors that go beyond the technical realm. In my experience, cyber incidents don’t happen in isolation; they’re the result of a combination of technical vulnerabilities, process failures, and human errors. Attackers don’t follow a script – they’re constantly adapting, finding creative ways to bypass defenses, exploit blind spots, and leverage misconfigurations or overlooked details. This nuanced understanding of how incidents unfold is often missing from the current training and exercising landscape. Realism vs textbook Many cyber resilience exercises available in the market today lack the depth and realism of a real-world attack, and that’s very difficult to capture, especially if you’ve never been exposed to it. Many exercises are built around predictable scenarios, focusing on textbook responses, and just don't capture those swings from tedium to confusion and then to panic. They’re also often performed in isolation, with the investigating/technical team making decisions and performing actions that wouldn’t be in their remit if it was a real incident. One of my all-time favourite incidents showed these to the extreme. It went from a simple ransomware investigation to identifying seven different threat actors in the environment, all with very different TTPs and MOs. You never pick up the other threat actors at the beginning of their attack, usually because they’ve compromised the same machines as the original actor, and you're left wondering why they’ve suddenly changed tactics. Then you get enough evidence to indicate it’s someone else, so now you have two investigations to perform. I’m not saying that all exercising should be done to that level, but I do feel that there’s a nice middle ground that can be achieved. Simulations can highlight things above and beyond simply probing a SIEM for answers to questions about the attack. Putting that into practice At Immersive, I have the privilege of bringing the lessons learned from years of offensive security into the realm of cyber resilience training. My goal over the last 12 months has been to help create more realistic, dynamic, and comprehensive simulations that mirror the true nature of cyber incidents. This means developing scenarios that go beyond the basics – not just testing the technical teams but also involving executives, legal teams, PR, and other stakeholders who play critical roles during a crisis. By integrating real-world attacker tactics, techniques, and procedures (TTPs) into exercises, we can help organisations build muscle memory for responding to incidents in a way that’s both informed and effective. It’s not just creating realistic simulations, it’s highlighting how the results of an investigation can influence the executive team's decision making and how the decisions made by leadership can either help or hinder an active investigation. This is what led to my involvement in building out Immersive Cyber Drills. But what are drills, I hear you ask? Here’s what our marketing team say: “Immersive Cyber Drill events enable simultaneous drilling of executive and technical leadership teams. These facilitated drills use multiple tools from our platform to evaluate an organisation's capacity to detect, respond to, and recover from cyberattacks through a mix of technical and non-technical drilling.” Ultimately, the goal is to empower organisations to respond confidently to the threats they face. Cyber resilience isn’t just about having the right tools or technologies – it’s about understanding the attacker’s mindset, anticipating their moves, and being prepared to act swiftly and decisively when an incident occurs. Building a foundation for Cyber Drills Instead of creating theoretical scenarios or low-risk simulations, we began building exercises that mirrored the attacks I’d seen work in my previous life. The aim was simple: make the drills feel as close to a real attack as possible while keeping the barrier to entry low enough that they’re still achievable to people just starting out. One of the biggest breakthroughs came when we built a standard environment that mimicked much of the corporate world's infrastructure. We then implemented these real-world attacks over the top of those environments and dropped the users in the middle of the attack. This transformed the experience from a disconnected series of technical challenges into a real narrative. Participants were now uncovering the motives behind attacks, following the trail of TTPs left by the attackers, and trying to predict where they went next. Very rarely do security teams get to investigate in a nice, peaceful manner – there are always questions coming from other areas of the business. Leaders aren't just responsible for understanding the attack, they also need to communicate with stakeholders, manage the internal teams, and make high-pressure decisions. As the Cyber Range Exercises (formerly Team Sims) became more realistic, it was clear that the Crisis Simulations used for the leadership team should follow suit. So we built Crisis Sims around the same attack narrative, putting participants in a situation where leadership had to make decisions that they didn’t know the answers to. If they did want to find out, they would need to ask the teams performing the investigation. This forced both teams to think strategically, communicate effectively, and most importantly, anticipate the other team's perspective and restrictions. We also introduced real-world elements like media scrutiny, conflicting priorities, and escalating pressures to mimic the experience of an actual cyber breach. The results were immediate. The teams were forced to think on their feet and develop genuine muscle memory in ways that couldn’t have been achieved through traditional tabletop exercises. And most importantly – they needed to talk to each other. This fusion of leadership training, technical training, and realism has resulted in teams leaving the drill with a stronger understanding of how to work cohesively as a team and how well they communicate across departments. It also provides a better understanding of the types of nuance that can crop up during a cyber breach. Share your thoughts For the analysts reading this article, what’s the hardest part of performing an investigation in your current organisation? For the executives, what’s one thing you wished all analysts knew about your role? And to everyone, during an investigation, what was your biggest panic moment that could have been easily avoided? Join me in this discussion by sharing your thoughts in the comments.
