CISSP Domain 7 Security Operations essential topic!

For years, security teams had a patch window.

A vulnerability was disclosed.
A patch was released.
Organizations had time to test, approve, and deploy it.

And when the organization used that window for patching, the probability of exploitation was very low.

Well, here is the bad news: That window is GONE!

A recent industry analysis put the average time-to-exploit at minus seven days.

Yes, that’s right, negative 7 days.

That means attackers were observed exploiting vulnerabilities, on average, before a patch was publicly available.

In other words: On average, the attacks start before defenders even have something to install.

Rapid7 also found that 55% of known exploited zero-days in its dataset were exploited within one week of public disclosure. Rapid7’s research

So, what does that all mean? Are we losing the battle? Should we just all forget what patch management means and give up?

Of course not! As always, we need to take what we already have and adapt it!

Once again, I will explain an essential CISSP topic that, thanks to AI, has become more relevant than ever!

So whether or not you want to take the exam, I suggest you continue reading.

By the end, you will understand:

• How vulnerability management and patch management work together

• The CISSP patch-management lifecycle: Evaluate → Test → Approve → Deploy → Verify

• What to do when a critical vulnerability cannot be patched immediately

• Why CISSP knowledge is still essential, even when the patch window has disappeared

First: a vulnerability is not the same as a missing patch

Before we get to the patch management process itself, let me start from the very beginning - establishing the relevant terms.

In this case, the difference between vulnerability and patch management. These two might be very close, but in reality, they are completely different things.

Vulnerability management is how an organization identifies, assesses, prioritizes, and tracks security weaknesses.

Patch management is one way (not ONLY way) to remediate those weaknesses.

Here is the relationship between them: Vulnerability management finds the enemy. Patch management decides how to fight it.

Patch management process in a nutshell

CISSP note: Vulnerability management identifies weaknesses. Patch management safely remediates them.

As usual, the patch management process is divided into multiple phases where each phase has its own purpose.

The good news is, this is very easy to remember!

Evaluate

Description: Assess the vulnerability, affected assets, and potential business impact.

Goal: Prioritize based on real risk—not just the CVSS score. A lower-scoring vulnerability on an internet-facing, business-critical server may be more dangerous than a critical finding on an isolated test machine.

What to avoid: Treating every vulnerability as equally urgent, or prioritizing only by severity score.

Test

Description: Apply the patch in a controlled environment or pilot group before broad deployment.

Goal: Confirm that the patch fixes the issue without breaking applications, integrations, or performance. Prepare a rollback plan.

What to avoid: Deploying an untested patch directly to every production system—unless an emergency risk decision explicitly requires it.

Approve

Description: Review the test results, deployment plan, and expected business impact through the change-management process.

Goal: Ensure the right people understand and accept the risk of the change before it reaches production.

What to avoid: Treating patching as an informal technical task with no ownership, documentation, or approval.

Deploy

Description: Roll out the approved patch to production systems, preferably in phases.

Goal: Reduce exposure while limiting disruption. For normal patches, begin with IT and pilot users; for actively exploited vulnerabilities, use an emergency change process.

What to avoid: Waiting for the next routine patch window when attackers are actively exploiting a critical vulnerability.

Verify

Description: Confirm that the patch was successfully installed on every targeted system.

Goal: Prove that the vulnerability has been remediated through patch reports, version checks, and follow-up scans.

What to avoid: Assuming a completed deployment report means every system is secure. Devices may be offline, installations may fail, and reboots may still be pending.

If you cannot verify the patch reached the vulnerable system, you have not won that battle.

One process does not fit every organization

It is important to remember that patch management is a framework, not dogma.

A large enterprise may have dedicated test environments, formal change boards, and multiple approval layers. A small business may not have the people, budget, or infrastructure for that.

That does not mean an SMB should skip patch testing.

It means testing needs to be practical.

Many smaller organizations deploy patches first to IT staff and a small group of power users. They monitor for problems for a few days, then expand the rollout if no issues appear.

The goal is not to copy an enterprise process.

The goal is to reduce security risk without causing unnecessary business disruption.

CISSP takeaway: Security must support business objectives. Apply controls in a way that is appropriate for the organization’s risk, resources, and operational needs.

Are we losing the battle or not?

Maybe I should say that we are, to get more views, but I honestly think we don’t lose the battle. Only the old patching model is.

The patch window may be gone, yet patch management is more important than ever.
We need to install patches quicker, monitor vulnerabilities better, and follow a risk-based approach.

Is that enough to keep the organization secure?

Of course not!

Patch management is one essential layer of defense in depth. It works alongside asset management, secure configuration, least privilege, network segmentation, monitoring, and incident response.

Without patch management, you leave known weaknesses open for attackers. Handle it well, and you live to fight another day.

Remember: The goal is not to patch everything instantly. It is to reduce risk faster than attackers can exploit it.

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

If that sentence feels wrong, this article is for you. Because the people who understand why it is true are the ones who build detections, run SOCs, quantify risk for boards, and get paid more for it.

In this post I will:

• Show you why cybersecurity is a data problem wearing a security uniform

• Walk through the one piece of math that will show you why good data analysis is essential for threat detection

• Give you two working Python scripts (log hunting and risk quantification) you can run today

• Map the career paths where these two fields merge, and a 90-day plan to get there

Get 14 day free trial

The problem: people treat these as two separate careers

Most beginners see two doors.

Door 1: cybersecurity. Firewalls, certifications, incident response.

Door 2: data science. Python, statistics, machine learning.

They pick one and ignore the other.

Here is the issue. Open any SIEM, any EDR console, any GRC risk register. What are you looking at?

Data. Millions of rows of it.

• A SIEM is a data pipeline with alerts on top

• A detection rule is a classifier

• A risk assessment is a probability estimate

• A threat hunt is exploratory data analysis with a hypothesis

You do not need to become a data scientist. But if you cannot think like one, you will drown in alerts you cannot prioritize and risks you cannot explain.

The insight: security is a classification problem

Every security decision boils down to one question: is this thing malicious or not?

That is a classification problem. Data scientists have studied classification for decades. Security people often learn it the hard way, through alert fatigue.

Which brings us back to the 99% accurate rule.

The base rate trap (the most important math in this article)

Imagine your environment produces 1,000,000 events per day. Only 100 of them are actually malicious.

You deploy a detection that:

• Catches 99% of malicious events (true positive rate = 99%)

• Wrongly flags only 1% of benign events (false positive rate = 1%)

Sounds excellent, right? Now run the numbers:

• Malicious events caught: 99 out of 100

• Benign events wrongly flagged: 1% of 999,900 = 9,999

• Total alerts: 10,098

• Alerts that are real: 99 / 10,098 = under 1%

Your “99% accurate” detection produces alerts that are wrong more than 99 times out of 100.

This is the base rate fallacy. When the thing you are hunting is rare (and attacks are rare compared to normal activity), even a tiny false positive rate creates an ocean of noise.

What this means in practice:

• “Accuracy” is the wrong metric for security. Ask about precision (how many alerts are real) and recall (how many attacks you catch)

• Lowering false positives often matters more than catching one more attack

• This is why SOC analysts burn out. It is not a people problem. It is a math problem

Interview tip: if someone asks how you would evaluate a new detection rule, say “precision and recall against the base rate.” Very few junior candidates do. It signals you understand the job, not just the tools.

Read more

They can define prompt injection. They can name the OWASP category. And they still couldn’t tell you how to secure an AI agent that reads email and can access company documents.

Today’s guest post fixes that.

is one of the first creators I started following. We both launched almost two years ago, and I’ve read his work ever since.

Here’s why I trust him on this topic:

• AI Security Engineer at Amazon
• Ex-NSA and USMC
• M.S. in Cybersecurity and CISSP (which is how we connected in the first place)

Very few people understand both AI and security at this level. Even fewer explain it this clearly.

If you’re studying for SecAI+, preparing for an AI security interview, or just trying to understand what “securing an AI agent” actually means, read this one twice.

Over to Toxsec.

Prompt injection is easy to define. Securing the system after it happens is where you find out whether you actually understand AI security.

AI security is becoming something you can study for.

There are certification objectives. Flashcards. OWASP lists. Threat names. CompTIA now has an entire SecAI+ certification dedicated to the subject.

Which means we are rapidly approaching the point where somebody can correctly define prompt injection, pass a test on it, and still have absolutely no idea how to secure an AI agent.

And I think prompt injection is the perfect example of why.

Congratulations, You Memorized Prompt Injection

Let’s start with an exam question.

A company deploys an AI assistant that can read support tickets. An attacker submits a ticket containing instructions telling the model to ignore its original task and follow the attacker’s instructions instead.

What happened? Easy.

Prompt injection.

More specifically, if the attacker directly supplied the malicious instructions to the model, we would call it direct prompt injection. If those instructions were hiding inside something the AI later consumed, like an email, webpage, PDF, support ticket, or document, we would generally call it indirect prompt injection.

OWASP describes prompt injection as input altering an LLM’s behavior in unintended ways. It also makes the important distinction between direct injections from a user and indirect injections arriving through external content. (OWASP)

Cool! You get the exam point.

Now let’s make the question slightly worse.

The same AI assistant can read internal company documentation. The attacker inserts malicious instructions into a support ticket. The model reads them, searches the internal knowledge base, and starts pulling information the attacker was never supposed to see.

What control failed?

Suddenly, “prompt injection” is no longer much of an answer.

You need to start asking about trust boundaries:

• What information can the model retrieve?

• Whose permissions does it inherit?

• Can untrusted support tickets influence queries against trusted internal data?

• What does the application do with the model’s output?

Now we are doing security.

Give the Model a Tool and Things Get Weird

Let’s make the system worse again.

Our assistant can now send email.

The workflow looks roughly like this:

An attacker plants instructions inside a ticket telling the agent to find sensitive internal information and send it somewhere else.

This is where prompt injection stops being a funny screenshot of a chatbot saying something dumb.

The model has agency.

NIST calls this kind of indirect prompt injection against agents agent hijacking. The attacker places malicious instructions inside content the agent may naturally encounter, such as emails, websites, or code repositories, with the goal of redirecting the agent into harmful actions. (NIST)

And this is very much an active security problem.

In a large public red-teaming competition analyzed by NIST, Gray Swan, the UK AI Security Institute, and frontier AI labs, more than 400 participants launched over 250,000 attacks against 13 frontier models across tool-use, coding, and computer-use scenarios.

At least one successful hijacking attack was found against every model tested. (NIST)

That is the point where your flashcard starts looking a little lonely.

Because knowing the vulnerability name tells you what happened to the model. It does not tell you why the incident became dangerous.

Read the research: How Vulnerable Are AI Agents to Indirect Prompt Injections? Insights from a Large-Scale Public Competition

Gray Swan AI, US CAISI, UK AISI, OpenAI, Meta, Anthropic, and collaborators.

Figure 2. Indirect Prompt Injection Arena, from Dziemian et al. (2026).

The Interesting Question Is What Happens After the Injection

Imagine two systems.

System A is a chatbot sitting on a public website. You successfully prompt inject it and convince it to respond like a pirate.

Annoying.

System B is an internal agent with access to company documents, email, cloud APIs, and a handful of automated workflows. You successfully prompt inject that one.

Same broad vulnerability class. Very different Tuesday.

The difference lives outside the model. The second system has privileges. It has data access. It has tools. It has connections to other systems.

It may even have credentials allowing it to take actions without asking a human first.

So once the model gets confused, the question becomes painfully familiar:

What is the compromised thing allowed to do?

And cybersecurity has been asking that question forever:

• Least privilege.

• Segmentation.

• Authentication.

• Authorization.

• Trust boundaries.

• Input validation.

• Logging.

• Human approval for dangerous operations.

• Containment.

• Blast radius.

The vocabulary around the attack changed. A surprising amount of the defensive thinking did not.

NIST reached a similar conclusion in its 2026 analysis of AI agent security. Respondents broadly agreed that agents introduce novel threats, while fundamental cybersecurity practices remain relevant and need to be adapted for these systems. (NIST)

That distinction matters.

AI security absolutely has new problems. But you do not get to skip the old ones.

SecAI+ Quietly Makes the Same Point

This is one reason I actually like what is happening with AI security certifications.

In February 2026, CompTIA launched SecAI+, its first Expansion Series certification focused on securing AI systems and using AI within cybersecurity operations. (Announcement)

And there is a detail in how CompTIA describes it that I think matters more than the shiny new certification name.

SecAI+ is designed to build on an existing skills foundation. CompTIA explicitly positions it alongside real-world experience and certifications such as Security+, CySA+, and PenTest+. (Announcement)

That makes sense.

You should learn prompt injection. You should understand model poisoning, RAG security, agent hijacking, AI governance, adversarial machine learning, and the growing pile of terminology surrounding these systems.

There is genuinely new stuff here.

But imagine being asked to secure the support agent from our example.

Knowing the definition of indirect prompt injection gets you through the first ten seconds.

Then I want to know:

• Can the agent access every support ticket or only tickets assigned to its workflow?

• Does it query the knowledge base using the user’s identity, its own identity, or some horrifying global service account?

• Can it send email anywhere?

• Can it attach retrieved documents?

• Does sending sensitive data require approval?

• Are external URLs unrestricted?

• Can an attacker use one tool to feed malicious context into another?

• Can you reconstruct which document influenced the agent’s decision after something goes wrong?

Those questions sound suspiciously like regular cybersecurity questions.

Because they are.

Prompt Injection Is a Great Interview Question

If I were interviewing someone for an AI security role, I would absolutely ask about prompt injection.

But the definition would be the warm-up.

Here is the question I actually care about:

An internal AI agent reads employee email, searches company documents, and can send messages. An attacker sends an employee an email containing an indirect prompt injection. How would you reduce the risk?

Someone who memorized the topic might tell me about filtering malicious prompts. Maybe they mention strengthening the system prompt.

Those things can help, let’s keep going.

OWASP’s guidance goes much further. It recommends least-privilege access, human approval for high-risk operations, separating untrusted external content, deterministic validation, input and output filtering, and adversarial testing. It also explicitly warns that foolproof prevention of prompt injection may not exist. (OWASP)

So the stronger answer starts assuming the model may eventually screw up.

What happens when it does?

The email should be treated as untrusted input. The model should only receive the permissions required for the current task. Sensitive retrieval and dangerous tool calls should have deterministic controls around them.

A simplified policy check could look like this:

# Generic policy pseudocode

if tool_call.name not in allowed_tools:

deny(tool_call)

if tool_call.risk == “high”:

require_human_approval(tool_call)

execute_with_scoped_identity(tool_call)

audit_log(tool_call)

High-risk actions may need human approval. Credentials should be scoped. Network access should be constrained. Actions should be logged well enough that somebody can reconstruct what happened afterward.

And if the agent gets hijacked anyway, the architecture should make that failure boring.

That last part is the goal.

Getting a model to follow a malicious instruction is interesting.

Getting a model to follow a malicious instruction and discovering it has permission to email your entire customer database to Mars is an architecture problem.

Study the Attack as a System

So if you’re studying AI security right now, whether that’s SecAI+, OWASP material, an internal training program, or just trying to keep up with whatever happened this week, I would study these attacks differently.

Learn the terminology.

Then immediately break the vocabulary apart.

Take prompt injection:

• Ask where the malicious input entered.

• Ask which trust boundary it crossed.

• Ask what data became reachable.

• Ask which identity the application used.

• Ask which tools became available.

• Ask what authorization happened before the tool executed.

• Ask what an attacker actually gained.

• Ask what the logs would show.

• Ask where you could contain the failure without trusting the model to save itself.

Do that and one vocabulary word suddenly teaches you ten security concepts.

More importantly, you start building a mental model that survives after the certification exam changes.

Because it will change.

The models will change. The frameworks will change. The attack names will multiply at an exhausting rate.

Three years from now we will probably have seventeen extremely serious acronyms for an AI agent doing something unbelievably stupid.

But permissions and identity will still matter. Trust boundaries will still matter. Logs will still matter.

And least privilege will still be sitting there, quietly fixing problems while everybody else argues about what to call them.

You absolutely can study your way into AI security.

Just don’t memorize your way into it.

Conclusion

Back to me.

This is the part that stuck with me the most:

“The vocabulary around the attack changed. A surprising amount of the defensive thinking did not.”

I see the same mistake every week. People jump straight into AI security, cloud security or threat hunting, and skip the fundamentals that make those fields make sense.

Then they meet a real system and get stuck.

Prompt injection is new. But the questions that stop it from becoming an incident are not:

• Who has access?

• What can it reach?

• What happens if it gets compromised?

• Can you prove what happened afterward?

If you can answer those four questions, you’re already ahead of most people studying AI security.

If you can’t yet, don’t worry. That’s exactly what Decoded Security is here for.

A huge thank you to Toxsec for this one. If you got value from it, go follow his work. He’s one of the few people writing about AI security from real experience, not from headlines.

Subscribe now!

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

If you’ve been in cybersecurity for a while you’ve surely already met the term “Defense in Depth”.

The trouble is that a definition doesn’t tell you what the layers look like in a real cloud environment. It doesn’t tell you which question each layer answers either, or what happens when one of them fails.

So I asked someone who deals with this every day.

has 12 years in cybersecurity. He has pen-tested 100+ applications, reviewed 50+ cloud architectures, and assessed 200+ SaaS vendors and I have been following his work for a while now.

Impressive record, isn’t it?!

In this guest post, he’ll walk you through:

• The 7 layers organisations use to protect cloud infrastructure and data

• The one question each layer has to answer

• Real attack paths from his offensive security days (including a database he dumped through a hardcoded credential)

• His top recommendations for identity, secrets and workload security

Read it with one question in mind: if my organisation’s strongest control failed tomorrow, what would stop the attacker next?

Let’s take a look at what Kushal has to say about that.

Layer 1 - Defend Application from Malicious Traffic

An internet facing application cannot distinguish between legitimate user from an attacker.

The attacker use this gap to

• Launch DDoS attacks, that overwhelm infrastructure or application resources.

• Perform credential stuffing, using leaked credentials to attempt account takeover.

• Scan for vulnerabilities by continuously probing applications, APIs, and exposed services.

The first layer is to filter malicious traffic before it reaches the application.

Hence, most organisation use edge controls such as

• WAF to stop application level attack.

• DDoS protection to mitigate heavy volume request.

• Rate limiting to throttle excessive request, and

• Bot controls to detect and filter unwanted automated traffic.

But the attack always doesn’t look malicious. A traffic with stolen credential can perfectly be a legitimate request.

And that’s why we need next layer to ask the question -

“Who is making the request and are they authorised ?”

Layer 2 - Protect Identity & Access

In the first half of 2025, identity-based attacks rose by 32%, according to Microsoft’s Digital Defense Report.

More than 97% of the identity attacks Microsoft observed were password attacks.

Today when Identify fails, everything fails. You cannot access anything. And that is why modern attackers no longer start with network. They start with Identity.

And cloud environments rely heavily on non-human identities, including:

• Service accounts

• Managed identities

• CI/CD pipeline identities, etc.,

These identities if compromised or granted excessive permissions, allows attackers to break pipelines, move between workloads, modify infrastructure and access sensitive data.

In my countless review of IAM policy -

My top 3 recommendation has always been

1. To eliminate unnecessary long lived credentials.

2. Go for managed identities or workload identities, and

3. Stop granting excessive permission to resource they don’t need.

A simple identity policy that grants a limited access to specific folder instead of entire S3, can have huge impact to an organisation security posture.

Coz Layer 2 ensures that authentication and authorisation decisions are made before a request reaches protected resources.

But what if a traffic with malicious intention has valid credentials and required privilege ?

This is where next layer of defense becomes important.

Layer 3 - Secure the API

In 2017, during my API security testing days, I followed a simple checklist to attack an API endpoint:

• Can I send 500+ requests per second?

• Can I send malformed request ?

• Can I send an unsigned or invalid JWT ?

• Can I abuse the API to gain access to other resources ?

• Can I send request from any IP or is IP whitelisting enforced ?

The reason for these questions was simple: Layer 2 alone doesn’t make request safe.

Even a valid identity can send a malicious request.

Layer 2 answers: “Alice is authenticated and has permission to use the xyz API.”

Layer 3 asks: “Is Alice’s request valid, expected, and within the rules of this API?”

This layer adds controls such as:

• API Gateway, centralizes and enforces API traffic policies.

• Rate limiting, throttles excessive requests and API abuse.

• Schema validation, rejects malformed or unexpected input.

• Signature validation, verifies request integrity and authenticity.

• IP restrictions, limits requests to trusted sources where required.

• API authorization, checks whether Alice can access the requested resource or action.

The goal is to add another enforcement point before the application, complementing network and identity, other layers that follows it.

Layer 4 - Isolate the Workload

Once I was reviewing an architecture and was surprised to see -

1. Production and Testing share the same network.

2. Production data used in testing.

This is typical case of flat network with no boundaries defined.

A flat network gives compromised workload unnecessary network reachability to other workloads, increasing opportunities for lateral movement.

So, how to prevent this ? Network segmentation

It prevents by separating resources into zones with different trust level and access requirement.

In cloud environment, this is achieved though VPC/Vnet, Security Groups or NSGs, NACL(Network Access Control), and private connectivity mechanism.

Consider a typical 3 tier architecture, where

1. Internet-facing load balancer in public subnets

2. Application workloads in private subnets, and

3. Databases in a more restricted data tier.

This creates multiple network boundaries.

If an attacker compromises an internet-facing component, they still need to overcome additional controls before reaching application workloads or sensitive data.

The objective of this is to make unnecessary movement harder, reduce the number of reachable resources, and limit the blast radius of a compromise.

Layer 5 - Secure the Compute Environment

Assume the traffic successfully

1. Passes the edge, Layer 1

2. Is authenticated via Layer 2, 3 and

3. Follow network access policy via Layer 4

The compute environment can still be compromised.

A vulnerable Lambda, container, or EC2 instance can become the entry point.

Recently, I working on an assessment where team was deploying container pulled directly from Docker Hub.

Our organisation have strict policy:

Production workload must use approved Golden Container Images(GCI).

The policy is enforced via automation and stops deployment if using unknown or unapproved public images.

The reason is simple.

An untrusted or vulnerable image introduces another potential supply-chain attack vector.

Golden images are hardened, scanned and equipped with security endpoint tools that helps organisation maintain strong a security posture.

But hardening alone isn’t enough.

Vulnerable code or a compromised dependency can still compromise the workload.

So don’t assume the workload can never be compromised.

Assume it will be. Then ask: what is the blast radius?

A compromised workload is dangerous because it’s next attack path maybe to look for credentials and secrets so that it can access database connected to workload.

And that brings us to the next question:

What secrets can the workload access?

Layer 6 - Protect Credentials & Sensitive Configuration

Now let’s assume the attacker has

1. Breached all the above 5 layers.

2. Gained access to K8 cluster, and

3. See a connected to database.

But there is a problem.

The workload needs credentials, tokens or secret to access it.

And if those secrets are hardcoded in

• Source code

• Container images

• Configuration files or

• Exposed through insecure environment, the attacker job becomes much easier.

In 2019, I was able dump a database because I found hardcoded credential in XML file on a VDI server. The attack was simple -

1. Access the VDI Desktop.

2. Escape the VDI to access underlying OS files and folder.

3. Searched and found the credentials.

4. Used netstat to figure out the TCP connection to Db IP and Port.

5. Fired up database manager with IP, Port and credentials and I was in.

Today, I am on the defensive side of security and now recommends treating secrets as another layer that need to be defended aggressively. But how ?

My top 3 recommendation are -

1. Centralised Secret Management, store credentials outside application code and configuration.

2. Access Control, allow only authorised workloads to retrieve specific secrets.

3. Secret/credential rotation, regularly replace credentials to reduce the impact of compromise.

But given that we still find hardcoded in insecure environment, one final questions left at the end of attack path -

Can the attacker actually read or modify the data ?

Layer 7 - Protect the Data

Even after breaching all the above layer, a strong data protection can add another barrier.

And every-time I do a architecture review or vendor SaaS review, I ask following question:

1. Is data encrypted at rest and algorithm used ?

2. Is data encrypted in transit ?

3. Who can access and modify the data ?

Because a data stored internally or externally must be

• Stored encrypted in databases, object storage, disks, and backups.

• Encrypted while it moves between clients, services, and systems.

• Limited to identities which can read or modify specific data.

But there is one problem.

A load balancer can terminate TLS connection, which means the traffic is decrypted at load balancer before being forwarded to the backend.

Meaning the data exists in plaintext at that processing point.

Hence most organizations use end-to-end encryption or application-level encryption so that the intermediary is unable to read the data.

So, the final question in Defense in Depth is therefore not just:

“Can the attacker reach the data?”

It’s:

“If they do, can they read, modify, or use it?”

And that’s a wrap.

To recap:

Layer 1: Should this traffic reach us?
Layer 2: Who is making the request?
Layer 3: Is the request valid and safe?
Layer 4: What can this workload reach?
Layer 5: What happens if it’s compromised?
Layer 6: What secrets can it access?
Layer 7: Can it read or modify the data?

And this is how an organization protects its data and defends its infrastructure, not by treating controls in silos, but by using them strategically to build Defense in Depth.

If cloud security is your direction, his newsletter explains how security reviews work in practice, from someone who does them for a living.

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

Not one wrong answer.

If you’re trying to break into this field, that number probably hit you in the stomach.

You’ve spent months studying. Maybe you paid for courses. Maybe you’re about to spend €700+ on an exam. And a free chatbot just answered every question perfectly.

So the thoughts start:

Why would anyone hire me when AI already knows all this?
Am I preparing for a job that won’t exist in two years?
Should I even keep going?

I get it. And I’m not going to tell you the fear is stupid, because part of it is real.

But most people are panicking about the wrong thing.

Let’s separate what you should actually worry about from what you shouldn’t.

What you can expect from this article

• Why passing an exam and doing the job are not the same test

• What AI actually changed about entry-level hiring, and what it didn’t

• The one skill that got more valuable, not less, because of this

Why I think AI passed so easily

Look at how an exam question is built.

A clear scenario.

Four options. Multiple technically correct answers, but only one BEST answer. Everything you need is inside the question somewhere.

That’s exactly what AI is built for. That’s where it thrives.

Now look at the same situation at work.

Exam version:
“A user reports a suspicious email requesting an urgent wire transfer. What should the security professional do FIRST?”

Real version:
A Slack message from the CFO’s assistant. It has a screenshot, not the original email. The CFO is on a flight. Finance wants to pay the invoice today because the vendor is “critical.” And nobody knows if this vendor changed banks last month.

AI answers the first one in two seconds.

The second one has no four options. Nobody tells you what the question is. You have to:

• Figure out what you’re actually looking at

• Work out what’s missing and who has it

• Decide what matters more: stopping the payment or keeping the business running

• Explain your decision to people who don’t care about security

The exam tests whether you know the answer. The job tests whether you can figure out what the question is.

So let’s stop confusing passing an exam with being a good cybersecurity professional.

So, should you panic or not?

So am I saying that you shouldn’t be worried? Not really.

The whole industry is changing, there is no doubt about that.

Pretending otherwise would be lying to you.

Some tasks that used to fill a junior’s week now take minutes:

• First drafts of policies and procedures

• Explaining what a log line or alert means

• Summarizing a CVE

• Writing a quick script to parse a file

• Answering “what does this acronym mean?”

If your plan was to get hired to do only these things, you have a problem.

But in my personal opinion, if you’re reading this, that was never your goal.

On the other hand, thanks to AI, the number of attacks is increasing rapidly. So many vulnerabilities can now be exploited basically for free.

And that also means you need more and more people who continue to monitor your network.

Yes, AI helps analysts spot anomalies. But anyone who has ever run a SIEM or XDR knows the tool doesn’t make the call. You still need an analyst who can decide whether an alert actually matters.

And that’s the pattern. AI changed the tasks. It didn’t change who’s responsible:

• Someone has to own the risk: “The chatbot said it was fine” doesn’t pass an audit.

• Someone has to know the environment: AI doesn’t know your undocumented legacy server.

• Someone has to check the output: A fluent wrong answer is more dangerous than an obvious one.

The skill that just got more valuable

For years, knowledge set you apart. Ports, frameworks, acronyms.

Now answers are free. What’s scarce is the ability to judge them.

And you can’t judge what you don’t understand.

Say AI tells you to block an IP that’s generating strange traffic. It’s confident. It even writes the firewall rule for you.

But what if that IP is your own email gateway? Or a partner integration finance depends on?

Plausible answer, but completely wrong for your environment.

The junior who catches that gets hired. The one who copies and pastes it is a liability.

So remember: AI doesn’t make fundamentals less important. It makes them even more important.

The real question

This brings me back to one of my past ideas: entry-level cybersecurity jobs don’t really exist.

