DEV Community: Faizan Nazir

Day 17–Day 22: From Compliance to Command SOC — Building the Real Foundation of a Security Operations Center

Faizan Nazir — Tue, 04 Aug 2026 16:26:33 +0000

Day 17 — Compliance & Regulatory Foundations in SOC
When we talk about cybersecurity in enterprise environments, we are not just talking about stopping hackers. We are talking about protecting legal integrity, customer trust, and business survival. On Day 17 of my SOC Analyst journey, I focused on understanding how compliance regulations shape Security Operations Center operations. Without compliance awareness, a SOC analyst is incomplete because detection and response are deeply tied to legal obligations.

One of the most powerful global regulations is the General Data Protection Regulation, commonly known as GDPR. GDPR applies to any organization that processes personal data of European Union citizens, even if the organization is not physically located in Europe. This regulation protects personal data such as names, email addresses, IP addresses, financial details, and biometric identifiers. GDPR is built on principles such as transparency, accountability, data minimization, and integrity. What makes GDPR especially critical for SOC teams is the breach notification requirement. If a data breach occurs, the organization must report it within seventy-two hours. Failure to do so can result in penalties reaching up to twenty million euros or four percent of global annual turnover. From a SOC perspective, this means logs must be preserved, alerts must be detected quickly, and investigations must be documented clearly.

Another major standard is PCI-DSS, the Payment Card Industry Data Security Standard. PCI-DSS applies to organizations that handle credit and debit card information. Whether it is an e-commerce company or a financial institution, any entity that processes cardholder data must follow strict security controls. These include network segmentation, encryption of payment data, access control, anti-virus deployment, regular security testing, and continuous monitoring. SOC teams play a crucial role here by monitoring payment systems, identifying suspicious login attempts, detecting data exfiltration, and maintaining audit logs. If an organization fails to maintain monitoring evidence, it can lose its ability to process card payments entirely, which could be devastating for business operations.

HIPAA, the Health Insurance Portability and Accountability Act, focuses on protecting healthcare data in the United States. It safeguards Protected Health Information, including patient records, diagnosis details, insurance information, and treatment history. SOC analysts working in healthcare environments must monitor access to sensitive medical records, detect unauthorized access attempts, and ensure proper logging is maintained. A single unauthorized access event can trigger regulatory investigation and heavy penalties. This shows that compliance is not just legal paperwork; it is directly connected to SOC monitoring efficiency.

Day 18 — SOC Fundamentals: People, Process, and Technology
On Day 18, I moved deeper into understanding the structural foundation of a Security Operations Center. A SOC is not just a room filled with screens; it is a structured ecosystem built on three pillars: people, process, and technology.

The first pillar is people. Technology can generate alerts, but humans interpret them. In a typical SOC structure, Level 1 analysts are responsible for monitoring alerts and performing initial triage. They determine whether an alert is a false positive or a real threat. Level 2 analysts handle deeper investigation, malware analysis, and containment strategies. Level 3 analysts focus on threat hunting, advanced forensics, and detection engineering. Above them is the SOC manager, who ensures operational efficiency, tracks key performance indicators, and reports to executive leadership. Without skilled analysts, even the best tools fail to protect the organization.

The second pillar is process. SOC processes ensure consistency and speed. Every alert follows a defined workflow. When an alert is triggered, it is reviewed, validated, escalated if necessary, contained, and documented. Playbooks guide analysts on how to respond to phishing attacks, malware incidents, brute force attempts, and ransomware cases. Documentation is not optional; it becomes legal evidence during audits and post-incident reviews. A structured process reduces confusion and ensures no critical step is missed.

The third pillar is technology. SOC relies heavily on specialized tools to collect, analyze, and respond to threats. Technology enables scalability, but it must align with people and processes to be effective.

Day 19 — Core SOC Technologies: SIEM, SOAR, EDR, and TIP
Day 19 was focused on understanding the tools that power modern SOC environments. The most important technology in a SOC is the Security Information and Event Management system, commonly called SIEM. SIEM collects logs from servers, firewalls, endpoints, and applications. It normalizes data from different sources and correlates events to detect suspicious patterns. For example, multiple failed login attempts followed by a successful login from the same IP address may indicate a brute force attack. SIEM not only generates alerts but also stores logs for compliance and forensic purposes.

Become a Medium member
Security Orchestration, Automation, and Response, known as SOAR, enhances SIEM capabilities by automating repetitive tasks. When an alert is generated, SOAR can enrich it with threat intelligence, block malicious IP addresses, create incident tickets, and notify analysts automatically. This reduces manual workload and improves response time.

Endpoint Detection and Response, or EDR, focuses on monitoring activity at the endpoint level. It tracks process execution, file changes, registry modifications, and network connections. If a malicious process chain occurs, such as a document launching PowerShell and then executing suspicious commands, EDR provides detailed visibility into the timeline. This is essential for detecting ransomware and lateral movement.

Threat Intelligence Platforms, or TIPs, store indicators of compromise such as malicious IP addresses, domains, file hashes, and threat actor information. When integrated with SIEM and SOAR, TIP provides context to alerts, allowing analysts to quickly assess whether an indicator is associated with known threat campaigns.

Day 20 — Incident Response Lifecycle in Real SOC Operations
On Day 20, I focused on Incident Response, which is the heart of SOC operations. Incident Response follows a structured lifecycle consisting of preparation, detection, analysis, containment, eradication, recovery, and lessons learned. Preparation ensures that tools are configured and teams are trained. Detection occurs when suspicious activity is identified through alerts or user reports. Analysis determines the scope and impact of the incident.

Containment involves isolating infected systems or disabling compromised accounts to prevent further damage. Eradication removes malware and addresses vulnerabilities that allowed the attack. Recovery restores systems to normal operation using backups and verification procedures. Finally, lessons learned help improve detection strategies and prevent similar incidents in the future. SOC analysts primarily handle detection and initial containment, but understanding the entire lifecycle prepares them for advanced roles.

Day 21 — Business Continuity and Disaster Recovery in Cybersecurity
Cybersecurity does not end at containment. On Day 21, I explored how organizations maintain operations during and after a cyberattack. Business Continuity Planning ensures that critical operations continue even during a crisis. For example, if a primary data center is compromised, a secondary environment should automatically take over. This prevents financial loss and service disruption.

Disaster Recovery focuses specifically on restoring IT infrastructure after a disruption. Two critical metrics define Disaster Recovery strategies: Recovery Time Objective and Recovery Point Objective. Recovery Time Objective defines how quickly systems must be restored after an outage. Recovery Point Objective defines how much data loss is acceptable, measured in time. For example, if the RPO is one hour, backups must be performed at least every hour to ensure minimal data loss. SOC plays a supporting role by detecting incidents early, thereby reducing downtime impact.

Day 22 — Types of SOC Structures in Modern Enterprises
On Day 22, I studied different SOC models used across industries. An in-house SOC is fully operated internally by the organization. It provides complete control but requires significant investment in infrastructure and staffing. A Virtual SOC operates remotely, often cloud-based, providing cost-effective monitoring for small to mid-sized organizations.

A Co-Managed SOC combines internal teams with external Managed Security Service Providers. This shared model allows organizations to leverage external expertise while maintaining internal oversight. Finally, a Command SOC is a centralized structure that oversees multiple regional SOCs. Large multinational enterprises use this model to maintain global threat visibility and standardized security practices across locations.

By the end of Day 22, it became clear that becoming a SOC analyst is not about memorizing tools. It is about understanding compliance, structured operations, coordinated response, business resilience, and architectural security design. Compliance protects legal standing. People, process, and technology build operational strength. SIEM, SOAR, EDR, and TIP enable detection and response. Incident Response ensures structured handling. Business Continuity protects revenue. Disaster Recovery restores stability. And different SOC models reflect organizational maturity.

This is what transforms a beginner into an enterprise-ready SOC professional.

Day 11–Day 16: Cybersecurity Fundamentals Every SOC Analyst Must Master

Faizan Nazir — Tue, 21 Jul 2026 08:52:49 +0000

Introduction
Before a SOC analyst can investigate alerts, analyze logs, or respond to incidents, one foundation must be strong:

Cybersecurity fundamentals.

Between Day 11 and Day 16, we covered the core knowledge required to defend enterprise networks from real-world cyber threats.

