That gap bothers me, because the practice is spreading fast inside real security teams. The discipline is ahead of its own content. So instead of writing another explainer from the outside, I went to the people doing the work.

This guide is built from long-form conversations I had on the Cyber Stories Podcast with two practitioners who shaped how I think about this space:

• Ayoub Fandi, GRC Engineer at Lovable. Ayoub co-authored the GRC Engineering Manifesto and hosts the GRC Engineering Podcast. His path runs through Big Four consulting, a startup, Salesforce, and GitLab, where he was a Staff Security Assurance Engineer when we spoke.

• Izzy Vixsama, a staff-level GRC professional at Datadog. Izzy has spent over a decade in information security, working at the intersection of cloud, compliance, and engineering teams.

I added my own experience from years in security engineering, building automation so humans wouldn't have to do repetitive work by hand.

What follows is curated, not transcribed. I organized their ideas into one path: what GRC is, how GRC engineering is changing, what software can and cannot automate, and how to build a career in it.

Share

Subscribe now

Part 1: What GRC Actually Is

Before engineering anything, it helps to understand the job.

Ayoub describes GRC as “the conduit between the business and security [and] the engineering org.” It sits between engineering, corporate security, legal, HR, finance, leadership, and the board’s audit committee. Engineering thinks in sprints and releases. The business thinks in quarters. GRC has to speak both languages.

That makes the skill set unusual. In Ayoub’s words, you need to be “an inch deep but a mile wide.” You do not need to be the deepest expert in every area. You need to understand enough of each to connect them.

Done well, that position gives GRC real leverage. When a security team wants to enforce MFA, add scanning, or put controls on incoming merge requests, GRC can help “win those battles” by tying the request to business impact: a customer deal, a certification renewal, a real risk to the company.

Why GRC got a nontechnical reputation

Many engineers think GRC is paperwork. Ayoub is honest about why. Audits can feel like check-the-box exercises. An audit might cover a narrow slice of the company while the certification gets presented under the whole company’s name. Engineers know the critical systems with the real problems, like unencrypted S3 buckets or keys that never rotate, and they watch the auditor ask about something else. It is easy to conclude the whole function has nothing to say about security.

Izzy pushes back on the idea that GRC means nontechnical. She describes a spectrum:

• People who are hands-on keyboard

• People who used to be hands-on keyboard and now translate technology into strategy

• People who are not hands-on keyboard but understand how information flows, what users need, and how systems operate

“You really have to understand where you fit in that spectrum and then how you enable compliance will kind of naturally flow.” Izzy Vixsama

When Izzy got access to an AWS account, she went into the console and started looking at S3 bucket configurations. She looked at how often teams committed code and how often scans ran. She was not building those systems. She wanted to understand them well enough to make better recommendations. That curiosity is the bridge into GRC engineering.

Why GRC is becoming more technical

The cloud changed the ground under compliance. Static perimeters and fixed IP allowlists gave way to dynamic IPs, short-lived instances, Terraform, and Helm charts. Frameworks like ISO have updated to emphasize cloud environments, and auditors have had to follow suit.

Izzy frames cloud risk plainly: moving to the cloud is not inherently riskier. “It’s the same risk. You just either transfer it to someone else or you are choosing to ignore the risk.” The shared responsibility model still applies. The provider secures the cloud. You secure what you put in it. And somebody still has to govern, assess risk, and prove compliance.

“As a security professional you should trust and verify, but you should still move forward in the direction that technology is taking you.” Izzy Vixsama

Part 2: What GRC Engineering Is

GRC engineering is what happens when you apply real software engineering practices to governance, risk, and compliance. You encode controls as automated tests. You run them continuously instead of once a year. You plug compliance checks into the systems your engineering team already uses.

Ayoub breaks it into two goals.

Goal 1: Make GRC more effective

Traditional GRC tests controls once a year, every six months, or every quarter. GRC engineering aims for real-time data on control health and risk posture, with alerts when a control stops working. That applies even when a certification does not explicitly require continuous monitoring. The point is knowing, not passing.

Ayoub describes the end state as a “Minority Report dashboard”: one view across application security, vulnerability management, and every other function, showing what is healthy and what is drifting.

Goal 2: Integrate GRC with engineering

Most GRC teams only talk to engineering during audit season. GRC engineering puts compliance inside engineering workflows instead.

This is where policy as code comes in. Tools like Open Policy Agent let you express a control as a machine-checkable rule. Ayoub’s example: a control that verifies SAST runs in every CI build. The check does not have to block the build. It can simply record a violation when SAST did not run. Over time, those violations show you patterns, and patterns tell you whether you have a people problem or a process problem.

The same idea extends to governance. Policies can live in Markdown in a Git repository, so every change has a history, a reviewer, and a reason.

Checks do not have to block. Sometimes the most useful thing a control can do is tell you, honestly, how often it fails.

Where it is today

When we spoke, while Ayoub was still at GitLab, he estimated the companies doing this seriously could be counted on two hands, with teams at places like Netflix leading the way. He called GRC engineering “just the beginning.” If you think you missed the window, you did not. The manifesto lives at grc.engineering, and it accepts pull requests.

Part 3: Five Questions to Ask Any GRC Platform

A lot of software now says it “automates compliance.” I went deep on this in my video GRC Engineering Explained: What GRC Software Actually Automates (and What It Doesn’t), which uses Vanta as a worked example of a modern compliance automation platform. If you want to see these ideas applied to a real product, start there. Here are the five criteria from that guide that I use to separate real GRC engineering from a compliance checklist with a nicer interface.

1. Is it continuous, or point-in-time?

If you have ever owned a SOC 2 audit, you know the old way. Inventory every resource. Screenshot a setting to prove it was configured correctly on the day someone asked. Do it again next quarter, because a January screenshot proves nothing about April.

A real GRC engineering setup runs automated tests against connected systems on a continuous schedule, often hourly. When a passing control starts failing, say a security setting gets reopened by accident, you hear about it within the hour, not at the next audit.

Ask: Is it actually watching, or is it a nicer spreadsheet?

2. How deep does the coverage go?

Plenty of tools technically “integrate” with your cloud provider but only check a handful of surface-level settings. The real test is whether the checks map to something you would actually be audited against. For AWS, that usually means the CIS AWS Foundations Benchmark, the same reference an outside auditor would recognize.

Ask: Does it map what it finds to a benchmark someone outside the company would recognize?

3. Does evidence work across frameworks?

Most companies do not stay on one framework forever. You start with SOC 2 because a customer asks. Eighteen months later, someone asks about ISO 27001 or HIPAA, or an EU customer brings up GDPR. If your tooling only speaks one framework, you rebuild your evidence trail every time.

Good GRC engineering treats evidence as reusable. The same connected accounts and control tests should map across SOC 2 Type II, ISO 27001, HIPAA, GDPR, NIST CSF, and CMMC.

Ask: If I add a framework next year, do I have to start over?

4. How much of the real work gets automated?

This is where the category has moved most in the last year or two. Automation used to mean testing. Now some platforms use AI agents for the busywork around the testing:

• Policy drafting. An agent asks how your business actually operates and drafts a policy that fits, instead of handing you a generic template.

• Trust centers. Instead of answering the same 50 questions from every prospect’s procurement team, you point them to a public page that already holds the proof.

• Vendor risk. Instead of someone reading forty pages of a vendor’s SOC 2 report every time the company adopts a tool, an agent reviews documentation, assigns a risk score, and recommends a decision.

Ayoub described that vendor problem well. For “99% of companies,” third-party risk still means sending a questionnaire, checking whether the vendor uses SSO, and approving. He sees the future as connecting to vendors through APIs and monitoring their controls in real time, with alerts when something important stops working.

Notice the word “recommends.” You still make the final call. The agent removes the reading, not the responsibility.

Ask: Does “automation” only mean running tests, or does it also cover the paperwork?

5. What does it say it does not do?

This matters most if you are going to rely on a platform. Software does not replace a compliance team.

Genuinely automatable in a mature setup:

• Discovering resources in your cloud accounts

• Running control tests continuously

• Collecting evidence the moment something passes

• Flagging drift the instant a passing control fails

• Drafting a first version of a policy

• Scoring vendor risk from their own documentation

Not automatable, and probably never should be:

• Writing and approving the actual security policies. An AI draft is a starting point, not a final answer.

• Real risk assessments. The judgment about what matters to your specific business.

• Vendor due diligence conversations, still between humans.

• Accepting an exception when a control fails, and defending that decision to an auditor.

Ask: What does it say, out loud, that it does not do? If the answer is “nothing,” be skeptical.

Part 4: The Trap Nobody Talks About

Ayoub raised something that stuck with me. Automation has a hidden cost.

When GRC teams were small, and everything was manual, they had to build relationships with product and engineering. You had to sit with the infrastructure team to understand how encryption actually worked. Connectors & MCPs change that. You can now pull data from Slack, GitHub, and AWS without talking to anyone.

The problem is that connector data gives you a baseline, what Ayoub called the “lowest common denominator” view of security. It tells you whether a setting is on. It doesn't explain why a 15-year-old Oracle database cannot be replaced, or which architectural tradeoff makes a particular vendor dangerous for your company.

Izzy says the same thing from the other direction. Security works as a partnership, not a dictatorship. Understanding what a team is trying to accomplish and applying a security lens to it “is going to be a hundred times more successful” than dictating. Some requirements are firm. Many only say what must be achieved, not how, and that is where GRC earns its seat by finding a path that satisfies the control without getting in engineering’s way.

Automation should buy you time for relationships, not replace them.

Ayoub’s framing is the right one: “winning time on low leverage activity so you can spend time on high leverage where cognitive ability makes sense.” Automation is coming for GRC. The first result should be more interesting work, not fewer people.

Part 5: How to Get Into GRC Engineering

Ayoub and Izzy came from very different places. Ayoub studied economics and linguistics and wrote a master’s thesis on how the YouTube algorithm polarized politics. Izzy studied business management and finance, spent six months in finance, hated it, and ended up doing risk assessments and building automated vulnerability reports at a major bank. Neither followed a straight line. Here is what they would tell you.

Decide whether GRC fits you

Izzy is direct: “Just because you want to do GRC doesn’t mean you’re going to be good at it.” Before committing, ask what you want your days to look like. Do you like meetings? Documentation? Audits? Strategy? Technical investigation?

Be realistic about the early years too. “In your first five years you might not be on that strategy track.” Expect a lot of documents, audit support, and policy work before the interesting strategic problems show up.

Pick your environment carefully. Izzy’s line: “If you do GRC for an old, archaic company, it’s 100% going to be boring.” GRC at a company shipping a new product every six weeks is a completely different job.

Learn frameworks, but think in control objectives

“You can’t be a GRC professional and not know anything about a framework,” Izzy says. “That’s literally our bread and butter.” She recommends starting with SOC 2 and ISO because they are non-prescriptive. They tell you what to achieve, not how, which leaves room to learn.

Ayoub adds the key shift: do not try to memorize every control in ISO or NIST 800-53. Start at a higher level, like the NIST Cybersecurity Framework. Take one control, look up what it means, and understand what problem it is trying to solve.

“Instead of thinking controls, think control objectives.” Ayoub Fandi

Izzy describes the core skill as translating “lawyer speak” into real-world applications. A control that says a system must have a mechanism to determine vulnerabilities really means you need a scanner, a process for finding vulnerabilities in your code, and a way to prove both.

Build technical fundamentals

Izzy’s list: networking fundamentals, how a basic computer works, the OSI model, TLS and data in transit, load balancing, proxies, vulnerability scanning, cloud configuration, and how repositories and scanning pipelines work. “How do you know what you’re securing if you don’t know what the OSI model is?”

Learn to script

Ayoub’s argument for coding is simple. User interfaces lie about what a system can do. With APIs and SDKs, you can do “a hundred times more than what you see in the UI.” Development experience also teaches you how software is actually built: Git, CI/CD pipelines, Markdown documentation, and machine-readable policies. That is the native language of GRC engineering.

The combination of software engineering and GRC is still rare. Ayoub calls it a “unicorn profile.” Many people leading the field come from detection and response, security operations, AppSec, or infrastructure security, not audit. If that sounds like your background, you are closer than you think.

Build something you can show

Both of them push hands-on work. Ayoub points to the Cloud Resume Challenge and its security-focused variant: build a small cloud environment, implement specific controls, and write about how you did it. Even hosting a blog and documenting how you secured it counts. Izzy’s version: “Get you a lab. Actually build a lab.” Start small.

A homelab is the perfect sandbox for GRC engineering. Pick a framework control, implement it, write a policy-as-code check for it, and track when it fails. That is a portfolio piece most applicants will not have.

Make a realistic plan

Izzy has seen too many learning plans that try to cover GRC, SOC work, pentesting, vulnerability scanning, and network engineering in nine months. “This is like seven jobs.” Pick a target role and build toward it over six months, nine months, or longer.

Keep certifications in perspective. The CISSP is not an entry-level cert. You need five years of experience to earn it, regardless of when you pass the exam. And be honest about pay. Izzy warns that entry-level offers can be closer to $45,000 than the six figures some people promise.

You do not need to spend much to learn. Google, YouTube, and Udemy go a long way. But if you skip structured programs, you have to supply the discipline yourself.

Build relationships, not follower counts

Izzy’s advice on mentorship is blunt: “Don’t just follow me on LinkedIn and immediately ask me to be your mentor because the answer is always going to be no. I don’t know you.” Know what you want, why you want it, and what specific help you need before you ask anyone.

Part 6: Growing Into Staff Level

Both guests hold staff-level roles, and they described the same shift.

At staff level, nobody tells you what to work on. Ayoub says you should have enough context, relationships, and experience to find important problems that aren't obvious or assigned. There is always more work than people, so you delegate important but noncritical work and mentor others through it, even when you could do it faster yourself.

Izzy describes her staff work as process improvements that benefit everyone: making security more visible and more effective, and helping engineering teams work more cohesively with security. “You are not responsible for any of the actual work, but you can kind of influence and guide the direction that the work goes.”

That is what GRC engineering looks like at its best. Not a person with a spreadsheet, and not a platform on autopilot. A systems thinker who uses automation to see clearly and relationships to act on what they see.

But 2026 isn’t the environment I came up in, and if I were 18 again walking into my first semester, I’d do this very differently.

Three things changed. More people hold a degree and a Security+ than there are entry-level seats for them. AI is already doing a chunk of what used to be somebody’s first job: summarizing logs, writing basic scripts, drafting first-pass triage. And the biggest threat to actually building skill now isn’t a lack of resources. It’s your attention.

Also, my goal wouldn’t be to graduate with a degree. It would be to graduate with four years of evidence, starting week one, that I belong in this industry.

I wouldn’t assume I need a cybersecurity degree

I’d be choosing one of three degrees: Computer Science, IT or Information Systems, and Cybersecurity. All three get you here. The real question is what foundation you want underneath security.

CS goes deeper on programming, algorithms, data structures, and computing theory. IT puts you on the systems side: networking, operating systems, infrastructure, cloud, server administration. Cybersecurity programs give you a security-focused curriculum from day one.