Even junior cybersecurity roles expect experience in IT or another relevant field.

So maybe the real question isn’t whether AI will take entry-level cybersecurity jobs.

It’s whether AI can take something that may never have existed in the first place.

The path in was always the same: build real fundamentals, then move into security. AI didn’t change that. It just made skipping them far more difficult.

Conclusion

I don’t think AI is coming for entry-level cybersecurity jobs. I think it’s coming for the version of the job that was already the weakest way to break in: pure recall, no judgment, nothing you actually built yourself.

That’s not a reason to panic. It’s a reason to stop preparing for a job that was disappearing anyway, and start preparing for the one that’s actually available.

If you’re trying to figure out exactly which path to prepare for and what to actually study first, that’s precisely what the 90-Day Cybersecurity Job Blueprint walks you through, path by path, without wasting a year on the wrong certifications.

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

I’ll be honest here: I truly believed there is a certain type of question that AI models will struggle with, and therefore I will be able to make the AI fail.

Well, all tested models scored 100%. Every single time. No matter how much I tried, they aced it.

That result surprised me, and it changed what I think you should be spending your study time on. So let me walk you through exactly what I did and what it means for you.

What you can expect from this article:

• Exactly how I ran the experiment: the models, the setup, and how the questions were designed

• What the result of this experiment means

• What is the one thing that AI models still cannot do

• What I think it means for cybersecurity professionals and their work

Note: CISSP (Certified Information Security Systems Professional) exam is one of the most complex exams and most recognized certifications in the field.

About the experiment

First, let me describe the details of my little experiment, because the input variables are essential for interpreting the results.

CISSP questions

First, the questions. I did not use real CISSP exam questions. Those are under the ISC2 NDA, and I would not touch them. I did not pull from a paid question bank either.

I wrote all 150 myself, in CISSP style, across all eight domains. So the result can be slightly influenced by my personal bias. However, I really think that I am quite experienced with the style of the questions.

AI models

I used three independent and widely used models.

• ChatGPT: GPT-5.6 Luna

• Gemini: 3.6 Flash

• Claude: Sonnet 5

Process

I ran the experiment in two rounds.

Round one was 100 standard questions across all 8 CISSP exam domains. Straight knowledge and application, the kind you see in most practice sets. This is where I expect the AI to be very strong.

Round two was 50 complex questions where you’re offered multiple technically correct answers and need to choose the BEST answer based on the context. Again, I covered all 8 domains of the CISSP exam.

This is where most people fail the exam, because it requires a specific skill set and experience. This is where I expect to dominate the AI model.

Then I gave all the models the same instruction: “Pick the single best answer and explain your reasoning in one sentence. Export the result as a .md file.

The result

The result was quite clear. All models scored 150/150.

ChatGPT: 150 out of 150.
Gemini: 150 out of 150.
Claude: 150 out of 150.

And the reasoning? Correct, every single time.

I couldn’t figure out the way to confuse the AI model into picking the wrong answer. No matter how much I tried. (without cheating, of course)

Is the CISSP useless now?

You might jump to the “easy” conclusion that CISSP is useless now and AI will replace security professionals.

But in my opinion, that’s the wrong lesson to learn here.

Let’s focus on the exam first.

I know many people will disagree, but I don’t think that a value of an exam is lowered just because an AI model can pass it.

The process of learning for the exam teaches you to recognize patterns and think like a cybersecurity professional. It isn’t just about giving the right answer. It’s much more about the endless hours of studying and understanding concepts that will allow you to make the right decisions.

And trust me, they won’t allow you to take your own pen to the exam room, let alone an AI model.

Note: Let’s stop value things purely on the fact if AI can do it. Often, giving the right answer isn’t the whole story.

And what does it mean for security professionals and their work?

I think the CISSP exam, like almost every certification exam, is a recognition test. It gives you a predefined set of answers and asks you to choose the best one.

And recognizing the best answer is clearly something that the AI models are very good at.

But that’s not how it works. If you’re about to start your first cybersecurity job, you will very quickly recognize that you have to make decisions with very limited knowledge of the situation.

There is no predefined set of correct answers, and you don’t even know if what you did was the right thing to do.

AI models might be better at taking exams, but that doesn’t make them suitable for creating a cybersecurity strategy for your company.

Conclusion

So here is what I think you should take from this little experiment. The demand for people in cybersecurity continues to increase as more and more companies are realizing they need to take this seriously.

I don’t think that’s going to change any time soon. However, we all need to leverage AI in our work and fully use the benefits it brings to the table.

Clearly, there are tasks at which AI models are much better than humans. Automate them, and focus on things where you’re a lot better than any AI model can ever be.

Stop competing with AI models and rather use them to your advantage.

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

TL;DR: Most people run AI coding agents like Claude Code in YOLO mode: full access to their machine, no questions asked. It is fast, and it is a real security risk. A poisoned package or a single misread instruction becomes a live command on your system. The good news: You do not have to choose between speed and safety. Run the agent in an isolated, disposable box, with throwaway credentials and limited network, keep a mode that asks for everyday work, and save YOLO mode for the sandbox. Below I break down every Claude Code mode and the exact rules to run any agent securely.

Hello everyone, it’s me, Erich, and today I want to talk about something that, from my perspective, is being widely ignored.

It all started a couple of days back, when I posted this note. It turned out that many of you would like me to track my hands-on experience with AI agents.

So I didn’t hesitate, and for once, I stepped back from those shiny, nice CISSP concepts and started creating an actual multi-agent environment.

And while I was setting up my first agents, it got me thinking.

I know so many people who leave their agents for hours.

And that means one crucial detail. All of those people allow their AI agents to freely execute terminal commands on their machines.

Once again, convenience won over security, and we let AI agents operate in YOLO mode.

But how do you know the command is safe?

How do you know the library or a package it downloads isn’t malicious or contains a crucial vulnerability? How do you know the agent won’t delete your documents?

There are so many questions that could go wrong if you let an external entity use your terminal.

Today, I will walk you through the following topics:

• Explain what agent modes actually control

• Walk through Claude Code’s modes from safest to most dangerous

• Show you what YOLO mode really does, and when it is acceptable

• Show you how to run AI agents securely even in YOLO mode

What agent modes actually control

Before we deep dive into specific modes, let's stop for a moment and talk about what agent modes actually control.

The concept can differ based on the model you use; however, every model answers one question: how much can the agent do without stopping to ask you?

Picture the following situation..

The agent is working through a task. Along the way it wants to:

• Read your files (harmless)

• Edit your code

• Run npm install some-package (downloads and runs code from the internet)

• Run rm -rf ./old-build (deletes files)

• Run git push (sends your code to a remote server)

Every one of those steps is a decision. Does the agent just do it, or does it stop and ask for your permission?

That’s all an AI agent mode is. It defines the line between “go ahead” and “ask me first”.

A strict mode would stop it basically every step of the way. A loose mode lets it read, edit, install, delete, and push without a single prompt. YOLO mode removes the line completely.

But that's enough theory. Let's see how one of the most popular AI coding agents, Claude Code, actually handles this.

Claude Code's modes

This is the modes Claude Code implements from safest to YOLO:

• Manual: Reads files on its own, but asks before every edit, command, or network call. Least privilege. Best for sensitive work.

• Plan: Write a full plan and change nothing until you approve it.

• Accept edits: Edits files in your working folder without asking. Anything outside it still prompts you.

• Auto: Runs most things on its own, but a second model checks each action first and blocks the dangerous ones (piping scripts off the internet into your shell, pushing secrets, force pushes, mass deletions). Now the default is on paid plans.

• Bypass permissions, aka YOLO mode: Everything is off. You opt in on purpose with the --dangerously-skip-permissions flag.

To switch modes, simply press Shift+Tab to cycle modes mid-session, or start with a flag like claude --permission-mode plan.

Why people use YOLO mode despite the risk

Let’s keep it real. Once again, convenience won over security. That’s how it is, and that’s how it will always be.

We don’t want to babysit our AI agents. We want them to work for us while we are enjoying our coffee.

And I get it, the convenience is real, and I know from experience that when the gap between a secure solution and a convenient solution is too wide, convenience always wins.

So how do we solve this situation? On one side, we have people who want to let AI agents do their work for them, on the other, we have significant risks associated with AI agents executing commands in the environment.

Sounds almost like an impossible situation, right?

How to run any AI agent securely

Would I let any AI agent in YOLO mode operate on my machine?

Absolutely not.

That’s an unacceptable risk, and any good AI policy should strongly prohibit these situations. That would be my decision as a Head of IT security.

Does it mean you can’t use AI agents in YOLO mode?

Of course not.

You just have to stop running the agent with your whole life within its reach.
These are the rules that I’d suggest following if you want to use AI agents securely:

• Isolate it - limit the blast radius: Run the agent inside a container or a throwaway virtual machine, not directly on your main system. If something goes wrong, you delete the box and start fresh. Your real machine is never in the blast radius.

• Keep your credentials out: Don’t hand the agent your SSH keys, cloud logins, or password manager. Give it only a scoped, short-lived token for the one task it’s doing.

• Limit the network: Allow only the connections the task actually needs. An agent that can’t reach the open internet can’t quietly send your data out or pull down a malicious payload.

• Drop the privileges: Run it as a non-root user inside that box. Least privilege doesn’t stop at the container wall.

• Mount only what it needs: Give the agent access to the one project folder, not your entire home directory. Take a snapshot before a big run so you can roll back in seconds.

And one habit above all: Follow the secure default principle and save YOLO mode for the disposable box, where losing everything costs you two minutes.

None of this is advanced or new. It’s how you would treat any untrusted program that runs commands. And that is exactly what an AI agent with terminal access is.

Save this list. Then tell me in the comments which of the five you already do, and which one you are missing. I will be happy to help you close the gap!

Leave a comment

Conclusion

I must say I am happy that I finally found time to actually start playing with AI agents.

There is no doubt that AI agents are one of the most useful tools I have picked up this year, and I have a big plan with them.

If you want to follow this journey and learn more about how to use AI agents securely, simply subscribe to Decoded Security and reach out to me anytime!

Subscribe now

Put the agent in a box it can't escape, and you get all the speed with none of the gamble.

That's just least privilege, human in the loop, and blast-radius thinking, the same fundamentals I keep coming back to, applied to a tool you probably use every day.

And what now?

I'm turning my own setup into a Secure AI Agent Setup guide.

The exact container config, the settings that lock things down, and a one-page checklist so you can run any AI agent in full-autonomy mode without handing over your machine.

It is not public yet. To get it the moment it drops, join the waitlist here.

Join waitlist

Thank you for reading Decoded Security!
See you next time..

Erich

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

It comes from Drawn To Cyber, a newsletter that breaks down complex cybersecurity concepts through simple writing and clear visuals.

In this piece, she follows a single IP address through an entire vulnerability scan and shows exactly how it becomes a finding on your dashboard. If scan results have ever felt like a black box, this will fix that.

Go give her a follow, and enjoy!

Subscribe to Drawn to Cyber

You enter an IP address into a vulnerability scanner.

You configure the scan, click Launch, and wait.

A little later, the results start appearing.

Critical. High. Medium. Low.

But how did the scanner get from an IP address to a list of vulnerability findings?

It didn’t simply look at the IP address and somehow know what was vulnerable.

Before producing those findings, the scanner had to discover the host, identify what it could reach, understand what was running, perform relevant security checks, and gather enough evidence to report what it found.

That journey is also where networking and vulnerability management start to connect.

So let’s follow one IP address through a typical network vulnerability scan and see what actually happens along the way.

Step 1: It starts with a target

Imagine we want to scan:

192.168.1.25

At this point, the scanner doesn’t know much about the system behind that address.

The IP address simply tells the scanner where to look.

Behind it could be a Windows server, a Linux server, a network device, or something else entirely. What the scanner eventually learns depends on what it can reach, how the scan is configured, and how much access it has to the target.

So before looking for vulnerabilities, the scanner needs to answer a much simpler question:

Is there actually a reachable host at this address?

Step 2: Is the host reachable?

Before spending time checking the target for vulnerabilities, the scanner may first try to determine whether a host is actually reachable at that IP address.

This is host discovery.

The scanner can send different types of network probes and watch for a response. If the target responds as expected, the scanner has an indication that there is a live host worth assessing.

But there is an important catch:

No response doesn’t always mean no host.

A system may be running perfectly well while a firewall or another network control blocks the scanner’s discovery traffic. The scan configuration can also affect how the scanner decides whether a host is reachable.

This is our first example of why networking matters to vulnerability scanning.

What the scanner can discover depends partly on what the network allows it to see.

Once the scanner has a reachable target, the next question becomes:

What is exposed on that host?

Step 3: Which ports are open?

Now that the scanner knows there is a reachable host, it can start looking at the network services exposed by that system.

One way it does this is by checking ports.

Ports are numbered communication endpoints used by network services. A scan might discover something like:

22 → open

80 → open

443 → open

These numbers provide useful clues. Port 22 is commonly associated with SSH, port 80 with HTTP, and port 443 with HTTPS.

But “commonly associated with” is important here.

Finding port 443 open doesn’t automatically prove that a particular web server is running behind it. Services can run on non-standard ports, and an open port by itself doesn’t tell us everything about the application listening there.

And most importantly:

An open port is not a vulnerability.

At this stage, the scanner has learned that something is listening. It still needs to figure out what that something actually is.

That takes us to service discovery.

Step 4: What service is actually running?

An open port gives the scanner a clue. Now it needs to learn more about what is actually responding on that port.

This is where service detection comes in.

The scanner can interact with the service and examine the information it returns. Instead of knowing only:

443 → open

it may learn something closer to:

443 → HTTPS → web server

Depending on what the service reveals, the scanner may also gather information about the software, version, operating system, or configuration.

This moves the scan from:

“Something is listening here.”

to:

“Here is what I can learn about what’s running here.”

That distinction matters because a port number alone isn’t enough to identify a vulnerability. The scanner needs more information before it can decide which security checks are relevant.

And that’s where vulnerability testing begins.

Step 5: Now the vulnerability checks begin

By this point, the scanner has gathered information about the host and the services it can see.

Now it can start running vulnerability checks that are relevant to what it discovered.

Vulnerability scanners contain large collections of checks, often called plugins, signatures, or vulnerability tests depending on the product. Each check is designed to look for a particular vulnerability, configuration issue, or security condition.

How a check works can vary.

A scanner might examine information returned by a service, look for a particular configuration or behavior, check software and patch information, or use other evidence available from the target.

