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!

The MITRE ATT&CK Framework is one of the most recognized and most referenced knowledge bases in the blue team community. And for good reason.

At its core, ATT&CK maps out the tactics and techniques real-world threat actors use across the full attack lifecycle.

For Security Operations teams, it can be a powerful tool: a way to align your defensive strategy towards specific adversarial behaviors, to identify gaps, and to mature your detection capabilities.

But too often I see MITRE ATT&CK get ignored, misunderstood, or just barely scratched at the surface.

Why? Maybe it’s because there are too many cybersecurity frameworks floating around and it’s difficult to tell which ones are worth your time.

Or maybe…

It’s because everyone tells you about MITRE ATT&CK, but no one’s shown you how to make the framework work for you in a way that’s integrated, contextual, and scalable.

So in this article, we’ll break down how to use the Framework to assess coverage, identify blind spots, and improve your Security Operations function in ways that actually move the needle.

A Brief History

The MITRE ATT&CK Framework was first developed in 2013 by MITRE, a non-profit created to support the US Government with technical expertise and threat intelligence..

ATT&CK stands for Adversarial Tactics, Techniques, and Common Knowledge - and the goal was simple: document how real-world attackers behave based on publicly available intelligence.

It became publicly available in 2015, and since then, it’s grown into a community-driven framework that is constantly evolving as researchers and threat hunters discover new techniques.

Today, it's one of the most practical resources security teams have to simulate attacker behavior, strengthen their defenses, and build more threat-informed detection strategies.

The Framework

The MITRE ATT&CK Framework is made up of two core components: Tactics and Techniques.

Tactics represent what an attacker is trying to achieve - their technical objective during a specific phase of an intrusion. Think of them as high-level categories or goals that shape an adversary’s behavior throughout the attack lifecycle.

As of now, there are 14 Tactics in the Enterprise ATT&CK Matrix:

1. Reconnaissance: Gathering information about the target, either actively or passively.

2. Resource Development: Acquiring infrastructure or resources (like domains or malware) for future use.

3. Initial Access: Gaining a foothold within the target environment.

4. Execution: Running malicious code on a victim system.

5. Persistence: Establishing mechanisms to maintain access over time.

6. Privilege Escalation: Gaining higher-level permissions within the environment.

7. Defense Evasion: Avoiding detection while moving through the network.

8. Credential Access: Attempting to steal account credentials.

9. Discovery: Learning about the internal environment.

10. Lateral Movement: Moving from one system to another.

11. Collection: Gathering data of interest from internal systems.

12. Command and Control (C2): Communicating with compromised systems to maintain control.

13. Exfiltration: Removing stolen data from the environment.

14. Impact: Disrupting availability, integrity, or the business itself.

Techniques explain how those Tactics are achieved. Each Technique is a specific method used by attackers - like phishing for Initial Access, or credential dumping for Credential Access. These techniques are more granular, and many of them even come with sub-techniques to break things down even further.

There are currently about 200 Techniques and 400 Sub-Techniques, so listing them all here isn’t really plausible. But, I encourage you to explore the full framework here.

Remember:

• Tactics give you the big picture.

• Techniques provide the details you can actually build around.

Once you understand that structure, you can start to align your security strategy more directly against real-world threats.

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

The Framework in Practice

Yes, MITRE ATT&CK can absolutely help your security posture, benchmark your maturity, identify blind spots, and even communicate more clearly with stakeholders.

But here’s the truth: None of that matters if you’re not actively measuring and applying it across your entire operation.

It’s easy to reference MITRE ATT&CK in passing, but much harder to integrate it in a way that can drive your day-to-day efforts and prioritization.

So, here’s how you put it to work.

Detection Engineering

The most straightforward way to operationalize MITRE ATT&CK is through your detection suite.

Start by thinking of the framework as your creative springboard. Break the mold of just thinking of writing detections against your tooling, and leverage it to build logic around real adversary techniques.

Start tagging your detections with their corresponding Tactic and Technique IDs. This unlocks a new level of visibility and measurement across your detection program, specifically in 2 areas.