I did IT, and that systems foundation has been immensely useful because security engineering is still engineering. You can’t investigate a Linux server without understanding Linux. You can’t analyze network traffic without understanding networking. You can’t secure AWS if you’ve never deployed anything to it. However, I had to learn to code on my own.

There’s a newer wrinkle too. AI writes code, generates configs, and explains concepts faster than almost any professor. Genuinely useful. It also means the value isn’t in memorizing syntax anymore. It’s in understanding systems well enough to know when the AI system is wrong. In security and compliance work, being confidently wrong about a control is how you get breached, not just how you get a bad grade.

So I wouldn’t ask whether the degree says cybersecurity. I’d ask what I’ll actually know how to do when I finish it.

I’d weigh the boring stuff seriously, too: cost, flexibility, the real curriculum, and whether the school is thinking about what happens after graduation or just during it.

Freshman year: apply before you feel ready

This is the one part of my own story I’d repeat exactly, and lean into harder.

I got my first internship freshman year at a company called BenefitMall. Not by applying to Amazon or Google. I got it by applying to smaller local companies after getting turned down everywhere else. By sophomore year, I had a cybersecurity engineering internship offer from Intel in June, two months before the start date, after people told me it was already too late to try.

Most advice says spend years one and two getting ready, then chase internships junior year. In 2026, I think that’s dangerous. If the entry-level market is already tight and AI is already absorbing the easiest first-job tasks, waiting two years to build verifiable experience means starting the race two years behind.

So freshman year I’d do two things at once, not in sequence.

• Learn fundamentals. Networking, Linux, Windows, basic programming, Git. How operating systems work. What DNS actually does. What happens when two computers talk to each other. Processes, permissions, authentication.

• Apply that same semester. Help desk, sysadmin, cloud, networking, anything that puts me around real infrastructure. You are never going to feel ready. I didn’t. You get the internship first, and the readiness catches up.

And alongside both, a homelab. VirtualBox, VMware, Proxmox if I have spare hardware. A Linux box, a Windows machine, maybe a Windows Server. I’d break things on my own time and figure out how to fix them.

I broke down the full internship strategy (resume, technical prep, timing, target companies, interviews) here:

Sophomore year: the lab becomes cyber-focused

Ideally, I’m interning again with more responsibility, and layering security onto that IT base. How Active Directory works and how attackers abuse it. What an EDR actually sees. What gets logged when someone authenticates. What malicious PowerShell looks like next to normal PowerShell.

That’s when the IT lab turns into a real security lab. Deploy Wazuh, Splunk, or Security Onion. Collect Windows logs with Sysmon and Linux logs alongside. Generate telemetry, attack your own environment, then go look at it from the defender’s chair.

This is also where I’d use AI deliberately: explain a concept I’m stuck on, debug a script, quiz me on what I just learned. Not generate a detection rule without understanding.

If you can’t explain what the AI gave you, you haven’t learned anything. You’ve outsourced the exact part of the job that was supposed to make you employable.

Certifications, with receipts attached

Somewhere in year one or two: Security+, maybe Network+ if networking is shaky, maybe a cloud cert.

I made this mistake myself. It’s easy to get addicted to collecting them. Every “congratulations, you passed” screen feels like progress, and it is. But passing an exam proves you can pass that exam. AI has made cramming multiple-choice easier than ever, so a cert alone tells an employer less than it did five years ago.

Certs support learning; they don’t replace it. Security+? Put a project next to it. AWS cert? Show me what you built in AWS.

The fight that runs all four years

When I was in school, there were distractions, but they weren’t engineered against me the way they are now. Short-form video, endless feeds, notifications, all designed to fragment your attention into smaller pieces.

The skills that matter here require the opposite. Reading logs carefully. Following a chain of reasoning through an investigation. Sitting with a problem you don’t understand yet. Sustained, boring, uninterrupted focus.

So I’d treat homelab time like a class I can’t skip. Phone in another room, one task, a timer if needed. And I’d be honest about the difference between learning and consuming content about learning. A two-hour video on AD attacks feels productive. Two hours building and attacking your own AD, getting it wrong four times before it works, is productive.

Everyone has the same tutorials and the same AI now. The differentiator isn’t access to information. It’s who can sit still long enough to use it.

Years two and three: pick a direction

Cybersecurity isn’t one job. Detection engineering, cloud security, AppSec, pentesting, security engineering, incident response, threat intel, GRC, identity. At some point you have to go deeper.

I didn’t start in detection engineering. I started in a SOC on tier-one alerts and worked my way in. Picking a direction doesn’t mean landing there day one. It means having a target instead of drifting.

Then build toward it. Detection engineering: write detections, generate telemetry, learn Sigma, learn how logs get parsed and normalized, learn Python. Cloud security: build environments, learn IAM, Terraform, containers, Kubernetes, cloud logging. AppSec: write a lot more code, learn CI/CD, learn how applications actually get built.

The goal is walking into an interview with something you built, broke, and fixed, not a summary of a course you watched.

Senior year should be boring

If the earlier years went right, I’m not scrambling for a first internship. I’ve had two or three, probably with a return offer or at least a team that knows my work. Degree nearly done, a couple certs, real projects, a homelab, a clear direction.

Now I document properly. GitHub. Writing about what I’m learning. Talking to people already doing the job I want. That’s literally what became Cyberwox for me. Documenting my own journey publicly turned into a body of work that speaks for itself in a way a resume never could.

And I’m applying for full-time roles before graduation, not after somebody hands me the degree.

What I’m Taking Away From This

The shift is timing, not credentials. Not which degree or which certs. It’s refusing to split college into two years of preparing and two years of doing.

Every piece has one job. Classes give structure. The degree gives a credential. Certs give focused learning. Projects give practical experience. The homelab gives somewhere to experiment. Internships starting freshman year give real exposure early enough to compound. Documenting all of it gives proof.

Attention is the actual scarce resource. AI raised the floor on information access and did nothing for your ability to focus for three uninterrupted hours, which is exactly why that ability is worth more now.

The Challenge

You don’t need your career figured out at 18. I definitely didn’t. Explore, build things, break things, find what you’re actually interested in.

But don’t treat the degree as the destination, and don’t assume you have time to wait.

So do one thing this week: apply to one internship you feel unqualified for, or spin up one VM and start the lab. Then reply and tell me which, or drop it in the Discord.

Graduation shouldn’t be where your cybersecurity journey starts. It should be where you cash in four years of proof.

Sources and further resources for this issue:

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, & Substack 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

Watching tutorials helps. Taking notes helps. Even stacking up certifications helps, a little. But none of that forces you to touch packets, break something on purpose, read your own logs, secure an app, deploy infrastructure, and then explain what you actually built.

So this issue is my answer to that gap: five cybersecurity projects that map directly to real skills, network analysis, cloud and container security, secrets management, Kubernetes, SOC operations, and detection engineering. I’ve either built these myself on the channel or worked through similar examples already, so I’m linking the receipts as I go.

Why I Think Watching Isn’t Enough Anymore

A lot of people say they want security operations, threat hunting, incident response, or blue team work, and then skip the fundamentals entirely.

The goal is not to become a packet wizard overnight. The goal is to build the muscle to look at traffic and say, “Okay, I understand what is happening here.”

That line applies to basically every project below. None of these are “beginner project” ideas that sound good on a resume and teach you nothing. Pick one, build it, and document it like you’d document work you actually got paid for.

Project 1: Build a Network Traffic Analysis Lab

So much of security still comes back to understanding what’s actually happening on the wire. Set up a couple of virtual machines, generate normal traffic (browse the web, SSH into a box, transfer a few files), and capture it with Wireshark.

Then start interrogating it:

• What does normal DNS traffic look like?

• What does an SSH connection look like?

• What changes once traffic is encrypted?

• Can you identify the source, destination, protocol, port, and purpose?

Once you’ve got a feel for “normal,” introduce something suspicious: run a basic port scan, simulate a file download from a shady host, or replay a PCAP from a malware analysis challenge. That skill translates directly into SOC work, incident response, and detection engineering.

I’ve already worked through this kind of analysis on the channel:

A Quick Word on Python and SQL

Many of these projects are hands-on, but two foundational skills make them easier: Python and SQL.

Python shows up everywhere in this field: parsing logs, hitting APIs, automating repetitive tasks. SQL matters just as much once you’re touching logs, SIEMs, and dashboards, because most security work is really just asking better questions of data.

Every modern SIEM you’ll touch- Splunk, Sentinel, Chronicle, Elastic- is essentially SQL under the hood. Pivoting through auth logs for lateral movement, correlating DNS queries against a threat feed, building a dashboard of failed logins by user: that’s SQL.

I partnered with DataCamp for this one, for exactly that reason. I’d point you to their Python Programming Fundamentals and SQL Fundamentals tracks, both around 12 hours and hands-on the whole way through, with a certification at the end for your resume or LinkedIn.

You only retain about 20% of what you passively consume. When you’re actively writing code, that jumps to 75 or 90%.

That’s the actual reason I’ve been using it myself to keep those skills sharp: DataCamp Python Fundamentals and DataCamp SQL Fundamentals.

Project 2: Securely Containerize a Basic App

This one is underrated. A lot of people want to jump straight to cloud security or DevSecOps without ever containerizing an application themselves, and I don’t mean copying a Dockerfile off the internet and running it docker build.

Take a basic Flask app, a Node app, or something intentionally vulnerable, containerize it, and then secure it. Ask yourself:

• Am I running this container as root?

• Do I need every package inside this image?

• Are there secrets hardcoded in the app?

• Did I expose unnecessary ports?

• Can I scan this image for vulnerabilities?

This bridges the gap between “I know cybersecurity theory” and “I can actually secure something engineers use,” because in the real world, security teams spend as much time on how software is built and shipped as they do triaging alerts.

Reference points from past videos on the channel:

Then take it further by documenting your own hardened version: write a README, show the before-and-after Dockerfiles, and include the scan results.

Project 3: Self-Host a Password Manager

Everyone understands passwords and why password managers matter. What most people skip is the security model underneath it.

You can run this locally in your homelab or host it in the cloud with something like Vaultwarden or Passbolt. The value isn’t in getting it running; it’s in thinking through the threat model: Is it exposed to the internet? Is it behind a VPN? Are backups handled safely? Are you monitoring authentication attempts? Are you actually applying updates?

That’s the difference between “I installed a password manager” and “I deployed a security-critical service, locked down access, configured backups, and monitored it.” One of those is a resume line. The other is a project.

The same reference video applies here:

And it stacks well with the other projects on this list: put it behind Tailscale, monitor it with Wazuh, write detection rules for failed logins.

Project 4: Learn Kubernetes the Hard Way (or Break It With Kubernetes Goat)

Kubernetes is intimidating the first time you look at it: containers, networking, certificates, YAML, RBAC, service accounts, ingress, all stacked together. That’s exactly why it’s worth learning properly.

Two paths here. Kubernetes the Hard Way has you manually build a cluster and actually understand the certificates, control plane components, and networking that a managed service normally hides from you:

Kubernetes Goat is the security-focused path: it covers vulnerable scenarios such as misconfigurations, privilege escalation, secret exposure, and container escapes.

If your goal is to understand infrastructure, do the Hard Way. If your goal is Kubernetes security specifically, do Goat. If you’re serious, do both: understand how it works first, then attack and defend an insecure version of it.

Project 5: Build a Cybersecurity Homelab or Mini SOC

This is probably the project most aligned with this channel, because if you’ve been around a while, you already know I love homelabs. And a homelab does not need to be expensive. You don’t need a rack, you don’t need enterprise gear, you don’t need ten servers humming in a closet. An old laptop, a mini PC, a Raspberry Pi, or even VirtualBox on your current machine is enough.

A simple version looks like: a hypervisor like Proxmox, a Windows endpoint, a Linux endpoint, a Wazuh manager and a few agents, a vulnerable machine, and some log sources. Then you start generating real questions: Can I see failed logins? Can I detect suspicious PowerShell? Can I collect logs from Linux and Windows and write a custom detection rule?

Installing Wazuh, Security Onion, or Splunk is not the project. The project is what you do after it’s installed: generating telemetry, tuning false positives, building dashboards, and documenting the incidents you investigate.

I’ve documented my own homelab journey across my Homelab and Detection playlist and Home SOC projects, including the Proxmox build itself:

How I’d Actually Approach These Five

If you’re new to the field, start with the Network Traffic Analysis Lab and either the Homelab or the SOC project. Those give you the strongest fundamentals.

If cloud security, DevSecOps, or AppSec is the goal, start with containerizing an app and self-hosting a password manager.

If you want to push into more advanced infrastructure, do Kubernetes the Hard Way or Kubernetes Goat.

But honestly, the real magic is connecting them. Build a homelab. Run a password manager inside it. Containerize a basic app. Monitor everything with Wazuh. Capture the traffic. Deploy Kubernetes Goat. Generate attacks. Write detections. Document the whole thing.

That’s the difference between someone who says “I’m interested in cybersecurity” and someone who can say “here is what I built, here is what I broke, here is what I secured, and here is what I learned.”

What I’m Taking Away From This

Consumption isn’t the bottleneck anymore; application is. Between YouTube, certifications, and endless write-ups, information has never been easier to find. The people who stand out are the ones who actually built something with it.

Documentation is the project. Building the lab and never writing it down is basically the same as not building it. A README, a set of screenshots, and an honest account of what broke turns a weekend project into a portfolio piece.

Connected projects beat isolated ones. A password manager behind Tailscale, monitored by Wazuh, inside a homelab you built yourself, tells a far stronger story than five disconnected weekend experiments.

Your Challenge

Pick one of these five projects and actually build it. Not save it, not bookmark it, not add it to a Notion board. Build it, then document it: take the screenshots, write down the commands, explain what went wrong and what you fixed.

That documentation is what turns into a GitHub project, a blog post, a LinkedIn post, or your next interview talking point.

I genuinely want to know: which one of these five are you building this summer? Network Traffic Analysis Lab, Securely Containerizing an App, Self-Hosting a Password Manager, Kubernetes the Hard Way or Goat, or your own Homelab/SOC? Reply and let me know; I want to see what y’all are building.

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, & Substack 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

It’s a strategic blueprint from someone who helped Netflix scale security without slowing the company’s engineering engine—a balance that’s notoriously hard to get right.

It got me thinking about my own path as a Security Engineer and the various domains I’ve worked in.

What stuck with me wasn’t just Jason’s structured layers of context, strategy, and execution, but how those principles have shown up in my work again and again.

Sometimes explicitly. Sometimes, without realizing it until later.

So in this issue, I want to do two things:

1. Walk you through a few pivotal moments in my security engineering career

2. Extract real, applicable lessons from each so that you can bring them into your own context

This is not just “what I did.”

It’s “why it mattered, and what it could mean for you.”

Subscribe now

Join a vibrant cybersecurity community of over 7,000 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

Watch the full video breakdown below:

When Speed Is the Priority

Jason discusses how security teams must make room for velocity, not hinder it.

That means knowing when to optimize for “good enough right now” versus “perfect later.”

That lesson hit me hard during an active cloud campaign while I was a cloud threat detection engineer.

We were watching an attacker group compromise cloud environments at scale, deploying crypto miners using consistent IAM roles and resource naming patterns.

We had clear indicators, but no time for elegant detection modeling or layered behavioral TTP-based detections.