This is why vulnerability scanning isn’t simply:

Detect a software version → match it to a CVE → report a vulnerability.

Version information can be useful, but it is only one way a scanner can gather evidence.

And the amount of evidence available depends heavily on how much the scanner can see.

From the network, its visibility may be limited.

Give the scanner authorized access to the system, however, and that picture can change significantly.

Step 6: What changes when the scanner has credentials?

Think about trying to inspect a house while standing outside.

You can see the doors, windows, and anything else exposed to you. You can learn quite a bit, but your view is still limited.

An unauthenticated scan works in a similar way. The scanner examines what the target exposes over the network and runs checks based on what it can observe remotely.

Now imagine being given authorized access to go inside.

With valid credentials and sufficient privileges, an authenticated scan can log in to the target and gather information directly from the system.

Depending on the operating system and scan configuration, that might include:

• installed software

• missing patches

• system configuration

• local security settings

• other information that may not be visible remotely

This gives the scanner another source of evidence and can help it identify issues that are difficult or impossible to determine reliably from the network alone.

Same IP address. Same host.

But with greater visibility, the scanner can build a much more complete picture of what is happening on that system.

And with all that evidence collected, we’re finally ready to see what appears in the scan results.

Step 7: We finally reach the vulnerability finding

Now we arrive at what the analyst eventually sees in the vulnerability management platform:

The finding.

By this point, the scanner has gathered information about the target, discovered what it can access, identified services, run relevant vulnerability checks, and collected evidence.

A finding may include information such as:

• the affected asset

• the vulnerability that was detected

• the affected port or service

• severity information

• evidence from the scan

• identifiers such as a CVE, when applicable

• recommended remediation

So what initially looked like:

IP address → Vulnerability finding

was actually a journey:

IP address → Host discovery → Port discovery → Service detection → Vulnerability checks → Evidence → Finding

This is the part of vulnerability scanning we don’t always see when looking at a dashboard full of results.

The scanner didn’t start with a vulnerability.

It started with a target and gradually gathered enough information to tell us what might need attention.

But reaching a finding doesn’t mean the work is finished.

For a vulnerability management team, this is often where the next part of the work begins.

The scanner finding isn’t the finish line

Getting a finding into the dashboard doesn’t mean the vulnerability management work is complete.

In many ways, it is just the starting point.

The finding still needs context.

A vulnerability management team may need to understand:

• Is the finding accurate?

• How important is the affected asset?

• Is the system externally exposed?

• Is the vulnerability exploitable in this environment?

• Are there existing controls that reduce the risk?

• Who owns the affected system?

• How quickly should it be remediated?

Then comes the work of coordinating remediation, tracking progress, and eventually verifying that the issue has actually been addressed.

This is an important distinction:

Vulnerability scanning finds potential security issues. Vulnerability management is what an organization does with that information.

The scanner gives us the finding.

The real work is deciding what it means in the context of the environment and what needs to happen next.

Why networking knowledge matters in vulnerability management

You don’t need to be a network engineer to work in vulnerability management.

But understanding networking fundamentals makes vulnerability scan results much easier to interpret.

When you understand IP addresses, ports, protocols, firewalls, routing, DNS, and network segmentation, you start asking better questions.

Why couldn’t the scanner reach this asset?

Why is this port exposed?

Why was a service detected on an unexpected port?

Why can the scanner see one system but not another?

Why did an authenticated scan reveal findings that weren’t visible remotely?

And when something looks unusual in the scan results, networking knowledge gives you a better starting point for figuring out why.

You begin to see the scan as more than a list of vulnerabilities.

You can understand how the scanner reached the asset, what it was able to see, and how that visibility influenced the findings it produced.

That’s why networking and vulnerability management are so closely connected.

From an IP address to a finding

The next time you see a vulnerability finding in a scan report, think about what happened before it reached the dashboard.

The scanner had to find the asset, communicate with it, understand what was exposed, gather information, run relevant checks, and collect enough evidence to report what it found.

That journey helps explain something important about vulnerability scanning:

A scanner can only work with the visibility and access it has.

Understanding what happens behind the scan results makes it easier to interpret those results, troubleshoot what looks wrong, and ask better questions as a vulnerability management analyst.

An IP address may be where the scan starts.

But understanding everything that happens after that is what makes the findings useful.

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

August was a big month for us, and since you’re part of it, I wanted to share where things stand and say thank you.

What I published this month

In case you missed any of them, here’s what went out in August:

📄 A Port Is Just a Door. Here’s Why Everyone Keeps Knocking
📄 This Is How I Explain SIEM To a Beginner
📄 CISSP Identity Lifecycle Management: The Account You Forgot Is the One That Gets You
📄 Everyone in Cybersecurity Talks About the OWASP Top 10. Almost Nobody Can Tell You Why It Matters.
📄 [Guest post] You cannot make a game unhackable. Here is what “good enough” security actually means.

The numbers

📬 Newsletter subscribers: 1,536 (+75)
🧵 Threads followers: 2,912 (+1,312)
📸 Instagram followers: 196 (+1)
👍 Facebook followers: 458 (+1)

Threads absolutely took off this month, more than doubling.

Some platforms grew faster than others, but every one of those numbers is a real person who decided this was worth their time.

Thank you for being one of them.

New tools this month

The interactive platform at quiz.decodedsecurity.com continued to grow. If you haven’t played with these yet, they’re all free and run right in your browser:

🔧 Port scanner: See exactly what an attacker sees when they scan a target, live in your browser. No install, no setup.
🔧 Linux Sandbox: Practice real Linux commands in a safe, throwaway environment. Break things, undo them, and build muscle memory.
🔧 DNS simulator: Watch what really happens when you type a URL, every hop from your browser to the server, step by step.

The whole idea is to stop reading about cybersecurity concepts and actually try them. Browse them all here!

Decoded Security Tools

Collaborations

August also brought a collaboration I really enjoyed: I teamed up with Tim from GuardingPearSoftware on a piece about why no tool alone will save you from bad habits.

Working with people who care about the human side of security as much as I do is easily one of my favorite parts of this.

If you missed it, it’s worth a read: First rule of cybersecurity: no tool alone will save you from bad habits

And there’s more coming!

Now I want to hear from you

I plan what to write and build based on what you actually want to learn. So hit reply and tell me: what topic, concept, or tool would help you most right now?

Networking? A specific certification? Something that keeps confusing you? Tell me. I read every reply, and the most-requested ideas go straight to the top of my list.

A gift to close out the month

If you’ve been curious about Decoded Security Premium, now’s the moment: I’m opening a 14-day free trial.

Get 14 day free trial

Premium gives you 50% discount on all Decoded Security products and premium content! Try it free for 14 days, and if it’s not for you, cancel before it ends and pay nothing.

Thanks for being here through August. September’s going to be even better.

Let’s learn and grow together!

Erich

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

Have you ever stopped to wonder what that actually means?

What is that 8000 doing there?

If you want a career in cybersecurity, you need to know these networking basics. That is non-negotiable.

Ports and scanning are not something you memorize only for an exam and forget. They are the ground floor of the whole field.

Firewalls, threat detection, penetration testing, incident response, and almost every interview you will ever sit in all assume you already understand this.

So let me show you everything you need to know about this topic to pass not only security exams, but also security interviews, and most importantly, be a useful member of a security team.

What you’ll learn today:

• What a network port actually is

• The handful of ports worth memorizing

• What port scanning is, and the three answers a scan gives you

• Why attackers and defenders scan the exact same way

• What an “open port” really means

What is a port actually?

Every device on a network has an IP address.

You can think of it as the street address of a building. But a building is not one room.
It has many doors, and behind each is a different service.

A port is one of those doors.

Your computer might run a website, an email service, and a remote login all at once. The port number is how it knows which service the incoming traffic is meant for. So the full address of a service is the IP plus the port:

192.168.1.10:443

That means: go to this building (the IP), then knock on door 443 (the port). Behind 443 is usually a secure website.

👉 Clearest “what is a port” you have read? Tap the ❤️ like so the next beginner finds it.

The doors you will see over and over

There are 65,535 possible ports, but a couple you should be aware of. Especially if you’re preparing for some cybersecurity exam, such as the Security+:

• 80 (HTTP) regular, unencrypted websites

• 443 (HTTPS) secure, encrypted websites (the little lock icon)

• 22 (SSH) securely logging into a machine from a command line

• 3389 (RDP) Remote Desktop into a Windows machine

• 25 (SMTP) sending email between mail servers

• 53 (DNS) turning names like decodedsecurity.com into IP addresses

However, there is one thing I’d like to make absolutely clear. You can run any service on any port you like. This is only a convention, nothing else!

Scanning is just like knocking

If a port is a door, a port scan is knocking on those doors, one after another, to see which open.

A scanning tool sends a small message to a port and listens for the reply.

That reply sorts every door into one of three states:

• Open. Someone answered. A service is running behind this door and is ready to talk. This is a live entry point.

• Closed. The host replied “nobody home.” The machine is reachable, but no service is listening behind that door.

• Filtered. Total silence. Something, usually a firewall, is blocking the knock, so you cannot even tell if a service is there.

The important distinction here is that closed and filtered are not the same.

Closed means “no service here.” Filtered means “you are not allowed to ask.”

A tool like Nmap runs this on thousands of ports in seconds and hands you a labeled map of every state. That map is the starting point for almost every security assessment.

Want to watch these states change in real time? Try the Decoded Security Port Scanner and learn how to read the output!

Port Scanner

What an “open port” actually means

Here is the myth I want to kill: an open port is not the same as a vulnerability.

An open port just means a service is running and reachable, which is often exactly what you want. Your web server is supposed to have 443 open. A closed 443 means your website is down.

An open port only becomes a problem when:

• It should not be open at all (nobody remembers why 3389 is exposed to the internet)

• The service behind it is outdated (the door is fine, the lock is easy to pick)

• The service is misconfigured (the door opens and never asks for a password)

So the real question is never just “is this port open?” It is “should it be open, and is the thing behind it locked properly?”

Remember: Always make sure you know exactly what services you expose to the internet.

The plot twist: attackers and defenders scan the same way

Here is the funny thing about port scanning. Both sides do it. Because it turned out, that in this case, the easiest way to find a vulnerable service on your own network is to do the same thing that attackers would do.

The only difference is the reason why we do it.

• An attacker scans to find a way in: An open door running old software is their lead.

• A defender scans to find what needs protecting: You cannot secure a door you did not know existed.

Same tool. Same technique. Same output.

The only thing that changes is intent and permission.

Port scanning is a flashlight: a burglar uses one to case a house, a homeowner uses one to check the locks. Nobody blames the flashlight.

Do you like my analogies? Hit ❤️ and help other people find it!

Key takeaways

Okay, I have been working as a cybersecurity manager for years, and here is what I believe you should take from this article

• A port is a numbered door, and each leads to a different service.

• The full address is the IP plus the port (localhost:8000)

• A scan is knocking to see which doors are open, closed, or filtered.

• What each state means

• Attackers and defenders use the same technique; intent and permission are the differences.

• An open port is not automatically dangerous, only when it should not be open, or the service behind it is weak.

Master this one analogy, and a whole layer of networking makes sense. Scans stop being scary and start being information.

If this made ports click, do two quick things: tap the ❤️ like so more beginners find it, and subscribe so you never miss the next one.

Subscribe now

What to read next

If ports clicked for you, keep building your networking foundation with these:

• This Is How I Explain DNS To Beginners: how a name like decodedsecurity.com turns into an IP address, the step that happens before you ever knock on a port. Read it here

• This Is How I Explain Subnetting: what an IP address really is underneath, and how networks get carved into smaller pieces. Read it here

• What Actually Happens When You Open a Website: the full DNS to TCP to TLS to HTTP chain, and the exact question interviewers love to ask. Read it here

Free resource: Top 10 Cybersecurity Fundamentals

Before you go, grab my free guide. It covers the 10 cybersecurity fundamentals behind roughly 90% of entry-level interview questions, the exact concepts that get you hired faster. 80 pages, zero cost.

Top 10 Cybersecurity Fundamentals

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap
Decoded Security Platform: Decoded Security
Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

Note: Infographics were created by .

Here is what I love about cybersecurity: the same concepts show up everywhere, and it is fascinating to watch them play out in different environments, especially when you get to read it from experts like Tim.

This guest post is a perfect example. It takes the exact ideas you are studying for GRC and CISSP, residual risk, risk treatment, threat modeling, impact versus likelihood, and shows them running live inside the gaming industry.

Real cheaters, real stolen revenue, real players walking away. Same framework you are learning for exams, such as CISSP, but with way better stories than any textbook.

So who better to walk you through it than someone who does this for a living? This post comes from Tim Uhlott, founder of GuardingPearSoftware, who has protected 4,000+ games since 2017.

Over to Tim.

You cannot make a game unhackable. Here is what “good enough” security actually means.

You finish a build. You ship it. Then a thought shows up that nobody put in the design doc.

Can I make my game totally unhackable?

I hear that question a lot from game developers who are just starting to care about security. It sounds responsible. It also points you at the wrong target.

Short answer: no. You cannot make a game unhackable. That is normal. The game runs on a computer or phone that the player owns. If someone has the device, they can look at files and change memory. They can replay traffic too. Perfect protection is not available on hardware you do not control.

The useful question is different. What is worth protecting, and what risk can you live with?

Here is what you will learn in this article:

• Why “unhackable” is the wrong goal

• Why a common cheat can matter less than a rare failure

• Why single-player and multiplayer need different decisions

• What economic protection actually means

• How security people treat leftover risk on purpose

If you build games and you are new to cybersecurity, this is the shift that will save you months.

The player owns the device

A game client is not a vault. It is software sitting on someone else’s machine.

That person can open the install folder. They can attach tools while the game is running. They can change a value in memory and see if the health bar moves. They can send the same “I won” message twice. None of this requires a movie-hacker setup. A lot of it is boring, documented, and shared in public.

So when your game checks a score on the device, or unlocks a sword because a local file says so, you are asking the player to be honest. Some will be. Some will not.

Client-side checks still have a job. They stop curious players. They slow down copy-paste scripts. They are a speed bump. They are not a wall.

Remember: The most dangerous system is not the one without anti-cheat. It is the one that believes the player’s device.

If one idea from this article sticks, make it that one.

Threat is not the same as impact

New security people often rank problems by how scary they sound. Infinite health feels urgent. A missing backend check on a purchase feels like paperwork.

Impact asks a different question. If this works, who gets hurt?

A cheat can be common and still be a shrug. A failure can be rare and still close a live game.