This phase focused on understanding:

How enterprise cybersecurity works
Core security concepts (Threat, Vulnerability, Risk)
Major attack types
Ethical hacking fundamentals
Why SOC analysts must understand attacker techniques
These topics form the backbone of professional SOC work.

1️⃣ Cybersecurity Fundamentals for SOC Analysts
Essential Knowledge for Defending Enterprise Networks
A SOC (Security Operations Center) analyst is responsible for:

Monitoring security alerts
Investigating suspicious activities
Identifying attack patterns
Escalating incidents
Documenting findings
Reducing risk
In enterprise environments, cybersecurity protects:

Business operations
Customer data
Financial systems
Intellectual property
Brand reputation
Without strong fundamentals, a SOC analyst cannot:

Accurately classify incidents
Identify root causes
Detect emerging attack patterns
Create meaningful detection rules
This stage builds your defensive mindset.

2️⃣ What is Enterprise Cybersecurity? (SOC Perspective)
Enterprise cybersecurity is different from personal cybersecurity.

In an enterprise environment, you are protecting:

Hundreds or thousands of endpoints
On-premise servers
Cloud infrastructure
Active Directory
Firewalls and IDS/IPS
SIEM and EDR platforms
From a SOC perspective, enterprise cybersecurity means:

24/7 monitoring
Alert triage
Log correlation
Incident investigation
Escalation workflows
Compliance awareness
SOC analysts primarily operate in the Detect and Respond phases of security.

Prevention tools exist, but SOC ensures threats that bypass prevention are caught quickly.

3️⃣ Understanding Core Concepts
These three concepts are the foundation of all cybersecurity investigations.

3.1 Threat
Press enter or click to view image in full size

A Threat is any actor or event capable of causing harm.

Examples:

Cybercriminal groups
Nation-state actors
Insider employees
Malware
Hacktivists
Threats can be:

External (internet-based attackers)
Internal (employees or contractors)
A threat alone does not cause damage. It needs a weakness.

3.2 Vulnerability
Press enter or click to view image in full size

A Vulnerability is a weakness in a system.

Examples:

Weak passwords
Unpatched software
Open ports
Misconfigured firewalls
Outdated applications
Human error
Vulnerabilities exist in:

Software
Hardware
Network design
User behavior
If vulnerabilities are not patched, they increase attack success probability.

3.3 Risk
Risk exists when:

Threat + Vulnerability + Impact = Risk

Risk can be simplified as:

Risk = Probability × Impact

Example:

Weak password (vulnerability)
Brute force attack (threat)
Account compromise (impact)
SOC analysts aim to detect activity before risk becomes damage.

4️⃣ Attack Types (SOC Relevant)
Press enter or click to view image in full size

Understanding attack categories allows SOC analysts to quickly classify incidents.

4.1 Malware Attacks
Press enter or click to view image in full size
Press enter or click to view image in full size
Malware = malicious software.

Types include:

Virus
Worm
Trojan
Ransomware
Spyware
Malware impacts:

Files
Systems
Credentials
Network traffic
SOC detection methods:

File hash monitoring
Process analysis
EDR alerts
Network anomaly detection
4.2 Phishing & Social Engineering
Phishing manipulates users into:

Revealing credentials
Downloading malware
Transferring money
Common tactics:

Urgent email messages
Fake login pages
Impersonation (CEO fraud)
Malicious attachments
SOC detection:

Email log analysis
Domain reputation checks
Authentication anomalies after email clicks
4.3 Credential Attacks
Credential attacks target authentication systems.

Become a Medium member
Types:

Brute force
Password spraying
Credential stuffing
Indicators:

Multiple failed login attempts
Logon attempts from unusual locations
Login outside business hours
Multiple accounts targeted by one IP
SOC analysts monitor authentication logs carefully.

4.4 Insider Threats
Insider threats originate from trusted users.

Examples:

Data theft
Privilege abuse
Unauthorized access
Accidental data exposure
Indicators:

Access outside job role
Large file transfers
Privilege escalation
Access at unusual times
Insider threats are complex because activity may look legitimate.

4.5 Web-Based Attacks
Common web attacks include:

SQL Injection
Cross-Site Scripting (XSS)
File upload exploitation
Command injection
Indicators:

Suspicious HTTP POST requests
Error log spikes
Abnormal URL patterns
Database anomalies
SOC analysts review:

Web server logs
WAF logs
Application logs
4.6 DoS / DDoS Attacks
Denial of Service attacks overwhelm systems with traffic.

DoS = Single source
DDoS = Multiple distributed sources

Impact:

Service unavailability
Network congestion
Revenue loss
Indicators:

Traffic spikes
Bandwidth saturation
Repeated requests
Firewall alert patterns
SOC teams monitor NetFlow and IDS logs for detection.

5️⃣ Introduction to Ethical Hacking
Press enter or click to view image in full size

Ethical hacking is authorized security testing.

Its purpose:

Identify vulnerabilities
Simulate real-world attacks
Strengthen defenses
Ethical hackers (Red Team) simulate attackers.
SOC analysts (Blue Team) defend against them.

Understanding red team techniques improves blue team detection.

5.1 Hacking vs Ethical Hacking
Hacking refers to gaining unauthorized access to systems, networks, or data with malicious intent, such as stealing information, disrupting services, or causing financial damage. It is illegal and often driven by personal gain, revenge, espionage, or criminal activity. Ethical hacking, on the other hand, is the authorized and legal practice of testing systems for vulnerabilities in order to improve security. Ethical hackers, also known as white-hat hackers, work with permission from the organization to identify weaknesses before malicious attackers can exploit them. While both use similar technical skills and techniques, the key difference lies in intent and authorization — malicious hackers exploit systems for harm, whereas ethical hackers help strengthen defenses and protect organizations from cyber threats.

5.2 Malicious Hacking vs Ethical Hacking
Malicious hacking aims to:

Steal data
Demand ransom
Disrupt operations
Spy on organizations
Ethical hacking aims to:

Discover weaknesses
Improve detection
Strengthen incident response
Simulate attack scenarios
SOC analysts must understand both perspectives.

6️⃣ Why SOC Analysts Learn Attacker Techniques
Understanding attackers improves detection engineering.

6.1 Recognize Attack Patterns
Most attacks follow a lifecycle:

Reconnaissance
Initial access
Privilege escalation
Persistence
Command & Control
Data exfiltration
If SOC analysts understand this chain, they can detect earlier stages.

6.2 Think Like the Adversary
Attackers ask:

Where is the weakest point?
Which account has admin privileges?
How can I hide activity?
How can I maintain persistence?
SOC analysts must ask:

What logs show this?
What detection rule can identify it?
What anomaly indicates compromise?
What behavior deviates from baseline?
This mindset shift is critical for professional SOC work.

6.3 Improve Detection Rules
Example:

If attackers use encoded PowerShell commands:

Detection rule:
Alert when PowerShell runs with “-enc” parameter.

If attackers create scheduled tasks:

Detection rule:
Alert on scheduled task creation event.

Better understanding of attacker techniques leads to:

Fewer false positives
Faster detection
Stronger correlation rules
Better incident response
🎯 Why Day 11–Day 16 Was Important
This phase built:

Security vocabulary
Defensive mindset
Attack awareness
SOC-level thinking
Enterprise perspective
Without mastering these fundamentals, SIEM and log analysis later would lack context.

These six days transformed basic cybersecurity knowledge into SOC-ready foundational understanding.

🏁 Conclusion
Between Day 11 and Day 16, the focus was not tools.

It was mindset.

You learned:

How enterprises defend infrastructure
The relationship between threat, vulnerability, and risk
Major attack categories
The importance of ethical hacking
Why SOC analysts must understand attacker techniques
Strong fundamentals create strong defenders.

And strong defenders protect enterprises.

Linux File Permissions & Ownership Explained for SOC Analysts (Day 10— Linux Phase)

Faizan Nazir — Sun, 19 Jul 2026 12:48:29 +0000

Introduction
Linux is the backbone of modern infrastructure. From cloud servers and firewalls to SIEM platforms and security tools, Linux runs silently behind most enterprise environments. For a Security Operations Center (SOC) analyst, understanding Linux is not optional — it is a core skill.