So I made the call to build and deploy an IOC-heavy detection.

The logic was sharp but narrow. It was very atomic in nature.

Honestly, it wasn’t what I’d want to ship under normal conditions. But it bought us time.

Visibility first. Accuracy later.

What I learned (and you can apply):

• There is a time and place for precision, but don’t let the perfect detection delay critical visibility.

• Your first iteration (for an atomic detection) doesn’t have to scale. It has to inform.

• Build something quickly, but tag it for review. Revisit it once the fire’s out.

• Sometimes, shipping quickly is the safest thing to do.

And this applies far beyond cloud detection.

Whether it’s building IAM policies, hardening containers, or writing security automation, sometimes velocity is the first layer of resilience.

Build Once, Scale Forever

Jason describes “strategy” as choosing high-leverage work that scales your impact.

When I was tasked with building detections for Google Cloud (GCP) as a cloud threat detection engineer, I could have started cranking out detections service by service.

But I knew that wouldn’t scale, and frankly, I didn’t fully understand GCP yet. Instead, I stepped back and developed an understanding of the cloud provider and a cloud threat modeling framework.

I grouped GCP services into high-level domains - Compute, storage, IAM, databases, and then used those abstractions to understand attack surfaces.

From there, I could drill down into the specifics:

• What does identity misuse look like across IAM and storage?

• How does lateral movement manifest in GCP’s managed services?

• How are GCP services abused differently or similarly to other Cloud services?

What I learned (and you can apply):

• Before building tooling or detections, have a mental model of the domain. It doesn’t have to be perfect—it just has to make complexity navigable.

• Focus on identifying common patterns across services rather than isolated exceptions. This is where reliable detection logic starts.

• If you’re onboarding into a new cloud provider, threat modeling isn’t a “nice to have”—it’s your best shot at building a reusable, scalable detection strategy.

• Documentation is a weapon. When you build mental models, write them down. It’ll save the next person weeks of confusion—and save you from repeating work six months later.

If you’re early in your career, this is gold: don’t just solve the problem, try to solve the class of problems.

Why Saying “No” is Strategic

One of the sharpest lines from Jason’s piece comes from Netflix’s former CEO, Reed Hastings:

“Strategy is about what you don’t do.”

In my current role, I work on differentiated threat intelligence for specific business units.

One thing I’ve learned the hard way is that not all intel is valuable, even if it’s technically correct or urgent elsewhere.

The internet is full of noise: threat feeds, CVEs, indicators, and intel reports. But my responsibility is to ask, “Is this relevant to us?” If not, I let it go—even if it seems scary or hyped.

What I learned (and you can apply):

• Intelligence without context is just a distraction.

• Learn to filter based on business impact and sector alignment, not just raw severity.

• It’s okay to ignore the noise—especially if you’re building a detection or IR strategy. Not every problem is your problem.

• Write down your priorities or “filter criteria.” That makes your decisions repeatable and teachable.

This applies equally across the SecOps team: don’t get caught writing detections or chasing rabbit holes just because something trended on Twitter.

Institutional Memory is Security Engineering’s Secret Weapon

Chan stresses that true scalability requires building systems people can use long after you’re gone.

That lesson came alive for me recently.

There were two major internal systems my team was responsible for—critical to detection, response, and threat intelligence—but they were barely understood.

No central knowledge. No reusable playbooks.

So, I took it on: I studied the systems, documented their behaviors and our failure points in our interactions with them, hosted a team lunch-and-learn, and built an internal wiki that others could use.

What I learned (and you can apply):

• Documentation isn’t a chore—it’s a force multiplier.

• If your knowledge lives only in your head, your impact dies when you take PTO.

• Teach others how to operate what you’ve built. That’s when you know you’ve succeeded.

• Institutional knowledge is a competitive advantage—don’t let it go to waste.

If you’re early in your career, this is one of the fastest ways to stand out:

Be the person who makes the unclear clear.

Final Thoughts

Jason Chan’s framework gave me words for things I was already doing—but it also challenged me to be more intentional about them.

His call to build guardrails, not gates… to prioritize reuse over heroics… to measure and iterate... all of it resonates more deeply the longer I’ve been in this space.

So here’s my version of his model in practice:

• Context: Understand what your org actually needs, not what LinkedIn or Twitter’s yelling about.

• Strategy: Invest in models, processes, and documentation that outlive you.

• Execution: Move fast when needed—but reflect hard and revise often.

• Measurement: Let the data from real incidents teach you how to improve.

If you’re a security engineer, a detection engineer, a threat hunter, or even just starting, this is your reminder that speed and security don’t have to be enemies.

They can be collaborators if you give them structure.

Keep building paved roads.

And when you do, leave signs behind for the next engineer.

Share

What kind of engineer am I?

Not just what tools you use. Not just what your current title says.

But how do you show up?

How do you solve problems?

How do you instinctively approach complexity?

I’ve seen this question (and its answer) surface over and over again in Slack threads during IRs, in 1:1s with mentees, in hallway conversations, in the quiet frustration of mid-career engineers trying to “level up” but not quite sure how.

And after half a decade in the field—from building threat detection pipelines at prominent startups to leading IR and threat detection at one of the largest tech companies on Earth—I’ve come to believe that most of us in security tend to move within a few core archetypes.

Not boxes. Not labels.

Gravity wells.

You may have blended skills, but there’s usually a center of mass—a force that pulls you toward a particular way of thinking, contributing, and growing. And once you can name that?

That’s when your career starts to gain direction.

Subscribe now

Join a vibrant cybersecurity community of over 7000 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

Watch the full video breakdown below:

Archetypes: A Language for How We Work

Across every security team I’ve been on, I’ve seen five archetypes show up again and again.

These are less about job titles and more about your operating posture.

How you move through problems, what you prioritize, and what kind of work gives you energy.

The Guardian

You’re the shield. The one who jumps on high-severity alerts before anyone else blinks.

You see logs like other people see spreadsheets in patterns, stories, and subtle shifts. Your radar is constantly scanning for badness.

You live in detection pipelines, SOAR playbooks, and IR processes.

You bring signal out of noise. And when things are chaotic, you’re the one who restores order.

Superpower: Translating alerts into action. Noise into signal. Chaos into clarity.

Growth Edge: Learning to zoom out. Don’t just be good at building detection rules or IR workflows. Learn to ask why this detection matters to the business in the first place.

The Architect

You’re the builder. Quietly designing the walls that stop attackers before they ever reach the door.

You speak the language of Identity and Access Management, Infrastructure-as-code, network segmentation, service mesh, secure architectural patterns, and secure-by-default everything.

You don’t want to just to fix incidents; you want to make sure they never happen again.

You design systems to be resilient by nature.

Superpower: You bring legibility to complexity. You think long-term and build for scale.

Growth Edge: Realizing that great architecture accounts for messy real-world constraints.

The Mercenary

You move fast. You ship. You patch holes and write scripts while others are still setting up their IDEs.

You care about real-world effectiveness, not perfection. You make things work, and your team leans on you when time’s running out.

You might not care about elegance, but your solutions get results.

Superpower: You create momentum when others are stuck. You execute under pressure.

Growth Edge: Learning to build for handoff. Speed without structure can turn into tech debt that no one wants to inherit.

The Researcher

You go deep. You reverse engineer malware, trace attack paths, test theories in your lab at 2 AM, not because anyone asked you to, but because you have to know.

You’re the kind of person who asks “why” five times in a row, not to be difficult, but to get to the truth.

You don’t just spot indicators. You uncover root causes. And then you sometimes document it beautifully.

Superpower: Depth. Insight. Rigor. You go where others won’t, and you bring back answers.

Growth Edge: Learning to package your insights for the broader team. If it stays in your notebook, it doesn’t scale. You don’t scale either.

The Diplomat

You’re the bridge. You know how to speak engineering, product, compliance, and executive. You translate technical risk into something others can act on.

You don’t just point out flaws, you create alignment.

Your tools aren’t just SIEMs or bash/python scripts. They’re conversations, whiteboards, and narratives. You help people care about security before it’s a crisis.

Superpower: Influence without authority. You drive change by aligning people, not just fixing systems.

Growth Edge: Staying close to the tech when you spend more time in meetings. You can’t lead security conversations if you’re out of touch with the work itself.

But What If You’re New?

Maybe you’re early in your journey. Perhaps you’re pivoting into security from another field.

You might be thinking: How am I supposed to know my archetype if I’m still trying to figure out what a “SIEM” even is?

Fair.

But here’s the thing—your archetype isn’t based on what tools you’ve mastered. It’s based on your instincts.

Here’s how you start to uncover it:

Look at your energy, not just your skillset.

What kinds of problems do you enjoy solving—even when you’re off the clock? When do you lose track of time?

Pay attention to your curiosity trail.

What do you fall down rabbit holes about? Is it misconfigured identities? Detection logic? Threat intel? Architecture? That’s your fingerprint.

Notice your default team role.

In group settings (even outside of security), do you tend to gravitate toward fixing things? Explaining things? Organizing? Building? Those patterns show up early.

Experiment through exposure.

You don’t have to pick an archetype right now. Try a little of everything. Build a detection. Automate a workflow. Dig into a threat emulation lab. Your gut will tell you what sticks.

Trust your gut.

The Framework Behind It All

These archetypes aren’t just cute metaphors. They map directly to how we grow and operate in teams.

• I-shaped engineers go deep in one area. Think of a Guardian who’s a detection ninja but doesn’t engage outside their lane.

• T-shaped engineers have depth in one skill, but range across others. Think of an Architect who also understands compliance, detection, and incident response.

• π-shaped engineers (pi-shaped) have two deep specialties—often one technical and one interpersonal, such as a Diplomat who also oversees incident response functions and conducts threat modeling sessions with developers.

Most of us start I-shaped. And that’s okay.

You need real depth before you can scale your impact.

But over time, that horizontal bar becomes crucial. It’s what allows you to collaborate, influence, and adapt across domains.

Security is a team sport, and threats are multi-layered.

Our skillsets should be too.

Becoming the Polymorph

There’s one more archetype that doesn’t exist on a slide deck or job description. It’s not something you start with—it’s something you grow into.

I call it: The Polymorph.

Polymorphs don’t just dabble across domains; they move fluidly between them. One day, they’re tuning detections.

Next, they’re designing a new cloud security model.

Then they’re mentoring a junior engineer, building a SOAR workflow, or briefing execs.

They do it not to impress, but because they’ve built range on top of real depth.

In career frameworks, this is the π-shaped engineer fully realized.

In practice? These are your Staff+ & Principal engineers.

The people you call when there’s a fire, or when you’re planning something ambitious. They don’t just get work done. They make the whole team better.

But here’s the truth:

No one starts as a Polymorph.

You grow into it, step by step.

So, How Do You Get There?

You begin where you are.

Begin by identifying the archetype that feels most natural to you. Build deep credibility and a real, authentic experience in that domain.

Then stretch.

Study how that area connects to others. Take on projects that intimidate you. Volunteer for work that’s outside your lane. Learn to explain what you know in ways others can use. Pair up with people who think differently. Build things. Break things. Share everything.

And eventually, you’ll wake up one day and realize:

You’re not just a Guardian anymore.

Or just a Researcher.

You’re not easily labeled.

You’ve become the kind of engineer that teams build around.

Want to Grow Into a Specific Archetype?

Here’s a quick nudge for each path:

Guardian → Understand detection-as-code. Triage real alerts. Learn log pipelines. Tune until a signal emerges.

Architect → Master IAM. Learn Terraform. Understand zero trust. Build preventative security by default.

Mercenary → Script small win projects. Learn security automation. Triage fast. Automate quicker. Ship working code.

Researcher → Build a purple team lab. Read threat reports. Emulate real TTPs. Write deep dives—even if no one asks.

Diplomat → Sharpen your storytelling. Join cross-functional efforts. Translate risk. Lead with empathy.

Final Thoughts

If you’re still here, let’s pause and make this personal:

• What archetype feels like home right now?

• Which one challenges you, but pulls at your curiosity?

• Where are you still I-shaped?

• What would it take to become more T-shaped—or grow toward π?

• Are you moving toward becoming a Polymorph?

  And if so, what’s one small step you’ll take this month?

Because at the end of the day, growth in security is about knowing yourself, building with purpose, and becoming the kind of engineer your future self would want on their team.

Share

Most of the time, you don’t just buy an asset and walk away; you continue to pay to maintain it. Take an investment property, for example. You pay for staff, maintenance, utilities, and software to sustain operations.

Cybersecurity is no different.

Every new detection rule, workflow automation, or control we deploy carries its own operational expenditure. It requires continuous validation, clear documentation, and regular upkeep via updates or deprecations.

But more importantly, it consumes the scarcest resource in cybersecurity: skilled humans. There simply aren’t enough experienced security professionals to go around, and every new control competes for their limited time, focus, and expertise.

On the same note, building new things is great; as a matter of fact, I encourage all cybersecurity engineers to be builders. However, building is a capital expenditure (CapEx). It’s exciting, one-time, and easy to celebrate.

Maintaining what we build? That’s OpEx. It’s invisible, mundane, constant, but essential.

The more you build, the more likely you are to owe, especially if you cut corners. And like financial debt, it doesn’t disappear. It compounds. You’re borrowing time from your future self, and eventually, the bill comes due.

But enough doom and gloom. This issue isn’t meant for that. It simply expresses this sentient problem as it relates to cyber defense.

Subscribe now

Detection Engineering: Hidden Subscription Fees

Writing a detection rule feels like a win. Even better when it catches an actual threat. You get the dopamine hit of adding coverage, expanding visibility, and contributing to your SOC’s “rule count.”

But every detection you create is a new “subscription”. More specifically, a line item on your cybersecurity operational budget.

The starting cost is the time spent building the detection and testing for precision. Then comes the forever tax of cycles spent triaging inevitable false positives. Then there are hidden fees in the form of headspace needed to document, tune, and maintain as adversaries shift or your environment evolves.

Over time, these costs may accumulate into what I call detection debt. This is the backlog of unmaintained rules and unreviewed alerts that quietly bleed efficiency from your Cybersecurity Operations function.

And like real debt, it then accrues interest if you don’t pay it down quickly or reel in your “spending” habits: more noise, more fatigue, more missed signals.

A future issue of the newsletter will address the topic of detection deprecation which may help keep your budget on track.

Incident Response: Expensive Attention

Incident Response operates under high pressure, where time is capital in a very valuable currency.

And just as a company’s burn rate determines its financial health, your alert volume and false positive rate determine your cognitive health, especially for the engineers or analysts triaging or responding.

When everything triggers, nothing stands out. It’s just like the boy who cried wolf. When security alerts lose credibility through repetition, coupled with little detection accountability, the real threats get ignored.

Each noisy alert from your detection engineering “subscription fees”, misconfigured automation workflows, or irrelevant security escalation/investigation costs minutes, which compound into hours across the team.

Ultimately, the time (capital) spent, or otherwise wasted, in a security incident could be the difference between containment and compromise. This is where those hidden fees start charging interest and bleeding you even more of your most finite IR resource - time.

GRC: The Cost of Compliance Theater

Governance, Risk, and Compliance (GRC) resides in the fine print of cyber defense, which is precisely where operational costs accumulate quietly. Every new framework, audit requirement, or control mapping is like adding another recurring bill.

At first, it looks harmless. One more spreadsheet, one more evidence collection task.

However, over time, these small costs accumulate into process debt, resulting in endless reviews, repetitive documentation, and reactive reporting loops.

Essentially, the result of GRC becoming a checklist rather than a compass. OpEx skyrockets without improving actual security outcomes. Policies become artifacts. Audits become rituals.

You end up paying to maintain a compliance theater instead of actual cyber resilience. Everyone loves a good show, but it should not come at the expense of actual security.

Maturity

Just as financial maturity isn’t necessarily measured by how much you make but by how much you actually keep, Security maturity should not simply be measured solely by how much you deploy.

It should also measure how much you sustain without drowning in your own complexity.

And your cost model should account for both maintenance and development.

I don’t want to reduce operational cost to a mere financial metaphor; I’ll dare to say that it’s a mindset.

It forces you to ask:

• Can this <insert control here> survive without me?

• Can this <insert control here> be maintained six months from now?

• Can this <insert control here> adapt to changes in the environment?

If the answer is no, it’s not ready for production — it’s just another liability waiting to mature.

Every control is a contract. Every rule is a recurring bill.

The longer you operate without acknowledging this, the more expensive your security becomes.

💭 Closing Thought

What’s your team’s real operational cost? Audit your detections, playbooks, and controls to see what you’re still paying for in time, toil, and attention.

Share

I’ve been in this space for five years now, working as a security engineer, mentoring hundreds of students, and teaching th…

Read more

What started as a room of students, career-switchers, and curious professionals asking simple questions — “What exactly is cybersecurity?” — turned into a deep dive on why this field matters, how attackers operate, and how you can build a career in …

Read more

That provided us with a map of what we’re defending against.

Now let’s talk about the people who do the defending, and those who play offense to make defenses stronger. From there, we’ll dive into t…

Read more

Now it’s time to get a little more structured.

When I teach cybersecurity, I always emphasize that we need foundations—concepts that simplify a massive, complex fie…

Read more

Not quick hot takes. Not polished LinkedIn posts.

This is where I reflect, document, and share the more profound lessons that shape my career and this community.

Earlier this year, I had the opportunity to give a two-hour live workshop on t…

Read more

I was 18, a college freshman, and an immigrant trying to figure out not just how to pass classes, but how to carve out a future in an industry I barely understood. Back then, terms like Blue Team and Red Team sounded like code names from a movie, not real jobs people built career…

Read more

Most people burn time and money on certifications that don’t change their trajectory. Use this 4‑question framework every time you consider a cert:

1. Career Value: Does this tangibly move me toward the role I want?

2. Hands‑On Depth: Will I build and prove real skills, not just memorize trivia?

3. Planned Application: Exactly how (and how soon) will I use these skills on the job or in projects?

4. Faster Alternatives: Is there a more practical path (cert, lab, project) that gets me further, faster?

If the answer to any of these is weak, pass. Simple.

About Me

If you're new here, I'm Day, a Cybersecurity Engineer at Amazon. With five years in cybersecurity, my experience covers Detection Engineering, Cloud Security, Incident Response, Threat Hunting, and most recently, Threat Intelligence.

Before Amazon, I worked at Datadog as a cloud threat detection engineer, where I researched cloud threats and built detections for various cloud providers and SaaS applications.

I've worked my way up from various SOC analyst roles, investigating everything from endpoint threats to building detection systems for cloud-based abuse, so I know exactly what it takes to break into this field and make career advancements.

I started, just like many of you, learning from scratch, asking questions, and figuring it out one step at a time. And now, I'm here to help you do the same.

If you want to stay up-to-date on the cybersecurity industry and everything technical and career-related, be sure to like and subscribe to the newsletter for more content like this.

Join a vibrant cybersecurity community of over 6,800 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

The Problem: Cert Chasing Without Strategy

I’ve taken numerous certifications for learning, career advancement, and as part of my time at WGU.

Some were worth it. Some weren’t.

The difference came down to one thing: did it create real leverage in my career?

2025 (or any year of your life) is not the time to spend on anything that doesn’t materially level you up.

No more paying for multiple‑choice trivia that never shows up in your day job.

No more “I’ll just add this to my résumé” without a plan to apply it.

Let’s fix the way you evaluate certs—once and for all.

The 4‑Question Certification Framework

1) Does it create career value?

Don’t start by asking “Is this cert popular?” Start by asking: “Does this push me directly toward the role, scope, or compensation band I’m targeting?”

How to test that quickly:

• Pull 15–20 recent job postings for the role you want.

• Highlight every required or “nice to have” cert. Notice the patterns.

• Map the cert’s curriculum to the skills those jobs demand.

• If there’s a weak or non‑existent connection, skip it.

If it doesn’t move you toward your target role, it’s a distraction.

2) Does it teach you hands‑on skills?

Multiple‑choice is not how modern teams validate your ability to ship, respond, detect, or break systems.

The market is flooded with practical training now. Use it.

Prefer these styles of exams and programs:

• Hands‑on labs in real or simulated environments

• Capstone projects that you can show and talk through

• Scenario-based exams (IR, SOC triage, malware, adversary emulation)

• Challenge platforms (HTB, TryHackMe, CyberDefenders) tied to certs

Examples:

• Defensive / SOC:

  • Security Blue Team — BTL1

  • CyberDefenders — CCD

  • Hack The Box — CDSA

• Offensive:

  • TCM — PNPT

  • INE/eLearnSecurity — eJPT, eCPPT, malware analysis tracks

  • Offensive Security — OSCP/OSEP (when you truly need that depth and rigor)

• Cloud & AppSec:

  • Cloud Breach — Offensive AWS/Azure

  • Altered Security — Azure AD, Azure application security

  • Microsoft & AWS — now adding real lab credits so you actually deploy and test (you get Azure credit to build and break things + AWS Free Tier)

• DevSecOps:

  • DevSecOps Institute and a growing set of hands‑on DevOps/SRE/Supply-chain security certs

If it’s not practical, you’re paying to forget it.

3) How will you apply it immediately?

If you don’t use it, you will lose it. Rapidly.

Before you pay:

• Define the use case. “I’m an IR analyst who wants attacker empathy, so I’ll take PNPT and immediately emulate those TTPs to harden our detections.”

• Define the artifact. “I will build a purple-team playbook, tune three detections, and push a Sigma rule PR by the end of the month.”

• Define the repetition loop. “Every Friday, I’ll spend 90 minutes re‑running one offensive technique in the lab, documenting telemetry and defensive visibility gaps.”

No plan to apply = guaranteed skill decay.

4) Are there faster, more practical alternatives?

Many legacy certs still get promoted because they’ve been around forever. That doesn’t mean they’re the best for you.

Example: For the price of PenTest+, you can get PNPT, which gives you a complete end‑to‑end practical exam with reporting that mirrors real consulting work.

Same “destination” (penetration testing competency), but PNPT gets you there faster and deeper.

Ask yourself: Is there a practical training program, project, lab series, or community-driven cert that gets me to demonstrable skill faster?

If yes, choose that.

A Simple Scorecard (Use This Before You Swipe Your Card)

Score each question from 0 to 3. Anything <8 total is a pass for me.

Sample Scorecard Evaluation: PenTest+ vs PNPT

🎯 Target Role: Junior Penetration Tester / Offensive Security Consultant

Total Score

• PenTest+: 3/12 → ❌ Skip (Low value, not practical)

• PNPT: 12/12 → ✅ Strong pick (Career-aligned, hands-on, and applicable)

Quick, Opinionated Shortlists

If you’re heading into SOC / IR / Detection Engineering

• BTL1, CCD, CDSA, PJSA, SAL1

• Practical Malware Analysis tracks (INE/eLearnSecurity)

• Build Purple team labs (SCYTHE, Atomic Red Team, DetectionLab, etc.) + writeups

If you want Offensive Security / Adversary Emulation

• PNPT (strong ROI)

• CPTS, CJSA, PT1

• eJPT → eCPPT progression

• OSCP/OSEP when you need to clear that bar for specific roles or teams

If you’re focused on Cloud Security (Blue & Red)

• Cloud Breach (AWS/Azure offensive)

• Altered Security (Azure AD, Azure appsec)

• Microsoft certs are now increasingly tied to real Azure credits and labs—use them in a practical way.

If you’re going DevSecOps / Platform Security / Supply Chain

• Practical DevSecOps

• Supplement with hands-on lab work: IaC scanning, SCA/SBOM pipelines, signing/verification, policy-as-code

Common Traps (Skip These)

• Certs you can’t map to a role you actually want.

• MCQ exams sold as “industry standard” with no lab component.

• “I’ll just learn it now for later” with no maintenance plan.

• Choosing the name-brand test when a practical, cheaper option exists.

• Paying for prestige over proof. Hiring managers care far more about what you can do and show.

If You’re Still in School (WGU, bootcamps, etc.)

Use those required certs to build a practical foundation, then pivot hard into hands‑on paths:

• Treat every “theory-heavy” cert as a primer, not the finish line.

• Immediately wrap practical labs, projects, or purple-team exercises around the content.

• Publish what you learn: detection writeups, IR playbooks, Sigma rules, Terraform modules, attack simulation notes… make it visible.

Action Plan (Do This Today)

1. Define your target role (title, team, and comp band).

2. Collect 15–20 job descriptions and extract the common required skills/tools.

3. List 3–5 certs you’re considering and run them through the scorecard.

4. Pick one that clears your bar.

5. Write a 4-week application plan: what you’ll build, tune, emulate, or publish using those skills.

6. Ship the artifact. Talk about it publicly (GitHub, blog, Substack, LinkedIn, X).

7. Rinse, refine, repeat.

My Final Take

Certifications can be either rocket fuel or busywork disguised as progress.

The difference is intentionality.

If it doesn’t add real value to your path, isn’t practical, won’t be applied, and has a better alternative, you already know the move: don’t take it.

Be surgical. Be practical.

Go further, faster, and smartly.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!

I’ve been on both sides of this.

I failed the A+ twice, came back and passed, and even went on to complete the full CompTIA “trifecta” (A+, Network+, Security+).

Along the way, I disc…

Read more

This isn’t about ego, titles, or theatrics. It’s about execution. About being the kind of operator who steps into chaos and leaves behind clarity through efficiency, and impact.

This is the mindset I’ve been reflecting on lately, particularly as I’ve transitioned through various roles and companies in my half-decade cybersecurity career.

We often discuss frameworks, titles, skills, and playbooks in cybersecurity. But sometimes, what separates good from great isn’t a fancy detection algorithm, a well-polished resume, or even years of experience.

It’s how you move.

I call it the mercenary mindset, but not in the “gun-for-hire” sense.

I’m also not talking about loyalty to the highest bidder or some kind of dark ops aesthetic.

I’m talking about the real mercenary archetype. The type of person who doesn’t wait for permission. They don’t stall for clarity. They don’t need a job description to act.

They step in.

Assess the landscape.

Adapt to the terrain.

Execute the mission with precision.

And most importantly, they leave things better than they found them.

About Me

If you're new here, I'm Day, a Cybersecurity Engineer at Amazon. With five years in cybersecurity, my experience covers Detection Engineering, Cloud Security, Incident Response, Threat Hunting, and most recently, Threat Intelligence.

Before Amazon, I worked at Datadog as a cloud threat detection engineer, where I researched cloud threats and built detections for various cloud providers and SaaS applications.

I've worked my way up from various SOC analyst roles, investigating everything from endpoint threats to building detection systems for cloud-based abuse, so I know exactly what it takes to break into this field and make career advancements.

I started, just like many of you, learning from scratch, asking questions, and figuring it out one step at a time. And now, I'm here to help you do the same.

If you want to stay up-to-date on the cybersecurity industry and everything technical and career-related, be sure to like and subscribe to the newsletter for more content like this.

Join a vibrant cybersecurity community of over 6,500 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

The Mercenary Archetype

Historically, mercenaries have played pivotal roles in shaping outcomes.

This was not because they were the most powerful, but rather because they were efficient, decisive, and unencumbered by internal red tape.

Take Executive Outcomes, for example, one of the most well-known private military companies of the 1990s. With a few hundred well-trained personnel and outdated equipment, they helped stabilize conflict zones and secure strategic resources that entire national armies had failed to manage.

Their success wasn’t rooted in scale. It was rooted in clarity of mission and precision of execution.

Now think about that through the lens of your cybersecurity career.

• How often do we see teams spin their wheels waiting for a Jira (or similar system) ticket to be resolved?

• How many times do people hold off on building a solution because they haven’t been told to?

• How many incident remediation tasks get delayed because no one wants to take ownership of the gray areas?

Mercenaries thrive in the gray. That’s where the impact is.

Personal Case Studies

Case Study 1: How I Built and Deployed an IR Analysis Procedure in a Single Day

Not long ago, while I was still working as a Security Engineer on my day job’s incident response team, a new detection triggered.

It was built recently and triggered on suspicious behavior, which was something worth investigating.

But as I looked into it, I quickly realized there was a problem. There was no documented response process for this alert—nothing for analysts to follow.

No clear runbook.

Just ambiguity.

Guess what? We love ambiguity over here.

But that ambiguity had a cost.

Analysts were escalating alerts like this to engineers because they weren’t confident in the next steps. The result was longer investigation times, duplicated effort, and a slow, inconsistent feedback loop.

Now I could’ve waited.

Sent a Slack message about it.

Logged a ticket.

Mentioned it in a weekly sync.

But that’s not how mercenaries move.

While actively working on the escalated alert, I created the missing process in real time. I defined the triage flow, codified the expected behaviors, and scoped it not just to that one alert, but to an entire class of similar alerts. That instantly multiplied the value of the effort.

Since the investigation involved decoding tokens, I also wrote a lightweight Python script to automate that decoding. It was designed to work within our data confidentiality boundaries while saving analysts significant time.

By the end of the same day, I had:

• Investigated and closed the alert

• Created a repeatable response framework for similar detections

• Built a Python tool that the team could use going forward

• Reduced time-to-resolution for all future alerts in that class

That wasn’t a heroic moment. That was a mercenary moment.

A single day of focused, strategic work that scaled our team’s capability in a measurable way.

Case Study 2: Dropped into New Terrain and Building from Scratch

In my previous role as a Cloud Threat Detection Engineer, I primarily worked on cloud infrastructure detections across AWS, Azure, and GCP.

That was my zone. I had a strong foundation there.

However, I was then temporarily reassigned to a team focused on cloud workload detection. Think Linux systems, container activity, and Kubernetes clusters.

This was less familiar territory.

I could have hesitated.

Could’ve waited to get trained up.

But mercenaries don’t (can’t) ask the terrain to change. They adapt to it.

Within one quarter, I developed a structured onboarding framework for new engineers, enabling them to write agent-based and rule-based detections for cloud workloads.

I mapped out common attacker behaviors, data sources, and detection strategies. I didn’t just ramp myself up. I reduced the ramp-up time for everyone who came after me.

Then I was handed a noisy detection for Network Utilities Executed in a Container. It triggered constantly. False positives everywhere. Most engineers would suppress it through exclusion-based detection filters.

