Toheeb A. Husain
Cloud Security Engineer
Location: Northampton, England

Open to cloud security, SOC, and detection engineering opportunities with hands-on experience across Microsoft Sentinel, Chronicle SIEM/SOAR, KQL, Terraform, Microsoft Azure, Google Cloud, Security Command Center, and cloud incident response.

About me| Projects| Skills| Certifications| Experience| Education| Awards| Open-source| Volunteering| Contact| Links

View CV GitHub LinkedIn Email Me

About me

Projects

• SentinelPay: AWS Cloud Security & DevSecOps Hardened a vulnerable fintech platform into a Terraform-managed AWS architecture with private ECS Fargate services, WAF-protected ALB ingress, customer-managed encryption, secrets lifecycle controls, CI/CD security gates, and managed detection and response.

  Role: Cloud Security & DevSecOps Engineer
  Domain: AWS Security Architecture, DevSecOps, Infrastructure as Code, Detection Engineering, Secrets Management, Supply Chain Security
  Environment: AWS, Terraform, ECS Fargate, ALB, WAF, Route 53, ACM, RDS PostgreSQL, ElastiCache Redis, S3 Object Lock, KMS, Secrets Manager, IAM, CloudTrail, GuardDuty, Security Hub, AWS Config, EventBridge, Lambda, GitHub Actions OIDC, Docker, Cosign, Syft, Trivy, Checkov, tfsec, SonarQube, Gitleaks, Python Flask

  Hero summary: SentinelPay is a fintech security engineering project where I took an inherited vulnerable Flask-based payments and KYC platform and designed a defensible AWS deployment around the project security constraints. The work covered application hardening, private network design, encrypted data services, scoped service identities, runtime secret handling, signed CI/CD delivery, and cloud-native detection and response.

  Business challenges:

  • The inherited application required cloud hardening before it could be safely deployed as a realistic payments and KYC workload.
  • Internet ingress had to terminate only at an AWS-managed Layer 7 service with AWS WAF coverage for common web attacks and payment endpoint rate limiting.
  • Runtime compute, PostgreSQL, Redis, and KYC document storage had to remain private and encrypted with customer-managed KMS keys.
  • Pipeline access needed to use GitHub Actions OIDC instead of long-lived AWS keys, with security gates before deployment.
  • The environment needed a detection foundation with GuardDuty, CloudTrail, Security Hub, AWS Config, EventBridge containment, and honeytoken alerting.

  Architecture implemented:

  • Edge plane: ALB with HTTPS termination, ACM certificate, AWS WAF managed rule groups for Common, SQLi, and XSS coverage, plus a custom payments rate-limit rule.
  • Application plane: ECS Fargate payments-api and kyc-api services in private subnets across multiple availability zones, using separate task roles and security groups.
  • Data plane: RDS PostgreSQL, ElastiCache Redis with TLS and AUTH token, and a KYC S3 bucket with versioning, server access logging, public access blocks, Object Lock governance mode, and customer-managed KMS encryption.
  • Identity and secrets: least-privilege IAM, KMS key-policy separation between administrators and users, Secrets Manager for runtime secrets, rotation Lambda wiring, and GitHub Actions OIDC roles for plan, apply, ECR push, and Lambda signing.
  • Detection and response: GuardDuty protection plans, CloudTrail with validation, Security Hub standards, AWS Config recording and conformance support, EventBridge routing for high-severity findings, Lambda containment hooks, and an instrumented honeytoken pattern.
  • Pipeline security: Gitleaks, SonarQube, Bandit, Trivy, Checkov, tfsec, SBOM generation, Cosign signing, AWS Signer-backed Lambda code signing, and environment-based promotion from dev to staging to production.

  Outcome: The project produced a production-grade security architecture blueprint for a non-production fintech environment. It demonstrates how to translate explicit security constraints into Terraform modules, CI/CD controls, AWS managed security services, and operational evidence suitable for a security review.

  View SentinelPay Repository

  