1. Coverage: Tagging your detections gives you a birds-eye view of your detection footprint. You’ll be able to quickly spot redundancies based on over representation of techniques, and gaps based on underrepresented tactics. This becomes a feedback loop and can be used to prioritize new detections, rebalance existing coverage, and to better align your strategy across the board. Mature teams can do this proactively, but any team can benefit from laying a solid foundation early.

2. Surface: Once alerts start flowing in, you can begin correlating alert volume by Tactic and Technique to the quality of your detections. Think about True/False positive ratios, high/low signal counts, and any reports of alert fatigue. Over time, this gives you a clearer picture of your active attack surface and allows you to tune your detection coverage to match your unique risk profile.

If you want to mature your detection engineering function, tagging with MITRE isn’t just nice to have - it’s foundational and sets you up to make smarter decisions, decrease gaps, and give you more resilience over time.

Threat Hunting

MITRE ATT&CK can be a powerful launchpad for structured threat hunts.

As a hunter, you can leverage the framework to focus your efforts on known gaps in your detection coverage. Whether it’s a technique you’re missing entirely or just one that has limited visibility, ATT&CK helps you align your hunts with actual risk rather than just intuition and news.

Start by combining your MITRE mapping with internal knowledge about your environment. Then layer in OSINT or public threat intelligence to build out hypothesis-driven hunts that target specific behaviors, sub-techniques, or IOCs.

Even when engaging in unstructured hunts, your knowledge of your current MITRE coverage can still act as a compass. It gives your exploration focus while still giving you the creative freedom that comes with unstructured threat hunts.

But don’t just stop with the hunt itself.

Any findings (missed activity, detection gaps, new hypotheses) should feed right back into your detection lifecycle. This keeps your detection engineering function agile yet always grounded in the reality of your security posture.

Incident Response

Incidents are the most honest indicators of where your defenses fall short.

Each phase of an incident can be mapped back to specific MITRE ATT&CK techniques or subtechniques, giving you insights into the tactics that slipped through the cracks. And since incidents are multi-layered, you’ll usually uncover several techniques from a single event.

The key is to track them.

Failing to tag incidents to ATT&CK tactics and techniques, or worse - failing to review those analytics over time, is a major missed opportunity.

Why? Because that data shows not only where you were weak in the moment, but where you might be consistently vulnerable over time.

When tracked properly, incident data can feed:

• Your detection engineering priorities

• Your threat hunting hypotheses

• Your training and tabletop exercise planning

If you want your incident response program to mature, start treating every incident as a feedback loop. MITRE ATT&CK is that added layer to give you structure and a foundation to do it in a measurable, repeatable way.

The SecOps ATT&CK Ecosystem

By now, it’s clear: MITRE ATT&CK weaves through every layer of your Security Operations function.

When used intentionally, it becomes a unifying thread that connects each discipline, encourages collaboration, drives prioritization, and builds maturity.

• Alerts: SOC Analysts can use ATT&CK mappings to help prioritize triage, choose accurate classifications when closing alerts, and provide structured feedback to Detection Engineers.

• Detection Engineering: Detection Engineers can map their detection suite to ATT&CK to assess coverage, reduce redundancy, and prioritize new detections based on gaps.

• Threat Hunting: Threat Hunters can form hypotheses grounded in uncovered gaps, launching hunts that directly target under-monitored behaviors or subtechniques.

• Incident Response: Responders can map incident activity to ATT&CK to understand the full attack path, identify defensive breakdowns, and generate action items during post-mortem.

• Leaders: By building the framework into your processes, managers and executives can leverage metrics that give a clear picture of operational maturity.

But still want to take it a step further?

Use it to drive your purple teaming exercises. Leverage the framework to simulate attacks that specifically target underrepresented techniques in your detection suite. This lets you validate existing detections, strengthen controls, and spot your gaps.

💬 Are you using MITRE ATT&CK as part of your security strategy? Or are you leveraging other frameworks? Let me know below!

Leave a comment

Another Iterative Piece to the Process

If you’ve been reading the Cybersec Café for a while, you’ve probably noticed a recurring theme: iteration is everything in Security Operations. And that’s by design.

Each key pillar of SecOps feeds into the others. And the MITRE ATT&CK Framework isn’t just another checkbox, it’s a platform that helps you align those pillars to build with purpose and evolve with intention.

This framework becomes even more valuable as your team matures. The last thing you want is to find yourself:

• Wasting time building redundant detections

• Accumulating tech debt from untagged rules

• Hunting in well-covered areas while blind spots go unchecked

• Skipping improvement items in incident reviews because you lack structure

Put simply, if you’re not using MITRE ATT&CK to guide your growth, you’re not measuring your security posture in its entirety.

MITRE ATT&CK is a mindset that brings structure and strategy to your operations. Use it early. Use it often. And let it evolve with your team.

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!

No, they’re not the flashiest part of Security Engineering. But if you want a scalable, world-class Security Operations function, they’re absolutely essential.

I’m talking about Playbooks - the step-by-step documentation your team relies on to triage alerts, mitigate threats, and respond to incidents consistently and effectively.

With the volume of alerts that modern SOCs handle, it’s inevitable that processes will get lost or forgotten - whether through turnover or just the chaos of daily operations.

Most teams store documentation somewhere like Confluence, GDrive, GitHub, or Notion. Inside you’ll find the play-by-play steps for identifying, triaging, responding to, and remediating various security events.

But Playbooks are not just limited to SIEM alerts.

You can have them for phishing, vulnerability management, incident response, threat hunting - even your daily workflows. If you're repeating a process more than once, it’s probably worth turning into a Playbook.

At the end of the day, the goal is simple: streamline operations, drive consistency, and keep your team efficient with as little guesswork as possible.

Let’s walk through how to build a great Playbook with a realistic scenario.

Subscribers get access to the Playbooks Repository in Cybersec OS to follow along with this article!

Scenario

You’ve just started ingesting GSuite logs into your SIEM. While some out-of-the-box detections offer basic coverage, you’re not confident it’s enough.

So, you create a custom detection: GDrive Excessive Sharing to External Non-Business Emails.

The idea? Catch early signs of potential insider threats by flagging unusual volumes of sharing to non-business emails.

The detection logic is ready to go live - but before it does, it needs a solid Playbook to guide your team in the case it does fire off.

Drafting Your Playbook

Start with Purpose

There’s no one-size-fits-all approach to writing Playbooks, but one habit I’ve found especially helpful is starting with a purpose statement.

This sets the tone. It tells the reader exactly why this Playbook exists, without diving into too many technical weeds. It should be a one-line (or two) that answers: What is this Playbook helping us do?

This not only gives context to the person executing the Playbook, but also helps future-proof the doc by anchoring it to a clear goal.

Purpose

This Playbook supports the “GDrive Excessive Sharing to External Non-Business Emails: detection. It’s designed to help identify potentially malicious insider behavior by investigating the user suspected of sharing large volumes of files to non-customer, public email providers within a 24-hour period. Use it to filter out legitimate business activity and focus on suspicious sharing patterns.

Give a Description

Next, add a brief description of the alert this Playbook is tied to. Think of this as the “what fired” explanation - not the why, just the what.

It’s less about the process and more about quickly giving your team a mental model of what the detection means and what triggered the response.

This should be short and simple, ideally no more than a sentence or two.

Description

A user has shared an unusually high number of files to external email addresses. It may indicate unauthorized data sharing or insider threat behavior.

Investigation

Now it’s time to walk the reader through exactly how to investigate this alert.

Your goal here isn’t to write an essay - it’s to build a checklist of actionable, repeatable steps that guide someone through the early stages of triage.

Use short, direct instructions and include quick links to essential tools like dashboards, IP lookups, saved queries, or relevant docs whenever possible.

Investigation

1. Investigate the filenames and the external email addresses flagged in the alert using GDrive External Share Dashboard.

   1. Assess sensitivity of shared files. Check if file names suggest sensitive content, like financial, customer, design, sales, or architectural documents.

   2. Identify potentially suspicious recipients. Look for personal or unrecognizable email addresses. Signs of a potential insider threat include: the user’s own personal email, a team member’s personal email, an unknown email, or a competitor.

2. Use the Investigate User Dashboard and Investigate IP Dashboard to view recent behavior and access patterns tied to the user and associated IPs.

   1. Leverage IP Reputation Tools to validate legitimacy. (VirusTotal | Talos Intelligence)