Instead, I decomposed it into multiple high-fidelity detections.

• One focused on curl or wget used for data exfiltration

• Another focused on command-line requests containing suspicious URIs

This approach eventually surfaced real-world threats, including a live PyPI supply chain attack, which abused the curl utility to send data to an attacker-controlled infrastructure.

That detection wouldn’t have been possible without decomposing the original alert into something sharper and more intentional.

I documented the full methodology. I turned that one fix into a repeatable process that others could apply across other detections.

I wasn’t the loudest person in the room. I wasn’t the most senior engineer (in fact, I was the most junior engineer).

But I delivered the signal where there was noise.

That’s mercenary execution.

Mercenary Execution

Sometimes, Mercenaries Move Fast Because They Love the Fight

Here’s the part we don’t talk about enough.

Some people move like mercenaries, not because they’re forced to.

Not because they want recognition or the money.

Not because they’re trying to impress someone.

Some people move like mercenaries because they love the work.

They love the hunt. The build. The pressure. The challenge of untangling complex security problems and delivering sharp, effective solutions.

That’s me. And if you’re reading this, it’s probably you, too.

The reason I could build a runbook, script, and close an investigation all in one day wasn’t just because it needed to be done. It was because I enjoyed the challenge.

I liked the problem.

I was locked in.

When I stepped into an unfamiliar domain, such as Linux and container detection engineering, it wasn’t just about adapting. It was about embracing the opportunity to grow and build something useful.

I liked being in the arena. I enjoyed making the messy stuff make sense.

When you love the work, you don’t wait for direction. You move.

• You build things no one asked for because you know they’re needed.

• You care deeply about getting it right, not for applause, but because you find joy in the process.

Loving the work is the cheat code. It’s the engine behind sharp execution, fast iteration, and long-term growth.

It’s what turns “extra work” into meaningful craft.

The Mercenary Playbook

This mindset isn’t about breaking rules or ignoring process.

It’s about having a bias toward action and a habit of excellence.

It looks like:

• Prioritizing outcomes over checkboxes

• Owning the gray areas no one else wants to touch

• Building tools, docs, and workflows that outlive your tenure

• Learning just enough to ship, and then learning some more to keep iterating

• Executing with precision, not waiting for someone to tell you to

Ask Yourself

• What’s a broken process or detection flow that you could fix this week?

• What uncomfortable space have you been avoiding because it’s unfamiliar?

• What would happen if you stopped waiting for permission and started executing with conviction?

Final Thoughts

The mercenary mindset is not about ego or chaos.

It’s about precise, repeatable, decisive execution.

It’s about leaving things better than you found them.

And it’s about loving the mission enough to keep showing up, even when no one’s watching.

You don’t need to be the most senior. You don’t need a fancy title.

You need to be the one who gets things done.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!

I've applied to hundreds, if not thousands, of jobs so far, and I certainly didn't get most of them; in fact, I was rejected from most of them, which is entirely normal.

Most of the jobs I’ve had have been obtained through referrals and my network, rather than through applications, but that’s a topic for another day.

The thing is this: with each rejection, I learned something new, like an area of interviewing that I could improve upon or a skill set that I was missing, and with each application, I became a better and better candidate, landing various jobs, including my current one as a Security Engineer at Amazon.

About Me

If you're new here, I'm Day, a Cybersecurity Engineer at Amazon. With five years in cybersecurity, my experience covers Detection Engineering, Cloud Security, Incident Response, Threat Hunting, and most recently, Threat Intelligence.

Before Amazon, I worked at Datadog as a cloud threat detection engineer, where I researched cloud threats and built detections for various cloud providers and SaaS applications.

I've worked my way up from various SOC analyst roles, investigating everything from endpoint threats to building detection systems for cloud-based abuse, so I know exactly what it takes to break into this field and make career advancements.

I started, just like many of you, learning from scratch, asking questions, and figuring it out one step at a time. And now, I'm here to help you do the same.

If you want to stay up-to-date on the cybersecurity industry and everything technical and career-related, be sure to like and subscribe to the newsletter for more content like this.

Join a vibrant cybersecurity community of over 6,000 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

My Personal Experience and Advice

I'd like to start by sharing with you my experience of applying to a bunch of jobs, combined with my years of experience working in the cybersecurity industry and exposure to lots of colleagues, recruiters, and hiring managers, so that I can give you my take on how you should apply for cybersecurity jobs, depending on how much relevant experience you have.

For each stage, I'll focus solely on the most critical aspects, such as having a strong resume, an irresistible portfolio, the right technical and problem-solving skills, and an optimized LinkedIn profile, as these will serve as a good baseline to start from.

That’s when your career starts to gain direction.

Please note that I use 'Stage' and 'Level' interchangeably for the remainder of this newsletter.

Level One: No Relevant Experience and No University Degree

Let's start with Stage One, where you have no relevant experience, no university degree, and no cybersecurity certification.

I'm not going to lie; this is a very challenging starting position, but if you're truly determined to become a cybersecurity professional, there are several steps you can take to achieve your goal.

Your number one priority should be to gain hands-on, relevant experience.

Depending on your age, I recommend pursuing different activities.

Say, if you're in high school, and you don't want to go to or cannot go to college for whatever reason, you could apply for apprenticeships or training programs available at your school.

These programs are typically designed for students nearing the end of high school, such as those in 11th or 12th grade, or for those who have recently graduated from high school. Most large corporations offer similar programs.

The names of these programs might differ by country, state, or the program itself; they might be called apprenticeships or training programs, but the idea is the same:

• To allow you to develop your skills

• Get real-life experience

• Get paid enough at the same time

Even if you don't go for a specific cybersecurity apprenticeship program, as long as you work with technology, systems, or networks as part of the role, you should be fine.

You could use these programs as a stepping stone to accelerate your journey to become a full-time cybersecurity professional at a very young age.

Now, if you're not in high school and you've been stuck in another job that you don't like and are super interested in data analytics, I'd recommend focusing on

• Learning the technical skills required

• Getting well-known and knowledge-dense certifications

• Building a strong portfolio to showcase your skills

• Writing a great resume

• Optimizing your LinkedIn profile (more on this later in the newsletter).

I’ve already created video guides on how to optimize your LinkedIn profile and write a resume, as well as various cybersecurity portfolio projects, where I go through everything in detail.

However, as a quick summary, I'd start by learning the basics through the CompTIA Trifecta curriculum, then pursue a program like the Google Cybersecurity Certificate or Microsoft Cybersecurity Certificate, and finally decide on the path you want to take.

You can choose either the Offensive or Defensive side of Cybersecurity. Then, I recommend completing labs, projects, and certifications to reinforce this.

You can also learn a programming language of your choice. I'd personally recommend Python.

In terms of certifications, I can primarily speak to defensive ones, so you can opt for well-known ones, such as the BTL1 from Security Blue Team, the CCD from CyberDefenders, or the CDSA from HackTheBox.

I’ve made several videos about these certifications on my channel.

For offensive security, based on a conversation with my friend Tadi, who’s an Offensive Security Engineer, you can go for certifications like the eJPT from eLearn Security, the PNPT from TCM Security, or the OSCP from Offensive Security.

You can watch more about how he got into offensive security, just like me, without a college degree.

I have already put together a cybersecurity learning framework that you can review at the end of this newsletter.

I've personally gone through everything at this stage because I got into cybersecurity as a college freshman without a degree, so I can relate to this, and I believe others can too. If you're currently teaching yourself cybersecurity while in college or another situation, feel free to share your feedback in the comments below.

I'm sure we'd all appreciate hearing your thoughts and insights.

Level Two: No Relevant Experience, But Have a University Degree

Moving on to stage two, where you still lack relevant experience but have a college degree. Here, depending on whether you just graduated, are about to graduate, or graduated over three years ago, I would approach applying for jobs differently.

If you're about to graduate or are a recent graduate, focus on applying to graduate job programs designed for those in their final year of higher education or recent graduates.

While you probably won't find a cybersecurity-specific graduate program, getting into a program that helps you develop technical skills would be ideal.

I know several people who transitioned into cybersecurity this way; it often makes the process easier.

Graduate job programs are beneficial because they typically involve placements lasting six to twelve months and include rotations that provide valuable experience. This allows you to work in various teams and departments, helping you determine what you want to do by learning what you don't want to do.

If you graduated a while ago, pursued something else, traveled, or life led you in a different direction, and now you want to pursue a career in cybersecurity, I recommend focusing on the cybersecurity roadmap, your resume, portfolio, and certifications outlined in Stage One.

Also, highlight your degree, especially if you studied relevant fields such as computer science, cybersecurity, IT, or Information Systems, or took courses related to cybersecurity.

Level Three: Some Relevant Experience

Let's move on to stage three, where you have some relevant job experience.

For example, in your current role, you handle Identity and Access Management and work with endpoints or vulnerability scanners daily, or you might be involved in governance, compliance, or similar areas.

You may not be performing advanced cybersecurity tasks, but you're actively working within the security field.

For instance, if you're a systems administrator managing user access controls, your duties may differ from those of a cybersecurity analyst; however, you still utilize tools to manage user privileges and create reports for IT meetings and presentations.

This is valuable experience to highlight at the top of your resume.

However, since you're applying for a cybersecurity role, emphasize the security aspects of your work that support system integrity rather than just your general IT skills.

Network management skills are essential and necessary in cybersecurity; however, since they are not the primary focus for recruiters and hiring managers, don't place them at the top of your resume.

Instead, showcase how well you understand the security implications of user permissions and how effectively you can communicate security threats using data to a non-technical audience, rather than your overall communication skills or IT reporting abilities.

Level Four: Plenty of Relevant Experience

Finally, level four, where you have substantial relevant experience and are looking to transition into cybersecurity by applying the skills you've gained throughout your career.

Let's use a specific scenario, based on personal experience, to demonstrate how you can apply your existing skills to cybersecurity. I

I have coached someone who worked as a systems administrator, managing various systems, networks, and security protocols daily.

Their focus was on identifying potential vulnerabilities in the network, managing access controls, ensuring security protocols were in place, and reviewing network packet captures using Wireshark for analysis.

Although the role was not explicitly cybersecurity-named, the skills they developed over the years were highly applicable to cybersecurity tasks, such as reviewing system logs for anomalies or intrusions, implementing security measures, and developing strategies to mitigate threats.

If you're in a similar position where your skills are transferable to cybersecurity, I would highlight this relevant work experience at the top of your resume.

Concluding Advice and Encouragement

Now, this is probably the most crucial advice, whether you have no experience or a lot, it's not to give up.

It may sound cliché, but the difference between successful and less successful people isn't really their ability to succeed; it's their ability to bounce back from defeat, failures, and rejections, to work hard, and to improve and grow.

I’ve been rejected over a hundred times, maybe even over a thousand, and the first rejection really hurt, so did the second, the tenth, and the hundredth.

Of course, these rejections affected me; it was a sad, frustrating, and discouraging experience.

I thought, "This is not fair; I'm clearly doing my best as an entry-level candidate. I've got the certificates, the projects, everything," but that was definitely the wrong mindset.

The moment I stopped dwelling on the rejections and started analyzing why I was rejected and how I could improve so it wouldn't happen again, everything changed.

I focused, pushed through, and worked tirelessly. It's this work ethic, the countless hours of learning, the days spent alone in my room, forgoing pleasures, building and sharpening my skills, that landed me my job and helped me grow quickly.

Don't dwell on the past; live in the present, and focus on the future. Another thing I’ve learned is to stop comparing myself to others; I'm just trying to do my absolute best and be a good person.

Everything I've achieved since leaving Nigeria at age 14 has come through my hard work and the grace of my Lord and Savior, Jesus Christ, and I am truly proud of it.

I hope you can take inspiration from my experience and continue moving forward.

Remember, it's not success that defines you. It's your ability to bounce back from failures that truly shapes who you are.

Recent Content

A few publications I’ve released recently.

Building A Cyber Threat Intelligence Career with Nigel Boston | EP 26

Chatting with Nigel Boston, who is a Senior Cyber Threat Intelligence Professional. Nigel has built and led threat intelligence programs that reduce incident response times, operationalize threat intelligence, and automate workflows to help teams focus on what matters: staying ahead of the threat curve.

In this episode, we discuss how Nigel discovered cyber threat intelligence and carved a path into the field, what core security skills make a difference in Cyber Threat Intelligence, and how threat intelligence intersects with detection engineering, cloud security, and even AI.

We also dive into the future of threat intelligence, the rise of actionable intelligence, and his new course, Cyber Threat Intelligence Fundamentals, with Ellington Cyber Academy (ECA), which is a game-changer for anyone looking to break into the space.

We’ve also had Kenneth, the founder of ECA, in EP 10, so definitely be sure to check that out.

Whether you're new to cybersecurity or looking to elevate your threat intelligence, this conversation is packed with clarity, strategy, and real-world wisdom.

Quick side note: This episode was filmed in November 2024, so you can expect to see me with shorter hair.

Cyber Stories Podcast

Cyber Threat Intelligence with Nigel Boston | EP. 26

Chatting with Nigel Boston, who is a Senior Cyber Threat Intelligence Professional. Nigel has built and led threat intelligence programs that reduce incident response times, operationalize threat intelligence, and automate workflows to help teams focus on what really matters: staying ahead of the threat curve…

Listen now

a year ago · Day Johnson

Detection-In-Depth

A guest post on THOR Collective Dispatch!

Also featured on the tl;dr sec newsletter issue #282 under the blue team section, and as a Detection Engineering Gem in issue #112 of the Detection Engineering Weekly Newsletter!

I explore the mindset of detection-in-depth, which is first a play on the existing “defense-in-depth” concept, outlining a strategy where defenders aim to catch adversaries across every stage of their attack, not just during initial access.

It walks through:
- Why detection-in-depth means catching adversaries at every stage, not just the first or somewhere in the middle.
- The importance of tuning OOTB rules for the context and uniqueness of your environment
- How precision and not just coverage make alerts more effective

This one’s for security engineers, IR folks, and anyone who’s ever looked at an alert and thought, “This could be better.”

THOR Collective Dispatch

Detection-In-Depth

Detection-in-depth is an evolution of the classic cybersecurity principle known as defense-in-depth. Defense-in-depth means that no single security control can fully protect an environment—instead, multiple layered defenses must work together to slow down, detect, and ultimately stop adversaries…

Read more

a year ago · 26 likes · Day Johnson

Career Quest: Cybersecurity Careers with Day Johnson

I had the pleasure of sitting with students from my Alma mater (WGU) and sharing with them about Cybersecurity career pathways.

Getting Your First CYBERSECURITY Job - College, Certifications & Work Experience

The YouTube version of this post!

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!

On one hand, the global shortage of cybersecurity professionals remains a pressing issue.

According to Cybersecurity Ventures, there are 3.5 million unfilled cybersecurity positions worldwide, a number that has persisted since 2021.

In the U.S. alone, nearly 470,000 cybersecurity job openings were reported between May 2023 and April 2024.

On the other hand, specific traditional roles are experiencing a decline.

Job postings for Security Engineers and Security Analysts have decreased by approximately 25% from 2022 to 2024.

This decline is attributed to factors such as automation, outsourcing, and the evolving nature of cybersecurity threats.

