Day 1: The AI Security Roadmap — Why Foundations Matter More Than Models | Kuldeep Singh

As a software engineer, it's tempting to jump straight into prompt injection. But if the underlying infrastructure is insecure, the AI's safety guardrails are irrelevant. Here is my curriculum for laying the bedrock: Networking, Linux, and the Threat Mindset.

📍 Journey Navigation Prev: Why I'm Learning AI Security · Next: Day 2 — Theory First, Chaos Later | Day 1 | Day 3 | Day 5 | Day 6 |

Yesterday, I shared the "Why" behind my transition into AI Security. Today is Day 1, and it's time to get tactical.

As a software engineer, it's incredibly tempting to jump straight into the high-level world of prompt injection or adversarial machine learning. But AI doesn't exist in a vacuum. It runs on servers, communicates over networks, and lives inside Linux environments.

If the underlying infrastructure is insecure, the AI's safety guardrails are irrelevant.

Today, I finalized the curriculum for my first module: Networking + Linux + Threat Mindset. This is the bedrock. Without these fundamentals, you aren't an AI Security researcher; you're just a tool user.

I have already set up my Linux environment and started the deep dive into network basics. Here is the complete syllabus I've built to bridge the gap from a Developer mindset to a Security mindset.

Phase 1: The Theory Index (Building the Knowledge)

I've broken this down into 3 core areas. The goal here isn't just to learn definitions, but to understand the security implications of how systems talk to each other.

1. Networking & Communication Fundamentals

IP & Routing: Private vs. Public IPs, Subnetting (CIDR), and Gateway logic.
The "Binding" Concept: Understanding why 127.0.0.1 is a local secret while 0.0.0.0 is a public broadcast. This is where most "accidental" AI exposures happen.
TCP/IP Deep Dive: The "body language" of the internet—3-way handshakes and TCP flags (SYN, ACK, RST, FIN, PSH).

2. Linux & Web Internals

System Fundamentals: Permissions (rwx), PIDs, and environment variables.
Network Mapping: Using ss and lsof to trace exactly which process owns which port.
Web Basics: The stateless nature of HTTP and why HTTPS is only the first step in a much larger security chain.

3. The Threat Mindset (The Core Layer)

Attack Surface Identification: Mapping what is exposed vs. what is hidden.
Trust Boundaries: Where does my "safe" code end and the "untrusted" network begin?
Assume Breach: Moving from "How do I stop them?" to "What do they see once they are already inside?"

Phase 2: The "Lab 17" (Building the Muscle)

Theory is a map; labs are the actual journey. I've committed to these 17 hands-on executions to turn concepts into instinct:

1. Network Basics: Mapping interfaces and ARP tables to see how a machine "sees" its neighbors.
2. Ports & Services: Auditing open ports and practicing the "Kill Chain" by terminating unauthorized processes.
3. Nmap Scanning: Comparing Stealth (SYN) vs. Connect scans to identify attack surfaces.
4. Wireshark Analysis: Seeing the invisible handshake in real-time packets.
5. Firewall Filtering: Observing how "Dropped" vs. "Rejected" packets change an attacker's perspective.
6. Web Server Exposure: Hosting a Python server to find and exploit unintentional data leaks.
7. HTTP Inspection: Using curl -v to strip the UI and see raw headers and server signatures.
8. The 0.0.0.0 Test: Understanding the critical boundary between local and remote access.
9. Reverse Shells (Core): Executing bash-based reverse shells to understand attacker connectivity models.
10. Shell Stability: Upgrading "dumb" shells to fully interactive TTY sessions.
11. Web Delivery Attacks: Simulating in-memory attacks via curl | bash commands.
12. Internal Service Abuse: Targeting 127.0.0.1 services after a perimeter breach.
13. Enumeration Mastery: Combining Nmap, Curl, and Netcat into a comprehensive target profile.
14. Custom Port Scanner: Writing a scanner from scratch to master socket timeouts and multi-threading.
15. Subnet Recon: Scanning a /24 range to identify lateral movement paths.
16. Misconfig Lab: Spotting .env, logs, and sensitive file exposures.
17. Attack Chain Simulation: My first end-to-end "Scan → Identify → Exploit → Access" flow.

Phase 3: The "Project 10" (The Engineer's Edge)

As an engineer, I only truly understand what I can build. I'm building these 10 tools to master the mechanics of security:

1. Upgraded Port Scanner: A multi-threaded tool with banner grabbing.
2. Network Mapper: A mini-Nmap clone for automated subnet sweeps.
3. Banner Grabbing Tool: Automating the extraction of service versions and signatures.
4. Simple Packet Sniffer: Capturing and logging source/destination traffic at the packet level.
5. Reverse Shell Generator: A utility to generate one-liner payloads for various environments.
6. Web File Server + Simulation: Practicing payload delivery via HTTP.
7. Local Service Enumerator: A post-exploitation script to find hidden internal targets.
8. Firewall Tester: Testing scan evasion and detection under different rule sets.
9. Multi-Tool Recon Script: A master automation suite for reconnaissance.
10. Attack Chain Simulator (Capstone): End-to-end automation of the full recon and access lifecycle.

The Mindset Shift: From Builder to Breaker

As a Software Engineer, I've always been rigorous about reliability, performance, and handling complex edge cases. We don't "blindly trust" our code—we test it relentlessly to ensure it performs as expected under pressure. However, the engineering mindset is fundamentally focused on intended functionality and system stability.

Now, that mindset is dead.

I am moving beyond verifying that a system works to investigating how it can be intentionally manipulated. It's not that I didn't trust my code before; it's that I'm now questioning the very environment it lives in—the ports, the network protocols, and the OS configurations that we often treat as "out of scope" during standard feature development. This foundation—Networking, Linux, and the Threat Mindset—is what will allow me to look at a complex AI system and see the architectural cracks that traditional functional testing isn't designed to find.

I've got my Linux environment ready. I've started the networking deep-dive.

The journey has begun.

Why I'm Learning AI Security — The motivation and the "why now" behind this 90-day journey
Day 2 — Theory First, Chaos Later — Structuring the learning plan before touching any tools
Day 3 — From Theory to Packets — Building the attack-defense lab environment
Day 4 — Nmap, Firewalls & the Attacker's View — First six labs: scanning, fingerprinting, and firewall control