One of the most critical security mechanisms in Linux is its file permission and ownership model. Attackers abuse permissions to execute malware, hide persistence, escalate privileges, and erase evidence. SOC analysts rely on permission analysis to detect anomalies, investigate incidents, and build accurate timelines.

Become a Medium member
This article covers Linux File Permissions and Ownership in deep detail from a SOC analyst’s perspective. It is designed to take you from absolute beginner to security-aware professional, with real-world examples, attack scenarios, and investigation insights.

Why Linux File Permissions Matter in SOC
In SOC operations, analysts constantly deal with:

Authentication logs
System logs
Application logs
Scripts and binaries
Configuration files
Evidence files during incident response
Every one of these objects is protected by Linux permissions.

From a SOC perspective:
Incorrect permissions = security risk
Permission changes = potential indicator of compromise
Executable permissions = possible malware
Ownership changes = possible log tampering
Understanding permissions allows SOC analysts to:

Detect unauthorized access
Identify privilege escalation
Spot malware execution
Preserve forensic evidence
Reconstruct attacker activity
Understanding Linux File Permission Basics
Linux follows a Discretionary Access Control (DAC) model. This means:

The owner of a file controls who can access it
Permissions define what actions are allowed
Every file and directory in Linux has:

A type
Permissions
An owner (user)
A group
These attributes decide:

Who can read the file
Who can modify it
Who can execute it
Viewing Permissions Using ls -l
The most common command to inspect permissions is:

ls -l
Example output:

-rw-r--r-- 1 root root 23456 Jan 20 10:30 auth.log
This single line contains critical security information.

Breaking Down ls -l Output

File Type Indicator The first character represents the file type:

→ Regular file d → Directory l → Symbolic link c → Character device b → Block device SOC Insight Unexpected symbolic links can indicate privilege abuse Writable directories can allow attackers to drop payloads Device files with wrong permissions can expose system resources
Permission String The next 9 characters represent permissions:

rw-r--r--
These are divided into three groups:

rwx | rwx | rwx
User Group Other
Each group defines what actions are allowed.

Understanding r, w, x Permissions
Read (r)
Allows viewing file content
Allows listing directory contents
SOC usage:

Reading logs
Reviewing configuration files

Inspecting scripts
Risk:

Unauthorized read access can leak sensitive data
Write (w)
Allows modifying file content
Allows deleting or renaming files
SOC risk:

Log tampering
Evidence deletion
Configuration manipulation
Write permission on logs is a major red flag.

Execute (x)
Allows running a file as a program
Allows entering a directory
SOC risk

Malware execution
Backdoor activation
Persistence mechanisms
Logs should never be executable.

User, Group, and Others Explained
Linux permissions apply to three categories:

User (Owner)
The file creator or assigned owner
Has primary control over the file
Group
A collection of users
Often used for team-based access
Others
All remaining users on the system
SOC Insight
System logs are usually owned by root
Normal users should not have write access to logs
Excessive access to “others” increases attack surface
Numeric Permission System
Linux represents permissions numerically for simplicity.

Permission Values
Read (r) = 4
Write (w) = 2
Execute (x) = 1
Values are added together.

Examples
7 = rwx (4+2+1)
6 = rw- (4+2)
5 = r-x (4+1)
4 = r-- (4)
Common Permission Modes (SOC-Relevant)
644 — rw-r--r--
Common for log files
Owner can read/write
Others can only read
755 — rwxr-xr-x
Common for scripts and binaries
Executable by all users
600 — rw-------
Used for sensitive files
SSH keys, credentials, tokens
777 — rwxrwxrwx
Extremely dangerous
Full access to everyone
Strong indicator of misconfiguration or compromise
Changing Permissions with chmod
The chmod command modifies permissions.

Syntax
chmod
Examples
chmod 644 auth.log
chmod 600 id_rsa
chmod 755 monitor.sh
SOC Relevance of chmod
Attackers often:

Add execute permission to malicious files
Remove write permission to logs after tampering
Change permissions to maintain persistence
Red Flags
Sudden execute permission on unknown files
Permission changes on /var/log
World-writable system files
Symbolic Permission Changes
Linux also supports symbolic notation:

chmod +x file.sh
chmod -w auth.log
SOC usage:

Detect when malware becomes executable
Identify defensive actions by attackers to lock logs
File Ownership Concepts
Each file has:

One owner (user)
One group
Ownership determines who can change permissions.

Typical SOC Observations
Logs owned by root
Configuration files owned by system users
Ownership changes are uncommon in normal operations
Changing Ownership with chown
The chown command changes ownership.

Syntax
chown user:group file
Example
chown root:root auth.log
chown user:group file
chown root:root auth.log
SOC Importance of Ownership Changes
Ownership changes can indicate:

Covering attacker activity
Persistence setup
Privilege escalation
SOC analysts should:

Record ownership changes
Correlate with login events
Include in incident timelines
Real-World SOC Attack Scenarios
Scenario 1: Log Tampering
Attacker gains access
Changes permissions to allow deletion
Deletes authentication logs
Removes write access to hide changes
SOC detection:

Permission audit
File metadata analysis
Timeline correlation
Scenario 2: Malware Execution
Malicious file uploaded
Execute permission added using chmod
File executed
Persistence established
SOC detection:

Unexpected executable files
Permission change logs
Process creation events
Scenario 3: Privilege Abuse
Misconfigured permissions allow normal user to modify system files
Attacker escalates privileges
SOC response:

Identify misconfiguration
Correct permissions
Document exposure
Permissions in Incident Response & Forensics
During incident response:

Permissions help preserve evidence
Incorrect permissions can contaminate forensic data
Analysts must avoid modifying timestamps
Best practice:

Always inspect permissions before analysis
Use read-only access when possible
Document original permissions
Why SOC Analysts Must Master Linux Permissions
Linux permissions are:

A defensive control
An attack vector
A forensic artifact
SOC analysts use permissions to:

Validate alerts
Detect compromise
Identify attacker behavior
Strengthen system hardening
Mastery of permissions separates a beginner from a job-ready SOC analyst.

Day 2 — Linux Phase Summary
Linux permissions control access and execution
Permissions are divided into user, group, and others
Numeric permissions simplify management
chmod modifies permissions
chown modifies ownership
Permission misuse is a strong indicator of compromise
SOC analysts must always analyze permissions during investigations
What’s Next?
In Day 10 of the Linux Phase, we move into:

Linux File System Hierarchy
/var/log deep dive
Log reading commands (cat, less, head, tail)
Real SOC log analysis
🚀 Final Note
If you are serious about becoming a SOC analyst, Linux permissions are not theory — they are daily reality. Every investigation starts and ends with access control. Learn it deeply, practice it daily, and analyze it critically.

Day 9 Linux File System Hierarchy

Faizan Nazir — Sat, 18 Jul 2026 17:18:56 +0000

Linux File System Hierarchy Explained (SOC Analyst Perspective)
When you step into the world of cybersecurity — especially into a Security Operations Center (SOC) — your relationship with an operating system changes completely. You no longer see Linux as “just an OS”. You start seeing it as a crime scene, where every directory can contain evidence, every file can tell a story, and every log can confirm or deny an attack.

One of the most important foundations for any SOC analyst is a clear and deep understanding of the Linux File System Hierarchy. Without this, log analysis, incident response, threat hunting, and even SIEM investigations become guesswork.

This article explains the Linux File System Hierarchy from a SOC Analyst’s perspective, not just what directories exist, but why they matter in real-world investigations.

Understanding the Linux File System Hierarchy
Linux follows a hierarchical, tree-like file system structure.
At the top of this hierarchy is a single directory called the root directory, represented by /.

Unlike Windows, Linux does not use multiple drive letters such as C: or D:.
Instead:

Everything exists under /
All files, folders, logs, devices, and configurations are part of one unified structure
This predictability is one of the biggest advantages for security investigations
For a SOC analyst, this means:

If an attack happens, the evidence is always somewhere inside the Linux file system hierarchy.

Understanding this hierarchy is equivalent to understanding where attackers operate and where defenders must look first.

Root Directory / – The Foundation of the System
The root directory / is the top-most directory in Linux.

Key points:

Every directory and file is a child of /
Nothing exists outside this directory
It acts as the foundation of the operating system
From a SOC perspective:

Every investigation logically starts from /
Analysts mentally map the system beginning at root
Incorrect actions at this level can impact the entire system
Root is not just a directory — it is the entry point to understanding the whole system.

/home – User Activity and Initial Compromise Zone
The /home directory contains home folders for normal (non-root) users.

What lives here:

User documents
Downloads
Scripts
Tools
User-specific configuration files
Command history files such as .bash_history
Why /home matters in SOC:

Most attacks begin with user-level compromise
Phishing attacks, stolen credentials, and malicious downloads all land here
Attackers often operate inside user directories before escalating privileges
SOC analysts examine /home to:

Identify suspicious scripts and binaries
Check hidden files used to evade detection
Review command history for attacker behavior
Confirm the initial access vector
In many incidents, /home tells you how the attack started.

/root – Privilege Escalation Evidence
The /root directory is the home directory of the root (administrator) user.

Important characteristics:

Only accessible by the root account
Normal users should never interact with this directory
SOC relevance:

Activity inside /root strongly indicates privilege escalation
Once attackers gain root access, they often operate from here
Tools, scripts, and archives found in /root are high-risk indicators
For SOC analysts:

Any suspicious activity in /root is treated as high severity
It confirms that the attacker has full control over the system
If /home shows how the attack began, /root often confirms how far it went.

/etc – Configuration and Persistence Zone
The /etc directory contains system-wide configuration files.

This directory controls:

User accounts
Authentication behavior
Service configurations
Network settings
Critical files include:

/etc/passwd – user account definitions
/etc/shadow – encrypted password hashes
/etc/ssh/sshd_config – SSH access control
/etc/crontab – scheduled tasks
SOC importance of /etc:

Attackers modify configuration files to maintain persistence
Backdoor users may be added here
SSH settings may be weakened for easier access
Cron jobs are often abused to execute malware repeatedly
SOC analysts carefully inspect /etc to detect:

Unauthorized user creation
Configuration tampering
Long-term persistence mechanisms
This directory often reveals how attackers plan to stay.

/var – Variable Data Directory
The /var directory stores data that changes frequently.

Become a Medium member
It includes:

Logs
Cache files
Runtime data
Spool files
While /var itself is important, its most critical subdirectory for SOC analysts is /var/log.

/var/log – The Heart of SOC Investigations
/var/log contains system and application log files.

This is the most important directory for any SOC analyst.

Typical logs include:

Authentication logs (login attempts)
System logs (errors, warnings, service activity)
Application logs
Web server access and error logs
Why /var/log is critical:

Logs provide evidence, not assumptions
Brute-force attacks are visible through repeated failed logins
Successful logins confirm account compromise
Attack timelines are built using log timestamps
Incident reconstruction depends on logs
A core SOC rule:

If logs were not reviewed, the investigation is incomplete.

Logs transform suspicion into confirmation.

/tmp – Malware Execution and Staging Area
The /tmp directory is used for temporary files.

Key characteristics:

World-writable (any user can write here)
Files are often short-lived
Commonly cleaned automatically
Why attackers love /tmp:

Easy to write files
Often lightly monitored
Ideal for executing malicious scripts
Used for fileless or in-memory attacks
SOC red flags:

Executable files inside /tmp
Running processes originating from /tmp
Correlation between /tmp activity and suspicious logs
For SOC analysts, /tmp often indicates active or recent attacks.

/bin and /sbin – System Binary Integrity
These directories contain essential system commands.

/bin – commands used by all users
/sbin – administrative and system management commands
SOC relevance:

Attackers may replace legitimate binaries with malicious ones
Trojanized commands allow stealthy execution
PATH hijacking can redirect execution to malicious binaries
SOC analysts may:

Verify command integrity
Compare binary hashes with known baselines
Investigate unexpected command behavior
Binary integrity issues can turn trusted tools into attack vectors.

/proc – Live System and Memory View
The /proc directory is a virtual filesystem created by the kernel.

Important characteristics:

Does not store data on disk
Shows real-time system information
Exposes running processes and memory usage
SOC importance:

Some malware exists only in memory
Hidden or injected processes can be detected here
Useful during live incident response
/proc answers the question:

What is happening on the system right now?

Linux File System Hierarchy in a SOC Investigation Flow
In real incidents, SOC analysts often follow this pattern:

/home – identify initial access and user compromise
/tmp – check for malware execution
/etc – detect persistence mechanisms
/root – confirm privilege escalation
/var/log – build the incident timeline
/proc – observe live attacker activity
This flow is not theoretical — it mirrors real SOC investigations.

Final Thoughts
The Linux File System Hierarchy is not just an operating system concept — it is a map of attacker behavior and defender response.

For SOC analysts:

Tools generate alerts
Logs provide evidence
File systems reveal the truth
Mastering the Linux file system hierarchy means knowing where to look before what to search. It transforms you from someone who reacts to alerts into someone who understands incidents.

This foundation is essential before moving into SIEM, EDR, threat hunting, or incident response.

🔚 End of Article
(Day 2 — Linux File System Hierarchy)

Day 8 — Understanding Linux From the Ground Up: The System Every SOC Analyst Must Know

Faizan Nazir — Thu, 16 Jul 2026 08:01:12 +0000

Introduction: Why Linux Deserves a Proper Beginning
Learning Linux is often introduced in the worst possible way. Most beginners encounter it through random command lists, copied cheat sheets, or flashy “hacker” tutorials that skip the most important question: what exactly are we interacting with?

On Day 8 of my SOC journey, I made a deliberate decision to slow everything down and rebuild my understanding from the lowest possible level. Instead of memorizing commands, I focused on understanding the system itself — because in cybersecurity, shallow knowledge always collapses under pressure.

This article documents that approach.

Linux is not just another operating system you install. It is the foundation of modern infrastructure. If you want to analyze incidents, understand logs, investigate breaches, or defend systems, Linux is not optional knowledge. It is the environment where real systems live.

To understand Linux properly, we must start even earlier — with the concept of an operating system itself.

What an Operating System Really Is (Not the Textbook Definition)

An operating system is often described as “software that manages hardware.” While technically correct, that definition hides its true importance.

At a deeper level, an operating system is a decision-maker.

It decides which process gets CPU time.
It decides how memory is allocated.
It decides who is allowed to read or write files.
It decides how devices communicate with applications.

Without an operating system, hardware is powerless. A CPU does not know what to execute. Memory does not know who can use it. Storage does not know how data should be organized.

The operating system acts as an intelligent layer that translates human intent into machine execution.

Every click, every keystroke, every network packet flows through the operating system.

This is why operating systems are central to cybersecurity. When an attack occurs, it does not attack “the computer” — it attacks decisions made by the operating system.

Enter Linux: An Operating System Built for Control
Press enter or click to view image in full size

Linux is an operating system, but it follows a very different philosophy compared to desktop-focused systems like Windows.

Linux was designed with the assumption that:

The user wants control
The system must be stable for long periods
Transparency is more valuable than convenience
Linux is open-source, meaning its internal behavior is not hidden. Anyone can inspect how decisions are made. This is one reason Linux dominates servers, cloud platforms, and security tools.

Another critical difference is that Linux is not one single product. It is a kernel, combined with different tools, interfaces, and utilities to form distributions. This modular design allows Linux to be adapted to very different use cases — from lightweight servers to full desktop environments.

For SOC analysts, this flexibility is essential. You may encounter different Linux distributions across environments, but the core principles remain the same.

Linux vs Windows: A Difference in Philosophy, Not Just Features
Press enter or click to view image in full size

The Linux vs Windows discussion is often reduced to surface-level comparisons like “Linux is free” or “Windows is user-friendly.” Those points are true, but they miss the real difference.

Windows is designed primarily for end-user convenience. Its graphical interface is central. Many system decisions are abstracted away to reduce complexity for the user.

Linux, on the other hand, is designed for explicit control. It expects users to understand what they are doing, or at least to take responsibility for their actions.

This difference becomes extremely important in security contexts.

Windows tends to hide system internals behind layers of abstraction. Linux exposes them. In SOC work, visibility matters more than comfort. When something goes wrong, Linux gives you direct access to the system’s state — logs, processes, files, and configurations — without forcing you through multiple UI layers.

This is one reason Linux dominates servers and security environments despite having a steeper learning curve.

