Cybersecurity on Software Engineering Learning Paths

Threat Landscape & Attacker Mindset

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

You cannot defend what you don’t understand. Security is fundamentally adversarial — there are intelligent humans actively trying to break your systems. Understanding their motivations, methods, and tooling is the first step to building effective defenses.

Threat Actors#

Classification by Motivation#

Actor	Motivation	Resources	Persistence	Typical Targets
Script Kiddies	Fun, bragging rights	Low (public tools)	Low	Anything vulnerable
Hacktivists	Political/ideological	Low–Medium	Medium	Government, corporations
Cybercriminals	Financial gain	Medium–High	High	Anyone with money/data
Insiders	Revenge, money, negligence	High (already inside)	Varies	Their own organization
Nation-States (APT)	Espionage, sabotage, influence	Very High (unlimited)	Very High	Critical infrastructure, IP
Competitors	Business advantage	Medium	Medium	Trade secrets, strategies

Advanced Persistent Threats (APTs)#

APTs are the most dangerous — state-sponsored groups with:

Cryptography

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Cryptography is the mathematical foundation of all digital security. Every time you visit a website, send a message, or authenticate to a service, cryptographic algorithms are protecting you. Understanding how they work — and how they fail — is essential.

Core Concepts#

Concept	Purpose	Property Provided
Encryption	Hide data from unauthorized readers	Confidentiality
Hashing	Create fixed-size fingerprint of data	Integrity
Digital Signatures	Prove who created/approved data	Authentication + Non-repudiation
Key Exchange	Securely agree on a shared secret	Confidentiality (setup)

Symmetric Encryption#

Same key for encryption and decryption. Fast, efficient for bulk data.

Network Security

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Networks carry all data between systems. If an attacker controls the network, they can intercept, modify, or block any communication. Network security creates boundaries, monitors traffic, and ensures only authorized communication occurs.

Defense in Depth#

No single control is sufficient. Layer defenses so that if one fails, others still protect:

flowchart TD
 Internet["Internet (untrusted)"]
 Internet --> Edge["Edge Security<br/>DDoS protection, CDN, WAF"]
 Edge --> Perimeter["Perimeter Firewall<br/>Stateful inspection, IPS"]
 Perimeter --> DMZ["DMZ<br/>Reverse proxies, public-facing services"]
 DMZ --> Internal["Internal Firewall<br/>Micro-segmentation"]
 Internal --> App["Application Layer<br/>Input validation, auth"]
 App --> Data["Data Layer<br/>Encryption at rest, access controls"]

Firewalls#

Types#

Type	OSI Layer	Inspects	Strengths	Limitations
Packet Filter	L3–L4	IP, port, protocol	Fast, simple	No state, no content inspection
Stateful	L3–L4	Connection state + packets	Tracks sessions	Can’t inspect encrypted traffic
Application/WAF	L7	HTTP content, headers, body	Deep inspection	Slower, complex rules
Next-Gen (NGFW)	L3–L7	All + threat intel + user identity	Comprehensive	Expensive, complex

Firewall Rule Design#

Rules are evaluated top-to-bottom, first match wins:

Web Application Security

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Web applications are the most common attack surface. They’re internet-facing, complex, and handle sensitive data. Most breaches involve exploiting web application vulnerabilities.

OWASP Top 10 (2021)#

The Open Web Application Security Project’s definitive list of critical web risks:

#	Category	Root Cause
A01	Broken Access Control	Missing or bypassed authorization checks
A02	Cryptographic Failures	Weak crypto, plaintext data, missing encryption
A03	Injection	Untrusted data interpreted as code/commands
A04	Insecure Design	Flawed architecture, missing threat model
A05	Security Misconfiguration	Default configs, unnecessary features enabled
A06	Vulnerable Components	Outdated libraries with known CVEs
A07	Identification & Auth Failures	Weak passwords, broken session management
A08	Software & Data Integrity Failures	Unsigned updates, insecure deserialization
A09	Logging & Monitoring Failures	Attacks go undetected
A10	Server-Side Request Forgery	Server makes requests to unintended targets

Injection Attacks#

SQL Injection#

The server treats user input as SQL code:

Identity & Access Management

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Identity is the new perimeter. In cloud and remote-work environments, controlling WHO can access WHAT is the primary security control. IAM failures are behind most breaches — stolen credentials, excessive permissions, and broken authentication.

Core Concepts#

flowchart LR
 Subject["Subject<br/>(user, service, device)"]
 Subject -->|"AuthN: Who are you?"| Identity["Identity<br/>Verification"]
 Identity -->|"AuthZ: What can you do?"| Access["Access<br/>Decision"]
 Access -->|"Allow/Deny"| Resource["Protected<br/>Resource"]

Concept	Question	Mechanism
Identification	Who claims to be?	Username, email, certificate CN
Authentication (AuthN)	Prove it	Password, MFA, certificate, biometric
Authorization (AuthZ)	What’s allowed?	Roles, policies, attributes
Accounting/Auditing	What did they do?	Logs, audit trail

Authentication Protocols#

SAML 2.0 (Security Assertion Markup Language)#

XML-based SSO protocol, common in enterprise:

Operating System Security

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

The operating system is the foundation of every workload. If the OS is compromised, everything running on it — applications, data, credentials — is compromised. OS hardening reduces the attack surface and limits what an attacker can do even after gaining initial access.

Hardening Principles#

Principle	Actions
Minimize attack surface	Remove unused packages, disable unnecessary services
Least privilege	Non-root execution, restricted sudo, capability-based access
Patch continuously	Automated updates, vulnerability scanning
Secure defaults	Disable root login, enforce strong auth
Defense in depth	Multiple layers (firewall + MAC + audit)
Immutability	Read-only filesystems, rebuild instead of patch

Linux Security Architecture#

flowchart TD
 User["User Space"]
 User --> DAC["DAC<br/>(file permissions)"]
 User --> MAC["MAC<br/>(SELinux/AppArmor)"]
 User --> Caps["Capabilities<br/>(fine-grained root)"]
 
 Kernel["Kernel Space"]
 DAC --> Kernel
 MAC --> Kernel
 Caps --> Kernel
 
 Kernel --> Seccomp["seccomp<br/>(syscall filter)"]
 Kernel --> Namespaces["Namespaces<br/>(isolation)"]
 Kernel --> Cgroups["cgroups<br/>(resource limits)"]
 Kernel --> Audit["auditd<br/>(logging)"]

Discretionary Access Control (DAC)#

Traditional Unix permissions:

Cloud Security

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Cloud environments are the primary target for modern attacks. Misconfigurations — not sophisticated exploits — cause most cloud breaches. The shared responsibility model means YOU are responsible for securing your workloads, data, and configurations.

Shared Responsibility Model#

flowchart TD
 subgraph You["YOUR Responsibility"]
 Data["Data & Encryption"]
 IAM["IAM & Access Control"]
 App["Application Security"]
 OS["OS & Network Config"]
 FW["Firewall Rules"]
 end
 
 subgraph Provider["PROVIDER Responsibility"]
 Physical["Physical Security"]
 Network["Global Network"]
 Hypervisor["Hypervisor"]
 Hardware["Hardware"]
 Regions["Regions & AZs"]
 end

Responsibility by Service Type#

Layer	IaaS (EC2)	PaaS (Lambda, RDS)	SaaS (S3, SQS)
Data classification & encryption	You	You	You
IAM policies	You	You	You
Application code	You	You	N/A
OS patching	You	Provider	Provider
Network config	You	Shared	Provider
Physical infrastructure	Provider	Provider	Provider

Key insight: Moving to managed services (PaaS/SaaS) shifts more responsibility to the provider — but data and access control are ALWAYS yours.

Vulnerability Management

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Every system has vulnerabilities. The question isn’t whether they exist — it’s whether you find them before attackers do, and whether you fix the right ones fast enough. Vulnerability management is the continuous process of discovery, assessment, prioritization, and remediation.

Vulnerability Lifecycle#

flowchart LR
 Discover["Discover<br/>(scan, report, disclose)"] --> Assess["Assess<br/>(CVSS + context)"]
 Assess --> Prioritize["Prioritize<br/>(risk-based)"]
 Prioritize --> Remediate["Remediate<br/>(patch, mitigate, accept)"]
 Remediate --> Verify["Verify<br/>(rescan, validate)"]
 Verify --> Report["Report<br/>(metrics, trends)"]
 Report --> Discover

