Selected work
Projects
Detailed case studies — architecture, technical decisions and results — for the internships and personal projects behind my CV.
SOC Lab — CHU Hassan II
Cybersecurity Intern — IT & Security Department, Fès
Overview
Designed and deployed an end-to-end Security Operations Center in an isolated VMware lab: detection, enrichment, case management and automated response, validated against real attack simulations mapped to MITRE ATT&CK.
Objectives
- Centralize detection across network, host and web layers
- Automate alert triage to reduce manual analyst workload
- Validate detection coverage through red-team simulations
AWS Architecture
Detection & response pipeline
Screenshots
Technologies
What I did
- Built the isolated VMware lab and integrated all SOC components end to end
- Automated alert extraction, deduplication, VirusTotal/MISP enrichment, email notification and case creation in TheHive via Shuffle
- Ran red-team simulations mapped to MITRE ATT&CK to validate detection and response
- Evaluated web attack protection with ModSecurity and OWASP CRS
Challenges & technical decisions
Challenge — Raw SIEM alerts arrived faster than they could be manually triaged, creating a backlog similar to real SOC alert fatigue.
Decision — Built a Shuffle workflow to auto-deduplicate alerts and enrich them with VirusTotal/MISP reputation data before they ever reached an analyst.
Challenge — Needed to prove detection actually worked, not just that tools were installed.
Decision — Ran attack simulations mapped to specific MITRE ATT&CK techniques and checked each one produced a corresponding alert end to end.
Results
8
Integrated SOC tools
1
Automated triage pipeline
ATT&CK
Mapped simulations
Key learnings
- A SOC's value comes from the workflow connecting tools, not from any single tool in isolation.
- Automating enrichment first is what actually reduces analyst workload — detection alone just moves the bottleneck downstream.
Links
Private Cloud Hardening
Personal / academic project
Overview
Built and secured an OpenStack private cloud with segmented DMZ, database and management zones, hardened with defense-in-depth controls and validated through penetration testing.
Architecture
Screenshots
Technologies
What I did
- Segmented the network into DMZ, database and management zones using OVN security groups
- Implemented defense-in-depth: SSH hardening, UFW, Fail2ban, ModSecurity/OWASP CRS and Wazuh for centralized monitoring
- Validated hardening through penetration testing from Kali Linux and benchmarked with Lynis against CIS controls
Challenges & technical decisions
Challenge — A flat network meant a single compromised host in the app tier could reach the database directly.
Decision — Segmented the infrastructure into DMZ, app and database zones with OVN security groups, so lateral movement requires crossing an explicit, monitored boundary.
Challenge — Manual hardening checklists are easy to apply inconsistently across hosts.
Decision — Benchmarked every host against CIS controls with Lynis after hardening, turning a checklist into a repeatable, scored audit.
Results
3
Segmented network zones
5+
Hardening controls applied
CIS
Benchmark-validated
Key learnings
- Network segmentation is only as strong as the security group rules enforcing it — each zone boundary needs to be tested, not assumed.
- Hardening and monitoring are complementary: Wazuh caught misconfigurations that static hardening alone would have missed.
Links
AWS Cloud Security Monitoring & Automated Incident Response
Personal project
Overview
Designed and deployed a secure, segmented AWS environment using Terraform, with centralized logging, continuous threat detection, security monitoring, and automated incident response for compromised EC2 instances.
AWS Architecture
Detection & Response Pipeline
Technologies
What I Did
- Designed and deployed a segmented AWS environment with Terraform, including a VPC, public and private subnets, ALB, WAF, RDS, IAM controls, KMS encryption, and VPC Endpoints for private service connectivity.
- Implemented centralized logging and security monitoring using CloudTrail, VPC Flow Logs, AWS Config, GuardDuty, and Security Hub.
- Built an automated incident response workflow using EventBridge, SNS, and Lambda to process high-severity security findings and automatically quarantine affected EC2 instances.
- Validated the security architecture through controlled attack simulations, including privilege escalation, port scanning, and SQL injection/XSS scenarios mitigated by AWS WAF.
Challenges & Technical Decisions
Challenge — Security alerts alone do not immediately contain a compromised EC2 instance.
Decision — Connected high-severity GuardDuty and Security Hub findings to EventBridge, SNS, and Lambda to trigger automated alerting and EC2 quarantine.
Challenge — A public-facing application should not directly expose its database or rely on unnecessary public network paths for AWS service communication.
Decision — Placed the database in private subnets, enforced least-privilege IAM and KMS encryption, and used VPC Endpoints for private connectivity to supported AWS services.
Results
Terraform
Infrastructure as code
Automated
EC2 quarantine on high-severity findings
3
Attack scenarios validated
Key Learnings
- Effective security monitoring requires an actionable response layer: connecting GuardDuty and Security Hub to EventBridge and Lambda transforms security findings into automated containment.
- Security should be built into the architecture from the beginning through network segmentation, least-privilege IAM, encryption, and private connectivity.
Links
Secure CI/CD Pipeline — DevSecOps Automation
Personal project
Overview
Built an end-to-end DevSecOps pipeline with GitHub Actions on a fork of OWASP Juice Shop. Five security scanners feed a centralized Python Quality Gate that applies severity thresholds and automatically blocks non-compliant builds.
Pipeline
Technologies
What I did
- Integrated SAST (Semgrep), SCA (OWASP Dependency-Check), secret scanning (Gitleaks), container scanning (Trivy) and DAST (OWASP ZAP) into a single GitHub Actions pipeline
- Developed a centralized Quality Gate in Python that aggregates findings, applies severity thresholds (0 critical, at most 2 high, at most 10 medium) and blocks non-compliant builds
- Published JSON/HTML reports from the pipeline and tracked accepted findings in a documented security exceptions file
Challenges & technical decisions
Challenge — Each scanner reports findings in its own format and severity scale, so a build could not be judged consistently.
Decision — Centralized every result in one Python Quality Gate that aggregates findings and applies a single set of severity thresholds.
Challenge — Juice Shop is deliberately vulnerable, so known and accepted findings would fail every build without a way to document them.
Decision — Kept the thresholds fixed and recorded accepted findings in a documented exceptions file, so nothing is waved through silently.
Results
5
Integrated security scanners
1
Centralized Quality Gate
JSON/HTML
Published reports
Key learnings
- A quality gate is only credible if the thresholds stay fixed and exceptions are documented — otherwise failures get waved through.
- SAST, SCA, secrets, container and DAST scans each catch a different class of issue; none of them is enough on its own.
Links
Cyber Threat Intelligence Platform
Cybersecurity Intern — Symolia Groupe, Rabat
Overview
Designed and deployed a Cyber Threat Intelligence pipeline correlating multiple external sources for continuous IOC enrichment and SOC-oriented reporting.
Pipeline
Screenshots
Technologies
What I did
- Integrated CVE, VirusTotal, Shodan and OSINT sources into a single enrichment pipeline
- Correlated identified threats with MITRE ATT&CK for contextualization and prioritization
- Built a real-time dashboard and containerized the platform with Docker for scalable deployment
Challenges & technical decisions
Challenge — CVE, VirusTotal, Shodan and OSINT sources each return data in different formats with different rate limits.
Decision — Normalized every source into a common IOC schema before correlation, and queued enrichment calls to stay under each API's rate limit.
Challenge — Raw IOC lists don't tell an analyst what to prioritize first.
Decision — Mapped correlated threats to MITRE ATT&CK techniques so the dashboard surfaces context, not just a flat list of indicators.
Results
4
Correlated data sources
Real-time
Dashboard refresh
Docker
Containerized deployment
Key learnings
- Correlation is what turns raw threat data into intelligence — a list of IOCs without ATT&CK context is just noise.
- Containerizing the pipeline early made it trivial to redeploy the platform in a clean environment for demos.
Links
Smart Lock with ZKP Authentication
Personal / academic project
Overview
A secure smart lock system authenticating users with Zero-Knowledge Proofs — no raw credentials ever transmitted or stored.
Architecture
Technologies
What I did
- Designed a ZKP-based authentication protocol so credentials are never transmitted or stored in raw form
- Implemented asymmetric cryptography for the challenge-response exchange to prevent man-in-the-middle attacks
- Integrated an Android client with a Spring Boot backend secured via JWT session management
Challenges & technical decisions
Challenge — Traditional password-based auth means the backend must store something derived from the user's secret, which is itself a liability if breached.
Decision — Used a Zero-Knowledge Proof challenge-response scheme so the server can verify identity without ever holding a value that could be reversed into the credential.
Challenge — A challenge-response exchange is still vulnerable to interception if the channel itself isn't protected.
Decision — Layered asymmetric cryptography on top of the protocol specifically to close that man-in-the-middle gap.
Results
0
Raw credentials stored
ZKP
Auth protocol
JWT
Session management
Key learnings
- Zero-Knowledge Proofs make a strong theoretical guarantee, but the surrounding transport still needs its own protection — crypto primitives don't compose safely by default.
- Designing the protocol before writing any Android/Spring Boot code made the client-server contract far easier to implement correctly.
Links