Evaluation of Self Healing for Cyber Security (Containerized)
Cyber Security
Semester programme:Master Applied IT
Client company:TNO (The Netherlands Organisation for Applied Scientific Research)
Project group members:Stefano Nieuwenhuizen
Project description
SH4CS (Self-Healing for Cyber Security) is TNO's bio-inspired security framework for cyber security. Instead of trying to prevent every intrusion, it detects attacks and heals itself by regenerating compromised containers. A sidecar component, the Lymphocyte, runs a control loop: it raises a threat level when an attack is detected and regenerates the container once a threshold is reached, then resets.
The central design challenge is that SH4CS has no memory of past attacks: regeneration wipes the threat state, so a previously seen attack is detected and handled as slowly as a new one. My research tests how effective SH4CS is against MITRE ATT&CK mapped attack scenarios, using detection time, regeneration time and re infection rate. It looks at where the system's design falls short, and from there I sketched an immune memory concept.
Context
SH4CS is a cybersecurity project for Cyber security as a whole, however in my specific project in the containerized security. Instead of trying to prevent every intrusion, it detects attacks and heals itself by replacing compromised containers with clean ones, modelled on the human immune system. The test environment is DVWA running on the Fontys EduCloud Kubernetes cluster, attacked with scripted scenarios mapped to three MITRE ATT&CK techniques. The project is part of TNO's broader self-healing security research.
Results
The project produced a working artifact and a set of measured results. SH4CS was deployed end to end on a Kubernetes cluster, including DVWA, the Lymphocyte self-healing sidecar, and the full detection pipeline, along with the scripts needed to launch and time scripted attacks.
The three MITRE ATT&CK mapped scenarios were run and re-run, giving measured detection and regeneration times across all scenarios. The work also explains two structural limits: a single attack type alone cannot trigger regeneration, and re-attack timing varies depending on whether the restart causes the alert to reset to a fresh state, not on attack intensity.
During testing, a real race condition was found and fixed in the upstream SH4CS source, confirmed through static code analysis rather than assumption, which is a concrete contribution back to the framework.
The other output is the immune memory concept: a design for giving SH4CS persistent memory of attack signatures across regenerations, with two candidate ways to integrate it into the mechanism. This is the proposed next step, not yet implemented.
The results come from repeated, instrumented runs against a real Kubernetes deployment and a real vulnerable web application, supporting reasonable confidence in the findings for this environment. In TRL terms, my own assessment rather than a documented figure, I'd place the current work around TRL 3, with the immune memory design itself closer to TRL 1/2.
About the project group
This is an individual graduation project rather than a multi-person group. I'm a Master of Applied IT student previously did my Bachelor at Fontys and specializing in Infrastructure. This project was an 18 week research project for TNO. I worked independently day to day: setting up and debugging the test environment on Kubernetes, running and re-running the three attack scenarios, and writing up the findings and the IEEE paper, with periodic check-ins with my supervisors. Next to this we also have stand-ups on Tuesdays and Fridays in which we can discuss our progress and ask for feedback. These stand-ups were really valuable.