Making the Most of Custom Lab Builder: A Guide to Writing Inclusively for All
Language shapes how people perceive and engage with content, so it’s crucial to consider the kind of words you use. Using outdated terminology can offend and disengage learners, as well as hurt a company’s reputation. This blog is the second in a series on making the most of the Lab Builder, looking at what we call the Four Cs. Ensuring your writing is… Conscious Consistent Conversational Concise The previous post in this series looked at accessibility. In this post, we’ll explore what it means to write consciously and inclusively, share practical tips, and show how our platform supports this critical effort. Why is inclusive language important? Inclusive language avoids bias, respects diversity, and ensures accessibility for all. In cybersecurity, it means using terms that foster collaboration and trust, avoiding outdated or harmful phrases, and creating welcoming and empowering content The Quality Team at Immersive Labs is committed to staying up to date with how language changes in the cyber industry. We regularly undertake research and speak to other industry professionals to ensure that our language is appropriate. Words to avoid We recommend avoiding specific terms that some people may find offensive, and some socially charged language that may have negative connotations. Non-inclusive language to avoid Preferred inclusive versions Whitelist/Blacklist Allowlist/Denylist White hat/Black hat hackers Ethical/Unethical hackers Master/Slave Leader/Follower, Primary/Replica, Primary/Standby Grandfathered Legacy status Gendered pronouns (e.g. assuming “he/him/his”) They, them, their Gendered pronouns (e.g. “guys”) Folks, people, you all, y’all Man hours, man power Hours, engineer hours, workforce, staffing Man-in-the-middle attack Machine-in-the-middle attack Sanity check Quick check, confidence check, coherence check Dummy value Placeholder value, sample value Crazy, insane Amazing, incredible, or any other appropriate adjective Socially charged words Preferred inclusive versions Native Built-in, default, pre-installed, integrated, core Abort Stop, cancel, end, force quit Cripple Disable, impair, damage, destroy, ruin Kill Stop, force quit, close, shut down Trigger Activate, initiate, cause, launch Unsure if a phrase you’ve used could be seen as offensive? Ask yourself: is this the most accurate and appropriate choice? Often, you can find a more descriptive word and avoid using these examples. Top tips for inclusive language Use writing tools Tools like Grammarly can help identify problematic words or phrases. You can create customized lists in Grammarly, which will then flag when a word has been used in your writing. Additionally, there are many inclusive language guides available online. Keep it short and sweet Use short sentences and paragraphs. Shorter sentences are easier to read, scan, and understand – especially for those with cognitive disabilities. Aim for sentences around 10–15 words, with variation for a natural flow. Avoid sentences longer than 20 words, as they can be harder to follow. Read aloud Proofread your work aloud to catch awkward phrasing, overly complex sentences, or insensitive terms. Hearing the words can help identify spots where clarity or tone might need improvement. Get a second opinion Ask a colleague to review your final version. A fresh set of eyes can spot language that might be unclear, inappropriate, or overly complicated. Share your thoughts Now that Lab Builder is here and you’ve had a chance to create your own content, how have you made your content more inclusive? We’re always looking to stay up to date, so if you have any further suggestions to add to our list of words to avoid or any other tips, let us know! We’d love to learn from you and grow the collective community knowledge.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:Making the Most of the Custom Lab Builder: Writing With Accessibility in Mind
What if someone tried to access your content who was visually impaired? Or who had cognitive difficulties? Or who was hard of hearing? Would they be able to understand the information you’ve provided and improve their cyber resilience? Our in-house copyediting team has created a series of articles to help you craft high-quality labs, aligned to the rigorous processes we follow. We embrace what we call the Four Cs to ensure all labs are: Consistent Conscious Conversational Concise These articles delve into each of these principles, showing how to implement them in your labs to create content that resonates with readers, enhances learning, and boosts cyber resilience. This post highlights how being conscious of your formatting can enhance accessibility for assistive technology users and how consistent formatting improves navigation for everyone. Rich text formatting Rich text formatting tools like subheadings, bullet points, lists, and tables in the Custom Lab Builder help organise information for easier scanning, better retention, and improved comprehension. Using these will ensure your content is consistent, accessible, and reader-friendly for everyone! Rich text formatting elements carry specific meaning, which assistive technologies rely on to convey information to specific users. Headings Visually, headings represent hierarchy through different font styling and allow users to quickly scan content. Programmatically, they allow users who can’t see or perceive the visual styling to access the same structural ability to scan. Heading elements should reflect the structure of the content. So your title should go in ‘Heading 1’ formatting, your next subheading will go in ‘Heading 2’ formatting, and so on. To ensure your content reads correctly to screen reader users, don’t use HTML heading styling to represent emphasis, and don’t use bold to make text appear like a heading. Lists (bullets/numbering) Always use bullets or numbered lists using the provided formatting to convey a list. A screen reader will announce that the following information is a list. Links How a link is formed significantly impacts usability. Consider the following sentence: “To find out more about this topic, complete our Intro to Code Injection lab here.” Links are interactive elements, which means you can navigate to them using the tab key. A user who relies on screen magnification to consume content may choose to tab through content to see what's available. The example above would be communicated as just “here”, which provides no context. They’d need to manually scroll back to understand the link’s purpose. Always use descriptive link text that clearly indicates its destination. Avoid ambiguous phrases like “here”. If that’s not possible, ensure the surrounding text provides clear context. “To find out more about this topic, complete our Intro to Code Injection lab.” Bold Only use bold for emphasis! Avoid italics, capital letters, or underlining (reserved for hyperlinks) to prevent confusion. Consistency in formatting reduces cognitive load, making your text more accessible. Bold stands out, provides better contrast, and helps readers quickly identify key information. Avoid italics With 15–20% of the population having dyslexia, italics are worth avoiding because research shows it’s harder for this user group to read italic text. Italics can sometimes bunch up into the next non-italic word, which can be difficult to comprehend or distracting to read. Media If you’re adding media to your labs, such as videos and images, it’s especially important to consider those who use assistive technologies. These users need to have the same chance of understanding the content as everyone else. They shouldn’t miss out on crucial learning. What is alternative text? Alt text describes the appearance and function of an image. It’s the written copy that appears if the image fails to load, but also helps screen reading tools describe images to visually impaired people. Imagine you’re reading aloud over the phone to someone who needs to understand the content. Think about the purpose of the image. Does it inform users about something specific, or is it just decoration? This should help you decide what (if any) information or function the images have, and what to write as your alternative text. Videos Any videos you add to your lab should have a transcript or subtitles for those who can’t hear it. Being consistent Consistency is a major thinking point for accessibility. We recommend adhering to a style guide so all of your labs look and feel consistent. We recommend thinking about the structure of your labs and keeping them consistent for easy navigation. In our labs, users expect an introduction, main content, and a concluding “In This Lab” section outlining the task. This helps users recognize certain elements of the product. It reduces distraction and allows easier navigation on the page. For example, some users prefer diving into practical tasks and referring back to the content if they need it. By using the same structure across your lab collections, your users will know exactly where to find the instructions as soon as they start. TL;DR It’s crucial to focus on accessibility when writing your custom labs. Utilise the built-in rich text formatting options in the Custom Lab Builder (and stay consistent with how you use them!) to ensure your labs are easy to navigate for every single user. By being conscious and consistent with your formatting, every user will engage with your content better, remember the topic, and be able to put it into practice more easily, improving their cybersecurity knowledge and driving their cyber resilience. No matter how they consume content. Keep your eyes peeled for the next blog post in this series, which will look at inclusive language. Share your thoughts! There’s so much information out there on creating accessible content. This blog post just focused on the language, structure, and current formatting options available in the Custom Lab Builder. Have you tried to make your labs or upskilling more accessible, and how did this go down with your users? Do you have any other suggestions for the community on how to write content with accessibility in mind? Share them in the comments below!
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?
Making the Most of the Custom Lab Builder: Tone of Voice
Now you can build your own labs in the Custom Lab Builder, we thought we’d provide some guidance on writing with a strong tone of voice to ensure your labs are as engaging as possible. This blog is the third in a series on making the most of the Lab Builder, looking at what we call the Four Cs. Ensuring your writing is… Conversational Concise Conscious Consistent The previous two posts looked at accessibility and inclusivity. This post focuses on tone of voice and how to write authentically to ensure your audience engages with the lab and remembers the message you’re trying to teach them. Writing well For most of your life, you’ve probably been told to write properly. Avoid contractions at all costs. Use complex sentences with plenty of fancy connecting words like “furthermore” and “moreover”. And never start a sentence with “and”. This formal style works really well for some industries. Academia is traditionally an incredibly formal area when it comes to the written word, as is the broadsheet newspaper realm. This is often to reflect the work’s sincerity, to avoid weakening a writer’s reputation, and to present ideas consistently and objectively. But Immersive Labs believes writing can be sincere and objective without being so... dull! Be conversational Copywriting is increasingly conversational, appearing everywhere from LinkedIn posts to the back of your milk carton. This style engages readers by feeling personal and authentic, aligning with Richard Mayer’s Personalization Principle, that people learn more deeply when words are conversational rather than formal. A human-to-human copywriting style makes sense for Immersive Labs, as we’re all about focusing on the humans behind the screens. When using the Lab Builder, we recommend writing your labs in an engaging, approachable style to create a modern, user-friendly learning environment. But conversational doesn’t mean sloppy. It’s about presenting ideas clearly and confidently, helping users feel at ease while they learn. Use everyday, concrete language Using fancy, complex words doesn’t make content better – it can actually distract readers and undermine clarity. Instead, prioritize clear, straightforward language to ensure your message is easy to understand, especially by users with cognitive disabilities. Avoid overly poetic phrases, figures of speech, idioms, or ambiguous language, which can confuse or overwhelm readers, including those with autism spectrum conditions. Strive for clarity to help users grasp your message the first time, keeping their needs front and centre. Address the reader Authenticity is all about gaining your reader’s trust. We recommend speaking directly to them in your custom labs by using “you” throughout your copy. This handy trick also avoids any ambiguity when it comes to practical tasks. Take the following example. “In this lab, the machine must be analyzed and IoCs must be extracted.” Instead of being vague and passive, we recommend talking directly to the reader and telling them exactly what they need to do. “In this lab, you need to analyze the machine and extract IoCs.” Or better yet, you can be even more direct by cutting that down even further: “In this lab, analyze the machine and extract IoCs.” Our labs and scenarios frequently talk directly to the reader. Users are more likely to stay engaged when they’re spoken to, not at. Use contractions Contractions instantly make your writing more conversational by mimicking natural speech. Combining words like "it is" to "it’s" or "you are" to "you’re" adds a touch of informality that feels approachable and inclusive. While once discouraged in formal writing, contractions are ideal for a modern learning environment, making text easier to read, understand, and remember. Be concise Writing in plain language is good for all users, but can make a massive difference for neurodivergent users, those who struggle to focus, those who hyperfocus, or maybe those who find reading difficult. We follow recommendations from the Advonet Group, the British Dyslexia Association, and Clark and Mayer’s Coherence Principle to ensure accessibility for a diverse audience – and you should too! Writing simply and clearly doesn’t mean trivializing content or sacrificing accuracy; it just makes your message easier to understand. After all, no one's ever complained that something's too easy to read! The difficulty comes when balancing this with technical content. How can you make advanced, complex cybersecurity topics clear and concise? Keep it short and sweet Sentences longer than 20 words become difficult to understand and can detract from the point being made. It’s easy for people’s minds to wander, so get to your point in as few words as possible. The same goes for paragraphs. Try and avoid long, dense walls of text. Nobody wants to read that, and it’s no good when thinking about accessibility. Keep your paragraphs to four or five lines, maximum. Get to the point Avoid adding unnecessary side notes to your labs, as they can distract from the main message and make learning harder. Unnecessary content distracts the learner’s attention from the main message, making them less likely to remember the core topic. It disrupts the connections between key messages and diverts the learner’s focus, making it harder to piece together the bigger picture. This is all down to cognitive load theory, which says that in general, humans can handle around four pieces of new information at any one time. To help users focus, stick to the lab's core topic and avoid overloading them with unrelated details. TL;DR When writing your labs with the Custom Lab Builder, ensure all your text is conversational to engage your users with the topic. And also make all your copy as concise as possible. Getting your message across in as few words as possible will reduce cognitive overload, boredom, and frustration. By focusing on being conversational, as well as being consistent and conscious (as we covered in the previous blog posts in this series), your readers will engage with your content better, remember the topic, and be able to put it into practice more easily – improving their cybersecurity knowledge and driving their cyber resilience. Share your thoughts! What do you think about these tone of voice tips when writing your custom labs? Have you tried to write your labs in a conversational yet concise way, and how did this go down with your users? Do you have any other suggestions for the community on how to write conversationally? We’d love to hear from you!Snort Rules: Ep.9 – Exploit Kits
I am pulling my hair with question number 8 Create a Snort rule to detect the third GET request in the second PCAP file, then submit the token. This one should do it but it is not working. alert tcp any any -> any any (msg:"detect the third GET request"; content:"e31e6edb08bf0ae9fbb32210b24540b6fl"; sid:1000001) I tried so many rules base on the first GET header and still unable to get the token. Any tips?More Immersive Cyber Drills: How Rich Media Can Bring a Scenario to Life
When running a cyber drill, it’s useful to have a consistent and cohesive sense of the story throughout. The use of branding and rich media (videos and audio related to the theme) can engage participants through a sense of world-building and storytelling. Imagine your company drill looking like your company — logo, color scheme, font and all. The Brand It’s a good idea to start with all the assets needed to create the custom content. In my case, I created a logo and color scheme for a fictional news company, CHANNEL 6 News. The intention was to create a consistent look and feel for the news updates we would use. Using a simple color palette and classic news branding style, I could then create a virtual website for news updates using presentation software. This allows for ease of editing and can be presented full-screen to look like a webpage. A key requirement of the project was to create content that could be edited by anyone — no special software needed. This is just a slide in a presentation! The slide format could be used to represent a company website, a news outlet, or anything to aid the storytelling. Each slide in the presentation is a copy of the previous, but the news story is changed (title, image, and copy). Rich Media Video is engaging; it grabs our attention and helps with immersion. Video that has relevant branding and specifics has the chance to immerse participants even further. Continuing with the Channel 6 News theme, I used an AI video generator to create a news presenter intro and outro, all within a single prompt to maintain a consistent look. I also created a graphical intro in professional video editing software, aligning the branding and adding stock backing music. Using a more stripped-back video editing app, such as Google Vids, templates can be created with the intro and outro already in place. In between, video clips and voiceover (also generated) provide the main content of the news update. These templates allow for quick editing by anyone without the need for expert software. Download the MP4, and we’re ready to slot it into a cyber drill! Here's an example of the intro/outro and small amount of content between. Company Videos Immersive has a fictional company it uses for Crisis Sims called Orchid Corp. We have brand assets (logos, graphics, etc.) that we use to create print and digital media. I created employee welcome videos using stock media and generated voiceover audio, which ended up being fairly convincing. Now, imagine your company assets in whatever type of video you want. Perhaps a news broadcast, maybe an internal or external press release on the crisis situation. The more entertaining and interesting the content, the more immersion and engagement. Prove and Improve Running drills with custom videos will capture your audience’s attention and imagination. There's a great opportunity to review how the media can be adjusted for further storytelling depth. It could be effective to have the story evolve at a future drill, building on the actions taken previously. Having templates for the content, such as a news update clip, means that significant time is saved in preparation and a consistent feel is kept across drills.