3. Use Recent Activity or Common Activity from the GSuite Saved Query Knowledge Document, or use the GDrive External Share Query shown below for a more tailored look.

   1. Leverage Selecty to build or refine queries quickly. Iterate as needed to dig deeper into file access, sharing patterns, or privilege escalation.

4. Start forming hypotheses based on the user’s activity and context. Begin forming a narrative.

   1. Was this accidental? Intentional? A pattern? You don’t need to prove it yet, but mentally sketch an outline.

- Today’s Sponsor -

Selecty is a database-agnostic, sidecar query assistant - built to integrate seamlessly into your workflow without dulling your edge. Generate smart, contextual queries, optimize them to your use case, break them down into plain English, and debug faster than ever - all in one sleek interface. Check it out!

Learn More

Triage

Once your initial investigation is complete, it’s time to triage the alert - decide what action, if any, should be taken.

The goal here is to help analysts move from “What’s happening?” to “What should we do about it?” based on common outcomes. Provide clear guidance based on potential investigative findings.

Triage

1. If files don’t appear sensitive & no malicious activity is detected:

   1. Follow up with the user. Ask why they’re sharing files externally.

   2. Educate over enforce. Many users share files with themselves for convenience or to move data between personal and work devices.

   3. Remind them of the risks and reinforce that intermingling work and personal data is against policy - even if intentions are harmless.

   4. If the user says they’re using personal software to improve their workflow, remind them that only approved tools are allowed for security reasons. Encourage them to submit a request if they believe a tool should be reviewed.

2. If files appear sensitive or potentially malicious:

   1. Escalate to the Security and IT teams. This includes documents like customer lists, IP, legal agreements, etc.

   2. Context matters. Some users may share personal accounts for malicious reasons, but others may be confused or misinformed.

   3. Gauge the user’s intent and context before jumping to conclusions.

   4. Assess for Insider Threat indicators. Reach out to the manager in a shared DM (with Security team) to keep communication private but visible. Look for red flags:

      1. Are they leaving the company?

      2. Are they launching a competing business?

      3. Have they expressed dissatisfaction or disengagement?

   5. If malicious intent is suspected:

      1. Don’t tip them off. Continue monitoring their activity quietly to collect more evidence.

      2. Coordinate internally and prepare contingency plans.

      3. If risky behavior continues, escalate further. Get security leadership approval and work with IT to disable access and secure data.

Queries and Links

This section is meant to make both Investigation and Triage as seamless as possible.

While hyperlinks should be embedded throughout your Playbook, this is your central hub that brings everything together. It’s okay (and encouraged) to repeat hyperlinks that appear earlier in the document. That way, readers know they can simply scroll here when they’re in a hurry.

Include direct links to dashboards, saved queries, detections, and related documentation that your team relies on.

Queries and Links

Use the GSuite Saved Queries document to find your general saved queries to investigate the log source.

Dashboards:

• Investigate User Dashboard: Get a holistic view of the user’s recent activity across services.

• GDrive External Share Dashboard: Focused view of all files shared externally from Google Drive.

• IP Investigation Dashboard: Helps identify suspicious or rare IP activity associated with the user.

GDrive External Share Query

• Use this query to identify which files the user shared externally, including the target email addresses. Replace insert_email_address with the address of the user under investigation.

Escalation and Response

This section outlines the recommended actions based on possible outcomes from your Investigation and Triage steps.

Each case below is framed to guide the analyst in deciding whether to close out the alert, take educational action, or escalate further

Escalation & Response

1. False Positive

   1. Indicators

      1. No sensitive files shared.

      2. Target email appears benign.

   2. Actions

      1. Reach out to the user with a reminder about the risks of transferring files between personal and work devices.

      2. Use an educational tone - highlight security concerns rather than applying blame.

2. Confirmed Activity

   1. Indicators

      1. File shared with a customer who lacks a custom domain.

      2. File content is not sensitive, or applies to the customer.

   2. Actions

      1. Confirm the customer relationship with the user and/or team.

      2. Document the outcome and details in the ticketing system for future reference.

3. True Positive (Benign)

   1. Indicators

      1. Files shared with the user’s personal email.

      2. Files are not sensitive, but this violates policy.

   2. Actions

      1. Educate the user about company policy and risks.

      2. If a pattern emerges or the user is noncompliant, escalate to their manager for reinforcement.

