31 alerts fired. End-to-end detection confirmed. The Elastic SIEM phase of the portfolio was complete.

So naturally, I installed a second SIEM.

Lab 22 is the start of the Splunk chapter — deploying Splunk Enterprise 10.2.2 on the same Kali Linux host, pointing it at the same log source, and seeing what it takes to build detection coverage from scratch on a completely different platform.

Same logs. Same threats. Different tool.

Why Splunk

Real SOC environments don't run one SIEM and call it done. Different organizations use different platforms — Elastic, Splunk, Microsoft Sentinel, IBM QRadar. An analyst who only knows one tool is an analyst with a ceiling.

The goal of the Splunk series isn't to prove that Splunk is better or worse than Elastic. It's to demonstrate that the detection engineering concepts I built in Labs 11–21 aren't platform-specific. The logic transfers. The syntax changes.

That's what platform-agnostic detection actually looks like in practice.

Installing Splunk Enterprise on Kali Linux

Splunk Enterprise doesn't come pre-installed. The setup starts with downloading the .deb package directly from Splunk's servers:

wget -O splunk-10.2.2-linux-amd64.deb "https://download.splunk.com/products/splunk/releases/10.2.2/linux/splunk-10.2.2-80b90d638de6-linux-amd64.deb"

Then installing it:

sudo dpkg -i splunk-10.2.2-80b90d638de6-linux-amd64.deb

Then starting Splunk and accepting the license:

sudo /opt/splunk/bin/splunk start --accept-license --run-as-root

On first launch, Splunk prompts you to create an admin account. Once that's done, the web interface is accessible at http://localhost:8000 — Splunk's browser-based UI where everything lives.

First impression coming from Elastic: different layout, different terminology, same fundamental concept. You're building a pipeline from log source to searchable index to detection logic. The plumbing is just labeled differently.

Configuring Log Ingestion

Getting Splunk to ingest logs follows a similar path to Elastic — you tell it where to look, what to call it, and how to handle it.

The configuration path in Splunk's web interface:

Settings → Add Data → Monitor → Files & Directories

Settings applied:

• Source: /var/log/auth.log

• Source Type: linux_auth (custom, created to properly categorize authentication log events)

• Host: kali

• Index: default

• Continuously Monitor: Yes

That last setting — Continuously Monitor — is important. It means Splunk doesn't just take a one-time snapshot of the file. It watches for new events in real time, which is what you need for live detection.

Verifying Ingestion

A pipeline that's configured but unverified is a pipeline you can't trust. Lab 21 taught me that lesson the hard way.

I ran a baseline search to confirm events were actually making it into Splunk's index.

Result: 180 events indexed.

Then I ran a targeted search to confirm the SSH brute force events from Labs 13 and 21 were present:

Result: 76 events — all SSH brute force attempts confirmed.

That number matters. 76 events from previous lab simulations, sitting in Splunk's index, immediately available for analysis. The rsyslog fix from Lab 21 wasn't just about closing the Elastic detection gap — it was a prerequisite for everything that comes next in the Splunk series.

One fix. Two SIEMs. Both operational.

What This Lab Actually Taught Me

Installing a second SIEM reinforced something that's easy to read about but harder to internalize until you've done it:

The tool is not the skill.

The ability to configure a log source, verify ingestion, and confirm that the right data is in the index — that process is identical whether you're in Elastic or Splunk. The interface looks different. The search syntax is different. The underlying discipline is exactly the same.

Analysts who understand the pipeline — log source → ingestion → index → search → detection — can work in any SIEM. Analysts who only memorized the clicks in one platform are going to struggle the moment they sit in front of another one.

That's the gap I'm closing with this series.

What's Next

Splunk is running. Logs are flowing. 76 SSH brute force events are sitting in the index waiting to be detected.

Lab 23 is where the detection rules get built — writing SPL queries targeting SSH authentication failures and configuring real-time alerts. Same logic as Lab 12 in Elastic. Different syntax.

Full lab report and documentation on GitHub: github.com/RouteToRoot

Follow the journey:
GitHub: github.com/RouteToRoot
YouTube: youtube.com/@RouteToRoot_Sec
Portfolio: routetoroot.io

