DEV Community: Raghavvram Johnson

Data handlers (CISSP)

Raghavvram Johnson — Tue, 13 Oct 2026 17:47:19 +0000

Data handlers

1. Data Subject

Who they are: The individual (natural person) to whom the personal data relates. This is the person whose information is being collected, processed, or stored.

What they do: They are the rights-holder under privacy regulations (GDPR, CCPA, etc.). They can exercise rights like access, rectification, erasure, and portability.

Data Lifecycle Stage: Creation/Collection — they are the source of data. They also appear at Disposal when exercising the "right to be forgotten."

CISSP Relevance: Domain 2 (Asset Security) — understanding whose data you protect; Domain 1 (Security & Risk Management) — legal/regulatory compliance.

2. Data Owner

Who they are: A senior-level individual (often a business unit head or C-level executive) who has ultimate accountability for a specific dataset. They "own" the data from a business perspective.

What they do:

Determines data classification and sensitivity levels
Authorizes access and approves data sharing
Ensures data quality and proper use
Bears responsibility for data breaches within their domain

Data Lifecycle Stage: Present across all stages, but most active at Creation/Collection (classification decisions) and Use/Sharing (access authorization).

CISSP Relevance: Domain 2 (Asset Security) — data classification and ownership; Domain 5 (Identity & Access Management) — access control decisions.

3. Data Auditor

Who they are: An independent party (internal or external) responsible for reviewing and verifying that data handling practices comply with policies, standards, and regulations.

What they do:

Conducts audits of data access logs and processing activities
Verifies compliance with data protection regulations
Identifies control gaps and non-compliance
Produces audit reports for management and regulators

Data Lifecycle Stage: Primarily active during Use/Processing and Retention stages, but audits can span the entire lifecycle.

CISSP Relevance: Domain 1 (Security & Risk Management) — governance, risk, and compliance; Domain 7 (Security Operations) — monitoring and auditing.

4. Data Steward

Who they are: Operational-level role responsible for day-to-day management and oversight of data assets on behalf of the Data Owner. They are the "hands-on" custodians.

What they do:

Implements data policies and standards set by the Data Owner
Manages data quality, metadata, and documentation
Handles data access requests and user provisioning
Ensures data is properly labeled, stored, and maintained

Data Lifecycle Stage: Active across all stages, particularly Storage, Use/Processing, and Retention.

CISSP Relevance: Domain 2 (Asset Security) — data handling and maintenance; Domain 5 (Identity & Access Management) — operational access control.

5. Data Controller

Who they are: The entity (person, organization, or authority) that determines the purposes and means of processing personal data. They make the "why" and "how" decisions.

What they do:

Decides what data to collect and for what purpose
Determines legal basis for processing (consent, contract, legitimate interest, etc.)
Bears primary legal responsibility for data protection compliance
Must maintain records of processing activities (ROPA)

Data Lifecycle Stage: Creation/Collection (deciding what to collect and why), Use/Processing (determining how data is used), and Disposal (retention schedules).

CISSP Relevance: Domain 1 (Security & Risk Management) — legal/regulatory compliance; Domain 2 (Asset Security) — data governance.

6. Data Processor

Who they are: An entity that processes personal data on behalf of the Data Controller. They do not decide the purpose or means — they execute the Controller's instructions.

What they do:

Performs operations like storage, retrieval, analysis, or transmission
Must process data only per the Controller's documented instructions
Implements security measures to protect data
Must notify the Controller of breaches
Often requires a Data Processing Agreement (DPA)

Data Lifecycle Stage: Primarily Storage, Use/Processing, and sometimes Sharing (if sub-processors are involved).

CISSP Relevance: Domain 2 (Asset Security) — third-party/vendor risk; Domain 1 (Security & Risk Management) — contractual and legal obligations.

7. Data Custodian

Who they are: The technical/IT professional responsible for the physical and logical protection of data assets. Unlike the Data Steward (business-focused) or Data Owner (accountability-focused), the Custodian is hands-on technical — they manage the systems, infrastructure, and controls that house the data.

What they do:

Implements and maintains security controls (encryption, backups, access controls)
Manages storage infrastructure, databases, and cloud environments
Performs backups, recovery, and disaster recovery operations
Configures and monitors technical access controls (firewalls, permissions, DLP)
Ensures data availability, integrity, and confidentiality at the technical layer
Handles data migration, archiving, and secure deletion