4. True Positive (Malicious)

   1. Indicators

      1. Files contain sensitive company data.

      2. Shared with a personal or suspicious external email.

   2. Action

      1. Escalate to the Security team immediately.

      2. Consider insider threat potential; do not alert the user.

      3. Involve the manager discreetly if additional context is needed.

      4. Coordinate with IT for user access restrictions if malicious intent is confirmed.

Version Control and Tags

Maintaining version history and tagging is essential for Playbook lifecycle management. Whether you’re using GitHub, Confluence, or another platform, make sure every update is recorded and traceable.

Version and Tags

v1.0

Created: 6/17/25

Updated: 6/17/25

Tags: GSuite, T1537, T1020, T1087.004, T1071.001

💬 Tell me about a time when you were really glad your team had a playbook in place. What happened, and how did it help you in that moment?

Leave a comment

How Playbooks Help Your Security Team

There’s no way around it - Playbooks are essential to any high-functioning security team, and building them is a collective responsibility.

They don’t just document what to do - they preserve critical knowledge. Whether a team member leaves, a process is rarely used, or you’re deep in a fast-moving investigation, Playbooks ensure that nothing gets lost and no one is left guessing.

Playbooks can help you turn chaos into action.

They allow your team to:

• Respond to threats quickly and confidently without reinventing the wheel.

• Empower junior analysts, new hires, and even non-security collaborators to contribute meaningfully.

• Maintain consistency and quality as your team grows and scales.

• Build automation on solid, vetted foundations - turning tribal knowledge into executable workflows.

They’re more than just internal documentation, Playbooks are operational guardrails. They reduce risk, improve efficiency, and help your team operate without fear of making the wrong move.

So next time you find yourself doing something more than once - take the time to write the Playbook. Your future self (and your team) will thank you.

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!

Detection Engineering is an underappreciated role in cybersecurity.

Is it the flashiest? The most technical? The most revenue-generating role in tech? Definitely not.

But it is niche, highly valuable, and a revenue saving role when done well.

At its core, Detection Engineering is about writing and refining the rules meant to detect threats in your environment. It gives the security team complete and customizable visibility into the tooling deployed across your environment.

And depending on how many platforms and tools you plan on monitoring, this job can quickly go from manageable to overwhelming.

Just think about it: You purchase a new application. You onboard the new log source. Your SIEM has no out-of-the-box detections for it. You spend a couple weeks parsing docs while the logs start trickling in. You write some detections to start gaining coverage, just to have low confidence they’re valuable. And then…

Boom. Your team gets flooded with alerts. All false positives. All adding noise to an already overwhelmed SOC. Now your team is frustrated and you’re starting to feel the pressure.

This is where tuning becomes critical.

It’s unrealistic to expect your first iteration of a detection to be perfect. Sometimes there’s just not enough context or data upfront to have high confidence from the start.

The goal is simple: We want detections that identify real, meaningful threats - not rules that drown your feed with noise.

Here’s how to tune your detection suite at scale with clarity and confidence.

Detection Tuning

In order to build a process that scales, you first need to understand the most common ways to improve your detections.

These aren’t one-and-done tasks. Tuning is iterative. You’ll often need to apply multiple techniques in combination to tailor a detection to the unique characteristics of your own environment.

Logic Adjustments

Logic adjustments are the bread and butter of detection tuning. They come into play when your detection isn’t quite aligned with the real-world behavior it’s meant to catch.

Sometimes, the logic may not include all the relevant events, misinterpret key:value relationships, or rely on a flawed understanding of the raw data.

Whatever the case, don’t sweat it - this is completely normal.

Detections aren’t always going to be straightforward, and they’re rarely perfect on the first try. That can generally be attributed to one of three things:

• You’re still figuring out the threat behavior, so you widen the scope to better understand what the signal actually looks like.

• You’re playing it safe, so you expand the logic to reduce the chance of false negatives - even if it means more noise at first.

• You’re waiting on data since the logs haven’t rolled in quite yet, so you’re guessing at the structure of the log.

While each of these cases are different, they share one similarity: uncertainty.

But as a detection engineer, you can’t let perfection delay progress. Start broad, get something in place, and refine as you learn more. That’s how a top-tier detection suite is built.