GUI and Terminal: Two Ways to Interact With a System
Linux can be used in two primary ways: through a graphical user interface (GUI) or through the terminal.

The GUI is familiar. It uses windows, icons, and mouse interactions. For beginners, this feels comfortable because it resembles other desktop systems.

The terminal, however, is where Linux reveals its true nature.

The terminal is a text-based interface that allows direct communication with the operating system. Instead of clicking buttons, you issue instructions. Instead of guessing what the system is doing, you ask it directly.

In real-world server environments, GUIs are often not installed at all. They consume resources, increase attack surface, and are unnecessary for remote administration. This is why SOC analysts must be comfortable with terminal-based interaction.

Learning Linux without understanding the terminal is like learning networking without understanding IP addresses — you can get by, but you will always be limited.

Why Linux Is Used Everywhere (And Why That Matters)
Linux dominates modern infrastructure for practical reasons.

It is stable enough to run continuously for years.
It handles resources efficiently.
It allows fine-grained permission control.
It integrates easily with automation and scripting.

From a security perspective, Linux provides transparency. Logs are accessible. Processes are visible. Configurations are readable. This transparency allows defenders to understand system behavior deeply — but it also means attackers target Linux systems heavily.

Understanding Linux is therefore not about preference. It is about relevance.

The Terminal: The Core of Linux Interaction
Press enter or click to view image in full size

The terminal is not just a tool. It is the primary interface philosophy of Linux.

Become a Medium member
When you open a terminal, Linux presents you with a prompt that looks simple but carries critical information. It tells you who you are, which system you are interacting with, and where you are located in the filesystem.

This prompt is not decoration. It is context.

In SOC work, context prevents mistakes. Acting without context leads to misinterpretation and system damage.

Learning to read and respect the terminal prompt is the first step toward safe Linux usage.

Understanding Location in Linux: Why It Comes First

Linux operates based on your current working directory. Every command you run is executed relative to your location unless you specify otherwise.

This is why the pwd command exists.

pwd stands for Present Working Directory. When executed, it tells you exactly where you are in the filesystem hierarchy. The output is a full path starting from the root directory.

For example, an output like /home/user tells you that you are inside your home directory. This information may seem trivial, but it prevents serious mistakes.

In security investigations, analysts often work inside sensitive directories. Running commands without confirming location can lead to unintended consequences.

pwd does not modify the system. It only informs. That makes it one of the safest and most important commands for beginners and professionals alike.

Observing Before Acting: The Role of ls
Once you know where you are, the next logical step is understanding what exists in that location. This is where the ls command comes in.

ls lists the contents of a directory. It shows files and folders without opening or modifying them. Like pwd, it is a read-only command.

This pattern — first check location, then observe contents — reflects a broader security principle: observe before acting.

In SOC workflows, analysts constantly list directories to confirm file presence, verify logs, or identify anomalies. ls builds awareness without risk.

Why These “Simple” Commands Matter So Much
It is tempting to dismiss pwd and ls as beginner commands. That mindset is dangerous.

In real-world environments, most destructive incidents are not caused by advanced exploits — they are caused by small mistakes executed in the wrong context.

Linux does not protect users from themselves. That is why disciplined habits matter.

Understanding the ls Command:
Press enter or click to view image in full size

Press enter or click to view image in full size

In Linux, one of the most important habits a user must develop is the habit of observation before action. The ls command exists precisely for this reason. While it may appear simple on the surface, ls plays a critical role in how users, administrators, and SOC analysts interact safely with a Linux system.

The ls command stands for list. When executed, it shows the contents of the current directory, including files and folders. Unlike commands that modify the system, ls is a read-only command. It does not open files, change permissions, delete data, or alter system state. It only reveals what already exists. This makes it one of the safest commands in Linux, especially for beginners.

When a user runs ls, Linux responds with the names of files and directories present in the current working directory. This output helps the user understand the environment they are operating in. Without using ls, a user is effectively working blind, which is risky in any system and especially dangerous in production or security-sensitive environments.

From a SOC perspective, ls is far from a basic or “beginner-only” command. Analysts frequently use it to verify the presence of log files, inspect suspicious directories, confirm malware artifacts, or check whether expected files exist. During investigations, ls helps establish context before deeper analysis begins.

In Linux, mistakes are rarely caused by advanced commands. They are usually caused by executing the right command in the wrong place. The ls command reduces that risk by enforcing awareness. It teaches a simple but powerful lesson: always look before you touch.

This is why ls is not just a command—it is a mindset.

Linux Learning as a SOC Analyst
From a SOC perspective, Linux is not just a system you use — it is a system you interpret.

Logs are stored in Linux paths.
Processes run under Linux permissions.
Malware hides in Linux directories.

Understanding Linux behavior allows analysts to separate normal activity from suspicious behavior.

That understanding begins with fundamentals, not tools.

Reflection: What Day 8 Actually Built
Day 8 did not make me proficient in Linux. It made me comfortable with Linux.

I learned how to:

Think about operating systems conceptually
Understand Linux’s role in security
Interact safely with the terminal
Build awareness before action
This foundation is far more valuable than memorized commands.

Conclusion: Why This Phase Matters
Linux is the environment where real security work happens. Treating it casually creates blind spots. Treating it seriously builds competence.

Day 8 was the start of that seriousness.

This article is not a tutorial. It is a mindset reset.

Linux rewards those who understand before they act — and that principle defines good SOC analysts.

Day 7 - Revision

Faizan Nazir — Tue, 14 Jul 2026 18:29:21 +0000

Why This Revision Was Important
In a SOC environment, networking knowledge is not theoretical.

Every alert, every log, every incident —
everything flows through the network.

So before touching Linux, SIEMs, or alerts, I wanted to make sure that:

Concepts are clear
Connections between topics make sense
I can relate theory to real SOC scenarios
What I Revised (Networking Fundamentals)
1. Network & Networking
Understanding what a network actually is and why networking exists — enabling communication, data transfer, and service access between systems.

In SOC, this helps answer:

Where is the traffic coming from?
Where is it going?
Is this communication expected or suspicious?
2. LAN vs WAN
LAN (Local Area Network): Internal communication within an organization
WAN (Wide Area Network): Communication over larger distances (internet, branches)
SOC relevance:

Internal vs external traffic classification
Identifying lateral movement vs external attacks
3. Data Flow in Networks
Revisited how data travels:

Source → destination
Through routers, switches, and networks
This is crucial for:

Understanding packet paths
Interpreting alerts related to unusual traffic flows
4. Reachability & Identification
How systems identify each other
How reachability is tested
SOC relevance:

Detecting unreachable hosts
Understanding failed connection attempts
Identifying scanning or reconnaissance behavior
5. IP Addressing (Basics)
Purpose of IP addresses
How devices are uniquely identified
SOC use-case:

Tracking suspicious IPs
Distinguishing internal vs external addresses
Correlating alerts with source and destination IPs
6. DNS (Domain Name System)
Revisited how:

Domain names are resolved to IP addresses
DNS queries and responses work
SOC relevance:

Detecting malicious domains
Understanding DNS-based attacks
Investigating unusual DNS activity
7. Networking Tools Revision
ping
Tests reachability
Uses ICMP
SOC perspective:

Connectivity checks
Initial investigation during outages or alerts
traceroute
Shows packet path across networks
SOC perspective:

Understanding traffic routes
Identifying unusual or unexpected hops
Nslookup
Queries DNS records
SOC perspective:

Investigating suspicious domains
Validating DNS behavior during incidents
8. TCP vs UDP
Revisited differences with use-case clarity, not rote learning.

TCP: Reliable, connection-oriented
UDP: Faster, connectionless
SOC relevance:

Understanding protocol-based attacks
Interpreting alerts based on protocol behavior
Key Takeaway from Day 7
This revision helped me:

Connect networking concepts instead of memorizing them
Think from a SOC analyst’s perspective
Prepare mentally for Linux, where logs and networking meet
Strong foundations reduce confusion later.

SOC Analyst Day 6

Faizan Nazir — Mon, 13 Jul 2026 17:45:35 +0000

Network Devices & Security: Firewalls, Routers, Switches, and Network Segmentation
Introduction
In previous days, we focused on understanding how data moves across a network, how traffic behaves, how ports and services operate, and how attackers exploit weak configurations.
Day 6 marks a critical transition in the SOC learning journey.