About Me

If you're new here, I'm Day, a Cybersecurity Engineer at Amazon. With five years in cybersecurity, my experience covers Detection Engineering, Cloud Security, Incident Response, Threat Hunting, and most recently, Threat Intelligence.

Before Amazon, I worked at Datadog as a cloud threat detection engineer, where I researched cloud threats and built detections for various cloud providers and SaaS applications.

I've worked my way up from SOC analyst roles, investigating everything from endpoint threats to cloud-based abuse, so I know exactly what it takes to break into this field.

I started just like many of you—learning from scratch, asking questions, and figuring it out one step at a time. And now, I'm here to help you do the same.

If you want to stay up-to-date on the cybersecurity industry and everything technical and career-related, be sure to like and subscribe to the newsletter for more content like this.

Join a vibrant cybersecurity community of over 6,000 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

The Impact of AI on Cybersecurity Roles

Now, let's dive into this issue by first understanding the impact of AI on cybersecurity operations.

Automation and Augmentation

Artificial Intelligence (AI) is revolutionizing cybersecurity operations.

AI systems are now capable of analyzing vast amounts of data, detecting anomalies, and responding to threats in real-time.

For instance, AI can process up to billions of data points daily, significantly enhancing threat detection and similar capabilities.

However, this innovation is a double-edged sword.

While it increases efficiency, it also reduces the demand for entry-level roles focused on routine cybersecurity tasks.

Conversely, there is a growing need for professionals who can architect, manage, and oversee AI-driven systems, interpret complex data, have a deep understanding of cyber threats, and make informed strategic decisions.

The Rise of Outsourcing in Cybersecurity

Globalization of Cybersecurity Services

Outsourcing has also become a significant trend in cybersecurity.

Organizations are increasingly turning to Managed Security Service Providers (MSSPs) and Security Operations Center as a Service (SOCaaS) to handle their security needs.

This shift is driven by factors such as cost-effectiveness, access to specialized expertise, and the need for 24/7 monitoring.

While outsourcing offers benefits to organizations, it also affects job opportunities for cybersecurity professionals.

There's a growing emphasis on roles that require professionals who can bridge the gap between outsourced services and organizational objectives.

Economic Factors Influencing the Cybersecurity Job Market

Budget Constraints and Strategic Investments

Economic pressures are also influencing how organizations allocate resources to cybersecurity.

While overall spending on cybersecurity continues to grow, there is a shift toward strategic investments in people, technologies, and services that offer the highest return on investment.

This includes AI-driven solutions, cloud security, and advanced threat detection systems.

Regulatory Compliance and Risk Management

Additionally, international regulatory requirements are becoming more stringent and, quite frankly, more expensive, compelling organizations to invest in compliance and risk management.

This trend is creating demand for professionals skilled in Governance, Risk, and Compliance (GRC), as well as those who can navigate complex regulatory landscapes.

In fact, there has been a substantial increase in specialized cybersecurity roles focused on data protection and user privacy, particularly in positions such as Privacy Engineering, Data Protection Officers (DPOs), and Privacy Compliance Specialists.

Across various roles, I’ve also experienced legal professionals being embedded in cybersecurity organizations, both product-focused and operationally focused.

These roles have become increasingly critical as organizations navigate complex privacy regulations and consumer data protection requirements.

What Now?

So what does all this mean for you?

You already know that AI is changing the game, but it can’t replace real-world experience.

You can’t prompt your way out of a real-world incident. You can’t ChatGPT your way through a breach when a customer’s data is at risk for a publicly traded company.

What you need is reps. What you need is judgment.

And that’s precisely why DFIR Labs, the sponsor of this issue, stood out to me.

DFIR LABS BY THE TEAM BEHIND THE DFIR REPORT

Gain hands-on access to the type of cyber chaos that no simulation can recreate: with ambiguous enterprise logs, noisy alerts, subtle lateral movement, and the tactics real attackers use when they breach your network. Based on actual intrusion cases grounded in incidents that occurred in the wild, you’ll learn to think like an analyst, not just follow a checklist, and begin to recognize attacker behavior and tradecraft in real telemetry.

Master DFIR with Hands-on Labs

Positioning yourself for success

Alright — now let’s talk about how to position yourself to win in this new cybersecurity world.

1 - Embrace Continuous Learning

If there’s one trait that separates those who thrive in cybersecurity from those who eventually stagnate, it’s an unshakable commitment to continuous learning.

Cybersecurity isn’t just dynamic, it’s also volatile.

The threat landscape doesn’t evolve year to year. It changes by the week, sometimes by the day.

New CVEs drop. New threat actors emerge. Cloud platforms update security models. AI opens doors to both powerful defense tools and new classes of adversarial abuse.

If you’re not consistently sharpening your skills, you’re falling behind.

But here’s the nuance people miss:

Continuous learning isn’t just about earning certs or reading blog posts. That’s important, yes — but it’s not enough.

You need friction. You need context. You need reps.

Because cybersecurity isn’t just a knowledge game, it’s a judgment game.

You don’t just need to know what lateral movement is. You need to recognize it when it’s buried under ten thousand other logs.

You need to know when a misconfiguration is just sloppy infrastructural negligence, and when it’s signaling malicious intent.

That’s how you build instincts. That’s how you learn to investigate under pressure, follow leads, ask better questions, and ultimately become the kind of security professional companies can’t automate away.

2 - Develop Cross-Functional Expertise

A while back, Cybersecurity used to live in a silo.

You had the network engineering people, the developers, the infrastructure teams, and somewhere in a dark corner, the security team that everyone avoided unless something went really wrong.

But in 2025, that model is dead.

Today, cybersecurity is both a business enabler and a cost center.

So if you're not thinking cross-functionally, you’re not thinking strategically.

Gone are the days when your job was monitoring logs, patching systems, or tweaking firewall rules.

That’s table stakes.

Organizations now expect security professionals to operate at the intersection of technology, business, risk, and communication.

Here’s what that means:

• You need to understand how security decisions impact product development

• You need to know how an exploited misconfiguration can affect customer trust and potential revenue.

• You should be able to explain to an executive why an unpatched vulnerability is not just a CVSS score, but could lead to real financial liability.

• And when you’re working in the cloud? Understanding DevOps, CI/CD pipelines, IaC, and cloud-native architecture isn’t a “nice to have.” It’s baseline fluency.

The best cybersecurity engineers I know and I’ve worked with aren’t just technically sharp — they’re also able to walk into a room of stakeholders from engineering, product, legal, and compliance and explain what’s at risk in plain English.

They know when to escalate, when to advise, and when to collaborate.

And let me say this clearly: Being technically brilliant but context-blind will hold you back.

You’ll get overlooked for leadership roles, for strategic projects, even for the kind of work that really moves the needle.

Cross-functional expertise doesn’t mean you have to be an expert in everything.

It means you need to build enough breadth to communicate effectively and enough depth to execute responsibly.

It’s about thinking beyond just systems and endpoints.

It’s about understanding the business and helping protect the entire value chain — from source code to customer experience.

Learn that, and you become indispensable.

3 - Cultivate Soft Skills

Let’s be real — when most people hear “soft skills,” they roll their eyes.

Especially in cybersecurity, where it’s easy to assume the only thing that matters is how technically sharp you are.

Can you reverse engineer malware? Write detections? Secure infrastructure?

That stuff matters and is important. No question. Full stop.

But here’s what a lot of early-career folks don’t realize until it’s too late:

The further you grow in cybersecurity, the more your success depends on your ability to work with people.

Not tools. Not terminals. Not tickets. People.

Soft skills — and I’m talking about honest communication, leadership, and emotional intelligence — are what separate good security engineers from the ones who actually lead initiatives, gain trust, and make strategic impact.

Here’s what cultivating soft skills actually looks like in our field:

1. Being able to walk into a tense post-incident review and clearly explain what happened without throwing anyone under the bus.

2. Communicating risk to leadership in the language they understand by translating technical findings into business impact.

3. Navigating cross-functional friction when the security team is seen as the “department of no” and flipping that perception by being a partner, not a blocker.

4. Mentoring junior engineers & analysts. Holding your team accountable. Knowing how to escalate a threat without creating panic.

These are the moments that make or break trust.

And trust is the currency of cybersecurity.

If your team doesn’t trust you, if your leadership doesn’t listen to you, if your partners tune you out, your technical brilliance won’t matter.

You’ll be ignored. Or worse, replaced.

Now here’s the part most people underestimate:

Soft skills aren’t just about external collaboration.

They’re also about internal regulation.

• Can you stay calm during a high-severity incident?

• Can you manage your time across competing priorities?

• Can you ask for help before burnout takes over?

• Can you receive feedback without getting defensive?

These are human skills.

And cybersecurity, for all the talk about code and exploits and zero-days, is a deeply human field.

We’re dealing with threat actors — humans.

We’re protecting people’s data — humans.

We’re collaborating across teams — again, humans.

So if you want to go far in this field, not just technically, but as someone others want to work with, then don’t just cultivate your knowledge.

Cultivate your character.

That’s what creates longevity. That’s what builds leadership. That’s what keeps you relevant in a space that’s changing faster than ever.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Recent Content

A few publications I’ve released recently.

My Honest Advice On Starting A Cybersecurity Career in 2025 (in less than 5 mins)

Advice from my 5 years of learning, teaching, and working in the cybersecurity industry (in less than 5 mins).

Building a DNS Server with Python - 2 (Parsing The Header)

Second installment of this series, in this case we’re parsing the header.

Detection-as-Code & CI/CD for Detection Engineering with Dennis Chow | Detection Opportunities EP 9

Detection as Code is one of the most importnat evolutions in modern security detection, and in this video, we break it down.

I first encountered this concept as a Cloud Threat Detection Engineer at Datadog. Today, I’m joined by Dennis Chow, a Detection Engineering specialist and author of Automating Security Detection Engineering (which I had the honor of technically reviewing).

Together, we explore what Detection as Code really means and walk through two hands-on CI/CD pipeline demos:

🔹 Lab 1: Building SIEM detections with synthetic AI testing using Sumo Logic

🔹 Lab 2: Policy-as-Code integration testing with Cloud Custodian on GCP.

You’ll learn how Detection as Code leverages Git, automated testing, reproducibility, collaboration, and CI/CD to make detection engineering more scalable, accountable, and reliable.

My Honest Thoughts on the Cybersecurity Job Market in 2025

The YouTube version of this post!

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!

In 2025, one of the fastest-growing and most in-demand roles in cybersecurity is Cloud Security Engineering.

But how do you actually become one, especially if you're starting from scratch?

In this newsletter, I'll provide you with a step-by-step roadmap to become a Cloud Security Engineer, without requiring a college degree or prior technical experience.

About Me

If you're new here, I'm Day, a Cybersecurity Engineer at Amazon. With five years in cybersecurity, my experience covers Detection Engineering, Cloud Security, Incident Response, Threat Hunting, and most recently, Threat Intelligence.

Before Amazon, I worked at Datadog as a cloud threat detection engineer, where I researched cloud threats and built detections for various cloud providers and SaaS applications.

I've worked my way up from SOC analyst roles, investigating everything from endpoint threats to cloud-based abuse, so I know exactly what it takes to break into this field.

I started, just like many of you, learning from scratch, asking questions, and figuring it out one step at a time. And now, I'm here to help you do the same.

I personally was able to break into cybersecurity as early as my freshman year of college. I’ve secured several jobs and interviews prior to earning my college degree, and I’ve helped thousands of people achieve the same success on my various content channels and in my Discord Community.

Join a vibrant cybersecurity community of over 6,000 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

What Cloud Security Engineers Actually Do

Let's start with the most essential question: What is cloud security engineering?

Many people imagine it's just monitoring dashboards, reviewing alerts, and adjusting IAM permissions. But the reality is far more complex and deeply technical.

A cloud security engineer builds and protects the systems, identities, data, and infrastructure that power cloud environments, such as AWS, Azure, and GCP.

The role involves designing secure cloud architectures, detecting cloud service abuse, automating responses to cloud misconfigurations, and investigating breaches through cloud log analysis, among other tasks.

This position uniquely blends software engineering, DevOps, and cybersecurity skills.

Unlike a SOC Analyst who mainly analyzes threats, as a Cloud Security Engineer, you'll build security guardrails, write scripts, deploy infrastructure, and prevent security incidents by fixing cloud misconfigurations—one of the leading causes of cloud attacks.

If you're expecting a simple checklist job, think again. Cloud security engineering requires critical thinking, curiosity, and a genuine engineering mindset.

Understanding the Cloud Comes First

Before diving into tools or certifications, it is essential to understand how cloud systems work.

You can't secure what you don't understand—and cloud infrastructure is truly a world of its own.

This means learning and understanding how identity works in cloud platforms—how users, services, and roles authenticate and what they can access.

You need to understand how resources, such as virtual machines, storage buckets, and containers, are deployed and managed.

You must also grasp how cloud networks are segmented, how logs are generated, and what telemetry is available for detecting suspicious behavior across different cloud planes—specifically the control plane (or management plane) and the data plane.

This goes beyond memorizing terminology. It's about developing a deep understanding of how cloud environments are built and how data flows through them. When something breaks—or worse, when someone breaks in—you need to recognize the signs and distinguish between normal, risky, and malicious behavior.

Starting with AWS, Azure, or Google Cloud doesn't matter at first. What's important is choosing one platform and committing to learn it from the ground up.

A previous video on how to become a Cloud Security Engineer:

Mastering Networking Fundamentals

After you've started to understand how cloud services are structured, the next piece of the puzzle is networking.

This is one of the skills I strongly advocate cybersecurity professionals learn early on—and while many people tend to skip ahead or zone out here, trust me, you won't want to ignore this.

Networking is the lifeblood of everything in security, especially in the cloud. Without it, you'll be flying blind.

You need to understand how devices communicate with each other over the internet.

This includes concepts like IP addressing, subnets, and Network Address Translation (NAT).

You'll want to become familiar with how public and private networks function in a cloud context, as well as how traffic is routed between services and across regions.

You'll also need to understand protocols because when an attacker probes your cloud environment, they often use protocols like HTTP, SSH, or DNS in abnormal ways.

If you can't recognize what "normal" looks like, you'll never be able to spot the subtle signs of an intrusion or ongoing attack.

But beyond detection and investigation, networking also helps you build better cloud architecture.

It helps you segment services to reduce your blast radius and design environments that are harder to exploit and move through laterally.

So don't rush this step. It will pay off over and over again in your career.

How To Learn Computer Networking:

Computer Networking Mini-Course

Understand the System Before You Secure It

Once you've started to grasp cloud infrastructure and networking, you might be tempted to jump right into learning tools like SIEMs or EDRs.

While these tools are essential, they are not where you should start.

Why? Because every security tool relies on the underlying telemetry and behavior of the system it monitors.

Without understanding how a system works, knowing which buttons to click won't be of much help.

You won't recognize architectural problems, spot anomalies, or even build meaningful detections.

When I started working on cloud detections professionally, I encountered a cloud provider with which I had no prior experience.

Within a few months, I transformed from a novice in this cloud platform to writing multiple detections, supporting customers during a large-scale cloud incident, and presenting my research on company blogs and at major cybersecurity conferences.