Takeaway: spend time where impact is high, not where the scare story is loud.

Note: Security professionals split this into likelihood and impact. A risk is not “this can happen.” A risk is “this can happen, and here is the damage if it does.”

If you only remember the table, remember the last two rows. Those are the ones that surprise studios.

Single-player and multiplayer are not the same problem

The same word, “hacked,” hides two different jobs.

In an offline single-player game, a person who gives themselves infinite gold mostly hurts themselves. You might still care about piracy, copied art, or a paid unlock that never went through a store. Gameplay cheats are usually not your first problem.

In a multiplayer game, one modified client changes everyone else’s night. Fake damage, wallhacks, and invented currency do not stay on one machine. They show up as unfair matches and empty queues. The store stops making sense.

Purchases sit in the same bucket. If the device says “the store charged the card” and your game believes it, you did not sell an item. You accepted a story.

This is threat modeling, without the textbook first. You list what an attacker wants, who gets hurt, and which system is allowed to decide the truth.

Remember: The hack did not change. The owner of the harm did.

Ask “who pays if this works?” before you ask “how do I block every tool?”

Make cheap attacks expensive

Attackers are not a single villain with unlimited time. Most of them are people, or scripts, looking for a reward that is worth the evening.

If a leaderboard can be faked in ten minutes, someone will fake it. If inventing currency takes a week of ugly work and the reward is a hat, most people move on. Security people call this economic protection. You raise the cost of the attack until it is no longer a good deal.

You will not stop the most dedicated person on earth. That person is not your planning target. Casual edits and public copy-paste kits are.

Good enough security is not a fortress. It is a set of decisions that makes the cheap attacks annoying and the expensive attacks rare.

Remember: Good enough security makes the cheap attacks expensive and the expensive attacks rare.

That is a much kinder goal than “nobody can ever touch this.”

Leftover risk is not a failure

Some things you cannot prevent, because the player owns the device.

You cannot stop someone from reading memory on their own PC. You cannot fully stop software that aims by looking at the screen. You cannot hide every secret forever if that secret ships inside the app. A person with enough time can study a client.

That leftover piece has a name: residual risk. It is the risk that remains after you have done the work you chose to do. Naming it helps you stop chasing a clean score of zero.

Security people then pick a treatment. They do not hope the leftover risk disappears.

Accept it. Infinite gold in a paid offline game can stay in the “we know, we are fine” pile.

Mitigate it. Put rewards, purchases, and match results on a server you control. Make the shipped code harder to read. Watch for progress that cannot happen in a real session.

Transfer it. Let the store confirm a receipt. Let Steam, Apple, or Google confirm that a session belongs to a real owner. Let a host or protection service take the first hit when traffic tries to knock the game over.

Avoid it. If you cannot put the truth on a server, do not ship ranked mode, player trading, or a real-money economy. That is not cowardice. That is choosing not to create a problem you cannot own.

Note: This set is called risk treatment: accept, mitigate, transfer, avoid. The grown-up move is choosing one of the four on purpose, not hoping for zero risk.

If you skip the choice, you still made one. You accepted the risk by accident.

A simple order of work

You do not need a security team to start. You need a short sequence you can repeat.

First, name the game you actually shipped. Offline single-player, online with scores, competitive, or something that sells items for real money. The type changes every later choice.

Second, write down what would actually hurt. Stolen revenue. Other players leaving. Keys that open a backend. A public board that looks fake. If a problem is not on that list, it can wait.

Third, move the painful decisions off the device. The client can send input. It can show animations. It should not be the judge of rewards, inventory, match outcomes, or purchases.

Fourth, accept the rest out loud. Write it down if you have to. “Players can cheat their own offline save. We are okay with that.” That sentence is a control. It stops you from spending a month on a lock nobody needed.

Fifth, ship, then look again when the game’s value changes. A quiet hobby project that later adds trading is a new game from a risk point of view. The old accept list may be wrong now.

What game are you building, and which row in the table above is the one that would actually hurt you? Tell me in the comments. I am curious where people draw the line.

Key takeaways

1. Unhackable is not a goal. The player owns the device, so leftover risk will always exist.

2. Impact beats fear. A common cheat can be cheap to ignore. A rare failure can be expensive.

3. Game type changes the model. Offline cheats and live-service cheats are not the same job.

4. Raise the cost. Make casual and automated attacks a bad use of time.

5. Treat leftover risk on purpose. Accept, mitigate, transfer, or avoid. Do not drift.

Master those five, and you will stop asking “is this bulletproof?” You will start asking “what fails, who pays, and which treatment did I pick?”

That is how security people think. It is also how you keep building games instead of rebuilding the same lock.

The question was the trap

Go back to the start. “Can I make this unhackable?”

If you chase yes, you delay the release, and you still fail. The device is not yours. The dedicated attacker still exists. The month you spent on a perfect client check was a month you did not spend on the server decision that actually mattered.

Good enough security is a clear risk choice. It protects the money and the other players. It also protects the secrets. It leaves the rest alone on purpose.

That is not giving up. That is how you ship.

About the author

I am Tim Uhlott. I started coding at 12 because I wanted to know how games worked, and I still like taking a messy problem apart until the real decision shows up.

That is the work I do now at GuardingPearSoftware. I teach cybersecurity for games and I build security tools for Unity developers who are trying to protect the parts that actually matter.

If you want more of this, you can find me here.

guardingpearsoftware.com

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

OWASP Top 10

It shows up in job interviews. In study guides. In LinkedIn posts. In tool documentation. In your CISSP prep. It shows up everywhere.

The funny thing is, most people who claim it's important have no idea why it is actually useful. They just repeat it like a broken gramophone because they want to sound like an expert.

And maybe that’s why it took me so long to figure out how useful it is.

So let me explain it to you in a way that I wish someone had explained it to me at the beginning.

Here is what you’ll learn today:

1. What the OWASP Top 10 actually is

2. Why it is different from what you think

3. Why the whole industry rallies around it it

4. How to actually use it as a beginner

5. How to talk about it in an interview so you stand out

Shall we?

What Is the OWASP Top 10?

Let’s start from the beginning.

OWASP is the Open Worldwide Application Security Project. It is a nonprofit community, not a company trying to sell you something.

The OWASP Top 10 is their flagship publication:

A regularly updated list of the ten most critical security risks facing web applications, based on real-world data from thousands of applications and breaches.

Read that definition again, because two words in it do all the heavy lifting.

“Regularly updated.” This is not carved in stone. It changed from the 2021 version to the newest 2025 version, and it will change again. Because attackers move, and the way we build software moves.

“Real-world data.” It is not somebody’s opinion about what feels dangerous. It is a ranking built from evidence, from what is actually going wrong out there.

So the plain-English version is this: every few years, a global community looks at where organizations are actually getting hurt, and publishes the ten risk categories doing the most damage right now.

How is it different from what you think

Most beginners and so-called experts start focusing on the categories. They test people to see if they can recite them in the interview.

But the categories are not the point of the list. The categories might change, but what the list represents stays the same.

And I hate to say this, but most people focus on the categories rather than what the list represents and how to use it to actually improve the organization's security posture.

So if I want you to remember one thing from this article, it is this:

The OWASP Top 10 is not a list to memorize. It is a way of thinking about risk that the whole industry agreed to share.

Why does the whole industry rally around it

I just told you what the OWASP Top 10 isn’t. So now let’s take a look at what are the actually benefits it brings that you SHOULD remember as a cybersecurity professional.

So why is the OWASP Top 10 so important?

1. It gives everyone a shared language.

A developer in Berlin, an auditor in Toronto, and a CISO in Singapore can say “we have an access control problem” and instantly mean the same thing.

Before a common reference existed, every team described risk in their own words, and nobody could compare notes.

The Top 10 is the vocabulary that lets security people talk to each other without translation.

2. It turns an impossible problem into a priority list.

There are thousands of ways an application can be insecure and you can’t possibly handle all of them.

The OWASP Top 10 gives us risk-based prioritization, and it is the core of the entire security profession.

Remember: Security professional shouldn’t just implement security controls aimlessly.

3. It gives us baseline

No serious organization treats the Top 10 as “do these ten things and you are secure.” It is the baseline that we should focus on with the highest priority.

If you cannot even address the ten most common risks, you have no business worrying about advanced threats.

It is the minimum bar of awareness, which is exactly why it is everywhere.

Thousands of ways to be insecure, and no clue where to start. The OWASP Top 10 exists to answer one question: What do I fix first?

4. It is built into your tools and your tests.

This took me a while to figure out but most security scanners (the tools that automatically check your code and your running apps) label what they find by OWASP category.

Penetration testers scope their work around it and map every finding back to it in their reports.

So even when nobody says the words out loud, the tools and the tests are already speaking Top 10.

5. It has become a compliance standard.

Open a vendor security questionnaire, a client contract, or a framework like PCI DSS, and you keep running into the same line: “must address the OWASP Top 10.”

In other words, It is now something auditors, clients, and regulators expect you to have handled.

Notice the pattern.

Not one of these five requires you to recite the ten categories from memory. Every single one treats the list as a standard, a baseline, and a shared language.

That is the whole point.

Conclusion

This article has only one goal. Explain that the OWASP TOP 10 shouldn’t be a list that people recite, but much rather a reference model that can change over time.

And trust me, if someone asks you about it in an interview and you’ll tell them how it’s actually used in the real practice instead of naming the categories, you will make much better impression.

If I can give you a piece of advice, do this 3 things:

Learn the "why," not the "what."Ask the question: what damage does it cause, and why is it still on the list after twenty years?

Use it as a lens, not a list. Connect it to what you already know, access control, authentication, data protection, and you'll see it is just your fundamentals breaking in the real world.

Then turn the news into a game: Next time you read about some breach, try to assign the breach to the right category. It is a simple excercise that you can do on your way to work.

Here is how you should describe the OWASP Top 10 from now on: The OWASP Top 10 is the industry's data-driven list of the most critical web application risks. What makes it valuable isn't the ten items. It's that it gives teams a shared language and a way to prioritize what to fix first.

Subscribe now

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

You have brilliant access management, you label all the data, and everything is a well-oiled machine.

But you forgot one small detail. You forgot how to handle accounts when people leave.

Or maybe you forgot to review the accounts once in a while, and now you have a couple of employees who have access to more sensitive information than the CEO.

The whole identity lifecycle can be very tricky, and ignoring its risks can easily destroy the security posture of your organization.

Remember: A forgotten account is like an invitation for an attacker.

Here is what you’ll learn in today’s article:

• Why identity and access management is so problematic in real organizations

• The full IAM lifecycle - phase by phase

• How access control, compliance, and configuration management hold the middle together

• Why is deprovisioning the most neglected control in security

• The key CISSP takeaways you need for the exam and the real world

Let’s get into it.

The problem nobody wants to own

Before we dive into details of how to handle accounts, let me tell you what’s the most problematic thing about it from my experience.

Nobody wants to own this problem.

Everyone loves the beginning. A new hire joins, IT creates the account, access is granted, and everyone feels productive.

But the rest of the lifecycle? Silence.

Nobody wants to review access every quarter.

Nobody wants to untangle the permissions an employee collected over five years.

And nobody remembers to remove access the day someone walks out the door.

IT assumes the manager will flag it.
The manager assumes IT takes care of it.
Everyone assumes there’s a process.

And the account just sits there. Alive. Long after the person is gone.

That’s the real issue. Identity lifecycle management isn’t hard because the technology is complicated. It’s hard because it’s boring, it never ends, and it belongs to everyone and no one at the same time. At least that’s what people think.

So remember this: the manager owns their team's accounts. Not IT.
IT just configures access based on the rules they're given. That's where their job ends.

So how do you fix a problem everyone ignores?

You stop treating access as a one-time event and start treating it as a lifecycle.

Break it into phases, and “someone should handle this” becomes “this phase, this owner, this action.”

That’s how forgotten accounts stop happening. Let’s break it down.

The IAM Lifecycle, Phase by Phase

Every identity in your organization moves through the same lifecycle. Understanding each phase, and the controls that belong to it, is what separates a security professional from an administrator.

The lifecycle looks like this:

The beginning and the end get attention. The red area is where it gets problematic.

Provisioning: Creating and Granting the Identity

Provisioning is the creation of a user’s digital identity and the assignment of their initial access, typically on day one.

This phase usually works. It has a clear trigger, a new hire or an HR record, and it’s often automatic. That’s exactly why it rarely gets forgotten.

The one rule that matters: least privilege. Grant only what the role needs, nothing more.

CISSP note: When access is technically functional but excessive for the role, the correct answer favors restricting access from the start, not granting broadly and correcting later.

The Problematic part between the beginning and the end

Okay, hooray. We have the account, the person happily uses it. So where’s the problem?

The problem is that nothing stays still.

The account was perfect on day one. But people don’t stay on day one. They get promoted, switch teams, join a project and leave it.

Every one of those changes is supposed to update their access, and too often, it doesn’t.

This is the maintenance phase, the longest stretch of an identity’s life. It’s where access control, compliance, and configuration management all live.

But if you remember one thing from this section, make it this:

Access must be reviewed periodically.

Not once. Not “when we get around to it.” On a schedule.

Because even the best processes won’t prevent all mistakes, and without regular reviews, nobody removes old access.

Five years later, you’ve got an employee who moved through three departments and kept every permission from all of them.

On paper, they’re in operations. In reality, they can still touch finance, HR, and systems from a role they left in 2021.

That’s called privileged creep, and periodic reviews are the one control that catches it before it becomes an audit finding or a breach.

Two rules make reviews actually work:

• They run on a fixed schedule (quarterly, annually)

• The manager or data owner conducts the review, never the user.

Remember: In this phase, the danger isn’t the access you grant. It’s the access you forget to take away.

Deprovisioning: This is where it ends

Every account has a last day. The problem is you don’t often know it’s the last day.

What if a contractor finishes the project and nobody tells the IT department? Or an employee is fired, but the manager didn’t trigger the right workflow?

That’s how the account just sits there. Alive. And a dormant account with nobody watching it is exactly what an attacker is hoping to find.

The fix is simple, and it’s the same one that fixes half of this lifecycle: automation.

When HR marks someone as terminated, the system should kill their access everywhere, instantly.

And as I was saying before, back it up with periodic checks for orphaned accounts that slipped through.

CISSP note: When a scenario describes a terminated employee who still has access, the answer is almost always automated deprovisioning tied to HR, not a manual step someone has to remember.

Remember: The most dangerous account isn’t the one you’re watching. It’s the one you forgot existed.