I knew the attack happened. The logs confirmed it. But the SIEM never saw it — because the logs that mattered weren't making it into Elastic. I documented the gap, flagged it for remediation, and kept building.

That gap followed me through Labs 14, 15, 16, 17, 18, 19, and 20.

Lab 21 is where it finally gets closed.

What Was Actually Broken

The root cause turned out to be two configuration issues working together to create a complete blind spot.

Kali Linux doesn't install rsyslog by default. Without it, systemd-journald — the logging backend — has no syslog consumer to forward logs to. And without a syslog consumer, no /var/log/auth.log file gets created.

That's the first problem.

The second problem: ForwardToSyslog in /etc/systemd/journald.conf was set to no by default. Even if rsyslog had been installed, forwarding still wouldn't have happened without explicitly enabling it.

The combined effect: SSH authentication failures were being captured in the systemd journal — they existed, they were real, they were verifiable — but they never made it to a file that Elastic Agent could read. Elastic Agent's System integration monitors file-based log sources. No file, no ingestion. No ingestion, no alerts.

The detection rule wasn't broken. The pipeline was.

The Remediation

The fix required two steps: enable syslog forwarding in journald, then install rsyslog to receive it.

Step 1 — Enable ForwardToSyslog

sudo nano /etc/systemd/journald.conf

Changed: ForwardToSyslog=yes

sudo systemctl restart systemd-journald

Step 2 — Install rsyslog

sudo apt install rsyslog -y

Step 3 — Confirm auth.log exists

ls /var/log/auth.log

Output: /var/log/auth.log

That output — /var/log/auth.log — was the moment I knew the fix had worked. The file existed. The pipeline had somewhere to write.

Validating End-to-End Detection

A fix that hasn't been tested is a fix you can't trust.

I ran the same brute force simulation that had produced zero alerts in Lab 13 — ten consecutive failed SSH authentication attempts against the local SSH service using an invalid username:

for i in {1..10}; do ssh -o ConnectTimeout=5 invalid_user@127.0.0.1; done

Then I verified the attack was writing to auth.log:

sudo grep "invalid_user" /var/log/auth.log

Confirmed. Then I went to Kibana Discover and queried for ingested events from the Kali host.

61 documents returned.

Then I checked the Alerts dashboard.

31 alerts fired.

Rule: SSH Authentication Failure Detected. Host: kali. Severity: Medium. Risk Score: 47.

The full pipeline — from attack activity on the host, through rsyslog, into /var/log/auth.log, picked up by Elastic Agent, ingested into logs-system.auth-*, evaluated against the detection rule, and surfaced as an alert in Kibana — was working end-to-end.

Eight labs. One misconfiguration. Thirty-one alerts.

What This Actually Means

There's a lesson here that goes beyond rsyslog configuration.

The detection gap was invisible. The rules didn't error. The agent didn't report a problem. The SIEM dashboard looked normal. Nothing screamed that something was wrong — because a missing log source doesn't generate noise. It generates silence.

And silence in a SOC is dangerous, because silence can look like safety.

In a real environment, this kind of gap could persist for months without anyone noticing. Attackers targeting SSH on Linux hosts would have gone completely undetected. No alerts, no investigation, no response — not because the security team wasn't watching, but because the SIEM was watching the wrong data stream.

The analysts who catch gaps like this aren't the ones who trust the dashboard. They're the ones who run simulations, verify log sources, and treat silence as a signal worth investigating.

That's the work.

The Detection Chain — Fully Validated Step Status SSH brute force executed ✅ Confirmed Events written to auth.log ✅ Confirmed Logs ingested to Elastic ✅ 61 documents Detection rule triggered ✅ Yes Alerts generated ✅ 31 alerts What's Next

The Elastic SIEM phase of the lab portfolio is complete.

Next up: Splunk. Same detection logic, different platform — because real detection engineering isn't about memorizing tool syntax. It's about understanding the pattern underneath it. Platform-agnostic. Threat-focused.

Labs 22–25 build out Splunk detection coverage from scratch. The gap that took eight labs to close in Elastic? We're not making the same mistake twice.

Full lab report and documentation on GitHub: github.com/RouteToRoot