Exceptions

Exceptions let you preserve your detection logic while suppressing known and expected behavior from surfacing as alerts.

Once an exception is in place, any alert that matches it won’t trigger - saving your team from digging through noise you’ve already deemed as benign.

They’re especially useful for:

• Known service account activity

• Trusted IP addresses

• Confirmed user travel

• Regular and verified actions by internal teams

Extra points if you combine multiple fields (e.g. IP + user + process) into a single exception to increase fidelity.

But a word of caution: don’t implement exceptions until you’ve confirmed the activity is always a false positive both with relevant stakeholders and historical data.

It only takes one measly edge case to turn a well-meaning exception into a dangerous blind spot.

Threshold & Rolling Windows

Thresholds and Rolling Windows wor hand-in-hand to fine-tune the “when” behind a detection.

• A threshold is the number of times an event needs to happen.

• A rolling window defines how quickly it needs to happen to be considered suspicious.

Let’s break that down with an example.

Say you’re building a brute-force detection. You wouldn't want to alert if someone fails a log in 10 times over a week. But 10 failed attempts in 10 minutes? That’s probably worth flagging.

So, you set a threshold of 10 over a rolling window of 10 minutes.

But what if a system already locks accounts after 5 failed attempts in a 10-minute span?

Well, in that case, your detection wouldn’t fire unless you lower your threshold or extend the rolling window (and at this point, you may even go back to the drawing board with the design of this detection as a whole).

In many cases, your threshold might just be 1 if the activity is rare or highly privileged enough to be suspicious on its own. But for other detections, you may need to experiment, monitor performance, and adjust over time as you learn what “normal” looks like.

However, you may not truly know what is needed until a detection has been in production for some time.

Correlations

Sometimes a detection seems logically sound, but then it hits production and you realize it’s not producing the value you expected.

That’s when it might be time to start thinking about correlations.

Correlation detections help you connect multiple lower-fidelity signals into a higher-fidelity alert. You can link different detections within a rolling window to pick up signals that would generally go unnoticed unless being performed in succession.

At first, use cases for correlation detections might not jump out at you. But over time, especially once detections are live, patterns will start to emerge.

And one of the strongest use cases? Insider threat detection.

Let’s say you have a rule watching for large columns of files shared externally. A savvy insider might stay just under the threshold to avoid triggering an alert. But what if that same user also modified admin configurations or deleted artifacts around the same time?

Each activity in isolation may seem benign, but together? It may just be suspicious.

These detections are much more complex than traditional rules, but they’re a powerful tuning strategy when a single log line just isn’t enough to tell the full story.

Alert Context

If a detection fires and no one knows what to do with it, was it even valuable?

As a Detection Engineer, one of your top priorities is to make alerts actionable. Analysts should be able to understand what happened and why it matters within seconds, and be able to investigate further with just a few clicks.

While how alerts are delivered will vary from SIEM to SIEM, the essence remains the same. Here’s how to elevate your alert contexts:

• Write Clear, Verbose Titles: The title should be tailored specifically to the alert that just fired and what artifacts are involved;

  • Bad Title: A user CRUD action occurred in the platform

  • Good Title: User first.last@website.com deleted an API Key in Sensitive Application via CLI

• Include Key Artifacts: Deliver the most important details right in the alert body, ideally as readable JSON or a structured output. Include fields like:

  • IP Addresses

  • Network/Location Data

  • Actor identity

  • Target resources or users

  • Behavioral indicators

• Provide Tailored Playbooks: Every alert should have relevant, up-to-date playbooks including response steps specific to the detection, escalation paths, and links to relevant documentation or dashboards.

Your ultimate goal is this: analysts should be able to triage and act on a detection with minimal guesswork and uncertainty. If alerts are consistently taking 5+ minutes to triage, they can likely be improved.

Severity Adjustments

Tuning isn’t just about logic or exceptions, it’s also about making sure your severity reflects reality.

Adjusting detection severity up or down is a normal part of the process. It’s also just as common to add dynamic severity logic based on key:value pairs as you start to gain more environmental context.

Maybe a detection didn’t end up being the strong Indicator of Compromise you thought it would be, or maybe you’ve added exceptions or correlations that raise your confidence. Either way, regular severity audits are a must.

And here’s the golden rule: Reserve critical severity for alerts with high confidence and high potential for malicious activity. If everything is critical, then nothing is.

Get in the habit of tuning severity as part of your detection maturation process. It’s not just about catching threats, it’s about helping your team easily prioritize the right ones.

- Today’s Sponsor -

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

An Iterative Detection Lifecycle

I’ve said it before and I’ll say it again: Detection Engineering is an iterative process and your team needs to treat it that way.

You’re not going to get detections perfect the first time, every time. Maybe not even the second or third. But that’s okay.

Just like software development has its lifecycle, so should your detection engineering process. You need to build this into your team’s operating procedures - regularly reviewing what’s working, what’s not, and where improvements are needed.

A scalable detection lifecycle should include three types of reviews:

1. Regular Reviews: Set a cadence, monthly or quarterly, to review your detection suite as a team. These reviews are your chance to flag underperforming, noisy, or outdated detections that may have gone unnoticed.

2. Ad-Hoc Reviews: Tuning can’t always wait. You need a fast lane for real-time feedback, whether it’s from your SOC analysts drowning in false positives or engineers spotting a logic mistake. Build a simple process for submitting requests, implementing changes, and peer reviewing.

3. New Detection Reviews: Every new detection should have a follow-up baked into the process. A week or two after the push to production, circle back and look at the alerts it’s generating, assess its performance, and adjust as needed. Don’t set it and forget it.

Take the time to formalize your detection lifecycle. Align on timelines, responsibilities, and escalation paths. Most importantly, get buy-in across the team.

If you want a detection suite that scales, you need a process that supports it.

Prioritization

Now, I know what you’re thinking: “But Ryan, how do I know which detections actually need tuning?”

Here’s how I approach it:

1. Look for High-Volume Detections: If a detection is firing at a higher frequency than the rest of your suite, it’s a prime candidate for tuning. High-volume alerts are often the low-hanging fruit, especially early after rolling out your SIEM. In most cases, they’re triggered by common, legitimate user behavior that just hasn’t been refined for your environment yet. Over time, these should become less obvious if you’re tuning effectively.

2. High False Positive Rate: If you’re constantly marking a detection as false positive, something’s off. Check your logic, maybe it’s too loose. Or maybe it’s time to add an exception for a known, safe activity. High false positive counts waste time and erode the quality of your detection suite.

3. Low True Positive Rate: This is the next level of detection maturity. Let’s say you’ve got two detections: one has 1 true positive for every 10 false positives, and the other has 1 true positive for every 2 false positives. We’d want to turn our attention to the first detection even if the latter is higher volume overall, and rethink what constitutes a true vs. false positive for this specific use case.

4. High Time to Remediation: If a specific alert is consistently taking longer to triage, that’s a red flag. It may be a sign the detection isn’t actionable, lacks context, or the playbook is weak. While an underdeveloped SOAR might be part of the issue, slow Mean-time-to-remediation often points to alerts that aren’t clear or concise enough. Revisit your alert contexts and supporting artifacts.

5. Ad-Hoc Tuning Requests: As mentioned earlier, you need a fast feedback loop from your team triaging alerts on the front lines. While their input might be anecdotal, it can often be the most practical signal for tuning. Build a channel to intake requests, require evidence to be submitted in the form, and watch your detection fidelity slowly form itself to your environment.

Prioritization will always depend on your team’s maturity, but if you’re unsure where to start - this is your playbook.

💬 How do you ensure your team adheres to an iterative detection lifecyle? I’d love to here your leadership and operational tips below!

Leave a comment

Don’t Overthink It, Just Do It

At the end of the day, tuning your detection suite comes down to understanding your environment and building processes that scale.

Without frameworks in place to support iteration, it’s easy for the day-to-day grind to overshadow the long-term fidelity of your detections. But if you want a detection program that actually works, one that analysts trust and that surfaces real threats, you need to make tuning part of the culture.

Take pride in your detections. The rules you write aren’t set-and-forget, they’re living pieces of your defensive strategy. And like anything you care about, they deserve routine attention.

You wouldn’t go too long without a car tune-up, so don’t let your detection engine go untouched either.

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.