• SecureFlow: End-to-End DevSecOps Security Platform Designed and secured a vulnerable cloud-native banking platform by implementing DevSecOps controls across application, infrastructure, container, Kubernetes, supply chain, secrets, and runtime monitoring layers.

  Role: Application Security & Cloud Security Engineer
  Domain: DevSecOps, Application Security, Kubernetes Security, Cloud Security, Container Security, Supply Chain Security, Runtime Threat Detection
  Environment: Python, Flask, PostgreSQL, Docker, Kubernetes, Terraform, GitHub Actions, HashiCorp Vault, OPA Gatekeeper, Falco, Loki, Grafana, SonarQube, Gitleaks, Trivy, Checkov, Cosign, Sigstore

  Hero summary: SecureFlow is a deliberately vulnerable banking platform developed to simulate real-world security weaknesses across modern cloud-native environments. I designed and implemented a complete DevSecOps security architecture that integrates automated security testing, policy enforcement, secrets management, software supply chain security, and runtime threat detection. The objective was to demonstrate how security can be embedded throughout the software development lifecycle rather than being applied only before production deployment.

  Business challenges:

  • Application services contained exploitable vulnerabilities including SQL Injection, Cross-Site Scripting (XSS), Broken Authentication, Insecure Direct Object References (IDOR), CSRF, insecure session management, and business logic flaws.
  • Secrets such as database credentials, JWT signing keys, session secrets, and cloud credentials were stored in plaintext across source code, Docker Compose files, environment variables, and Kubernetes ConfigMaps.
  • Container workloads were deployed with insecure defaults including root containers, vulnerable base images, excessive privileges, missing resource controls, and weak workload isolation.
  • Infrastructure-as-Code introduced cloud security risks including overly permissive IAM roles, public exposure of resources, weak encryption controls, and insecure Kubernetes configurations.
  • No automated security validation existed within the delivery process, allowing vulnerable code and infrastructure changes to progress toward deployment without review.
  • Limited runtime visibility made it difficult to detect suspicious activity, privilege escalation attempts, or abnormal workload behaviour after deployment.

  What I built:

  • Conducted a structured security assessment and documented more than 40 vulnerabilities across application, infrastructure, container, and Kubernetes environments.
  • Mapped identified weaknesses against OWASP categories including Broken Access Control, Injection, Authentication Failures, Security Misconfiguration, Insecure Design, Cryptographic Failures, and Software Supply Chain Failures.
  • Remediated application-layer vulnerabilities including SQL Injection, XSS, weak authentication controls, sensitive error disclosure, IDOR, CSRF, mass assignment, and insecure transaction logic.
  • Integrated Gitleaks into GitHub Actions to detect exposed secrets and automatically block commits containing credentials, tokens, or passwords.
  • Implemented SonarQube for static application security testing (SAST), vulnerability detection, code quality analysis, and security hotspot reporting.
  • Integrated Trivy to scan container images, repositories, and Kubernetes manifests for known vulnerabilities and security misconfigurations.
  • Implemented Checkov to evaluate Terraform and Kubernetes Infrastructure-as-Code against cloud security and compliance best practices.
  • Designed a risk-based Security Gate that aggregates security findings and blocks deployment when critical vulnerabilities are identified.
  • Implemented HashiCorp Vault with Kubernetes authentication, service-specific policies, and Vault Agent Injector to eliminate secrets from source code and Kubernetes resources.
  • Configured Vault audit logging to verify that each service could access only its authorised secret path.
  • Applied Kubernetes hardening controls including non-root execution, resource requests and limits, secure security contexts, image pinning, network segmentation, and policy enforcement.
  • Implemented OPA Gatekeeper policies to enforce Kubernetes security standards and prevent insecure workloads from being deployed.
  • Built software supply chain controls using Cosign, Sigstore, and SBOM attestation to strengthen image provenance and deployment integrity.
  • Implemented Falco runtime threat detection and integrated Grafana dashboards for security monitoring, observability, and incident investigation.
  • Developed an end-to-end security architecture covering build-time, deploy-time, and runtime security controls.

  Key outcomes:

  • Established a secure CI/CD workflow capable of automatically identifying security weaknesses before deployment.
  • Implemented multiple layers of defence across application, infrastructure, container, Kubernetes, and runtime environments.
  • Eliminated hardcoded secrets from application code, deployment manifests, and infrastructure configurations through centralised secret management.
  • Improved Kubernetes security posture through workload hardening, policy enforcement, and network segmentation.
  • Strengthened software supply chain security through image signing, signature verification, and SBOM generation.
  • Enabled real-time detection of suspicious activity through Falco-based runtime monitoring and Grafana observability.
  • Created an auditable security workflow supported by security scans, Vault audit logs, signed container images, SBOM artefacts, and deployment evidence.
  • Demonstrated how DevSecOps principles can be applied to secure applications throughout the entire software development lifecycle.

  Key lessons learned:

  • Security is most effective when embedded throughout the development lifecycle rather than treated as a final deployment checkpoint.
  • Secret management requires identity controls, access policies, auditing, and secure injection mechanisms rather than simply encrypting values.
  • Security gates should be risk-based and capable of distinguishing between blocking and non-blocking findings.
  • Kubernetes security requires multiple complementary controls including workload hardening, policy enforcement, network isolation, and runtime monitoring.
  • Software supply chain security is increasingly important as organisations become more dependent on containers and third-party components.
  • Runtime detection complements preventative controls by providing visibility into threats that bypass earlier security layers.
  • Effective cloud security relies on combining preventative, detective, and governance controls rather than relying on a single security mechanism.

  

  

  

  

  

  

  

• AWS Infrastructure as Code and CI/CD Governance Migrated manually managed AWS infrastructure to Terraform with GitHub Actions, OIDC authentication, remote state, and a senior engineer approval gate for controlled production changes.

  Role: Cloud Security Analyst Consultant - Amdari.io
  Domain: Cloud Security Operations, Infrastructure as Code, CI/CD Governance, Cloud Risk Reduction
  Environment: AWS, Terraform, GitHub Actions, OpenID Connect (OIDC), IAM, S3, DynamoDB, KMS, VPC, EC2, RDS PostgreSQL, Security Groups, GuardDuty, CloudWatch

  Hero summary: I designed and implemented a Terraform-based AWS infrastructure workflow for a regulated fintech organisation where manual console changes had created operational, security, and compliance risk. The solution moved infrastructure into version-controlled code, introduced automated validation through GitHub Actions, used OIDC to remove long-lived AWS credentials, and added a production approval gate so high-risk infrastructure changes require senior engineer review before deployment.

  Business challenges:

  • No authoritative record of cloud infrastructure, making recovery and onboarding dependent on senior engineers' memory.
  • Production changes could be made directly in the AWS console without peer review, approval, or a clear rollback path.
  • Environment drift between development, staging, and production caused failed deployments and delayed releases.
  • Disaster recovery was difficult to execute because infrastructure configuration was not repeatable from code.
  • Regulatory expectations required documented, auditable, and controlled change management for production systems.

  What I built:

  • Created Terraform configuration for the AWS network, compute, database, security group, logging, and encryption layers.
  • Separated one-time backend bootstrap resources from the main application infrastructure.
  • Configured S3 remote state with DynamoDB locking and KMS encryption to protect Terraform state and prevent concurrent changes.
  • Built a GitHub Actions pipeline that runs terraform fmt, terraform init, terraform validate, terraform plan, and terraform apply, and terraform destroy.
  • Stored the generated Terraform plan as a workflow artifact so the reviewed plan is the exact plan applied later.
  • Added a protected production environment gate that pauses deployment until a senior engineer reviews and approves the change.
  • Used GitHub OIDC with AWS IAM role assumption so the pipeline does not rely on stored AWS access keys.

  Key outcomes:

  • Infrastructure changes now follow a controlled path: plan, review, approval, and apply.
  • Production deployments have a clear audit trail through GitHub commits, workflow logs, plan artifacts, and environment approvals.
  • The environment can be rebuilt from Terraform instead of relying on undocumented manual console knowledge.
  • Security-sensitive changes, such as database and security group updates, are reviewed before reaching production.
  • The workflow reduces configuration drift and gives the business stronger evidence for compliance and operational resilience.

  Key lessons learned:

  • Infrastructure as Code is not only an engineering convenience; it is a business control for regulated environments.
  • Approval gates are most valuable when reviewers approve the exact plan that will be applied.
  • OIDC improves CI/CD security by removing the need to store long-lived cloud credentials in GitHub.
  • Remote state, locking, and encryption are foundational controls for safe Terraform collaboration.

  View Terraform Repository

  

  

  

  

  

• Cloud Threat Detection and Automated Response with Microsoft Sentinel Built a Microsoft Sentinel SIEM/SOAR proof of concept that centralised Azure telemetry, introduced KQL-based detections, automated response workflows, and used Terraform to create reusable deployment templates.

  Role: Cloud Security Analyst Consultant - Amdari.io
  Domain: Cloud Security Operations, SIEM/SOAR, Detection Engineering, Automation
  Environment: Microsoft Azure, Microsoft Sentinel, Log Analytics Workspace, Microsoft Defender for Cloud, Microsoft Entra ID, Azure Logic Apps, KQL, Terraform

  Hero summary: I designed and deployed a Microsoft Sentinel proof of concept for CloudScale Logistics to address fragmented visibility, weak alert correlation, and slow manual response across Azure. The solution centralised Azure Activity, Defender for Cloud, and identity telemetry, used KQL and analytics rules to improve threat detection, and supported faster incident handling with Logic Apps automation. I also used Terraform to build reusable infrastructure templates so the deployment could be maintained, versioned, and reused for future implementations.

  Business challenges:

  • No unified security view across subscriptions, identities, and workloads.
  • Alert fatigue from uncorrelated Defender alerts and manual portal reviews.
  • Slow incident response with no documented runbooks or automated containment.
  • Compliance pressure due to weak evidence of structured cloud threat detection.

  What I built:

  • Deployed a dedicated Log Analytics Workspace and enabled Microsoft Sentinel on top of it.
  • Connected Azure Activity Logs, Microsoft Defender for Cloud, and Microsoft Entra ID telemetry.
  • Enabled built-in analytics for brute-force and suspicious activity scenarios.
  • Worked with KQL to investigate sign-ins, role assignments, failed operations, and resource changes.
  • Designed custom detection logic for risky privilege escalation outside business hours.
  • Integrated Azure Logic Apps playbooks to automate incident notification and response workflows.
  • Used Terraform as infrastructure as code to reduce manual configuration, improve consistency, and create a reusable deployment template for future use.

  Tools and technologies:

  • Microsoft Sentinel
  • Azure Log Analytics Workspace
  • Microsoft Defender for Cloud
  • Microsoft Entra ID
  • Azure Activity Logs
  • Azure Logic Apps
  • Kusto Query Language (KQL)
  • Terraform for infrastructure as code

  Key outcomes:

  • Centralised cloud telemetry into one searchable security operations platform.
  • Improved visibility into control-plane activity, authentication patterns, and suspicious changes.
  • Reduced the dependence on manual alert triage by correlating signals into incidents.
  • Created a repeatable detection and response approach aligned to Detect, Respond, and Recover.
  • Delivered reusable Terraform templates that reduced human error and gave the organisation a maintainable starting point for similar future deployments.

  Key lessons learned:

  • Detection engineering only works when the data foundation is complete and consistent.
  • Uncorrelated alerts create noise; incident context is what makes triage effective.
  • KQL is essential for turning cloud activity into investigations and usable detections.
  • Automation matters most when it removes response delay in high-severity scenarios.
  • Strong cloud security posture depends on both visibility and operational response discipline.

  View IaC Repository

  

  

• Respond and Recover from a Cloud Data Breach A hands-on Google Cloud capstone focused on incident detection, containment, remediation, recovery, and compliance verification after a simulated data breach.

  Hero summary: In this capstone, I investigated and remediated a cloud security incident affecting a virtual machine, firewall configuration, and public storage bucket. The scenario involved malware infection, exposed remote access services, privilege escalation risk, and public data exposure. I used Google Cloud security tooling and secure reconfiguration practices to contain the incident, recover workloads, and improve the environment's compliance posture.

  Problem statement: Cymbal Retail experienced a major breach in its cloud environment. Attackers gained access to a vulnerable VM, exploited weak configurations, escalated privileges, and exfiltrated sensitive credit card data through a publicly accessible storage bucket. The environment also showed multiple high-severity findings, including open SSH/RDP exposure, a public IP on the VM, and a public bucket ACL.

  My role:

  • Analyzing findings in Security Command Center.
  • Identifying attack paths and misconfigurations.
  • Containing the breach.
  • Recovering the compromised workload.
  • Remediating storage and firewall weaknesses.
  • Validating remediation through compliance checks.

  Tools and technologies:

  • Google Cloud Security Command Center
  • Compute Engine
  • Cloud Storage
  • VPC Firewall Rules
  • Snapshots / VM recovery
  • Compliance reporting
  • BigQuery / logging concepts
  • IAM and least privilege principles

  Key vulnerabilities identified:

  • Public bucket ACL exposing sensitive data
  • VM with public IP address
  • Open SSH and RDP ports to the internet
  • Default service account / excessive API access risk
  • Firewall logging disabled
  • Malware activity on the compromised VM

  What I did:

  1. Investigation

  I reviewed active findings and compliance results in Security Command Center to understand the scope of the breach and identify the most critical affected resources: the storage bucket, compute instance, and firewall.

  2. Containment and eradication

  I shut down the compromised VM, prevented further exposure, and removed insecure access paths that enabled unauthorized entry. This reduced the attacker's ability to persist or continue lateral activity.

  3. Recovery

  I created a new VM from a trusted snapshot, removed public exposure, and enabled more secure settings such as secure boot to rebuild the workload in a safer state.

  4. Storage remediation

  I removed public access to the storage bucket and enforced uniform bucket-level access to eliminate insecure fine-grained public exposure.

  5. Firewall hardening

  I created a restricted SSH rule, removed overly permissive default firewall rules, and enabled logging to improve network visibility and reduce attack surface.

  6. Compliance verification

  I re-ran compliance checks to confirm that the major vulnerabilities had been remediated and that the environment's security posture had improved.

  Outcome: This project demonstrated practical cloud security skills across detection, response, recovery, and hardening. The final state included a rebuilt VM from a clean snapshot, restricted firewall access, improved bucket security, and verified remediation of major findings tied to the breach scenario.

  Key lessons learned:

  • Misconfigurations can be as dangerous as malware.
  • Public exposure of compute and storage resources creates major risk.
  • Incident response is not only about detection, but also containment and recovery.
  • Logging and compliance validation are critical for both visibility and assurance.
  • Least privilege and secure defaults reduce blast radius during an incident.

  View Final Report

  

  

  

  

• Implementing Scalable Azure IAM and RBAC Built a group-based Azure IAM/RBAC model that enforced least privilege, removed permission creep, and cut admin onboarding to under five minutes.

  Role: Cloud Security Analyst Consultant - Amdari.io
  Domain: Cloud Security, Identity & Access Management (IAM), Cloud Governance
  Duration: 07, March 2026 - 27, March 2026

  Tech stack & tools: Microsoft Azure (Subscriptions, Resource Groups, Virtual Machines), Microsoft Entra ID (Azure AD), Azure RBAC, Azure Portal (GUI), Microsoft Graph PowerShell module, Azure CLI, Microsoft Authenticator.

  Project overview: CloudScale Logistics is a mid-sized global shipping and supply chain provider rapidly expanding its workloads into a multi-subscription Azure environment. As the environment grew, the team relied on manual, user-level permission assignments, which led to permission creep, an unnecessarily large attack surface, and growing compliance risk. As a Cloud Security Analyst Consultant at Amdari.io, I designed and implemented a group-based RBAC model in Microsoft Entra ID and Azure to enforce least privilege, establish a zero-trust, need-to-know baseline, and create a repeatable identity and access pattern.

  Context and problem: The IT team lacked a standardized access hierarchy across Azure subscriptions, and permissions were granted directly to individual user accounts on resources. Over time, this created a situation where many users, including Service Desk personnel, accumulated high-privilege roles such as Owner that exceeded their daily operational duties. This model made it difficult to answer basic security and compliance questions such as who has what access and why, increased the blast radius of any single compromised account, and made onboarding new administrators slow and manual.

  Objectives:

  • Eliminate direct user-to-resource role assignments and move to a group-based RBAC model in Microsoft Entra ID.
  • Establish a zero-trust, need-to-know baseline where identities can authenticate but have no default access to Azure resources.
  • Design a tiered administrative model for Senior Admin, Junior Admin, and Service Desk roles mapped to Azure RBAC roles: Owner, Contributor, and Reader.
  • Ensure access can be managed consistently through Azure Portal, Microsoft Graph PowerShell, and Azure CLI.
  • Reduce administrator onboarding time from several hours of manual assignments to a single group membership change.
  • Improve audit readiness and support cleaner access reviews for standards such as SOC 2 and ISO 27001.

  Architecture and access design: To isolate the proof-of-concept and enforce regional data residency, I created a dedicated resource group named CloudScale-Logistics-RG in the East US region. This resource group served as the management boundary for deploying test resources and validating role behavior without impacting production workloads. I then designed a three-tier administrative structure that mapped Microsoft Entra ID security groups to Azure RBAC roles at clearly defined scopes: Senior Admins to Owner at subscription scope, Junior Admins to Contributor at resource-group scope, and Service Desk to Reader at resource-group scope. All access was assigned to groups instead of individual users, removing direct user-to-resource assignments and enforcing least privilege.

  Implementation:

  • Used Azure Portal to manually create the initial Senior Admin identity, representing the highest administrative tier and following governance-friendly naming and profile practices.
  • Used Microsoft Graph PowerShell to automate Junior Admin provisioning by installing the Graph module, connecting with the required scopes, creating user accounts and the Junior Admins security group, and adding users to the group with commands such as Connect-MgGraph, New-MgUser, New-MgGroup, and New-MgGroupMember.
  • Used Azure CLI to provision Service Desk identities, create the Service Desk group, add members, and support broader role-assignment and resource-management workflows.
  • Audited existing role assignments with Azure CLI to identify direct user permissions and excessive Owner access, including Service Desk users holding privileges beyond their responsibilities.
  • Migrated access from direct user assignments to group-based RBAC and verified effective assignments using Azure CLI role-assignment queries.

  Validating zero-trust and least privilege: I tested both authentication and authorization across all three tiers. All users were confirmed in the tenant and validated for sign-in and MFA registration using Microsoft Authenticator. After deploying a test virtual machine, I confirmed that Owner users could create, modify, and delete resources, Contributor users could manage resources but not assign roles or change access control, and Reader users could view resources and properties but could not create, delete, or start and stop the VM. Attempted actions beyond Reader scope correctly resulted in access denied behavior, demonstrating blast radius limitation.

  Cost management and decommissioning: To avoid unnecessary spend and leave the environment clean, I listed resources with Azure CLI, deleted proof-of-concept resources, removed the CloudScale-Logistics-RG resource group, and verified that no unnecessary cost remained after decommissioning.

  Results:

  • Reduced administrator onboarding time from several hours of manual per-resource assignments to a single group membership change, typically under five minutes.
  • Eliminated direct Owner role assignments for non-admin identities such as Service Desk, significantly reducing the attack surface.
  • Confirmed that Reader-level accounts could not perform destructive or state-changing actions on Azure resources, limiting blast radius.
  • Established a reusable, group-based RBAC pattern aligned with least privilege and zero-trust principles.
  • Improved audit readiness by centralizing role assignments on Entra ID groups, simplifying periodic access reviews for SOC 2 and ISO 27001.
  • Demonstrated cross-platform IAM management via Azure Portal, Microsoft Graph PowerShell, and Azure CLI, increasing operational flexibility.

  Challenges and learnings: This project deepened my understanding of Azure RBAC scopes and inheritance across subscriptions and resource groups, and showed how balancing usability with strict least privilege is central to effective cloud governance. It also highlighted how Azure Portal, Microsoft Graph PowerShell, and Azure CLI complement each other when building reliable and auditable IAM workflows.

  
• J.P. Morgan Software Engineering Virtual Experience Built Spring Boot REST APIs with Kafka messaging and H2/JPA for Midas Core incentive and balance operations.
  • Developed and tested REST API endpoints (GET/POST) supporting incentive and balance workflows with secure data validation.
  • Integrated Apache Kafka message queuing to process and persist transaction data in real time.
  • Implemented H2 in-memory database plus Spring Data JPA repositories for consistent data access.
  • Applied dependency injection, debugging, and transaction management to keep services reliable.
  • Simulated financial backend operations used at J.P. Morgan Chase & Co.
• SensoryNeural - AI-Powered Sensory Support System (Team Lead / Co-Creator) 2nd Place, Elevate Great AI Competition (London, £2,500) with AI + IoT sensory-safe environments.
  • Architected an ethical AI framework with explainable dashboards for caregiver transparency.
  • Built privacy-by-design data anonymization aligned with GDPR and the EU AI Act from the first design pass.
  • Engineered a real-time IoT hub that modulates lighting and noise-cancellation based on AI-predicted stress triggers.
  • Led a multidisciplinary team through agile sprints, ensuring timely delivery and cohesive integration of AI, IoT, and user experience components.
  • Visited the SensoryNeural website: click here
• Personal Financial Management Full-stack Spring Boot API with Angular dashboard and MySQL storage.
  • Implemented secure CRUD endpoints for financial data with Spring Boot and MySQL.
  • Built an Angular dashboard with dynamic charts/graphs for real-time spending insights.
  • Designed RESTful resource structure and data validation for reliable user flows.
• Database Management System Oracle SQL database for a school system with optimized schema design.
  • Used ER modelling to optimize schema and improve retrieval efficiency by ~30%.
  • Authored stored queries and constraints for better organization and data integrity.