Key Takeaways

Identity and access management isn’t hard because it would be a complex technical issue.

It’s hard because it never ends, and someone has to own every phase. Here’s what to walk away with - best practices for the exam and for the real world:

1. Treat access as a lifecycle, not an event. Provisioning, maintenance, deprovisioning. Every phase needs an owner, or accounts fall through the cracks.

2. The manager owns the accounts, not IT. IT configures based on the rules it’s given. Accountability sits with the manager or data owner.

3. Provision with least privilege. Grant only what the role needs. Excessive access is a risk from day one, and the CISSP answer is always to restrict from the start.

4. Review access on a schedule. Periodic reviews are the one control that catches privilege creep before it becomes a breach. The manager reviews, never the user.

5. Deprovision automatically. Tie revocation to HR so access dies the moment someone leaves. The account you forget is the one that gets you.

Master these five, and you’ll read any IAM exam scenario, spot the phase that failed, and pick the control that reduces risk. That’s exactly how the CISSP wants you to think, and what serves me in my role.

What to Read Next

If this clicked, here’s where to go from here on Decoded Security:

• The AAA Framework: Can Your Coworkers Log In as You? The identification, authentication, and authorization concepts behind every access decision in this article, explained the same simple way.

• Start Here: The Decoded Security Roadmap New to cybersecurity or on the CISSP path? This is the map. It shows you exactly what to focus on so you stop drowning in scattered material.

• GRC for Beginners: The Exact Study Plan Want to turn these governance and risk concepts into a real career direction? Start with this.

Pick one, keep the momentum, and you’ll build real understanding instead of collecting random facts.

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

How many events do you think happen on a corporate network every minute?

Logins. Failed logins. File accesses. Network connections. System changes. Application errors. Policy violations.

Take a guess.

I bet you think it is less that it really is.

On a medium-sized corporate network, we are talking about tens of thousands of log entries every single minute. Hundreds of thousands per hour. Millions per day.

Now imagine your job is to find the three events in that ocean of data that actually indicate a real attack.

That is what a Security Information and Event Management system - a SIEM - is designed to help you do.

So what can you expect today?

After reading this article, you will understand:

• What a log actually is and why it is the foundation of everything in security operations

• What a SIEM actually does in a real environment

• Why collecting every log is the worst mistake you can make

• Why false positives are the real operational challenge

• What CC, Security+, and CISSP candidates need to know for the exam

Warning: CC, Security+, and CISSP relevant topic.

It All Starts with Logs

Before we deep dive into complicated theory, let’s make just one thing clear.

Because without knowing what a log is, everything else that follows simply won’t make sense.

Every operating system, application, firewall, cloud service, and network device constantly records events. These records are called logs.

Some examples include:

• A user successfully logs in.

• A firewall blocks a suspicious connection.

• A web server receives a request.

• A new administrator account is created.

• An employee connects through the VPN.

Think of logs as the digital footprints left behind by every activity inside your environment.

As each device in your infrastructure generates some logs, it would be very difficult to work with them. That’s why they are typically stored in one place, where we can manage the logs in accordance with the company’s policies.

Collecting all of this information is useful, but only if you can actually find what you’re looking for. Otherwise, you have just hard drives full of data.

What a SIEM Actually Does

A common misconception is that a SIEM is simply a place where logs are stored.

It isn’t. That’s log management.

A SIEM is a system that continuously analyzes logs coming from different sources and looks for suspicious relationships between them.

Imagine these three events happen within five minutes:

• A user successfully connects through the VPN.

• PowerShell starts on a production server.

• A new administrator account is created.

Individually, none of these events necessarily indicates malicious activity.

Employees connect through VPNs every day.

System administrators use PowerShell constantly.

New administrator accounts are occasionally created.

But when all three happen together, using the same account within a very short time window, they tell a much more interesting story.

A SIEM identifies these relationships using correlation rules.

Instead of looking at individual log entries, it asks questions such as:

“Did Event B happen shortly after Event A?”

or

“Did the same user trigger these events across multiple systems?”

If the answer is yes, the SIEM generates an alert for a security analyst to investigate.

This is what makes a SIEM so powerful. It doesn’t just collect information. It connects the dots between them.

Well, there is one slight problem with that…

The False Positive Problem

It all sounds nice. You have a system that correlates events and tells you when something bad is going on.

It might sound impressive until you realize that only like 1% of those alerts represent actual malicious activity.

Everything else is just people working, and your SIEM flagging them. This is known as a false positive.

A false positive is an alert that appears suspicious but ultimately turns out to be legitimate activity.

And this is where it gets actually difficult. Tuning your SIEM and configuring it to reduce the number of false positives to a minimum while still being able to recognize malicious activity.

As you can see in the picture below, if you make the system too sensitive, it will flood you with false positives. If you make it too ignorant, you will miss real attacks.

The funny thing is that there is no “general” template, and it requires a strong understanding of the environment.

It is very easy to just “set up” SIEM and then never look at it. Or flood your Incident Response team with countless alerts.

Neither of those options will actually improve your organization's security posture.

A good SIEM isn't measured by how many alerts it generates. It's measured by how many meaningful alerts it generates.

Exam Takeaways (CC, Security+, CISSP)

If you’re preparing for a certification exam, or you are about to implement SIEM remember this:

• Log management is not the same as SIEM. Log management focuses on collecting, storing, and searching logs. A SIEM goes further by correlating events from multiple sources to detect suspicious activity.

• More logs do not automatically mean better security. Collect the logs that provide security value. Ingesting every possible log increases costs, creates noise, and makes investigations more difficult.

• SIEM requires continuous tuning. Detection rules must be refined over time to reduce false positives while maintaining the ability to detect real threats.

• A SIEM is not a “set it and forget it” solution. Detection rules need regular updates as your infrastructure, applications, and attack techniques evolve.

• A SIEM does not replace security analysts. It generates alerts, but people still need to investigate them, determine whether they are legitimate, and respond appropriately.

• False positives are inevitable. The objective isn’t to eliminate every false positive. It’s to reduce them to a manageable level without significantly increasing the risk of missing real attacks.

• Correlation is the primary value of a SIEM. Individual log entries rarely tell the full story. A SIEM connects related events across multiple systems to identify attacks that would otherwise remain hidden.

Remember: A good SIEM isn’t judged by the number of logs it collects or the number of alerts it generates. It’s judged by its ability to help analysts identify genuine threats quickly and efficiently.

Conclusion

At the beginning of this article, I asked you to imagine finding three malicious events hidden among millions of log entries.

Hopefully, you now understand why that task is impossible without the right tools, and why organizations rely on SIEM solutions to make sense of overwhelming amounts of security data.

But remember, a SIEM isn’t a magic box that will do it on its own.

It doesn’t automatically make an organization secure. It doesn’t stop attacks on its own. And it certainly doesn’t replace skilled security analysts.

A SIEM is only as effective as the logs it receives, the detection rules it uses, and the people responsible for tuning and monitoring it.

So remember that you NEED people to actually use the SIEM! Otherwise, it is just an expensive dashboard full of alerts.

Want to go deeper on the concepts connected to SIEM?

SIEM sits at the heart of security operations. These articles build the complete picture:

Understand what happens when a SIEM fires an alert:
👉 The Incident Response Mistakes That End Interviews Early

See SIEM in action with a hands-on lab:
👉 Hands-On Lab: How Attackers Crack Passwords in 0.0006 Seconds

Understand the path that uses SIEM every day:
👉 How to Choose the Right Cybersecurity Role

Get a structured study plan for the SOC path:
👉 SOC Study Plan: Entry Level to Intermediate

Understand the networking that feeds logs into your SIEM:
👉 This Is How I Explain DNS To Beginners
👉 Top 5 Most Important Network Protocols

Build the Linux skills every SOC analyst needs:
👉 This Is How I Explain Linux To a Beginner
👉 Top 5 Linux Commands for an Entry-Level Cybersecurity Role

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

And when I say brilliant, it means it didn’t work at all, but that’s not the point here.
The point is that it required creating a simple app.

Even though it was simple, it took me more than a month to develop and deploy it. Something that would probably take you less than a day today, thanks to the AI.

That’s how it works nowadays, right?

You just tell AI what you want, and it will create it for you.

There is even a term for it: Vibe Coding.

And that’s what I will cover in this article, because it isn’t something that’s relevant only for individuals trying to create something on their own.

This is serious business, as they are forcing their developers to use AI as much as possible, thinking it will lower development costs.

Lesson #1: AI does not know the difference between “code that works” and “code that is safe.”

Here’s what you can expect to learn from this article:

1. What is Vibe Coding

2. Why does AI produce these flaws by design

3. The 3 security issues that show up in vibe-coded apps over and over

4. An interactive challenge at the end

What is Vibe Coding?

Vibe coding means describing what you want in natural language and letting AI write the code. In other words, instead of opening an IDE, setting up an environment, creating an architecture, and then developing an app, you just tell Claude to create an app that does X and Y.

You test if it works. If it does, you move on. If it doesn’t, you paste the error back and let the AI fix it.

You never fully read the code. You never fully understand the code. You “trust the vibe”.

It sounds perfect, doesn’t it? Finally, you don’t need those expensive developers.

But there is a hidden cost that most people don’t see.

You might save effort now, but you pay with security and maintenance.

The hidden cost of Vibe coding

There are two major problems with this concept.

First, if you develop an app or any system this way, you don’t really know how it works. Which also means, if there is any problem with the app, there is no one who can effectively fix it.

A team of developers who actually wrote the code is typically able to debug it a lot more effectively than that one guy who let the AI do his work.

A lack of knowledge of a system’s internal workings will eventually drive maintenance costs to an unbearable level and create significant technical debt that will need to be paid off someday.

WITH INTEREST.

Second, AI typically creates insecure code. And when I say insecure, I mean real security vulnerabilities that can be easily exploited.

Why?

The reason is quite simple: AI coding assistants learned from public code. All of it.

Secure code written by careful engineers. And insecure code from old tutorials, learning materials, and Stack Overflow answers that skip security “for simplicity.”

If there is one thing you should remember from this article, this is it: AI does not know the difference between “code that works” and “code that is safe.”

Let’s take a look at the most common security mistakes AI makes so you can spot them!

Top 3 security issues - Vibe Coding

Let me set one thing clear. I didn’t perform any comprehensive study. This list is based purely on my personal experience as Cybersecurity Manager.

This is the most serious security issue that I see AI make on a regular basis.

1. Hardcoded secrets

API keys, database passwords, and tokens written directly into the code.

The app works perfectly. Of course if does. But it is something that even junior developers are used to avoiding.

This is something you really want to avoid. So next time you create an app with an AI, make sure the secrets are stored securely.

How to fix it: secrets belong in environment variables or a secrets manager. Never in code. Search your codebase for “key”, “password”, “token”, “secret” before every deploy.

2. Missing authentication and authorization

Two different questions that vibe-coded apps constantly confuse:

• Authentication: Who are you?

• Authorization: Are you allowed to do this?

AI-generated apps often check the first and forget the second.

This is what usually happens: Your app verifies the user is logged in, but not that the invoice they’re opening is their invoice.

So if you change /invoice/1042 to /invoice/1043 in the URL, you can easily read someone else’s data.

This is called an IDOR (Insecure Direct Object Reference). One of the most common real-world vulnerabilities. And something that you can see all the time in vibe coded apps.

The fix: for every endpoint, answer two questions. Who can call this? What exactly are they allowed to see or change?

3. Poor input validation

This particular problem was fairly common even before the AI age.

Well, that means AI had plenty of opportunities to learn the incorrect behavior.

A lack of input validation opens the door to SQL injection, cross-site scripting, or path traversal attacks.

They still work, because many apps still trust user input. Even though they shouldn’t.

AI-generated code usually validates the “correct” path only. Because the correct path is what makes the demo work.

However, the real world isn’t always so peachy.

How to fix it: Treat every input as hostile. Validate on the server, not just in the browser. Use parameterized queries, always.

Test yourself: Can you spot the vulnerability?

Reading about my experience with Vibe-coded apps is one thing. But can you actually spot the vulnerabilities in the real world?

That’s why I built an interactive challenge for you!

Finish the challenge, comment on the article, and get a 1-month premium Decoded Security subscription for FREE!

Take the challenge!

Conclusion

Congratulations! If you finished the challenge, you can now spot the most common security mistakes AI typically makes.

But before you go, let me say this. I am not saying using AI for software development is bad. That isn’t the point. However, we shouldn’t give up on the standards that we spent decades developing.

AI isn’t the problem, the 100% trust that it doesn’t make any mistakes is.

So keep that in mind!

See you next week!

Erich
Decoded Security

FAQ

Is vibe coding bad? No. It can speed up the development, and it is perfect for prototypes. The problem is shipping code nobody reviewed, and nobody understands for real users.

Can’t I just ask the AI to write secure code from the start? It helps a lot. Add “follow security best practices, no hardcoded secrets, validate all inputs, enforce authorization on every endpoint” to your prompts. But make sure to verify it anyway!

Does this matter for the CISSP or Security+ exam? Absolutely. Secure defaults, least privilege, input validation, and secure SDLC are core exam concepts. Vibe coding is simply the newest place where the oldest principles apply.

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

Your bank sends password resets there. Your cloud accounts send login codes there. Your company sends contracts, invoices, and credentials there.

Email is your digital passport. If someone can convincingly pretend to be you, they can walk through almost any door you own.

And here is the uncomfortable part:

Email was never designed to verify who is sending it.

The protocol behind email, SMTP, was created in 1982. Back then, the internet was a small club of researchers who trusted each other. So nobody built in authentication.

That means I can send an email that says it is from ceo@yourcompany.com. The protocol will happily deliver it.

So how is it possible that your inbox is not full of fake emails from your bank?

Because of three mechanisms bolted on top of email decades later: SPF, DKIM, and DMARC.

Most people can name them. Very few can explain what each one actually does. And in interviews, that difference gets noticed immediately.

In this article, you will:

• Understand why email spoofing is possible in the first place

• Learn what SPF, DKIM, and DMARC each verify

• See why SPF and DKIM alone do NOT stop spoofing

• Check any domain’s email security yourself, with two commands

Have you ever been asked about SPF, DKIM, or DMARC in an interview? Give this article a like and help others prepare for the same question!

First, understand the trick: an email has TWO senders

This is the concept everything else depends on.

Every email has:

1. The envelope sender. A hidden address used by mail servers to route the message. You never see it.

2. The From header. The address displayed in your inbox.

