DEV Community: Khalif AL Mahmud

Building My First LAN in Cisco Packet Tracer: Connecting 4 PCs Through a Switch

Khalif AL Mahmud — Sun, 26 Jul 2026 19:13:42 +0000

Networking always felt like one of those "black box" topics to me — you know your laptop connects to Wi-Fi and somehow reaches the internet, but the actual mechanics of how devices talk to each other on a local network stay invisible. I decided to fix that by getting hands-on with Cisco Packet Tracer and building the simplest possible network from scratch: a handful of PCs, one switch, and enough IP addresses to make them all understand each other.

This post walks through exactly what I did, why each step matters, and how I verified the whole thing actually worked — not just looked right on screen.

Problem Statement

The goal was straightforward on paper: connect four computers to a single switch, give each one its own IP address, and confirm they can all reach each other over the network. Simple as that sounds, it forces you to actually understand a few core networking concepts:

Why you need a specific cable type to connect a PC to a switch
How IP addresses and subnet masks decide which devices can "see" each other
How to prove connectivity actually works, instead of just assuming it does

Tools Used

Cisco Packet Tracer
1x Switch (2960 series)
4x PCs
Copper Straight-Through cables

Step-by-Step Walkthrough

Step 1: Set Up the Devices

I opened Packet Tracer and dragged a 2960 switch into the middle of the workspace, then placed four PCs around it. Nothing connected yet — just laying out the topology first so I could see the shape of the network before wiring anything up.

Step 2: Cable Everything Together

This is where the "which cable do I use" question comes in. There are two main copper cable types in Packet Tracer: Straight-Through and Crossover. The rule of thumb is:

Different device types (PC ↔ Switch, PC ↔ Router) → Straight-Through cable
Same device types (Switch ↔ Switch, PC ↔ PC) → Crossover cable

Since I was connecting PCs to a switch — two different device types — a Straight-Through cable was the correct choice. I connected each PC's FastEthernet0 port to its own port on the switch:

PC0 → Switch Fa0/1
PC1 → Switch Fa0/2
PC2 → Switch Fa0/3
PC3 → Switch Fa0/4

After a few seconds, every link light turned green, which confirmed the physical layer connection was solid on all four links.

Step 3: Assign IP Addresses

With cabling done, the next job was making each PC addressable on the network. I went into each PC's Desktop → IP Configuration, switched to Static, and assigned the following:

PC	IP Address	Subnet Mask
PC0	192.168.1.1	255.255.255.0
PC1	192.168.1.2	255.255.255.0
PC2	192.168.1.3	255.255.255.0
PC3	192.168.1.4	255.255.255.0

The subnet mask is the important detail here. Using 255.255.255.0 on every PC keeps them all in the same 192.168.1.0 network, which is what allows them to talk to each other directly without needing a router. If the subnet masks didn't match, or the IPs landed in different subnets, the PCs would technically be cabled together but logically isolated — a good reminder that physical connection and network connection are two very different things.

How to Verify

Configuring IPs is one thing — proving they actually work is another. I opened PC0's Command Prompt and ran:

ping 192.168.1.2
ping 192.168.1.3
ping 192.168.1.4

Every single ping came back with a Reply from... response and 0% packet loss, which confirmed PC0 could reach PC1, PC2, and PC3 without any issues.

Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

