The On-Page SPL Engine: Live Searches Against the NE Corpus, No Install

Most security training ends its orientation with a setup chore: install these add-ons, provision a tenant, stand up a lab, download a data pack, then spend an evening fighting it before you write a single search. This course has none of that. Your entire toolkit is the search bar on the page, and the Northgate corpus is already loaded behind it.

There is no Splunk license to buy, no instance to deploy, no virtual machine, and nothing to download. You read a search, you run it, you read the result, and you do that against real evidence from the first search in Module 1 to the capstone.

That is a design decision with a reason behind it, and the reason connects straight back to how this course thinks about detection.

A detection is only real if it returns the right rows against real data and stays quiet against the noise around it. A screenshot cannot show you that, and a paragraph describing what a query "would" return cannot either. A live result can, and so can the failure when your query returns nothing, or returns the wrong rows, or times out.

Putting the data and the engine on the page is how the course lets you feel those outcomes instead of being told about them, which is the only way the judgment you are here to build actually forms.

There is a sharper version of this point for the work ahead. Tuning, the craft SPL0.5 described, cannot be learned from static material, because tuning is a back-and-forth with real data: you set a threshold, run it, see how many benign rows slip through, adjust, and run it again. Every one of those turns needs a live result to react to.

The same is true of testing whether a change removed a false positive or merely hid it, and of the moment a search you were certain about returns nothing at all. None of that survives translation into a screenshot.

The engine on the page exists so that the loop of trying, failing, and adjusting, which is where detection skill actually comes from, happens here rather than waiting for your first day in a real environment.

Three surfaces, one engine

You write SPL against the Northgate corpus in three places, and all of them run on the same engine and the same data, so a technique you learn in one carries straight to the others.

The inline search blocks live inside the modules. They carry the searches the lesson is teaching, and they are where most of your time goes: you read the search the sub is explaining, run it, and reason about what comes back.

Query Practice is an open search bar with no objective and no grading. It is the place to test an idea, take a search apart to see how a piece of it behaves, or try the variation a module mentioned but did not run. The SPL Lab is graded.

Each exercise hands you a scenario and a starting point, and you build the detection or investigation to a defined result, which is how you confirm you can produce an answer yourself rather than only follow one someone else wrote.

In practice the three form a loop. You meet a technique in an inline block and run it as written to see it work. You carry it into Query Practice to take it apart, change it, and find where it breaks, which is usually where the understanding arrives.

Then you prove you own it in the SPL Lab, against a scenario that gives you a goal and a starting point but withholds the answer. Moving from following a search, to dismantling one, to producing one under a defined objective is the same progression that turns a Splunk user into someone who can build detection logic with no worked example in front of them.

How a live block works

From Module 1 onward, the search blocks in the content are not pictures of Splunk. Each one is an editor wired to the engine, and it behaves in a consistent way across the whole course. Run executes the search against the Northgate corpus and renders the result as a table directly beneath it, the way Splunk renders a completed search job.

Edit lets you change the SPL in place and run it again: raise a threshold, add a by clause, swap a source, and watch the result move, which is the fastest way to build a feel for what each part of a search is doing.

Reveal uncovers an output block that was hidden on purpose, so that you can commit to a prediction about what the search returns before you see whether you were right.

Those three actions are the whole interface, and the last of them is worth using deliberately rather than clicking past, for reasons SPL0.2 sets out as a study method. Any blocks you have seen so far in this orientation were illustrative only. The first live search is in Module 1, and from there the searches are meant to be run in order, because the result you produce in one section is frequently the evidence the next section reasons about.

It is worth being specific about what to do with Edit, because the temptation is to run a block once and move on. The quickest way to understand a search is to change one thing at a time and watch the result respond. Remove a filter and see how much noise floods back in. Tighten a threshold and watch real results vanish alongside the false ones.

Add a field to a by clause and see the result split apart. Each small edit answers a question about how that piece of the search behaves, and the answers accumulate into the intuition you lean on when you write searches from scratch.

Reading the result table is half the skill: a count, a list of values, a set of rows, each is the search telling you something, and learning to ask what a table does and does not prove is the same reasoning the knowledge checks and the exam are built to test.

The corpus behind the engine

The data the engine searches is the Northgate corpus introduced in SPL0.6, and two of its properties shape how you work with it. It is a fixed window of evidence rather than a live feed, anchored to a set point in time, so a search references that window rather than the present moment, and the modules tell you how to handle time against a fixed corpus wherever it matters.

It is also the same for everyone: a given search returns the same rows for you as for any other student, so the predictions you make are stable and an answer you reach is one you can check against the module's own.

The seven attack chains are embedded in the corpus as real sequences, so when a module asks you to find the spray or reconstruct the endpoint compromise, the evidence is genuinely there to be found rather than staged for the occasion.

The teaching engine and production Splunk

The engine on the page runs real SPL, and everything this course teaches executes in it: base searches and field filters, stats and its aggregations, eval, rex, and the more advanced commands the later modules lean on. The data models and lookups introduced from Module 2 onward are present and queryable against the corpus.

When you write a detection here, you are writing the same search language you would write in a production Splunk, which is the point: the skill has to transfer or the course has failed.

It is still a teaching engine, not a full Splunk Enterprise deployment. There is no app ecosystem, no Enterprise Security interface, no data-onboarding pipeline, and the time controls are simplified because the corpus is a fixed window of evidence rather than a live feed. A few commands outside the scope of this course are not implemented.

None of that changes the SPL you learn or the way you reason about a result, and where the engine's behavior differs from production Splunk in a way that would matter to a detection, the module says so on the page. A surprise you were warned about here is far less costly than the same surprise discovered later in your own environment, mid-incident.

If you also have Splunk at work

You need nothing beyond this page to complete the course, and the on-page engine is where every detection in the modules is written and graded. That said, much of this course's audience already sits in front of a Splunk environment at work, and running the same techniques there is good practice once you have learned them here.

If you want the extra repetitions, Splunk offers a free tier you can install locally, an official search tutorial with a sample dataset, and the publicly released Boss of the SOC datasets, which are security-focused and suit the detection and hunting work this course covers. Treat all of that as optional enrichment rather than a requirement.

The corpus this course is built on lives on the page, and so does the work.

Confirm you are ready

Before Module 1, you should be able to say yes to each of these:

• You can read a Splunk result table and reason about what it does and does not prove. The course assumes this rather than teaching it, and SPL0.2 draws the assumed-versus-taught line precisely.
• You have the base SPL the course expects you to bring: a search with index= and sourcetype=, stats with by, eval, and rex. If those are not yet comfortable, the KQL course (SEC201) and Splunk's free material are the on-ramp, and this course will be far more rewarding once they are second nature.
• You understand the Northgate estate and the kind of evidence each source holds, from SPL0.6. You do not need its index map memorized; mapping evidence to indexes is the first thing Module 1 does.

If those hold, you are ready, and the orientation has done its job. You know why the SIEM holds the whole estate, why an attack is a trail across its sources, why detection is the discipline of separating signal from noise, what the Northgate environment is, and how to run a search against it on this page.

Module 1 takes you into the platform itself: search-time versus index-time, how the Common Information Model is applied to Northgate's data, and your first detection-grade searches, run live against the corpus.