DEV Community: Soumya Ranjan 🎖️

The 8 CISSP Security Domains You Probably Don’t Think About — But Should

Soumya Ranjan 🎖️ — Mon, 13 Apr 2026 16:58:33 +0000

When people hear “cybersecurity,” they usually think of firewalls, hackers, or antivirus software. What they don’t realize is that security is much bigger than tools. That’s why CISSP breaks security into eight domains — each one representing a real area where things can go wrong if ignored.

Below is a practical walkthrough of all eight domains, explained with real situations and what role a security professional actually plays.

1. Security and Risk Management

This domain is about understanding what needs protection, why it matters, and what level of risk is acceptable. It covers policies, laws, compliance, ethics, and decision-making at an organizational level.

Imagine a company planning to outsource part of its operations to a third-party vendor. The vendor asks for access to internal systems. At this point, security is not about blocking everything — it’s about assessing risk. What data will the vendor access? What happens if it’s leaked? What controls should be applied?

The security professional’s role here is to identify risks, recommend controls, ensure compliance with laws and regulations, and help leadership make informed decisions. This domain sets the foundation for every other security action.

2. Asset Security

Asset security focuses on what data exists, where it lives, who owns it, and how it should be protected. Not all data is equal, and treating everything the same creates both security gaps and operational problems.

Consider an organization that stores customer emails, payment information, and public marketing content. If a developer copies all of it into a shared drive without restrictions, that’s a problem. Sensitive data must be classified, protected, and handled differently from public data.

In this domain, security teams define data classification levels, control how data is stored and transferred, and ensure sensitive information is encrypted, restricted, and properly disposed of when no longer needed.

3. Security Architecture and Engineering

This domain deals with designing systems that are secure by default, not patched later. It covers encryption, operating systems, hardware security, and secure design principles.

For example, when a new application is being built, decisions like where encryption is applied, how secrets are stored, and how services communicate matter a lot. A weak design can make even the best monitoring useless.

Security professionals in this area review system designs, perform threat modeling, recommend secure architectures, and ensure that security is built into systems from the start — not added after a breach.

4. Communication and Network Security

This domain focuses on how data moves — across networks, between systems, and over the internet. It includes network segmentation, secure protocols, firewalls, VPNs, and intrusion detection.

Imagine an attacker gains access to one machine in a company network. If the network is flat, the attacker can move freely. If it’s segmented and monitored, the damage is limited and detectable.

Here, security teams design secure network architectures, monitor traffic, detect suspicious activity, and respond to network-based attacks. This domain is critical for limiting blast radius during incidents.

5. Identity and Access Management (IAM)

IAM is about who gets access to what, when, and how. It covers authentication, authorization, identity lifecycle, privileged access, and multi-factor authentication.

A common real-world scenario: an employee leaves the company, but their account is not disabled. Weeks later, that account is used to access internal systems. That’s an IAM failure.

Security professionals manage user access, enforce least privilege, implement MFA, and ensure accounts are created, modified, and removed properly. Many breaches happen not because of advanced hacking, but because access wasn’t controlled correctly.

6. Security Assessment and Testing

This domain ensures that security controls actually work. It includes vulnerability scanning, penetration testing, audits, and continuous testing.

For example, a vulnerability scan might reveal an exposed admin interface. A penetration test might show how that exposure can be exploited. Without testing, organizations often assume they’re secure when they’re not.

The security role here is to test systems, validate findings, prioritize fixes, and confirm that vulnerabilities are properly resolved. This domain turns assumptions into evidence.

7. Security Operations

Security operations is where the real action happens day to day. It covers monitoring, logging, incident response, forensics, disaster recovery, and business continuity.

Imagine an alert shows unusual outbound traffic from a server. The priority is not to write reports — it’s to contain the threat, stop data loss, investigate what happened, and recover safely.

Security professionals in this domain follow incident response plans, analyze logs, coordinate response efforts, and ensure systems can recover after incidents. This domain separates theory from real-world pressure.

8. Software Development Security

This domain ensures that applications are built securely, not just protected after deployment. It covers secure coding, code reviews, dependency management, and security in CI/CD pipelines.

A simple coding mistake like improper input validation can lead to SQL injection or data leaks. If security is part of development, these issues are caught early. If not, they reach production.

Here, security professionals work closely with developers to integrate security into the development process, run automated tests, review risky code changes, and promote secure coding practices.