Skills

Certifications

Experience

• Cloud Security Analyst Consultant - Amdari.io November 2025 - Present
  • Delivered cloud security engineering and DevSecOps solutions across AWS and Azure environments, covering IAM, SIEM/SOAR, Infrastructure as Code, cloud governance, and security automation.
  • Designed and implemented Microsoft Entra ID and Azure RBAC access control models using least-privilege principles to strengthen identity governance and reduce permission creep.
  • Built a Microsoft Sentinel SIEM/SOAR proof of concept that centralised telemetry, developed KQL-based detections, and supported automated incident response workflows.
  • Developed Terraform-based cloud infrastructure deployments across AWS and Azure, integrating security controls, policy enforcement, encryption, logging, and access governance.
  • Implemented secure CI/CD security controls including SAST, secrets detection, infrastructure scanning, container security testing, and deployment approval workflows.
  • Designed and secured Kubernetes and containerised environments through workload hardening, policy enforcement, runtime monitoring, network segmentation, and secure secrets management.
  • Strengthened software supply chain security through image signing, SBOM generation, vulnerability management, and deployment integrity verification.
  • Performed cloud security assessments, privilege reviews, and security validation exercises to identify vulnerabilities, reduce attack surface, and improve overall cloud security posture.
  • Used Terraform, GitHub Actions, AWS IAM, Microsoft Graph PowerShell, Azure CLI, Sentinel, Kubernetes, Vault, Trivy, Checkov, Falco, and Grafana to deliver repeatable security solutions and operational resilience.
• Cyber Threat Intelligence Analyst Intern - CSFI Cyber Security Forum Initiative (Jul 2025 - Aug 2025)
  • Delivered actionable intelligence mapped to MITRE ATT&CK, D3FEND, and the Cyber Kill Chain.
  • Conducted OSINT-based threat hunting to identify IOCs and emerging trends; enriched threat feeds with sandbox analysis.
  • Collaborated on RFIs and presented findings to stakeholders.
  • Analysed 50+ phishing domains and mapped TTPs to MITRE ATT&CK.
• Mail Sorter - Angard Staffing (Royal Mail) Midland Super Hub Northampton (Sep 2023 - Jan 2026)
  • Recorded and analysed truck flow statistics to optimise logistics and operational efficiency.
  • Coordinated team activities and fostered a collaborative, productive environment.

Education

• Bachelor's in Computer Science (Expected Graduation Year 2026) University of Northampton, Northampton, United Kingdom

  BSc Computer Science (Expected First Class, 2026). Relevant modules:

  • Data Structures and Algorithms
  • Modern Databases
  • Web Development
  • Operating Systems
  • Computer Networking
  • Mobile Application Development
  • Advanced AI and Applications
  

Awards & Honors

• Daria-Romana Pop Award Best Intern Award, Cyber Security Forum Initiative (CSFI)

  Recognised for standout impact during the CSFI internship cohort, delivering actionable CTI outputs.

• Self-financed University Education Demonstrated resilience balancing work, study, and high performance

  Funded studies while maintaining strong academic results, showing discipline, ownership, and time management.

Open-source Contributions

• SigmaHQ Contribution Improved DNS exfiltration detection by tightening Invoke-DNSExfiltrator rule parameters.

  Improved the SigmaHQ DNS exfiltration rule by requiring the mandatory Invoke-DNSExfiltrator arguments (-i, -d, -p), closing gaps that could miss real-world activity.

  • Analyzed the tool source, rebuilt detection logic, and aligned with Sigma naming/conventions.
  • Simulated attack scenarios, tested locally, and validated with sigma check.

  Pull Request #5801 - Improved DNS Exfiltration Detection Logic

  This contribution strengthens SOC and detection teams by improving coverage for covert DNS exfiltration techniques.

Volunteering

• Assistant Team Lead - CSFI Cyber Security Forum Initiative (Sep 2025 - Feb 2026)
  • Supports coordination of CTI tasks and mentors interns.
  • Assists with project planning and reviewing threat analysis reports.
  • Continues contributing to CSFI's mission on a volunteer basis.
• AI Society Volunteer - University of Northampton Sep 2023 - Present
  • Contributed to workshops on AI trends and ML projects.
  • Co-led a Discord channel curating AI opportunities, boosting member engagement.

Featured Links

• GitHub Profile
• LinkedIn Activity
• Cloud Data Breach Technical Report

×