I’ve watched too many people get into cybersecurity for the paycheck and quit three years later - burnt out, bitter, and blaming the state of the industry for their shortcomings.

The ones who stayed, fought through the adversity, and actually became good got in for a different reason entirely.

They got in for the passion. Upskilled and improved for the money. And stayed for the challenge.

That’s the only sequence I’ve seen work, and the exact sequence I’ve lived over the last six years.

And anyone expecting the same results but approaching it in a different order will find themselves eventually washing out.

So whether you’re just starting in the industry, are a few years in, or are thinking about breaking in - make sure you have the correct mindset before you do.

- Today’s Sponsor -

Reading about cybersecurity won’t get you hired. Practicing it will.

That’s what Defend the Org is built for - writing the detection, triaging the alert, leading the incident, running the threat hunt.

Hands-on labs designed, custom engineered by professional blue teamers, around the exact skills you’ll use on the job.

Whether you’re pivoting into cybersecurity, landing your first role, or upskilling up in your current one - DTO is where you get reps in.

Learn More

Get in for the passion

Passion is an entry-level requirement in this industry. It’s not just a tiebreaker for recruiters like you might find in other industries.

I didn’t get into cybersecurity because someone showed me a salary chart. I got in because it sounded badass.

That was the whole reason. It doesn’t need to be something deep.

The way cybersecurity got framed in media was what had me interested. A lot of marketing makes it look sexy and mysterious.

You’re the people who outsmart the bad guys.

This obviously is very far from the truth of what professionals do in their day-to-day, but at this point I had zero hands-on experience. The mystique got me interested.

But underneath the mystery I also had something more durable: I already loved technology.

I was studying computer science and interning as a software engineer right before I made the switch.

And before all of that? I loved video games. That was the original on-ramp (shout-out Watch Dogs) along with the curiosity about how things work, why systems behave the way they do, and what’s happening underneath the screen.

When I stumbled onto cybersecurity, it wasn’t a cold-start passion. It was a passion for technology that found its sharpest expression.

I get to set up the defenses. I get to outsmart attackers trying to break in. I get to think strategically against a real adversary.

That was enough to light the fuse.

And the fuse had to be lit, because this field will burn you out otherwise. Here’s what nobody tells you when you’re being recruited into cybersecurity by a TikTok salary screenshot:

• The field moves faster than almost any other in tech because malicious actors don’t sleep.

• You will always feel dumb in some corner of it. Cloud security, malware analysis, IR, detection engineering, identity - there’s always a domain that’s not yours.

• Threat actors don’t clock out at 5. Working after hours is part of the job - forever.

Without passion, all of that can feel like punishment. With it, it feels like the reason you showed up.

The burnout pattern is predictable. People who entered for comp tend to plateau around year three. They learned enough to be useful at one job, but they can’t summon the energy to keep learning.

Passion isn’t what makes you stand out later. It’s what gets you through the part where you’re still bad.

Improve for the money

Your compensation growing is the consequence of getting genuinely good.

The people clearing the top of the band became a valuable asset: a mix of general cybersecurity knowledge mixed with deep domain expertise. The money chased them.

Here’s what “improve for the money” actually looks like in practice:

• You’re reading threat reports to stay up to date with the state of the industry.

• You’re standing up lab environments on weekends to practice writing detections.

• You’re threat hunting at 11pm because something didn’t sit right.

• You’re not chasing certs - you’re chasing skills.

Three or four years of that behavior compounds.

You’re not interchangeable anymore. That’s where the money lives — not in the title or the certifications you have.

Your expertise has become irreplaceable.

I’ll be honest: money was a major motivator for me to keep pushing once I was in.

A promotion dangled in front of me was all I needed. Titles never moved me - but the dollar amount attached to a title? That made me move with a purpose.

And that mindset is completely okay to have.

I’m a naturally frugal person in many aspects of my life. Spending money on myself has always felt hard.

So at first, it was difficult to spend money on things that would develop my expertise faster: lab platforms, courses, mentorship.

But I had to reframe my mindset. I had to stop calling it spending, and start calling it investing.

And flipping the script made it stop feeling like an expense, and more like it was capital I was putting to work.

And every dollar I put in has already come back tenfold.

But this only works if the underlying passion is there. The chase is brutal otherwise.

Work-life balance in cybersecurity doesn’t always exist. You’ll work more than 40 hours a week. You’ll work 12-hour days. You’ll work weekends when an incident hits. You’ll be studying after work.

It’s nonstop.

If the only thing you came for is the paycheck, you won’t find the joy, and the math stops working pretty fast.

But the way the world is moving - AI increasing attack surface in an unknown way, adversaries benefitting from AI, and defenders struggling to keep up - the cybersecurity industry is going to be more lucrative than ever.

The money flows most to the person who would still show up if it didn’t.

How to Stand Out in the 2026 Cybersecurity Job Market

The Cybersec Café is now more than just a newsletter. Check out the partner content on the platform of your choice - YouTube, TikTok, Instagram or X.

Learn More

Stay for the challenge

There’s a third trap nobody warns you about: people who got in for the passion, got good, and made it to senior comp still leave the field.

Not because the money dried up but because they forgot to find the joy in what got them in.

The danger zone is somewhere around year five to seven: Comp is solid, the work feels easier, and the after-work labs have declined.

But the fire starts to dim because of those long hours, weekends worked, and difficult work.

What pulls you back is the part that’s actually unique about this field:

• No two days look the same. This is not just a marketing line, it’s actually true.

• There’s a real adversary actively trying to outsmart you. Almost no other job has an opponent like this.

• The problems are constantly evolving. New TTPs, new attack surfaces, new tooling, new defensive paradigms. It never stops moving.

For me, the things that keep me engaged are the same things I sometimes hate in the moment.

Take incident response.

I sometimes hate being in the middle of one - the late Fridays, the early mornings, the weekend pages.

But when I stop to actually look at what I’m doing? It’s a game of mental gymnastics. I’m trying to decipher what an attacker was thinking, how they got in, how they moved, what their goal was.

That’s challenging, and honestly fun.

Detection engineering hits the same nerve.

After every incident, the question becomes: how do I detect this (or any derivative of it) if it happens again?

It’s like coaching a football game. When an attacker calls a play, did I watch enough film to recognize the formation before the ball is snapped? In other words, did I build the right detection?

Threat hunting is its own joy. 99% of hunts turn into nothing. But the 1% that does? The thrill of catching a real adversary red-handed before they’ve acted and spinning up IR to box them in before they realize you’ve seen them - there’s no money that buys that feeling.

That’s the part you have to protect.

Take the project nobody understands yet. Lead the incident nobody wants. Build the detection nobody’s tried. Hunt on that hypothesis that probably goes nowhere.

The challenge is what kept you here in the first place. It’s also the only real moat against your skills going stale.

Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. Engage in real-world security discussions and live events (coming soon!).

This is where the next generation of defenders can connect. Join for free below.

Join Now!

Approach it the Right Way

Cybersecurity rewards the people who would have done this work for free, pays them more than they could imagine, and hands them a new problem worth caring about every morning.

Get in for the passion. Improve for the money. Stay for the challenge.

That’s the only sequence that lasts.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe delivers Deep Dives on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X, Instagram, TikTok, YouTube, or my Website. Let’s keep learning, sharing, and leveling up together.

In six years working in cybersecurity, I’ve never been asked to hack a website.

That’s not the work.

My specialization is detection and response - and almost nobody talks about what it actually involves day to day.

Most cybersecurity news and content is built around offensive security: hack the box, find the flag, ship the writeup. That’s because that’s the type of security that sells, that grabs your attention and instills this notion of fear.

But a majority of cybersecurity jobs don’t look like that.

Here’s the actual skill stack I use as a detection & response engineer. Each one is a real lane of work with its own day-to-day tasks, but they all crossover with each other in one way or another.

- Today’s Sponsor -

Reading about detection engineering won't make you a detection engineer. Doing the work will - writing the detection, triaging the alert, leading the incident, running the hunt.

That's what Defend the Org is built for. Hands-on labs designed by blue teamers around the exact skills mapped out above. Real scenarios. Real data. Real defenders.

Whether you're pivoting into cybersecurity, landing your first role, or upskilling up in your current one - DTO is where you get reps in.

33% off Launch Sale ends in 1 week!

Learn More

Detection Engineering

Detection engineering is the work of writing the rules that catch attackers in your environment.

Every alert that fires in a SOC came from a detection somebody wrote - and this is a fundamental part of the role (it’s literally in the name).

The task is to understand how attackers behave - the commands they run, the files they touch, the actions they’d make when acting maliciously - and translate that behavior into a query that runs continuously against your log data, extracting this activity as it happens in near real-time.

In practice that means reading threat intel reports and turning them into detections, writing queries against telemetry from EDR, cloud platforms, identity providers, and network sensors.

Tuning rules so they catch the bad without paging the on-call for every benign admin action.

And unit-testing detections against known malicious samples before shipping them to production.

It’s writing code to stop the worst day of your company’s life before it happens.

Data Analytics

The single most leveraged skill in modern detection & response. Every other skill on this list touches data in one aspect or another.

Modern security platforms are running data lakes - Snowflake, BigQuery, Databricks, Athena. Your detections, your hunts, your dashboards. They all rely on turning big data into a story you can act on.

If you understand how to analyze data and can write a tight query against three joined tables of telemetry, you can do this job. If you can’t, you’ll spend your career waiting on people who can.

Day to day this looks like writing detection logic against authentication, process, network, and cloud audit logs, joining EDR telemetry against identity data to scope blast radius during an incident, pulling 90-day windows out of a multi-trillion-row warehouse without getting killed by the optimizer, and building the metrics that prove your team is working and improving.

Data analysis is the skill where the gap between “can technically write a SELECT statement” and “can answer hard questions fast under pressure” is the widest.

Closing that gap is an integral part of this job.

Programming

Programming is the glue between engineering and operations. Every team I’ve been on has had tooling that relies on scripting in some form, or custom tooling that requires maintenance and upkeep.

No matter what everyone tells you - cybersecurity engineers are required to understand programming fundamentals, especially in DnR.

Python is the friendliest to learn and has the largest potential impact if you’re just starting out.

Day to day often looks like writing scripts to parse data, building enrichment pipelines, automating the boring parts of incident response, and even writing detection-as-code depending on your SIEM.

You don’t need to be a fully fledged software engineer. But you do need to be the professional who can throw together a hacky solution when under the gun.

Threat Hunting

Threat Hunting is like Detection Engineering’s free-form cousin. Detections fire on behavior you’ve already defined, hunting is what you do when you suspect there’s behavior you haven’t defined yet.

Hunters often start with a hypothesis - “if an attacker were living off the land in our M365 tenant, what would that look like in our sign-in logs?”

Then its up to the hunter to go pull the data and see if the signal is there. Sometimes the hunt finds active compromise. More often you end up reasoning and finding a gap in your detection coverage, which becomes the next detection you write.

To be a great hunter, you need the strong mind of a data analyst, the technical skills to iterate on queries quickly, the mind of an attacker to embody what a malicious actor would do, and the perspective of a defender to understand how to catch a threat actor.

Hunting is the skill that allows you to continue to bolster your defenses aganst the attackers you haven’t seen yet.

Incident Response

When all your defenses fail, this is what happens.

A real incident has phases - identify what’s happening, contain the blast radius, eradicate the threat from the environment, and recover the affected systems.

Each phase requires a different set of brain muscles.

Containment is about cutting the attacker off without spooking them into burning your environment.

Eradication is about being really sure that you got everything.

Recovery is about restoring service without restoring the foothold.

And security engineers in detection and response are expected to fill the different pieces of this operational workflow - anywhere from incident commander to an individual contributor.

Leading an incident often means coordinating cross functionally with many teams:

• Engineering when it involves the product

• Legal when an incident escalates

• Account executives when it involves a customer

While the goal is to not get popped - the reality is, you will. And when you do, you’re not running the response alone.

IR is the highest-stakes lane on this list. The clock is always running.

What is Detection & Response?

The Cybersec Café is now more than just a newsletter. I started creating content on YouTube, TikTok, and Instagram.

Learn More

Security Operations

Detection engineering writes the rules. Security Operations is the skill that lives in their output.

Security Operations is the operational muscle of cybersecurity - the people in the queue, on the rotation, dispositioning alerts as they come in. Every detection you write eventually fires on somebody’s shift, and that somebody is a Security Operations engineer or analyst making the call: is this real, is this benign, do we escalate.

Day to day this looks like triaging alerts coming out of the SIEM, running playbooks against the ones that turn out to be real, escalating to incident response when scope grows, feeding false positives back to detection engineering for tuning, and owning the on-call rotation that keeps the lights on 24/7.

Security Operations is the dsicipline where most cybersecurity careers start, and where most of them stay. It’s also the lane that hands every other skill on this list its feedback loop - if your detections are noisy, Security Operations tells you. If your hunts produce nothing useful, Security Operations tells you. If your IR playbooks fall apart under pressure, Security Operations is where you find out.

MITRE ATT&CK

MITRE ATT&CK is the framework that functions as a shared language defenders use to talk about attacker behavior. Without it, every team would be reinventing their own taxonomy for “the bad guy did X.”

The framework is a structured catalog broken into tactics (the why) and techniques (the how) attackers use.

A detection isn’t really shippable until it’s mapped to a technique.

A threat intel report isn’t really actionable until you’ve extracted the techniques it describes.

A coverage gap in your detection program isn’t really visible until you’ve laid your detections against the matrix.

Think of it like the periodic table of cybersecurity.

Code Review

Cybersecurity engineers review code constantly.

Some of it is friendly code: detection-as-code PRs from teammates, internal tooling, automation scripts - with the main job being to make sure the logic matches the intent, the tests cover the failure modes, and the rule won’t drown the on-call when it ships.

Some of it is hostile code: PowerShell payloads pulled off a compromised endpoint, obfuscated JavaScript dropped by a phishing landing page, malware samples extracted from a sandbox.

And the reality is that it won’t always be in a programming language that you know how to write.

But part of the skill is understanding logic, reasoning on syntax, and figuring out exactly how it fits into the bigger picture.

Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. Engage in real-world security discussions and live events (coming soon!).

This is where the next generation of defenders can connect. Join for free below.

Join Now!

Cloud Security

The way we think about perimeter is fundamentally different than it was 10-15 years ago. The thing you used to defend with a firewall is now a policy written in terraform or another configuration language.

The cloud attack surface looks different than the traditional on-premise network - stolen access keys, OIDC token abuse, role chaining, over-privileged service accounts, exposed metadata endpoints.

And the telemetry looks different - CloudTrail, GCP audit logs, Azure activity logs, are the language we have to learn how to speak (and again, ties back to data analysis).

You may find yourself writing detections against or hunting through cloud audit logs, reviewing IAM policies and trust relationships for over-privilege, responding to an incident siloed to the cloud, and building telemetry pipelines to ingest audit logs to your SIEM.

Every defender on the planet is becoming a cloud defender, whether they wanted to or not.

Software Engineering & System Design

The difference between scripting and engineering is durability. A script is extremely limited in scope.

Real, enterprise-grade software gets written, deployed, tested, verisoned, and maintained.

It starts with secure system architecture. You may find yourself designing systems from scratch, or reviewing systems from a security perspective before they get built - the services, data flows, trust boundaries, integrations.

Software engineering is more than just coding - it’s reasoning about how systems can break, how they scale, and how they become maintainable.

Detection & Incident Response teams function more like a traditional software engineering team than you might think, with the tools, processes, and deployment pipelines that have become a staple of security engineering.

Most security teams underinvest in this skill. But the best DnR engineers are system thinkers first, and especially in today’s AI age - programmers second.

The Truth about Detection & Response

If you’re not deep in the weeds of security engineering, especially Detection & Response - it may be hard to believe just how adjacent it is to so many other disciplines.

That’s because both engineering and operational efforts tie so closely to the entire environment because every organization needs visibility over their systems, and a team ready to respond in the case of a security incident.

But don’t let that scare you. When people say Detection & Response isn’t an entry-level job, they’re not lying. It’s tough to get into off the jump because of how much knowledge you need across the entire stack of an organization.

What matters is understanding the pieces that go into becoming a detection & response engineer, and putting in the work to develop your skill set to get there.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe delivers Deep Dives on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X, Instagram, TikTok, YouTube, or my Website. Let’s keep learning, sharing, and leveling up together.

Cybersec Café community - it’s been a while

Six months, to be exact.

A lot has happened in that time. New job. A front-row seat to the chaos and acceleration of AI. And experimenting with new forms of content (you might’ve seen me on IG or TikTok).

But honestly… it feels good to be back. Sitting down, reflecting, writing - getting my thoughts out again.

Today, I want to talk about how Security Engineering has changed - fast - because of AI.

In just a few months, we’ve seen massive leaps in capabilities: skills, knowledge bases acting as brains, advanced reasoning, and ever expanding context windows.

And these shifts are actively reshaping how the job is done.

I want to contrast what the role looked like just 6-8 months ago vs. what it looks like now. And why, even with all the hype around tools like Anthropic’s Mythos and the sea of other AI tools - cybersecurity is still one of the best careers you can be building right now.

- Today’s Sponsor -

Stop studying for your fifth certification.

Employers don't want proof you can pass a test. They want proof you can do the job - write a detection, triage an alert, lead an incident, conduct a threat hunt.

That's what Defend the Org is built for. Hands-on labs based on the skills you’ll actually use on the job - built from the ground up by blue teamers.

Whether you’re trying to pivot into cybersecurity, land your first role, or upskill in your current one - start getting reps in at Defend the Org.

$29/month or $300/year $20/month or $200/year for a limited time.

Learn More

Security Incidents

SIEM Alerts are still a thing of the present and future. But the way we triage, escalate, and remediate them is shifting.

Automation and AI reasoning has made reducing throughput less of a concern, and put an emphasis on deciding where human intervention is required.

Before

A SIEM alert fires - and everything starts with the analyst.

You’d run queries to build context: normal activity, login locations, user role, recent behavior.

From there, it was a mix of experience and whatever playbooks existed (if they existed at all).

The analyst would:

• write queries

• stitch together a timeline

• interpret the data

• and ultimately decide: true positive or false positive

If it escalated, an incident would be declared and handed off to Incident Response.

From there, the process was still heavily manual: tracking timelines, coordinating actions, writing updates, and eventually documenting the full incident lifecycle.

End-to-end, it was a deeply hands-on process.

Running an incident wasn’t just technical - it was a full-time coordination effort.

Now

What used to take hours of manual effort now starts with AI.

Alerts are triaged by agents that integrate directly into your tooling through MCP servers - pulling logs, correlating signals, and building context automatically.

With reasoning models like Claude Opus, a basic playbook is no longer static - it’s something that can be iterated on in real time.

In minutes, you can get:

• a structured timeline

• correlated evidence across systems

• and an initial determination

Faster than any human analyst could realistically produce.

The analyst’s role shifts from doing the work to validating and directing it.

If deeper analysis is needed, you don’t jump back into manual querying - you instruct the agent to go further.

If it’s a true positive, escalation still happens - but now you’re working alongside specialized agents across the incident response lifecycle:

• containment suggestions

• automated remediation steps

• real-time documentation

• even post-incident write-ups

Are hallucinations and false positives still a concern?

Yes - but with a human in the loop, the upside is too hard to ignore.

We’re even seeing scheduled workflows that:

• build timelines automatically

• generate incident reports

• and propose improvement actions before the incident is even closed

Security incidents haven’t become easier - the way we approach them has changed.

Less hands-on keyboard work. More high-level thinking, validation, and orchestration.

Detection Engineering

Just over a year ago, I wrote my most popular article: to date: My SIEM-Agnostic Creative Process to Detection Engineering.

And while the core ideas still hold (how to think about coverage, how to create value), the way I approach the technical process behind Detection Engineering couldn’t be more different.

Before

Detection ideas came from everywhere:

• OSINT

• incident learnings

• threat models

• or the need to cover a new log source

From there, the process was… manual.

You’d dig through documentation, search open-source detection repositories, and piece together ideas that might work in your environment

There was a lot of strategy involved - making sure coverage was meaningful, not just surface-level.

My personal workflow always included a mini threat hunt: explore the log source, understand what “normal” looked like, and identify high-leverage behaviors that might’ve been missed.

Then came the build phase:

• translate ideas into detection logic

• write unit tests

• deploy and monitor over weeks

Tuning was inevitable - balancing signal vs. noise, adjusting thresholds, refining logic.

It was a craft. And it took time.

Now

The barrier to building detections has collapsed.

With modern AI, detection engineering has shifted from manual construction to guided generation.

In a single afternoon, I can generate multiple detections, create unit tests, and produce full documentation of the attack surface being covered.

As long as I’ve clearly drafted my use case.

I don’t even need a deep, upfront understanding of the log source or its schema anymore.

With access to my datalake via MCP and the ability to parse documentation instantly, AI can explore the data, identify patterns, and propose detection strategies for me - significantly reducing the front-loaded phases that used to come with detection engineering.

Whether I’m building a detection suite from scratch, identifying coverage gaps, or looking for exception opportunities - the model can generate a structured plan in minutes.

From there, it’s a short step to production:

• convert to detection-as-code

• attach metadata and tests

• pass CI

• deploy

Are these detections always deeply complex out of the gate? Not necessarily.

But with the right inputs and iteration, these models can produce detection logic that rivals, or even exceeds what most engineers could write manually.

Faster too.

The tradeoff is the same as everywhere else: you still need a human in the loop. But the time to ship has become insane to think about.

Detection engineering is no longer bottlenecked by creation. It’s bottlenecked by judgment, testing, and monitoring.

The time-to-value is faster than anything this field has seen before.

Runbooks

Runbooks used to be a necessary evil.

Evil because no one liked writing them.
Necessary because they could dramatically reduce time to remediation.

AI has completely flipped that dynamic.

Before

Runbooks were written by humans, for humans.

They followed rigid, workflow-style logic:

• if this → then that

• branching decision trees

• copy/paste queries into the SIEM

• step-by-step paths from alert to resolution

They were structured, but brittle. And keeping them up to date was a constant struggle.

Every triaged alert should have fed back into improving the runbook to ensure it was current. But in reality, that work often fell behind. Manual upkeep rarely wins against more urgent tasks.

And coverage was always incomplete. Runbooks typically existed for the most common scenarios or the most critical alerts.

Everything else? You’re on your own.

That 6am medium-severity alert that suddenly escalates… no runbook, no guide - just the analyst trying to figure it out, and often resorting to pulling in a more senior engineer for assistance.

Necessary? Absolutely. Loved? Depends who you ask - the person using it, or the person writing it?

Now

Runbooks are no longer written for humans. They’re written for machines, by machines - typically as structured, deeply detailed markdown.

Designed end-to-end by agents.

The format hasn’t fundamentally changed.

However, instead of manually crafting every branch and edge case, you can:

• feed in detections

• reference your knowledge base

• and let an LLM generate a near-complete runbook

In just a few minutes.

These runbooks essentially function as executable logic for agents:

• how to triage

• how to enrich

• how to escalate

• how to remediate

And because they’re machine-consumable, they scale in a way human-written runbooks never could.

The human role doesn’t disappear - it shifts.

You’re no longer writing from scratch. You’re reviewing, drafting refining instructions, and validating output.

LLMs still struggle with higher-level judgment, but they’re more than capable of getting runbooks most, if not all, of the way there.

And when paired with detection-as-code, the impact compounds. When you have your detections and runbooks all living as code under the same roof, your agents now have access to your entire suite as a knowledge base to reference against.

In a modern security team, “everything as code” isn’t aspirational - it’s become the standard.

Automations and Workflows

Security teams have relied on deterministic workflows for ages.

But AI has made a lot of that infrastructure feel… outdated.

Who needs to create custom functions to call APIs anymore when MCPs exist?

Before

What we now call “agentic workflows” used to exist as automations — primarily through SOAR platforms.

And to be fair, SOAR was powerful.

It gave teams the ability to automate triage steps, enrich alerts, trigger response actions - but everything was deterministic.

If you didn’t explicitly define a step, it didn’t happen.

Which meant every detection needed its own workflow, every query had to be written ahead of time, and every edge case had to be anticipated.

Even when detections were similar, workflows had to be manually reviewed and adapted. Scaling this across a growing detection suite was a massive lift.

Unless you built it perfectly from day one, maintaining it became its own burden.

With that said, when it worked, it really worked - and it felt magical at the time.

At a previous company, after fully implementing a SOAR platform aligned with our detection suite, we saw:

• ~80% reduction in average time to resolution

• hours of analyst time saved per week (can’t remember the exact amount)

For its time, SOAR was ahead of the curve - and we must tip our hats to those that came before AI.

Now

The shift from automations to skills is a step up, not just an iteration.

Skills are the building blocks of modern, agentic workflows. And in security engineering, they’re delivering the same kind of impact SOAR did at first, just amplified by at least 10.

Any repeatable part of your workflow should be a skill. If it’s not, you’re leaving leverage on the table.

The difference now is flexibility. Instead of hardcoding workflows, you:

• define capabilities (skills)

• give agents access to tools (via MCP)

• and let them decide how to execute

These systems are no longer waiting for exact instructions, they’re reasoning through the problem space.

In practice, this looks like:

• Every alert triggering an automated triage workflow
  → reading the runbook
  → gathering context
  → closing benign positives automatically
  → or escalating when needed

• Incidents invoking specialized skills
  → handling repeatable response actions
  → coordinating investigation steps

• Even PR reviews becoming a target for automation
  → reducing friction in how quickly teams can ship

And the barrier to entry is lower than ever.

You can describe a skill in plain language, have a model generate it, schedule or event-trigger it, and deploy it in minutes

What used to take weeks of engineering effort now takes an afternoon.

Less hands-on keyboard. Less rigid workflow design.

More orchestration. More system-level thinking.

The work hasn’t just disappeared into thin air, it’s moving up a layer and requiring us engineers to adjust with it.

Multi-tasking

AI has changed how the world thinks about productivity. It’s enabled a form of multi-tasking that just wasn’t possible before.

Before

Attention and bandwidth were everything.

A single critical alert could consume an analyst’s entire day. Two at once? You’re probably underwater.

A Sev1 incident could derail an entire week for an incident responder.

A detection might take days to move from idea, through development, just to hit the staging environment - not even production yet.

Even experienced engineers, the ones who could juggle both engineering and operations, were still constrained.

Most were effectively siloed to: one incident and one project or initiative at a time

Not because we couldn’t think across multiple problems, but because execution was limited by what you could physically do, by hand, in a sprint.

And context switching? Expensive.

Switching between tasks too frequently usually slowed you down more than it helped. So the solution was structure: block time, focus deeply, close out tickets sequentially.

You could balance types of work (ops + engineering), but rarely multiple engineering efforts in parallel.

Now

Now it feels like everything runs in parallel. Because, in a way, it does.

The biggest shift for me was to think of every task as if I have an intern assigned to it.

I need to give that intern clear instructions, but the could set it free to run in the background and it would come back to me with a structured output or plan a few minutes later.

All while I can move on to work on something else.

A typical workflow might look like:

1. Kick off an alert investigation skill

2. Spin up a detection development workflow

3. Actively working on a separate engineering project

All at the same time. It’s honestly insane to just think about.

The mental model has changed to “If I’m actively working on something, I should also have agents working passively in the background.”

If the tokens are there, you should be using them.

But this shift comes with a cost.

The volume of output has increased dramatically. What used to fill a two-week sprint can now happen in days.

And that compression creates a new kind of pressure - more decisions. More context to track. More high-level thinking, more often.

The low-level work has been abstracted away. But the cognitive load hasn’t increased.

Engineers aren’t necessarily doing more work… but they are operating at a consistently higher level of intensity.

And that’s something I don’t think we’ve fully adapted to yet.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

So where is security engineering headed?

Nowhere.

At least not in the way people try to fear-monger you into thinking.

The release of Mythos is an example - an advanced reasoning model to find vulnerabilities at a speed no one can fathom. An amazing feat of engineering nonetheless.

But cybersecurity has never been just about code vulnerabilities. That’s only a small slice of the problem.

The real value is in domain knowledge:

• Understanding how attackers think

• Knowing how systems fail

• Being able to analyze and interpret data (and use LLMs to assist you)

Those skills are becoming more valuable - not less. And if you’re considering a career shift to cybersecurity, I think it’s worth understanding where the leverage is shifting.

Right now, I’d place my bets on areas like:

1. Detection & Response: An end-to-end understanding of your environment - how to detect, investigate, and mitigate threats. AI can assist here, but it still struggles to fully grasp the nuance and context required to make the right calls.

2. Infrastructure Security: We’re operating in a cloud-first, AI-driven world. Infrastructure is evolving fast, and securing it requires engineers who understand both the systems and the strategy behind them.

3. Application Security: AI is getting very good at finding vulnerabilities. But security doesn’t stop there. It’s about embedding security into the development lifecycle, driving remediation, and building systems that are secure by design.

The role of the security engineer isn’t being replaced, just elevated.

Less hands-on execution. More judgment. More strategy.

The opportunity is expanding for those willing to adapt.

–

On a final note, while I don’t plan on writing as frequently as before - it feels great to be pressing publish on another article at the Cybersec Café.

I’m looking forward to showing up in your inbox more consistently throughout 2026 than I did in Q1.

Thanks for continuing to follow along at the Cybersec Café!

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe delivers Deep Dives on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X, Instagram, TikTok, YouTube, or my Website. Let’s keep learning, sharing, and leveling up together.

A couple months back, I shared how I built a Detections-as-Code MVP implementation for my small security team using the DataDog SIEM - walking through the design decisions that let me ship an early version fast and start reaping the benefits of an “as-code” workflow within just a couple of weeks.

If you haven’t read that one yet, I’d recommend jumping back there first so this part makes more sense: https://www.cyberseccafe.com/p/detections-as-code-in-datadog-how

One of the key benefits I mentioned briefly was automated testing through the CI/CD workflow, and that’s exactly what we’re diving into today.

I’ll break down how I test detections end-to-end, how this fits into the automation pipeline, and how you can replicate it in your own environment.

And for subscribers, I’ve set up a demo repository that shows the entire implementation in action, Pt1 and Pt2 - available now inside Cybersec OS.

Let’s get into it.

The Methodology

Part of my solution is the methodology I use to ensure that a detection is truly ready to be pushed into production.

At its core, this approach serves as quality control, preventing broken or overly broad detections from slipping through and causing noise or missed alerts.

Now, there are certainly more advanced ways to test detections. In large-scale environments where cost and scale are critical, you could build out a full staging environment and validate detections there first.

But my goal here is speed and effectiveness. I wanted an MVP that serves as a practical, lightweight testing framework that adds confidence without slowing deployment down.

Requirements

Every detection must meet the following criteria before being merged:

• True Case (Mandatory) - Ensures the detection actually fires as intended. Each test must include at least one log containing all the necessary fields for the rule to trigger successfully.

• False Case (Mandatory) - Validates that the detection doesn’t fire when it shouldn’t. This prevents overly broad logic and reduces false positives in production.

• Edge Case (Optional) - An edge case should nearly match the detection logic but miss one key condition. This adds confidence that detections only fire under precise circumstances.

  • Example: if a rule is meant to trigger on specific actions except when performed by a known service account, the edge case would simulate the action from that service account, ensuring it correctly returns false.

• Additional Cases (Optional) - In Datadog, detections often consist of multiple queries. During peer review, I recommend enforcing at least one true case per query. This keeps quality consistent across the entire detection, not just the main condition.

The Script

After a bit of digging through the docs, I was able to find an API endpoint from DataDog that lets me test detection logic directly against sample logs - perfect for validating our test cases automatically.

The idea was simple: build a script that takes a detection’s YAML file, formats it into the JSON parameters the API expects, sends it to the endpoint, and outputs the results.

This is also where we enforce our testing requirements.

A detection “passes” only if it includes at least one True and one False test case, both behaving exactly as expected. If any single test case fails, that detection fails. And if one detection fails, the entire log source folder fails.

It’s surprisingly straightforward once you break it down. As long as we avoid overengineering early on, we can reach a functional, automated system much faster.

You can find the full code snippet at the bottom of this post or in the demo repository.

- Today’s Sponsor -

IRHQ is a modern suite of tools designed to help security teams respond faster, reduce risk, and stay audit-ready. It’s the first platform to combine:

• Incident Management - track and resolve incidents efficiently

• Built-in Post Mortem Frameworks - turn every incident into actionable and trackable action items

• Advanced Analytics - measure performance, spot trends, and improve security posture

• Compliance Reporting - simplify audits and show evidence of strong controls

Take control of your IR operations and make IRHQ your go-to Incident Response Headquarters.

Learn More

Phase I: CI/CD Automation

The first phase of my testing approach was, without question, the most critical.

It was logical that the CI/CD pipeline responsible for deploying detections should also handle their automated testing.

The first version of this workflow ran tests on every commit, with an option to manually trigger tests for specific detection folders when needed. And this entire pre-PR workflow had to pass before a Peer Review could even begin - meaning at least 1 folder must pass.

Why? Because no new detections should make it into production without passing the pipeline first.

Once tests passed, the Peer Review phase kicked in. Reviewers verified that the correct folders were tested, and authors were expected to attach a link to their passing test results in the pull request comments.

From there, reviewers confirmed that all mandatory test cases (one True and one False) were present, and encouraged authors to include the optional Edge and Additional cases for extra assurance.

Finally, once approved, the pipeline enforced that all log source subfolders in the detections directory had to pass testing. If even one unrelated detection to the Pull Request failed, no new deployments could proceed.

This is to strictly enforce that only functional detections can make it into our production environment.

This setup gave my team a solid foundation for our Detections-as-Code workflow, but it also surfaced a few pain points that would shape our next phase.

Phase II: Local Testing

As I started building my first batch of custom detections and porting over the out-of-the-box ones from DataDog into code, I began noticing clear friction in my testing workflow.

Every time I wanted to verify a small change, I had to commit the code, wait for the CI/CD job to spin up, let it run through Terraform checks, and finally manually trigger the test folder.

In total, a single test cycle could take 3-5 minutes just to confirm if a detection worked correctly. With the amount we’re expecting to utilize this workflow in the future, the time cost becomes painful fast.

So I asked myself: I already have the testing infrastructure… what if I could know my code was correct before even committing it?

Enter the Python script.

I built it by repurposing the same logic from my CI/CD testing script and made it callable directly from the command line. This let me instantly test a single detection or an entire folder - no waiting, no pipeline delay.

The benefits were immediate: iteration became faster, wait times disappeared, and merge requests were cleaner since I no longer needed to squash a pile of micro-commits.

Best of all, it’s low-maintenance and consistent. By using the same core testing logic both locally and in CI/CD, I’ve kept testing predictable across environments - while moving a lot faster.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Moving Forward…

While I have an MVP in front of me, it’s far from perfect.

For starters, my current implementation supports manually running specific folders. I made that choice intentionally because I felt it would give detection engineers flexibility to test only the detections they were actively working on, without waiting for the entire project to pass.

However, this has its drawbacks, because when developing detections, it means I have to manually kick off portions of the job each time. A better long-term approach would be for the pipeline to automatically detect which folders changed and dynamically run tests against only those. That’ll be my next quick win.

Another improvement on my roadmap is to dynamically set test case requirements based on each detection’s complexity. Instead of always requiring one true case, I could scale requirements based on the number of queries - ensuring every query has a mapped test case. This would tighten quality and scale much better over time.

Lastly, I plan to add support for additional detection types. While I’ve covered the most common ones, DataDog’s Terraform modules include quite a few variations. My YAML-based approach simplifies things, but it also adds complexity - requiring dynamic Terraform blocks rather than simple copy-paste patterns for new types.

That said, the turnaround from no detections-as-code to a fully automated CI/CD pipeline, complete with tests and our most popular detections migrated, was at just about one month.

The lesson? MVP > Perfection.

Ship fast, learn, and continuously evolve.

Bash Script

Python Script

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

The rollercoaster of emotions that comes with responding to a critical security incident is real, and nothing I say will fully capture that feeling.

Because of that, it’s nearly impossible to ever prepare perfectly. But what you can do is practice in a safe, low-stress environment so the team isn’t figuring things out for the first time during a real outage.

Enter the Table Top Exercise (TTX) - an informal discussion-based simulation where the team plays through different roles and decisions against a hypothetical incident scenario.

The main goal isn’t to break systems - it’s to practice processes, collaboration, and decision-making so that when something actually goes wrong, you’ve already worked through the hard parts together.

TTX’s are often a compliance checkbox once a year, but I’d argue that you should run them as often as your team finds them useful.

And putting a TTX together is easier than you think. Let’s run through the essentials.

The Roles

In order to run a successful TTX, there are various positions you’ll need to fill:

1. TTX Master - Facilitator and scenario driver. Usually a senior person who keeps the discussion moving, drops prompts when things stall, and ensures the exercise stays on track.

2. Incident Commander - Leads the simulated response from open to close. Owns investigation, mitigation, and the overall course of action.

3. Incident Deputy - Supports the Commander and owns documentation during the exercise (notes, timeline, decisions).

4. SME (Subject-Matter Expert) - Brought in as needed (network, app, infra, legal, comms). Provide technical depth and business context.

5. Cross-Functional Roles - (Optional) Invite representatives from IT, product, legal, PR, customer success - whoever you’d need for a real incident.

Ground Rules

Set up expectations up front so the exercise is productive:

1. Focus on the Exercise, not the Incident - The scenario is artificial. Don’t get hung up on perfect realism. Prioritize process, communication, and decision-making.

2. Work on Collaboration - Lean into your role. Ask questions. Play the worst-case assumptions and test your team’s response paths.

3. No “Right” Answers - Encourage discussion and divergent thinking. That’s where the learning happens.

4. Practice Like You Play - Capture timeline entries, decisions, artifacts, and open questions. The incident documentation plays a key part in your response and Post Mortem.

What You Need

Incident Response Processes

A TTX is only as good as the processes it tests. The objective isn’t just to talk through a made-up incident - it’s to walk your team through your actual IR process from end to end and make sure everyone knows how to execute when the clock is ticking.

At a minimum, your team should have:

• An Incident Response documentation process (how you track timelines, artifacts, action items, meeting notes, etc.)

• A Post-Mortem Process (how you capture root cause, lessons learned, improvement items, etc.)

If you don’t have either in place, I got you covered. Check out my articles How to Create Incident Response Documentation and How to Improve Your Security Posture After a Security Incident.

TTX Scenario

The scenario is the backbone of your exercise. Write it up in advance so the session flows smoothly.

A good scenario provides just enough detail to keep the conversation moving, but leaves plenty of space for the team to problem solve.

A few tips:

• Use real services and systems that exist in your environment.

• Include specific assets like service accounts, container names, or endpoints to keep it grounded.

• Keep it open-ended so the team has room to ask questions, pivot, and collaborate.

Want a free set of Google Slides for your next TTX? Subscribers get it free on Cybersec OS!

- Today’s Sponsor -

IRHQ is a modern suite of tools designed to help security teams respond faster, reduce risk, and stay audit-ready. It’s the first platform to combine:

• Incident Management - track and resolve incidents efficiently

• Built-in Post Mortem Frameworks - turn every incident into actionable and trackable action items

• Advanced Analytics - measure performance, spot trends, and improve security posture

• Compliance Reporting - simplify audits and show evidence of strong controls

Take control of your IR operations and make IRHQ your go-to Incident Response Headquarters.

Learn More

Running Through the Incident Scenario

When I run a TTX, I like to structure it around a simple, repeatable flow:

Event → Outcome → Artifact

1. Event: A short 1–2 sentence description of something that happens.

2. Outcome: A summary of what results/findings from that event.

3. Artifact: A deliverable that supports the outcome (for example, logs, screenshots, or emails).

This flow keeps the incident moving in a way that feeds on itself.

I’ll typically repeat this 3-5 times throughout the exercise to create a natural rhythm and progression.

The Beginning

Start with an alert.

It could be a SIEM alert, a ticket from another team, or a low-level monitoring event that doesn’t seem like a big deal at first glance. The key is to make it realistic enough to start a conversation about risk, triage, and initial response steps.

Again, keep it open-ended. Your goal is to give the team just enough context to start discussing what they’d do next.

The Middle

This is the core of your exercise.

Plan for 3-5 events that progressively build the story and test different aspects of your IR process. Each event and outcome should be plausible and prompt critical thinking or decision making.

The idea is to come up with different things that could reasonably be found along the way while attempting to resolve the incident.

Each event/outcome should be something that could be thought up by the team through discussion.

A few tips:

• Assign fictional timestamps to events to simulate a real timeline

• Include clear details on actors, systems, and actions involved.

• Where possible, provide artifacts like JSON logs, screenshots, or mock files to give the scenario more realism.

The middle of the TTX is where you’ll see collaboration, decision making, and process testing come to life.

The End

Close the scenario in a logical way for your exercise - whether it ends in a true positive or false positive is up to you.

This phase is also about reflection. Ask questions that help the team assess how well they worked together and what could be improved, such as:

• Was there an appropriate time along the way to communicate with stakeholders?

• Were there any temporary actions that could have been taken along the way?

• Were any response actions taken too early?

• Was there a better way to contain the threat?

As TTX Master, make sure to call out key learning objectives and check in with each participant. How confident do they feel with the tools, the processes, and their role in the response?

The goal is simple: identify opportunities for training and process improvement before a real incident forces you to.

Running Through the Post Mortem

The Post Mortem is just as important as the incident itself. It’s the time for all stakeholders to come together, reflect, and identify new areas for improvement.

The purpose here isn’t just to review what happened, it’s to practice running an effective Post Mortem so that when a real incident occurs, everyone already knows the process, their roles, and what’s expected of them.

This stage also gives the team experience in formally identifying root causes and spotting opportunities for improvement. Even in a simulated TTX scenario, there’s almost always something you can take away - whether it’s a process gap, documentation gap, or miscommunication that could slow you down in a real event.

The goal: make continuous improvement second nature, no matter if it’s a real incident or a practice run.

If you haven’t established your Post Mortem process yet, check out my article How to Improve Your Security Posture After a Security Incident. It walks through exactly how to build one.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Measuring Success

As TTX Master, your role is to observe how the team performs and identify where things can improve. Here are a few key areas to watch during the exercise:

1. Understanding of IR Processes - Make sure there’s no friction when it comes to spinning up resources, following playbooks, or referencing documentation. This is your chance to test how well your written processes actually hold up in practice.

2. Communication and Collaboration - Watch how the team interacts under simulated pressure. Are they collaborating effectively? Are leaders guiding the conversation and fostering clear, open communication?

3. Technical Familiarity - Pay attention to how comfortable the team is with the technologies involved. Misunderstandings here can reveal gaps in knowledge or training that could slow response time in a real incident.

4. Role Execution - Each role should feel natural and defined. The Incident Commander should take clear ownership and direction, while the Incident Deputy maintains strong documentation and support. SMEs should demonstrate confidence within their areas of expertise.

While there’s no single metric for success in a TTX, your job as facilitator is to take notes on any friction points, process gaps, or miscommunications that arise.

After the exercise, talk to your team. Gather their feedback, ask how comfortable they felt, and capture their perspectives on what worked and what didn’t.

Just like a SaaS company talks to its customers to understand pain points, you should talk to your team to understand yours.

That’s how you improve your IR processes, your confidence, and ultimately - your security posture.

And finally, run TTXs often. Don’t limit them to a once-a-year compliance checkbox. Rotate roles, mix up scenarios, and give everyone the opportunity to build the experience and composure needed to thrive when the real thing hits.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

Security Incidents are some of the toughest situations you can be thrust into - not only as a security team, but as an entire organization.

They’re high-stakes, high-stress, and often come with reputational risk. The pressure is on to contain it fast and minimize the damage.

No matter what scenario puts you in this position, one thing’s certain - you’re in a tough spot.

But even when your back’s against the wall, there’s always an opportunity to turn the situation into something positive.

Every incident tells you something. It exposes weaknesses, highlights blind spots, and reveals parts of your attack surface you didn’t know existed.

Once you’ve contained the incident and things start to stabilize, don’t just move on. If it didn’t completely take you down, it should become an opportunity to make you stronger. Treat it as a lesson, not a loss.

As one of my old coaches used to say: “Mistakes are good, as long as you learn from them.”

That’s where the Post-Mortem, or what I prefer to call the After Action Report (AAR), comes in.

An AAR is your chance to slow down, bring all stakeholders to the table, and talk openly about what happened - what went wrong, why it went wrong, and how to make sure it doesn’t happen again.

It’s not about blame. It’s about growth. It’s about acknowledging shortcomings, celebrating wins, and walking away with a concrete plan to strengthen your security posture.

For me, conducting AARs after major incidents isn’t optional - it’s non-negotiable.

Here are my must-haves for running an effective AAR that actually improves your security posture.

Root Cause Analysis

The first section of any AAR is also one of the most important: the Root Cause Analysis.

This is where all key stakeholders get the chance to formally discuss and agree on the true cause (or causes) of the incident.

The consensus forms the foundation for everything that follows. The root cause shapes not just the rest of the discussion, but also the bulk of the improvements that stem from it.

This is the moment to gather your SMEs and collectively identify what went wrong - not who went wrong. Blame doesn’t solve problems, but understanding does.

Nailing down the root cause is critical to ensuring history doesn’t repeat itself. When you start seeing the same causes appear across multiple incidents, it’s a red flag that your organization isn’t improving or maturing from a security perspective.

Once the group agrees on the cause, categorize it clearly and write a short description of what it entailed. That simple step makes later reporting, trend analysis, and follow-up work much easier.

A well-documented root cause sets the tone for a mature and transparent security culture - and that’s where real growth starts.

AAR Rubric

The AAR Rubric is a concept I coined to help objectively grade the team against a standardized framework each incident.

It’s a structured way to measure execution as a function, identify opportunities for improvement, and track performance over time.

Here’s some of my go-to questions, though there’s plenty of room to customize based on your environment:

• Was the incident detected in a timely manner?

• Did members have sufficient training to handle this type of incident?

• Was there an IR plan or playbook in place?

• Were IR procedures adequate?

• Were internal docs adequate to triage the incident?

• Were stakeholders kept appropriately informed throughout the incident?

• Were communications adequate?

• Were mitigation efforts sufficient to prevent further impact?

• Were the proper resources available to address the incident?

• Did the response process avoid unnecessary downtime or collateral damage?

• Is the team confident that similar incidents can be prevented in the future?

I have a standardized grading system for each category:

• N/A (Not Applicable)

• Poor

• Needs Improvement

• Good

• Great

• Highlight

• Yes

• No

The purpose is twofold: to spot specific areas that need work, and to identify trends over time.

For instance, if the question “Were IR procedures adequate?” consistently gets marked as “Needs Improvement,” that’s a clear signal something systemic needs to change.

The real value of the AAR Rubric is in its trend analysis. It helps ensure your team isn’t just reacting incident to incident - but actually improving with each one.

Continuous improvement is the goal. The rubric gives you the data to prove it’s happening.

🚨 Calling All Incident Responders! 🚨

I’ve been building IRHQ, a new platform for security teams that makes incident response trackable, repeatable, and insightful - not a chaotic mix of Slack threads, docs, and spreadsheets.

If you’ve ever struggled to keep timelines straight, track details mid-incident, or wish you had real data to back up IR improvements, that’s exactly what IRHQ is built to fix.

I’m looking for a few experienced responders from the Cybersec Café Community to test it out and share feedback that shapes where it goes next.

No sales pitch - just looking for thoughtful feedback to build something better for IR teams.

I'm Interested

Discussion Items

Discussion Items are a two-part process.

The first happens during the incident. These are notes or thoughts that you, or anyone on the team, capture in real time. They’re small things you don’t want to lose sigh of, like:

• Something that didn’t go smoothly

• A tool you wish you had

• A gap in documentation or communication

I usually dedicate a section in my Incident Response document where participants can drop these items, along with a quick note or context.

The second part comes during the AAR itself. This is where we actually discuss each item in detail and document the outcomes of those discussions.

The purpose is to dig into the specifics - what went wrong, what could’ve gone better, and what we need to fix or improve. Whether it’s:

• A misconfiguration spotted

• A process that needs to be formalized

• An SOP that caused friction

Whatever it is, make sure it gets surfaced and talked through. And always track who wrote down each item - the author will have the most context and can help drive a productive conversation.

The end goal of Discussion Items is to spark actionable improvements. Not every improvement ties directly to the root cause or the rubric. Some are smaller, one-off issues - but they still matter.

That’s where Discussion Items really shine - they capture the small details that often slip through the cracks but can have a huge impact when addressed.

Cost

One of the most underrated parts of an AAR is estimating the cost of the incident.

It’s not just about technical impact. It’s about illustrating exactly how much each incident actually costs the business. This transparency can be a powerful tool for driving executive buy-in and securing future funding for the improvements that matter most.

Here are the main categories I like to track.

• Human Costs: Break this down into human hours and estimated salary/hourly costs for everyone involved, not just the security team. Think engineers, product managers, customer success, or anyone else pulled into the response.

• Tooling Costs: Capture any tools or licenses purchased specifically to aid the investigation or response.

• Service Costs: Track any external services or consulting engagements used during the incident.

• Revenue Impact: Estimate the business impact. Did the incident cause downtime or interrupt operations that affected revenue?

Once you have your data, I like to summarize it into three clear metrics that tell the full story:

• Estimated Incident Costs = Human + Tooling + Service

• Estimated Revenue Impact

• Estimated Total Cost = Incident Costs + Revenue Impact

Over time, tracking these numbers helps you see patterns - especially if certain types of incidents keep costing you more.

If those costs start trending upward, you now have tangible data to justify additional spend in areas that will actually reduce your long-term risk and financial exposure.

Trust me, this is one adjustment I wish I’d started much earlier in my career.

Improvement Items

Improvement items are the entire reason you conduct an AAR in the first place.

They’re the concrete action items that are meant to prevent the same incident from happening again.

The most important thing here is ownership. Every improvement item must have a clear owner - because without ownership there is no accountability. And without accountability, those items will never get done.

Not every action item will be a top priority, and that’s okay. What is important is in the AAR to clearly document:

• What was discussed

• Why it matters

• Who is responsible

Each root cause should be tied to at least one improvement item, if not more. Otherwise, you’re leaving parts of the incident unaddressed - and that’s how repeat issues happen!

During the AAR, I like to assign one member of the security team to take live notes on potential improvement items as the discussion unfolds. That way, by the time you get to this section, you’re not starting from scratch - you’re simply refining and assigning.

And finally, don’t let these items live and die inside your AAR document. Track them in your project management system or backlog where there’s visibility, reminders, and progress tracking.

Continuous improvement only happens when visibility and accountability go hand in hand.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Always Be Improving

Remember - mistakes are good, as long as you learn from them.

While an incident is never ideal, every single one is a learning opportunity. It’s a direct signal point to where your security posture needs to improve.

The way I run my AARs has consistently helped pinpoint root causes, uncover org-wide areas for improvement, and drive accountability through clearly owned action items.

Doing things asynchronous and hoping they’ll just “get done” will never be as effective as sitting down for a formal discussion to hash out what actually happened and how to prevent it next time.

But now I want to hear from you - the Cybersec Café community! How do you run your Post Mortems? This is one of those processes that rarely gets talked about openly, so I’d love to hear how others approach it. Drop your insights below!

And if you’re currently drowning in incidents, give AARs a shot. Worst-case scenario? You spend two hours talking with your team about how to get better. Best-case scenario? You continuously improve your security posture, start identifying long-term trends, and build a rock-solid business case for more investment in security.

Either way, you come out ahead.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

In cybersecurity, the landscape never stops changing. If you want to succeed, you need to adapt. Fast.

Early in my career, I stumbled on a mindset that completely changed the way I work and accelerated my growth.

I call it the “Just Figure It Out” mindset.

Today, information is everywhere. A quick Google search or a single LLM prompt can unlock answers that once took weeks (or months) to put together.

And yet… I’m constantly surprised by how many people don’t leverage the powerful tools we have at our fingertips.

They get stuck, shrug their shoulders, and either move on or throw it over the fence to someone else.

With resourcefulness and the right mentality, you can solve problems faster, learn new skills on the fly, and keep pace with an industry that refuses to stand still.

Here’s how I’ve applied the “Just Figure It Out” mentality across different areas of cybersecurity, and why it’s been one of the biggest growth drivers of my career.

New Tools & Technologies

Cybersecurity touches every corner of the tech industry, which means it’s constantly evolving alongside every tangent.

Attackers adapt their techniques daily, and staying ahead means adapting just as fast.

In my opinion, one of the best ways to do this is staying up to date with the latest tools. Whether it’s enterprise platforms or open-source projects, modern security teams have more options than ever.

Just see what problems people are solving out there.

And with the rise of SaaS and AI lowering the barrier to building products, each solution seems to have countless competitors - so you’ll be able to compare and contrast what works best for your use case.

The truth is, no two organizations will ever have an identical stack. Your next role might have a different SIEM, a new EDR, or a more expensive email getaway.

But no one is reinventing the wheel. The fundamentals remain the same.

Once you understand the core concepts behind tools like SIEMs, EDRs, and cloud providers, the differences lie in just the details.

That’s where the “Just Figure It Out” mindset kicks in. Learn to learn the nuances quickly without feeling like you’re starting from scratch.

New Languages

No, I’m not talking about French or Spanish. I’m talking about the different syntaxes you’ll come across as you pick up new tools and technologies.

Query Languages are a commodity these days. Every tool you’ll come across seems to have its own flavor.

But once you’ve mastered one, adapting to others gets easier.

At its core, they all work the same way: you’re selecting data from somewhere and filtering it down to what you find valuable.

The same goes for programming languages. If you learn the major language in the cybersecurity landscape (Python), you’ll find most security systems will support it.

And when you inevitably have to pivot, you’ll find it much easier to pick up that next language.

For example, with the rise of Infrastructure as Code, security engineers have been pushed to pick up Terraform. But a declarative language is much easier to pick up after learning the basics of an object-oriented language.

Plus, with LLMs at your fingertips, you can prompt to learn and prompt to solve. Leverage them to explain concepts, walk through examples, and accelerate your understanding - but don’t let it replace your critical thinking.

Accessibility isn’t an excuse to stay shallow.

Read, understand, implement. That’s how you’ll build lasting skills.

Incident Response

Every company is different. Tech stacks may look similar on paper, but architecture never is.

As you join a new organization, one of your first hurdles is learning the network and all of the services running inside of it.

Again - while the fundamentals don’t change, you’ll have to learn how the dots connect.

And even if you’re not new to an org, you’ll often respond to incidents in parts of the environment you never touched before. In fact, I’d argue most incidents don’t come neatly packaged with the full context you’d like.

You’ll be working with incomplete information, siloed knowledge, and business context you’re still piecing together.

That’s where “Just Figure It Out” really matters - learning how to make decisions with incomplete information.

You’ll need to learn how to quickly pull in the right team (system admins, developers, business owners) and piece together the puzzle on the fly.

That ability to adapt, learn, and connect the dots under pressure is what separates a good responder from a great one.

- Today’s Sponsor -

Whether it’s Detection Engineering, Incident Response, or Threat Huting - Security Operations is built on data. And as a Security Engineer, you need to make that data work for you. Selecty is a database-agnostic, sidecar query assistant built to do just that. Generate queries based on your table schehmas, optimize them to your use case, iterate on them quickly, and debug faster than ever - all in one sleek interface. Check it out!

Learn More

New SIEM Sources

This one’s a given. You’re always going to be onboarding new log sources that you’ll need to learn in order to be effective at your job.

As business expands, so will the use cases for your SIEM - new tools, services, integrations. And with each comes a new schema to decipher.

We’d all love a world where logs are neatly standardized to a common schema, but that’s never going to happen. The reality is - that’s your job when you’re crafting your SIEM ingestion.

You’ll need to crack open raw logs, pick apart the key/value pairs, and figure out where the valuable fields lie.

Turning that noise into actionable data is a skill you only build by doing.

A “Just Figure It Out” mentality here can make you an assassin on the keyboard. The faster you can make sense of a new data source, the more valuable you become when an investigation lands on your plate.

Nothing is better than being so familiar with your log sources that you can write queries on a schema from memory.

And the only way to get to this level is by finding an excuse to work with your data:

• Run your own mini threat hunts

• Find excuses to test new detection ideas

• Build and refine a saved query library

• Investigate alerts manually instead of relying only on dashboards

Each of these builds a framework that forces you to “Just Figure It Out.”

And over time, those reps will make you reliable when it’s crunch time.

Cloud Micro-Services

It’s natural to get comfortable with the cloud services you touch every day. You build muscle memory, you learn the quirks, and you become incredibly efficient.

But as businesses evolve, new services will almost always get thrown into the mix.

That’s where the “Just Figure It Out” mentality comes in. When a new service lands on your plate, lean on every resource at your disposal:

• Leveraging official docs

• Reading Blog Posts

• Speaking with SMEs

• Digging into Log Sources

Personally, I prefer the latter - logs don’t lie.

Take AWS CloudTrail for example. By filtering down to a new service, you can piece together flows, establish baselines, and learn its schema in the context of your environment.

All of these skills start to stack. Once you’ve figured out a few services, your confidence will compound, and the next one won’t feel so intimidating.

And if you’re not there yet? That’s fine. You already know the answer: Just Figure It Out.

New Responsibilities

As you grow in your career, your responsibilities will inevitably expand.

And with that expansion comes the uncomfortable reality that you’ll be pushed into areas you’ve never touched before.

It’s part of growth not only as a professional, but as a person.

You won’t always be an expert. You may be asked to manage a team in a domain of cybersecurity you’ve never been hands-on with. Or lead a strategic initiative in an area that’s brand new to you.

In those moments, the “Just Figure It Out” mentality is your best tool.

Your job isn’t to know everything, it’s to learn fast enough to stay in the conversation and contribute meaningfully.

Knowledge is everywhere. But turning that knowledge into action is what makes you invaluable.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Seriously, Just Figure It Out

The “Just Figure It Out” mentality is one of the fastest ways to grow.

It builds knowledge. It builds confidence. And it proves to yourself that you can handle whatever gets thrown your way.

At its core, it’s all about mindset - the belief that you not only can figure it out, but that you will.

Why? Because the information is out there. 99.9% of the time, we’re not reinventing the wheel.

The real skill is knowing how to find that information and apply it to solve problems.

So when in doubt… Just Figure It Out.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

When I first started in cybersecurity, I was lost.

Every meeting, it felt like I was listening to a foreign language. Not only was I trying to absorb a new industry and an endless stream of technical concepts, but the acronyms made it nearly impossible to follow along.

If I wasn’t confused going into a meeting, I most certainly was confused coming out of the meeting.

I think Elon Musk, a CEO with a track record of talking about efficiency in the workplace, said it best:

“Excessive use of made up acronyms is a significant impediment to communication… A few acronyms here and there may not seem bad, but if a thousand people are making these up, over time, the result will be a huge glossary that we have to issue to new employees. No one can actually remember all of these dumb acronyms and people don’t want to seem dumb in a meeting, so they sit there in ignorance. This is particularly tough on new employees.”

That quote sums up my first six months in cybersecurity perfectly.

But as much as we would like to ditch acronyms altogether, that’s not realistic. They exist for a reason - they make conversations faster and prevent us from saying five-word technical phrases over and over again.

Cybersecurity is already tough enough - let’s not make it harder with all of these acronyms.

While I can’t give you a guide to company specific acronyms, I decided to compile a list of acronyms spread across three categories: General Tech, Networks, and Cybersecurity Specific.

Whether you’re new to the field or just need a quick refresher in the middle of a meeting, use this as your cheat sheet.

General Tech Acronyms

• API (Application Programming Interface): A set of rules that lets software programs talk to each other.

• CLI (Command-Line Interface): A text-based way to interact with your computer by typing commands instead of clicking.

• DNS (Domain Name System): The “phonebook of the internet” that translates website names (like google.com) into IP addresses.

• GUI (Graphical User Interface): The visual part of software (windows, icons, buttons) that makes it easier to use.

• IDE (Integrated Development Environment): A software tool that gives programmers everything they need to write and debug code in one place.

• IP (Internet Protocol): The addressing system that lets devices send and receive data across the internet.

• OS (Operating System): The core software (like Windows, macOS, Linux) that manages your computer’s hardware and applications.

• RAM (Random Access Memory): The short-term memory of a computer that stores data the system is actively using.

• SaaS (Software as a Service): Cloud-based applications you access over the internet instead of installing locally (e.g., Gmail, Slack).

• SDK (Software Development Kit): A collection of tools and libraries developers use to build applications for a specific platform.

• SQL (Structured Query Language): The standard language used to interact with and manage databases.

• UI/UX (User Interface / User Experience): UI is what you see and click, UX is how it feels to use the software overall.

• URL (Uniform Resource Locator): The web address you type into a browser to visit a specific page or resource.

• VM (Virtual Machine): A “computer inside a computer” that runs its own operating system on top of another system.

Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!

Learn more

Networking Acronyms

• ARP (Address Resolution Protocol): Maps an IP address to the physical MAC address of a device on a network.

• BGP (Border Gateway Protocol): The routing protocol that decides how data travels between large networks across the internet.

• CIDR (Classless Inter-Domain Routing): A way to represent IP address ranges more efficiently than the old class-based system.

• DHCP (Dynamic Host Configuration Protocol): Automatically assigns IP addresses and network settings to devices.

• FTP (File Transfer Protocol): An older protocol used to transfer files between computers over a network.

• FW (Firewall): A security barrier that monitors and controls incoming and outgoing network traffic.

• HTTP/HTTPS (Hypertext Transfer Protocol / Secure): The protocol that powers the web, with HTTPS adding encryption for security.

• ICMP (Internet Control Message Protocol): Used by network devices to send error messages and diagnostics (like “ping”).

• ISP (Internet Service Provider): The company that provides you access to the internet.

• LAN (Local Area Network): A network of devices in a small physical area, like a home or office.

• MAC (Media Access Control): A unique hardware address assigned to every network interface card (NIC).

• NACL (Network Access Control List): A set of rules that control what traffic is allowed in or out of a network.

• NAT (Network Address Translation): Lets multiple devices share a single public IP address by translating traffic.

• OSI (Open Systems Interconnection): A conceptual model that describes how different layers of networking work together.

• QoS (Quality of Service): Manages bandwidth and prioritizes network traffic to improve performance.

• SMTP (Simple Mail Transfer Protocol): The protocol used to send email across the internet.

• SNMP (Simple Network Management Protocol): Allows administrators to monitor and manage network devices.

• SSH (Secure Shell): A secure way to remotely log into and manage servers over a network.

• TCP/IP (Transmission Control Protocol / Internet Protocol): The foundational suite of protocols that power the internet.

• UDP (User Datagram Protocol): A faster but less reliable protocol for sending data, often used for streaming or gaming.

• VPN (Virtual Private Network): Encrypts your internet connection and hides your IP address for privacy and security.

• WAF (Web Application Firewall): A firewall specifically designed to protect web applications from common attacks.

• WLAN (Wireless Local Area Network): A Wi-Fi network that connects devices without cables.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Cybersecurity Acronyms

• APT (Advanced Persistent Threat): A long-term, targeted cyberattack where attackers quietly stay inside a network to steal data.

• AV (Antivirus): Software that scans and removes malicious programs from computers.

• C2 (Command and Control): The server that attackers use to remotely control compromised machines.

• CERT/CSIRT (Computer Emergency Response Team / Computer Security Incident Response Team): Specialized teams that handle and respond to cybersecurity incidents.

• CVE (Common Vulnerabilities and Exposures): A public catalog of known software and hardware security flaws.

• DLP (Data Loss Prevention): Tools and policies that prevent sensitive data from leaking outside an organization.

• DDoS (Distributed Denial of Service): An attack that floods a system or website with traffic from many sources to make it unavailable.

• EDR (Endpoint Detection and Response): Security tools that monitor computers and devices for suspicious activity and attacks.

• IAM (Identity and Access Management): The framework for managing user identities and controlling who can access what.

• IDS/IPS (Intrusion Detection System / Intrusion Prevention System): Systems that detect (IDS) or block (IPS) malicious activity on a network.

• IOC (Indicator of Compromise): A clue or artifact (like a file hash, IP, or domain) that suggests a system has been attacked.

• MITRE ATT&CK: A knowledge base that documents real-world hacker tactics and techniques for defenders to study.

• MFA (Multi-Factor Authentication): A login method requiring more than one proof of identity (like password + code on your phone).

• NIST (National Institute of Standards and Technology): A U.S. agency that publishes widely used cybersecurity standards and guidelines.

• PKI (Public Key Infrastructure): The system that manages encryption keys and digital certificates to enable secure communications.

• SIEM (Security Information and Event Management): A platform that collects, analyzes, and alerts on security logs across an organization.

• SOC (Security Operations Center): The team or facility that monitors and responds to security threats in real time.

• SAST/DAST (Static/Dynamic Application Security Testing): Tools that scan code (SAST) or running apps (DAST) for vulnerabilities.

• SOAR (Security Orchestration, Automation, and Response): Tools that automate security workflows and incident response tasks.

• TTPs (Tactics, Techniques, and Procedures): The patterns of behavior attackers use, from strategy down to specific methods.

• XDR (Extended Detection and Response): A security solution that integrates threat detection across endpoints, networks, and cloud systems.

• ZTA (Zero Trust Architecture): A security model that assumes no one, inside or outside the network, should be trusted by default.

💬 Did I miss any? Drop them in the comments below!

Leave a comment

Acronym King

As much as acronyms suck, they’re here to stay..

That means the faster you get up to speed, the easier it’ll be to follow along in architecture reviews, change boards, or even just your day-to-day team conversations.

And let’s be honest - nobody wants to say “Endpoint Detection and Response” every time when a simple “EDR” will do.

Use this as a guide to strengthen your acronym game, and better yet, contribute to it in the comments and help others out in the Cybersec Café community!

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

With the pace of business today, cloud adoption is a key ingredient to accelerating how businesses scale, ship products faster, and reach the market first.

But with that speed comes tradeoff: expanded attack surfaces.

This adoption of cloud infrastructure has fundamentally changed how we approach security. Unlike traditional on-prem environments, where perimeters are more defined, the “infinite perimeter” of the cloud means your resources can (theoretically) be accessed from anywhere.

Cloud providers operate under a shared responsibility model, which helps, but it doesn’t absolve customers of their part. At the end of the day, you’re still responsible for workloads, configurations, identity, and data.

That’s why the demand for Security Engineers with cloud expertise continues to grow. If you’re looking to pivot into this in-demand field, here’s how I’d start building a strong foundation.

Cloud-Agnostic Security Concepts

Each cloud provider (AWS, Azure, GCP, etc.) has its quirks, but the fundamentals remain consistent.

If you double down on the basics, you’ll be able to pivot into any provider quickly and adapt to whatever stack your company uses.

Identity and Access Management (IAM)

At its core, cloud security is really about identity.

That’s because identity has become the new perimeter. Attackers no longer need to brute force Firewalls and probe networks. If they can just hijack valid credentials, they can walk straight into your environment.

IAM has a few fundamental building blocks:

• Users represent individual entities, like human users or service accounts.

• Roles are sets of permissions that can be assumed by users, apps, or services.

• Groups are logical collections of users that inherit policies.

• Policies are JSON-like permission sets that define what actions are allowed or denied.

There are a few best practices when it comes to IAM:

• Avoid raw user accounts for day-to-day use and instead opt to federate users through SSO and enforce role-based access with Just-in-Time (JIT) provisioning.

• Use groups to scale policy management across your user base.

• Leverage the Principle of Least Privilege (PoLP) to design policies so users and services only get the access they need and nothing more.

Overly broad roles and misconfigured policies are some of the most common (and costly) pitfalls in cloud security. Tight IAM controls are often the difference between a minor incident and a full blown breach.

Networking & Segmentation

At a high level, cloud networking looks a lot like on-prem, just with some new terminology.

• VPCs (Virtual Private Clouds) are essentially the cloud equivalent of a datacenter network. They cut out a private slice of the provider’s global infrastructure, letting you define your own IP ranges, routing rules, and connectivity. Misconfigurations here are one of the fastest ways to unintentionally expose workloads to the internet.

• Subnets work in much the same way as on-prem and are commonly split into public and private zones to control exposure.

• Security Groups (SGs) and Network ACLs (NACLs) act as your main filters. SGs are instance-level, stateful firewalls that handle both inbound and outbound rules. While NACLs are subnet-level, stateless filters with explicit allow/deny logic.

The key here is microsegmentation. You can shrink your attack surface and minimize blast radius in the event of an incident just by applying fine-grained controls between your workloads.

Data Protection

You’ve heard it before, and you’ll hear it again: Encryption in Transit and At Rest in the Cloud.

Fortunately, most cloud providers make this straightforward. TLS is easy to enforce across internal APIs and external endpoints, and storage systems often encrypt at rest by default.

You’ll also have to get comfortable with a couple critical services:

• Key Management Systems (KMS) are provider-managed services that handle key creation, rotation, and usage. You can define fine-grained access controls around who or what can use specific keys.

• Secrets Managers centralize sensitive values, enforce rotation policies, and give you visibility into who access what, when - for those pesky audits.

Used together, KMS and Secrets Managers provide a solid foundation for a data protection strategy in the cloud.

Monitoring and Logging

Visibility is non-negotiable in the cloud.

Cloud providers offer services that collect complete audit trails of who did what, where, and when. These logs are invaluable for forensics, so you’ll want to get them ingested into your SIEM ASAP in order to correlate, investigate, and get real-time alerting.

These providers also have their own flavors of anomaly and threat detection services that leverage machine learning and threat intelligence to surface anomalies. While they can’t replace custom detection, they’re a welcome compliment.

You’ll still need to put on your detection engineer hat to fight off alert fatigue, so if you’re already ingesting your cloud log sources into your SIEM - I’d suggest checking out my Detection Engineering Starter Guide.

Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!

Learn more

Key Threats in the Cloud

To be an effective Cloud Security Engineer, you’ll need to get good at identifying potential indicators of misconfiguration (IOMs) and potential attack paths.

While finding advanced threats takes some experience, generally the most impact comes from nailing the fundamentals.

Here are some of the top threats you can start addressing from day one.

Misconfigurations

Misconfigurations are a primary cause of cloud breaches, and unfortunately - they’re everywhere. Even with Infrastructure as Code (IaC) reducing risk, mistakes still slip through.

Some classic examples include:

• Open storage buckets are the byproduct of misunderstood defaults and rushed settings. Suddenly, your bucket is wide open to the internet. Attackers passively scan for these and what can leak out usually isn’t good: PII, credentials, or even proprietary source code.

• Overly permissive IAM roles occur when convenience takes precedence and caution is thrown to the wayside. It’s not uncommon to see blanket administrator roles attached to roles that have no business having those permissions. Ignoring the Principle of Least Privilege doesn’t just expand your attack surface, it creates a fleet of unnecessary high-privilege accounts waiting to be abused.

• Even in IaC-driven environments, manual console tweaks can lead to Infrastructure drift. Those one-off changes create inconsistencies, complicate audits, and leave a hidden layer to your attack surface that will soon be forgotten.

Misconfigurations are easy to make, and just as easy for attackers to find. Your job is to spot them early, correct them quickly, and to foster a culture that puts Infrastructure as Code first.

Credential Theft & Privilege Escalation

Cloud credentials make the mouths of attackers water.

And even though credentials are known to be sensitive, it’s surprisingly common for developers to accidentally commit access keys into repositories.

If those repos are public, you’ve just gifted everyone the keys to the kingdom.

Even in private repos, once credentials are exposed, they can be chained with misconfigurations or overly permissive roles to move laterally and escalate privileges. And just like that, what may seem like a small leak can escalate to a full environmental compromise.

Even with a strong logging and monitoring strategy, credential misuse is notoriously hard to detect because it just looks like legitimate access at that point.

Supply Chain Risks

Just like any project, your cloud environment runs on top of countless dependencies, packages, images, and pipelines.

And each has risks associated:

• Dependency poisoning can occur from a typosquatted malicious package, or even a legitimate library that quietly accepted a malicious pull request. Installing the wrong code can cause instant RCE, credential theft, or potentially even worse.

• Insecure base images can often contain outdated libraries and known vulnerabilities that devs may not notice until too late. Pulling “latest” without validation is a recipe for trouble. Make sure to pin to a stable version.

• CI/CD pipeline compromise can effectively allow an attacker to inherit trusted, privileged access to your cloud environment. Your pipeline is a crown jewel - protect the secrets, signing keys, and deployment credentials that it holds.

If you don’t know and control what’s running in your environment, someone else will figure out a way to!

Essential Cloud Skills for Security Engineers

Understanding threats is only half the job.

The other half is building the skills to mitigate them. Cloud environments demand a mindset that balances speed, scale, and security without slowing down the business.

Here are the core skills I’d focus on to level up as a Cloud Security Engineer.

Strong IAM Knowledge

It’s one thing to understand IAM concepts, and another to actually enforce PoLP at scale.

That means:

• Granting only the minimum necessary permissions for roles.

• Using groups and policies to manage users efficiently.

• Striking a balance between strong security and developer productivity.

On the operation side, partner with IT to federate your cloud environment into SSO or enforce MFA everywhere, and apply a logging strategy.

And of course - ban use of the root account unless in the case of emergencies. Monitor it closely, and make sure no one uses it for day-to-day operations.

Zero Trust Networking

The old mindset of “inside equals safe” doesn’t cut it in the cloud.

A Zero Trust approach means every request must be authenticated and authorized, even if it originates from inside your VPC.

In practice, this means building systems around continuous verification and treating internal traffic with the same scrutiny as external.

By leaving implicit trust at the door, you reduce the blast radius of compromise and force attackers to work harder for every step they try to take.

Container & Kubernetes Basics

You’ll want a solid grasp of containerization concepts effectively with DevOps and Infrastructure teams while also spotting potential security gaps.

At minimum, you should be familiar with:

• Namespaces: Logical isolation of workloads

• Registry: Servers that store and distribute container images

• RBAC: Role Based Access Control for fine-grained permissions

• Pod Security Policies/Pod Security Admission: Controls that prevent risky or insecure configurations

From a security perspective, focus on protecting registries and images.

Use private registries with enforced access controls, regularly scan images for CVEs, implement signed images to prevent tampering, and avoid the “latest” tag by pinning to immutable versions.

These measures reduce risk and increase confidence in what’s running in production.

IaC & Drift Management

Infrastructure as Code (IaC) is now a standard practice.

And while you don’t necessarily need to write production-ready templates, you should be able to read and understand them.

IaC enabled repeatability, version control, and peer review - which in turn makes infrastructure predictable and secure.

Although each tool has its own syntax and providers, the declarative approach is consistent.

As a security engineer, your role is to:

• Integrate security checks directly into the development workflow.

• Help teams identify misconfigurations early.

• Address infrastructure drift.

Unmanaged drift creates “invisible” infrastructure - your attacker's ideal target. Staying on top of drift ensures you’re defending the actual state of your environment, not just the state defined in code.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Cloud-Native

Cloud is the new baseline, and it’s becoming a requirement to have this kind of knowledge in the various security engineering disciplines.

Security engineers today are expected to protect this dynamic and distributed cloud infrastructure.

That shift means rethinking familiar concepts in new contexts:

• Running IR in the cloud.

• Leveraging cloud-native threat intelligence.

• Working with developers to embed security early in their pipeline.

The work is different, but principles remain.

The key is continuous learning and adaptability. Build your foundation cloud-agnostically, then map them to the services and platforms your organization uses.

This approach keeps your skills portable, scalable, and resilient as the cloud continues to evolve - making you cloud-native.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

Cybersecurity isn’t just about firewalls, exploits, or technical know-how. It’s also about people.

Too often, soft skills get overlooked in favor of technical abilities. And while technical skills are certainly a major part of the field, they’re only part of the equation. The other half, the part that makes you effective beyond the keyboard, is how you work with people.

Like it or not, people are always part of the security equation. You won’t be siloed to your department. You’ll collaborate across teams, partner with stakeholders, and negotiate with vendors.

That’s where soft skills come in. They help you influence decisions, lead with your vision, earn trust, and build rapport.

They can be the difference between landing a job and being passed over. The difference between being a good professional and a great one.

Key Soft Skills Every Cybersecurity Professional Should Develop

Communication

Communication in cybersecurity isn’t just about sounding polished or articulate. It’s about making sure your message lands.

That means being able to:

• Translate technical findings into business language.

• Write concise incident reports, executive summaries, and documentation.

• Explain risk in a way that enables decisions.

• Clearly lay out tradeoffs.

But communication isn’t only about talking, it’s about listening. Don’t just listen to respond. In security, you need to listen to understand.

Take in the perspectives of engineers, executives, and stakeholders, and then weigh them with your own judgment. You don’t have to accept everything at face value, but you do need to account for it.

Collaboration

You won’t spend your career working only with other security engineers. In fact, most of your impact will come from how well you work with people outside of security.

Collaboration often looks like:

• Partnering with compliance teams on audits.

• Helping IT refine policies.

• Communicating incidents to executives.

• Coordinating a diverse cast during an incident response.

• Reviewing architectures with engineering teams.

And that’s just the beginning.

Good collaboration is about finding common ground, speaking in a way others can understand, and working together toward solutions that stick.

In order to be a strong teammate, stay open to new ideas and approaches, even if they aren’t the ones you would have chosen first.

Leadership

Even if you’re not a manager, leadership qualities are some of the most valuable you can bring to the table.

Strong leadership drives projects forward, creates meaningful impact, and helps motivate those around you.

Even without the formal manager title, you might find yourself:

• Leading an incident response

• Mentoring junior staff

• Driving project direction

• Setting strategic goals and milestones for the team

Leadership is less about authority and more about trust.

Build that trust through having a reputation for action. Your teammates will notice, making them far more likely to follow your lead.

Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!

Learn more

Critical Thinking and Problem Solving

The ability to take in data and make smart, informed decisions is a brain muscle that needs constant exercise.

In security, you’ll often make high-impact calls with incomplete information. That’s where weighing risk and trade-offs becomes essential.

There is also something I was once told by a friend, somewhat jokingly, but oddly resonated: “Don’t come to me with problems, come to me with solutions.”

No one wants to work alongside someone who only points out problems without moving the needle forward.

Be the person who takes initiative to drive solutions. Even if you don’t have the full answer, come prepared with potential options and kick off the dialogue.

At the end of the day, this job is problem-solving. The faster you embrace the mindset, the more effective you’ll be.

Adaptability and Continuous Learning

Technology is always changing, and the threat landscape constantly changes with it.

Curiosity and adaptability are survival skills in cybersecurity. You need to:

• Pick up new tools quickly.

• Understand shifting business contexts.

• Learn how to ask sharp, relevant questions.

What’s critical today may be irrelevant tomorrow, and professionals who thrive are the ones who can pivot without losing momentum.

Emotional Intelligence

A large part of cybersecurity is managing the emotional rollercoaster.

On-call rotations, surprise incidents, and high-stakes decisions can start to take a toll.

The best security professionals learn how to manage stress and stay level-headed when it matters most.

Emotional intelligence also means empathy. You’ll often work with non-technical colleagues who don’t share your background, and occasionally with technical peers who have different priorities.

Patience, empathy, and the ability to communicate at their levels are core to building rapport.

At the end of the day, your role is just as much about securing systems as it is about educating and guiding the people you work with.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Soft Skills: Your Unfair Advantage

Technical skills may open the door, but soft skills will be the ones that help move you up the ladder.

The skills we’ve covered: communication, collaboration, leadership, problem solving, adaptability, emotional intelligence - these help you build trust, influence others, and ultimately amplify the impact of your technical work.

The good news? Soft skills can be trained just like technical ones. A few practical ways to start:

• Seek feedback from your peers/managers.

• Volunteer to give presentations in low-stakes settings.

• Take the lead on small projects or meetings.

• Mentor junior teammates and help them grow.

Cybersecurity has always been about more than firewalls, logs, or alerts. The more intentional you are about strengthening these skills, the more effective you’ll become.

So, be honest with yourself: Which of these skills do you need to work on the most?

That’s your starting point. Because just like any muscle, soft skills only grow when you use them.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

SIEM is the backbone of every detection engineering program.

It gives you log aggregation, near real-time alerting, and a single pane of glass where everything is searchable and (hypothetically) correlatable.

But as your detection program grows, if you don’t have a solid engineering process in front of it, alert fatigue will hit you fast. And just having a SIEM in place on its own won’t save you from that.

When teams hit this wall, that’s usually when teams start looking at the next shiny thing: SOAR platforms or, lately, the mystical “AI Agents.” Just picture it:

Automated initial triage. Response workflows. Branching logic that adapts with every new data point - Sounds amazing, doesn’t it?

Well, I’m sure I’m not the first you’ve seen to say it, but more tools don’t automatically make your detection program better.

The promises of SOAR and AI Agents infatuate many detection engineering teams, but is it really the logical next step for you?

Yes, SOAR and AI tools can help reduce some noise and automate repetitive tasks. But they’re bandaid fixes to your problems, not cures.

And if your alerts are poorly designed, automation only helps you fail faster.

The real problem isn’t a lack of SOAR or AI Agents - it’s bad alerts.

How to Address Your Poor Alerts

When I say “poor alerts,” I’m talking about the constant stream of detections in your SIEM that just aren’t pulling their weight. Usually, they fall into one of three buckets:

• They don’t provide any real value

• They’re detached from your environmental context

• They lack the context you need to actually investigate

Bottom line: you need a methodical way to improve alert quality.

Here’s where I’d start.

Tune Out Alerts that aren’t Valuable

One of the biggest mistakes I see is letting weak alerts linger far too long because of perceived value.

This usually looks like keeping a detection around because the activity it picks up sounds suspicious, but in reality, it’s just flagging normal behavior over and over again.

Medium severity detections are notorious for this problem.

There are two approaches I take with high-volume, low-value alerts:

1. Tuning the Detection: While tuning sounds like the simple and obvious choice, it isn’t just an easy tweak and checkbox exercise. It requires a deep understanding of the log source and how attackers actually abuse the behavior you’re trying to pick up on. Without that context, you risk tuning yourself into blindness.

2. Using the Detection in Conjunction with Others: Sometimes a noisy detection isn’t useless. It’s just weak on its own. Repurpose it to strengthen confidence when combined with other signals. By itself, it might be informational. Paired with another detection in the same time window, it might point to something more serious.

The goal of either approach is to eliminate busy work chasing meaningless alerts.

But be cautious and don’t get too trigger-happy. If you tune too aggressively or downgrade everything, you’ll lose visibility into your environment fast.

Move slowly, validate changes, and make sure new behavior matches your expectations.

If you want a deeper dive, check out my article on my detection tuning methodology. The TL;DR: start broad, collect data, and gradually refine down to granular coverage as you scale.

- Today’s Sponsor -

Whether it’s Detection Engineering, Incident Response, or Threat Huting - Security Operations is built on data. And as a Security Engineer, you need to make that data work for you. Selecty is a database-agnostic, sidecar query assistant built to do just that. Generate queries based on your table schehmas, optimize them to your use case, iterate on them quickly, and debug faster than ever - all in one sleek interface. Check it out!

Learn More

Get in Touch with Your Environment

One of the earliest lessons in detection engineering is that most of your Indicators of Compromise (IOCs) come down to privileged actions being taken under the wrong guise.

However, you’ll also quickly find that these same privileged actions are also carried out legitimately every single day by real users and service accounts.

Without tuning, you’ll drown in false positives.

The fix starts with research. Over time, patterns begin to emerge, and it’s your job as a detection engineer to recognize them.

You’ll also find it valuable to communicate with stakeholders. They’ll likely be able to tell you exactly which accounts or teams routinely perform certain actions, and the business cases behind them.

And sometimes, the tuning idea comes from anecdotal experience. If you’re triaging the same false positive five times a day, it’s probably time to adjust your detection logic.

This is especially true when implementing out-of-the-box or open-source detection rules. They’re a great foundation, but they’re designed to flag potentially malicious actions.

What’s normal vs. abnormal in your environment is something that only you, as a detection engineer, have the information to define.

Make Your Alerts Actionable.

If your analysts can’t quickly understand and act on an alert, you don’t have a detection - you have noise.

Poor alerts are generic. They leave you asking: Who was involved? What environment? From what IP? What was the target?

Without answers, you’re forcing your analysts to waste time digging for context.

Frankly, this is one of my biggest complaints with certain SIEM vendors (no names, but you know who you are). Their out-of-the-box rules often feel like they were designed by people who’ve never had to use them.

So how do you fix it? Start by asking yourself: What would I want to know from a quick glance at this ticket?

In most cases, the answers are simple—users, actions, and targets. That’s the core. Build your alert logic and enrichment around them.

Then, make the alert human readable in a way that makes it easy to understand where and how to take action.

Titles should be clear and artifact-rich. Always include critical context like IP addresses, accounts, or targets. Add quick links that make triage almost effortless:

• A dashboard view pre-filtered for that user

• A saved query for that action

• A VirusTotal link with the IP already embedded.

The less manual work, the better. Plus, you’ll achieve a SOAR-like benefit of easily accessible information by following these steps.

Personally, I have a motto for detection engineering. I am to make every alert something I can triage from my phone in Slack.

At a glance, I should know what happened, who’s involved, and whether it’s worth leaving the couch to log in.

That level of clarity isn’t just about efficiency, it’s also preventative towards burnout - especially on small teams.

Having alerts that explain themselves is the difference between sustainable operations and constant fatigue.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Processes, Not Products

It’s easy to get wowed by a flashy product demo or sold on the promise of what a tool should deliver.

And while there’s a place for SOAR platforms and AI agents, we can’t let the bells and whistles distract us from what really matters: the fundamentals.

In detection engineering, the fundamentals boil down to having a clear framework and guardrails for how you design detections:

• Create detections that provide value, not noise.

• Build with environmental context in mind.

• Make the output actionable.

Often, the real magic isn’t in what you add, but in what you choose to leave out. A SOAR platform is a fantastic next step for a mature detection program. But it’s not the step you need when you’re still building toward maturity.

The temptation to chase the shiny object is always there, but deep down, we know the truth: the answer lies in our processes, not our products.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

Over the past couple weeks, I’ve been heads-down building out a Detections as Code (DaC) implementation for my Security Operations team.

In past roles, I've worked with DaC setups, but they were always there before my arrival - already somewhat mature with the needed infrastructure in place.

But this time is different. I’m maturing the SecOps function from scratch. That means I have full creative control over how this solution gets built (within the constraints of the platform, of course).

It’s a project that’s been pushed down the backlog a few times for more urgent fires, but I finally carved out time to sit down in my IDE and get started.

Our SIEM of choice in this instance is DataDog. While they provide some high-level resources on DaC setup, primarily in the form of a blog article, they leave much of the implementation open-ended.

That freedom has given me the space to design something that works not only for us today, but hopefully scales well and sticks around long after I’ve moved on.

Why Detections as Code?

We’re a small team, which means bandwidth is always stretched. That’s the main reason DaC has been on the backburner for months.

At first, our priority was coverage. We needed detections in place, fast - with the understanding that we’d later port them into an “as Code” framework.

But here’s the challenge: with just two senior engineers, one mid-level, and two analysts, time is our most precious resource. And DaC has some heavy up front cost: setting up pipelines, porting detections, and ironing out bugs.

But most of that cost is front-loaded. Once the pipelines and infrastructure are running, maintaining detections becomes far less painful than managing them purely through a UI.

Yes, there’s still upkeep. But compared to the manual overhead of UI-driven workflows, the long-term payoff is massive.

That’s why, even for a very small team, I’m convinced the investment is worth it.

Benefits

As Code (In General)

Once you get used to having your detections in an easily searchable codebase, you realize just how much friction the UI-only approach creates.

In the UI, you can’t simply search for detection logic. You can’t mass update rules from the same data source. You can’t easily reuse components. Every action feels one-off and manual.

With a centralized codebase, everything lives in one place - accessible through your IDE. That makes detection creation and maintenance dramatically easier.

And it’s not just about queries. With the right architecture, your DaC setup can also integrate things like runbooks, dashboard links, or quick links with embedded variables.

Bottom line - as your suite grows, a well-documented “as code” implementation actually scales better and becomes more maintainable than UI-based workflows.

Version Control & Code Reviews

Managing detections strictly through the UI leaves you with little traceability. If a faulty rule is pushed, good luck rolling it back - you won’t have access to change history or context.

With DaC, quality control shifts into familiar engineering territory: Git, versioning, and peer review.

Peer reviews before merges help catch logic errors and ensure changes are documented. Compare that to the UI, where it’s all too easy to click “enable” without proper testing.

And, unless you’ve got detections on your audit logs set up for your SIEM platform (thankfully we do, even though they don’t ship with them out-of-the-box) - no one may even know a new detection was added. Or worse: disabled.

Version control also helps keep the team dynamic. Often, junior and mid-level engineers will hesitate to make changes because they’re afraid of “breaking something.” With reviews, traceability, and rollbacks baked into the workflow, that fear largely disappears.

You’d have to try pretty hard to mess things up.

- Today’s Sponsor -

Whether it’s Detection Engineering, Incident Response, or Threat Huting - Security Operations is built on data. And as a Security Engineer, you need to make that data work for you. Selecty is a database-agnostic, sidecar query assistant built to do just that. Generate queries based on your table schehmas, optimize them to your use case, iterate on them quickly, and debug faster than ever - all in one sleek interface. Check it out!

Learn More

CI/CD Linting and Testing

A proper CI/CD pipeline for detections is like having a built-in safety net. Every commit automatically tests your syntax and detection logic - removing guesswork and reducing human error.

Think about it: every time you push code, your detections validate themselves before they ever reach production. If configured properly, you can’t even deploy unless your tests pass.

This does two powerful things:

1. Creates a continuous feedback loop that minimizes the risk of broken detections slipping through.

2. Builds in positive friction Requiring test cases forces engineers to think more critically about their logic before submitting that PR.

In short, automation not only catches mistakes but also raises the overall bar for quality.

Detection Standardization

Standardization might sound nitpicky at first, but in practice it’s a game-changer for maintainability. By creating a consistent framework for detection development, you make the process predictable, scalable, and easier for others to contribute.

Instead of reinventing the wheel every time, engineers follow the same structure. Almost like filling out a form. This lowers the barrier to entry, accelerates onboarding, and ensures your detection library grows in a way that’s sustainable.

The result? Anyone on the team can contribute without friction, while the codebase stays clean and manageable long-term.

Side Note: As I’ve been porting over detections, this standardization also helps me fly through transferring them over. I literally feel like I’m filling out a form!

DataDog Implementation

When it came time to actually build, I set myself one rule: keep it simple, but don’t sacrifice scalability or maintainability.

After digging through the DataDog Terraform docs, I landed on an approach that templatizes my terraform module while leaning on YAML files as the configuration file for detections.

Instead of writing Terraform for every detection, my team can now fill out a YAML file that looks and feels more like a form than raw code. The pipeline then takes care of the Terraform layer behind the scenes by looping through my detection folders.

While some may call this overengineering, I like to call it simplification.

By minimizing Terraform complexity and reusing a YAML template, we can port existing detections faster, create new detections with less friction, and empower everyone on the team (even those less comfortable writing code) to contribute meaningfully.

YAML gives us the right balance - structure enough to scale, simple enough for broad adoption.

📁 Scroll to the end to see the files. Or, want the raw files? Subscribers get them free through Cybersec OS!

Update 10/20/25 - Subscribers now get access to the MVP Repository in Cybersec OS. Kickstart your own DataDog DaC implementation now!

Deploy

On the deployment side, I added one extra layer to the typical Terraform flow.

Beyond the standard terraform plan and terraform apply, our CI/CD pipeline automatically runs tests against each detection using DataDog’s API.

Any folder with updated detection files triggers automated test runs, and all tests must pass before anything can be deployed.

My rule of thumb is that every detection must include at least three test cases: one true positive, one false positive, and one edge case. This is the number I landed on that forces the detection engineer to ensure their detection works as expected.

The pipeline enforces the true/false checks, while the edge case is a required part of peer review. This ensures detections aren’t just technically correct, but also thoughtfully designed.

Deployment becomes just as much about quality control as it does about pushing detections to production.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Why I View This as Our Ideal MVP Solution

Is this the most elaborate, rigorously tested detection-as code pipeline, battle hardened by our (non-existent) red team?

No.

What it is, though, is a minimal viable product that brings detections-as-code to a small team without the overhead of a massive pipeline, and still delivers most of the benefits of an as-code approach.

This solution lays the foundation for scalability and maintainability. It lowers the barrier to contribution, requiring only minimal Terraform knowledge, and keeps the team focused on what matters: shipping and refining detections.

It’s simple. It’s learnable. And it works.

And to me, seeing my team actually use this lightweight but powerful approach - that’s the real win.

Terraform File:

YAML File:

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

For the past year and 80 posts here at the Cybersec Café, I’ve preached the same mantra: get technical, sharpen your programming skills, and deepen your technical expertise to set yourself apart as a security engineer.

But today, I’m flipping the script. I’m here to talk about something very different - writing.

Now, I know what you might be thinking: Writing? As a security engineer? We’re supposed to write code, give security recommendations, and enforce security best practices - where does writing words fit into that equation?

Or maybe you’re running toward the tech industry because you hate writing or thought you were bad at it.

Don’t worry, same here - writing was by far my worst subject in school. If you asked my old teachers, they’d probably agree.

But I’m lucky that early in my career I figured out the impact that being a quality writer can make on your work. That’s one of the primary reasons I started this newsletter, to improve. And here I am, a year and a half into writing a weekly newsletter.

So how did I get here? And why do I believe writing is one of the most underrated skills for a security engineer?

Why Writing?

At first, writing seems almost contradictory to an engineering role. After all, engineers are judged on technical chops - system design, debugging, and complex coding interviews.

But here’s the thing - clear and concise writing is criminally underrated in tech, and can be a major differentiator.

Ryan Peterman put it well in a LinkedIn post:

• “Distinguished engineers at Meta make upwards of $3M per year. Every diff description, launch post, or directional doc [these engineers] write is crystal clear. I don’t need to work in their domain to understand what they say.”

Think about it. Who doesn’t appreciate a well explained design document? Or a detailed, easy-to-follow bug bounty report? Or even just a thoughtfully written ticket?

Money aside, writing is just part of modern engineering. Building systems isn’t just pounding out code and writing tests - it’s planning, documenting, and communicating ideas before a single line even gets written.

And from a personal perspective, writing forces you to organize your thoughts. If you can lay them out clearly on the page, you’ll communicate more clearly when you speak too. That’s a skill every engineer benefits from.

I’m a firm believer that you don’t even need to be a great writer. Just an above-average one can have a massive impact on your effectiveness as a security engineer.

And here’s how.

Real-World Writing for Security Engineers

Requirements Documents

Ah yes - the trusted requirements doc. I’m not going to lie - the first time I had to write one back in university for my senior design project, I thought it was a complete waste of time.

But little did I know, it would save me an incredible amount of time down the road.

At its core, a requirements doc defines the scope of a project and the features needed for it to be considered a success. In other words: it sets the success criteria.

If done well, it makes the project crystal clear to all stakeholders and acts as a guardrail against scope creep.

But let’s be real - if your company’s current approach is to throw projects at the wall, iterate quick, and see what sticks, then requirements docs probably aren’t part of your workflow.

But if you’re serious about building something meaningful, then requirements docs become less of a formality and more of an opportunity to align cross-functionally.

Skip this step, and you’ll waste far more time later trying to fix misaligned expectations, rather than taking that extra time to spell it out and discuss first.

Technical Design Documents

Once you’ve nailed down the what and why in your requirements doc, the next step is the how. That’s where the technical design document comes in.

The purpose of a design doc is simple: think through your solution before you build it. Taking the extra time saves you from painful redesigns, costly mistakes, and the dreaded “rip it all out and start over” scenario.

Benefits of design docs really shine through when it comes to peer review. Sharing it gives others a chance to strengthen your work before it’s set in stone:

• Infrastructure teams can validate architecture.

• Security team members can flag risks.

• Network engineers can ensure efficient data flows.

• DevOps can review for any CI/CD implications.

• Product can confirm it still solves the right problem.

Not every project will need this level of rigor. A small internal tool might not warrant a 10-page design doc. But if you’re building a complex system, this is where the serious work begins.

Vendor Evaluation Documents

These days, no matter what kind of product you’re looking at, there are dozens of competing vendors - each with their own strengths, weaknesses, and trade-offs.

Business best practice is always to evaluate multiple options before committing to the one that best fits your organization’s needs. And the best way to keep that process organized is with a vendor evaluation document.

A vendor evaluation doc lets you clearly outline what each product brings to the table, where it falls short, and how it stacks up against your defined requirements (yep, those requirements again….).

By putting everything on paper, you strip away emotion and shiny marketing pitches, and instead make decisions based on the facts.

A good evaluation allows you to quantify your options against your requirements - that way you’re not left with gut feelings, you’re left with data-backed decisions.

You may not be writing vendor evaluation later in your career, but early on? Expect to write quite a few.

Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!

Learn more

Pull Requests & Tickets

Pull Requests (or Merge Requests) are part of daily life anywhere code is written.

They’re how changes make their way into production, and the quality of your PRs says a lot about your professionalism as an engineer.

At minimum, your PR should include a clear title describing what it does, break down commits in a way that’s easy to follow (or squash them if needed), and include a description that provides relevant business and technical context.

PRs are usually tied back to tickets, which act as the main artifact for work efforts by attaching relevant conversations, documents, and supporting materials. If done well, this makes it possible to verify that the code does exactly what it’s supposed to.

If you’ve ever had to review a RP labeled “Bug Fixed” with a description of “Fixed bugs in the process,” you know how painful bad documentation can be.

A vague PR isn’t just annoying for reviewers - it’s a nightmare later when something breaks and you’re trying to figure out what changed and why.

Well-written PRs save time, reduce mistakes, and make rollback scenarios easier. Think of it as documentation for your future self (or whoever inherits your code).

Bug Bounty Reports

This one’s a bit of a more niche, but one I’ve studied quite a bit.

Last year, I spent 100 days reading and dissecting a different bug bounty report every day (you can dig deep into my Twitter archives if you want to see). After going through that many, one thing became painfully obvious when it came to those achieving high payouts, and those getting minimum bounties.

Let me explain.

I previously worked at a company with an in-house bug bounty program. Although I wasn’t the primary triager, I saw plenty of submissions and even had the opportunity to sit in during some payout discussions. What stood out to me was how much the writing quality influenced the reward:

• A technically valid report that was confusing, incomplete, or hard to reproduce? Minimum payout.

• A report with clear reproduction steps but no stated impact? A bit more.

• A polished report with step-by-step instructions, a clearly articulated impact, and a working proof of concept? That was top payout every time.

Why? To reward hunters who made the work of fixing bugs easier, and to incentivize them to continue hunting on the program.

Clarity, reproducibility, and impact were just as valuable as the technical finding itself. I can’t speak for every bug bounty program out there, but I’d bet most follow a similar philosophy.

What I learned is simple: if you want to maximize both payouts and your credibility, learn to write bug reports that are clear, concise, and impossible to misinterpret.

Runbooks

Runbook is kind of a catch-all term in security, but at its core it’s simple: a runbook tells you exactly what to do in a specific situation to achieve a specific outcome.

They come in all flavors - alert triage, routine processes, incident response - but the guiding principle is always the same: speed, accuracy, and reliability.

When someone grabs your runbook, it’s usually not during a calm, controlled moment. It’s during a high-stress situation where mistakes are costly.

The last thing you want is ambiguity.

If your instructions are unclear, outdated, or missing steps, the entire point of the runbook is lost. That means writing matters. Every runbook should:

• Start with a clear purpose.

• Spell out each step unambiguously.

• Account for branching logic (e.g., if this fails, then do that).

Think of runbooks as automation for humans. They should be so well written that anyone on your team, even someone half-asleep at 3am, can follow them to the letter and get the right result.

Incident Response Documentation

Quality IR documentation is one of those things that you don’t appreciate until you’re in the middle of an incident where it makes all the difference.

For smaller incidents, you can usually scrape by with a loose process and verbal updates on an incident bridge.

But when that time comes when multiple teams get involved and the situation becomes increasingly difficult to manage - clear, well-structured documentation becomes a lifeline.

Good documentation speeds up onboarding for new SMEs - Instead of wasting an hour digging through Slack threads or waiting on a call for context, they can immediately understand the scope of the incident, their responsibilities, and the current state.

That hour saved could be the difference in resolving the incident faster.

It also streamlines executive communication. Providing a crisp status report is often time consuming: What happened? What’s been done? What’s next?

But when details are already documented in a central, organized way, reporting becomes simple.

Ultimately, strong IR documentation removes guesswork. It gives everyone clarity on their role, reduces overhead, and frees people to focus on the incident itself - not on catching up or chasing information.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Clarity is Your Competitive Advantage

At the core of everything we’ve covered is one theme: communication.

Strong writing doesn’t just help you document your work - it makes your ideas land.

It helps you collaborate, persuade and lead. When it’s time to push for a solution, the clarity of your words will often determine whether your ideas gain traction or get lost.

If you’ve ever faced unnecessary pushback, endless revisions, or a rocky transition from a legacy tool, remember this: the responsibility for clarity lies with the sender, not the receiver.

For engineers, writing is more than a soft skill. The better you write, the more influence you have. And the more influence you have, the more impact you make.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

In today’s world, threat actors are always circling, looking for any signs of weakness to snatch away valuable data from the bottomless pile of SaaS products that cluttering our phones and computers.

While these products make our lives easier in countless ways, they also come with a trade-off: you hand over personal data, trusting the vendor to keep it safe.

And while you might not be the intended target of these attacks, the reality is that with the modern day digital footprint each one of us carries, it doesn’t take much to be caught in the crossfire.

What may seem obvious for security professionals is not always obvious to the masses (something I’ve come to realize recently. And what you may not know is that securing your own precious data is not as difficult as you might expect.

What feels second nature to security professionals often isn’t obvious to everyone out there - and I’ve been reminded of that more than once lately.

The good news? Securing your data isn’t nearly as hard as you might think.

You don’t need to overhaul your life to protect your digital assets. Small, intentional changes make big differences.

My philosophy is simple: make yourself a harder target than the person next to you. If an attacker sees you or your accounts as too much work, they’ll move on to an easier mark.

If I were building my personal security posture from scratch today, these are the 40 steps I’d take to do it.

Essentials

These are those practical habits everyone should do, even if you’re not tech savvy.

1. Enable Two-Factor Authentication (Impact: 9/10 | Effort: 4/10): 2FA adds a second barrier of authentication to your accounts. Even if your password is stolen, attackers still need the second factor, drastically reducing your risk of compromise.

2. Use a Password Manager (Impact: 9/10 | Effort: 5/10): Use your password manager to generate strong, unique passwords for every account and remove the need to memorize them. This prevents one breach from endangering multiple of your accounts.

3. Update Your Devices Regularly (Impact: 8/10 | Effort: 2/10): Software updates patch vulnerabilities attackers actively exploit, and delaying updates leaves you exposed to known threats. Just set your devices to update while you sleep!

4. Don’t Reuse Passwords (Impact: 8/10 | Effort: 4/10): Reusing passwords allows one breached account to unlock many others. Unique passwords stop attackers from snowballing their access to your entire account portfolio.

5. Avoid Clicking Unknown Links (Impact: 8/10 | Effort: 3/10): While it may sound obvious, suspicious links in emails or texts can lead to phishing sites or malware. Hover before clicking and verify the sender. Or, just navigate directly to the site in your browser.

6. Use Unique Security Questions & Answers (Impact: 7/10 | Effort: 3/10): Real answers are often guessable or public. Use fake but memorable answers stored in your password manager for stronger account recovery security.

7. Check Website URLs Before Entering Credentials (Impact: 8/10 | Effort: 2/10): Phishing sites mimic legitimate ones. Quickly check the URL to ensure you’re on the real domain before logging in.

8. Install Antivirus/Endpoint Protection (Impact: 7/10 | Effort: 4/10): These software offerings detect and block malware before it can damage your system or steal your information. Some are even free!

9. Log Out on Shared Devices (Impact: 6/10 | Effort: 3/10): Prevents others from accessing your accounts when using shared computers, phones, or tablets.

10. Use + Email Aliasing (Impact: 6/10 | Effort: 5/10): Adding +sitename to your email before the “@” lets you see where spam originates and limits damage if one account is compromised, all while still receiving email at the same email address.

Securing Your Digital Footprint

If you want more control over how your data is spread online, prioritize these actions.

11. Google Yourself Regularly (Impact: 7/10 | Effort: 3/10): Search your name to see what personal details are floating around online. If you find something sensitive, take steps to get it removed before an attacker finds it first.

12. Limit Public Social Media Info (Impact: 8/10 | Effort: 4/10): Your vacation pics and work updates can double as a goldmine for social engineers. Keep personal details locked down and share selectively. If you’re really serious, make all of your accounts private.

13. Remove Old Accounts You Don’t Use (Impact: 7/10 | Effort: 5/10): Every forgotten account is a potential breach waiting to happen. Shut them down and shrink your digital footprint.

14. Avoid Oversharing in Public Posts (Impact: 8/10 | Effort: 3/10): Birthdays, addresses, even your favorite coffee shop are all clues a highly motivated hacker could piece together. Don’t give them the puzzle pieces.

15. Opt Out of Data Broker Sites (Impact: 9/10 | Effort: 6/10): Sites like Whitepages and Spokeo sell your personal info to anyone who pays. Use opt-out guides or services to make yourself harder to find.

16. Use Disposable Emails for Sign-Ups (Impact: 7/10 | Effort: 4/10): For one-off sign-ups, use disposable addresses to keep spam and trackers out of your main inbox.

17. Use Different Profile Pictures (Impact: 3/10 | Effort: 3/10): Reverse image searches can link accounts you thought were separate. Switch up your photos to keep them unconnected.

18. Revoke Permissions from Unused Apps (Impact: 7/10 | Effort: 4/10): Old apps can still track you or access your data long after you stop using them. Cut them off before they become a liability.

19. Clear Old Cloud Storage Files (Impact: 6/10 | Effort: 5/10): Sensitive files in cloud storage are easy to forget about—and easy for attackers to grab if they get in. Clean house regularly.

20. Separate Work and Personal Accounts/Devices (Impact: 8/10 | Effort: 5/10): One compromised login shouldn’t take down your whole life. Keep work and personal data in their own lanes.

    ---

- Today’s Sponsor -

Navigating personal digital security can feel overwhelming. SecuriBeat makes it easy by breaking down complex security practices into simple, actionable steps so you can build confidence in your cybersecurtiy decisions. Use the Security Dashboard to visualize your footprint over 15+ categories, understand your risk level, and track your progress over time. Take control of your digital footprint today.

Learn More

Privacy Habits

If you want to stay off the radar and keep your data private, start implementing these behaviors.

21. Use a Privacy-Focused Browser (Impact: 8/10 | Effort: 4/10): Browsers like Brave and Firefox block trackers by default, keeping advertisers from quietly building a file on you.

22. Install Tracker-Blocking Extensions (Impact: 8/10 | Effort: 3/10): Tools like uBlock Origin and Privacy Badger cut off advertisers and data brokers at the source.

23. Use a VPN on Public Wi-Fi (Impact: 9/10 | Effort: 4/10): Public hotspots are hacker hunting grounds. A VPN encrypts your traffic so no one can spy on your data.

24. Turn Off Location Tracking When Not Needed (Impact: 7/10 | Effort: 3/10): Your phone doesn’t need to log your every move. Disable always-on location tracking for all your apps and opt for “only while using” options.

25. Use Encrypted Messaging Apps (Impact: 9/10 | Effort: 3/10): Signal and WhatsApp use end-to-end encryption to keep your conversations private - even from the platform itself.

26. Disable Ad Personalization (Impact: 6/10 | Effort: 3/10): Tell Google, Facebook, and friends to stop profiling you for “better” ads. You’ll still see ads, just less that make you feel like these platforms are listening.

27. Avoid Linking Accounts Across Services (Impact: 8/10 | Effort: 6/10): If that master account gets breached, you’ll experience a cascade across every account you own. Keep them siloed and link selectively.

28. Use Privacy-Friendly Search Engines (Impact: 7/10 | Effort: 2/10): DuckDuckGo, Startpage, or Kagi won’t turn your searches into ad targeting profiles.

29. Use Burner Numbers for Sign-Ups (Impact: 7/10 | Effort: 4/10): Google Voice and similar services keep your real number out of marketers’ and scammers’ hands.

30. Encrypt Your Hard Drive (Impact: 9/10 | Effort: 5/10): Disk encryption makes sure your data stays locked away, just in case you lose your laptop.

The Next Level

For those of you who want to go all-in on security best practices, these are for you.

31. Enable hardware security keys for logins (Impact: 10/10 | Effort: 7/10): Physical keys like YubiKey or Titan provide the strongest defense against phishing, ensuring only someone with the key can log in.

32. Segment your home network (Impact: 8/10 | Effort: 8/10): Place IoT devices (smart bulbs, cameras, speakers) on a separate Wi-Fi network from your computers and phones to limit the blast radius if one is compromised.

33. Run regular security audits on your accounts (Impact: 9/10 | Effort: 6/10): Review login history, connected devices, and suspicious activity to catch problems early.

34. Review and rotate passwords every 6–12 months (Impact: 7/10 | Effort: 7/10): Refreshing credentials reduces exposure from breaches that may not yet be public.

35. Use email forwarding rules for breach monitoring (Impact: 7/10 | Effort: 5/10): Set up rules to flag suspicious incoming messages, helping you spot breaches and phishing faster.

36. Set up alerts for your name and email on breach databases (Impact: 8/10 | Effort: 3/10): Use HaveIBeenPwned or similar to get notified when your information shows up in a breach.

37. Sandbox suspicious files (Impact: 9/10 | Effort: 8/10): Open unknown files in an isolated, secure environment to check for malware without risking your main system.

38. Use virtual machines for risky browsing (Impact: 9/10 | Effort: 7/10): Contain high-risk activity (like downloading from untrusted sites) in a disposable VM to protect your main OS.

39. Disable macros in Office documents by default (Impact: 8/10 | Effort: 3/10): Macros are a top malware delivery method. Keeping them off blocks a huge attack vector, although it may cause some friction in your workflow.

40. Create an “If I’m hacked” response plan (Impact: 10/10 | Effort: 5/10): A personal incident response plan helps you react quickly, secure accounts, and limit damage if the worst happens.

    ---

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Personal security is a commitment, but it doesn’t have to be overwhelming.

Even tackling just the 20 easiest steps from this list can put you ahead of 90% of people out there.

Start small, chip away at them one by one, you’ll feel that background anxiety start to fade and be replaced with the confidence that you’ve made yourself a much harder target.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

Close your eyes for a second and think: How does my SOC actually operate?

Are analysts cherry-picking alerts? Sitting around waiting for tickets to roll in, only to close them with a lazy two-word update like “False Positive” or “Expected Activity”? Are they more focused on hitting a ticket quota than actually improving your security posture? Desensitized to threats because of fatigue?

If any of that triggered you in any way, then I hate to break it to you: Your SOC is functioning like an IT Helpdesk.

And look, no shade to IT. They’re often the unsung heroes keeping the org running. But your Security Operations Center has a different mission: detect and respond to threats, not to just clear a queue.

Modern threats demand a modern SOC. One that runs on curiosity, context, and critical thinking. Not one that measures success in ticket count per analyst.

To get there, you need to build a culture of proactivity. That means giving analysts space to grow and share their environmental knowledge, to threat hunt, to explore the unusual, and to dig deeper into high-fidelity signals.

But shifting from a culture of ticket-closing and towards one of threat hunting takes more than a pump-up speech and a good night’s sleep.

It requires leaving the helpdesk mindset behind and building systems that enable your team to become the proactive, threat-focused machine you’ve been dreaming of.

Remove Friction

In order for your team to shift towards a proactive methodology, the first thing you need to do is remove friction throughout your operation.

A frictionless SOC doesn’t mean alerts top flowing or incidents never happen. It means your analysts don’t feel stuck, confused, or overwhelmed during the process of completing their tasks.

It’s about clearing the path so your team can focus on what matters, rather than focus on moving through rugged processes.

Here’s how you start:

Build a DLC that Encourages Value, not Volume

Your Detection Lifecycle (DLC) is one of the most powerful tools in your fight against alert fatigue.

And let’s be honest - alert fatigue is the number one killer of proactivity.

If your team is drowning in low-quality alerts, they won’t have the time or energy to dig deeper into emerging threats.

That’s why your DLC should be designed to prioritize value over volume - and that’s a cultural shift that needs buy in at every level:

• Analysts should feel empowered to flag noisy or useless alerts.

• Engineers should be encouraged to propose detection creation and tuning ideas.

• Everyone should contribute environmental knowledge to improve coverage.

Make this a regular cadence - biweekly, monthly, whatever works. But make detection quality a recurring conversation.

When you build space for these conversations, you invest in long-term efficiency, trust, and better threat coverage.

Engineer Your Alerts to be Actionable

Too many SOCs suffer not from a lack of alerts - but an influx of bad alerts.

There’s nothing more deflating than opening a ticket that says: “A user performed this sensitive action.”

Okay, cool. But… What user? In what system? What’s the potential impact? Why should I care?

I have a theory when it comes to designing alerts: Every click matters.

If analysts have to dig through raw logs, dashboards, and runbooks just to figure out what happened and what to do - that’s the definition of friction. Time wasted. And that’s entirely avoidable.

The solution? Take the extra time to design alerts that actually make sense from a glance. Include:

• The impacted user/system

• Contextual enrichment

• Potential impact

• Suggested next steps with applicable links

And if you’re using a SIEM that ships with garbage default alerts (there’s a few of you out there I’m looking at), don’t be afraid to repurpose them into custom ones yourself.

Thoughtful alert design is the first kindness you can give your analysts.

Make Escalation Paths Accessible

Escalation should never be a guessing game.

When something serious pops up, the last thing your team needs is to ask: Who’s on call? Is this IR-worthy? Who do I tag in which Slack channel? Do I need to page someone?

Make sure escalation paths are clear, documented, and easily accessible:

• Maintain and share on-call schedules

• Define IR triggers and response thresholds

• Clarify responsibilities - who owns what, and when.

Not only does this reduce response time and stress, it helps ensure your high-severity incidents get the right eyes on them fast, without burdening the wrong people.

Whether it’s Detection Engineering, Incident Response, or Threat Huting - Security Operations is built on data. And as a Security Engineer, you need to make that data work for you. Selecty is a database-agnostic, sidecar query assistant built to do just that. Generate queries based on your table schehmas, optimize them to your use case, iterate on them quickly, and debug faster than ever - all in one sleek interface. Check it out!

Learn More

Automations are the Unsung Hero of the SOC

Every SOC knows that SOAR is part of the equation when it comes to designing a modern security function.

What’s unfortunate is that a majority of teams never actually make it there. But the impact of having a well thought out solution is difficult to overstate.

Have you ever triaged an alert from your phone just by looking at a Slack channel? I have. And let me tell you, it’s as glorious as it sounds.

Spotting automation opportunities isn’t always intuitive. But one of the highest-impact lowest-effort places to start is with automating the initial triage process - where analysts spend the bulk of their time just trying to understand the context around an alert.

When you’re deep in the triage trenches, you’re often pulling the same queries, checking the same dashboards, and referencing the same OSINT tools over and over.

Start broad. Begin at the source level, then move to the service-level, and finally down to the detection level.

It’s all about iteration over time, not getting it perfect out the gate. Over time, you’ll layer in these automations until the entire initial triage process runs without human input, and you’ll be able to triage a ticket from a quick glance.

This is one of the most effective ways to reduce alert fatigue. It frees analysts from the noise and lets them focus on alerts that are actually suspicious with real context, not just a vague title and arbitrary severity score.

Constantly Expand your Knowledgebase

Documentation is the king of “we know we should, but we don’t.”

And yet, it’s the single biggest contributor to consistency across your SOC.

Everyone on the team shares responsibility for maintaining internal knowledge. That means keeping resources up to date and ensuring critical information is just a quick search away when needed most.

At minimum, you should have:

• An org chart

• An architecture overview of your environment

• A master list of applications and their owners

• An on-call schedule

• Escalation procedures and your incident response guide

And at the heart of it all: Runbooks.

Runbooks are the main character in operational consistency. They need to be:

• Actionable, with correct queries and clear next steps.

• Concise, with no fluff and no ambiguity.

• Contextual, with links to relevant tools and dashboards.

• Flexible, with branching logic to account for different outcomes.

• Escalation-ready, with explicit instructions when help is needed.

Don’t expect perfection from the start., Think of your runbooks as living documents that are iterated on with every shift, incident, or handoff.

Because when people leave, and they will, your knowledge base is what keeps the SOC humming.

Make Threat Hunting a Recurring Meeting

We’ve all sat through that one meeting that everyone knows is a waste of time, and yet we still prioritize attending them.

So why don’t we apply that same consistency to threat hunting?

Threat hunting is the definition of proactively searching for threats, and the clearest way to shift your team from reactive defense toward proactive detection.

Whether done as a full team, in small groups, or solo deep dives, setting a regular cadence for threat hunting starts by acknowledging a simple truth: Your detection stack isn’t perfect. No stack is.

Threats slip through, and that’s just part of the game.

And while threat hunting often gets treated as a “nice to have,” if you’re serious about improving your security posture, it will quickly become clear that it’s a necessity.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Analytics Run the SOC

If you’ve been hanging around the Cybersec Café for a while, you’ve heard me say this before - probably more times than you can count. (Anyone up for counting how many times I’ve actually alluded to this?)

But I’ll say it again: Analytics are a must.

Sure, anecdotal experiences have their place. It can help shape your detection strategy in the early days. But as your SOC matures, it’s the data that will show you what’s working and what isn’t.

That's why it’s critical to methodically build metrics into every step of your operations. If you’re not measuring it, you’re not managing it.

Here are a few low-effort, high-impact ways to start embedding metrics today:

• Detections: Track alert classification (True Positive, Confirmed Activity, False Positive, etc.) when closing tickets. These metrics reveal detection quality and help highlight candidates for tuning or automation.

• Alert Triage: Measure Mean Time to Triage (MTTT) and Mean Time to Remediation (MTTR). This will tell you which alerts are burning the most hours on your team and what should be first in line for automation.

• Incident Response: This is a gold mine for tracking improvements. A great starting point is mapping MITRE ATT&CK techniques to affected platforms during incidents. It’s a quick win that reveals blind spots in your coverage.

• Post Mortem Improvement Items: Track your team’s ability to follow up on action items. What’s complete? What’s in progress? What’s been sitting on the backlog for too long?

• Day to Day: How much of the team is completing assigned project work each sprint? If deliverables keep slipping, is alert fatigue the culprit?

Metrics don’t necessarily paint the entire picture. But they’re a reliable way to track progress and spot bottlenecks before they become systematic issues.

And remember, the goal isn’t to micromanage. The goal is to run an efficient, proactive, high-performing SOC. Metrics just help you figure out where to look.

Remember: Proactive is the Goal

Your SOC doesn’t rise to the level of the talent you have. Rather, it falls to the level of the systems that you build around it.

If you structure your team like a Security Helpdesk, that’s exactly what it will become.

But if you invest in strategy, build scalable systems, foster a culture of continuous improvement, and fiercely protect your team’s time - you’ll unlock the full potential of your analysts and engineers.

Give your team the space and structure to hunt threats and embed security deep into your organization - not reactively, but intentionally.

It’s no easy task.

As an engineer, your job isn’t just to execute. It’s also to pause, reflect, and architect the systems that make long-term success possible. Anyone can build things, but few build with intent.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

Whether you’re new to the industry or pivoting into cybersecurity, I’m here to tell you that it’s easier than you think to stand out in this hyper-competitive field.

But, I’m blown away by how many professionals I’ve met who never do it, and also those who have no aspirations to do it.

And no, I’m not going to tell you to chase another certification.

Sure, certs can help if you need a foot in the door. But if you’ve been following this newsletter for a while, you’ll know I’m a big fan of building tangible skills, not just collecting PDFs.

Because the people who make a real impact in cybersecurity? They’re the ones who build, break, and solve things. Not the ones who spend every other month cramming for an exam.

Here’s the secret: get technical from day one.

That’s it.

Now, I get it - you’re probably thinking, “Okay Ryan - Sure, getting technical sounds great in theory, but what does that actually mean in practice?”

In this article, I’ll give you the foundations to get started. And the best part? Everything you absolutely need to learn is free.

But, the rest is up to you.

The Foundation

This is where it all begins. If you’re serious about building technical skills in cybersecurity, you need to start with the core concepts.

They may not be glamorous or exciting, but they’re critical. These fundamentals will form the mental scaffolding for future concepts, tests, and solutions you’ll encounter throughout your career.

Everything you learn will build upon these foundations in some way, so take the time to truly understand them. I’ll give you exactly what you need here to get started, but I challenge you to be curious and dive deeper into them.

Infrastructure Basics

Firewalls

Firewalls are security devices or software that monitor and filter network traffic based on a defined set of rules - either incoming (ingress) or outgoing (egress) traffic. Think of them as digital security guards standing at the perimeter of your device or network.

There are two primary types:

• Host Based: Installed on individual machines to filter traffic specific to that device. (Ex. Windows Defender Firewall)

• Network Based: Deployed at the edge of a network to control traffic between the internal network and internet. (Ex. Palo Alto, Cisco ASA)

Misconfigured firewalls are one of the easiest ways attackers can sneak in. As a security engineer, you’ll frequently need to review logs or help create firewall rules - especially during security incidents.

Network Basics

To understand how systems communicate, you need to understand the OSI model. It breaks networking into 7 logical layers:

It consists of 7 layers:

1. Physical: Hardware like cables and switches.

2. Data Link: Manages MAC addresses and switching on local networks.

3. Network: Routes data across networks using IP addresses, subnets, and routers.

4. Transport: Ensures reliable data delivery.

5. Session: Manages communication sessions between applications.

6. Presentation: Handles data formatting, encryption, and compression.

7. Application: The user-facing layer (e.g. web browsers, email clients).

Each layer relies on specific protocols for communication. Here are some common ones you’ll run into:

• TCP (Layer 4): A reliable, connection-oriented protocol used fin most web traffic and email

• UDP (Layer 4): A faster, connectionless protocol used for streaming, DNS, and VoIP.

• ICMP (Layer 3): Used for diagnostics and often abused by attackers during reconnaissance.

• SFTP (Layer 7): Secure file transfer using SSH, differing from the insecure FTP protocol.

Each layer also has ports associated with various services. They’re often tied to Layer 4 protocols:

• 22 - SSH: Secure shell access to remote machines.

• 53 - DNS: Domain name resolution.

• 80 - HTTP: Unencrypted web traffic.

• 443 - HTTPS: Encrypted web traffic.

Web Protocols

Whether it’s tooling or applications, much of what we deal with as security engineers involves the web in one way or another.

That’s why it’s essential to understand how the web works at a foundational level

As I mentioned earlier, ports 80 and 443 are delegated by default to HTTP and HTTPS. The differences between the two are:

• HTTP: Data is sent in plaintext and is vulnerable to sniffing.

• HTTPS: Data is encrypted via TLS, protecting it in transit.

Over these protocols, web applications use core HTTP methods to communicate:

• GET: Retrieves data.

• POST: Submits data.

• PUT: Updates or replaces data.

• DELETE: Removes data.

There are also three fundamental components to understand how web applications work and how all aid the layered security approach:

• Cookies: Store session data on the client side and can be hijacked if not properly secured.

• Headers: Metadata passed with requests and responses.

• Sessions: Track users after login and are crucial to maintain state and identity.

Getting a handle on these web basics will help you contribute confidently in web security conversations.

DNS

DNS is a foundational topic to how the internet works. It’s essentially the internet’s phone book.

It translates human-readable domains into machine friendly IP addresses.

At a high level, DNS resolution involves a recursive lookup process, typically flowing form:

1. Local DNS Resolver

2. Root Name Server

3. Top-Level Domain (TLD) Name Server

4. Authoritative Name Server

Each step helps you route to the correct IP address behind a domain.

I highly recommend watching this explanation video from PowerCert on YouTube for all the details:

Cybersecurity Basics

Now that you’ve covered the foundational knowledge of how networks and the web work (from a mile-high view), it’s time to jump into some cybersecurity basics - after all, that is the industry you’re looking to get into.

Authentication vs Authorization

At its core, cybersecurity is about ensuring secure access to data. That starts with secure applications.

Applications rely on two key concepts:

• Authentication: Verifies who you are. (Ex. username/password, MFA code, fingerprint scan)

• Authorization: Determines what you’re allowed to do after you’ve been authenticated.

These two go hand-in-hand: authentication gets you in the door, and authorization determines what rooms you can access once you’re inside.

Encryption

Encryption is one of the most fundamental cybersecurity concepts - and for good reason.

It’s all about protecting data from unauthorized access by converting it to unreadable formats.

There are two main types:

• Symmetric: Uses the same key to encrypt and decrypt data. It’s fast, efficient, and great for large volumes of data. (Ex. AES)

• Asymmetric: Uses a public key to encrypt and a private key to decrypt. It solves the key exchange problem and enables use cases like secure web browsing, email encryption, and digital signatures. (Ex. RSA)

A real world example: When you visit a website over HTTPS, asymmetric encryption helps initiate the secure connection. After the handshake, symmetric encryption takes over for faster performance.

Hashing

Hashing is the process of turning data into a fixed-length string using an algorithm. Unlike encryption, it’s one-way - meaning you can hash data, but you can’t “unhash” it.

But here’s the key: the same input will always produce the same output when using the same hashing algorithm.

It’s important to note that hashing is not encryption. It’s not meant for secrecy, it’s meant for integrity. And it’s not secure by default. Hashes can be brute-forced or cracked using rainbow tables if they’re not properly salted.

Some common use cases for hashing algorithms, like SHA256 and MD5, are:

• Password Storage: Hash and salt password before saving them to a database.

• File Integrity: Verify a file hasn’t been tampered with.

• Digital Signatures: Ensure authenticity and data integrity.

Popular Vulnerabilities

Or as I like to call them: the ticket sellers of cybersecurity.

Let’s be real - most of us got interested in this field because of the hacks, the breaches, and the drama we saw in news articles. That’s why you should know about the most common (and some of the coolest) vulnerabilities:

• Cross-Site Scripting (XSS): Allows attackers to inject malicious scripts into web pages. It’s often used to steal cookies or hijack sessions, but can be prevented with proper input sanitization and proper output encoding.

• SQL Injection (SQLi): Attackers can manipulate SQL queries via user input to access or modify data they shouldn’t. It’s common in poorly coded login forms or search boxes and can easily be mitigated by using parameterized queries.

• Buffer Overflow: Happens when more data is written to a buffer than it can handle and can lead to crashing or code execution. It’s typically found in lower-level languages like C and C++.

Command Line

You can’t be effective in security without getting comfortable in the terminal.

Whether you’re on Linux, macOS, or Windows, the core concepts stay the same - you’ll just need to learn the different syntaxes.

Mastering the command line will help you navigate systems, investigate EDR alerts, use command-line tooling - all while looking like a pro hacker in the coffee shop.

Here are a few foundational basic unix based commands to know:

Navigating Files

• cd - Used to move between folders

  • Ex. cd /var/log

• ls - View files and directories in the current folder

  • Ex. ls

• cat - Concatenate and view file content in the terminal

  • Ex. cat config.txt

• find - Search for files

  • Ex. find / -name “*.log”

Permissions

• chmod - Change file permissions to control who can read, write, or execute files

  • Ex. chmod 755 script.sh

• chown - Change the owner or group of a file

  • Ex. chown root:admin secure.txt

• unmask - Sets default permissions when new files/folders are created

  • Ex. unmask 022

• sudo - Execute a command as superuser

  • Ex. sudo npm install package

Network Troubleshooting

• ping - Tests is a host is reachable and how fast

  • Ex. ping cyberseccafe.com

• traceroute - Track the path to a host

  • Ex. traceroute cyberseccafe.com

• curl - Send requests to web servers

  • Ex. curl -I https://www.cyberseccafe.com

• nmap - Scan hosts and networks for open ports and services

  • Ex. nmap -sV 192.168.1.1

If want hands-on practice, a brilliant resource for learning command line fundamentals is OverTheWire’s Bandit challenge: https://overthewire.org/wargames/bandit/

SQL

SQL isn’t just nice to know anymore - it’s a must-have.

In a field driven by logs, alerts, and data streams, your ability to extract insights with a simple query can make or break an investigation.

Even if your tooling doesn’t use SQL directly, most security platforms use SQL-inspired languages (like KQL, Lucene, or SPL).

Start with these core SQL concepts and dig down from there:

• SELECT - Choose the columns you want to view

  • Ex. SELECT username, login_time

• FROM - Specify the table where the data lives

  • Ex. FROM login_events

• WHERE - Filter rows based on conditions using operators like:

  • = (Exact Match)

    • WHERE status = ‘failed’

  • LIKE (Pattern Matching)

    • WHERE email LIKE ‘%@gmail.com’

  • IN (Multiple values)

    • WHERE country IN (‘US’, ‘UK’, ‘CA’)

• LIMIT - Restrict the number of rows returned.

  • Ex. LIMIT 50

• ORDER BY - Sort the results

  • Ex. ORDER BY timestamp DESC (most recent events first)

• GROUP BY - Aggregate similar values

  • Ex. GROUP BY ip_address

• COUNT() - Count rows returned. Often used with GROUP BY

  • SELECT ip_address, COUNT(*) FROM logins GROUP BY ip_address

You can use a resource like SQL Practice and SELECTY to write, test, and understand queries in real time.

If you want to go deeper, I’d suggest reading my article Why Knowing How to Query is an Essential Cybersecurity Skill.

Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!

Learn more

Programming with Python

With so many languages out there, choosing where to start can often feel overwhelming.

Truthfully, you can pick almost any major programming language and be fine. But if you’re heading into cybersecurity, I strongly recommend starting with Python. Here’s why:

• It’s beginner friendly and reads like plain English.

• It makes automation easy - perfect for eliminating repetitive tasks.

• It helps you focus on problem-solving, not memorizing confusing syntax.

• It’s widely used across the security landscape - from detection engineering, to incident response, SOAR, and open-source tooling.

The best part is you don’t even need to master complex topics. If you get the basics from this article, you’re off to a strong start.

Basic Data Types

• Strings (str) - text

• Integers (int) - whole numbers

• Floats (float) - decimal numbers

• Booleans (bool) - True or False

• NoneType (None) - Represents the absence of a value

Collections

• Array (list) - ordered, changeable (mutable) sequence

• Set - unordered collection of unique values

• Dictionary (dict) - key-value pairs

Basic Scripting
These control structures form the foundation of logic for any script.

• if Statements - for decision making

• for Loops - for iterate over data

• Functions - for packaging and reusing logic

JSON

You’ll frequently encounter JSON data when working with APIs and logs. JSON (Javascript Object Notation) looks almost exactly like a Python dict, and Python has built-in tools to work with it seamlessly.

Advanced Concepts

Security professionals frequently write scripts that talk to other tools via APIs.

Python has a library called requests that makes this simple:

• requests.get()

• requests.post()

• requests.put()

• requests.delete()

It’s common to work with CSV files. Whether you’re parsing logs or generating reports, Python’s csv module has csv.reader and csv.writer methods to perform these operations with ease.

Next Step

The best way to learn is by building. Try this project to apply everything above:

Build a simple Flask API in Python. Ask ChatGPT to help you brainstorm what it should do (but don’t let it code the whole thing for you). For example: upload a CSV of your weekly expenses and return them sorted by price range.

Then…

Create a CLI tool to talk to your Flask API. An example use case could:

• Take a CSV filename from your local system

• Send the data to your Flask endpoint

• Write the returned response to a JSON file.

You have the tools. You have the blueprint - what are you waiting for?

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

Bonus Exercise: Web App Security

In today’s world of SaaS platforms and microservices, web applications are everywhere - so understanding how they work (and, just as important, how they break) is key.

One of the best beginner-friendly ways to learn is by using Juice Shop - a deliberately vulnerable web app that teaches security through hands-on hacking. You’ll explore these real-world concepts in a legal environment and gain insight into how websites actually work.

You’ll also develop essential debugging skills - like using browser developer tools to inspect requests and responses.

Pro Tip: Pair Juice Shop with Burp Suite - a powerful tool used by AppSec pros to intercept and manipulate HTTP requests. Their free Web Academy is one of my favorite online resources (unsponsored) and is a fantastic way to go even deeper and build confidence in your skills.

Why Being Technical Matters

Cybersecurity is more competitive than ever, and standing out is getting even harder. The industry is shifting, and technical skills are becoming a must.

The truth is, most people don’t put in the extra time to sharpen their skills. That’s your opportunity. It could be the difference between landing the job or missing it, getting promoted or staying stuck.

As professionals, we owe it to ourselves to keep growing. If you’ve been in the field and know your technical skills need work - this is your sign to start.

If you’re just getting started - this is your chance to build a strong foundation early.

If you already have the skills - double down and keep rounding yourself out.

Because at the end of the day, growth matters. And leveling up your technical skills is one of the most powerful ways to grow.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

Forget the movie scenes. Most days in cybersecurity aren’t about zero-days, red teaming, or duct-taped Python scripts written in the heat of an incident.

The real work often revolves around data.

Security professionals spend a large bulk of their time collecting, interpreting, and responding to streams of telemetry across systems, endpoints, and networks.

Without quality data, robust systems, and intelligent people to interpret and take action - there is no security team.

• You can’t write effective detection rules.

• You can’t hunt for threats retroactively or proactively.

• You can’t investigate, contain, or recover from incidents.

If there’s no visibility into your environment, you’re flying blind. Or just as dangerous is having the data and not knowing how to read it.

That’s why data analytic and statistical knowledge aren’t just nice-to-haves. They’re critical.

In this field, if you don’t understand your environment, you can’t protect it.

Challenges

Even with the right tools and a skilled team, logging and monitoring isn’t as simple as flipping a switch.

There’s more to it than plugging different platforms into the SIEM, waving your magic wand, and suddenly you have valuable insights.

There are tradeoffs, tough choices, nuance, and plenty of considerations to be made along the way.

What do we collect?

Not all logs are created equal. You can’t collect everything - at least not realistically.

So a conscious decision must be made for every source.

At its simplest form, you need to determine what log sources are valuable by taking the time to spell out why.

Start by asking:

• What’s the actual value of this log source?

• Is it needed for real-time detection?

• Does it help with incident response?

• Does it enrich other logs through context?

• Is it required for compliance?

A shared understanding of what you’re collecting and why helps avoid wasted effort and bloated pipelines.

This is the foundation of a smart, sustainable strategy.

Where do we store it?

Storage is a constant balancing act between cost and capability. Budget is not infinite and log storage is expensive.

You’ll likely have two primary tiers:

• High-cost storage (e.g. your SIEM) for logs that support real-time detection use cases and require fast access.

• Low-cost storage (e.g. AWS S3) for logs that provide investigative context or are required for compliance retention.

There’s no one-size-fits-all solution. It’s no longer realistic nor cost-effective to store all log sources in a single source.

As a team you’ll need to understand what you prioritize - speed, budget, a single-pane-of-glass…

If you have the budget to keep all logs in one place - consider yourself lucky!

How long do we keep it?

It’s not always obvious what data you will need, or when you will need it.

The safest answer is often: “Keep everything, for as long as you can stomach it.”

But the reality is storage costs add up fast, especially for high-volume, high-cost platforms like SIEMs.

Many teams default to keeping logs for 12-15 months, which aligns with common compliance requirements.

But what happens if a threat has been lurking quietly for beyond then? What if a legal hold or regulatory inquiry suddenly requires access to old logs?

These are the kinds of scenarios that make retention strategy a critical part of your logging plan. The key is balancing cost, compliance, and risk - while also preparing for the unknown.

How do we drive action from our data?

With so many sources, fields, and values flooding your SIEM every day, separating noise from real signals can feel impossible.

But at the end of the day, that’s the job. Turning raw data into meaningful insight is what makes a security program proactive instead of reactive. And that takes skill.

You’ll need to write queries, look for patterns, understand business context, and recognize anomalies. It’s not just an analyst’s job - it’s a core skill for anyone working in cybersecurity - whether you’re red team, blue team, or somewhere in between.

The good news? Once you learn how to work with data, that skill travels with you.

The hard part? Getting there. But once you’re on the other side, it’s one of the most valuable tools for your career.

Whether it’s Detection Engineering, Incident Response, or Threat Huting - Security Operations is built on data. And as a Security Engineer, you need to make that data work for you. Selecty is a database-agnostic, sidecar query assistant built to do just that. Generate queries based on your table schehmas, optimize them to your use case, iterate on them quickly, and debug faster than ever - all in one sleek interface. Check it out!

Learn More

Architecture

The Traditional Approach

The go-to strategy for many cybersecurity teams has long been to send all logs to the SIEM.

The goal? A mythical “single pane of glass” - or one place to see everything. But in today’s landscape, is that even practical? Or smart?

Relying on a single platform can quickly lead to vendor lock-in. The more time and effort you invest into the one platform, the harder it becomes to leave.

Migrating your data, retraining your team, rebuilding your infrastructure, reconfiguring alerts - it’s a heavy lift.

And vendors know this. But at this point, you become a slave to their pricing because they know you’re stuck. There are a couple vendors that are notorious for insanely high cost (but I won’t put them on blast here).

Then there’s the issue of siloed data. Along with security specific data, security teams also often ingest some similar sources as other departments - leading to double ingestion costs and unnecessary complexity.

The truth is, the traditional model is showing its age. New players are entering the market with flexible, cost-effective approaches.

That “single pane” is cracking, and it might be time to rethink what centralized visibility should really look like.

Data is on the Move

Data lakes are rapidly becoming the backbone of modern security architectures.

Why? Because they’re not just cheaper, they’re smarter. A well-architected data lake allows you to store security-relevant data at scale, run advanced analytics, and break down silos between teams.

All while avoiding traditional vendor lock-in. You have the ability to:

• Centralize and unify data across departments.

• Lower storage and compute costs.

• Scale effortlessly.

• Support more complex detection and investigation workflows.

As this model continues to gain traction, SIEM vendors are being forced to adapt. They’re now figuring out how to work on top of your data lake - a major shift in power and flexibility.

The result? You take back ownership of your data. You control the architecture. And you can swap in and out tools as your needs evolve without feeling handcuffed to a single platform.

The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.

Join Now!

How Security Teams are Operationalizing Data

Statistics is the science of collecting, analyzing, interpreting, presenting, and organizing data.

The SIEM is a big data engine. It provides the tools to ingest, store, and visualize your security telemetry. But without the skills to analyze and operationalize the data, it’s like owning a library and not being able to read.

Security teams must develop strategies to act on their data at scale. Otherwise detection engineering, triage, hunting, and incident response all break down.

Detections

Detections are the heart beat of security operations.

Traditional detections often rely on black and white boolean logic to determine whether an event matches known bad behavior. But as threats grow more subtle and user behavior more dynamic, this approach starts to fall short.

That’s where statistical thinking steps in.

Behavioral detections, especially user-based ones, are notoriously tricky to get right. But by applying basic statistical analysis like mean and standard deviation to historical activity, you can begin to identify anomalies by searching for outliers.

These are specific activities that are statistically improbable.

This mindset shift allows you to go beyond simple pattern matching and to find signals that are truly anomalous.

Combine this with boolean logic, and you’ve got a powerful hybrid.

Alert Triage

Whether you’re manually triaging alerts or building automated SOAR workflows, statistical reasoning is a crucial skill.

Every alert is in a sense, a question: “Is this worth our time to investigate further?”

To answer it, you need to think like both a security analyst and a data analyst - you need to sift through raw telemetry, identify the relevant pieces, and organize them into a coherent story about a user, system, or behavior.

The goal is to contextualize the signal and assess the likelihood that it represents real risk. Sounds straightforward - but the challenge lies in variety and business context.

Different log sources, enrichment layers, and detection types all introduce complexity. And in these moments, environmental knowledge becomes just as important a technical skill.

Performance

The numbers don’t lie.

When you’re dealing with massive volumes of data, gut feelings won’t cut it - you need your metrics to prove your security function is performing.

Start collecting performance data across your operations as soon as possible: detection, response, and SOC workflows. These metrics provide an honest snapshot of where you stand today and how you’re trending over time.

Track the fidelity of your detections, the mean time to triage, and how long it takes to resolve incidents.

This data will quickly become your compass - pointing the way to efficiency and continuous improvement.

Threat Hunting

At its core, threat hunting is about finding what doesn’t belong.

It’s a manual process rooted in curiosity, intuition, and a methodical approach.

The best hunters don’t just stumble upon threats - they use structured techniques to interrogate data, spot anomalies, and test their hypotheses.

That means slicing through big datasets, surfacing patterns, and building a story based on evidence.

It takes a blend of technical skill and investigative mindset. The challenge? Knowing what to look for and how to get there without drowning in the noise.

Security Incident Response

Incident response thrives on precision, and your data is the foundation.

You’re not just collecting metrics to see how your team responds, you’re also building a full timeline of events based on historical data.

Attacks often sprawl. Your job is to trace them: sift through logs, correlate data sources, and identify the start and spread of an incident.

That means narrowing scope, identifying what’s relevant, and cutting the rest.

If you can compare current activity against historical baselines, even better. You’ll move faster, make stronger decisions, and resolve incidents with confidence.

💬 How else do you utilize data analytics and statistics concepts in your day-to-day as a security engineer? Let me know below!

Leave a comment

The Narrative

By now, you’re probably noticing a theme: using data and statistical analysis to craft a narrative.

In cybersecurity, it’s not enough to just make sense of data - you need to translate it into something others can understand and act on.

That means making data actionable - the skill of filtering through massive amounts of telemetry, identifying what matters, and drawing conclusions that drive decisions.

Sure, if you’re communicating engineer to engineer, raw data might be enough.

But let’s be honest - that’s not how the real world works. Most of the time you’ll need to explain your findings to people who don’t live in the logs like you do.

Data is the evidence. The narrative is the conclusion.

This is exactly why statistical proficiency is so critical in cybersecurity. It’s the intersection of math and communication - taking something complex and making it understandable.

The professionals who can look at a wall of numbers and translate it into a compelling, security-relevant story are the ones who stand out. That skill of turning raw data into a clear and confident narrative is a superpower.

Cybersecurity is challenging for this exact reason. It’s not just one discipline - it’s many combined.

You need technical chops across a massive stack, data fluency, communication skills, and strategic thinking. All working in harmony.

But like anything else worth mastering, it takes practice. You won’t learn this overnight, but you will learn it if you show up, do the work, and build on the basics.

If you’re looking to improve this specific skillset, I’d highly recommend checking out these two articles next:

• My Log Source-Agnostic Methodology to Understanding Big Data

• Why Knowing How to Query is an Essential Cybersecurity Skill

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

It’s easy to get swept up in the hype and buzzwords around cybersecurity careers. I know I did - that’s a big part of what initially drew me to the field.

But it’s important to understand what the day-to-day actually looks like as a Security Engineer.

It’s not nonstop writing POC scripts for CVEs. It’s not waking up every morning to fend off DDoS attacks. And no, you’re probably not battling a ransomware threat every month (at least I hope not).

But often, the real glamor is in the unglamorous.

Day-to-day as a Security Engineer is about tackling the tasks that truly move the needle. It’s the steady, consistent efforts that prepare you for when the inevitable happens.

Here’s what a typical day in my life as a Security Engineer looks like.

Morning Routine (5:30am-6:15am)

I’m a firm believer that setting yourself up for success starts the moment you wake up. For me, that means getting straight to it as soon as the alarm goes off and keeping my phone tucked away for a majority of the morning.

I always start with a 20-minute yoga/stretching routine. Sitting at a desk all day can wreak havoc on your body, so this is a non-negotiable for me. It not only gets me feeling energized and focused, but helps prevent long term damage from sitting for hours.

Next is my daily morning walk. This 10-15 minute effort helps switch my brain on, gets light in my eyes, and gets my blood moving. And honestly, some of my best ideas come during these walks.

Finally, I wrap up my morning routine with a mix of athletic greens while I take my daily supplements.

By the time that’s done, I’m fully dialed in and ready to start the day.

Daily Preparation (6:15am-7:00am)

Proper preparation is the single biggest productivity hack. When you know exactly what you’re going to focus on, you waste less time deciding and spend more time doing real, deep work.

Security Alerts

A big part of working in Detection and Response or Security Operations is security alerts from the SIEM and other reporting platforms.

This early review not only helps to get my brain going, but is also to ensure no critical IOCs were missed overnight by the SOC team. I’ll spend a few minutes reviewing for any suspicious activity, then triage any leftover alerts that may have come through during the handoff between shifts.

Emails & Tickets

Next up is catching up on emails and tickets. I’m looking for anything new to add to my to-do list for the day, or updates on ongoing work that needs to be documented.

It’s not the most thrilling of activities, but staying on top of comms helps in prioritizing tasks for your day.

News Catchup

It’s essential to stay aware of any critical news or emerging threats in the cybersecurity world.

I usually spend 10-15 minutes scanning articles or threat intel updates that might impact me or my industry.

This step is small but important, as it can easily inspire new detections to create, or even spark a threat hunt if something stands out.

Day Planning

This is arguably the most important part of the morning. There’s always too much to do and not enough time to do it - so prioritization is key.

I generally split tasks into three buckets

1. Day-to-Day: Ongoing, discipline-based tasks. For me, that includes managing the detection lifecycle (creation, tuning, SOAR maintenance), plus upkeep of the tools I administer.

2. Projects: Usually planned by the quarter. As you mature in your role, you have to carve out time for these medium-to-heavy lifts to keep them on schedule. They’ll vary depending on your security posture and priority as a team.

3. Ad-Hoc: One-off tasks that pop up through the week. They can take anywhere from 5 minutes to 2 hours and can vary wildly in priority. I always have a backlog of these, so I make sure to review and prioritize based on time and effort.

Each day, I pick out my highest-priority tasks and block off time on my calendar to tackle them. If you treat working on your tasks like attending a meeting, you’ll make sure to show up and get it done.

Stand Up (7:00am-7:20am)

When 7am rolls around, it’s time to celebrate. Not just because it’s time to chat and align with the team, but also because it’s time for my first cup of coffee.

Alignment on key tasks is crucial for making real progress, especially when you’re working across time zones. And like most teams, we leverage two-week sprint cycles for planning our efforts.

This stand-up is our chance to get everyone on the same page, unblock anything holding people up, and coordinate collaboration. It’s also where I check whether I can stick to my plan for the day or if I need to pivot to support other efforts.

Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!

Learn more

Deep Work (7:30am-10:00am)

Now, it’s time to dial in.

For me, that means filling up my second cup of coffee, queuing up LoFi Girl, throwing on my noise-cancelling headphones, and locking in on my most important tasks.

My morning deep work block is reserved for the biggest lifts: usually high-priority day-to-day tasks and project work.

Since I find my mornings are my most productive hours, I want to make sure I’m ready to hit the ground running. This is exactly where my early planning pays off. I can jump straight in without losing time figuring out what to do next.

When I say deep work, I mean it: phone away, notifications off, distractions limited - don’t underestimate the power of your flow state. Tackling your hardest tasks first thing in the morning is a great trick to build momentum for the rest of your day.

I also like to break my deep work session into smaller time blocks based on how long I think each task will take. That way I can plan to take quick breaks between items to reset before jumping straight into the next one.

The Looming Inevitable…

Of course, it’s not uncommon for my entire morning to get overtaken by a security incident.

Incident response is part of the job. It can completely derail what you planned for your day, but it’s also part of what makes this industry exciting.

You never know exactly what or when it will happen, but you have to plan for it. And if you’re lucky and don’t get many incidents in a quarter, that just means you’ll have extra time on your hands to prioritize other projects or efforts.

Meetings (10:00am-11:30am)

If I’m lucky, I can schedule any meetings for late morning so that I don’t disrupt my flow state during my deep work block.

Meetings are a necessary part of any role. While security engineering isn’t as meeting heavy as other jobs in tech, they are still very much a part of the job..

If I’m the one scheduling the meeting, I always provide attendees with an agenda. It doesn’t need to be overly detailed and outlined to the minute, but having a clear plan keeps us on topic, ensures everyone comes prepared and aligned, and makes sure not to waste anyone’s time.

Lunch (11:30am-12:30pm)

Lunch is my first meal of the day and is my time to refuel and mentally reset.

As boring as it might sound, I eat pretty much the same thing every day. It’s healthy and light, which keeps me from feeling sluggish the rest of the day, and also removes the decision-making overhead.

During lunch, I also try to be productive in other parts of my life. I’ll work on learning Spanish with Pimsleur or catch up on some of my favorite podcasts like Startups for the Rest of Us, Darknet Diaries, or Crime Junkie.

Most importantly, I fully disconnect from work during this time. It’s essential for refreshing my mind before diving back in for the afternoon.

Collaborative Work (12:30pm-2:00pm)

Afternoons tend to be less productive for heads-down solo work because more teammates are online and looking to collaborate.

That’s why I deliberately front-load my day with deep work.

This block is dedicated to anything that requires collaboration - whether that’s async strategizing over Slack, ad-hoc discussions, or formal meetings with other teams or departments.

Typically, this time is filled with project-related work or addressing ad-hoc tasks that pop up.

Afternoon Solo-Session (2:00pm-2:50pm)

Because I front-load my most challenging work in the morning, my afternoons are reserved for easier, low-effort day-to-day or ad-hoc tasks.

This approach works well around afternoon meetings since it’s much easier to fit these tasks in between calls since they don’t demand as much focus. Even if you get pulled away in the middle, it won’t derail your flow the way it would with a complex task.

Wind Down (2:50pm-3:00pm)

Part of setting yourself up for success tomorrow is properly closing out today.

I like to quickly document the things I accomplished, note any tasks that spun off from those efforts, and list anything I left unfinished.

This way, I can pick up exactly where I left off the next morning - especially helpful if “tomorrow” is the Tuesday after a long weekend.

Workout (3:00pm-4:30pm)

My workout is a non-negotiable part of my day.

It’s essential for my physical health, but equally important for my mental reset. It also creates a clear boundary between my job and my entrepreneurial work.

I train Monday through Friday without fail, and generally try to fit in another session on the weekends. My workouts rotate between weight training, cardio, yoga, and skill-sports (Basketball, Tennis, Golf, and Pickleball).

I genuinely believe that pushing yourself physically every day pays dividends in every other aspect of your life.

Afternoon into Evening Session (4:30pm-8:30pm)

This is where I switch gears and focus on my entrepreneurial endeavors - whether it’s writing this newsletter, building digital products, or growing my personal brand.

After my workout reset, I find it easy to get back in front of the screen and dive into creative work. Some days it’s two hours, others it’s a full four - it depends on how I feel and what I need to get done. But I try not to pressure myself too much during this block.

Funny enough, this part doesn’t feel like work. When you’re building something you care about, time flies.

I then like to reserve the last 60-90 minutes of my evening to wind down, disconnect, and rest before heading to bed.

💬 If you work in cybersecurity, how does my day compare to yours? Let me know below!

Leave a comment

Takeaways

You can definitely take this article at face value to see what a day in the life of a Security Engineer looks like and whether it aligns with your expectations. But I’d also love to leave you with a few lessons I’ve learned from how I structure my days:

Planning Works

Project management isn’t just for work. Applying it to your personal life clears up mental space and makes following through easier - whether that’s writing things down, tracking goals, or reviewing progress. Like my end-of-day wrap-up, it helps you pick up exactly where you left off and gauge your progress over time.

Use Your Time Intentionally

When you block time for a task, give it your full attention. Eliminating distractions allows you to finish faster, achieve higher quality work, and enjoy your free time guilt-free. Put your phone down, lock in, and be present - you might find you have more time later than you think.

Small Efforts Lead to Big Results

Progress isn’t always loud. Small, consistent efforts toward your goals compound over time. Success is less about giant leaps and more about showing up every day and putting in the work.

Securely Yours,

Ryan G. Cox

Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.

Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.

. . .

Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!

If you’ve spent more than a day in cybersecurity, you’ve definitely heard the phrase Indicators of Compromise, or IOCs, thrown around.

It’s often used as a blanket term for signals or behaviors that point to a potential threat, but it really only scratches the surface.

Threat indicators span a broader spectrum. Some are technical - concrete data points that may signal an attack or breach. While others are behavioral - suspicious activity or patterns that suggest something might be off.

By understanding the various terms and associated indicators, you can leverage them to sharpen your detections, improve your monitoring strategy, and proactively harden your defenses. They can also play a key role in shaping incident response plans by helping build processes tailored to the threats specific to your environment.

Not to mention, they’ll help you communicate clearly to your team members.

Put simply: knowing the full range of threat indicators means spotting and stopping threats before they escalate into something bigger.

While some of the terms we’ll cover are formal cybersecurity lingo, others are more contextual and used flexibly depending on the team or environment. I’ll highlight both, along with any alternate terminology you may hear.

Indicators of Compromise (IOC)

Indicators of Compromise observable pieces of evidence showing that a system or network has been breached. These typically surface during forensics work or investigations and act as proof that an attack has succeeded. Examples include known malicious IP addresses, malware hashes, or traces of unauthorized activity.

Alternate Terminology: Forensics, Artifacts, Evidence

Indicators of Attack (IOA)

Indicators of Attack signal that an attack is underway, even if an attacker hasn’t fully compromised systems yet. These clues often come from SIEM alerts, threat hunts, or patterns in logs that point to malicious activity in progress, like DoS attempts or suspicious process creations. Some common examples include command injection attempts, known malicious patterns in logs, or blocked lateral movement.

Alternate Terminology: Attack Activity, Attack Patterns

Indicators of Fraud

Indicators of Fraud point to social engineering, potential financial fraud, or account abuse - often surfacing as behavioral threat indicators. They can take many forms, from multiple failed payment attempts to phishing campaigns or signs of account takeovers. These indicators help teams spot and respond to abuse before significant damage occurs.

Alternate Terminology: Fraud Signals, Fraud Markers

Indicators of Misconfiguration (IOM)

Indicators of Misconfiguration are signs that systems or controls have been set up incorrectly. These can show up across your entire stack, but are especially common in cloud environments, infrastructure-as-code, and weak internal processes. Think open S3 buckets, overly permissive firewall rules, excessive user permissions, or default administrator credentials left unchanged.

Alternate Terminology: Misconfiguration Findings, Configuration Weaknesses

Indicators of Exposure

Indicators of Exposure are signs that sensitive data or infrastructure is publicly accessible or discoverable by attackers. They often live in plain sight and can be difficult to track. Sometimes on the surface web, sometimes leaked on the dark web. Examples include leaked credentials, exposed developer databases, open services found via Shodan, or code repositories containing hardcoded secrets.

Alternate Terminology: Exposure Signals, Public Data Leakage

Indicators of Behavior (IOB)

Indicators of Behavior are anomalies in either user or system activity that may suggest malicious intent or policy violations. While powerful, behavior-based indicators are notoriously finicky and often require human investigation due to high potential for false positives. Examples include impossible travel logins, unusual access patterns, abnormal working hours, or signs of automated user behavior.

Alternate Terminology: User Behavior Analytics, Entity Behavior Signals

Indicators of Vulnerability

Indicators of vulnerability are details about known weaknesses in systems that attackers could exploit. These can typically be rectified through regular patching, updates, or configuration changes. Examples include CVEs, deprecated software versions, and vulnerability scan results.

Alternate Terminology: Vulnerability Findings

Indicators of Reconnaissance (IOR)

Indicators of Reconnaissance are signs that an attacker is gathering information about your environment, likely before attempting an attack. While they can be more difficult to mitigate if they’re targeting your external attack surface, they’re often detectable due to their automated nature. Examples include network scans, DNS enumeration, OSINT collection of employee details, or social engineering efforts.

Alternate Terminology: Recon Activity

Indicators of Insider Threat

Indicators of Insider Threat are signs of malicious or risky actions by legitimate users within your organization. Insider threats can be particularly challenging to detect, but careful behavioral analysis can reveal warning signs. Examples include mass downloads of sensitive data, unusual privilege escalation, policy violations, or acts of sabotage.

Alternate Terminology: Insider Risk Signals, Trusted User Abuse Indicators

Indicators of Command and Control

Indicators of Command and Control reveal that a compromised system is communicating with attacker-controlled infrastructure. Detecting C2 activity relies heavily on monitoring network traffic, DNS queries, and identifying suspicious communication patterns. Examples include unusual protocol usage, beaconing to known C2 domains, regular timed outbound connections, or malware callbacks.

Alternate Terminology: C2, Beacon

Indicators of Data Exfiltration

Indicators of Data Exfiltration are signs that sensitive data is being stolen or transferred out of your network. Security teams should invest in robust Data Loss Prevention strategies to detect and stop exfiltration attempts. Examples include DLP alerts, unusually large outbound file transfers, excessive file downloads, or encrypted outbound channels designed to evade monitoring.

Alternate Terminology: Data Loss Signals, Exfil

Whether it’s Detection Engineering, Incident Response, or Threat Huting - Security Operations is built on data. And as a Security Engineer, you need to make that data work for you. Selecty is a database-agnostic, sidecar query assistant built to do just that. Generate queries based on your table schehmas, optimize them to your use case, iterate on them quickly, and debug faster than ever - all in one sleek interface. Check it out!

Learn More

Why it’s Important to Think Beyond IOCs

While Indicators of Compromise are undeniably valuable in detecting and responding to known threats, they’re inherently reactive and limited in scope.

Attackers know this, and they continuously evolve their tactics to bypass detection strategies that rely solely on static IOCs.

Expanding your perspective to the full spectrum of threat indicators allows you and your team to move beyond chasing known patterns. It pushes you to consider the broader context of suspicious activity, misconfigurations, exposure, and behavioral anomalies in your environment.

Regularly thinking about these different types of threat indicators helps you:

• Build a detection suite with broader and more complete coverage.

• Threat hunt with greater purpose and direction.

• Expand your forensic scope during incident response to capture the true impact.

Embracing these threat indicators proactively doesn’t just strengthen your security posture, it helps you truly understand your attack surface and better anticipate the constantly shifting threat landscape.

Securely Yours,

Ryan G. Cox

P.S. The Cybersec Cafe follows a weekly cadence.

Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.

. . .

For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.

We’re no longer “moving toward” the cloud. We’re already here.

Modern infrastructure lives in the cloud, and with that shift, understanding cloud security fundamentals is no longer optional for security practitioners.

It’s essential.

At its core, cloud computing is an on-demand, self-service model. Users can provision compute, storage, and services with just a few clicks. It essentially eliminates the need for heavy upfront hardware investment, enables agility, and supports a pay-as-you-go model that aligns cost with usage.

Cloud services typically come in three main flavors:

1. Infrastructure as a Service (IaaS): Provisioning and managing raw compute and storage resources.

2. Platform as a Service (PaaS): Deploying and scaling applications without managing the underlying infrastructure.

3. Software as a Service (SaaS): Consuming ready-to-use software over the internet.

The cloud-native architecture changes the game. Unlike on-prem environments, security in the cloud is a shared responsibility: cloud providers secure the infrastructure, but it’s on you to secure your data and applications.

Let’s walk through the key principles you need to know to build a secure and scalable foundation in the cloud.

Cloud Security Basics

What is IAM?

IAM, short for Identity and Access Management, refers to the framework of policies and technologies used to ensure that the right individuals and services have access to the right resources.

To grasp IAM, you need to first understand the differences between Authentication and Authorization:

• Authentication is the process of verifying identity. It typically uses a username/password combo, MFA, or biometrics and looks to answer the question: “Who are you?”

• Authorization determines what an identity can do. It dictates what resources they can access, what actions they’re allowed to perform, and looks to answer the question: “What are you allowed to do?”

IAM systems manage both of these functions and include several types of identities to help define a secure and scalable access model.

• Users: Individual identities (human users) that can be assigned direct access.

• Groups: Collections of users that make permission management easier by applying policies as scale.

• Roles: Temporary identities that can be assumed by users or services, ideal for least-privilege, time-bound access.

• Service Accounts: Non-human identities used by applications or automated processes to access resources.

• Root Account: The god-mode entity. Avoid using this unless you’re in an emergency situation, and make sure you have proper alerting and monitoring. Leverage Service Accounts in its place.

At the core of IAM are policies. Typically written in JSON, policies define what actions are allowed or denied on which resources. Policies are attached to identities and evaluated by the cloud provider every time a request is made to determine if access should be granted.

Without strong IAM practices, everything else starts to fall apart.

What is RBAC?

Role-Based Access Control (RBAC) is a security model that governs access to resources based on a user’s role within an organization.

Instead of assigning permissions directly to individual users, RBAC assigns them to roles like Admin, Developer, or Read-Only. Users then get assigned these roles, making access management simpler, cleaner, and more scalable.

This method also has several “built-in” advantages:

• Reduced risk of unauthorized access.

• Streamlined permissions management.

• Enhanced auditability for compliance.

Skipping RBAC, especially early on in your cloud journey, creates unnecessary risk. You may struggle to limit access cleanly, experience the nightmares of managing one-off permissions, or experience overly-permissive or conflicting access creep in over time.

So don’t wait. Think about RBAC from day one and save yourself the future tech debt.

What is PoLP?

The Principle of Least Privilege (PoLP) is a foundational security concept and practice that says users, systems, applications, and processes should only have the minimum level of access necessary to perform their functions or tasks.

In layman’s terms: you only get the permissions you need.

PoLP is crucial in cloud environments because of how dynamic and distributed they are. The more access you hand out, the larger your attack surface becomes.

By instilling the PoLP across your environment, you reduce risk of:

• Insider Threat: Only those who absolutely need access to sensitive data or systems have it, minimizing the damage a rogue or compromised insider can do.

• Lateral Movement: If an attacker compromises a single account, PoLP prevents them from pivoting freely across the environment.

In practice, PoLP means applying fine-grained policies, scoped roles, and tight permissions to everything from standard users, to service accounts, to admin roles.

What is IaC?

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure using code instead of manual processes.

Rather than clicking through a UI or running ad-hoc commands, you define your infrastructure in configuration files - bringing consistency, repeatability, and scalability to your cloud deployments.

IaC dramatically reduces the risk of misconfigurations by making infrastructure changes auditable, version-controlled, and testable.

Beyond reliability, it unlocks engineering benefits like CI/CD integration, change control, code reviews, and standardized templates.

Popular IaC tools include Terraform, OpenTofu, and ansible.

Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!

Learn more

Logging and Monitoring in the Cloud

With the scale and complexity of modern cloud environments, building a comprehensive logging and monitoring strategy is crucial.

A well-structured approach will not only allow you to detect and respond to security incidents quickly, but also gives you visibility into baseline behaviors, user activity, and system configurations (see Tuning Detections isn’t Hard Unless You Make it Hard for more).

Every major cloud provider offers its own flavor of audit logging services, but they all serve the same core purpose: capturing valuable operational data such as authentication events, access activity, resources changes, system and application logs, network traffic insights, and more.

They also have threat detection services meant to continuously monitor your accounts and identify potential threats, which produce logs of their own.

The good news? Nowadays, these logs are typically easy to integrate into your SIEM, even across multiple cloud accounts - exactly the architecture you’ll want for centralized monitoring and alerting.

But just keep in mind: cloud providers are great at scale, but log searchability, alerting, and real-time analysis usually isn’t their strong suit. But that’s where your SIEM thrives as that next, customizable layer.

So, before you start shipping your logs over at scale, make sure you’ve got some actionable detections in place so that your SIEM is ready to provide value.

Incident Response (IR) and Disaster Recovery (DR)

Incidents happen. And being prepared is what ensures rapid containment and smooth recovery.

But when you’re operating in the cloud, traditional incident response plans aren’t always enough. Cloud infrastructure introduces new variables (ephemeral resources, multi-region services, third-party dependencies) that standard IR playbooks may not account for. So, it’s critical to tailor your response plans to the specific complexities of your cloud environment.

The same goes for Disaster Recovery. Your DR strategy should focus on business continuity - restoring critical infrastructure, data, and applications quickly and efficiently after a disaster.

To do that well:

• Build flexible and scalable recovery solutions. For mission critical systems, consider cross-region replication to protect against regional outages.

• Automate backup creation and storage. Set a schedule for regular snapshots and backups, but automate where possible to reduce manual overhead and increase consistency.

• Test your backups regularly. An untested backup is just a false sense of security. Validate that your backup and restore processes work as expected.

• Store encrypted backups in separate regions or accounts. This adds a layer of protection, helping prevent unauthorized access to both production and backup data.

When done right, your cloud IR and DR strategies should scale with your environment, adapt to the technologies in play in your environment, and reduce your mean time to recover when things go sideways.

Security Controls

Security Controls are the backbone of enforcing policy in your cloud environment. They fall into three main categories, each serving a distinct purpose in your defensive strategy:

1. Preventative: These are measures designed to stop security incidents before they happen. Think IAM, RBAC, PoLP - all fundamental to Access Controls. But they also include network segmentation, firewalls, and intrusion prevention systems. Their job is to reduce risk at the gate.

2. Detective: These kick in after an event has occurred. Their purpose is to identify, log, and report suspicious or malicious activity. Think logging, monitoring, and alerting - your second line of defense when something slips through the cracks.

3. Corrective: These focus on limiting damage and restoring systems to a secure state after an incident. Think incident response plans, disaster recovery, patch management, and forensics. When the worst happens, corrective controls help you bounce back.

See how it all starts to fit together?

Cloud security isn’t about any single control. It’s about layering them so they work together to protect, detect, and respond.

Additional Best Practices

Encryption

Most cloud providers enable encryption by default, but you should still understand the basics:

• Encryption at Rest: Secures data stored on disks, databases, and object storage.

• Encryption in Transit: Protects data as it moves between systems, services, and users.

Use a Key Management System (KMS) to securely manage, rotate, and audit your encryption keys, Don’t just set it and forget it - make sure your key lifecycle is tightly controlled.

MFA

Enable Multi-Factor Authentication everywhere. Across all user accounts, admin interfaces, and especially privileged roles.

When possible, avoid SMS and opt for passwordless systems (i.e. biometrics combined with SSO and OTPs) or FIDO hardware.

Explore enabling adaptive MFA too based on user context like device, location, and behavior.

Tags and Labels

Define a consistent tagging strategy for your cloud resources.

It helps to establish clear ownership, track costs easier, and increase operational efficiency.

Automate tags wherever possible through IaC templates or provisioning workflows to maintain consistency across environments.

Secure Network Boundaries

If you have the bandwidth, apply network segmentation to break your infrastructure into isolated zones. This limits lateral movement in the event of a breach.

Tighten things further with:

• Private subnets to reduce public exposure

• Firewall rules to control ingress and egress traffic

• Network ACLs and Security Groups that minimize open ports. (Avoid 0.0.0.0/0 at all costs, unless you’ve got a rock-solid business case!)

Every entry point in your network should be deliberate.

Just Scratching the Surface

The cloud is extremely complex, and while these are certainly some of the most useful fundamentals, we’re really just scratching the surface.

At its core, many of the key cloud security principles boil down to IAM, RBAC, and PoLP.

By applying the Principle of Least Privilege and typing permissions to well-defined roles, you avoid operational chaos and build a more secure environment with the legs to scale.

Mastering the cloud isn’t optional anymore, it’s essential for today’s security practitioners. So give it the attention that it deserves.

Securely Yours,

Ryan G. Cox

Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.

Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.

. . .

Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!