CVE, CWE, and CVSS#

CVE (Common Vulnerabilities and Exposures)#

Unique identifier for a specific vulnerability:

Security Operations & Incident Response

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Prevention eventually fails. When it does, the speed and quality of your detection and response determines whether an incident is a minor event or a catastrophic breach. Security operations is the 24/7 function that watches, detects, and responds.

Security Operations Center (SOC)#

SOC Tiers#

Tier	Role	Responsibilities
Tier 1	Alert Analyst	Triage alerts, initial classification, escalate or close
Tier 2	Incident Responder	Deep investigation, containment, evidence collection
Tier 3	Threat Hunter / Senior Analyst	Proactive hunting, advanced forensics, malware analysis
Engineering	Detection Engineer	Build detection rules, tune alerts, automate playbooks

SOC Metrics#

Metric	Measures	Target
Mean Time to Detect (MTTD)	Discovery speed	Minutes–hours
Mean Time to Respond (MTTR)	Response speed	Hours
Alert volume	Workload	Manageable (not drowning)
False positive rate	Alert quality	< 30%
Escalation rate	Tier 1 → Tier 2	10–20%
Coverage	% of ATT&CK techniques detected	Increasing

SIEM (Security Information and Event Management)#

Centralized log aggregation, correlation, and alerting:

Secure Software Development

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Most vulnerabilities are introduced during development. Fixing a vulnerability in production costs 30–100x more than fixing it during design. Secure development integrates security into every phase of the SDLC — shifting left means finding and fixing issues earlier, when they’re cheapest.

Secure SDLC#

flowchart LR
 Req["Requirements<br/>· Security Requirements<br/>· Abuse Cases"] --> Design["Design<br/>· Threat Model<br/>· Architecture Review"]
 Design --> Code["Code<br/>· Secure Coding<br/>· SAST + SCA"]
 Code --> Test["Test<br/>· DAST + Pentest<br/>· Fuzz Testing"]
 Test --> Deploy["Deploy<br/>· Config Review<br/>· Secrets Check"]
 Deploy --> Operate["Operate<br/>· Monitor<br/>· Respond + Patch"]

Security Activities per Phase#

Phase	Security Activities	Output
Requirements	Security requirements, abuse cases, compliance needs	Security user stories
Design	Threat modeling, architecture review, crypto design	Threat model document
Implementation	Secure coding standards, SAST, code review	Clean code, no critical findings
Testing	DAST, penetration testing, fuzz testing	Security test report
Deployment	Configuration review, secrets scanning, hardening	Secure deployment
Operations	Monitoring, vulnerability management, incident response	Ongoing security posture

Threat Modeling#

STRIDE Model#

Systematic identification of threats per component:

Compliance & Governance

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

Security without governance is ad-hoc and unsustainable. Frameworks provide structure, accountability, and measurability. Compliance ensures you meet legal obligations. But compliance alone is not security — it’s the minimum baseline, not the ceiling.

Governance vs Compliance vs Security#

Concept	Focus	Question
Governance	Decision-making structure	Who decides? How are policies enforced?
Risk Management	Understanding and treating risk	What could go wrong? How bad? What do we do?
Compliance	Meeting external requirements	Are we following the rules?
Security	Protecting assets	Are we actually safe?

flowchart TD
 Gov["Governance<br/>(structure, accountability)"]
 Gov --> Risk["Risk Management<br/>(identify, assess, treat)"]
 Gov --> Compliance["Compliance<br/>(meet requirements)"]
 Risk --> Security["Security Controls<br/>(technical + organizational)"]
 Compliance --> Security

Major Frameworks#

ISO 27001 (Information Security Management System)#

International standard for managing information security systematically:

Offensive Security

Mon, 01 Jan 0001 00:00:00 +0000

Why This Matters#

You cannot build effective defenses without understanding how attacks work. Offensive security — penetration testing, red teaming, and ethical hacking — validates that your controls actually work against real-world attack techniques. It’s the difference between “we think we’re secure” and “we’ve proven it.”

Penetration Testing#

Methodology#