Data Lifecycle Stage: Active across all stages, but most critical during:

Storage — managing where and how data resides
Use/Processing — maintaining system availability and performance
Retention — enforcing retention policies and archival
Disposal — executing secure deletion, degaussing, or destruction

CISSP Relevance:

Domain 2 (Asset Security) — data handling requirements, classification enforcement
Domain 3 (Security Architecture & Engineering) — designing secure storage and processing systems
Domain 7 (Security Operations) — backup, recovery, and monitoring
Domain 5 (Identity & Access Management) — technical access control implementation

How Data Custodian Differs from Data Steward

Aspect	Data Custodian	Data Steward
Focus	Technical protection	Business/data quality
Responsibility	How data is secured	What data means and how it's used
Tasks	Backups, encryption, patching	Metadata, quality rules, access requests
Reports to	IT/Security leadership	Data Owner / Business unit
CISSP Domain	2, 3, 7	2, 5

Simple analogy: The Data Owner is the homeowner, the Data Steward is the property manager who handles tenant rules, and the Data Custodian is the security guard and maintenance crew who physically protect and maintain the building.

Summary Table

Role	Primary Responsibility	Key Lifecycle Stage	CISSP Domain
Data Subject	Rights-holder	Creation/Collection	1, 2
Data Owner	Accountability & classification	All (esp. Creation, Use)	2, 5
Data Auditor	Compliance verification	Use, Retention	1, 7
Data Steward	Operational data management & quality	All stages	2, 5
Data Custodian	Technical protection & infrastructure	Storage, Retention, Disposal	2, 3, 7
Data Controller	Determines purpose & means	Creation, Use, Disposal	1, 2
Data Processor	Executes processing on behalf	Storage, Use, Sharing	1, 2

Apache Kafka

Raghavvram Johnson — Tue, 13 Oct 2026 17:44:33 +0000

Apache Kafka is a powerful open-source distributed event streaming platform designed to handle real-time data feeds. It was originally developed by LinkedIn and is now maintained by the Apache Software Foundation. Kafka is widely used for building real-time data pipelines and streaming applications.

Core Concepts of Apache Kafka

Topics:
- A Kafka topic is a category or feed name to which records are sent by producers.
- Topics are partitioned, meaning each topic can have multiple partitions to allow parallel processing.
- Example: A topic named user_activity could store logs of user actions on a website.
Partitions:
- Each topic is divided into partitions, which are ordered, immutable sequences of records.
- Partitions allow Kafka to scale horizontally by distributing data across multiple brokers.
- Each record in a partition is assigned a unique offset.
Producers:
- Producers are applications that send data to Kafka topics.
- They can specify which partition to send data to or let Kafka decide based on a partitioning strategy.
Consumers:
- Consumers are applications that read data from Kafka topics.
- They can subscribe to one or more topics and process the data in real-time.
Brokers:
- Kafka brokers are servers that store data and serve client requests.
- A Kafka cluster consists of multiple brokers, and each broker is identified by a unique ID.
ZooKeeper:
- ZooKeeper is used for managing and coordinating Kafka brokers.
- It handles tasks like leader election for partitions and storing metadata.
Offsets:
- An offset is a unique identifier for each record within a partition.
- Consumers use offsets to keep track of their position in the topic.
Replication:
- Kafka replicates data across multiple brokers to ensure fault tolerance.
- Each partition has one leader and multiple replicas.

Kafka APIs

Producer API:
- Allows applications to send streams of data to topics.
Consumer API:
- Enables applications to read streams of data from topics.
Streams API:
- Used for building real-time stream processing applications.
Connect API:
- Facilitates integration between Kafka and other systems like databases or file systems.

Bridged, NAT, and Host-Only in Vmware

Raghavvram Johnson — Tue, 13 Oct 2026 17:42:10 +0000

VMware Workstation Pro provides three main default network modes (Bridged, NAT, and Host-Only) along with custom and specialized networking options managed through virtual switches (VMnet interfaces).

Main Network Modes

Bridged Networking (VMnet0)
- How it works: Connects the virtual machine directly to your physical local area network (LAN) using the host's physical network adapter.
- IP address: Receives a distinct IP address directly from your physical router or DHCP server on the same subnet as your host.
- Best for: Running servers, testing network services, or making the VM appear as a separate physical machine on your network.
NAT (Network Address Translation) Networking (VMnet8)
- How it works: Shares the host computer's IP address to access external networks or the internet through a built-in virtual NAT device and virtual DHCP server.
- IP address: Assigned a private IP address by VMware's internal DHCP server; inbound traffic is blocked unless port forwarding is configured.
- Best for: Safe internet access and general lab environments where the VM needs web access without exposing itself directly to the local network.
Host-Only Networking (VMnet1)
- How it works: Creates a completely isolated, private network container that links only the host and the virtual machines.
- IP address: Assigned by a virtual DHCP server on a closed internal subnet. The VM has no access to external networks or the internet.
- Best for: Secure sandboxing, offline testing, and practicing multi-machine setups like Active Directory or DNS.

Additional & Custom Options

Custom Networks (VMnet2 through VMnet255 on Linux / up to 20 on Windows)
- Allows you to use the Virtual Network Editor to build custom switch configurations (combining custom NAT, Bridged, or Host-Only rules) to isolate specific groups of VMs.
LAN Segments
- Specialized private networks that operate without a DHCP server or host connectivity.
- Best for: Multi-tier application testing or isolated multi-node cluster simulations.
Advanced Features
- Custom MAC address assignment, network throttling (simulating bandwidth limits or latency), and "Replicate physical network connection state" for mobile or Wi-Fi roaming laptops.

Here is the comparison table for the three primary network modes in VMware Workstation Pro:

Feature	Bridged (`VMnet0`)	NAT (`VMnet8`)	Host-Only (`VMnet1`)
IP Address Source	Physical network router / DHCP	VMware virtual DHCP	VMware virtual DHCP
Subnet Location	Same subnet as the host	Separate private subnet	Separate private subnet
Internet Access	Yes	Yes (via host IP)	No
Host Communication	Yes	Yes	Yes
External Network Visibility	Visible as a unique device	Hidden behind host IP	Completely hidden / Isolated
Inbound Connections	Allowed by default	Blocked (requires port forwarding)	Blocked from outside host
Best Use Case	Server hosting / Network scanning	Safe web browsing / Software updates	Malware sandboxing / Private labs

Advanced Connectivity Matrix

