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!

I spent weeks deep-diving into various networking topics before I figured out what the exam actually tests.

I wasted weeks of valuable time learning something that doesn’t matter for the exam, now you don’t have to, because you have this article.

Keep in mind that the CISSP is a security management exam.

Domain 4 doesn’t test whether you can configure a network.

It tests whether you understand which protocols are secure, which are broken, and which one to choose in a given scenario.

Once I figured that out, everything got easier.

Wi-Fi security is a perfect example.

You don’t need to understand every technical detail of how WPA3 works under the hood. You need to know the progression, the tradeoffs, and when to use what.

If you read this article, you’ll know exactly what the CISSP expects on Wi-Fi security.

You’ll learn:

• How Wi-Fi security evolved from WEP to WPA3

• The difference between TKIP and CCMP

• When to use PSK, SAE, or Enterprise mode

• How to answer scenario-based CISSP questions on wireless security

What Is Wi-Fi Security? (SSID, Encryption, Authentication)

Here is the story that the CISSP exam expects you to know.

Wi-Fi networks are identified by their SSID, the name you see when connecting. It can be up to 32 characters, like “HomeWifi” or “Airport_Guest.”

Once your device finds the network, two things need to happen: authentication and encryption. The protocol the network runs determines how both of those work.

That’s what we’re focused on here.

In other words, every Wi-Fi connection has two separate jobs:

1. Encryption: Encrypt the data traveling between your device and the access point so nobody can read it in transit.

2. Authentication: Proves that your device is allowed to join the network in the first place.

These are handled separately. And that’s exactly why WPA2 or WPA3 alone doesn’t tell you the full picture.

WPA2 and WPA3 define the encryption standard. PSK, SAE, and Enterprise define the authentication method.

This is very important, and you need to be aware of this general concept.

Think of it like a building:

• WPA2/WPA3 is the type of lock on the door.

• PSK, SAE, and Enterprise are the different ways people prove they’re allowed inside.

So the complete description of any Wi-Fi network is always the combination of both.

Here are the possible combinations:

The CISSP will give you a scenario and ask you to pick the right combination. Keep this table in your head.

WEP vs WPA vs WPA2 vs WPA3: What's the Difference?

Each standard replaced the one before it because the previous one had a serious security flaw.

You are expected to understand these flaws and choose the right option in the given scenario.

WEP (Wired Equivalent Privacy)

WEP was the original standard. The goal was to give wireless networks the same security as wired ones. It failed.

Attackers could crack WEP in minutes using freely available tools. It was deprecated in 2004. If you see WEP in a scenario, treat it as no security at all.

CISSP Note: It is never a good idea to use WEP.

WPA (Wi-Fi Protected Access)

WPA replaced WEP as an emergency fix.

It uses TKIP encryption, which was designed to run on existing hardware without requiring replacements.

Better than WEP, but still a patch. Now considered weak.

CISSP note: Used in scenarios where you have no possiblity to replace HW.

WPA2

WPA2 was the real upgrade.

It replaced TKIP with CCMP, which uses AES-128 encryption.

Strong, widely supported, and still running on the majority of networks today.

WPA2 is the minimum acceptable standard.

WPA3

WPA3 is the current best practice. It uses an improved version of CCMP and replaces the older PSK handshake with SAE (Simultaneous Authentication of Equals).

SAE uses the Dragonfly Key Exchange, meaning both parties prove they know the password without ever sending it over the network.

This eliminates offline dictionary attacks and adds forward secrecy, meaning a compromised session key doesn’t expose past sessions.

CISSP shortcut: WEP (broken) → WPA (weak) → WPA2 (current standard) → WPA3. Each replaced the one before it.

PSK, SAE, and Enterprise: Choosing the Right Authentication Method

Now that you understand the encryption standards, here’s how the authentication methods work and when to use each one.

WPA2-PSK (Personal Mode)

PSK stands for Pre-Shared Key. Everyone uses the same shared password to connect.

Simple and widely supported.

But there’s no individual accountability, and a weak password is vulnerable to offline dictionary attacks.

An attacker captures the handshake and runs password guesses against it offline, with no limit and no detection.

CISSP note: Use it only for home-network scenarios and only if there are compatibility limitations in the given scenario.

WPA3-SAE (Personal Mode, Upgraded)

SAE replaces PSK in WPA3-Personal.

Even if an attacker captures the handshake, they can’t run offline attacks against it.

Forward secrecy means past sessions stay protected even if a key is later compromised. No user accounts needed.

Use it for: Secure guest Wi-Fi or personal networks where you want real protection without managing individual credentials.

WPA2/3-Enterprise (802.1X Authentication)

Before explaining this one: 802.1X is not a Wi-Fi protocol. It’s an authentication framework. Here’s how it works:

1. Your device connects to the network

2. The access point blocks all traffic and asks for credentials

3. Your device sends them to a RADIUS server, a backend authentication server

4. The RADIUS server verifies them and grants or denies access

Every user has their own credentials. No shared passwords. Full accountability.

The tradeoff: It requires infrastructure. A RADIUS server, user accounts, and backend configuration. That overhead makes no sense for a guest network. It makes complete sense for a corporate one.

CISSP note: use it for corporate networks where individual accountability is required.

MAC Filtering and Captive Portals: Do They Actually Secure Wi-Fi?

MAC Filtering

Whitelists specific device MAC addresses. If your address isn’t on the list, you can’t connect.

Sounds useful. The problem: MAC addresses travel in cleartext even inside WPA2. Any attacker on the network can read a valid MAC address and spoof it in under a minute.

CISSP note: Layer 2 control. Trivial to bypass. Never a substitute for encryption.

Captive Portals

The page that appears at hotels and airports before you get internet access. You accept terms, authenticate, or pay.

Captive portals sit in front of internet access, not in front of the wireless connection. The Wi-Fi traffic itself is not protected by the portal. If the underlying encryption is weak, traffic is still exposed.

CISSP note: Captive portals = access control. Not confidentiality. Not integrity. Access control only. If a scenario asks how to control who can access the internet on a guest network, a captive portal is a valid option.

Conclusion

Let me give you a couple of shortcuts that served me well during the exam:

• Guest Wi-Fi, no user accounts needed: WPA3-SAE