Follow the journey: GitHub: github.com/RouteToRoot YouTube: youtube.com/@RouteToRoot_Sec Portfolio: routetoroot.io

Three prebuilt Elastic rules targeting Linux attack techniques. One custom KQL rule for SSH authentication failures. The pipeline was configured, the rules were live, and the SIEM was watching.

Lab 13 was the moment of truth — run a real attack simulation and see if the detections held up.

They didn't.

The Attack

The setup was straightforward. Start the SSH service on the Kali Linux host, run a brute force loop generating repeated failed authentication attempts against the local SSH service using an invalid username, and watch the Elastic Alerts dashboard for rule triggers.

sudo systemctl start ssh
for i in {1..10}; do ssh -o ConnectTimeout=5 invalid_user@127.0.0.1; done

Ten connection attempts. Three failed password entries per attempt. Thirty total authentication failure events generated on the host.

The attack worked exactly as expected. Confirmation came straight from the system journal:

sudo journalctl -u ssh --since "1 hour ago" | tail -20

The output was unambiguous — invalid user attempts from 127.0.0.1, failed password entries per connection, connection closed entries confirming authentication denial. Thirty failed authentication events, all logged, all verified.

The attack happened. The logs proved it.

The Alerts Dashboard

I pulled up the Elastic Security Alerts dashboard and waited.

Nothing.

Zero alerts. Four rules configured — three prebuilt Elastic rules and one custom KQL rule — and not a single one triggered. The Rule Monitoring tab told the same story: one rule succeeded, three with no response, zero failures, zero errors.

The rules weren't broken. They just hadn't seen anything to alert on.

Finding the Gap

This is where the lab shifted from attack simulation to detection engineering.

When an alert doesn't fire, there are only a few possible explanations. The attack didn't happen. The logs weren't generated. The logs weren't collected. The logs weren't in the right data stream. Or the rule query didn't match the data.

I'd already eliminated the first two — the attack happened and the logs were confirmed in the system journal. So I worked down the chain.

The Elastic detection rules query specific index patterns:

• filebeat-*

• logs-system.auth-*

Neither of those data streams contained the SSH failure events from the Kali host.

Root cause identified: the SSH authentication failure events generated on Kali Linux are stored in the systemd journal and the /var/log/btmp binary log file. The Elastic Agent System integration, as currently configured, wasn't collecting those specific log sources. The agent was enrolled and sending data — just not the right data.

The SIEM had blind spots it didn't advertise.

What the Detection Gap Actually Means

Here's the thing about detection gaps — they're not failures. They're findings.

In a real SOC environment, this is exactly the workflow: simulate attack activity, monitor for alerts, trace the detection chain when alerts don't fire, identify the gap, document it, remediate it. The gap between attack execution and alert generation has to be traced systematically — host logs → agent collection → data stream → rule query → alert. Every link in that chain is a potential failure point.

The fact that I could run the simulation, confirm the attack in host logs, monitor the SIEM, identify zero alerts, and then trace the root cause to a specific log ingestion configuration issue? That's not a failed lab. That's the lab working exactly as it should.

Detection gap documented. Remediation path identified.

What This Taught Me

A SIEM is only as effective as its log sources.

That sounds obvious when you read it. It hits differently when you've just watched thirty brute force events generate zero alerts because the agent wasn't configured to forward the right logs. The detection rule was correct. The attack was real. The gap was a misconfiguration that would have been invisible without running this test.

Real-world SOC environments have these gaps all the time. Misconfigured agent policies, blind spots in log collection, data streams that don't match rule queries. The analysts who find them — by running simulations, tracing detection chains, and documenting what they find — are the ones who actually improve the security posture of their organization.

Documenting a detection gap is as valuable as documenting a successful detection. It demonstrates that you understand the full pipeline, not just the alerts dashboard.

What's Next

The gap is documented. The remediation path is clear.

Lab 14 moves into threat hunting in Kibana — but the SSH detection gap doesn't go away quietly. It follows the lab series for the next several labs until it finally gets resolved.

That resolution is coming. But first, there's more to build.

Full lab report on GitHub: github.com/RouteToRoot