Conclusion

The eight CISSP domains are not just exam topics — they represent how security works in the real world. Every breach, incident, or failure usually touches more than one domain.

Strong security comes from understanding all eight areas and knowing how they connect. Whether you’re a SOC analyst, engineer, or security leader, these domains help you think clearly, act responsibly, and protect what truly matters: data, systems, and people.

Foundation of Cybersecurity

Soumya Ranjan 🎖️ — Thu, 22 Jan 2026 17:53:28 +0000

the 1st question. What is cybersecurity ?

Lets understand it by an example.

Imagine you have received a alert that a storm is coming. So you prepared by gathering tools, necessary material, food and water. You looked for the valuable items. Locked the doors and windows. the storm hits and there are powerful winds and rain.

The storm uses its power to breach into your house. you noticed that there are some leaks. You stood up and started the patching. You saw some water dripping from the roof to the floor. You put a bucket to prevent the damage for the floor.

Preventing and handling cyber attack is no difference. Organization must keep tools, rules, and prepare themselves to prevent and mitigate these type of attack or threats.

Definition: Cybersecurity is the practice of protecting information by ensuring its confidentiality, integrity, availability safeguarding peoples, network, and devices, from unauthorized access and exploitation.

What is Threat ?

Threat is a action done by threat actors to disrupt the operation, damage of asset, and information. There are mainly 2 type of threats. Internal threat and External threat.

internal threat arises inside the organization. This may be a person who works in the organization.

What is a Threat Actor ?

Threat actor is a person or group of person who intentionally harms the organization.

The 8 CISSP Security Domains You Probably Don’t Think About — But Should

Soumya Ranjan 🎖️ — Wed, 21 Jan 2026 16:39:20 +0000

Below is a practical walkthrough of all eight domains, explained with real situations and what role a security professional actually plays.

1. Security and Risk Management
This domain is about understanding what needs protection, why it matters, and what level of risk is acceptable. It covers policies, laws, compliance, ethics, and decision-making at an organizational level.

Asset Security

Security Architecture and Engineering

This domain deals with designing systems that are secure by default, not patched later. It covers encryption, operating systems, hardware security, and secure design principles.

Communication and Network Security

This domain focuses on how data moves — across networks, between systems, and over the internet. It includes network segmentation, secure protocols, firewalls, VPNs, and intrusion detection.

Imagine an attacker gains access to one machine in a company network. If the network is flat, the attacker can move freely. If it’s segmented and monitored, the damage is limited and detectable.

Identity and Access Management (IAM)

IAM is about who gets access to what, when, and how. It covers authentication, authorization, identity lifecycle, privileged access, and multi-factor authentication.

A common real-world scenario: an employee leaves the company, but their account is not disabled. Weeks later, that account is used to access internal systems. That’s an IAM failure.

Security Assessment and Testing

This domain ensures that security controls actually work. It includes vulnerability scanning, penetration testing, audits, and continuous testing.

The security role here is to test systems, validate findings, prioritize fixes, and confirm that vulnerabilities are properly resolved. This domain turns assumptions into evidence.

Security Operations

Security operations is where the real action happens day to day. It covers monitoring, logging, incident response, forensics, disaster recovery, and business continuity.

Imagine an alert shows unusual outbound traffic from a server. The priority is not to write reports — it’s to contain the threat, stop data loss, investigate what happened, and recover safely.

Software Development Security

This domain ensures that applications are built securely, not just protected after deployment. It covers secure coding, code reviews, dependency management, and security in CI/CD pipelines.

A simple coding mistake like improper input validation can lead to SQL injection or data leaks. If security is part of development, these issues are caught early. If not, they reach production.

Here, security professionals work closely with developers to integrate security into the development process, run automated tests, review risky code changes, and promote secure coding practices.

Conclusion

The eight CISSP domains are not just exam topics — they represent how security works in the real world. Every breach, incident, or failure usually touches more than one domain.

A Boolean Is a Bit — So Why Does It Take a Byte?

Soumya Ranjan 🎖️ — Tue, 13 Jan 2026 17:45:35 +0000

Introduction

In computer science theory, a boolean is the simplest data type: it’s either a 0 or a 1. It represents a single bit of information.

But in practice, if you declare a boolean variable in almost any high-level programming language—JavaScript, Python, Java—it takes up at least one full byte (8 bits) of memory. Often, due to object overhead and memory alignment, it takes up even more.