• Corporate network, individual accountability required: Enterprise/802.1X

• If you need contact information on people who use your network, use the captive portal

• WEP or open network anywhere in the scenario - INSECURE

That’s everything the CISSP expects you to know about Wi-Fi security.

With the knowledge in this article, you will be able to answer most questions on Wifi security without spending weeks going through advanced networking topics.

Keep Learning: Related Articles

If Domain 4 still feels overwhelming, these will help fill in the gaps.

Start Here: The Decoded Security Roadmap
Not sure where to begin? This is the map. It breaks down exactly what to study and in what order, whether you’re going for CISSP, Security+, or a GRC role.

7 Networking Questions That Instantly Reveal Skill Gaps
Before you go deeper into Wi-Fi security, make sure your networking fundamentals actually hold up. These 7 questions show you exactly where the gaps are.

This Is How I Explain DNS to Beginners
Wi-Fi gets your device on the network. DNS is what happens next. If you’ve never had DNS explained in a way that actually clicks, start here.

This Is How I Explain VPNs to Beginners
Wi-Fi security protects the connection to the access point. A VPN protects what happens after that. Here’s the difference, explained without the jargon.

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
Quiz platform: Test Your Knowledge

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 had no name, no resources, no subscribers, just me preparing for the CISSP exam with a decision to document my journey.

I still remember when I published my first article:

Looking back, it’s terrible. I know a lot about encryption, but I knew nothing about writing a newsletter.

Despite that, I will never delete this article, because it reminds me how much I have improved over time.

As of today, I have 1,304 subscribers, which is far more than I could imagine at the beginning. After all, I had around 30 subscribers after 2 months of publishing.

And I like to think that my articles have gotten a lot better, but that isn’t where I stopped.

What started as a simple newsletter with 1 post a week became a complex environment for people who want to build a career in cybersecurity and pass cybersecurity exams such as CC, CISSP, or Security+.

This is what Decoded Security offers now:

• Quiz platform: Just reading about some concept doesn’t mean you actually understand it. That’s why I publish CISSP-like quizzes that allow you to verify your knowledge.

• Personalized study plan: This allows you to create a plan tailored to your background and goals.

• Gumroad - Guides, Checklists, and other Study resources: Over time, I have published many guides. Here are the most successful ones.

  • Cybersecurity Fundamentals: The 10 Concepts That Get You Through 90% of Interviews (1,145 downloads, 5-star rating)

  • The 90-Day Cybersecurity Job Blueprint (49 sales, 4.8 star rating)

• Decoded Security Certification Hub: Study resources and tips categorized based on different cybersecurity exams: CC, Security+, CISSP.

• Practical labs for people who want to go beyond theory

• And most importantly, a community of people working toward the same goal

Biggest achievements - Decoded Security in numbers

Maybe you can tell that I am the kind of guy who loves stats and numbers.

So let’s take a look.

Here are a few milestones I’m especially proud of:

• Grew Decoded Security from 0 to 1,304 subscribers

• Decoded Security on Facebook - 404 followers

• Decoded Security on Threads - 566 followers

• Decoded Security on Instagram - 192 followers

• Erich Winkler on LinkedIn - 739 followers

• Reached 1,145 downloads for Top 10 Cybersecurity Fundamentals

• Sold 49 copies of the 90-Day Cybersecurity Job Blueprint

But the biggest achievement is not really the numbers. ( Even though I love them)

It’s seeing people use these resources to understand difficult concepts, prepare for exams, make career decisions, and feel less lost in cybersecurity.

Thank you for reading Decoded Security

I appreciate every single one of you for reading Decoded Security and reaching out to me with interesting questions.

However, I would especially like to thank some of the people I “met” on this journey who really helped me grow and improve my newsletter.

Since a simple thank you won’t help them much, I will also share their newsletter, which I find to be one of the best I have found on this platform.

• - One of the most experienced AI and Cybersecurity experts I have had a chance to collaborate with. We had 300 subscribers at the same time.
  Well, got ahead a little! This is my thank-you for our previous collaboration, and I hope we will work on another project together again!

  ToxSec - AI and Cybersecurity

  Security for a world run by machines that lie.

• - Sam runs one of the most interesting and fastest-growing AI newsletters out there. And I can tell it’s no coincidence. If you want a fresh perspective on how to use AI properly, Slow AI is for you!

  Slow AI

  Knowing when to use AI and when to leave it the hell alone.

  By Dr Sam Illingworth

• - Mohib is with me here from the very beginning. He helped me grow and commented on my posts when no one else did. We have had many interesting discussions. Thank you!

  SK NEXUS

  Breaking down Tech for the Mango Man (Aam Aadmi/Regular Person)

  By Saqib Tahir

• - Chris is the guy from practice. While I was describing high-level concepts from textbooks, he always provided insights on how things really work from his experience. If you’re curious about protecting business assets and your privacy, I can only recommend his newsletter!

Stopping the hackers by making cyber security simple

Helping small business owners "Stop the hackers" and be safer online with easy to understand and implement cyber security advice. For entrepreneurs, the self employed, sole traders, and limited companies with one to ten employees.

By Chris #TheAntiVirusGuy Moody

What Comes Next

Decoded Security is still just getting started.

Last year, I was building the concept and the brand.

This year, I’m building the system.

The goal is simple:

To make Decoded Security one of the best places for people who want to understand cybersecurity, prepare for certification exams, and build a real career in the field.

That means more practical explanations of cybersecurity concepts.

More exam-focused resources for CC, Security+, and CISSP.

More quizzes, study plans, labs, and career-focused material.

And more content that connects textbook knowledge with real-world security work.

Because passing an exam is important.

But understanding how to think like a security professional is what actually changes your career.

If you are not sure about your next step in cybersecurity, Decoded Security is here to help.

Thank you for being part of the first year.

The next one will be even better.

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

Let’s learn and grow together!

A ransomware attack hits on a Thursday night. The team triggers recovery. The backup exists. It was running for months. And then someone realizes: the backup was pointing to the same network share that got encrypted.

Three months of data. Gone.

Simply because of a bad backup strategy.

But how did that happen?

Many people think the hard part is knowing how different recovery strategies work.

But that’s actually quite simple. You can learn that in an hour.

The catch is understanding your business well enough to choose the right strategy.