Until now, we were mostly answering the question

“How does traffic move?”

From Day 6 onward, we start answering a more important SOC question:

“Where can traffic be controlled, restricted, monitored, and stopped?”

This article focuses on network devices and security controls that SOC analysts interact with daily, directly or indirectly:

Firewalls
Routers
Switches
Network Segmentation
These components form the structural backbone of enterprise security.
If an attacker succeeds, it is often because one of these controls failed, was misconfigured, or was not monitored properly.

Firewalls — The First Line of Defense Press enter or click to view image in full size

Press enter or click to view image in full size

What Is a Firewall?
A firewall is a security device or software that controls incoming and outgoing network traffic based on predefined security rules.

From a SOC perspective, a firewall is not just a blocking device.
It is also a visibility and evidence source.

In simple terms:

Firewalls decide what traffic is allowed
Firewalls decide what traffic is blocked
Firewalls generate logs that SOC analysts investigate
Why Firewalls Are Critical in Enterprise Networks
Without a firewall:

Any external system can attempt to connect to internal services
Open ports become direct entry points
Attack surface increases drastically
With a firewall:

Only explicitly permitted traffic flows
Unauthorized access attempts are blocked
Every decision can be logged and reviewed
For SOC teams, firewall logs are often:

The first indicator of reconnaissance
The earliest sign of a breach attempt
How Firewalls Make Decisions
Firewalls operate using rules, which evaluate traffic based on:

Source IP address
Destination IP address
Port number
Protocol (TCP, UDP, ICMP)
Action (allow, deny, drop, log)
A single firewall rule may look conceptually like:

Allow internal users to access the internet on HTTPS
Block all inbound traffic to internal databases

SOC analysts do not usually create these rules, but they analyze the outcomes of these rules through logs and alerts.

Types of Firewalls (SOC Awareness)
Packet Filtering Firewalls

Inspect packet headers only
Work at lower OSI layers
Very fast but limited context
Cannot track sessions
Stateful Firewalls

Maintain a connection state table
Understand whether traffic belongs to an existing session
Block unsolicited packets
Widely used in enterprise environments
Application Layer Firewalls

Operate at OSI Layer 7
Inspect application data
Understand protocols like HTTP, DNS, SMTP
Detect payload-level attacks
From a SOC viewpoint:

Stateful and application-layer firewalls provide better detection capability because they generate richer logs.

Firewall Logs and SOC Operations
Firewall logs typically show:

Source and destination IPs
Ports and protocols
Action taken (allowed or blocked)
Timestamp
SOC analysts look for:

Repeated blocked attempts from the same IP
Port scanning patterns
Access attempts at unusual times
Traffic targeting sensitive services
A firewall does not stop all attacks — but it often reveals attacker intent early.

Routers — Traffic Directors Between Networks Press enter or click to view image in full size

Press enter or click to view image in full size

What Is a Router?
A router is a network device that connects different networks and forwards data packets based on IP addresses.

Routers commonly connect:

Internal networks to the internet
One subnet to another subnet
Different organizational network zones
They operate primarily at OSI Layer 3 (Network Layer).

How Routers Work
Routers use a routing table that contains:

Destination networks
Next-hop addresses
Interfaces
Metrics (cost)
When a packet arrives:

The router checks the destination IP
It finds the best route in the routing table
The packet is forwarded accordingly
If no valid route exists:

The packet is dropped
Or forwarded to a default gateway
Security Role of Routers
Although routers are not security devices by default, they play a major role in security posture.

Become a Medium member
Routers can:

Restrict traffic using Access Control Lists (ACLs)
Limit which networks can communicate
Reduce exposure of internal segments
Misconfigured routers can:

Expose internal networks
Allow unauthorized routing paths
Enable data exfiltration
Router Logs from a SOC Perspective
SOC analysts monitor routers for:

Unexpected outbound connections
Traffic bypassing security devices
Sudden routing changes
Large data transfers leaving the network
In many breaches, routers are not compromised directly — but they reveal the attacker’s movement path.

Switches — The Core of Internal Networks Press enter or click to view image in full size

Press enter or click to view image in full size

What Is a Switch?
A switch is a network device used within a Local Area Network (LAN).

It:

Connects multiple devices
Operates mainly at OSI Layer 2
Uses MAC addresses to forward data
Unlike hubs, switches are intelligent devices.

How Switches Handle Traffic
Switches maintain a MAC address table:

Learn MAC addresses from incoming frames
Associate MAC addresses with switch ports
Forward frames only to the correct destination port
This:

Reduces unnecessary traffic
Improves performance
Limits collisions
Why Switches Matter for Security
Most internal attacks occur inside the LAN, not from the internet.

Switch-related risks include:

ARP spoofing
MAC flooding
Man-in-the-middle attacks
Unauthorized device connections
From a SOC perspective:

Internal traffic must never be assumed to be trusted.

Switch Logs and Internal Threat Detection
SOC teams look for:

MAC address changes
Excessive ARP traffic
Broadcast storms
Lateral movement patterns
Switches are critical for detecting:

Insider threats
Post-compromise activity
Malware spreading internally

Network Segmentation — Controlling the Blast Radius Press enter or click to view image in full size

Press enter or click to view image in full size

What Is Network Segmentation?
Network segmentation is the practice of dividing a network into multiple isolated segments or zones.

Each segment:

Has a specific purpose
Has defined access rules
Communicates with other segments in a controlled way
Why Segmentation Is Essential
Without segmentation:

One compromised system can reach everything
Malware spreads rapidly
SOC has poor visibility
With segmentation:

Attacker movement is limited
Damage is contained
Detection becomes easier
Types of Network Segmentation (Overview)
Physical segmentation
Logical segmentation
VLAN-based segmentation
Firewall-based segmentation
Zone-based segmentation
Micro-segmentation
DMZ segmentation
Each type balances security, cost, and complexity.

Segmentation and Lateral Movement
Lateral movement is when attackers:

Move from one compromised system to another
Search for higher privileges
Target critical assets
Segmentation:

Breaks attacker paths
Forces additional authentication
Generates detectable events
SOC analysts focus heavily on inter-segment traffic logs.

SOC Analyst’s Big Picture View By the end of Day 6, a SOC analyst should understand:

Firewalls control and log traffic
Routers define where traffic can go
Switches reveal internal movement
Segmentation limits attack impact
Security is not about one device — it is about how all devices work together.

Final Takeaways
Network devices are security controls, not just connectivity tools
Misconfiguration is often more dangerous than no security
Logs are as important as blocking
Internal traffic deserves as much attention as external traffic
Segmentation is one of the strongest defenses against breaches
Closing Note
Day 6 builds the structural security mindset required for SOC analysts.
From here onward, every alert, log, and incident will map back to these components.

Understanding where traffic is controlled is the foundation of understanding how attacks are detected and stopped.

Day 5: Understanding NAT, VAT, Traffic Flow, and Ports & Services

Faizan Nazir — Sun, 12 Jul 2026 05:18:11 +0000

Many beginners entering cybersecurity and SOC analysis rush toward tools, dashboards, and alerts. However, experienced analysts know that most SOC mistakes are not tool-related but concept-related. If you do not understand how network traffic behaves, how IP addresses are translated, and how services communicate, alerts will look random and confusing.

Day 5 is designed to fix that problem.

This day focuses on four deeply connected networking concepts:

Network Traffic Flow
NAT (Network Address Translation)
VAT / PAT (Port Address Translation)
Ports and Services
Together, these topics form the mental model every SOC analyst must have before touching SIEMs, IDS, or firewall logs.

Understanding Network Traffic Behaviour
What Is Network Traffic?
Network traffic refers to the movement of data packets from a source system to a destination system across a network. This movement is not random. Every packet follows a defined path, passes through specific devices, and carries identifiable attributes such as IP addresses, ports, protocols, and timing.

For a SOC analyst, traffic is not “data moving on the network.”
It is evidence.

Traffic Flow tells you:

where the data originated,
where it is going,
how frequently it is communicating,
and whether the communication pattern makes sense.
Security monitoring is essentially traffic interpretation.

Traffic Direction and Why It Matters
One of the most important ways to understand traffic is by looking at its direction.