Feature	Bridged (`VMnet0`)	NAT (`VMnet8`)	Host-Only (`VMnet1`)
VM-to-VM Access	Yes (If on the same physical network)	Yes (If on the same `VMnet8` switch)	Yes (If on the same `VMnet1` switch)
Access from another physical device (Same Network)	Yes (Directly via VM's IP)	No (Unless Port Forwarding is configured)	No (Completely isolated from physical network)
Access from the Internet	Yes (Requires port forwarding on physical router)	Yes (Requires double port forwarding: router $\rightarrow$ host $\rightarrow$ VM)	No (Cannot be routed out)
VM Access to Host	Yes	Yes	Yes
VM Access to Same Network Devices	Yes	Yes (Outbound traffic is NATed via host IP)	No
VM Access to the Internet	Yes (Direct outbound)	Yes (Outbound via host NAT)	No
Port Forwarding Possible	N/A (Not needed; it has a direct IP)	Yes (Built into VMware Virtual Network Editor)	No
Reverse Connection / Reverse Shell Success	Yes (To any device on the network or internet)	Yes (To host, network, or internet via NAT)	Host/Internal Only (Cannot reach external devices)

Key Takeaways for Advanced Control

Reverse Connections: If you are testing reverse shells or callbacks in a security lab, NAT allows the VM to reach out to an external listening device seamlessly, while Host-Only blocks all outbound packets from leaving your local machine.
The "Vice Versa" Rule: If a VM cannot see a network (like Host-Only looking at the internet), devices on that network cannot see it either. Outbound access usually dictates inbound capability unless explicit translation (NAT/Port Forwarding) is placed in between.

Advanced Capabilities & Performance Comparison

Technical Metric / Feature	Bridged (`VMnet0`)	NAT (`VMnet8`)	Host-Only (`VMnet1`)
DHCP Management	Handled by external physical router / network team	Handled internally by VMware DHCP Service	Handled internally by VMware DHCP Service
Bandwidth & Latency Throttling	Limited by host NIC and physical switch infrastructure	Controlled via VM Network Adapter advanced settings	Controlled via VM Network Adapter advanced settings
Promiscuous Mode / Packet Sniffing	Supported (Can capture physical network broadcast traffic)	Limited (Only captures traffic passing through the NAT gateway)	Isolated (Only captures traffic within the private host vSwitch)
MAC Address Handling	Exposes VM MAC directly to the physical network switch	Masked behind the host’s physical MAC address	Never exposed to the physical network
IP Address Exhaustion Risk	High (Can exhaust company/home DHCP pool limits)	None (Uses local private `192.168.x.x` scope)	None (Uses local private `192.168.x.x` scope)
Physical Link State Replication	Supported (VM drops connection if host unplugges Ethernet/Wi-Fi)	N/A (Virtual switch link stays up even if host loses internet)	N/A (Completely independent of physical link status)
VLAN Tagging (802.1Q)	Supported (If host NIC driver allows tagging pass-through)	Not Supported	Not Supported
Host System Resource Overhead	Lowest (Packets pass straight to hardware layer)	Highest (Host CPU translates packet headers via `vmnat.exe`)	Low (Handled entirely in host kernel RAM/vSwitch)

Contextual Metrics Broken Down

Security Risk & Network Isolation: In Bridged mode, a misconfigured firewall or a compromised VM exposes your entire physical corporation or home network to risk. NAT offers a default perimeter hardware firewall behavior, while Host-Only offers standard air-gapped sandboxing.
Wi-Fi / Roaming Stability: Bridged mode frequently drops connections or fails to pull an IP address when your host laptop switches between Wi-Fi access points or moves to an 802.1X authenticated corporate network. NAT eliminates this problem because the VM only cares about its stable link to the host OS.
Virtual Network Editor Customization: While VMnet0, VMnet8, and VMnet1 are default placeholders, you can change the underlying subnets, toggle the local DHCP servers on/off entirely, or restrict IP allocation ranges manually using the VMware Virtual Network Editor utility.

Security & Threat Exposure Matrix

Security Feature / Metric	Bridged (`VMnet0`)	NAT (`VMnet8`)	Host-Only (`VMnet1`)
Default Isolation Level	None (Fully exposed to the host's physical network segment)	Partial (Inbound blocked; outbound allowed via translation)	High / Strict (Air-gapped from external networks; host-guest only)
Attack Surface Exposure	Highest (VM can be directly targeted by any device on the physical LAN)	Low (Hidden behind host IP; only targetable via explicit port forwards)	Lowest (Invisible to the outside world; targetable only by the host or internal VMs)
Malware Sandbox Suitability	Dangerous (Malware can worm/spread to physical devices on your home/office network)	Risky (Malware can dial out to Command & Control servers or scan the LAN via NAT)	Excellent (Malware is safely contained within the local virtual switch infrastructure)
Network Sniffing Risk (Host Side)	High (Host machine can easily sniff all VM traffic via local interfaces)	Medium (Host can sniff traffic passing through the virtual gateway)	Medium (Host can sniff traffic passing through the virtual gateway)
Network Sniffing Risk (LAN Side)	High (Physical network attackers can capture VM broadcast/multicast packets)	Protected (Physical LAN attackers only see the host's traffic packets)	Completely Immune (No data packets ever touch the physical medium)
IP/MAC Spoofing Impact	Severe (A malicious VM can disrupt or poison the physical network's ARP table)	Contained (Spoofing only breaks or disrupts the internal `VMnet8` virtual switch)	Contained (Spoofing only breaks or disrupts the internal `VMnet1` virtual switch)
Enterprise Policy Compliance	Often Violates (Connecting unauthorized VMs directly to corporate ports frequently trips rogue device alerts)	Usually Allowed (Appears to corporate monitoring tools as standard, single-host traffic)	Safe (Does not interact with corporate infrastructure, preserving compliance)

Key Security Implementations

The Inbound Hardware Barrier: NAT acts as a unidirectional firewall by default. External machines cannot initiate a handshake with a NAT VM unless you intentionally program a rule into the Virtual Network Editor.
The Threat of Lateral Movement: If you run a vulnerable machine (like an unpatched Windows or Linux target for hacking practice) on Bridged mode, any infected machine on your actual living room or corporate Wi-Fi can attack it, and vice versa.
True Air-Gapping: To simulate a completely isolated environment (e.g., analyzing ransomware), Host-Only is the baseline standard. To completely sever the host machine from the loop as well, you would transition the VM from Host-Only to an isolated LAN Segment.

Common JS vs ECMAScript Modules

Raghavvram Johnson — Tue, 13 Oct 2026 17:39:50 +0000

CommonJS (CJS) and ECMAScript Modules (ESM) are the two main systems used in JavaScript to organize, import, and export code across files.

Key Differences

Syntax:
- CommonJS uses require() and module.exports.
- ESM uses import and export.
Loading Mechanism:
- CommonJS loads modules synchronously (blocking) at runtime.
- ESM loads modules asynchronously and supports top-level await.
Standardization:
- CommonJS is the original module format built specifically for Node.js.
- ESM is the official W3C/ECMAScript standard supported natively in modern web browsers and Node.js.
- CommonJS does not support reliable tree-shaking (dead code elimination) because exports are dynamic and not statically analyzable.
- ESM supports static analysis, allowing bundlers to drop unused code cleanly.
File Extensions & Config:
- CommonJS uses .cjs or default .js (unless overridden).
- ESM uses .mjs, or .js when "type": "module" is declared in package.json.
Global Variables:
- CommonJS provides direct access to __dirname and __filename.
- ESM does not have these globals; instead, it relies on import.meta.url.

Feature Comparison

Feature	CommonJS (CJS)	ECMAScript Modules (ESM)
Syntax	`require()` / `module.exports`	`import` / `export`
Loading	Synchronous (blocking)	Asynchronous (non-blocking)
Browser Support	No (needs a bundler)	Yes (native)
Tree-Shaking	Limited / Not supported	Fully supported
Default in Node.js	Yes (for `.js` files)	Yes (when configured)

Which Should You Use?

Use ESM as the default choice for all new projects, modern libraries, and browser-based applications.
Use CommonJS primarily when maintaining legacy Node.js codebases, working with older tools that lack ESM support, or when migrating would cause high disruption.

🚀 Splunk Core deployment Guide: Docker Server & Arch Linux Forwarder

Raghavvram Johnson — Tue, 13 Oct 2026 17:38:28 +0000

This reference manual documents the complete architecture, configurations, and commands required to spin up a standalone Splunk indexer and securely ingest host operating system events.

Part 1: Splunk Enterprise Server (Docker Compose)

We deployed a permanent Splunk Free environment on the x86_64 architecture. Using Docker volumes ensures all indexed data, search structures, and dashboards persist through restarts.

Deployment File Configuration

Create a dedicated working directory and save this file exactly as docker-compose.yml:

services:
  splunk:
    image: splunk/splunk:latest
    container_name: splunk_free
    environment:
      # Accept the mandatory Splunk licensing terms
      - SPLUNK_START_ARGS=--accept-license
      - SPLUNK_GENERAL_TERMS=--accept-sgt-current-at-splunk-com

      # Activates the perpetual 500MB/day Free license immediately
      - SPLUNK_LICENSE_URI=Free

      # Required for internal initialization protocols
      - SPLUNK_PASSWORD=YourSecurePassword123!
    ports:
      - "8000:8000"   # Splunk Web UI Browser Console
      - "8088:8088"   # HTTP Event Collector (HEC) API Ingestion
      - "9997:9997"   # Splunk Indexer - Receiving port for Forwarders
    volumes:
      - splunk_etc:/opt/splunk/etc  # Stores configuration settings and custom apps
      - splunk_var:/opt/splunk/var  # Stores raw indexed log databases
    restart: unless-stopped

volumes:
  splunk_etc:
  splunk_var:

Operational Operations

Start Stack: docker compose up -d
Stop Stack: docker compose down
Web UI URL: Access http://localhost:8000 (Free Mode automatically routes directly into the unauthenticated workspace).

Server Configuration Constraint (Crucial Step)

Before any external machine can communicate with this container, the indexer engine must be instructed to listen on its data pipeline port:

Navigate to Settings > Forwarding and receiving.
Click Configure receiving under the Receive data column header.
Select New Receiving Port, enter 9997, and click Save.

Part 2: Host Node Log Ingestion (Arch Linux)

Because Arch Linux relies natively on systemd-journald instead of traditional structural text files (like syslog), we implemented a direct, low-overhead native script architecture.

Install the Agent Binary via AUR

Install the stable binary tracking from the Arch User Repository:

paru -S splunkforwarder

Initial Setup Credentials

Initialize the runtime parameters to establish the root control passwords:

sudo /opt/splunkforwarder/bin/splunk start --accept-license

(Provide username admin and create a distinct local agent password when prompted, then stop the session via sudo /opt/splunkforwarder/bin/splunk stop to return control to systemd).

Establish System Target Routing

Map the outbound forwarding path toward the container server. If the agent runs on the same underlying operating system as Docker, target the internal loopback:

sudo /opt/splunkforwarder/bin/splunk add forward-server 127.0.0.1:9997 -auth admin:<YourForwarderPassword>

Overcome Arch Systemd Journal Security Boundaries

The splunk daemon user created by the package must be explicitly allowed to look inside binary operating system logging streams:

sudo usermod -aG systemd-journal splunk

Configure Native Journal Ingestion File

Rather than fighting text-file translation limits, manually specify a high-performance native journald input receiver stream.

Open the system configuration manager:

sudo nvim /opt/splunkforwarder/etc/system/local/inputs.conf

Overwrite or append the exact parameters below:

[default]
host = arch-workstation

[journald://system_logs]
disabled = false
index = main
sourcetype = journald

Permission Realignment & Service Activation

Force a complete runtime ownership sync on application directories and hand engine lifecycle tracking to the native scheduler:

sudo chown -R splunk:splunk /opt/splunkforwarder
sudo chmod -R 755 /opt/splunkforwarder
sudo systemctl enable --now splunkforwarder.service

Part 3: Telemetry Analysis

To confirm telemetry streams are transmitting across isolation boundaries, load the Splunk Search Panel and run the following queries:

Verify Infrastructure Logs Inbound:
```
index="main" sourcetype="journald"
```
Verify Client-to-Server Health Interconnectivity:
```
index="_internal" sourcetype="splunkd"
```

And Congratulations, you have successfully installed Splunk Free Edition

🔐 Demystifying NIST SP 800-53

Raghavvram Johnson — Fri, 02 Oct 2026 12:53:48 +0000

If you’re getting started with Cybersecurity, GRC, Compliance, or Security Engineering, you’ll eventually come across NIST SP 800-53.

But what exactly is it?

🏛️ What is NIST?

NIST stands for the National Institute of Standards and Technology.

It is a non-regulatory agency of the U.S. Department of Commerce, founded in 1901.

NIST develops standards, guidelines, and frameworks that help organizations manage technology, security, privacy, and risk.

🔐 What is NIST SP 800-53?

NIST Special Publication 800-53 is a comprehensive catalog of security and privacy controls for information systems and organizations.

In simple terms:

NIST 800-53 tells you what security and privacy controls you should consider implementing to manage risk.

It is widely used as a foundation for building and assessing security programs, particularly in U.S. federal environments.

📌 What does "Revision 5" mean?

Revision 5 is the fifth major revision of NIST SP 800-53.

It significantly modernized the publication by:

• Integrating privacy controls
• Introducing a more flexible, organization-centric approach
• Moving away from controls being tied strictly to specific technologies
• Expanding coverage for modern cybersecurity and supply-chain risks

📊 NIST SP 800-53 Rev. 5 — The Numbers

The catalog contains:

🔹 20 Control Families

🔹 ~1,200 total controls and control enhancements

🔹 Approximately 300 base controls, with the remainder consisting largely of control enhancements.

Impact-based baselines are also defined, with controls/enhancements allocated across:

• Low: 149
• Moderate: 287
• High: 370

🧩 The 4-Level Hierarchy

Think of NIST 800-53 like a tree:

Level 1 — The Catalog

The complete NIST SP 800-53 Rev. 5 catalog containing the security and privacy controls.

Level 2 — Control Families

The catalog is organized into 20 families, each covering a broad security or privacy domain.

Examples:

• AC — Access Control
• IR — Incident Response
• SC — System and Communications Protection
• SR — Supply Chain Risk Management

Level 3 — Base Controls

These are the foundational requirements within each family.

For example:

AC-2 — Account Management

Level 4 — Control Enhancements

Enhancements add additional requirements or rigor to a base control.

For example:

AC-2(1) — Automated System Account Management

So you can think of it as:

NIST SP 800-53
→ Control Family
→ Base Control
→ Control Enhancement

Once you understand this hierarchy, navigating NIST 800-53 becomes much less intimidating.

🔐 Cybersecurity isn't just about tools. It's also about understanding the controls, processes, and frameworks that define how security is managed.

Simple TCP Server in Python

Raghavvram Johnson — Thu, 01 Oct 2026 16:33:35 +0000

TCP Server

Creating TCP servers in Python is just as easy as creating a client. You might want to use your own TCP server when writing command shells or crafting a proxy (both of which we’ll do later). Let’s start by creating a standard multi-threaded TCP server. Crank out the code below:

import socket
import threading

bind_ip = "0.0.0.0"
bind_port = 9999

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind((bind_ip, bind_port))
server.listen(5)
print(f"[*] Listening on {bind_ip}:{bind_port}")

def handle_client(client_socket):
    request = client_socket.recv(1024)
    print(f"[*] Received: {request.decode()}")
    client_socket.send(b"ACK!")
    client_socket.close()

while True:
    client, addr = server.accept()
    print(f"[*] Accepted connection from: {addr[0]}:{addr[1]}")
    client_handler = threading.Thread(target=handle_client, args=(client,))
    client_handler.start()

To start off, we pass in the IP address and port we want the server to listen on.
Next we tell the server to start listening with a maximum backlog of connections set to 5.
We then put the server into its main loop, where it is waiting for an incoming connection.
When a client connects, we receive the client socket into the client variable, and the remote connection details into the addr variable.
We then create a new thread object that points to our handle_client function, and we pass it the client socket object as an argument.
We then start the thread to handle the client connection, and our main server loop is ready to handle another incoming connection.
The handle_client function performs the recv() and then sends a simple message back to the client.

import socket

target_host = "127.0.01"
target_port = 9999

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect((target_host, target_port))
client.send(b"AAABBBCCC")
response = client.recv(4096)

print(response.decode())

If you use the TCP client that we built earlier, you can send some test packets to the server and you should see output like the following:

[] Listening on 0.0.0.0:9999
[] Accepted connection from: 127.0.0.1:62512
[*] Received: ABCDE

That’s it! Pretty simple.

Simple UDP Client in Python

Raghavvram Johnson — Thu, 01 Oct 2026 16:29:28 +0000

A Python UDP client is not much different than a TCP client; we need to make only two small changes to get it to send packets in UDP form.

import socket

target_host = "127.0.0.1"
target_port = 80

client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
client.sendto(b"AAABBBCCC", (target_host, target_port))
data, addr = client.recvfrom(4096)
print(data.decode())

As you can see, we change the socket type to SOCK_DGRAM when creating the socket object.
The next step is to simply call sendto(), passing in the data and the server you want to send the data to.
Because UDP is a connectionless protocol, there is no call to connect() beforehand.
The last step is to call recvfrom() to receive UDP data back.
You will also notice that it returns both the data and the details of the remote host and port.

Simple TCP Client in Python

Raghavvram Johnson — Thu, 01 Oct 2026 16:00:12 +0000

This is a guide to write a quick simple TCP client in pure python.

First of all, why would anyone need this ?
Industry Servers dosent have tools like curl or wget, and most of the time have restricted network access, so downloading using the package manager isn't possible too.

But most if not all of the time, you can find a version of python installed.

So we will try to make a TCP client without any additional libraries, just using the buit in Sockets Library

import socket

target_host = "www.google.com"
target_port = 80

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect((target_host, target_port))
client.send(b"GET / HTTP/1.1\r\nHost: google.com\r\n\r\n")
response = client.recv(4096)

print(response.decode())

We first create a socket object with the AF_INET and SOCK_STREAM parameters.

The AF_INET parameter is saying we are going to use a standard IPv4 address or hostname, and SOCK_STREAM indicates that this will be a TCP client.
We then connect the client to the server and send it some data.
The last step is to receive some data back and print out the response.
This is the simplest form of a TCP client, but the one you will write most often.

In the above code snippet, we are making some serious assumptions about sockets that you definitely want to be aware of. The first assumption is that our connection will always succeed, and the second is that the server is always expecting us to send data first (as opposed to servers that expect to send data to you first and await your response). Our third assumption is that the server will always send us data back in a timely fashion. We make these assumptions largely for simplicity’s sake. While programmers have varied opinions about how to deal with blocking sockets, exception-handling in sockets, and the like, it’s quite rare for pentesters to build these niceties into the quick-and-dirty tools for recon or exploitation work, so we’ll omit them.