The method doesn’t matter if the requirements are wrong.

In this article, I will walk you through the entire process, from the very beginning to choosing the right backup strategy that fulfills the business requirements at the least cost.

Note: Yes, cybersecurity is all about money. Deal with it :)

What you’ll learn in this article:

• Why recovery metrics come before backup methods

• What MTD, RTO, WRT, and RPO actually mean

• How MTD, RTO, WRT, and RPO Work Together

• How to use them to make the right backup decisions

• BONUS: Printable A4 cheat sheet for certification exams with all the key backup and recovery metrics in one place

The Numbers That Drive Every Backup Decision

As always, people try to skip directly to choosing the backup methods. But remember, a good cybersecurity professional always balances the COST of security controls with their benefits.

So, before you choose a backup method, you need to understand metrics that describe the needs of your company and allow you to choose the right backup strategy.

Trust me, not all systems needs to be backup up every day.

MTD: Maximum Tolerable Downtime

This is the basic deadline. The absolute maximum amount of time a system or process can be down before the consequences become unacceptable. We're talking regulatory violations, financial collapse, reputational damage that can't be undone. Everything else is measured against this number.

If you don’t meet this deadline, you’re done!

RTO: Recovery Time Objective
This metric tells you how long the business can survive without the system.

In other words, the maximum time period within which a mission-critical system must be restored to a designated service level after a disruption.

This defines how fast you need to recover. Some systems are not important and can be out for a week. Some need to be up and running within minutes.

The shorter your RTO, the more expensive and complex your backup solution needs to be.

Remember: RTO < MTD. That’s non-negotiable.

WRT: Work Recovery Time
This is the part most people forget to account for.

The Work Recovery Time is the maximum amount of time available for certifying the functionality and integrity of restored systems and data before they go back into production.

You need to realize here that restoring a database is not the same as confirming the database is working correctly.

WRT is the validation window.

During this window, you check whether all records are intact, the application is functioning correctly, and users can log in.

RTO covers getting the system back. WRT covers confirming it’s safe to use.

RPO: Recovery Point Objective
How much data loss is acceptable?

If your RPO is 4 hours, you can afford to run backups every 4 hours and lose at most 4 hours of data in a disaster.

If your RPO is zero, you need real-time replication.

These are business decisions, not technical ones.

A security professional’s job is to translate them into the right backup architecture.

How They Connect

I know I have covered the connection between the metrics above, but it is so important that I decided to put it in one section.

If you’re preparing for any cybersecurity exam, this section is key to answering most questions about backup strategies (especially for the CISSP)

• MTD sets the ceiling. Nothing can exceed it. This is a number that should come up from your BIA (Business Impact Analysis)

• RTO is the time required to restore the system. RTO < MTD

• WRT is the time to verify that the system is safe to use. It starts the moment all systems are back online. Remember MTD = RTO + WRT.

• RPO determines how often backups run. The tighter the RPO, the more frequent the backup cycle, and the more expensive it gets.

Remember: MTD = RTO + WRT. The total time consumed by recovery and verification must never exceed your hard deadline.

How to Use These Metrics to Make the Right Backup Decision

Now you know the metrics, which means you are further than most people. Trust me, many technically oriented people tend to ignore this despite the fact that it is absolutely essential.

But now is the time to apply them.

Step 1: Start with MTD

Talk to the business.

Let them determine how long this system can be down before the consequences are unacceptable.

This number comes from your Business Impact Analysis.

It's not a technical decision. It's a business one. As a cybersecurity professional, you can help them with the analysis, but they need to be the ones who approve the number.

Step 2: Set your RTO and WRT

Once you have MTD, split it into two windows.

How long will the technical restore take?

That's your RTO.

How long do you need to verify everything works correctly before going live again? That's your WRT.

The two must add up to less than or equal to your MTD.

Step 3: Define your RPO.

Remember: This number comes from BIA.

Now that we know how fast we need to get our systems back and running, it’s time to determine how much data loss the business can tolerate.

One hour? One day? Zero?

This number directly determines how often you need to run backups and how much you’ll spend doing it.

Step 4: Now choose your backup method.

Only at this point does the method question make sense.

• Long RPO, high MTD: a weekly full backup with daily differentials is probably enough.

• Short RPO, low MTD: you need frequent backups, fast restore capability, and possibly real-time replication.

• RPO of zero: no backup method gets you there. You need mirroring.

The method is the last decision, not the first.

Every organization that skips the metrics and starts with the method ends up either overspending on protecting their systems that don’t need it, or underspending on systems that can’t afford to go down.

And that’s why certification exams put so much stress on this topic.

Conclusion

Most people think a backup strategy is a technical problem.

Pick the right method, configure it correctly, and you’re done.

I believe that after reading this article, you’re not like most people.

You understand now where those magical numbers come from and why they are so important for choosing the right backup strategy.

Take these four metrics and use them.

Next time someone asks about backup, don’t start with the methods.

Start with MTD. Ask what the real deadline is. Ask how much data loss the business can actually tolerate.

That’s the thinking. That’s how people will know you know what you’re talking about.

And if you want to know more about data security, here is what you should read next:

• Data Classification

• Data states

• Recovery sites strategies

• Backup strategies in details - NEXT WEEK

Frequently Asked Questions

What is the difference between RTO and RPO?
RTO measures time: how fast must the system be restored? RPO measures data: how much data loss is acceptable? RTO is about recovery speed. RPO is about backup frequency.

What does MTD mean in cybersecurity?
MTD stands for Maximum Tolerable Downtime. It’s the absolute maximum time a system can be unavailable before the consequences become unacceptable to the business. It’s the hard deadline that every recovery plan must be built around.

Is RTO always less than MTD?
Yes. Always. RTO must be less than MTD. MTD = RTO + WRT. If RTO and WRT together exceed MTD, the recovery plan has already failed before anything goes wrong.

Where do these numbers come from?
From the Business Impact Analysis (BIA). These are business decisions, not technical ones. The role of a cybersecurity professional is to help the business define them and then translate them into the right technical solution.

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, CISSP - Domain 2, and Security+ essential topic

Data is often the most valuable possession we have. Businesses have their trade secrets, and families have their photos from that vacation that everyone enjoyed.

You can buy a new computer or a new phone, but you won’t buy those pictures again.

