Part 1: Port Scanning (Lab, Detection, and Architecture)

A port scan is the digital equivalent of walking through a neighborhood checking which doors and windows are unlocked. It is the primary tool used in the Reconnaissance and Weaponization stages of the Cyber Kill Chain.

1. The Types of Scans (What the SOC is looking for)

• TCP SYN Scan (Stealth/Half-Open): The scanner sends a SYN. If the port is open, the target replies with SYN-ACK. The scanner immediately sends an RST (Reset) to tear down the connection before it fully establishes. This bypasses legacy application logs because the application never saw a full connection.
• TCP Connect Scan: Completes the full 3-way handshake. Noisy and easily logged by the target application, but required if the scanner doesn’t have raw socket privileges (e.g., scanning from a standard user account).
• UDP Scan: Sends empty UDP packets. If an ICMP “Port Unreachable” message comes back, the port is closed. If nothing comes back, it’s assumed open (or filtered). Highly unreliable and slow.
• ACK Scan: Doesn’t find open ports; it maps Firewall Rules. By sending ACK packets, the scanner can tell if a stateful firewall is blocking the traffic (filtered) or if it’s passing through to the host (unfiltered).

2. The Port Scanning “Lab” Environment

If you are setting up a lab to train SOC analysts or practice yourself, never scan production networks or public IPs you do not own (this is illegal and will get you blocked by your ISP).

• Safe Lab Platforms: Use platforms like TryHackMe (e.g., the “Nmap” and “Network Fundamentals” rooms) or Hack The Box. They provide isolated, legal, vulnerable targets.
• Local Virtual Lab: Build a local hypervisor (VMware/VirtualBox) with an isolated virtual network. Deploy a Kali Linux VM (the attacker) and a Metasploitable or intentionally vulnerable Windows/Linux VM (the target).
• Modern Tools to Master: While Nmap is the gold standard, modern SOC analysts and Red Teamers use Masscan or RustScan for internet-scale, high-speed asynchronous scanning.

3. The Defender’s Perspective: Detecting and Mitigating Scans

As a Platform Security Architect, your goal is to make port scanning useless to the attacker.

• Detection (How the SOC sees it):
  • Network Level: NDR (Network Detection and Response) or Firewall logs showing a single source IP attempting connections to multiple destination ports on a single host (Vertical Scan) or a single port across multiple hosts (Horizontal Scan).
  • Cloud Level: VPC Flow Logs (AWS) or NSG Flow Logs (Azure) showing massive amounts of REJECT statuses.
  • Host Level: EDR agents detecting rapid, sequential outbound/inbound connection attempts.
• The “Event vs. Incident” Trap:
  • Crucial Leadership Concept: A port scan is an EVENT, not an INCIDENT. An event is an observable occurrence. It only becomes an incident if the scan successfully identifies an open port, an exploit is launched, and a policy violation or breach occurs. The SOC should not wake up the CISO for a port scan; they should log it, enrich it with Threat Intel, and monitor the source IP for follow-up exploitation.
• Architectural Mitigation:
  • Default Deny: Ensure all cloud Security Groups and on-prem firewalls deny all inbound traffic by default.
  • Attack Surface Management (ASM): Continuously scan your own external IP space to find shadow IT and exposed ports before the attackers do.

---

Part 2: Incident Response (IR) Phases

When an event (like a successful exploitation following a port scan) becomes a true incident, the SOC and Security Leadership must follow a structured framework. The industry standard is the SANS 6-Step Model (PICERL), which aligns closely with NIST SP 800-61.

As a security leader, you are responsible for ensuring the organization is mature across all six phases.

1. Preparation (The Architect & Leader’s Domain)

This is the most critical phase. If you fail here, the response will be chaotic.

• Actions: Developing IR plans and playbooks, deploying and tuning the SIEM/SOAR, ensuring logging is enabled everywhere, establishing communication trees (who calls Legal? who calls the PR team?), and conducting Tabletop Exercises (TTX).
• Leadership Focus: Ensuring the team has the legal authority to isolate a critical Fintech production server at 2 AM without waiting for executive approval.

2. Identification (Detection & Analysis)

The SOC determines that a security breach has actually occurred.

• Actions: Triage alerts, perform log analysis, pivot on IOCs (Indicators of Compromise), and determine the scope (blast radius) of the incident.
• Leadership Focus: Ensuring the SOC has the telemetry they need. If the attacker moved laterally via SMB, but SMB traffic wasn’t being logged by the NDR, Identification fails. Declaring the incident and shifting the team into “War Room” mode.

3. Containment (Stopping the Bleeding)

This is the most high-pressure phase. The goal is to stop the attacker from causing more damage without destroying forensic evidence.

• Short-Term Containment: Isolating the affected systems. Modern approach: Using EDR to “network isolate” the host (it can only talk to the SOC management server) rather than physically unplugging it, which destroys RAM evidence.
• Long-Term Containment: Applying temporary patches, disabling compromised Active Directory accounts, or revoking stolen AWS IAM keys (via CyberArk/Okta) while the business continues to operate.
• Leadership Focus (The Fintech Dilemma): In a Fintech or OT environment, you cannot always just “shut down” the compromised server, as it might halt million-dollar payment processing or physical safety systems. You must architect graceful degradation and failover mechanisms so containment doesn’t cause a self-inflicted Denial of Service.

4. Eradication (Removing the Threat)

Once contained, the threat must be completely removed from the environment.

• Actions: Deleting malware, disabling rogue accounts, removing malicious artifacts, and most importantly, patching the root cause vulnerability that allowed the initial breach.
• Leadership Focus: Ensuring IT Operations and Cloud Engineering work seamlessly with the SOC to apply the patches. Eradication is incomplete if the attacker’s backdoor is removed but the unpatched vulnerability they used to get in is left open.

5. Recovery (Restoring Operations)

Returning systems to normal business operations securely.

• Actions: Restoring systems from clean, immutable backups, rebuilding compromised servers from golden images, and gradually restoring network connectivity.
• Leadership Focus: Implementing Enhanced Monitoring. Systems recovering from an incident must be watched with hyper-vigilance for 48-72 hours, as attackers often leave secondary backdoors or attempt to re-compromise the restored system.

6. Lessons Learned (Post-Incident Activity)

The phase most often skipped, but the most valuable for a Head of Platform Security.

• Actions: Holding a blameless post-mortem meeting within 14 days of incident closure. Documenting what went well, what failed, and what needs to change.
• Leadership Focus: Translating the technical failures into architectural and budgetary improvements. (e.g., “The SOC took 4 hours to contain the ransomware because we lacked automated SOAR playbooks for EDR isolation. I am requesting $X budget to mature our SOAR capabilities.”)