Here is the problem:

These two addresses do not have to match.

The envelope can say attacker@evil.com while your inbox displays ceo@yourcompany.com.

It is like a physical letter. The post office only looks at the envelope. Whatever name is written inside the letter is up to the sender.

SPF: The Guest List

Definition: SPF (Sender Policy Framework) is a DNS record that lists which servers are allowed to send email on behalf of a domain.

Think of SPF as a guest list published by the domain owner.

When a mail server receives an email, it asks:

Is the server that sent this email allowed to send for the envelope sender’s domain?

Simple enough. So, where is the problem? The receiving server checks if the sender is allowed to send emails on behalf of this domain, and it stops phishing, right?

Well, no.

Remember that every domain publishes its own guest list.

The attacker owns, for example, the evil.com domain. So the attacker writes the guest list for evil.com, and puts his own server on it.

Let me show it to you on one simple example:

Envelope sender:  attacker@evil.com
                  ↓
                  Server checks evil.com's guest list
                  ↓
                  Attacker's server IS on it. SPF PASSES.

From header:      Decoded Security <info@decodedsecurity.com>
                  ↓
                  Never checked. At all.

Note: The receiving mail server checks evil.com's SPF record because that's the envelope sender.

The mail server verified that evil.com was allowed to send the email. It never verified that the visible From address belonged to the same domain.

SPF checked the envelope. Not the sender shown to the recipient.

Do you see the problem now?

DKIM: The Wax Seal

Definition: DKIM (DomainKeys Identified Mail) adds a cryptographic signature to an email, which receivers verify using a public key published in DNS.

In other words: DKIM is a wax seal on the letter.

The sending server signs the message with a private key. The receiving server fetches the matching public key from DNS and verifies the signature.

If the signature is valid, two things are proven:

• The message really was signed by that domain

• The content was not modified in transit

That second part matters. Change one character in a signed email, and the seal breaks.

So DKIM solves spoofing, right?

Still no.

DKIM proves an email was signed by SOME domain. Not by the domain shown in the From header.

An attacker can sign an email with a perfectly valid DKIM signature from evil.com, while the From header says your bank.

Valid seal. Wrong sender.

Are you seeing the pattern?

Both SPF and DKIM can pass while the From header, the only thing a human ever looks at, is completely fake. If this surprised you, give this article a like. This is the part most people get wrong.

DMARC: The Enforcer

Definition: DMARC (Domain-based Message Authentication, Reporting and Conformance) requires that SPF or DKIM align with the visible From header, and tells receivers what to do when they do not.

DMARC adds the one check that was missing the whole time. It is called alignment:

• SPF passed? Fine. Does the envelope domain match the From header domain?

• DKIM passed? Fine. Does the signing domain match the From header domain?

At least one of them must align. Otherwise, DMARC fails.

So the full system works like this:

SPF   → WHO is allowed to send (the guest list)
DKIM  → Was the message signed and unmodified (the wax seal)
DMARC → Does any of it match the sender you SEE (the enforcer)

Try it yourself, right now

Two commands. On Windows, use nslookup -type=TXT instead of dig.

dig +short TXT decodedsecurity.com
dig +short TXT _dmarc.decodedsecurity.com

Mine returns:

v=spf1 include:zohomail.eu include:eu.zcsend.net include:_spf.mlsend.com ~all
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:...

Three approved senders, and a policy that sends anything unaligned to spam.

Now run it on your employer’s domain. Or your bank’s.

Check the p= value: none means watching without stopping, quarantine means spam, reject means the email never reaches the inbox.

What did you find? Drop the domain and its policy in the comments. I read every response!

Conclusion

Congratulations! You now understand something most IT professionals only pretend to.

You know why spoofing is possible, what each of the three mechanisms actually verifies, and why only DMARC alignment protects the address a human sees.

Next time someone tells you “we have SPF, we are safe,” you will know exactly what question to ask them.

Thank you for reading Decoded Security!

Erich

Where To Go Next

Email security builds directly on DNS and phishing fundamentals:

👉 This Is How I Explain DNS To Beginners

👉 How Phishing Works in 5 Steps

Want a clear 90-day plan for turning knowledge like this into a job offer?

90-day Cybersecurity Job Blueprint

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

Not your screen. Not your files by default. But the same local space.

It can see that your laptop exists.

It can see your phone, your printer, your NAS, your tablet, your camera, and every other device that answers on your home network.

That matters because smart devices are often the least trustworthy things we connect.

They are cheap. They are rarely updated. They run software you cannot inspect.

Some stop receiving security fixes after a few years. Some never receive meaningful fixes at all.

And if one of them is vulnerable, your firewall can be working perfectly, and you can still have a problem.

Because once a device is already inside your home network, the question changes.

It is no longer only: Can an attacker get in from the internet?

It becomes: What can this device reach now that it is already inside?

That is why smart devices belong on a separate network.

In this article, I will explain:

• Why smart devices are risky even when your firewall works

• How a compromised device can look around your home network

• Why a separate VLAN or guest network limit the damage

The Real Problem Is Trust

Most people build a home network like this:

Laptop, phone, printer, smart TV, security camera, thermostat, smart speaker, gaming console, and maybe a NAS all connected to the same Wi-Fi.

It feels normal because everything works.

Your phone can cast to the TV. Your laptop can print. Your devices can reach the internet. Nothing looks dangerous.

But from a security point of view, this is a trust problem.

Your laptop may have full-disk encryption, regular updates, a modern browser, and security controls.

Your smart TV may be running an old operating system, filled with vendor apps, talking to multiple cloud services, and receiving updates on a schedule you do not control.

Yet on a typical home network, both devices are treated as peers.

They are in the same room. They can discover each other. They can attempt to talk to each other.

They are trusted far more than they deserve.

The danger is not that every smart device is malicious. The danger is that many of them are weak, exposed, forgotten, or poorly maintained.

Attackers love weak devices because weak devices make good footholds.

A firewall protects you from the outside. It does nothing about the threats you plug in yourself.

Learn more about firewalls

What Happens If a Smart Device Is Compromised

Imagine your smart TV has a vulnerability.

Maybe it is an old app. Maybe it is outdated firmware. Maybe the vendor abandoned updates. Maybe an attacker finds a bug in a service the TV exposes locally.

Once that device is compromised, the attacker does not need to break through your firewall again.

They are already operating from inside your network.

From there, the device can ask simple questions:

• Who else is here?

• What addresses are alive?

• Which devices have open services?

This is not magic. It is normal networking.

• ARP requests can reveal devices on the local network.

• Ping sweeps can identify which addresses respond.

• Port scans can check what services are exposed.

Port 445 might suggest file sharing. Port 22 might suggest remote access. A web interface might reveal a printer, router, camera, NAS, or admin panel.

None of this requires the attacker to defeat the internet-facing firewall, because the traffic is happening locally.

The compromised device is not attacking from outside your house.

It is attacking from the couch.

Do you connect untrusted device to a separate VLAN? Let me know in the comments!

Leave a comment

And then it phones home

After a device sees what is around it, sending information out is often easy.

Most home networks allow outbound internet traffic by default. They have to.

Your devices need to stream video, check for updates, sync data, load websites, and talk to cloud services.

Much of that traffic uses HTTPS over port 443, the same encrypted channel your browser uses.

So if a compromised smart TV sends data to a remote server, the firewall may see encrypted outbound traffic to the internet and allow it.

The Fix: Put Smart Devices on Their Own VLAN

The principle is simple:

Your smart devices should be allowed to reach the internet.

They should not automatically be allowed to reach your laptop, phone, NAS, work machine, or private devices.

That is what a VLAN gives you.

A VLAN is a way to split one physical network into separate logical networks. Same home. Separate rooms.

For example:

• Main network: laptops, phones, work devices, NAS

• IoT network: TV, cameras, speakers, smart plugs, thermostat, vacuum, doorbell

• Guest network: visitors and temporary devices

When your smart TV is on the IoT network, it can still stream Netflix and download updates.

But if it tries to scan your main network, it should hit a wall.

Your laptop is no longer standing next to it. Your NAS is no longer one open door away.

That is the whole point of segmentation. You assume some devices are more likely to be vulnerable, so you limit what they can reach before anything bad happens.

Security is not only about keeping attackers out.

It is also about reducing what they can do if they get in.

If You Do Not Have VLANs, Use a Guest Network

You do not need enterprise equipment to start.

Many home routers have a guest network feature. In many cases, a guest network is a simplified form of isolation: devices on the guest network can reach the internet, but cannot freely access devices on your main network.

That is good enough for many homes.

Move these devices first:

• Smart TVs

• Security cameras

• Smart speakers

• Smart plugs

• Doorbells

• Robot vacuums

• Thermostats

• Cheap or old printers

• Unknown devices you cannot confidently update

Keep your trusted network for the devices that matter most:

• Laptop

• Phone

• Work devices

• NAS

• Admin devices used to manage your router

If you have a router that supports real VLANs, even better. Create a dedicated IoT VLAN and add firewall rules that allow IoT devices to reach the internet, but block them from initiating connections to your main network.

You can still create exceptions where needed.

For example, you might allow your phone to control the TV, or allow a specific printer connection from your laptop. The key is that these should be deliberate exceptions, not default trust for every device.

Do you want a step by step manual how to set-up a separate VLAN?

Let me know in the comments!

Conclusion

The goal of this article wasn’t to scare you. It was to show you that a firewall doesn’t solve everything.

And unlike the big companies, you can’t hire experts to design your network, and attackers know it.

Starting today, be careful about what you connect to your main network.

Trust me, even the simplest adjustments make the attackers move to an easier target, because there is an infinite number of them.

Do this tonight: scan your network, count your devices, and move your smart devices to a guest network or IoT VLAN.

Thank you for reading Decoded Security.
See you next time!

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

Even before I could have possibly known if it’s the right direction for me.

If you are considering cybersecurity right now, you might be asking yourself:

“Is it too late?”

“Is the field already too crowded?”

“Do I need to be deeply technical?”

“Which certification should I start with?”

Here is my honest answer after working in cybersecurity, earning a Master’s degree in the field, and sitting on both sides of the hiring table:

Cybersecurity is still one of the best career choices you can make.

But only if you stop learning randomly and choose the right path for your background.

The good news? I will help you with that!

1. The Demand Is Real - And the Bar Is Lower Than You Think

Everyone says cybersecurity has millions of unfilled jobs. You have probably seen that statistic so many times it stopped meaning anything.

So let me tell you what I actually see from the hiring side.

Cybersecurity is still a very new field.

Until a couple of years ago, most people only specialized in cybersecurity because someone forced them.

A company needed a security team and moved people across from IT. A developer got assigned to a security project. A compliance person ended up owning risk management by accident.

Very few people on the job market today started their career intentionally as a cybersecurity specialist.

And that changes everything.

For almost any cybersecurity role, it is genuinely difficult to find a candidate with even a minimum skill set. Not an expert. A minimum skill set.

The bar is not as high as the job postings make it look.

Many companies are willing to hire someone and train them. Senior cybersecurity professionals are either too expensive or simply impossible to find. Organizations would rather invest in someone with potential and foundational knowledge than leave a critical role empty for six months.

I have a Master’s degree in cybersecurity, and I am still telling you this.

Not because the degree does not matter. But because the field is so undersupplied, people with the right fundamentals and the right direction are genuinely competitive right now.

If you have the fundamentals, you are already ahead of most candidates applying for the same role.

Did this surprise you? Give me a like so I know I am not alone!

2. The Complexity Is the Point

Most cybersecurity content tries to reassure you that it is not as complicated as it looks.

I am going to tell you the opposite.

It is complex. And that is exactly why it is worth it.

The most important mindset shift you go through when you enter this field is realizing how broad it actually is.

Cybersecurity goes from physical security to software development. From network security to supply chain management. From technical vulnerability assessments to overall business risk management.

Every level of every company is affected by this field.

The person designing the office floor plan needs to think about tailgating attacks.

The developer writing the API needs to think about authentication.

The CFO approving the budget needs to understand what a ransomware attack would cost the business.

That breadth is not a burden. It is a career advantage.

It means you never stop learning. It means your knowledge stays relevant because the field keeps evolving. It means you can move between technical and business roles in a way that almost no other career allows.

Most fields reward specialists who go very deep in one direction.

Cybersecurity rewards people who understand how everything connects.

And once you see it that way, the complexity stops being intimidating.

It becomes the reason you chose this field in the first place.

3. There Is a Path for Every Background

When most people think about cybersecurity careers, they picture one thing.

Someone in a dark room finding vulnerabilities. A penetration tester. A hacker.

That is one path out of five.

And right now, from where I sit, the most underrated and fastest growing paths are GRC and privacy protection.

Here is why.

Everyone is talking about AI.

And yes, AI tools are transforming how security teams work. But the biggest actual increase in demand I am seeing is regulatory. The number of compliance requirements placed on companies from a cybersecurity perspective has grown dramatically. GDPR. NIS2. DORA. AI Act. The list keeps growing.

And AI has made privacy protection significantly harder than it used to be. Organizations are collecting more data. Processing it in more places. Sharing it with more vendors. Ensuring that data is handled correctly is now a genuinely complex operational challenge.

The budgets often do not reflect this yet. But the demand does.

And that gap creates opportunity for people who position themselves in this space now rather than in two years when everyone else catches up.

Here is the full picture of the five paths available to you:

The most important decision you make early in a cybersecurity career is not which certification to get.

It is the path that fits your background.

Get that right and everything else - certifications, skills, entry roles, timeline - becomes much clearer.

Which of the five paths resonates most with you? Comment below - I read every response.

Or better yet: take the free diagnostic and find out which path actually fits your background in just couple of minutes.

Take a Career Quiz

Where Should You Start?

I am not saying cybersecurity is for everyone. It is a demanding field, and if you’re not going to take it seriously, it won’t work.

However, if you are convinced cybersecurity is for you but unsure where to begin, Decoded Security is here to help!

Step 1: Find your path

First, I prepared a quiz to help you figure out which cybersecurity area suits you best. Based on your goals, your interests, and your background.

It will take you about 10 minutes, and as a bonus, you will get a personalized study plan that will help you get started. There is no sign-up, no email required.

You just click the button and take the quiz.

Take a Career Quiz

Step 2: Build your foundation

This is something I am really proud of. Over the years, I put together the top 10 Cybersecurity concepts that you need to know regardless of the area of cybersecurity you choose.

And to make it even better for you, I prepare countless quizzes and challenges for you, which can help you actually apply the concepts rather than just read them!