In other words, it doesn’t matter who you are, we all have data that we don’t want to lose because they have value for us, financial or emotional - it is an asset for us.

And modern cybersecurity is dedicated to protecting assets.

What can you expect from this article?

In this post, I will:

• Explain the three states of data and what each one actually means

• Show you what attackers target in each state

• Give you the right controls for each state

• Show you why a layered approach is the only one that actually works

But before we move any further, I would like to provide you with more resources on Data Security.

Knowing how to protect data means nothing if you do not know what data you actually have.

Before security controls come data classification (knowing what is sensitive and what is not) and the data lifecycle (understanding how data moves through your organization from creation to destruction).

If you have not read those yet, start there:

• This Is How I Explain Data Classification to a Beginner

• The Data Lifecycle: From Creation to Destruction

This article picks up where those leave off. Now that you know what data you have and where it lives, let’s talk about how to protect it at every stage of its existence.

Do you find this article helpful? Give it a like and help me share it to more people!

The Three States of Data

Lesson to remember: Protecting data at only one state is like putting your cash in a safe, then carrying the safe through a bad neighborhood with the combination written on the side.

There are three states that data can be in. In the following section, I will describe each state and tell you the typical security controls associated with it.

Data at Rest

Data at rest is data that is stored and not currently being processed or moved.

Meaning? Those are all the data that you have saved on your hard drive, your documents in cloud storage, or backups on a tape.

This is the state most people think about first, and for good reason. It is the easiest to picture. Data sitting still, waiting to be used.

What attackers target here: Physical theft of devices, unauthorized access to storage systems, misconfigured cloud buckets, or weak access controls.

How to protect it:

• Full-disk encryption (FDE) using AES

• Database encryption for sensitive records

• File-level encryption for individual documents

• Tokenization for sensitive data fields (credit card numbers, SSNs)

• Access controls that limit who can reach the data in the first place

• Data Loss Prevention (DLP) tools

The goal is simple: even if someone gets physical or logical access to the storage, they cannot read the data without the key.

However, sooner or later, we will need to either use the data or move it somewhere else.

If you find this article helpful, give it a like and help me get this to more people who are interested in cybersecurity!

Data in Transit

Data in transit is data moving from one location to another, typically across a network.

It can be an email traveling across servers, it can be a file being downloaded from a website, or an API call carrying user records.

The sky is the limit. If you’re moving data from one place to another - this is it!

This is where people get caught off guard.

Note: You need to decrypt the data to send it to someone else as you should be the only one who has the keys from the data on YOUR system.

The moment data leaves one system and heads to another, it is exposed to the network. Without the right controls, anyone with access to that network path can intercept it.

What attackers target here: Man-in-the-middle attacks, packet sniffing on unsecured networks, DNS hijacking, rogue Wi-Fi access points.

How to protect it:

• TLS/SSL for web traffic (HTTPS)

• IPsec for network-level encryption

• SSH for secure remote access and file transfer

• SFTP instead of plain FTP

• Firewalls and intrusion detection systems (IDS) at the network layer

The goal: Ensure confidentiality and integrity while the data is moving. No one in the middle should be able to read or tamper with it.

Still reading? Excellent. Decoded Security share all the study resources for free. Give this article a like and help us get it to more people who are serious about cybersecurity!

Data in Use

Data in use is data being actively processed, accessed, or manipulated by a system or application.

It can be anything from data entered into a web form to a file open in a word processor, to calculations running in a spreadsheet, to a query result loaded into an application.

This is the most overlooked state. And it is the hardest to protect.

For data to be processed, it usually has to be decrypted first. That means it exists in a readable state in memory. If an attacker gets access to that memory, the encryption you applied at rest means nothing.

What attackers target here: memory scraping (used in many point-of-sale breaches), process injection, screen-capture malware, and insider threats with legitimate application access.

How to protect it:

• Memory encryption

• Secure enclaves, also called Trusted Execution Environments (TEEs): isolated areas of a processor where sensitive data can be processed without being exposed to the rest of the system

• User access controls that limit what each person can do within an application

• Application security controls and secure coding practices

• Data classification so the system knows how to handle sensitive data differently

• Endpoint Detection and Response (EDR) tools

The goal: minimize the window during which data is exposed and detect any attempt to access it during that window.

Why This Matters Beyond any Exam

Security controls chosen without context are just expensive guesses.

Understanding data states gives you a framework for asking the right question: Where is this data right now, and what is threatening it in that state?

That question changes how you design systems, evaluate vendors, write security policies, and respond to incidents.

It also changes how you communicate risk to non-technical stakeholders. Telling a business leader “we encrypted the database” sounds like a great idea, but as you now know, it is only a third of the whole.

Telling them “we encrypted the database, secured transmission with TLS, and deployed endpoint protection to cover data in use” tells a much more accurate story.

Key Takeaways

• Data exists in three states: at rest, in transit, and in use

• Each state has a different threat profile and requires different controls

• Encrypting storage only protects one state

• A layered, state-aware approach is the only way to cover all three

• For CISSP and Security+: Always identify the data state before selecting a control

Note: This is what you need to remember for the CC, CISSP and Security+ exam!

Conclusion

While this isn’t the most complex topic that you’ll ever see, I find it absolutely crucial for data security.

In a world where everyone uses buzzwords and competes over who knows the “best” encryption algorithm, we need people who see the whole picture.

People who know that the weakest link in the chain determines how well the data is protected.

And there is one more thing. Reading about something is one thing, but actually understanding it and making the right decisions is completely another.

And because helping you understand cybersecurity concepts is Decoded Security's top priority, I prepared a free quiz based on this article, with detailed explanations.

The Three States of Data - FREE QUIZ

Thank you for reading Decoded Security!

Best,
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!

Warning: CC, CISSP - Domain 2, and Security+ essential topic.

Every company in the world collects data, and for many, it is the most important asset they have.

Customer records, employee contracts, financial reports, internal emails.

Most people assume someone is protecting it properly.

But if there is a good rule to live by for cybersecurity experts: Assumptions kill security.

If you're studying for a cybersecurity cert right now, like this post! You're not alone.

The problem is that the moment you start talking about data protection, everybody starts talking about encryption and tools.

But which tool you are going to use in your organization isn’t that important.