This is a small inefficiency that we usually ignore. Memory is cheap, right? But this discrepancy—between what a boolean is and how it’s stored—bugged me. It’s a paradox of modern abstraction: to make things easy to use, we waste 87.5% of the space.

This small curiosity led me to build ByteFlags.

The Real Problem

Why does this matter? For a simple "ToDo" app, it doesn't.

But consider a system where state is everywhere.

Feature Flags: A user might have isBetaTester, hasDarkTheme, emailVerified, notificationsEnabled, marketingOptIn, etc.
Game Development: An entity has states like isJumping, isGrounded, isInvincible, isDead.
Permissions: canRead, canWrite, canDelete, canExecute.

If you store these as separate boolean properties on an object, you are scattering these bits across bytes of memory. If you have millions of users or thousands of entities, that wasted space adds up. More importantly, managing unrelated booleans as loose variables can lead to messy code. You end up passing around long lists of arguments or having massive configuration objects.

I wanted a way to group these related flags into a single, compact unit.

Theory vs. Reality

So why do languages do this? Why isn't a boolean just a bit?

The reality is that computer memory is byte-addressable. The CPU likes to fetch data in chunks—bytes, words (4 bytes), or double words (8 bytes). It doesn't have a direct address for "Bit #3 of Byte #1000".

To read a distinct bit, the computer has to:

Fetch the whole byte.
Filter out the other bits (masking).
Check the result.

This is faster to do if the boolean just claims the whole byte for itself. The language designers made a trade-off: waste memory to save CPU cycles and simplify syntax.

As engineers, we accept this trade-off most of the time. But sometimes, checking that assumption is where the learning happens.

The Idea Behind ByteFlag

I decided to implement the "theory" manually. I wanted to pack up to 8 boolean flags into a single number (one byte, 0-255).

The concept is simple:

Bit 0 represents Flag A
Bit 1 represents Flag B
...and so on, up to Bit 7.

If I want flags A and C to be "on", I set the 0th and 2nd bits to 1.
0000 0101 in binary is 5 in decimal.

So instead of storing { A: true, B: false, C: true }, I just store the number 5.

To make this work, I needed bitwise operations:

OR (|) to enable a flag.
AND (&) to check a flag.
XOR (^) to toggle a flag.
NOT (~) to disable a flag.

Implementation Overview

While bitwise math is efficient, it’s not readable. No one wants to see if (user.flags & 4) in production code. You forget what 4 means immediately.

My goal with ByteFlags was to hide the math behind a clean, human-readable API, while keeping the storage compact.

I built it in TypeScript to ensure type safety. Here is the high-level design:

Mapping: The user provides a map of names to bit positions.

const flags = new ByteFlags({ User: 0, Admin: 1 });

High-Level API: I exposed intuitive methods so you never have to touch a bitwise operator:

State Management:
* enable('Admin') – Sets the bit to 1.
* disable('Admin') – Sets the bit to 0.
* toggle('Admin') – Flips the bit.
* reset() – Clears all flags instantly.

Querying:
* isEnabled('User') – Returns true or false.

Serialization (The "Magic" Part):
One of the biggest pain points with bits is debugging. I added methods to make the byte human-readable:
* toJSON() – Returns { User: true, Admin: false }.
* toBinaryString() – Returns "00000001".
* toHex() – Returns "0x01".

The complexity of (1 << index) is hidden. The developer just sees flags.enable('Admin').

What I Learned

Building this small library was a reflective process.

Data Representation: It forced me to think about how data actually sits in memory. We get so used to JSON and Objects that we forget the underlying zeros and ones.
The Cost of Abstractions: Every convenience in high-level languages has a cost. Usually, it's worth it, but knowing what you are paying makes you a better engineer.
Tooling: Setting up the CI/CD pipeline, publishing to NPM, and generating documentation took more time than the code itself. "Finished" code is only 20% of a shipping product.

Conclusion

ByteFlags isn't going to replace your database or revolutionize your tech stack. It’s a micro-optimization.

But working on it reminded me that great engineering isn't always about building massive systems. Sometimes, it's about looking at the smallest unit of data—a boolean—and asking, "Why is this the way it is?"

If you are curious about bitwise operations or just want a tiny library to manage states, check out the code. It’s simple, readable, and does exactly one thing.

Repository Link

https://github.com/Soumyaranjan-17/ByteFlag