flowchart LR
 Scope["1: Scope &<br/>Rules of Engagement"] --> Recon["2: Reconnaissance<br/>(passive + active)"]
 Recon --> Enum["3: Enumeration<br/>(services, versions)"]
 Enum --> Vuln["4: Vulnerability<br/>Analysis"]
 Vuln --> Exploit["5: Exploitation"]
 Exploit --> Post["6: Post-Exploitation<br/>(pivot, escalate)"]
 Post --> Report["7: Reporting"]

Phase Details#

Phase	Activities	Output
Scoping	Define targets, boundaries, rules, timeline	Rules of Engagement document
Reconnaissance	OSINT, DNS enumeration, technology fingerprinting	Target profile
Enumeration	Port scanning, service identification, version detection	Service map
Vulnerability Analysis	Identify weaknesses, research exploits	Vulnerability list
Exploitation	Attempt to exploit vulnerabilities	Proof of access
Post-Exploitation	Privilege escalation, lateral movement, data access	Impact demonstration
Reporting	Document findings, evidence, recommendations	Pentest report

Testing Types#

Type	Tester Knowledge	Simulates	Depth
Black Box	No internal info	External attacker	Broad, shallow
Grey Box	Partial info (creds, docs)	Insider or compromised account	Balanced
White Box	Full access (source, architecture)	Comprehensive audit	Deep, thorough

Reconnaissance#

Passive Reconnaissance (No Direct Contact)#

Technique	Tools	Finds
WHOIS lookup	whois, DomainTools	Domain owner, registrar, contacts
DNS enumeration	dig, dnsdumpster, subfinder	Subdomains, mail servers, records
Certificate transparency	crt.sh, Censys	All issued certificates (reveals subdomains)
Search engine dorking	Google, Shodan, Censys	Exposed files, services, devices
Social media/LinkedIn	Manual, theHarvester	Employee names, tech stack, org structure
Code repositories	GitHub, GitLab search	Leaked credentials, internal paths
Job postings	LinkedIn, company site	Technology stack, tools used

Active Reconnaissance#

Technique	Tools	Finds
Port scanning	Nmap, masscan, RustScan	Open ports, services
Service fingerprinting	Nmap -sV, WhatWeb	Software versions
Web crawling	Burp Spider, gospider	Pages, forms, parameters
Directory brute-forcing	ffuf, gobuster, feroxbuster	Hidden paths, admin panels
Virtual host discovery	ffuf, gobuster vhost	Additional web applications

Nmap Essentials#

# Quick scan (top 1000 ports)
nmap -sV -sC target.com

# Full port scan
nmap -p- -sV target.com

# UDP scan (slow but important)
nmap -sU --top-ports 100 target.com

# OS detection
nmap -O target.com

# Aggressive scan (noisy)
nmap -A target.com

Web Application Testing#

Methodology (OWASP Testing Guide)#

Category	Tests
Information Gathering	Technology stack, entry points, application mapping
Configuration	Default credentials, HTTP methods, error handling
Identity Management	User enumeration, account policies
Authentication	Brute force, credential stuffing, bypass
Authorization	IDOR, privilege escalation, path traversal
Session Management	Token analysis, fixation, timeout
Input Validation	Injection (SQL, XSS, command), file upload
Error Handling	Information leakage, stack traces
Cryptography	Weak algorithms, improper implementation
Business Logic	Workflow bypass, race conditions

Burp Suite Workflow#

flowchart TD
 Proxy["1: Proxy<br/>(intercept traffic)"] --> Spider["2: Spider/Crawl<br/>(map application)"]
 Spider --> Scan["3: Active Scan<br/>(automated testing)"]
 Scan --> Manual["4: Manual Testing<br/>(logic flaws, auth bypass)"]
 Manual --> Intruder["5: Intruder<br/>(fuzzing, brute force)"]
 Intruder --> Repeater["6: Repeater<br/>(craft specific requests)"]

Common Web Exploits#

Vulnerability	Test	Impact
SQL Injection	`' OR 1=1--`, sqlmap	Database access, data theft
XSS	`<script>alert(1)</script>`	Session hijacking, phishing
IDOR	Change ID in URL/request	Access other users’ data
SSRF	Internal URLs in parameters	Internal network access
File Upload	Upload web shell (.php, .jsp)	Remote code execution
Deserialization	Crafted serialized objects	Remote code execution

Network Penetration Testing#