The first question you should focus on is:

Which data actually needs protection, and how much?

That question is what data classification answers.

And if you’re studying for the CISSP, Security+, or just trying to understand how security programs actually work, this concept is something you need to understand deeply.

Here is what you can expect to learn from this article:

• Why data classification exists and what it actually is

• The classification levels used in government and business, and how they differ

• How the whole process of data classification works

• How classification connects directly to access control, compliance, and incident response

• Everything you need to know for the certification exams

If this is something you want to learn more about, just keep reading!

Why Data Classification exists

I like describing concepts with specific examples, because it allows people to tie them down to real situations and imagine them better.

After all, cybersecurity is supposed to solve real-world problems. We are far beyond academic debates that have no real impact.

So, imagine a hospital.

They have patient records. Financial reports. Internal memos. A lunch menu for the cafeteria.

All of that is “data.” But not all of it needs the same level of protection.

If someone leaks the cafeteria menu, no real harm is done.

If someone leaks a patient’s HIV diagnosis, lives can be destroyed, laws are broken, and the organization faces massive consequences.

So the first option would be to protect everything as classified. Well, that would probably mean your business won’t survive. The cost would be too high. The usability of the systems would be very low.

In other words:

Too much protection on everything is expensive and slows everything down. Too little protection on the wrong data leads to breaches, regulatory fines, and reputational damage.

Data classification is the solution. It forces you to think before you protect and spend your money efficiently.

What Data Classification Actually Is

Data classification is the process of categorizing data based on its sensitivity and the potential impact of its loss or unauthorized disclosure.

Simple definition. But the implications are huge.

When you classify data properly, you unlock the ability to:

• Apply the right controls to the right data (not the same controls to everything)

• Meet compliance requirements like GDPR and HIPAA

• Enforce least privilege access: people only see what they need to see

• Respond to incidents faster because you already know what was at risk

• Prevent loss of essential data by understanding what actually matters and implementing the right security controls

Classification is not a technical control. It is a foundational decision that makes all your technical controls work properly.

If you skip classification, your security program has no basis.

Remember: Classify first, then spend money on security controls!

Two Data Types You Must Know

Before we get to classification levels, there are two types of sensitive data that appear constantly in cybersecurity certifications for one simple reason.

Those two types are highly regulated, and if anything goes wrong, your company will pay the price.

So, which data are so special?

Personally Identifiable Information (PII): Any information that can identify a specific individual. Name, social security number, date of birth, biometric records, and home address.

Protected Health Information (PHI): Any health-related information tied to a specific person. This is covered under HIPAA in the US, and mishandling it carries serious legal consequences.

Both are high-sensitivity data by definition. They require the strongest classification levels and the tightest controls.

If you see either of these in an exam question, your brain should immediately think: maximum protection, strict access control, regulatory compliance.

The Classification Levels

Organizations classify data differently depending on whether they operate in the public or private sector. But the underlying logic is the same:

The more damage unauthorized disclosure can cause, the higher the classification level.

Here is how the two scales map against each other:

Remember that non-government organizations can use data classification categories of their own creation, tailored to meet their specific needs.

But these categories are the ones you’ll need for the CISSP exam.

Okay, now you know the levels.

But that is only half the picture. The other half is understanding the process that gets you there.

Most organizations follow four steps:

1. Create classification categories

Define the levels your organization will use. Public, Internal, Confidential, Restricted. Or whatever labels fit your context. The names matter less than having a consistent, documented scheme everyone understands.

2. Determine minimum security requirements per category

For each classification level, define the baseline controls that must be applied. What encryption is required? Who is allowed access? How long is the data retained? This is where classification turns into actionable policy.

3. Classify the data

Go through your data and assign the appropriate label based on sensitivity and potential impact. This step requires input from data owners, not just the security team. The people who create and use the data understand its value better than anyone.

4. Implement security controls

Now you spend money. Apply the controls defined in step two to the data classified in step three. Encryption, access restrictions, DLP policies, monitoring rules. Everything flows from the classification decision made in the previous steps.

The order matters. You do not buy tools and then figure out what you are protecting. You classify first, then implement.

How Classification Connects to Everything Else

Up until now, you might get a feeling that the whole thing is just an administrative exercise.

But it isn’t. It is the foundation of any good security program.

Let me give you a couple of examples:

Access Control: Once data is classified, you can define who is allowed to see it. You cannot enforce least privilege without knowing what you are protecting.

Compliance: Laws like GDPR and HIPAA require you to handle certain data in specific ways. Classification tells you which data falls under which regulations.

Incident Response: When a breach happens, you need to know immediately what was exposed. Classified data means you already have that answer. Unclassified data means you are guessing while the clock runs.

Data Loss Prevention (DLP): DLP tools use classification labels to automatically apply policies. If a file is labeled “Restricted,” the system can block it from being emailed externally. Without labels, DLP cannot do its job.

Audit and Monitoring: Classification tells your monitoring systems which data needs the most attention. You cannot watch everything equally. Classification tells you where to focus.

See? You can’t implement proper security controls if you don’t know what you’re protecting.

Conclusion

I hope that after reading this article, you won’t just remember - Public, Sensitive, and Private…but you will actually take it as an essential part of a security program.

I know that many cybersecurity professionals ignore this step, because it isn’t “technical” enough.

But the reality is that you can’t protect what you don’t know you have. So don’t take it as wasted time, but as an investment that will actually help you implement efficient security controls.

Looking to go deeper on data security? Start with these:

• Cybersecurity Basics: The Data Security Lifecycle

• GDPR Explained: The Privacy Law That Follows Your Data Everywhere

• How I passed the CISSP exam in 3 months!

And if you are still deciding which cybersecurity path makes the most sense for your goals, start with the career path guide.

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!

Well, that’s one way to put it, but if you’re serious about your cybersecurity career, you are going to need more than that.

That’s why I put everything you need to know about VPNs in one place.

Warning: Crucial CC, CISSP and Security+ topics

After reading this article, you will know:

• What a VPN actually is and why it exists

• Why simply using a VPN doesn’t mean you are safe

• Key components of the VPN infrastructure

• The most important VPN protocols (PPTP, L2TP, IPsec)

• Key takeaways - What you need to know as a cybersecurity professional

• Bonus - Decoded Security printable cheat-sheet: One page with the most important information

This is a foundational topic. Let’s build it from scratch.

What Is a VPN?

Let’s start with the simplest possible explanation.

When you connect to the internet from a coffee shop, your traffic travels over a network you don’t control. Anyone on that network could potentially intercept what you’re sending.

A VPN solves this problem by creating an encrypted tunnel between your device and a remote server.

Think of it like this:

Imagine you need to send a confidential letter across a city. Instead of handing it to a random stranger on the street, you put it in a locked tube, send it through a private pipe directly to the recipient, and only they can open it.

That’s a VPN.

The three things a VPN provides:

• Confidentiality: Your traffic is encrypted. Nobody in the middle can read it.

• Authentication: Both sides verify who they’re talking to.

• Integrity: The data hasn’t been tampered with in transit.

Sounds familiar? Those are core security principles. VPNs exist to enforce them over untrusted networks.

What a VPN actually is and why it exists - You know the answer now! ✅

Why Does This Actually Matter?

Today, remote work is standard. Employees connect to company systems from home, hotels, and airports. Without VPNs, every one of those connections is a risk.

A company that doesn’t use VPNs for remote access is exposing internal systems to anyone who can intercept traffic on a public network.

That’s why every serious organization uses VPNs. And that’s why every cybersecurity professional is expected to understand them.

Besides that, people are starting to use different VPN providers for personal use. You have seen the ads, right?
”Connect securely from anywhere in the world..”

Is it a good idea to use a VPN while traveling?

Yes, but before you do, make sure to continue reading! There is one catch that you need to be familiar with!

Why Every VPN Isn’t Safe

When you connect to a VPN, you are not becoming anonymous. You are moving trust.

Before the VPN: your ISP (Internet Service Provider) can see your traffic.

After the VPN: your VPN provider can see your traffic.

You haven’t eliminated the problem. You’ve relocated it.

And if you’re using a free VPN, it gets worse.

Free VPNs are not a service. They are a business. If you’re not paying for the product, you are the product. Your browsing history, location, and behavior patterns get packaged and sold.

Some free VPN providers have been caught injecting ads into user traffic. Others have been linked to data harvesting operations.

You installed a privacy tool, and you handed your data to a stranger.

Even paid VPNs aren’t automatically safe either. The questions that actually matter:

• Do they keep logs of your activity?

• Where are they headquartered, and what laws apply to them?

• Have they been independently audited?

The rule is simple. A VPN is only as trustworthy as the provider running it. Choose carefully.

Why simply using a VPN doesn’t mean you are safe - Checked! ✅

This marks the end of the “users” section. I felt obligated to spread the awareness as I personally know many people who use various VPNs, and it would be better if they didn’t use any at all.

Now we are moving to the part of the article that is crucial for cybersecurity professionals and CISSP candidates!

Key Components of a VPN

Before we get into different protocols, let’s quickly describe what the VPN is actually made of.

VPN Client

The software that is installed on your device. It initiates the connection, handles encryption, and manages the tunnel.

VPN Tunnel

The encrypted path between your device and the VPN server. All your traffic travels through this tunnel, hidden from anyone outside it.

VPN Server

The endpoint on the other side. It receives your encrypted traffic, decrypts it, and forwards it to its destination. In a corporate setup, this sits at the edge of the company network. In a consumer setup, it’s operated by the VPN provider.

Simple, isn’t it?

Each user has a client on their device that handles the connection between their device and the VPN server.

Now..buckle up. Because the next topic is one of the most tested in the certification exams and is actually essential to understand for real cybersecurity work.

Key components of the VPN infrastructure - Great progress! ✅

VPN Protocols

A VPN isn’t a single technology. It’s a concept implemented through different protocols, each with its own approach to encryption, authentication, and performance.

Basically, in this section, we are going to break down how the “tunnel” is created and implemented.

PPTP (Point-to-Point Tunneling Protocol)

PPTP is one of the oldest VPN protocols. You’ll see it mentioned in study materials. You will almost never see it used in practice.

Why? Because it has serious known vulnerabilities. The encryption it uses is weak by modern standards. It was fast, which was important in the 1990s when processing power was limited. That tradeoff no longer makes sense.

I only mention it because it often appears in the certification exam as the least secure protocol.

For the exam: PPTP = fast, obsolete, insecure. Don’t recommend it. Don’t use it.

L2TP (Layer 2 Tunneling Protocol)

L2TP is the next generation. But here’s the catch: L2TP doesn’t provide any encryption on its own.

It creates the tunnel. Nothing more.

That’s why you almost always see it paired with IPsec. Written as L2TP/IPsec.

When properly implemented with IPsec, L2TP/IPsec is considered secure. But it’s a legacy solution at this point. You’ll see it in older enterprise environments and on exam questions.

For the exam: L2TP alone = no encryption. L2TP/IPsec = secure when properly implemented.

IPsec (Internet Protocol Security)

This is the one you really need to understand.

IPsec isn’t a single protocol. It’s a suite of protocols designed to authenticate and encrypt IP packets. It can work as a standalone VPN solution or in combination with L2TP.

IPsec has two main components, and knowing the difference between them is high-probability exam content.

Authentication Header (AH)

AH calculates a cryptographic hash over the entire packet. This provides:

• Integrity: the packet hasn’t been modified in transit

• Authentication: you know who sent it

What AH does NOT provide: encryption. The data is visible. AH just ensures it hasn’t been tampered with.

Encapsulating Security Payload (ESP)

ESP encrypts the payload of the IP packet. This provides:

• Confidentiality: the data is hidden

• Integrity

• Limited authentication

ESP is what actually hides your data. AH confirms the data wasn’t touched. In practice, they’re often used together.

There is much more to the IPsec protocols, but I think this is enough for one day.

The most important VPN protocols (PPTP, L2TP, IPsec) - Checked! ✅

Key Takeaways

Here’s what you need to walk away with.

On the basics:

• A VPN creates an encrypted tunnel between your device and a remote server

• It provides confidentiality, authentication, and integrity over untrusted networks

• A VPN moves trust, it doesn’t eliminate it. Your provider can see everything your ISP used to see

• Never use a free VPN. If you’re not paying for the product, you are the product

On VPN components:

• Client: initiates the connection and manages the tunnel from your device

• Tunnel: the encrypted path your traffic travels through

• Server: receives, decrypts, and forwards your traffic at the other end

On protocols:

• PPTP: fast, obsolete, do not use

• L2TP: no encryption alone, secure when paired with IPsec

• IPsec: the gold standard, used standalone or with L2TP

On IPsec components:

• AH: integrity and authentication, no encryption

• ESP: confidentiality, integrity, limited authentication

• They’re often used together

Bonus - Decoded Security Cheatsheet

Everything for the exam and real-work practice at one page.

Decoded Security Vpn Cheat Sheet

27.4KB ∙ PDF file

Download

Download

Conclusion

VPNs are not complicated once you understand what they’re actually doing.

They exist to solve one problem: how do you communicate securely over a network you don’t trust?

The answer is: build a private tunnel. Encrypt what goes through it. Authenticate who’s on each end. Verify nothing was changed in transit.

Every VPN protocol, every configuration option, every exam question circles back to those fundamentals.

If you got value from this article, give it a like. It helps me understand which topics to cover next and helps other people find it.

And if you want a structured path through all the networking and security fundamentals that actually matter for certifications and job interviews, subscribe to Decoded Security.

Every article is built to move your knowledge forward, one concept at a time.

Looking to go deeper on networking? Start with these:

• This Is How I Explain DNS to Beginners

• This Is How I Explain Subnetting to a Beginner

• What Actually Happens When You Open a Website

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!

Millions of accounts. All passwords are hashed with MD5. No salt. The database was dumped and circulated online, and within days, the majority of passwords had been cracked.

And all the attacker needed was a wordlist and a loop.

But this couldn’t possibly have happened today, right?

Well, I hate to break it to you, but the same mistakes are still being made today. That’s why you need to understand what exactly happened in 2012 and how to prevent it from happening on your systems.

And what better way of learning than actually performing the attack?

Note: This article assumes you understand what hashing is and why it matters. If you are not there yet, read these first:

• Hashing: What It Is and Why It’s Not the Same as Encryption

• Hashing Algorithms: What Any Cybersecurity Specialist Needs to Know

What actually happened in 2012

Most modern systems don’t store passwords in plaintext, but in hashes.

That’s why when the attacker steals the password database, all they can see are hashes.

Once they have the hashes, the goal is quite simple.

To reverse them and figure out what password produced each hash.

But how?

Well, the first option is brute force. Try all possible combinations and sooner or later, you’ll hit the jackpot.

But it can take years.

So they need something more efficient - a dictionary attack.

Take a list of common passwords. Hash each one. Compare the result against the stolen hashes. If there’s a match, the password is cracked.

No magic. Just a list of words and a simple loop.

It works because most people choose predictable passwords.

“password”, “123456”, “password123”.

Variations with numbers at the end. Seasons plus years. The attacker’s wordlist reflects exactly how real humans think.

That’s exactly what happened in 2012. LinkedIn’s database was dumped. The attackers ran a wordlist against 117 million SHA-1 hashes. And because there was no salt and the algorithm was fast, the majority cracked in days.

And with SHA-1? A modern CPU can compute hundreds of millions of SHA-1 hashes per second. A poorly hashed password is cracked before you finish reading this sentence.

What is salting

If you’ve been paying attention, you noticed this sentence: “because there was no salt.”

What does that even mean? Are we worried about our passwords not being tasty enough? Or what?

Well..let’s take a look at it.

A salt is a random string added to a password before it gets hashed.

Without salting, every user who chooses “password” gets the same hash (assuming the same hashing algorithm):

password → 5f4dcc3b5aa765d61d8327deb882cf99

Always. Every time. On every system in the world.

With salting, a unique random string is generated per user and combined with the password before hashing:

password + x7k2mR9q → completely different hash
password + 4mNpQ2rs → completely different hash again

Two users with the same password now have completely different hashes in the database. An attacker who steals the database cannot use precomputed tables. They have to attack each hash individually. That changes the economics of the attack entirely.

And let’s face it, it’s all about the money.

Why MD5 and SHA-1 are dangerous for passwords

Note: If you have no idea what MD5 or SHA-1 means, make sure to read the articles linked above! You won’t regret it!

Both algorithms were designed for speed. Fast hashing is excellent for verifying file integrity or generating checksums. It is catastrophic for password storage.

A modern CPU can compute hundreds of millions of MD5 hashes per second.

A GPU pushes that into billions.

A weak password is cracked before you finish reading this sentence.

Neither algorithm was designed with password storage in mind. Using them for that purpose is a fundamental design mistake, not a configuration issue.

Make sure to remember that for both the real-world scenarios and certification exams!

What do we use instead?

bcrypt was designed specifically for passwords. The key difference is intentional slowness.

It has a cost factor, sometimes called a work factor, that controls how computationally expensive each hash computation is.

The same password takes milliseconds with MD5 and seconds with bcrypt. At scale, that difference makes automated cracking attacks impractical.

A wordlist with 56 passwords takes MD5 a fraction of a millisecond. The same list against bcrypt takes several seconds. Scale that to millions of passwords and the attack stops being viable on normal hardware.

Note: There is an even newer standard, Argon2, but bcrypt is still widely used.

What you are about to do

It’s time to get some hands-on experience.

The lab below uses a real Docker environment, real password hashes, and a real dictionary attack script.

You will crack three passwords in under a second. You will watch one password survive because it is not in the wordlist. You will see bcrypt slow everything down to a crawl.

Theory tells you this happens.

And the biggest benefit? Next time you’re in an interview, you will have a nice personal project to talk about.

Get 14 day free trial

The lab is waiting. Subscribe to access the full step-by-step walkthrough below.

Read more

You feel that urge to do something, but you always end up watching random YouTube videos, downloading Kali Linux, and feeling like you are getting nowhere.

In cybersecurity, a lack of direction is more dangerous than a lack of knowledge.

I am going to be honest with you. I am not a penetration tester. I am a Cybersecurity Manager.

But I have worked alongside pentesters. I have interviewed candidates for offensive security roles. And I have studied this path carefully enough to know exactly what separates the people who break in from the ones who stay stuck.

This is the study plan I would follow if I had chosen this path.

Penetration Testing (Offensive Security)