So, if you will read only one guide from Decoded Security, choose that one.

1200+ downloads, 5-star rating! Numbers that I am actually proud of! If this guide helped you too, let me know in the comments and help me share it to more people.

Download for Free

Step 3: Read the roadmap

And if you’ve already covered the basics and you have at least some idea what area of cybersecurity is interesting for you, it’s time for you to work on your goals!

The Roadmap page tells you how to use the Decoded Security resources and what the whole environment offers.

Articles, community, and, of course, training for specific certification exams.

Decoded Security Roadmap

Final Thought

If I had to start over, I would choose cybersecurity again.

Not because it is easy.

Not because jobs magically appear after one certification.

And not because every beginner should follow the same path.

I would choose it again because the field is still growing, the demand is real, and there are more ways to build a cybersecurity career than most beginners realize.

The opportunity is real.

The only thing that separates the people who break in from the people who stay stuck is having a clear starting point.

This is yours, and I am here to help you start your career!

Talk to you soon,
Erich
Decoded Security!

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

Then you show them how much that costs.

That’s why I told you about the recovery metrics. MTD, RTO, WRT, RPO. The numbers that tell you what the business actually needs before you touch a single backup tool.

This week, we finish the job and learn about the backup strategies available and their benefits and drawbacks.

CISSP, CC, and Security+ Domain 7 essential. This also happens to be one of the most common interview questions for SOC and GRC roles, so pay attention.

What you’ll learn in this article:

• The real difference between full, incremental, and differential backups (and why restore time is the part everyone forgets)

• The enterprise techniques used for database and always-on systems: electronic vaulting, remote journaling, remote mirroring

• The 3-2-1 rule, and the modern version that actually accounts for ransomware

The Three Backup Methods

Every certification exam expects you to know these. More importantly, so does every hiring manager who’s ever had to explain a bad restore to their boss.

But first, what is a backup method?

A backup method is just the rule that decides what gets copied and how often.

Not where it’s stored, not how fast you can restore it, just the logic behind what data actually gets captured each time a backup runs.

Let’s take a look at what methods are out there.

Do you think you understand backup methods already? Let’s find out!

Take a Free Quiz

1. Full Backup

This one is actually the easiest to understand. You take all the data and back it up. Everything, without a difference. Every file, every byte, every time.

It’s the safest method, but it requires the most resources. And as you know, we always have to balance cost and benefits.

• Frequency: Usually weekly or monthly. It’s big, and it’s slow.

• Restore: One backup set. That’s it. Nothing else needed.

• Trade-off: Simple to restore, expensive to run constantly

2. Incremental Backup

Copies only what changed since the last backup, whether that last backup was a full or another incremental.

• Frequency: Daily, sometimes hourly. Small and fast.

• Restore: You need the last full backup, plus every single incremental since then, applied in order.

• Trade-off: Cheapest to run. Riskiest and slowest to restore.

Remeber: One corrupted incremental in the chain, and everything after it is unusable.

3. Differential Backup

Copies everything that changed since the last full backup (not the last backup, the last full).

• Frequency: More often than full, less often than incremental.

• Restore: Last full backup, plus the most recent differential. That’s the whole chain.

• Trade-off: Bigger than incrementals over time, but restore is fast and doesn’t depend on a fragile chain.

Exam trap: Incremental backs up since the last backup of any kind. Differential backs up since the last full backup only. Mix those two up and you will get this question wrong.

When You’re Backing Up More Than Files

Full, incremental, and differential work fine for file servers. But what happens when the system can’t afford to be down long enough for a traditional restore?

Databases, transaction systems, anything close to real-time.

That’s where three enterprise techniques come in. You’ll see all three on the CISSP exam, usually as a “which one fits this scenario” question.

Electronic Vaulting

Bulk data gets transferred automatically to an offsite location on a schedule. Think of it as a scheduled, automated backup job over a network instead of a tape driving to a warehouse.

The catch: it moves in batches. If disaster hits between transfers, you lose whatever wasn’t sent yet.

Did this article help you understand how data security actually works? Give this article a like and help other people find it.

Remote Journaling

Instead of sending bulk data on a schedule, this transmits the actual transaction logs continuously, in near real time. That gets you point-in-time recovery instead of “whatever we captured at the last batch.”

Remote Mirroring

The most expensive, most complete option. A live, functioning duplicate of your system at another site, updated synchronously or asynchronously.

If your RPO is zero, this is the only option on this list that gets you there. Nothing else does.

Your RPO from last week’s article is what tells you which one you actually need. It is no surprise that the smaller is your RPO, the more expensive it gets.

The 3-2-1 Rule

The 3-2-1 rule is the golden standard, and it's not just theory. It's the baseline that regulations and compliance frameworks expect you to meet, and it's the one backup concept that comes up in almost every audit, exam, and interview.

Luckily for you, it’s actually quite simple!

3-2-1 rule:

• 3 copies of your data (the original plus two backups)

• 2 different types of media (so one failure mode doesn’t take out everything)

• 1 copy stored offsite (so a fire, flood, or local disaster doesn’t take out everything either)

Here’s why each number exists, not just what it is:

• One copy is a single point of failure. A bad drive, and it’s gone.

• Two copies on the same media type share the same failure mode. A firmware bug or a ransomware strain that targets the media wipes both.

• Even three copies fail together if they’re all in the same building. A fire, a flood, or a break-in takes out everything at once.

3-2-1 forces you to remove all three failure points in one move. That's why it stuck around this long, and why it's still the first answer expected in any conversation about backup strategy.

If you’ve made it this far, you now understand backup strategy better than most people who’ve been in IT for years.

Give this a like, it tells me to keep writing the technical deep dives!

Bringing It All Together

Congratulations. If you’re reading this, I am proud of you!

As a reward, I created a short summary to help you remember the most important parts of this article.

1. Start with your RPO and RTO from last week. They’re not optional context, they’re the whole basis for every decision below.

2. Choose your method (full, incremental, differential) based on how much data changes and how fast you need to restore it.

3. If the system is transactional or can’t tolerate any real data loss, layer in journaling or mirroring instead of relying on the method alone.

4. Test it. Untested backups fail exactly when you need them most, which is the entire plot of the story I opened this article with.

And that’s all for today!

Thank you for reading Decoded Security, and see you next week!

Here is what to read next

• RTO, RPO, MTD, WRT Explained

• Recovery Site Strategies

• Testing Disaster Recovery Plans: Why “Having a Plan” Isn’t Enough to Pass CC or CISSP

Frequently Asked Questions

What’s the difference between incremental and differential backups? Incremental backs up everything changed since the last backup of any type. Differential backs up everything changed since the last full backup. Incremental is smaller and faster to run, but the restore depends on every backup in the chain. Differential is bigger over time, but restore only needs the last full plus the latest differential.

Is tape backup obsolete? Not entirely, it still appears in long-term archival use cases and on exams, but disk-to-disk and cloud repositories have replaced it as the default for anything needing a fast restore.

What is the 3-2-1 rule in backup strategy? Three copies of your data, on two different types of media, with one copy stored offsite. It’s a baseline standard, though many organizations now extend it to 3-2-1-1-0 to account for ransomware and to require verified, error-free recovery testing.

What’s the difference between remote journaling and remote mirroring? Remote journaling transmits transaction logs continuously for point-in-time recovery. Remote mirroring maintains a full, live duplicate of the system at another location. Mirroring is faster to recover from but far more expensive.

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!

‼️ Warning: CC, Security+, and CISSP relevant topic!

If you are starting out in cybersecurity, you have probably heard that networking is the foundation.

That is true.

But here is what nobody tells you: knowing the attacks by name is worthless.

Exams describe scenarios. Interviewers describe situations. Log files show patterns. None of them comes with labels.

By the end of this article, you should be able to recognize the top 5 most common network attacks and how to prevent them.

In this article, I will:

• Break down the 5 network attacks you will meet in exams, interviews, and real incident logs

• Show you the one detail that identifies each attack, whether it appears in a scenario question or a log file

• Give you the countermeasure for each one, because recognizing an attack is only half the job

First, Understand the Family: DoS vs. DDoS

Every attack in this article is a denial-of-service attack. The goal is not to steal data. The goal is to make a system unavailable to the people who need it.

There are two main types:

• DoS (Denial of Service): One attacker, one source, flooding a target until it stops responding.

• DDoS (Distributed Denial of Service): The same idea, but the traffic comes from thousands of sources at once. Much harder to block, because there is no single IP to filter.

Now, let’s get into the 5 attacks.

Do you find this article useful? Give it a like and help more people find it!

1. SYN Flood: The Handshake That Never Finishes

This is the most important attack on the list. If you learn only one, learn this one.

Normal TCP connections start with a three-way handshake. The client says SYN. The server answers SYN-ACK. The client confirms with ACK. Connection established.

A SYN flood abuses the politeness of that process.

The attacker sends thousands of SYN packets and never sends the final ACK.

The server, being polite, holds a spot open for each half-finished handshake and waits. And waits.

Eventually, the table of half-open connections is full, and legitimate users get turned away.

The analogy: Imagine a restaurant where callers keep making reservations and never show up. Every table is “reserved.” Real customers stand outside a half-empty restaurant that they cannot enter.

Countermeasure: SYN cookies (the server does not commit resources until the handshake completes), reduced connection timeouts, and rate limiting.

If that finally made the three-way handshake click, give it a like! It tells me these breakdowns are worth writing.

2. Smurf Attack: Turning a Network Against You

The attacker sends ICMP echo requests (pings) to a network’s broadcast address. But here is the trick: the source IP is spoofed to be the victim’s address.

Every device on that network receives the ping and politely replies. To whom? To the victim. One packet from the attacker becomes hundreds of replies flooding the target.

The analogy: Someone sends a letter to an entire apartment building saying “please call this number immediately” and writes your phone number on it. You did nothing, and now your phone will not stop ringing.

Scenario keywords: ICMP, broadcast address, spoofed source.

Cousin to remember: The Fraggle attack is the exact same play, but with UDP traffic instead of ICMP. Exams love testing whether you know the difference. ICMP means Smurf. UDP means Fraggle. That single word decides the question.

Countermeasures: Disable IP-directed broadcasts on routers, and configure devices to ignore ICMP requests sent to broadcast addresses.

Reading an article is one thing, actually understand the concept the other.
Test your knowledge and make sure you can recognize the most common network attacks!

Network attacks - QUIZ

3. Ping of Death: One Packet, One Crash

Not every DoS attack needs a flood. Sometimes one malformed packet is enough.

The Ping of Death sends an oversized ICMP echo request that exceeds the system's maximum. Vulnerable systems try to process it, overflow their buffer, and crash.

The analogy: Mailing someone a package too big to fit through their door, and the door frame collapses when they try to force it through.

Scenario keyword: oversized packet.

Countermeasures: Patching. This attack exploits a bug, not a design flaw, so modern patched systems are largely immune.

4. Teardrop Attack: Fragments That Do Not Fit

Large packets get split into fragments for transmission and reassembled at the destination. The Teardrop attack sends fragments with overlapping offsets, so they cannot be reassembled correctly.

A vulnerable system tries anyway, gets confused by the overlap, and crashes.

The analogy: A jigsaw puzzle where the pieces are cut to overlap each other. The picture is impossible to assemble, but the system keeps trying until it breaks.

Scenario keywords: fragmentation, overlapping fragments, reassembly.

Countermeasures: Patching again. Like Ping of Death, this exploits a bug in TCP/IP reassembly. Firewalls that drop malformed fragments also help.

5. Land Attack: The Packet Addressed to Itself

The attacker crafts a packet where the source IP and port are identical to the destination IP and port. The victim machine receives a packet that appears to come from itself, addressed to itself.

A vulnerable TCP stack processes it, replies to itself, processes the reply, and loops until it freezes.

The analogy: Mailing yourself a letter that says “reply to this letter.” Forever.

Scenario keyword: identical source and destination IP and port. If you see that phrase, the answer is Land attack. Nothing else looks like this.

Countermeasures: Modern systems drop these packets automatically. Firewalls with ingress filtering block spoofed packets claiming to come from inside your own network.

Do you think you can recognize the network attacks now? Let’s find out!
Take the quiz and drop your score below!

Network attacks - quiz

How To Actually Remember These

Do not memorize definitions. Memorize the one detail that makes each attack unique:

• SYN Flood = half-open connections

• Smurf = ICMP to broadcast address (Fraggle = same but UDP)

• Ping of Death = one oversized packet

• Teardrop = overlapping fragments

• Land = source equals destination

Exam scenarios are built around exactly these details. Spot the detail, and the question answers itself.

If you are screenshotting this list, do me one favor first: hit like so the next person studying for their exam actually finds it.

Key Takeaways

Here is what I want you to remember:

• Denial of service is about availability, not data theft. That is the “A” in the CIA triad.

• Understanding network protocols is the first step in understanding network attacks

• DDoS is harder to stop than DoS because there is no single source to block.

• Always act proactively, not reactively. Prepare for these attacks BEFORE they happen, not after.

Great! If you understand these 5 attacks, you are already ahead of most people who claim to be cybersecurity experts. But before you go, I have prepared something else for you!

Test Yourself

Here is a scenario, exam style:

A server becomes unresponsive. Logs show a massive number of connection attempts, each stuck waiting for a final acknowledgment that never arrives.

Which attack is this, and which countermeasure would you deploy first?

Comment your answer below. I read every one, and I will tell you if your reasoning would hold up on exam day.

And if you want to really test your understanding of network attacks, I prepared a CISSP-like cybersecurity quiz for you!

Free Quiz

Take it and drop your score in the comments. I read every single one of the comments!

Leave a comment

‼️ Continue learning ‼️

Here is the truth most beginners miss:

Networking is not one topic in cybersecurity. It is the ground everything else stands on. Firewalls, attacks, monitoring, and incident response. None of it makes sense until the network underneath makes sense.

You just learned 5 attacks. Here is how to build on that, in order:

• Top 5 most important network protocols for cybersecurity beginners

• What are the things that keep our networks alive?

• 7 Networking Questions That Instantly Expose Beginners in Cybersecurity Interviews

• Wi-Fi Security for the CISSP candidates: Here Is What Actually Matters

• The Complete Guide to Firewall Types: From Packet Filters to Next-Gen

And if you are still asking the real question, “out of everything in cybersecurity, what actually matters?”, I answered it in one place.

I put together a free 80-page guide covering the 10 cybersecurity concepts behind 90% of entry-level interview questions. Download it here: Top 10 Cybersecurity Concepts

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!