How can you secure systems during evolution and maintenance?

Il y a des outils qui s'intègrent au chaîne de build et qui permettent de scanner les dépendances et de vérifier les différentes vulnérabilités, dépréciations ou mises à jour existantes. La chaîne de build peut aussi intégrer des modules de reporting. Pour d'autres composants, une inscription aux chaînes de diffusion et la veille permettent de suivre les différentes mises à jour à venir ou disponible. Il faut après vérifier l'intégration de chacune des mises à jour qui peuvent nécessiter des adaptations plus ou moins impactantes. Enfin il faut maintenir des fiches de versions et de stratégie, des procédures.

One good way to assess the current state is to run SAST, DAST, IAST, SCA, RAST, MAST tools. They can run integrated in your pipeline or isolated and individually. And will provide a very good backlog for your actions.

Current state assessment of the system is the no.1 prerequisite for any changes to it. That being set, depending on the system status-quo, you have a few choices: if the state of the documentation is bad or incomplete, it needs to be updated before any changes are even considered; secondarily, a system should strive to have no vulnerabilities or have methods to mitigate them. State assessment, under good circumstances, will be a verification of the deployed system vs documentation and identification of impact of the evolution / maintenance initiative by clearly highlighting impacted components and it's dependencies.

You must prioritize. I recommend to go for OWASP top 10 firstly. And hardening for o.s/runtimes secondly or parallelly if possible.

System security must be analyzed top-down, and cover all phases of the device life cycle. For high-security systems use proven methodologies by certification bodies (Common-Criteria, FIPS, etc).

Protecting systems during evolution and maintenance is crucial to ensuring they remain safe, reliable and performing over time. First, before implementing significant changes, extensive testing should be performed to ensure that the system works correctly and that the changes do not have unwanted effects on other parts of the system. This can include unit testing, integration testing, regression testing, and load testing. It is then necessary to carry out regular backups of critical system data to protect them from accidental loss or damage caused by errors during system evolution and maintenance. By also applying these practices, you can protect your systems during evolution and maintenance, ensuring they remain secure and reliable.

Secure coding guidelines and implementation are essential and enforcement as well as checking / auditing them in the deployment pipeline is a must for successful and stress-free system updates.

In any system, traditional monolithic structures or distributed SOA systems, testing as well continuous logging and monitoring are key, especially after new deployments. before you deploy changes, depending on the impact of them on the system, performance and CySec assessments and testing should be performed again to ensure proper functionality from security and performance standpoints. After the deployment, proper setup and configuration of the observability tool with alerts, dashboards for application as well as infrastructure combined with well-trained support service personal will ensure successful running of the updated system.

Not only update, also plan for upgrade when needed. Otherwise you will end up with an unsuported end of life software that will accumulate security breaches over the years. Depending on the system criticality for the business it can be really difficult to update/upgrade with zero downtime. If possible use Blue Green Deployment for near zero downtime, or similar technique.

The human factor is key in any and all aspects of the system, but educate the user is an insufficient concept or a practical impossibility under many circumstances. Many systems today are SaaS based, meaning that the users can be from diverse background from all over the world. This implies that they will register and potentially can start using the system without proper training. Depending on the system and it's target users, it may be impossible practically, to train all users so appropriate non-functional requirements have to be defined and implemented to mitigate this issue.

The most appropriate tool in the box of the system architect is the NFRs (non-functional requirements). With these, controls and measures can be defined and put in place to ensure system reliability. In my experience, well-defined NFRs are a sign of team and system maturity, which ensure secure and stress-free updates.