Follow the journey:
GitHub: github.com/RouteToRoot
YouTube: youtube.com/@RouteToRoot_Sec
Portfolio: routetoroot.io

Logs were flowing from my Kali Linux host into Elastic SIEM. The agent was enrolled. The data was real. But a SIEM that ingests logs and does nothing with them is just an expensive storage system.

Lab 12 was where I flipped the switch from passive to active — from collecting data to actually detecting threats.

What Detection Rules Actually Are

Before I get into the lab, it's worth explaining what a detection rule is, because it's one of those terms that sounds more complicated than it is.

A detection rule is a condition. It tells the SIEM: if you see this pattern in the logs, fire an alert.

That's it. The sophistication is in how you define the condition — what data you're looking at, what pattern you're matching, and how you tune the rule to catch real threats without drowning analysts in false positives.

Elastic Security gives you two ways to build detection coverage. Prebuilt rules developed and maintained by Elastic's security team, mapped directly to the MITRE ATT&CK framework. And custom rules you write yourself, tailored to your specific environment.

In Lab 12, I used both.

The Prebuilt Rules: Standing on the Shoulders of Elastic's Security Team

My first move was installing three prebuilt Elastic detection rules targeting Linux-based attack techniques:

• Linux User Account Credential Modification — detects changes to user credentials, a common post-exploitation technique

• Potential Internal Linux SSH Brute Force Detected — flags repeated failed SSH authentication attempts from inside the network

• Potential Linux Hack Tool Launched — identifies execution of known offensive security tools on a Linux host

Each of these rules is mapped to specific MITRE ATT&CK techniques. The SSH brute force rule, for example, maps to T1110 (Brute Force), T1110.001 (Password Guessing), and T1110.003 (Password Spraying). That mapping matters because it gives analysts immediate context when an alert fires — not just what happened, but where it fits in the attacker's playbook.

Installing prebuilt rules is straightforward. You navigate to the Detection Rules section in Elastic Security, browse the rule library, and enable the ones relevant to your environment. Three clicks and you have enterprise-grade detection logic written by people who track real threat actors for a living.

That's not something to take lightly.

The Custom Rule: Writing My First KQL Detection Logic

Prebuilt rules cover common attack patterns. But every environment has unique characteristics that prebuilt rules can't anticipate. That's where custom rules come in.

For Lab 12, I wrote a custom rule to detect failed SSH authentication attempts on my Kali Linux host using KQL — Kibana Query Language. KQL is Elastic's search syntax, and it's readable enough that you can understand what a query is doing even if you've never written one before.

The rule settings:

• Name: SSH Authentication Failure Detected

• Severity: Medium

• Risk Score: 47

• Rule Type: Custom Query

• Query Language: KQL

The query targets authentication events where the outcome is a failure — specifically catching the pattern of repeated failed login attempts that characterizes a brute force attack.

Writing this rule taught me something that reading about KQL never would: the query has to match the data that's actually in your environment. If your log source isn't structured the way your rule expects, the rule won't fire — even if the attack is happening. The rule is only as good as the data behind it.

Testing the Rules: Simulating an SSH Brute Force Attack

Rules that have never been tested are rules you can't trust. So I ran a simulation.

Using the Kali Linux host, I generated repeated failed SSH authentication attempts against the local SSH service:

sudo systemctl start ssh
ssh invalid_user@127.0.0.1

Multiple failed attempts. Multiple invalid users. The kind of activity that, on a real network, would indicate someone systematically trying to guess their way into a system.

Then I went to the Elastic Security Alerts dashboard and waited.

The rules fired.

Not all of them — and that matters, which is exactly what Lab 13 is about. But the detection logic was working. The pipeline from attack activity to log ingestion to rule evaluation to alert generation was intact.

That's a working SOC detection workflow, built from scratch.

What This Lab Actually Taught Me

Detection engineering is about more than writing queries. It's about understanding the relationship between attacker behavior, log data, and detection logic — and knowing where that chain can break.

A few things that landed differently after doing this hands-on:

MITRE ATT&CK isn't just a framework for reading. When you see your own detection rules mapped to T1110 and its sub-techniques, the framework stops being abstract. It becomes a practical tool for understanding what you're detecting and what gaps you still have.