North–South Traffic
North–south traffic is traffic that moves between an internal network and the internet. This includes users browsing websites, servers communicating with cloud platforms, and systems downloading updates.

This traffic usually passes through perimeter devices such as firewalls, gateways, and NAT systems. Because it crosses the network boundary, it is often well-logged and monitored.

From a SOC perspective, north–south traffic is commonly associated with:

external attacks,
malware command-and-control communication,
data exfiltration attempts.
Most beginner analysts focus only on this traffic, assuming that internal traffic is safe. That assumption is dangerous.

East–West Traffic
East–west traffic is traffic that moves within the internal network itself. Examples include server-to-server communication, database queries, internal scans, and lateral movement.

Modern attackers prefer east–west traffic because:

it often bypasses perimeter security,
it is less monitored,
it allows attackers to spread silently.
In real SOC operations, post-compromise activity almost always appears in east–west traffic.

Ignoring internal traffic is one of the most costly mistakes a SOC analyst can make.

Inbound and Outbound Traffic
Another important distinction is whether traffic is inbound or outbound.

Inbound traffic originates from outside the network and enters internal systems. This traffic is usually tightly controlled and represents obvious attack vectors.

Outbound traffic originates from inside the network and exits to the internet. Many organizations allow outbound traffic by default, which makes it attractive for attackers.

A critical SOC mindset is understanding that:

Outbound traffic is not automatically safe.

Malware frequently communicates outward to command servers, downloads payloads, and exfiltrates data using outbound connections.

NAT (Network Address Translation)
What Is NAT?
Network Address Translation (NAT) is a process that translates private IP addresses into public IP addresses and vice versa.

Internal networks use private IP ranges that are not routable on the internet. NAT enables these internal systems to communicate externally without exposing their internal addressing scheme.

In simple terms, NAT acts as a translator between private networks and the public internet.

Why NAT Exists
NAT exists primarily because of IPv4 address exhaustion. Public IPv4 addresses are limited, while private IP addresses can be reused indefinitely within organizations.

NAT allows:

conservation of public IP addresses,
internal network abstraction,
controlled internet access for private systems.
It is important to clarify that NAT is not a security control. While it hides internal IP addresses, it does not inspect, filter, or block traffic.

How NAT Works Conceptually
When an internal system initiates communication with the internet, the NAT device replaces the private source IP with a public IP. A mapping entry is stored so that when the response returns, it can be forwarded back to the correct internal host.

Become a Medium member
This mapping is stored in a NAT translation table.

For SOC analysts, NAT logs and translation tables are critical because they enable attribution. Without them, identifying the true source of traffic is extremely difficult.

Types of NAT
Static NAT
Static NAT creates a permanent one-to-one mapping between a private IP and a public IP. This type of NAT is commonly used for public-facing servers that must always be reachable from the internet.

From a SOC perspective, static NAT makes attribution easier because the public IP always maps to the same internal system. However, it also increases exposure if the system is misconfigured or vulnerable.

Dynamic NAT
Dynamic NAT maps private IP addresses to a pool of public IP addresses on a temporary basis. The mapping exists only while the session is active.

Because public IPs change over time, SOC investigations involving dynamic NAT require precise timestamp correlation. Logs become essential for determining which internal host was using a specific public IP at a given moment.

VAT / PAT (Port Address Translation)
What Is VAT?
VAT, commonly known as PAT or NAT Overload, allows multiple private IP addresses to share a single public IP address by using port numbers to distinguish sessions.

This is the most widely used form of NAT in modern networks, including home routers, enterprise environments, ISPs, and cloud infrastructures.

How VAT Works
With VAT, every internal connection is assigned a unique source port on the public IP. The NAT device tracks these mappings so that return traffic can be correctly delivered.

Because of VAT:

one public IP can represent thousands of internal systems,
ports become critical for session identification.
This significantly complicates SOC investigations.

SOC Impact of VAT
When analysts see logs showing the same public IP generating multiple connections, it does not mean a single system is responsible. It could represent hundreds of users behind a NAT device.

Without source port and timestamp information:

Accurate attribution is impossible.

This is why SOC teams frequently request NAT and VAT logs during investigations.

Ports and Services
What Is a Port?
A port is a logical number used by an operating system to identify which application or process should receive incoming traffic.

An IP address identifies the system.
A port identifies the application on that system.

Without ports, a system could run only one network service at a time.

What Is a Service?
A service is a software process that listens on a port to provide network functionality. Web servers, email servers, and remote access daemons are all examples of services.

Ports and services work together:

the port acts as the entry point,
the service performs the function.
Port and Service Mapping
Ports and services are linked by convention rather than enforcement. While certain ports are commonly associated with specific services, any service can technically run on any port.

This flexibility is frequently abused by attackers. Malware often uses common ports such as 80 or 443 to blend into normal web traffic.

Client and Server Port Roles
Servers listen on fixed, well-known ports so that clients know where to connect. Clients use temporary, ephemeral ports that change with each session.

A common beginner mistake is confusing source ports with destination ports during traffic analysis. SOC analysts must clearly understand which side initiated the connection.

Why Port Numbers Do Not Equal Safety
Many assume that traffic on common ports is safe. This assumption is incorrect.

Encrypted traffic can carry malicious payloads. Legitimate ports can be abused. SOC analysis must consider Behavior, frequency, destination, and context rather than relying on port numbers alone.

How All Concepts Connect in SOC Analysis
These topics are not separate. They form a single chain:

Traffic Flow explains how data moves.
NAT hides internal IP structure.
VAT makes ports critical for identity.
Ports and services explain what kind of activity is happening.

SOC analysis is about correlating all of these factors together.

A realistic SOC identity is determined by:

IP address + Port + Time + Behavior

Final Thoughts
Day 5 is not about memorizing definitions.
It is about learning to see the network the way attackers and defenders do.

When an alert appears, a skilled SOC analyst does not panic. Instead, they ask:

Does this traffic flow make sense?
Is this service expected on this host?
Does the timing and pattern align with normal behavior?
Mastering these fundamentals transforms SOC work from guessing into reasoning.

Day 4: How Devices Actually Communicate — Networking Explained for SOC Analysts

Faizan Nazir — Sat, 11 Jul 2026 17:42:53 +0000

Most people study networking as a set of definitions.
A SOC analyst experiences networking through alerts, logs, packet captures, and incidents.

Day 4 was about closing that gap. Instead of memorizing terms, the goal was to understand how communication actually happens inside a network, and why attackers love abusing these fundamentals.

In this article, I explain MAC Address, ARP, ICMP, and Ping in full depth — what they are, how they work, where they are used, where they are not used, and why each of them matters in a real SOC environment.MAC Address — The Physical Identity of a Device
A MAC (Media Access Control) address is the physical identity of a network device. It is assigned to the network interface card (NIC) and uniquely identifies a device within a local network. Unlike IP addresses, which can change depending on the network, a MAC address is designed to remain stable and tied to the hardware.

Every device that connects to a network — laptops, servers, routers, switches, printers, and even IoT devices — communicates at the local level using MAC addresses. This is why MAC addresses operate at the Data Link Layer (Layer 2) of the OSI model.

The purpose of a MAC address is simple but critical: it allows devices inside a local network to know exactly which device should receive a frame. Switches do not understand IP addresses in the way routers do. Instead, they read the destination MAC address in a frame and forward it to the correct physical port.

When a device sends data inside a LAN, it encapsulates that data into a frame that contains both a source MAC and a destination MAC. The switch examines the destination MAC, looks it up in its MAC address table, and forwards the frame only to the appropriate port. This process makes local communication fast and efficient.

MAC addresses are used for local identification, switching decisions, and asset tracking. However, they are not used for routing across the internet, they do not provide encryption, and they do not authenticate users. This limitation becomes important from a security perspective.

From a SOC analyst’s point of view, MAC addresses are extremely valuable. They help identify rogue devices, detect unauthorized connections, correlate IP addresses with physical systems, and spot MAC spoofing attempts. If the same MAC address suddenly appears in multiple locations, or if a trusted MAC changes unexpectedly, it often indicates suspicious activity.

ARP — How an IP Address Becomes a MAC Address
While applications and routing logic rely on IP addresses, actual delivery of data inside a LAN requires MAC addresses. This creates a fundamental problem: a device may know the destination IP address, but without the MAC address, it cannot deliver the frame.