Penetration testing is one of the 5 cybersecurity paths you can choose.

If you are not familiar with the cybersecurity paths, read this first:

👉 How to Choose the Right Cybersecurity Role Before You Waste Time and Money on the Wrong Certifications

But before you deep-dive into the materials I am about to provide, make sure this path is really for you.

You do not want to waste weeks and months learning things that will not get you any closer to your goal.

It is a great fit if you:

• Enjoy thinking like an attacker - finding weaknesses before others do

• Like structured problem solving with clear objectives

• Are comfortable going deep into technical detail

• Enjoy learning how systems actually work under the hood

• Have patience for long, methodical investigation

Be honest with yourself:

• Penetration testing is not beginner-friendly

• Most entry-level roles require at least some IT or networking background

• You will spend months building foundations before touching offensive tools

• The learning curve is steeper than almost any other cybersecurity path

But don’t get me wrong here. I am not saying it isn’t worth it! All I am saying is you need some IT experience first!

The Decoded Security Penetration Testing Roadmap

This roadmap has three main goals.

First, make sure you understand the cybersecurity fundamentals that underpin everything in offensive security.

Second, make sure you understand how systems and networks actually work, because you cannot attack what you do not understand.

Third, force you to practice in real environments, not just watch tutorials.

What is your target role? Let me know in the comments and let’s discuss your next steps!

Here is the exact roadmap I would follow if I had to start from scratch.

Step 1: Build the Right Foundation

Before you touch a single offensive tool, you need to understand how cybersecurity actually works.

Most beginners skip this step. They download Kali Linux on day one and wonder why nothing makes sense.

Do not make that mistake.

Make sure to understand these especially:

1. Threat ≠ Risk ≠ Vulnerability: Why CISSP Basics Matter More Than You Think

2. Cybersecurity Controls from Zero to Hero

3. The Psychology of Hacking: Why Smart People Fall for Dumb Scams

4. 6 Myths That Are Killing Corporate Cybersecurity

Step 2: Master Networking and Systems

You cannot hack what you do not understand.

Every penetration tester needs a deep understanding of how networks and systems communicate. This is not optional. It is the foundation of everything.

Focus on:

Networking fundamentals

• This Is How I Explain DNS To Beginners

• Top 5 Most Important Network Protocols for Cybersecurity Beginners

• This Is How I Explain Subnetting To a Beginner

• Why Most Beginners Don’t Understand How Networks Actually Work

• 7 Networking Questions That Instantly Expose Beginners in Cybersecurity Interviews

Linux - non-negotiable

• This Is How I Explain Linux To a Beginner

• Top 5 Linux Commands for an Entry-Level Cybersecurity Role

Cryptography basics

• Symmetric vs Asymmetric Encryption

• Digital Signatures Explained

• [This Is How I Explain PKI To a Beginner] - will be published soon!!

Attack techniques

• This Is How I Explain The Man-in-the-Middle Attack To a Beginner

• How Phishing Works in 5 Steps

• The QR Code Trap

Do you struggle with any of these concepts? Comment the one you don’t understand and I will break it down for you.

Step 3: Get Your First Certification

Most people ask the wrong question: “Which certification should I get?”

The right question is: “Which certification fits where I am right now?”

For penetration testing, here is the honest order:

Start here: eJPT (eLearnSecurity Junior Penetration Tester)

Free to study. Practical exam. Actually tests whether you can do the work, not just memorize definitions. This is the most realistic first certification for this path.

Then: CompTIA PenTest+

Widely recognized. Good intermediate step. Bridges the gap between foundational knowledge and hands-on offensive work.

The goal: OSCP (Offensive Security Certified Professional)

The industry standard for senior offensive roles. Do not attempt this first. Attempt it when you are ready - but consider attempting it earlier than you feel comfortable. Passing OSCP before you have extensive experience sends a signal that nothing else on this path does.

Read the full certification breakdown here: 👉 Stop Buying Random Certifications. Here’s Exactly Which One You Need Based on Your Path

Step 4: Practice in Real Environments

Reading about penetration testing will not make you a penetration tester.

You need to practice. Every day. In real environments.

Here are the free platforms I would use:

TryHackMe - Start here. Guided learning paths with real machines. The most beginner-friendly platform on this list. Complete the “Pre-Security” and “Jr Penetration Tester” paths first.

OverTheWire: Bandit - Teaches Linux command line through puzzles. Surprisingly fun. Surprisingly hard. Do this alongside TryHackMe.

HackTheBox - More advanced. Move here once you are comfortable with TryHackMe. The machines are harder and less guided.

The rule: One hour of practice every day beats five hours on weekends. Consistency matters more than intensity.

Do you struggle with any of these platforms? Comment below and I will point you to the right starting point.

Leave a comment

Step 5: Build a Portfolio

This is the step most beginners skip. Do not skip it.

A penetration testing portfolio proves you can do the work before you have a job to prove it.

What to include:

• CTF writeups - document every challenge you solve on TryHackMe and HackTheBox. Explain what you did, why you did it, and what you learned.

• Personal lab - set up a home lab with VirtualBox or Docker. Document your setup.

• A GitHub profile - publish your scripts, notes, and writeups publicly.

• A blog or newsletter - writing about what you learn forces you to understand it deeply. It also makes you visible to recruiters.

Hiring managers for offensive security roles do not just look at your CV.

They look at your GitHub. They look at your write-ups. They look for evidence that you actually do this.

Have you started a portfolio? Comment below and share it. I will give you feedback.

Leave a comment

Conclusion

Most people do not fail in penetration testing because it is too hard.

They fail because they never had a plan.

They download Kali Linux on day one. They watch random YouTube videos. They jump between tools without understanding what they are doing or why.

That is how months turn into years with nothing to show for it.

This roadmap fixes that. It gives you the structure I wish someone had given me when I was learning this field.

It tells you:

• What to learn

• In what order

• And how to actually practice it

You will start thinking like someone who can:

• Understand how systems communicate

• Identify realistic attack vectors

• Build the skills that actually get you hired

You already have the roadmap. Now it is about execution.

See you in the comments.

Thank you for reading Decoded Security!

Erich

Comment your target role and your current level. I will give you your next step.

💬 Which step feels most challenging right now? Comment below - I read every response.

Leave a comment

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!