Prebuilt rules are a starting point, not a finish line. They give you solid baseline coverage fast. But real detection engineering means understanding your environment well enough to write the rules that prebuilt libraries don't cover.

Rule tuning is the real work. Getting a rule to fire is easy. Getting it to fire on real threats without burying your analysts in noise is the skill that separates good detection engineers from great ones.

What's Next

The rules are configured. The simulation ran. Some alerts fired.

But not all of them — because there was a detection gap I didn't know about yet. One that would take eight more labs to find and fix.

That's Lab 13.

Full lab report and documentation on GitHub: github.com/RouteToRoot

Follow the journey:
GitHub: github.com/RouteToRoot
YouTube: youtube.com/@RouteToRoot_Sec
Portfolio: routetoroot.io

August 2026's Patch Tuesday was a big one.

421 CVEs patched across Microsoft's product lineup. 62 rated critical. And one — CVE-2026-68820, an elevation of privilege vulnerability in the Windows kernel — was already being actively exploited in the wild before the fix even shipped.

That's not a drill. That's a zero-day.

The patch doesn't protect you the moment it drops

Here's what most people outside of security don't fully appreciate: releasing a patch and deploying a patch are two completely different things.

Between the moment Microsoft publishes a fix and the moment that fix is actually running on every endpoint in your environment, there's a window. And that window — however long it lasts — is exactly where attackers operate.

For large enterprises, that window can stretch days, weeks, or longer. Patches have to be tested against production systems, prioritized by severity, scheduled around maintenance windows, and pushed across potentially thousands of endpoints without breaking anything.

421 patches. One month. That's the reality of vulnerability management.

This is a GRC problem, not just an IT problem

Vulnerability management lives at the intersection of technical controls and governance. It's not enough to know a patch exists — organizations need:

• A process for ingesting and triaging CVEs by severity and exploitability

• Defined SLAs for how fast critical patches must be deployed

• Accountability structures to ensure patches actually get applied

• Audit trails to prove compliance to regulators and auditors

Without that governance layer, even the best technical teams end up playing whack-a-mole. Patch management without policy is just hope.

What I'm building toward

I'm currently working through my cybersecurity lab portfolio — 29+ labs covering Elastic SIEM, Splunk, Microsoft Sentinel, Nessus, and more. My Nessus labs focus specifically on vulnerability scanning and prioritization — identifying exposures, scoring them by risk, and thinking through remediation workflows.

That hands-on work is teaching me what Patch Tuesday makes obvious every month: defenders don't have unlimited time, and neither do organizations. Prioritization isn't optional. It's survival.

421 CVEs. One already exploited. The clock is always running.

🔗 Explore my full lab portfolio: routetoroot.github.io

SIEM — Security Information and Event Management — shows up in almost every SOC job description. It's the platform analysts live in. The place where logs flow in, alerts fire, and investigations begin. I knew what it was conceptually. But knowing what something is and actually deploying one are two completely different things.

Lab 11 was the day I stopped reading about it and started building.

What I Was Setting Up

The goal was straightforward on paper: deploy Elastic Cloud Serverless SIEM, enroll an Elastic Agent on my Kali Linux host, and confirm that logs were actually flowing into the platform.

Three steps. One outcome — a working SIEM pipeline.

What nobody tells you before you start is that "straightforward on paper" and "smooth in practice" rarely mean the same thing in a lab environment.

Step 1: Standing Up Elastic Cloud Serverless

Elastic offers a free cloud trial that's more than enough to get a functional SIEM environment running. The Serverless option is the right choice for a home lab — no infrastructure to manage, no Elasticsearch cluster to babysit. You spin up a Security project, and Elastic handles the backend.

The setup process itself is guided. You create an account, start a new Security project, and land in Kibana — Elastic's web interface where everything lives. The dashboard is clean and purpose-built for security work. Integrations, detection rules, alerts, and the Discover interface for raw log querying are all right there.

First impression: this is a real tool. Not a toy, not a simplified student version. The same platform security teams use in production environments.

Step 2: Enrolling Elastic Agent on Kali Linux

Elastic Agent is the component that actually collects logs from your host and ships them to the SIEM. Getting it enrolled on my Kali Linux machine was the most technically involved part of the lab.