Internal Network Attack Path#

flowchart TD
 Initial["Initial Access<br/>(phishing, exploit)"] --> Enum2["Internal Enumeration<br/>(AD, shares, services)"]
 Enum2 --> Creds["Credential Harvesting<br/>(Responder, Kerberoast)"]
 Creds --> Lateral["Lateral Movement<br/>(pass-the-hash, RDP, WMI)"]
 Lateral --> Priv["Privilege Escalation<br/>(domain admin)"]
 Priv --> Objective["Objective<br/>(DC compromise, data access)"]

Active Directory Attacks#

Attack	Technique	Tool
Kerberoasting	Request service tickets, crack offline	Rubeus, GetUserSPNs
AS-REP Roasting	Target accounts without pre-auth	Rubeus, GetNPUsers
Pass-the-Hash	Use NTLM hash without cracking	Mimikatz, CrackMapExec
Pass-the-Ticket	Use Kerberos ticket	Rubeus, Mimikatz
DCSync	Replicate credentials from DC	Mimikatz, secretsdump
Golden Ticket	Forge Kerberos TGT	Mimikatz
BloodHound	Map AD attack paths	BloodHound + SharpHound

Privilege Escalation#

Platform	Technique	Tool
Linux	SUID binaries	find / -perm -4000
Linux	Sudo misconfigurations	sudo -l, GTFOBins
Linux	Kernel exploits	LinPEAS, linux-exploit-suggester
Linux	Cron jobs (writable scripts)	pspy, manual review
Windows	Unquoted service paths	PowerUp, WinPEAS
Windows	Token impersonation	Potato exploits, PrintSpoofer
Windows	DLL hijacking	Process Monitor, manual
Windows	AlwaysInstallElevated	PowerUp

Red Team Operations#

Red Team vs Pentest#

Aspect	Penetration Test	Red Team
Objective	Find vulnerabilities	Test detection and response
Scope	Defined targets	Full organization
Duration	Days–weeks	Weeks–months
Stealth	Not required	Essential (avoid detection)
Rules	Strict boundaries	Broader (with safety limits)
Output	Vulnerability list	Attack narrative + detection gaps
Blue team awareness	Usually aware	Usually unaware

Red Team Phases#

Phase	Activities
Planning	Objectives, threat profile to emulate, C2 infrastructure
Reconnaissance	Deep OSINT, target profiling, social engineering prep
Initial Access	Phishing, exploit, physical, supply chain
Establish Foothold	Persistence, C2 communication
Escalate & Move	Privilege escalation, lateral movement
Achieve Objectives	Data access, demonstrate impact
Reporting	Full attack narrative, detection gaps, recommendations

Command and Control (C2)#

Framework	Type	Features
Cobalt Strike	Commercial	Industry standard, malleable C2
Sliver	Open source	Cross-platform, modern
Mythic	Open source	Modular, multi-agent
Havoc	Open source	Modern, evasion-focused

Evasion Techniques#

Category	Technique
Network	Domain fronting, DNS over HTTPS, encrypted C2
Endpoint	AMSI bypass, ETW patching, unhooking
Payload	Obfuscation, encryption, living-off-the-land (LOLBins)
Behavioral	Slow operations, business-hours activity, legitimate tools

Purple Team#

Collaborative approach — red and blue work together:

OSINT (Open Source Intelligence)

Mon, 01 Jan 0001 00:00:00 +0000

What Is OSINT?#

Open Source Intelligence (OSINT) is the collection, analysis, and use of information from publicly available sources. It’s a critical skill in cybersecurity — used in penetration testing, threat intelligence, fraud investigation, incident response, and red team operations.

“Open source” here means publicly accessible — not “free software.” Sources include the internet, social media, public records, news, satellite imagery, and leaked databases.

The Intelligence Cycle#

flowchart TD
 A["1. Planning & Direction<br/>Define objectives"] --> B["2. Collection<br/>Gather raw data"]
 B --> C["3. Processing<br/>Filter, organize, normalize"]
 C --> D["4. Analysis<br/>Interpret, correlate, assess"]
 D --> E["5. Dissemination<br/>Report findings"]
 E --> F["6. Feedback<br/>Refine requirements"]
 F --> A

Planning Questions#

Before collecting anything, define: