Introduction
Several projects last week made me realize that I should revisit my VAPT and DRP protocols.
I have worked as a freelance VAPT and DRP implementer for some time. Recent vulnerability disclosures and exploits have made me question whether my existing assessment and response workflows are still sufficient.
The concern is no longer limited to individual applications or operating systems. Vulnerabilities can affect storage systems such as NAS and SAN, Linux hosts, databases, Kubernetes, containerized environments, and even connected IoT devices.
VAPT and DRP are two different disciplines, but both are affected by the changing threat landscape. VAPT helps identify and assess security weaknesses, while DRP prepares an organization to recover when an incident affects its infrastructure or services.
I believe it is time to reconsider how these protocols work together.
1. Everything2Shell
I started to call this trend Everything2Shell because vulnerabilities are appearing across different layers of the technology stack, and some can eventually lead to remote code execution.
We have seen examples such as PHP2Shell, React2Shell, Node2Shell, and vulnerabilities affecting database and container platforms.
These vulnerabilities do not necessarily have the same technical causes. Some originate from programming languages, others from application frameworks, shared libraries, database engines, or infrastructure components. However, the potential consequences can be similar: unauthorized code execution and compromise of the affected service.
The concern is that a vulnerable component does not always remain an isolated problem. If the affected service has access to other infrastructure, sensitive information, or privileged credentials, the impact may extend beyond its original environment.
One important distinction is that remote code execution does not automatically mean administrative or root access. The actual impact depends on the permissions of the affected process and whether additional security boundaries can be crossed.
This is why I think we need to reconsider security across the entire technology stack instead of focusing only on the application that initially reports a vulnerability.
2. Infrastructure as Code (IaC)
I think we should start revisiting our Infrastructure as Code (IaC).
IaC teams now need to work closely with security experts to review existing infrastructure definitions, modules, templates, and deployment scripts.
Some legacy code may require modification or complete rewriting, while other parts may remain valid after a security review. The objective is to identify configurations that are no longer appropriate and determine whether affected infrastructure needs to be redeployed.
This is particularly important when IaC is used for self-service infrastructure provisioning.
Self-service allows development and operational teams to provision their own resources without waiting for infrastructure administrators to handle every request. However, the ability to provision resources should not automatically provide unrestricted administrative access.
We need to review the permissions granted to users, automated services, deployment pipelines, and service accounts.
This brings us to Identity and Access Management (IAM) and Role-Based Access Control (RBAC).
Existing IAM policies, RBAC roles, service accounts, and deployment permissions need to be reviewed again. We should ensure that each user or automated process has only the permissions necessary to perform its assigned tasks.
The review should also include infrastructure state files, deployment credentials, configuration repositories, and CI/CD pipelines. Compromising the source code or deployment process could affect every environment created from it.
I would also consider introducing security checks into the IaC deployment process. Configuration scanning, policy validation, dependency reviews, and approval workflows should happen before changes reach production.
The objective is not simply to update the IaC code. We also need to verify that the deployed infrastructure reflects the revised security policies.
3. Infrastructure and Platform Security
After reviewing IaC and access control, we need to examine the infrastructure that is already running.
Storage: NAS and SAN
Storage systems should not be overlooked during vulnerability assessments.
NAS and SAN environments may contain large volumes of operational data, application information, databases, and backup resources. A vulnerability affecting their management interfaces, firmware, or connected services could have consequences beyond the storage system itself.
We should review firmware versions, management interfaces, access permissions, network connections, and vendor support policies.
Storage management should also be separated from ordinary client access wherever possible. Administrative access should be limited to authorized infrastructure personnel and approved management systems.
Another important consideration is backup protection. Storage snapshots are useful, but they should not be treated as a replacement for independent, immutable or offline backups.
Linux and Operating Systems
Linux is another critical component because it frequently supports application servers, databases, storage services, virtualization, and container platforms.
Security reviews should include kernel versions, installed packages, system services, exposed ports, user permissions, SSH access, and security configurations.
We also need to identify unsupported operating systems and packages that no longer receive security updates.
A vulnerability in a shared system library may affect multiple applications. Therefore, checking only the application version is not sufficient.
Docker and Kubernetes
Containerization does not automatically guarantee isolation.
We need to review container images, base operating systems, package dependencies, runtime permissions, mounted volumes, secrets, and communication between containers.
Kubernetes introduces additional components that need attention, including the API server, control plane, worker nodes, service accounts, RBAC, network policies, and container registries.
In particular, we should review whether workloads have been granted unnecessary permissions and whether their access to the host operating system or other services is properly restricted.
The same review should cover the CI/CD pipelines responsible for building and deploying container images.
A secure application image does not necessarily mean that the deployment environment is secure.
Infrastructure recovery considerations
These infrastructure reviews should also include DRP.
If a storage system, Linux host, container platform, or Kubernetes cluster is compromised, restoring the application alone may not be enough.
We need to understand which infrastructure components depend on one another and establish the correct recovery order.
IaC can help rebuild infrastructure consistently, but only when the source code, deployment credentials, configuration files, and required artifacts are trusted.
4. Home Assistant and IoT Security
Another concern is the increasing number of vulnerabilities affecting IoT devices.
Many IoT devices have limited security update capabilities. Some manufacturers provide updates only for a short period, while others may stop supporting a product before the device reaches the end of its useful life.
This creates a difficult situation because replacing every device is not always practical.
Home Assistant is one example of a platform that integrates devices and services from different manufacturers into one environment. Although this provides flexibility, it also means that we need to consider the security of the platform, its integrations, add-ons, and connected devices.
We should not assume that securing Home Assistant automatically secures every connected device.
When a device cannot receive security updates, alternative controls become necessary.
One approach is to use firewalls or network gateways as gatekeepers. These controls can restrict unnecessary communication, control outbound traffic, and limit which services a device can contact.
Network segmentation is also important. Consumer IoT devices should not automatically have access to trusted workstations, servers, NAS systems, or other sensitive infrastructure.
I would also consider using proxies or application gateways where appropriate. These can mediate supported application-layer requests and apply additional access policies.
However, not every IoT protocol can be inspected through a conventional proxy. Firewall rules and network policies remain important for traffic that cannot be mediated at the application layer.
Another consideration is integrating IAM and identity-aware access controls into the environment.
Users, devices, and services should have appropriate identities and permissions before accessing sensitive resources. Where devices cannot support modern authentication themselves, access can sometimes be controlled through a gateway or an intermediary service.
We should also reconsider the manufacturers we choose. Security update availability, vulnerability disclosure procedures, product support lifecycles, and device management capabilities should be part of the selection criteria.
The objective is to avoid relying entirely on the security capabilities of individual IoT devices.
5. Healthcare at Home: A Higher Security Level
Healthcare at Home requires a different level of security consideration.
Unlike ordinary home automation, these environments may include medical devices, patient monitoring systems, healthcare applications, and sensitive patient information.
A patient’s home may contain medical equipment alongside personal computers, smartphones, smart speakers, cameras, and other consumer IoT devices.
The problem is that these devices do not necessarily share the same security standards or update capabilities.
We cannot simply apply the same security policies used for ordinary home automation. Medical devices may have specific communication requirements, limited firmware update capabilities, and operational requirements that must not be interrupted.
I would consider Healthcare at Home a higher-assurance environment, with stricter security and operational requirements.
Network segmentation should separate medical equipment and healthcare information systems from personal devices and general home automation.
Access should be controlled through appropriate identity and authentication mechanisms. Firewalls and gateways should restrict unnecessary communications, while monitoring should help identify unexpected changes in device or network behaviour.
Another important consideration is protecting patient information. We need to consider where information is stored, how it is transferred, which services can access it, and how long it needs to be retained.
We should also reconsider the vendors providing medical devices and connected healthcare services. Their security update policies, technical support, vulnerability response processes, and product lifecycle need to be understood before integrating their products into a healthcare environment.
However, security changes must not interrupt essential medical functions.
For example, blocking all outbound communications from a monitoring device could prevent patient measurements from reaching healthcare professionals. Updates and network restrictions must therefore be reviewed with the relevant healthcare and device specialists.
The objective is not only to prevent unauthorized access, but also to protect patient information, maintain the integrity of medical data, and ensure that healthcare services remain available.
6. Revisiting the VAPT Workflow with AI
With all these changes, I also need to reconsider how I conduct vulnerability assessments.
Normally, I put system logs and assessment results through my program to check for known CVEs and exploits, then reconfirm the findings.
However, the increasing number of vulnerabilities and the variety of affected technologies make this approach insufficient on its own.
I want to introduce AI into the assessment workflow.
Instead of relying only on automated detection, I can use AI to help review logs, correlate findings with known CVEs, examine affected software versions, and identify potential relationships between vulnerabilities.
AI can also help classify findings and identify possible false positives.
However, I do not want AI to automatically dismiss a finding simply because it appears to be a false positive.
Some findings may initially look harmless but require deeper investigation. Others may be genuine vulnerabilities but not exploitable in the particular environment being assessed.
We need to distinguish between a genuine vulnerability, an affected but unreachable component, an unconfirmed finding, and a false positive.
AI should help with the investigation, but the final assessment still needs technical confirmation.
I would also introduce more context when prioritizing the results. A CVE score alone does not tell us the complete risk.
We should consider whether the affected component is exposed to the Internet, whether exploitation is known to be occurring, what permissions the affected service has, what information it can access, and which business services depend on it.
This should help us identify which findings need immediate attention and which can be scheduled for normal maintenance.
Another consideration is protecting assessment information. Logs, configuration files, and system inventories may contain sensitive information. They should only be processed through approved AI environments with appropriate data protection controls.
7. Vulnerability Mitigation and Service Availability
Identifying a vulnerability is only part of the process. We still need to determine how to mitigate it without causing unnecessary disruption.
Some vulnerabilities may require immediate patching. Others may require configuration changes, additional access restrictions, network isolation, or temporary service shutdowns.
In some situations, temporarily disabling a service until the necessary patches are installed may be safer than keeping an exposed service running.
For example, some maintenance activities in my environment may require approximately 2-3 hours to complete.
However, this decision should not be based only on the severity of a CVE. We also need to consider business requirements, service dependencies, data availability, and the possibility of interrupting other systems.
Before applying changes, we should establish a maintenance window, verify backups, test the patches where possible, and define a rollback procedure.
After deployment, we need to verify that the vulnerability has been addressed and that the affected services are functioning as expected.
For IaC-managed environments, changes should be reflected in the approved source code and deployment process rather than leaving production with undocumented manual modifications.
8. Revisiting the DRP Workflow
This brings us back to Disaster Recovery Planning.
DRP should not be limited to restoring data after a system failure. We need to consider what happens when infrastructure has been compromised.
For example, restoring a database without checking the operating system, application dependencies, service accounts, and network configuration could bring the same security weaknesses back into production.
The recovery process should therefore include a review of the environment before it is returned to service.
I would reconsider several parts of my existing DRP procedures:
- Infrastructure recovery: Rebuild affected servers, storage, network services, and container environments from trusted configurations.
- Identity recovery: Verify IAM, RBAC, administrative accounts, service accounts, and credentials.
- Configuration recovery: Use approved IaC templates and validated configurations rather than relying on unknown or potentially compromised copies.
- Data recovery: Restore data from verified backups and check its integrity before returning it to production.
- Service validation: Confirm that applications, integrations, monitoring, and communication between systems are working correctly.
- Security validation: Reassess the recovered environment before reconnecting it to other networks or exposing services externally.
We should also reconsider the protection of backup systems themselves.
Backups should not depend entirely on the same credentials and infrastructure that may become compromised during an incident. Offline or immutable backups provide another layer of protection.
Most importantly, we need to test recovery procedures regularly.
Having a backup does not automatically mean that we can restore a service within the expected timeframe. We need to verify both Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
9. Bringing VAPT and DRP Together
I do not intend to combine VAPT and DRP into one protocol. They have different objectives and should retain their own processes.
However, I think both need to share more information.
VAPT findings should help DRP identify which infrastructure components may need to be isolated, rebuilt, or recovered differently.
DRP testing should also help VAPT understand which systems are critical and where weaknesses could have a greater operational impact.
For example, if a vulnerability affects a storage platform that supports multiple applications, the assessment should not stop at the storage system itself. We should also understand the applications and services that depend on it.
Similarly, if a healthcare monitoring environment needs to be isolated during an incident, the recovery plan must account for the clinical services that depend on that environment.
This requires cooperation between security experts, infrastructure teams, application developers, network administrators, vendors, and business or healthcare service owners.
The security review should not happen only when a vulnerability is announced. It should become part of the infrastructure lifecycle.
Sum up
I think it is time to revisit how we approach VAPT and DRP.
The technology environment is becoming more interconnected, and vulnerabilities can affect multiple layers of the same infrastructure. From IaC and IAM to storage, Linux, containers, Home Assistant, and healthcare devices, each component introduces its own security considerations.
AI may help us process information and identify relationships that would otherwise take considerable time to investigate. However, it should support technical assessment rather than replace security expertise.
The same applies to disaster recovery. Having backups and deployment scripts is not enough. We need to know whether the configurations are trustworthy, whether access permissions are still appropriate, and whether the recovered environment can operate securely.
Perhaps the most important change is that security and recovery should no longer be treated as separate activities that happen only when something goes wrong.
They need to be part of how we design, deploy, operate, maintain, and recover our infrastructure.