The process runs through Kibana's Fleet interface — Elastic's agent management console. You create an agent policy, download the agent package for Linux, and run an enrollment command that registers the agent with your cloud instance.

The enrollment command looks something like this:

sudo ./elastic-agent install \
  --url=<your-fleet-server-url> \
  --enrollment-token=<your-token>

Once that runs successfully, the agent shows up as enrolled in Fleet. Green status. Connected.

That moment — watching the agent appear as active in the console — is one of those small wins that feels bigger than it probably should. Because it means the pipeline is alive. Data is moving.

Step 3: Confirming Log Ingestion

The final step was verifying that logs from the Kali host were actually arriving in Elastic. This is where a lot of first-time setups fall apart — the agent enrolls, but the data doesn't flow the way you expect.

In Kibana's Discover interface, I queried for events from the enrolled host and confirmed that system logs were coming through. The timestamps were current. The host name matched. The data was real.

Pipeline confirmed.

What This Lab Actually Taught Me

Setting up a SIEM from scratch teaches you something that reading about SIEM never does: you learn where the data actually comes from.

It's easy to think of a SIEM as a magic box that knows everything happening on your network. It's not. It only knows what you tell it. Every log source has to be explicitly configured. Every agent has to be enrolled. Every data stream has to be verified.

The intelligence of a SIEM is only as good as the instrumentation behind it. And the analyst who understands that — who knows not just how to query the data but where the data comes from and why it might be missing — is going to be more effective than one who just knows how to run searches.

That lesson was worth more than the lab itself.

What's Next

Lab 11 got the pipeline running. Lab 12 is where things get interesting — that's where I started building detection rules. Taking a live SIEM with real log data and teaching it to recognize an attack.

That's the post coming next.

If you want to follow along with the actual lab work, the full documented report is on my GitHub: github.com/RouteToRoot

Follow the journey:
GitHub: github.com/RouteToRoot
YouTube: youtube.com/@RouteToRoot_Sec
Portfolio: routetoroot.io

"SOC analyst or GRC analyst — whichever one hires me first."

That usually gets a laugh. But the truth is more nuanced than that, and I think it's worth laying out publicly — because if you're a career-changer trying to break into security, you've probably hit this same fork in the road.

Two paths. Both legitimate. Both in demand. And just different enough that the wrong choice could mean spending years doing work that doesn't fit you.

So here's how I'm thinking about it.

First, What Are We Actually Talking About?

SOC Analyst (Security Operations Center) is the hands-on, real-time side of security. You're monitoring alerts, investigating incidents, triaging threats, and responding when something goes wrong. The job rewards fast thinking, pattern recognition, and comfort with ambiguity. You live inside tools like Elastic SIEM, Splunk, and Microsoft Sentinel.

GRC Analyst (Governance, Risk, and Compliance) is the strategy and structure side. You're building frameworks, assessing risk, managing audits, and making sure the organization meets its compliance obligations — think NIST, ISO 27001, SOC 2, HIPAA. Less about chasing alerts, more about building the systems that prevent problems in the first place.

Both roles matter. Both are hiring. And they require more overlapping skills than most people realize.

Which Role Does My Background Map To Better?

This is where it gets interesting — because the honest answer is both, for different reasons.

My trucking background maps to GRC almost perfectly. Risk management, vendor assessment, documentation, audit readiness — I did all of that running Mud Mule LLC. I just didn't have the framework or the vocabulary. When I started studying GRC concepts, I kept having the same reaction: I've done this. I just called it something else.

But my lab work pulls me toward SOC. Twenty-nine labs deep, I've spent the most time in SIEM tools — building detection rules, analyzing logs, investigating simulated incidents, writing Python scripts to automate alert triage. That's SOC muscle memory. When an alert fires in a lab environment and I start working through it methodically, something clicks in a way that feels right.

So my background says GRC. My hands say SOC.

That's not a contradiction — it's actually an asset. It means I can speak both languages, which makes me useful in roles that sit at the intersection of the two.

So What's the Gut Feeling?

If I'm being honest — and this whole blog is about being honest — I think I'm a SOC analyst who will eventually move into GRC.