If a ping had failed, the next things I'd check are: cable type, whether the link light is actually green, whether the subnet masks match across devices, and whether I typo'd an IP address (it happens more often than you'd think).

What I Learned

This was a small setup, but it packed in a surprising number of fundamentals:

Switches operate at Layer 2 — they don't care about IP addresses to forward traffic within the same network, but the PCs still need valid IPs to communicate meaningfully above that layer.
Cable type matters more than I expected. Straight-Through vs. Crossover isn't just trivia — plugging in the wrong one (in real hardware, anyway) can mean no link light at all.
Subnet masks define the "neighborhood." Two devices can be cabled together perfectly and still fail to talk if their masks put them in different logical networks.
Ping is your best friend for verification. It's a simple command, but it's the fastest way to confirm connectivity actually exists rather than just looking correct visually.

Common Mistakes Table

Mistake	Why It Happens	Fix
Using a Crossover cable instead of Straight-Through	Mixing up when each cable type applies	Remember: different device types = Straight-Through
Mismatched subnet masks	Copy-pasting config without double-checking	Verify every PC uses the same mask if they should be on one network
Typo in IP address	Manual entry across multiple PCs	Double-check each octet before moving to the next PC
Assuming green link light = full connectivity	Confusing physical layer with network layer	Always confirm with `ping`, not just visual cues
Forgetting to set Static mode before entering an IP	DHCP is selected by default	Switch to Static first, then fill in the address fields

Conclusion

Building this tiny four-PC network was a great reminder that networking fundamentals aren't complicated once you actually build them out yourself instead of just reading about them. Cabling, addressing, and verifying — that's really the whole loop, and once it clicks, scaling up to routers, VLANs, and larger topologies feels a lot less intimidating.

Linux, Networking, Scripting, and AI: What Every Beginner Pentester Should Know

Khalif AL Mahmud — Fri, 17 Jul 2026 17:42:50 +0000

When I started digging deeper into cybersecurity, I quickly realized that almost everything in this field circles back to one operating system: Linux. Whether you're running a vulnerability scan, writing a quick automation script, or asking an AI tool to explain a weird output, Linux is the environment where it all happens.

I wanted to write down what I've learned so far in a way that's actually useful for someone just getting started — no fluff, just the stuff that matters.

Why Linux Dominates Cybersecurity

Linux is open-source, free, and highly customizable. Unlike Windows or macOS, it gives you full control over the system — down to the smallest configuration file. That level of control is exactly why almost every serious security tool is built for Linux first.

And within the Linux world, there's one distribution that stands out for security work: Kali Linux.

What Makes Kali Linux Special

Kali is a Linux distribution built specifically for penetration testing, maintained by Offensive Security. It comes preloaded with hundreds of tools covering:

Network scanning
Vulnerability assessment
Password testing
Digital forensics
Web application testing
Wireless security testing

Basically, if you're doing ethical hacking, Kali saves you the trouble of hunting down and installing every tool yourself.

Getting Comfortable With the Linux Filesystem

One of the first mental shifts coming from Windows is realizing there's no "C: drive." Everything starts from a single root directory: /.

A few directories you'll bump into constantly:

/home — where regular users keep their personal files
/etc — system and application configuration files
/var — logs, caches, and other data that changes often
/root — the home directory of the root (admin) user

Once that structure clicks, navigating any Linux system starts to feel natural.

The Commands You'll Actually Use Every Day

You don't need to memorize hundreds of commands to get productive. A small core set covers most of your daily work:

pwd                     # show current directory
ls                      # list files and folders
cd folder_name          # change directory
mkdir new_folder        # create a directory
touch file.txt          # create an empty file
cp source destination   # copy files
mv source destination   # move or rename files
rm file.txt             # delete a file
cat file.txt            # print file content

These feel small individually, but combined they let you move around, inspect, and manipulate a system faster than any GUI ever could.

Permissions: Read, Write, Execute

Linux controls access through three roles — owner, group, and others — and three permission types:

Read (4) — view or open a file
Write (2) — modify a file
Execute (1) — run it as a program or script

You change permissions with chmod, and most professionals prefer the numeric shorthand over the +x / +w style because it's faster and sets everything in one shot:

chmod 755 script.sh

That single command says: full control for the owner, read-and-execute for everyone else. Clean and quick.

Installing Software: apt and dpkg

Two commands handle almost all your software needs on Kali:

sudo apt update
sudo apt install nmap

apt pulls packages (and their dependencies) straight from repositories. When you already have a .deb file downloaded locally, dpkg installs it directly:

sudo dpkg -i package.deb

PATH and Environment Variables

Ever wonder how Linux knows where to find a program when you just type its name? That's the PATH variable at work — it's a list of directories the shell automatically searches.

echo $PATH

Environment variables in general are how the system and applications share small but important pieces of information, like usernames or language settings, without hardcoding them anywhere.

Networking Basics You Can't Skip

A few networking concepts show up constantly in security work:

IP address — the unique identifier of a device on a network
DNS — translates domain names like google.com into IP addresses
Gateway — the device (usually your router) that connects your local network to the internet

And the commands to actually see this in action:

ip a            # view IP address, interfaces, MAC address
ip route        # view gateway and routing info
ping google.com # test connectivity
traceroute facebook.com  # trace the path packets take

ping tells you if a host is reachable. traceroute shows you the hops your traffic takes to get there — genuinely useful when you're debugging connectivity or mapping out a network.

Scripting: Where Automation Begins

Once you're comfortable with commands, the next natural step is stringing them together. That's where Bash scripting comes in:

#!/bin/bash
echo "Hello From Khalif"

Save it, make it executable, and run it — congratulations, you've automated your first task.

Beyond Bash, Python is the real workhorse in cybersecurity. It's used for building network scanners, analyzing logs, automating repetitive tasks, and even developing full security tools. If you're serious about this field, learning Python isn't optional — it's foundational.

Where AI Fits Into All of This

This is the part that genuinely excites me. AI tools are starting to show up as real assistants in the pentesting workflow — not replacements for skill, but accelerators for it.

Tools like PentestGPT can help with:

Understanding vulnerabilities
Explaining confusing tool output
Suggesting the next step in an assessment
Writing commands and scripts
Drafting reports

AI is also increasingly used for threat detection, malware analysis, log analysis, intrusion detection, and phishing detection — anywhere there's a large volume of data that needs fast pattern-matching.

The Catch

AI isn't magic, and it definitely isn't infallible. It can:

Suggest incorrect commands
Miss context a human would catch instantly
Expose sensitive data if used carelessly
Lack the judgment and intuition a real analyst brings

That's why the right mental model is: AI is an assistant, not a replacement. It speeds up the boring parts and helps you learn faster, but the judgment calls — and the ethics — stay with the human.

Using AI Responsibly

A few ground rules I try to keep in mind:

Respect privacy, always
Never run unauthorized tests or attacks
Double-check AI-generated output before trusting it
Stay within legal and ethical boundaries
Treat AI as a co-pilot, not the pilot

Final Thoughts

None of this is groundbreaking on its own — Linux fundamentals, basic networking, a bit of scripting, and an intro to AI tools. But together, they form the backbone of how modern security work actually gets done. If you're starting out in cybersecurity, getting genuinely comfortable with these basics will take you further than jumping straight into flashy tools.

How Stuxnet Broke Into an "Offline" Nuclear Facility — Without Ever Touching the Internet

Khalif AL Mahmud — Fri, 17 Jul 2026 17:39:20 +0000

If you've spent any time in cybersecurity, you've probably heard the Stuxnet story thrown around as some kind of legendary tale. But here's the part that still trips people up: Iran's nuclear facility wasn't even connected to the internet. So how exactly did malware get in?

Turns out, "air-gapped" doesn't mean "unreachable." It just means attackers have to get a little more creative.

The Human Element Nobody Talks About Enough

Stuxnet didn't come in through some flashy remote exploit or a phishing email. It came in through a USB drive.

Somewhere along the line, an employee or contractor plugged in an infected USB drive into a computer at the facility. That's it. That was the entry point. No firewall to bypass, no network to breach — just a small piece of hardware crossing a physical boundary that no software defense could stop.

It's a good reminder that "air-gapped" systems are only as secure as the humans and removable media that interact with them. You can isolate a network from the internet, but you can't fully isolate it from people.

From One Machine to Industrial Sabotage

Once Stuxnet infected that first local machine, it didn't just sit there. It started spreading laterally through the internal network — the same kind of network segment that was supposed to be "safe" because it wasn't internet-facing.

Eventually, it found what it was looking for: the centrifuges' operating frequency. Stuxnet was specifically engineered to manipulate that frequency, causing physical damage to the equipment while feeding false readings back to operators so everything looked normal on the monitoring systems.

This is what made Stuxnet genuinely different from typical malware at the time. It wasn't just stealing data or crashing systems — it was reaching through code into the physical world and causing real, mechanical destruction. That crossover from digital to physical is a big reason Stuxnet is still studied as a landmark case in industrial control system (ICS) security.

A Quick Detour: What About Bloatware?

Slightly different topic, but worth a mention since it's related to system security hygiene: bloatware.

Bloatware refers to unnecessary pre-installed software that ships with a device — stuff you never asked for and rarely use. Beyond just eating up storage and system resources, bloatware quietly increases your attack surface. Every extra piece of software running on a machine is one more potential entry point for something to go wrong, whether that's a vulnerability, a misconfiguration, or just unnecessary background access to system resources.

It's a small thing, but it ties back to the same core lesson as Stuxnet: security isn't just about what's connected to the internet. It's about everything that has physical or logical access to a system — from USB drives to pre-loaded software nobody asked for.

The Takeaway

Stuxnet is a masterclass in why "isolated" systems still need serious security discipline. Air-gapping raises the bar, but it doesn't eliminate risk — it just shifts the attack vector from the network to the physical world. USB policies, endpoint monitoring, and controlling what touches your machines matter just as much as firewalls and network segmentation.

Over a decade later, it's still one of the best real-world examples of why defense-in-depth isn't optional.

Dark Web vs Dark Net vs TOR — Untangling Three Terms People Use Interchangeably

Khalif AL Mahmud — Thu, 16 Jul 2026 15:39:15 +0000

"Dark web," "dark net," and "TOR" get thrown around like they're all the same thing — usually in the same breath, usually with a slightly ominous tone. When I actually looked into it for this assignment, I realized they're related but distinct concepts, each describing a different layer of the same overall picture. Here's how I'd break it down.

Dark Web

The dark web is a hidden part of the internet that isn't indexed by search engines and is usually accessed through the TOR network. So when you Google something, you're searching the "surface web" or "deep web" (like your email inbox or a private database) — none of that touches the dark web at all.

The dark web exists to provide privacy, anonymity, and secure communication. It's mainly accessed through the TOR browser, and — this part surprised me — it was originally created to protect sensitive government and military communications, not for the reasons it's often associated with today.

Dark Net

The dark net is a private and anonymous network that hosts hidden websites and services. If the dark web is the content — the actual hidden sites and pages — the dark net is closer to the infrastructure underneath it, the network layer that makes accessing that hidden content possible in the first place.

Like the dark web, the dark net exists to provide anonymity, privacy, and secure communication, and it's accessed using special software such as TOR. It was also created originally to protect sensitive communications and support anonymous communication more broadly.

TOR

TOR (The Onion Router) is a network and browser used to hide a user's identity and location online. It's the actual tool that makes accessing the dark web and dark net possible for a regular person.

TOR exists to provide privacy, anonymity, and secure communication, and is accessed using the TOR browser. Same origin story as the other two: it was originally created to protect sensitive government and military communications, and was later released more broadly.

The name "onion router" isn't random, either — TOR works by routing your traffic through multiple layers of encrypted relays (like layers of an onion), so no single point in the chain knows both who you are and what you're accessing at the same time.

So how do these three fit together?

Here's the way I'd summarize the relationship:

TOR is the tool — the browser and network protocol that provides anonymity.
Dark net is the underlying network that hidden services run on, typically accessed via tools like TOR.
Dark web is the content layer — the actual hidden websites and pages that live on the dark net, reachable through TOR.

They all share the same core purpose (privacy, anonymity, secure communication) and largely overlap in practice, which is exactly why people use the terms so loosely. But technically, each one describes a slightly different piece of the same puzzle.

Worth remembering

None of these three technologies are inherently good or bad — they're neutral tools. The same anonymity that gets misused for illegal activity is also what protects journalists, whistleblowers, activists, and people living under oppressive surveillance regimes. Context is everything. Understanding what these terms actually mean (instead of just associating them with vague "scary internet" vibes) is a much more useful starting point than the popular narrative usually gives credit for.

What Is a Watering Hole Attack? (And Why It's Sneakier Than Most Cyber Attacks)

Khalif AL Mahmud — Thu, 16 Jul 2026 15:34:59 +0000

Most cyber attacks you hear about follow a fairly direct pattern — someone sends a phishing email, or someone tries to brute-force a password. Watering hole attacks are different, and honestly a bit unsettling once you understand the logic behind them, because the attacker doesn't come after you directly at all. They come after somewhere you already trust.

What is a watering hole attack?

A watering hole attack is a cyber attack where attackers compromise a trusted website that's frequently visited by their target users. Instead of attacking the victims head-on, the attacker infects a website the victims already visit regularly and waits. When the victims visit that website, their devices may become infected, or their information may get stolen.

The name itself comes from a pretty vivid analogy: in the wild, a predator doesn't chase every animal across the entire savanna. It just waits near the watering hole, because it knows the prey will eventually come to it on their own. Same idea here — instead of chasing individual targets, the attacker poisons the place the targets already go to voluntarily.

How it actually works

The attack generally plays out in three steps:

Identify the target's habits. The attacker figures out which website the target users visit regularly — this could be an industry forum, a niche news site, a vendor portal, anything the specific target group trusts and frequents.
Compromise that website. The attacker infects or compromises the website with malicious code, without necessarily touching the victims yet.
Wait for the victims to show up. When the victims visit the now-compromised website, malware gets downloaded onto their devices, or sensitive information gets stolen — all without the victim doing anything unusual or suspicious on their end.

Why it's particularly dangerous

What makes watering hole attacks especially effective is that they exploit trust rather than trying to break through it. A user visiting a site they've safely used for years has no reason to be suspicious. There's no obviously sketchy link to click, no urgent email demanding action — just a normal visit to a normal site that happens to have been quietly compromised.

This also makes watering hole attacks a favorite technique in targeted, sophisticated campaigns — often used against specific industries, organizations, or even government sectors, since the attacker only needs to compromise one commonly-visited site to potentially catch an entire group of targets at once.

The takeaway

Watering hole attacks are a good reminder that security isn't just about being cautious with suspicious-looking links or emails — even websites you've trusted for years can become a delivery mechanism for malware if attackers manage to compromise them first. It's part of why things like regular software updates, endpoint protection, and network monitoring matter even when you feel like you're "just browsing normal sites."

Non-Repudiation — Why You Can't Just Say "I Didn't Do That" Anymore

Khalif AL Mahmud — Thu, 16 Jul 2026 15:29:47 +0000

Of all the terms I covered in this assignment, non-repudiation is probably the one with the most satisfying "aha" moment once it clicks. It sounds intimidating, but the actual idea behind it is pretty intuitive once you break down the word itself: "repudiate" basically means to deny or reject something. So non-repudiation is, quite literally, about making denial impossible.

What non-repudiation actually means

Non-repudiation is a security concept that ensures a person cannot deny performing a particular action after it has already happened. It's about creating undeniable proof.

A simple example: if a user sends a digitally signed email or approves an online transaction using a digital signature, they cannot later claim they didn't do it. The signature itself becomes evidence tying that specific action to that specific person.

How is it actually achieved?

Non-repudiation isn't just a policy or a promise — it's backed by real technical mechanisms, including:

Digital signatures
Digital certificates
Secure logging

These technologies work together to create a verifiable, tamper-resistant trail connecting an action to the person who performed it, in a way that's mathematically difficult (practically impossible) to fake or deny after the fact.

Why does this matter?

Think about how much of daily life now runs through digital approvals — online banking transfers, contract signings, e-commerce purchases, official government submissions. If there were no way to prove who actually approved a transaction, the entire system of trust behind digital transactions would fall apart. Anyone could authorize something and later claim "that wasn't me," with no way to prove otherwise.

Non-repudiation closes that gap. It's what allows digital transactions to carry real legal and business weight, the same way a handwritten signature on a physical contract does — arguably with even stronger proof behind it, since digital signatures are backed by cryptography rather than just visual comparison.

The bigger picture

The main purpose of non-repudiation is to:

Create trust between parties in a digital transaction
Prove ownership of actions
Support legal or business processes whenever evidence is needed

It's one of those security principles that quietly underpins a huge amount of modern digital infrastructure — most people never think about it until there's a dispute, and suddenly it becomes the single most important thing in the room.

Accountability vs Audit — Knowing Who Did What, and Proving It

Khalif AL Mahmud — Thu, 16 Jul 2026 15:24:26 +0000

Out of all the term-pairs I went through for this assignment, Accountability and Audit felt the most closely tied together — almost like two halves of the same process. They work hand in hand, but they're not the same thing, and understanding the difference actually clarifies how organizations investigate security incidents.

Accountability: tying actions back to individuals

Accountability means making sure every user is responsible for their actions within a system. Since user activity is linked to individual accounts, it becomes possible to identify exactly who performed a specific action.

This is why shared logins are such a bad security practice — the moment multiple people use the same account, accountability collapses. You lose the ability to tie any specific action back to a specific person.

Audit: recording and reviewing what actually happened

Audit is the process of recording, reviewing, and analyzing system activities and logs to monitor security events and detect suspicious behavior. Where accountability is about structure (making sure actions are traceable to individuals), audit is about process — actually going through the logs, reviewing what happened, and looking for anything unusual.

Putting them together with an example

Say an employee deletes some important files. Here's how these two concepts play their separate roles:

Accountability is what makes it possible to identify which user performed that deletion in the first place — because their actions are tied to their individual account.
Auditing is what lets investigators actually review the logs afterward, reconstruct the sequence of events, and understand what happened and when it happened.

Without accountability, you might have logs, but they'd be meaningless — you wouldn't be able to tell whose actions they represent. Without auditing, you might have perfectly traceable accounts, but no process for actually reviewing what any of them did.

Why both matter together

Both accountability and auditing are essential for maintaining security and enabling proper investigation after incidents. They're not really competing concepts — one sets up the traceability, and the other actively uses that traceability to investigate. Security teams rely on both constantly, whether they're doing routine compliance checks or investigating an actual breach.

Authentication vs Authorization — "Who Are You?" vs "What Can You Do?"

Khalif AL Mahmud — Thu, 16 Jul 2026 15:21:33 +0000

If you've ever built a login system, or even just used one as a regular internet user, you've interacted with authentication and authorization dozens of times without necessarily separating the two in your head. They usually happen back to back, which is probably why people mix them up so often. But they're solving two completely different problems.

Authentication: confirming who you are

Authentication is the process of confirming who a user actually is. It verifies the identity of the person trying to access a system, before anything else happens.

Common examples of authentication:

Usernames and passwords
Fingerprints
Face recognition
One-Time Passwords (OTP)

Whenever you type in a password or scan your face to unlock an app, that's authentication doing its job — proving that you are, in fact, who you claim to be.

Authorization: deciding what you're allowed to do

Authorization happens after authentication. Once the system knows who you are, authorization determines what resources or actions you're actually allowed to access.

A good example: after logging into a university portal, a student can view their grades but cannot modify them. An administrator, on the other hand, can manage student records entirely. Both the student and the administrator went through the same authentication process — logging in — but what they're allowed to do afterward is governed entirely by authorization.

The order matters

This is the part that trips people up: authentication always comes first, and authorization comes second. A system needs to know who you are before it can decide what you're permitted to do. You can't authorize an unknown identity.

A simple way to remember it

Authentication answers: "Who are you?"
Authorization answers: "What are you allowed to do?"

Why this distinction matters in real security work

A lot of real-world security incidents happen because these two get conflated or implemented sloppily. A system might correctly verify who someone is (strong authentication) but fail to properly restrict what they can do afterward (weak authorization) — which is how a regular logged-in user sometimes ends up able to access admin-level functions just by guessing a URL or manipulating a request.

Strong security needs both pieces working correctly, and independently. Nailing authentication but neglecting authorization (or vice versa) leaves a gap that attackers actively look for.

Verification vs Validation — Two Questions Every Secure System Needs to Answer

Khalif AL Mahmud — Thu, 16 Jul 2026 15:17:39 +0000

Early on, these two terms — verification and validation — sound almost identical. Same starting letter, both feel like "checking if something works," and it's easy to just use them interchangeably. But in the cybersecurity (and software) world, they actually answer two very different questions. Once you see the distinction, it becomes obvious why both are necessary.

Verification: "Are we building the system correctly?"

Verification is about checking whether a system has been built according to the specified requirements and security policies. It's a process-focused check — you're comparing what's been built against a documented spec.

Common examples of verification include:

Code reviews
Document reviews
Security configuration checks

Basically, verification asks: Did we follow the blueprint we agreed on? It doesn't necessarily ask whether that blueprint was any good — just whether you actually built what was on paper.

Validation: "Are we building the right system?"

Validation, on the other hand, checks whether the final system actually meets the real needs of the users and delivers the expected level of security. This is an outcome-focused check.

Examples of validation include:

Penetration testing
Vulnerability assessments
User acceptance testing

Validation asks a very different question: Does this thing actually work the way it's supposed to, in the real world, for real users? You could pass every verification check on paper and still end up with a system that fails validation because it doesn't hold up against actual attacks or actual user needs.

Where each one fits in the lifecycle

In the cybersecurity development lifecycle, these two checks happen at different stages:

Verification typically happens during development — you're continuously checking your work against the spec as you build.
Validation mostly happens before deployment and during testing — once there's a working system, you throw real-world conditions at it to see if it actually holds up.

Why the distinction actually matters

Imagine a team builds a login system exactly according to the security requirements document — every checkbox ticked, every review passed. That's solid verification. But then a penetration test reveals the system is still vulnerable to a specific type of attack the requirements document never accounted for. That's a validation failure, even though verification passed cleanly.

This is exactly why relying on only one of the two is dangerous. Verification without validation can give you a system that's technically "correct" but practically broken. Validation without verification can leave you fixing symptoms without ever tightening the underlying process.

Quick way to remember it

Verification → Are we building the system right?
Validation → Are we building the right system?

Simple phrasing, but it's saved me more than once when these two terms started blurring together in my notes.

FIPS vs NIST — Two Acronyms You'll Keep Running Into in Cybersecurity

Khalif AL Mahmud — Thu, 16 Jul 2026 15:12:17 +0000

If you spend any real time reading about cybersecurity standards, two acronyms show up over and over: FIPS and NIST. For a while I genuinely thought they were the same thing, just used interchangeably. They're not — but they are closely related, and understanding how they connect actually makes a lot of security documentation easier to read.

What is NIST?

NIST stands for National Institute of Standards and Technology. It's a United States government organization, and its job is to develop security frameworks, guidelines, and best practices that both government and private organizations around the world actually use.

NIST is behind a lot of the cybersecurity guidance you'll bump into if you work in this field — the most well-known one being the NIST Cybersecurity Framework, which organizations use as a reference point for how to structure their entire security program: identify risks, protect systems, detect threats, respond to incidents, and recover afterward.

What is FIPS?

FIPS stands for Federal Information Processing Standards. These are security standards specifically developed for use by U.S. government organizations. FIPS defines rules and requirements around things like encryption, data protection, and information security — basically, the technical bar that systems need to meet if they're going to be trusted with government data.

So how do they connect?

Here's the part that used to confuse me: FIPS standards are actually published and maintained by NIST. So NIST is the organization, and FIPS is one category of standards that comes out of it — specifically the ones that are mandatory for federal systems.

You can think of NIST as the broader authority producing all kinds of guidelines, frameworks, and recommendations, while FIPS is a more specific, formal, and often mandatory subset of those — particularly around cryptography and data security requirements.

Why should you care?

If you've ever seen a product description say something like "FIPS 140-2 validated encryption," that's not just marketing fluff. It means the encryption module has been tested and certified against a specific FIPS standard, which is often a requirement for software or hardware being used in government or highly regulated industries.

Even outside of government work, a lot of private companies adopt NIST frameworks and FIPS-compliant encryption voluntarily, simply because they represent a solid, well-tested baseline for security.

The bottom line

NIST = the organization that creates broad cybersecurity guidelines and frameworks
FIPS = specific, often mandatory security standards (published by NIST) mainly used by U.S. government systems

Both exist for the same underlying goal: improving information security and helping organizations actually protect their systems and data instead of guessing at what "secure enough" looks like.

Small distinction, but once it clicks, a lot of compliance documentation stops feeling like alphabet soup.

What Exactly Is a DMZ, and Why Does Every Serious Network Have One?

Khalif AL Mahmud — Thu, 16 Jul 2026 15:03:53 +0000

If you're new to networking or cybersecurity, chances are you've bumped into the term DMZ and quietly nodded along without really knowing what it means. I did the same thing until I actually sat down and worked through it for an assignment. Turns out, once you get the idea, it's one of those concepts that just clicks and suddenly a lot of network diagrams make a lot more sense.

So, what is a DMZ?

DMZ stands for Demilitarized Zone — yes, borrowed straight from military terminology, and honestly the analogy fits pretty well. In networking, a DMZ is a separate network segment that sits between your organization's internal (private) network and the public internet.

Think of it as a buffer zone. It's not fully "inside" your trusted network, and it's not fully "outside" exposed to the raw internet either. It's a controlled middle ground.

Why would you even need this buffer zone?

Here's the thing — every organization has some services that need to be reachable from the internet. Your website has to load for random visitors. Your mail server has to receive emails from anyone, anywhere. Your DNS server has to answer lookups from the outside world.

But you obviously don't want those internet-facing servers sitting on the same network as your internal file servers, employee databases, or HR systems. If a hacker breaks into your public web server, you don't want that to be a free pass straight into your company's private data.

That's exactly the problem a DMZ solves. Public-facing services like web servers, mail servers, and DNS servers get placed inside the DMZ, physically and logically separated from the sensitive internal network.

How is it actually implemented?

A DMZ is usually built using one or more firewalls. The typical setup looks something like this:

One side of the firewall connects to the internet
The other side connects to the internal network
The DMZ sits in between, isolated from both

Some setups use a single firewall with three network interfaces (internet, DMZ, internal network), while more security-conscious organizations use two firewalls — one guarding the DMZ from the internet, and a second, stricter one guarding the internal network from the DMZ itself. That second firewall is really the last line of defense.

Why go through all this trouble?

The core reason is damage control. If an attacker manages to compromise a server sitting in the DMZ, they still don't get direct access to your internal network. There's another security layer standing in the way. Worst case, you lose a public-facing server temporarily — not your entire internal infrastructure.

It's the same logic as not letting a delivery guy walk straight into your house. You let them into the porch (DMZ), hand them what they need, and the front door (internal network) stays locked regardless of what happens on the porch.

Wrapping up

A DMZ isn't some fancy advanced concept reserved for huge enterprises — it's a basic, foundational piece of network security architecture. Anywhere you're exposing services to the public internet, a DMZ is worth having. It won't stop every attack, but it drastically limits what an attacker can reach even if they do get in.

If you're studying for a networking or security course like I am, this is genuinely one of those topics worth understanding properly rather than memorizing — it comes up constantly once you start looking at real network diagrams.

AI in Cybersecurity: Why Artificial Intelligence Is Both Our Strongest Defense and a Growing Threat

Khalif AL Mahmud — Sat, 04 Jul 2026 20:57:44 +0000

AI is everywhere now. It can recognize images, understand language, and even write code on its own by learning patterns from massive amounts of data. Naturally, this same technology has found its way deep into cybersecurity — because let's be honest, the volume of threats and data generated every single day is way too much for humans to handle alone.

But here's the catch: AI in cybersecurity isn't a one-sided story. It's being used for defense and offense, by the good guys and the bad guys, at the same time. Let's break it down.

How AI Is Actually Used in Cybersecurity

On the defense side, AI shows up in a few key ways:

Behavioral Analytics — AI learns what "normal" looks like for a user or network, so it can flag anomalies almost instantly.
SIEM (Security Information and Event Management) — AI helps sift through huge volumes of log data, cutting down false positives and surfacing real threats.
SOAR (Security Orchestration, Automation and Response) — systems can automatically respond to attacks, like blocking a malicious IP or isolating a compromised device, without waiting for a human to click a button.

Security researchers and pentesters also lean on AI for automated vulnerability scanning, source code analysis, and simulating real-world attacks through red teaming.

On the offense side, though, the exact same intelligence is being weaponized. Attackers use AI to build polymorphic malware — malicious code that rewrites itself every time it runs, making it nearly invisible to signature-based antivirus tools.

The Tools Changing Pentesting Right Now

A few AI-driven tools are quietly reshaping how penetration testing works:

PentestGPT — an LLM-powered assistant that walks through pentest methodology step by step, suggesting what technique to try next on a given target.
Burp AI — an AI feature built into Burp Suite that analyzes HTTP requests and explains potential vulnerabilities in plain language.
XBOW — a more autonomous platform that can find and exploit vulnerabilities on its own, then generate the report.

These tools point toward a future where AI-assisted workflows shrink the amount of manual grunt work in pentesting — but as we'll get to, they don't remove the human from the loop entirely.

The Real Advantages

Speed and scale — analyzing thousands of logs instantly is trivial for AI, brutal for humans.
Catching unknown threats — pattern recognition can flag zero-days even without a known signature.
Fewer false positives — context-aware alerts mean analysts stop drowning in noise.
Automated response — SOAR systems act the moment an attack is detected.
Doing more with less — even small security teams can now monitor large infrastructure.

The Limitations Nobody Should Ignore

Dual-use risk — anything built for defense can be repurposed for attack (AI-written phishing emails, polymorphic malware).
The black box problem — it's often impossible to explain why an AI model made a decision, which becomes a real headache when that decision needs to hold up as evidence.
False negatives — a poorly trained model can simply miss a real threat.
Garbage in, garbage out — AI is only as good as the data it was trained on.
Human verification is non-negotiable — trusting an AI-generated report or payload blindly is a mistake waiting to happen.

What an AI-Assisted Pentest Workflow Actually Looks Like

Recon — gathering target information using tools like Shodan, Censys, plus AI-assisted OSINT.
AI Analysis — an LLM reviews the collected data and flags potential vulnerabilities.
Payload/Exploit Suggestions — tools like PentestGPT propose exploit ideas, which are never used blindly.
Human Validation — a real pentester checks everything before it ever reaches a client report.

Speed and efficiency come from the AI. The final call still belongs to a human.

Where This Is All Heading

The numbers here are genuinely wild: a cyberattack happens roughly every 39 seconds, and global cyber damage is projected to hit around $10.5 trillion by 2026. At the same time, there are over 3.5 million unfilled cybersecurity jobs worldwide. Put those two facts together and it's obvious why AI-augmented defense isn't optional anymore — it's how the industry keeps up.

Expect Agentic AI — systems that can run an entire pentest or threat-hunting operation with minimal human input — to keep advancing. But the threat side is evolving just as fast: AI-generated malware, deepfake-based fraud, and hyper-convincing AI phishing are only going to get more sophisticated. Understanding how these tools work, and where they fall short, is becoming a baseline skill for anyone in security — not a nice-to-have.

Cyber Law and Ethics in the Age of AI

Technology moves fast. Law, by nature, moves slower. That gap is exactly where most of today's problems live.

What Cyber Law Actually Covers

At its core, cyber law exists to:

Protect data — safeguarding sensitive user information and privacy.
Prevent crime — defining and punishing things like unauthorized access and data breaches.
Protect intellectual property — covering copyrights on digital content and software.
Legitimize e-commerce — making online transactions safe and enforceable.

In short, cyber law defines who's allowed to do what in the digital world — and what happens when they don't.

What Cyber Ethics Actually Means

Ethics is the part that isn't always written into law but absolutely should guide how a security professional behaves. It rests on three pillars:

Integrity — never making harmful changes to a client's system, and never exploiting a found vulnerability for personal gain.
Privacy — never leaking sensitive data, source code, or credentials discovered during testing.
Accountability — staying within scope and delivering complete, honest reports.

Technical skill makes someone a hacker. Ethics and legal compliance are what make someone a security professional.

Cybercrime Has Changed Shape

The old advice — "check for spelling mistakes in phishing emails" — barely applies anymore. AI tools (including malicious variants of language models) can now scrape someone's LinkedIn or social profile and generate a perfectly personalized, grammatically flawless spear-phishing email.

Deepfake-driven executive impersonation is another major shift — fake audio or video of a company executive used to authorize fraudulent transfers. One well-documented case involved a multinational company losing roughly $25 million this way.

Malware itself has evolved too: polymorphic and metamorphic code rewrites its own structure on every execution, defeating traditional signature-based detection.

All of this creates brand-new legal headaches:

Attribution problem — proving who actually launched an attack.
Cross-border jurisdiction — whose laws apply when the attacker and victim are in different countries?
Algorithmic black box — how do you prove intent or fault in court when an AI system acted semi-autonomously?

What "Legal Use" of AI in Security Actually Requires

The one condition that separates legal from illegal use of AI in security work is simple: written consent. Testing a system you have explicit permission to test, participating in an official bug bounty program, or running malware analysis in your own isolated lab — all fine. Accessing a system without authorization, sniffing traffic on public networks, or using AI-generated exploits to steal and sell data — all firmly illegal, regardless of how the AI was used.

Internationally, frameworks like the EU AI Act and the NIST AI Risk Management Framework are starting to formalize this. The EU AI Act, for instance, requires strict audits for high-risk AI systems and mandates watermarking for deepfake content.

Using AI Tools Ethically

A few ground rules that matter regardless of jurisdiction:

Responsible disclosure — if you find a vulnerability, report it to the vendor privately (commonly with a 90-day window to patch) instead of dropping it publicly.
Know the model's limits — AI suggestions are not automatically correct. Treat them as a starting point, not gospel.
Don't break production — intentionally crashing a client's live system to "prove a point" is unethical, full stop.
Respect scope — testing anything outside the agreed boundaries is off-limits, even if you stumble onto a real bug there.

And here's the line that matters most: "the AI made a mistake" is not a legal defense. Responsibility always sits with the human operating the tool.

Rules of Engagement (ROE) and Scope

Before any penetration test begins, a signed Rules of Engagement agreement should be in place. It typically covers:

What the tester is and isn't allowed to do.
A defined testing window (often off-peak hours).
Which tools/techniques are permitted (e.g., is automated AI-driven exploitation allowed? Social engineering?).
An emergency contact in case something breaks mid-test.

Scope then draws the exact boundary — which domains, IPs, or applications are in-scope, and which (like third-party payment gateways or cloud infrastructure you don't own) are strictly off-limits. Skipping the ROE step isn't just risky — it can turn a legitimate test into an actual crime.

Why Responsible Practice Matters More Than Ever

Because AI-driven threats evolve faster than legislation can keep up, professionals need to hold themselves to a higher bar than the law strictly requires. That means:

Keeping meticulous documentation and command logs.
Maintaining proper chain of custody for sensitive data.
Securely wiping any collected data per agreed policy once the engagement ends.
Following established frameworks like OWASP and NIST.
Testing new tools or exploits in an isolated lab before anywhere near production.

The real goal is avoiding two traps: being legal but unethical, or ethical but illegal. A serious security professional has to satisfy both — because technical skill alone won't protect your career or credibility if either one slips.

The Takeaway

AI is now a genuine dual-use technology in cybersecurity — a force multiplier for defenders and attackers alike. Tools like PentestGPT, Burp AI, and XBOW make the work faster, but the final judgment call still has to be human, because when AI gets something wrong, the AI doesn't carry the consequences — the person using it does.

Technical skill can make someone a hacker. Ethics, scope discipline, and legal compliance are what make someone a security professional. And since AI keeps outpacing the law, new problems like attribution and jurisdiction are only going to get messier. Building ethics and responsibility alongside technical ability isn't optional anymore — it's the actual job.