Second Modification

q2-Attack-Simulation/q2-Attack-Simulation.md

@@ -0,0 +1,140 @@
+Task2:
+
+Attack Scenario
+An attacker successfully performed a brute-force attack against the application's login API hosted on Ghaymah Cloud. 
+After compromising a valid user account, the attacker accessed sensitive customer data and exfiltrated part of the database.
+
+________________________________________
+
+
+Attack Flow
+
+Internet
+     ↓
+Recon
+     ↓
+API Discovery
+     ↓
+Brute Force
+     ↓
+Successful Login
+     ↓
+Data Access
+     ↓
+Data Exfiltration
+     ↓
+Cleanup
+________________________________________
+Root Cause Analysis
+The attack succeeded because:
+•	No Rate Limiting on the login endpoint. 
+•	Weak user password. 
+•	No Multi-Factor Authentication (MFA). 
+•	Insufficient monitoring of repeated failed logins. 
+•	Missing Web Application Firewall (WAF) protections. 
+2. Incident Response Plan
+Phase 1 – Identification
+Objectives:
+•	Confirm the brute-force attack. 
+•	Identify affected user accounts. 
+•	Determine compromised resources. 
+•	Preserve forensic evidence. 
+Actions:
+•	Review application logs. 
+•	Analyze firewall logs. 
+•	Check authentication logs. 
+•	Identify suspicious IP addresses. 
+________________________________________
+Phase 2 – Containment
+Immediate actions:
+•	Disable compromised accounts. 
+•	Block malicious IP addresses. 
+•	Enable emergency rate limiting. 
+•	Rotate exposed API tokens. 
+•	Isolate affected application containers if necessary. 
+________________________________________
+
+
+
+
+Phase 3 – Eradication
+Remove the root cause.
+Tasks:
+•	Force password reset. 
+•	Patch authentication vulnerabilities. 
+•	Remove malicious scripts. 
+•	Update security configurations. 
+•	Scan containers using Trivy. 
+________________________________________
+Phase 4 – Recovery
+Actions:
+•	Restore clean services. 
+•	Monitor user authentication. 
+•	Validate system integrity. 
+•	Notify affected customers. 
+•	Resume production gradually. 
+________________________________________
+Phase 5 – Lessons Learned
+Conduct a post-incident review.
+Questions:
+•	Why did monitoring fail? 
+•	Why wasn't MFA enabled? 
+•	Why were brute-force attempts not detected? 
+•	Which controls should be added? 
+________________________________________
+
+3. Preventing the Attack on Ghaymah Cloud
+	Network Security Controls
+		API Rate Limiting
+		E.G. Maximum 5 login attempts per minute/per IP
+
+	Web Application Firewall (WAF)
+		Configure rules to:
+•	Detect brute-force attacks. 
+•	Block suspicious IP addresses. 
+•	Prevent SQL Injection. 
+•	Prevent XSS. 
+	Firewall Rules
+		Only expose   =>  HTTPS (443) 
+		Restrict:
+•	SSH 
+•	Database ports 
+•	Internal services 
+	Network Segmentation
+		Application
+		       ↓
+	           Private Network
+		       ↓
+		Database
+		The database should never be directly accessible from the Internet.
+
+	
+
+
+	Container Security Controls
+•	Scan every Docker image before deployment. 
+•	Run containers as non-root users. 
+•	Store secrets securely. 
+•	Use read-only file systems when possible. 
+•	Apply least privilege to Kubernetes service accounts. 
+•	Continuously monitor container runtime activity. 
+________________________________________
+4. Alert Rule for Early Detection
+	Detection Logic
+		Trigger an alert if:
+			More than 10 failed logins from the same IP within 60 seconds.
+________________________________________
+Additional Detection Rules
+Alert when:
+•	Login attempts originate from multiple countries in a short time. 
+•	One account receives failed logins from multiple IPs. 
+•	Sudden spike in authentication failures. 
+•	API requests exceed expected thresholds. 
+________________________________________
+Recommendations
+•	Enable MFA for all users. 
+•	Implement account lockout after repeated failures. 
+•	Deploy a Web Application Firewall. 
+•	Use centralized logging with SIEM. 
+•	Perform continuous container vulnerability scanning. 
+•	Conduct regular penetration testing.