The hands-on work energizes me. I like being in the terminal. I like the puzzle of an alert that doesn't make sense until suddenly it does. I like building detection logic and watching it catch something it was designed to catch.

But I also know that the skills I built in a decade of running a business aren't going away. At some point, the experience I have managing operational risk, dealing with vendors, and keeping meticulous records is going to be exactly what a GRC team needs.

For now, I'm keeping both doors open. Applying to SOC roles. Studying frameworks that matter for GRC. Building a portfolio that speaks to both.

What This Means If You're In the Same Position

Don't let the decision paralyze you. Both paths lead somewhere good. The worst thing you can do is spend six months agonizing over which role to pursue instead of building the skills that make you competitive for either one.

Figure out which work actually energizes you when you do it. That's your signal.

Study the fundamentals that apply to both — networking, log analysis, risk concepts, the major compliance frameworks. Security+ covers a lot of this ground intentionally.

And keep your options open until the market gives you feedback. Your first job in security probably won't be your last, and the skills transfer more than you think.

The route matters less than staying on it.

Follow the journey:
GitHub: github.com/RouteToRoot
YouTube: youtube.com/@RouteToRoot_Sec
Portfolio: routetoroot.io

Every morning started with variables I couldn't control. Fuel prices spiked overnight. A load that was confirmed yesterday got cancelled this morning. A tire blew out somewhere in the middle of nowhere at 2 AM. And somewhere in all of that, I still had to make payroll, keep the equipment moving, and make decisions — fast, with incomplete information.

I didn't know it at the time. But I was training for cybersecurity.

The Trucking Industry Doesn't Forgive Sloppy Risk Management

When you're running a commercial trucking operation, every decision is a risk calculation — whether you frame it that way or not.

Do you take a load that pays well but routes through a state with strict weight limits and aggressive DOT inspectors? Do you run a truck that's showing early warning signs, or do you pull it and eat the downtime? Do you lock in a contract rate or stay spot market and gamble on freight demand?

None of those decisions have a clear right answer. They all depend on your current exposure, your margins, your tolerance for downside risk, and what you know about the variables in play.

Sound familiar?

In GRC — Governance, Risk, and Compliance — that's the entire job. You assess risk. You weigh likelihood against impact. You make recommendations knowing that no environment is zero-risk, and that the goal isn't to eliminate risk, it's to manage it to an acceptable level.

I spent nearly a decade doing exactly that. I just didn't have the vocabulary for it yet.

When Things Break, You Don't Get to Panic

There's a moment every owner-operator knows. Something goes wrong — really wrong — and every instinct you have wants to spiral. But you can't. Because panicking doesn't fix the truck, and it doesn't get the load delivered.

You stop. You assess. What do I actually know right now? What's the immediate impact? What needs to happen in the next ten minutes, and what can wait?

That mental process — triage under pressure — is exactly what a SOC analyst does when an alert fires at 11 PM on a Friday.

You don't know yet if it's a false positive or a live incident. You don't know the scope. You don't know if someone is actively moving through the network or if a misconfigured rule threw a flag. What you do know is that spiraling wastes time, and time is the one thing you can't recover.

The ability to stay calm, work the problem methodically, and communicate clearly under pressure isn't something you learn in a classroom. I learned it on the side of a highway waiting for a mobile mechanic, trying to figure out how to salvage a load that was already running late.

Vendor Trust Is a Security Problem Too

Running a trucking company means managing relationships — brokers, shippers, fuel card providers, maintenance shops, insurance carriers. And one of the hard lessons you learn early is that not every party in your supply chain has your best interests in mind.

Brokers low-ball rates and bury fees in the fine print. Shippers misrepresent load weights. Third-party maintenance shops cut corners you won't discover until something fails on the road.

In cybersecurity, we call that the third-party risk problem. Your organization's security posture is only as strong as the weakest link in your vendor ecosystem. A trusted software provider with a compromised update pipeline can be your worst nightmare — and you let them in.

I already knew, viscerally, that "trusted" isn't the same as "verified." I'd just never heard the term supply chain attack before.

Logs, Records, and the Paper Trail That Saves You

If there's one discipline that trucking and cybersecurity share completely, it's documentation.

In trucking, your logbook is everything. Hours of service, inspection records, bills of lading, maintenance logs — all of it has to be accurate, timestamped, and audit-ready. Because when something goes wrong — an accident, a DOT audit, an insurance dispute — the paper trail is either your best defense or the thing that buries you.

In security, logs are your ground truth. SIEM tools like Elastic and Splunk exist because without a reliable, timestamped record of what happened on your network, you're flying blind. Detection is only possible if you collected the right data. Investigation is only possible if the logs weren't tampered with. Attribution is only possible if the chain of evidence holds.

The mindset is identical: document everything, because you don't know which record will matter until you need it.

The Skills Were Always There

Here's what I want other career-changers to hear.

You probably have more relevant experience than you think. The gap isn't your intelligence or your capability — it's vocabulary and technical depth. Both of those are learnable. You close them with study, labs, and time.

The instincts that come from running a business, managing real risk, working under pressure, and building trust in high-stakes environments? Those aren't learnable from a textbook. Those come from doing hard things for a long time.

I spent eight years building them without realizing what I was building.

Now I'm here — 29 labs deep, Security+ in progress, portfolio growing at routetoroot.github.io — and for the first time in a long time, the work feels like mine.

The route was longer than I expected. But I was more prepared for it than I knew.

Follow the journey: GitHub: github.com/RouteToRoot YouTube: youtube.com/@RouteToRoot_Sec Portfolio: routetoroot.io

I want to be honest with you from the jump.

I didn't come from a tech background. I don't have a Computer Science degree. I didn't start coding at 12. I wasn't the kid taking apart computers in the garage.

For nearly a decade, I ran a trucking company. Mud Mule LLC. I was the owner, the operator, the dispatcher, the accountant, and half the time, the driver. I built something from nothing with my own hands, and for a long time, that was enough.

Then it wasn't.

The Honest Truth About Why I Left

The trucking industry grinds you down in ways that are hard to explain unless you've lived it. You're always chasing the next load, the next contract, the next check. You're away from home more than you're in it. You're at the mercy of fuel prices, freight rates, broker margins, and a dozen things you can't control.

My company was struggling. I was tired — not the kind of tired that sleep fixes. The kind that comes from spending years building something that owns you more than you own it.

I needed out.

But here's the thing. Knowing you need to leave and actually leaving are two completely different things. Because the moment you start thinking about walking away, a voice in your head starts talking.

You're too old for this.
You don't have the education.
You have no experience in tech.
Who do you think you are?

I had been interested in cybersecurity and technology for almost eight years. Eight years of reading articles, watching videos, being fascinated by how systems work and how they break. Eight years of telling myself it was just a hobby. Eight years of talking myself out of pursuing the one thing that actually excited me.

I was my own worst enemy.

The Day Everything Changed

There wasn't a dramatic moment. No single event that flipped a switch.

I just got tired of being my own hater.

One day I decided — enough. I was going to be my own biggest fan instead. I was going to pursue this like I had nothing to lose, because honestly? At that point, I didn't.

I went all in.

I started studying. I built a home lab. I started doing hands-on cybersecurity exercises. I completed lab after lab — packet capture, network analysis, SIEM deployment, threat hunting, GRC compliance. Twenty-nine labs and counting, all documented, all evidence-based, all real.

I built this brand — RouteToRoot — because the name says everything about where I'm going. You follow the route until you reach root. You follow the path, however long it takes, until you get there.

What I Want You to Take From This

If you're reading this and you're in a similar place — stuck in something that's draining you, interested in cybersecurity but convinced you're too old, too inexperienced, too late — I want to tell you something.

You're not.

I'm building this in public so you can see every step. The labs. The certifications. The job search. The wins and the setbacks. All of it.

This blog is where I document the route. Every tool I learn, every vulnerability I analyze, every CTF I work through, every concept that finally clicks — it goes here.

You're not watching someone who already made it. You're watching someone make it in real time.

Welcome to RouteToRoot.

Follow the journey:
GitHub: github.com/RouteToRoot
YouTube: youtube.com/@RouteToRoot_Sec
Portfolio: routetoroot.io