ARP (Address Resolution Protocol) exists to solve this exact problem. Its role is to map an IP address to its corresponding MAC address within a local network.

When a device wants to communicate with another device in the same LAN, it first checks its ARP table to see if it already knows the MAC address associated with the destination IP. If the mapping is missing, the device sends an ARP Request. This request is broadcast to all devices in the network, asking which device owns the target IP address.

The device that owns that IP responds with an ARP Reply, sent as a unicast message, providing its MAC address. The sender then stores this mapping in its ARP cache and uses it for subsequent communication.

ARP enables seamless local communication, but it comes with a serious weakness: it has no authentication mechanism. Devices blindly trust ARP replies, even if they are malicious. This makes ARP vulnerable to spoofing attacks.

In ARP spoofing or ARP poisoning, an attacker sends fake ARP replies claiming to be the router or another trusted device. This causes traffic to be redirected through the attacker, enabling man-in-the-middle attacks, credential theft, and session hijacking.

Become a Medium member
For SOC analysts, ARP is a critical internal threat vector. ARP-based attacks often bypass perimeter defenses because they occur inside the network. Analysts monitor ARP anomalies such as IP-to-MAC mismatches, duplicate MAC addresses, and frequent ARP table changes to detect these attacks.

ICMP — The Network’s Feedback and Error Reporting System
IP is responsible for delivering packets, but it does not report what happens when something goes wrong. ICMP (Internet Control Message Protocol) fills this gap by acting as the feedback mechanism of the network.

ICMP is used by routers and hosts to report errors, signal delivery problems, and assist in network diagnostics. It operates at the Network Layer (Layer 3) and is encapsulated inside IP packets.

When a packet cannot reach its destination, when a route fails, or when a packet’s Time To Live (TTL) expires, ICMP messages are generated and sent back to the source. These messages help systems understand why communication failed.

ICMP is widely used for troubleshooting and monitoring. Tools like ping and traceroute rely on ICMP to test reachability and discover network paths. Without ICMP, diagnosing network issues would be extremely difficult.

However, ICMP is not designed to carry application data, establish connections, or guarantee delivery. It exists purely for control and reporting purposes.

From a security perspective, ICMP is a double-edged sword. While it provides visibility, attackers abuse it for reconnaissance, denial-of-service attacks, and covert data exfiltration through ICMP tunneling. SOC teams often choose to rate-limit ICMP rather than blocking it completely, balancing security with operational visibility.

Ping — A Simple Tool with Powerful Implications
Ping is often misunderstood as a protocol, but in reality, it is a diagnostic tool that uses ICMP. Its primary purpose is to test whether a host is reachable and how long it takes to respond.

When a ping command is executed, the system sends an ICMP Echo Request to the destination. If the destination is reachable and allows ICMP, it responds with an ICMP Echo Reply. The time taken for this round trip is measured as latency.

Ping is used to verify basic connectivity, measure network delay, and detect packet loss. However, it does not test application availability or service health. A system can respond to ping while critical services remain down, and conversely, a system may block ICMP while still serving traffic normally.

From an attacker’s perspective, ping is a reconnaissance tool. Ping sweeps are commonly used to discover live hosts within a network. From a SOC perspective, unusual ICMP volumes, sequential ping patterns, or unexpected ping activity can indicate scanning or early-stage intrusion attempts.

Final SOC Takeaway
Day 4 connected the foundational pieces of networking:

MAC addresses identify devices, ARP connects IPs to those devices, ICMP reports network health, and ping tests reachability. These concepts are not just theoretical — they directly shape how SOC analysts interpret alerts, investigate incidents, and understand attacker behavior.

Learning networking at this depth transforms logs from noise into signals. This is not shortcut learning — this is SOC-ready understanding.

SOC Analyst Journey — Day 4 Completed

Day 3 Learning How Data Actually Moves (TCP/IP, TCP vs UDP, DHCP)

Faizan Nazir — Fri, 01 May 2026 03:58:07 +0000

Day 3 of my SOC journey — and things are getting real.

Today I focused on how communication actually happens inside networks:

TCP/IP basics
4-layer model
TCP vs UDP
TCP handshake
DHCP + DORA

💡 Biggest insight:

Everything in SOC — alerts, logs, attacks —
depends on how data flows.

If you don’t understand this, you’re just guessing.

⚡ TCP = reliable
⚡ UDP = fast

Both matter.

What’s next?
MAC Address, ARP, ICMP, and Ping

🚀 SOC Analyst Journey – Day 2: IP, DNS & Basic Network Commands

Faizan Nazir — Mon, 27 Apr 2026 10:28:07 +0000

Day 2 of my SOC Analyst journey — and now I’m starting to see how the internet actually works behind the scenes.

Today’s focus was on the core networking concepts and commands that SOC analysts rely on during investigations and alert triage.

🧠 What I Covered
🌐 IP Addressing

Understanding how every device in a network is uniquely identified.

IPv4 & IPv6 basics
Source and Destination identification
Foundation of all network communication
🌍 DNS (Domain Name System)

Learning how domain names are converted into IP addresses.

Domain → IP resolution
Role of DNS in browsing and communication
How DNS can expose suspicious or malicious domains
🛠️ nslookup

A simple but powerful tool to query DNS records.

Used to check domain resolution
Helps analyze suspicious domains during investigations
Useful for quick DNS verification
📡 ping

One of the most basic yet essential network tools.

Checks if a host is reachable
Measures response time (latency)
Helps identify connectivity issues
🧭 traceroute

Understanding how data travels across networks.

Shows the path (hops) packets take
Helps identify where delays or failures occur
Useful for deeper network troubleshooting
🎯 Key Takeaways
IP addresses are the identity of devices in a network
DNS acts as the translator between domains and IPs
nslookup is useful for domain investigation
ping helps verify host availability
traceroute reveals the full journey of packets
🔍 Why This Matters in SOC

In a real SOC environment:

Alerts are often tied to IP addresses and domains
Analysts investigate suspicious DNS queries
Network commands help validate and trace activity

Without understanding these basics, it’s difficult to analyze logs or respond to incidents effectively.

📌 Progress Mindset

No tools yet. No dashboards yet.

Just building the foundation — step by step.

Because strong fundamentals make everything easier later.

💬 Let’s discuss:
Have you ever used nslookup to investigate a suspicious domain? What did you find?

# Day 1 – The Biggest Beginner Mistake in SOC: Ignoring Networking 🚀

Faizan Nazir — Sun, 26 Apr 2026 13:01:18 +0000

When I first thought about becoming a SOC Analyst, I imagined dashboards, alerts, and powerful security tools.

But Day 1 of my journey changed that completely.

Instead of jumping into tools, I started with the real foundation: networking.

Why Networking Matters More Than Tools

At its core, networking is just communication between devices.

Every time we:

Open a website
Send an email
Use an app

Data moves across a network.

Here’s what most beginners miss:

👉 Every cyber attack uses the same path.

If there’s no network, there’s no attack.

That’s why networking isn’t optional — it’s essential.

What I Learned Today

Networking basics
Data communication
Communication components
- Sender
- Receiver
- Message
- Medium
- Protocol

Simple concepts, but they explain how systems interact — and how attackers exploit them.

Client–Server Model (Game Changer)

Client → sends request
Server → sends response

We use this every day while browsing.

But attackers use it too.

Malware can act as a client and communicate with a malicious server.

That’s where detection starts.

LAN vs WAN (Important for SOC)

LAN → Private, trusted
WAN → Public, untrusted

Most attacks come from WAN and try to enter LAN.

Understanding this helps in prioritizing threats.

SOC Reality

SOC is not about chasing hackers.

It’s about understanding behavior.

Logs = records
Alerts = warnings

👉 Tools show data
👉 Networking helps you understand it

Key Takeaway

👉 SOC work starts with understanding behavior, not tools.

Networking is the language of SOC.

Without it:

Logs = confusing
Alerts = overwhelming

With it:

Everything connects

Final Thoughts

This is just Day 1, but it already changed my mindset.

I’m focusing on fundamentals first — tools later.

Let’s see where this journey goes 🚀

Discussion

Are you also starting in cybersecurity or SOC?

What did you focus on in your early days?