The takeaway is simple: master the system first. Always. Once you do, every tool you learn afterward will click into place.

My Research on Google Cloud Threat Detection.

My fwd:cloudsec talk on Google Cloud Threat Detection:

Learn Cloud Security Tooling Intentionally, Not Impulsively

Now that you’ve built a strong foundation in how cloud systems and networks operate, you’re ready to start exploring the tools that cloud security engineers use on the job.

However, I want you to approach this with intention, rather than impulse or guesswork.

Security tools are designed to enhance your understanding, not replace it.

Whether it’s a log analysis platform, a threat detection engine, or a cloud-native monitoring service, these tools help you find, investigate, and respond to threats.

But they’re only as powerful as your understanding of what you’re looking at.

Instead of trying to learn every tool out there, focus on learning how to think like a cloud defender. Understand what telemetry is available.

Learn how to follow the trail of an attacker moving through a cloud account. Practice reading logs, correlating events, and writing detection logic that isn’t just copy-pasted from a playbook.

Tools are essential, but they're only effective when paired with a cloud security engineering mindset, deep contextual understanding, strong problem-solving skills, and sharp analytical reasoning.

TRYHACKME DEFENDING AZURE LEARNING PATH

Rather than just covering surface-level cloud concepts, gain foundational knowledge through hands-on experience in real Azure cloud environments, including key Azure security tools such as Microsoft Sentinel, KQL, and Defender, with TryHackMe's Defending Azure Learning Path.

Learn How To Defend Azure!

Real-World Practice Is What Separates Theory From Skill

Reading articles and watching videos like this can provide knowledge, but knowledge alone doesn't build confidence.

That's why hands-on experience is essential if you want to become a cloud security engineer.

You need to simulate real-world scenarios.

This may involve setting up a mock cloud environment, deliberately misconfiguring it, and then identifying and resolving those issues.

Or it could mean working through labs where you analyze logs, triage alerts, and respond to simulated attacks.

Again, TryHackMe’s learning platform is perfect for precisely this kind of progression.

The defending Azure learning path will walk you through deploying, breaking, and defending systems in a safe environment.

The key is not just to study cloud security. Do cloud security and get your hands dirty.

Learning to Automate with Code

In the cloud, things move fast. And if you try to secure everything manually, you will fall behind.

That’s why automation isn’t just a nice-to-have skill—it’s a requirement.

If you want to scale your impact, reduce noise, and respond to threats efficiently, you need to learn how to write code.

Python is a fantastic starting point. It’s easy to learn, widely used in security, and perfect for tasks like:

• Parsing logs

• Querying APIs

• Automating responses

• Writing detection logic

Once you’ve built a foundation in Python, you can expand into scripting languages like Bash or PowerShell, depending on your environment.

However, the most important thing is to begin writing code that solves real-world problems.

That could be anything from a cloud function to a remediation workflow that disables misconfigured users, or a bash script on a virtual machine to install specific tooling on deployment.

Remember—you’re not trying to be a software developer. You’re building tools that make you a more effective security engineer.

This also ties closely to Infrastructure as Code.

Learning Infrastructure-as-Code

One of the most significant shifts in modern cloud environments is the transition to Infrastructure-as-Code.

Instead of clicking buttons in a web console, engineers are deploying resources using declarative templates and scripts. This has significant implications for security.

If you understand how Infrastructure as Code works, you can detect misconfigurations before they go live.

You can review changes in source control. You can build security guardrails into development workflows.

And you can make sure that security isn’t just something that happens after deployment—it’s baked in from the start.

You don’t need to master every IaC tool out there, but you should be comfortable reading, reviewing, and writing templates for the cloud environments you work with.

Build Projects That Showcase Your Skills

All of this learning—cloud, networking, systems, scripting—needs to be tangible.

That’s why projects are so important.

If you can build a small cloud environment, configure it securely, simulate an attack, and then detect and respond to that attack, you are almost job-ready.

If you can automate policy enforcement or build dashboards highlighting risky behavior, you are also almost job-ready.

Your projects don’t need to be flashy. They need to be real.

They need to demonstrate that you understand how to think, investigate, and solve cloud security problems.

And they need to be documented—on your GitHub, in your portfolio, or on your resume.

When you start applying for jobs, those projects are what set you apart from everyone else with a certificate and a list of buzzwords.

Staying Current and Never Stopping

Cloud security is not a static field; it is constantly evolving. It changes every single day.

New services launch. Old ones get deprecated. Attackers find new weaknesses. Teams build new defenses.

It’s just simply evolving.

Therefore, your role as a cloud security engineer is to evolve with the industry.

That means reading blogs or newsletters, reviewing vendor changelogs, joining security communities, and practicing regularly.

Not out of fear, but out of a commitment to being excellent at your craft.

This is a career, not just a class. And the more you treat it like a long-term journey, the more you’ll get out of it.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Recent Content

A few publications I’ve released recently.

Cybersec Café #59 - 03/18/25

This was a great conversation I had with Ryan Cox from The Cyber Cafe. Ryan and I sat down this past month and dove into my journey in cybersecurity, my path from beginner to established professional, how I’ve built my online business, and more. Since we’ve both specialized in Detection and Incident Response, it was great to see how our experiences compared and share my perspective on the industry.

The Cybersec Café

Cyber Chat: Day Johnson

I’m super excited to share my latest Cyber Chat with Day Johnson - a Cybersecurity Engineer and Content Creator…

Read more

2 years ago · 2 likes · Ryan G. Cox

Community College to Microsoft Cybersecurity Internship with Carl David | Cyber Stories Podcast EP 25

A conversation with Carl David, a rising cybersecurity professional who started as an Incident Response Intern with Microsoft’s world-renowned DART team. Carl, originally from Rwanda, shares how he broke into the field after studying at Collin College, where I also began my journey.

He’s now making waves as an Intelligence Analyst Intern at Semperis and will be joining USAA as a Cybersecurity Intern in Summer 2025. We explore Carl's journey of landing his first internship at Microsoft, which subsequently opened doors to two more offers, various certifications, clear college pathways, and career insights.

We also discuss the significance of deliberate networking and developing cybersecurity projects. Additionally, we address the hardships that come with immigration and the obstacles faced by international students, along with strategies for overcoming them.

Carl’s journey serves as a blueprint for aspiring cyber professionals, particularly those starting from humble beginnings.

Cyber Stories Podcast

Community College to Microsoft Cybersecurity Internship with Carl David

A conversation with Carl David, a rising cybersecurity professional who started as an Incident Response Intern with Microsoft’s world-renowned DART team…

Listen now

2 years ago · 1 like · Day Johnson

Fastest Way To Become a Cloud Security Engineer in 2025

The YouTube version of this post!

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!

Let’s get into it.

1. Enjoy Work & Embrace Discipline

As Gen Z, we’re often labeled as lazy or lacking discipline. But I’ve come to love the grind — not just in theory, but in action. I’ve learned to build a career I enjoy, and that makes all the difference. Work doesn’t feel like a burden when it aligns with purpose.

Discipline? It’s the multiplier. It fuels your work, your habits, your life.

2. Take Care of Your Physical Health

Your health is the foundation of everything, especially in a high-stress industry like cybersecurity.

Over the years, I’ve dialed in my sleep, diet, and training. Whether I’m cutting, bulking, lifting, or running, it helps me stay sharp.

Fitness isn’t about looking a certain way — it’s about feeling your best so you can be your best.

3. Relationships Matter More Than You Think

There was a season I didn’t prioritize friendships. I was isolated, anxious, and depressed.

But building meaningful connections with friends and family changed everything.

You don’t always need deep talks — sometimes a FaceTime call or gym session with your best friend can recharge your whole spirit.

4. Slow Progress Is Still Progress

I used to think speed was everything. But I’ve learned that consistent, steady progress — even if it’s slow — gets you further than burnout cycles.

The tortoise wins for a reason.

Stay in your lane, keep showing up, and trust the compound effect.

5. Procrastination Leads to Frustration

I’ve mastered the art of procrastination — and hated how it made me feel. The longer you delay a task, the more it hangs over you.

That mental weight turns into frustration, and it’s rarely worth it.

Get it done. Get it off your mind.

6. Be Present With Yourself

There’s power in silence. In not reaching for your phone. In driving without music. In sitting without distraction. Our brains are overstimulated. Presence gives you peace, clarity, and creativity. Practice being still. It changes how you work and how you think.

I’ve started doing small things: no music during drives, no podcast in the shower, no background noise while waiting in line. It helps me notice the world, my thoughts, and my environment.

Stillness isn’t empty — it’s clarity.

7. The Future Is Closer Than You Think

You blink and it’s five years later. I can vividly remember being 18, 19, 20 — it wasn’t that long ago.

You realize you could’ve started that project, changed that habit, made that move. Life moves fast. Time moves fast — faster than we think. Goals that feel far away will arrive quicker than you expect.

If you’ve been delaying something, start now. The future is around the corner.

8. The Future Is Also Further Than You Think

At the same time, one year is a lot of time. You can change your career, health, and relationships in a year. Heck, you can change your life in 6 months.

Two years is enough to break cycles, learn new skills, or move across the world. Don’t underestimate how much can be built slowly, with intention.

Keep your head down and build. Let time work for you — and be consistent.

9. If You Don’t Stand for Something, You’ll Fall for Everything

My dad said this to me growing up, and now it fully clicks. Without strong values, you become easily swayed by opinions, trends, and noise.

Stand firm in your beliefs, your ethics, your purpose — or risk living by someone else’s.

Stay grounded. You can be open-minded and firm at the same time.

10. You Rise to the Level of Your Standards

Set high standards for yourself. I do — in work, relationships, and goals. Not everyone will meet your standards, and that’s okay. Just don’t lower them to make others comfortable.

Hold yourself accountable, and let others meet you where you are.

11. Choose What You Let Stress You Out

Stress is inevitable; however, not all stress is equal. But you can choose what kind of stress you accept.

For me, I’m okay with my work stressing me out because I understand it and I can manage it. But unnecessary personal stress? That’s a no.

Learn to say no to draining situations and yes to peace.

12. Learn to Say “No” More

As someone who creates content and leads a community, I always want to help everyone. But I’ve learned I can’t — and that’s okay.

I’ve had to learn to say no, even to good things, to focus on the right things. So, say no to things that don’t align with your capacity or priorities.

Time and energy are finite. Protect them.

13. Say “Yes” More (To The Right Things)

On the flip side, say yes to opportunities that stretch you.

Early in my journey, I said yes to everything — and it taught me what to say no to later.

Saying yes to jobs, projects, and partnerships helped me grow, collaborate, and build something meaningful.

Join a vibrant cybersecurity community of around 6,000 people who are constantly engaging in conversations and supporting one another—covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

14. Do Something Outrageous Every Year

Push the limits. Not recklessly — but intentionally. Try something bold: a solo trip, a skydiving session, a new challenge.

Remind yourself you’re capable of more than you think.

15. Build Systems, Not Just Routines

Routines can become rigid. Life changes. But systems? Systems adapt.

When I shifted from evening workouts to morning kettlebell sessions, my system stayed the same — just the timing changed.

Build adaptable structures around your life. Build frameworks that survive chaos.

16. Read More

Most content today is diluted. Books go deeper. They give you the full picture, not just the summary.

Reading has helped me slow down, think clearer, and understand complex ideas.

If you want to grow, read like it’s your job.

17. Become a Better Communicator

Communication is one of the most underrated skills in both life and cybersecurity. Whether it's how you talk to your team, present in meetings, explain ideas, or connect with strangers — clear communication makes a massive difference.

Five years ago, I wasn’t as effective at communicating as I am now. Creating content, working in tech, and navigating corporate environments helped me learn how to listen better, ask better questions, and present myself more confidently.

If you want to grow your influence, impact, or network — become a better communicator.

18. Procrastination Robs You of the Life You Could’ve Lived

This one hit me hard. Procrastination isn’t just a delay — it's a thief. It steals potential. It quietly holds back the life you could be living right now.

I’ve had moments where I was like, “Man, if I had done this earlier, who knows where I’d be today?” I don’t want to live with that regret.

So I’m learning: Take action when the idea is fresh.

Do the thing now, not someday. “Someday” often turns into “never.”

19. You Can’t Always Be Present for Everyone

When you’re someone who genuinely cares about people, you want to be there for everyone — reply to every DM, support every friend, show up for every event.

But you can’t pour from an empty cup. I’ve learned to set boundaries. Some people only know how to take, and if you’re not careful, you’ll burn out trying to give them more than you have.

Be present for the people who matter — but protect your own peace too.

20. Obedience > Sacrifice

This one comes from my faith. It’s possible to be doing “good” things — helping others, building things, making moves — and still be out of alignment with what God has called you to do.

I've learned that obedience to that purpose brings more peace than any sacrifice ever could.

Sometimes the most powerful thing you can do isn’t to hustle harder — it’s to listen and follow the path you’re meant to walk.

21. Embrace Chaos and Disruption

I like structure. I thrive in routine. But life doesn’t always play by your rules. Chaos happens — burnout, career shifts, heartbreak, unexpected opportunities.

In the past, those seasons would shake me. Now, I lean into them. I look at chaos as a chance to learn, adapt, and grow.

Resilience isn’t built in comfort — it’s built when everything feels uncertain, and you keep showing up anyway.

22. Don’t Prolong Unhealthy Relationships

Sometimes we hold on to relationships — friendships, romantic, or even family — because of history or guilt. But I’ve learned that if something is consistently unhealthy, it’s okay to let go.

You don’t have to hate them. You don’t have to make it dramatic. But you do have to protect your peace.

Not every relationship is meant to last forever — and that’s okay.

23. Keep God First

This is the foundation of everything for me. Every time I drift away from my faith, I feel it — mentally, spiritually, emotionally.

But when I’m aligned with God, everything falls into place. I don’t mean life becomes easy. I mean, life becomes anchored. I feel rooted and established. Unshakeable. Untouchable.

If I’ve learned one thing that will always guide me, it’s this: When I keep God first, I walk with peace, clarity, and confidence — no matter what season I’m in.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Recent Content

A few publications I’ve released recently.

Governance, Risk & Compliance (GRC) Engineering with Ayoub Fandi | Cyber Stories Podcast EP 24

A conversation with Ayoub Fandi, a Staff Security Assurance Engineer at Gitlab and host of the GRC Engineering Podcast, as we discuss transforming GRC from a cost center into a strategic product through automation and engineering.

Ayoub shares his journey from aspiring economist to successful cybersecurity professional. We explore whether GRC is technical and introduce GRC engineering, which uses engineering practices to enhance governance, risk, and compliance. We highlight the shift in GRC professionals' backgrounds and how technical skills improve GRC workflows.

We also emphasize the importance of cybersecurity knowledge in GRC roles and what it means to operate at the staff level.

This conversation offers invaluable insights for aspiring staff engineers, including advice on getting into GRC and building a career in GRC Engineering.

Cyber Stories Podcast

Governance, Risk & Compliance (GRC) Engineering with Ayoub Fandi

A conversation with Ayoub Fandi, a Staff Security Assurance Engineer at Gitlab and host of the GRC Engineering Podcast, as we discuss transforming GRC from a cost center into a strategic product through automation and engineering. Ayoub shares his journey from aspiring economist to successful cybersecurity professional. We explore whether GRC is technic…

Listen now

2 years ago · 1 like · Day Johnson

FAANG Cybersecurity Engineer Reacts to Cybersecurity TikTok Advice

Bringing some cybersecurity reaction content back to the timeline...this one was a mixed bag. Lots of really great advice and some really bad

How To Learn Cybersecurity Fundamentals - Computer Networking (Breakdown)

For the longest time, I've been a strong proponent of learning cybersecurity fundamentals, especially computer networking. This video demonstrates how to approach this.

23 Things I Have Learned As a 23 Year Old Cybersecurity Engineer ~ Day's Engineering Diary EP14

The YouTube version of this post!

Closing

Once again, you made it this far :)

These aren’t just things I’ve learned — they’re things I’m living through. 23 has already come with its own challenges and lessons, but I’ve never felt more grounded, focused, and expectant. If anything here resonated with you, thank you for reading.

Feel free to reply, share your own lesson, or pass this on to someone who needs it.

Thanks for reading. If you so desire, subscribe and restack - it helps spread the word and keeps me writing content. If not, I’ll see you around…somewhere on the internet!

I'm going to guide you through the process of becoming a cybersecurity engineer, with a special focus on Defensive Security Operations Engineering, which includes high-demand roles like threat detection and incident response.

These roles are crucial in defending organizations from cyber threats and are highly technical and among the most demanded and well-compensated in the cybersecurity field.

About Me

If you’re new here, my name is Day, and I’m a Security Engineer at Amazon with a previous focus on Incident Response Engineering and a current focus on Proactive Security Operations covering Threat Hunting, Threat Intelligence, & Adversarial Emulation.

In the past, I’ve worked as a Detection Engineer at Datadog, where I focused on Cloud, Network, Endpoints, and SaaS Applications. And have also previously worked as a Tier 1/Tier 2 Analyst at various SOCs & MDRs.

With all of this experience, I will give you a step-by-step road map to get you to become a cyber security engineer even if you don't have a degree or any technical knowledge yet; as a matter of fact, this newsletter has no college education requirements.

I personally was able to break into cybersecurity as early as my freshman year of college. I’ve gotten several jobs and interviews prior to ever having a college degree, and I’ve helped thousands of people do the same on my various content channels and in my Discord Community.

Join a vibrant cybersecurity community of over 6,000 people who are constantly engaging in conversations and supporting one another—covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

Establishing a Foundation

When you’re getting started on your journey to becoming a Security Engineer, this journey can start from various points, whether you're currently in an IT role, such as a network engineer or a systems administrator, or even in a Security Role, like a SOC analyst, or entirely outside the tech industry, such as nursing or retail.

The critical first step you need to take is understanding the fundamental concepts of cybersecurity, which will form the backbone of your expertise in threat detection or incident response.

Educational Pathways and Certifications

To build a strong foundation in cybersecurity, I recommend pursuing certifications & training that provide a blend of theoretical knowledge and practical experience.

Cybersecurity Basics

Opt for industry-recognized certifications like Google’s cybersecurity certificate or Microsoft’s cybersecurity analyst certification.

These programs are specifically designed to equip you with essential skills and include hands-on labs, which are crucial for grasping the intricacies of security operations.

The great thing about the hands-on labs is you get to practice what you learn, so things make a lot more sense when you’re using those skills in the real world as a cybersecurity engineer.

The Google Cybersecurity Training includes labs that teach you Linux, which is a core skill for any cybersecurity engineer; MySQL, which will help you understand the basics of data analytics; and Python, which will be super important for scripting and automation - more on this later in the newsletter.

I also like that this program prepares you for CompTIA Security+, which is a staple foundational certification in the security industry.

My first impressions of the Google Cybersecurity Professional Certificate:

On the other hand, the Microsoft Cybersecurity Analyst Training will introduce you to the Microsoft Azure cloud and the Microsoft Sentinel platform - this is great because you get an introduction to a top cloud provider and, on the other hand, atop SIEM (Security Information & Event Management).

This program also prepares you for the Microsoft Security Operations Analyst Certification, which is also another great certification.

Is the Microsoft Cybersecurity Analyst Certificate Worth It?:

Computer Networking

Another foundational skill that you need to give significant consideration to and should never be overlooked if you want to become a proficient and effective cybersecurity engineer is an understanding of computer networking.

This skill is integral to cybersecurity as it provides the necessary knowledge to comprehend how data moves and communicates across systems.

You’ll need to understand the basics of IP addressing, Public & Private IP addresses, Network Address Translation or NAT, CIDR Notation, routing, network ports & protocols like HTTP, DNS, SSH, LDAP, etc.

You’ll also need to know the basics of Network Types & Topologies like peer-to-peer, client-to-server, Local Area Networks or LAN, Wide Area Networks or WAN, and so on.

All these can be learned from a good CompTIA Network+ course like the one from Professor Messer here on YouTube or paid ones on Udemy from Jason Dion.

Now, you don’t necessarily have to take this certification, but the knowledge you’ll gain from understanding how networks work will be extremely invaluable to your cybersecurity career.

I’ve landed several jobs, including my current job, just because of how I showed my strong understanding of networking during my interviews - do not overlook this skill at all.

Heck, dare I say you can not be a competent Cybersecurity Engineer without the basics of networking.

In this mini-course, we're going back to the basics. Many cybersecurity professionals don't fully understand how standard protocols and networking concepts work, largely because they've never interacted with these protocols beyond the theoretical level.

Think about it—have you ever seen how DHCP or ARP packets work? Do you genuinely understand packet encapsulation and decapsulation? Have you seen how TCP sessions end with reset packets or witnessed a TCP 3-way handshake? You'll find this mini-course valuable if you answered no to any of these questions.

In just over an hour, you'll level up your networking and protocol knowledge. My goal is to transform your theoretical knowledge from CompTIA Network+ or Security+ into practical understanding by showing you how to interact with these protocols and demystifying the complexities of computer networking.

ANY.RUN Security Training Lab

Gain practical knowledge, examine real-life scenarios, and become a cyber defense specialist with ANY.RUN's malware analysis course.

Learn Malware Analysis!

Specialized Learning in Threat Detection

Now, let’s talk about specializing in Threat Detection Engineering or Incident Response Engineering.

If your interest lies in any of these roles, you’ll typically be told that it's super important to become proficient in using monitoring and detection tools like Splunk or Crowdstrike, and while I think that is somewhat right, it is a half-truth.

All monitoring tools or detection tools are built on the foundation of native telemetry already provided by the system, be it cloud or Linux Windows - whatever the case is.

If you do not understand how these systems work or the threat against them, it does not matter how great you are at Splunk; you’ll never be able to detect anything.

This is precisely why I recommend understanding how a system works before trying to learn how to detect threats to it.

Let me give you a real-life example.

I was very new to the cloud when I first got my last job at Datadog. I had never done cloud detection engineering, but I had worked on some cloud security investigations in my previous roles as a SOC analyst.

However, in order to build detection rules and mechanisms for cloud threats, I first had to understand how the cloud worked.

One of my main projects was expanding our detection ruleset for Google Cloud, but I had never worked with Google Cloud in my life, so what did I do?

I dove into the documentation of Google Cloud, how IAM works, how the projects and organizations work, how resources are configured, service accounts, and several other things.

And you know how that helped me? In a matter of weeks, I was able to start building and testing detections for Google Cloud; I co-wrote an article on Google Cloud threat detection and even gave multiple talks on Google Cloud Threat Detection.

The moral of the story here is to replace Google Cloud with anything here - it could be Linux, windows, IOT, heck, it could be iPhones or Androids; the point I’m trying to get across is you need to understand the system, its intended use, and its weaknesses before you can detect any threats against it.

After this, you can then start learning tools like Splunk or Crowdstrike. The great thing about Splunk is that they offer free training that can take you from knowing nothing about it to becoming pretty decent at it.

You can also go through various tryhackme rooms that help guide you on Splunk and investigating with it. You can even deploy your own Splunk instance and ingest logs into it, as I’ve outlined in my cybersecurity home lab project.

I’ve made some videos on this, which you can find in my SecOps & Investigations playlist here.

A combination of strong system understanding and Splunk (or other SIEM tool) engineering will make you very suitable for detection engineering or threat detection roles.

The same thing applies to incident response. This specialization requires a thorough understanding of response processes and recovery strategies, and learning to manage and respond to security incidents effectively is key, but you’ll still need to understand the underlying system.

Deciding between Threat Detection and Incident Response:

Transitioning between Threat Detection & Incident Response:

Advanced Training in Incident Response

Now, how do you begin to build the core skills for these roles? This in itself is a whole breakdown, which I’ve covered in a previous video, covering several certifications and training to consider for various skills you might be looking to learn.

Everything from the BTL1 to the CDSA, BTL2, CCD and others.

In regards to training providers like Constructing Defense,13 Cubed, TCM Security DFIR DIVA, Purple Labs, XINTRA, and several others.

I highly suggest watching the video:

Hands-on practice and continuous learning

Now let’s talk about practice and labbing.

It is crucial to master the tools specific to your chosen specialization—whether threat detection systems like SIEM for detecting attacks or incident response techniques for mitigating them.

Each tool and technique requires a deep understanding of specific aspects of cybersecurity, such as network traffic analysis or log analysis for threat detection or forensics and crisis management for incident response.

So here are some platforms to help you practice these skills:

• ACE Defender

• BTLO

• THM

• Pwned Labs

• HackTheBox Sherlocks

• LetsDefend

• Cyber Defenders

• RangeForce

Applying your knowledge through these real-world simulations and practical labs is essential.

Start with foundational training on platforms like TryHackMe, which covers everything from basic security principles to complex system and application security tasks.

Then, advance to more specialized modules that focus on the intricacies of network and system security, malware analysis, incident management, etc.

Building Scripting and Automation Skills

The next thing you need to build on is your scripting and automation skills. In threat detection and incident response, having scripting and automation skills is very important.

You’ll need to automate redundant processes or make things more efficient, and scripting helps with this.

One of the best languages to start with is Python due to its simplicity and powerful capabilities.

Python is widely used in cybersecurity for automating repetitive tasks, parsing large amounts of data, and developing software tools.

With Python, you can automate boring or repetitive tasks and focus more on the strategic aspects of your job, such as threat analysis and incident response.

Starting with the basics, there are many online resources available to learn Python. I personally recommend learning Python the hard way through Zed Shaw, Code with Mosh’s Python course, and Code Crafters.

However, Codecademy, Coursera, and edX offer beginner-friendly courses that teach you Python programming fundamentals.

The key thing here is to pick a course and stick with it long enough to build your Python skills.

Once you have a good grasp of the basics, you can start exploring modules and libraries used explicitly in cybersecurity, such as Scapy for network analysis, pandas for data analysis, JSON for parsing JSON files, requests for making web requests, or BeautifulSoup for web scraping.

Also, various platforms provide cybersecurity-focused Python challenges that allow you to apply your newly acquired skills in practical scenarios.

For example, HackInScience’s Python challenges or Programming Hero’s 100-plus Python coding challenges are great resources for learning and practicing Python in cybersecurity.

Remember, the goal is not to become a software developer but to use Python to enhance your threat detection and incident response capabilities.

Therefore, focus on practical applications of Python in cybersecurity, such as automating data analysis, building simple tools, or integrating different security solutions using APIs.

Some other languages to consider will be Golang & Javascript, as they also help in various cybersecurity automation and integration workflows.

For scripting, Powershell for Windows and Bash for Linux.

Auxiliary Skills - Cloud & IaC

In addition to learning a programming language, understanding cloud and Infrastructure-as-Code is a crucial auxiliary skill for cybersecurity engineers focused on threat detection or incident response.

Cloud knowledge is essential because many organizations are shifting their operations and data storage to cloud-based solutions.

Therefore, cybersecurity engineers need to understand how to deploy and build security tools in the cloud, secure cloud-based infrastructure, how the data flow is managed, and how access controls work in a cloud environment.

They should be familiar with platforms such as AWS, Google Cloud, or Azure.

In addition to this, Infrastructure-as-Code (IaC) is a key concept in modern IT operations. It involves managing and provisioning computing infrastructure through machine-readable scripts rather than manual processes.

For a cybersecurity engineer, understanding IaC can help in automating security controls and policies.

It allows them to integrate security earlier in the development lifecycle, enabling a 'shift-left' in security that results in more secure and scalable systems.

Tools commonly used for IaC include Terraform, Ansible, Chef, Puppet, and many others.

Projects

In order to bring everything together, working on a few personal projects relating to cybersecurity can be an excellent way to strengthen and solidify these skills.

This can involve utilizing a range of tools such as Security Information and Event Management systems (SIEMs), Cloud technologies, Python programming, and Infrastructure as Code (IaC).

By actively building out these projects, you are able to gain hands-on experience and a deeper understanding of the intricacies involved in these various cybersecurity tools and how they work together.

Furthermore, these projects can serve as tangible evidence of your skills and knowledge, which can be outlined on your resume, and this not only enhances your professional profile but also provides you with concrete examples and experiences to draw upon during job interviews.

Ultimately, these personal projects can significantly boost your confidence and competence as a cybersecurity engineer.

Choosing a Pathway in Security Operations Engineering

Now, once you’ve established a solid foundation and gained some hands-on experience, it's time to choose a specific pathway within Security Operations Engineering.

Whether you decide to focus on threat detection or incident response, your path should be guided by both your interests and the specific needs of the job market.

Bear in mind that Cybersecurity is a field defined by rapid evolution and constant change.

Continuing your professional development through ongoing education, staying updated on the latest threats, and continually refining your practical skills are going to be necessary for your growth as a cybersecurity engineer.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Recent Content

A few publications I’ve released recently.

The Cybersecurity Bootcamp Industry & Level Effect w/ Anthony Bendas | Cyber Stories Podcast EP 23

A conversation with Anthony Bendas - Co-Founder at Level Effect, where he designs and delivers cutting-edge cybersecurity training programs, including the Cyber Defense Analyst Program. With over a decade of experience spanning penetration testing, security consulting, and engineering, he has built a reputation for translating complex security concepts into practical, real-world applications.

Cyber Stories Podcast

The Cybersecurity Bootcamp Industry & Level Effect with Anthony Bendas

A conversation with Anthony Bendas - Co-Founder at Level Effect, where he designs and delivers cutting-edge cybersecurity training programs, including the Cyber Defense Analyst Program. With over a decade of experience spanning penetration testing, security consulting, and engineering, he has built a reputation for translating complex security concepts …

Listen now

2 years ago · 1 like · Day Johnson

Building a DNS Server with Python - 1 (Repo & UDP Server Setup)

Starting a series on building a DNS Server with Python - guided by Code Crafters.

The Truth About The TryHackMe SAL1 Certification (Complete Review)

A breakdown of TryHackMe’s new SAL1 Certification.

Fastest Way To Become a Cybersecurity Engineer in 2025

The YouTube version of this post!

Closing

Once again, you made it this far :)

Thanks for reading. If you so desire, subscribe and restack - it helps spread the word and keeps me writing content. If not, I’ll see you around…somewhere on the internet!