Comment sécuriser les logiciels basés sur le cloud pendant la maintenance et l’évolution ?

To ensure we only add security improvements or controls that make sense for our organization and business needs, it is crucial to conduct some risk assessments. Depending on the maturity of the company and its procedures and security policies, this can take time and effort. You can rely on external input from pen-testing assessments or bug bounty security or use automatic scans for vulnerabilities or misconfiguration. Still, in the end, the organization must align its criteria to decide when some finding is or is not essential, and this is part of having a good Risk Management Process defined. With Risk rating criteria and good work identifying critical processes/assets for the business and scenarios we want to avoid.

Have a readable, actionable threat model document. A threat model says, "what is valuable," and "how do we protect it"? It is my constant experience that development teams do not explicitly write this down and so forget or disagree on what the consequential threats are. If they produce any threat modeling documentation, it is to satisfy an external requirement and as such is too convoluted and unreadable for the junior team members to bring their fresh insights into. You want every team member to be able to put on the hat of the threat actor and imagine how they would break into your system or make it do the wrong thing. From the accept, mitigate or transfer risk decisions you design out the concrete protections.

Using secure coding practices and conducting vulnerability scans on a regular basis. Also implementing DevSecOps practices and integrating security throughout the software lifecycle will enhance the overall security.

It is sometimes difficult to understand if your organization follows good security practices, general security principles, industry frameworks, etc. It is essential to assess this kind of thing with automation as much as possible, for example, by using tools like AWS config that implement monitoring checks to see if you are respecting some good practices and detect any change on that. Remembering those principles, frameworks, etc.. during risk assessment or management is also essential. While doing any risk management exercise, you can keep some checklist with principles or criteria your organization is willing to follow to facilitate thinking about them and considering them or as a way to ensure decisions are made with those in mind.

Encryption is mandatory and an easy-win nowadays in cloud environments; follow standards and ensure you encrypt everything. Regarding authentication, organizations grow so quickly sometimes that they need to gain control of authentication and authorization. Always centralize authentication and authorization through identity management software (such as Okta) or SSO to prevent this. You should avoid shared credentials. Any user authenticating to a service should be identifiable as a unique individual. If you centralize authorization, you can enforce MFA in just one place (Okta, Gmail, AD) instead of trying to do it for each service. Consider enabling physical MFA devices (yubikeys) for It admins or people with high privileges in your cloud.

Encrypt your data both in transit and at rest. Use strong encryption algorithms such as AES-256 and rotate your encryption keys regularly. You can also use field-level encryption to protect sensitive data such as credit card numbers or social security numbers

Define an Access Control Policy, and align the org on it. Permissions should be granted through roles, some automatically based on the individual's team/squad/role or attributes and some manually granted (and temporarily) when needed. If your organization can afford it, consider Identity Governance solutions to create workflows to grant access with request approval or by consensus and also to be able to grant temporary permissions to people (to avoid individuals accumulating permissions for specific tasks that never get removed). Implement a SIEM and start collecting logs from all critical services. Do risk assessment on privilege escalation and ensure you have controls to prevent unauthorized privilege escalation within the organization.

The longer you take to add a security patch, the more complicated it will get to do the upgrade in the future. Be sure to get different teams in the organization aligned with the necessity of applying updates in general, and also for dependencies. Set up CICD automation to detect when a project has available updates and consider making it block releases when the updates haven't been applied withing an agreed timeline. This way, people responsible for certain projects/services will need to apply patches in order to progress on their work (release more code) and since there is a policy and automation defining this, nobody could blame security/DevOps for blocking a release.

I want to add the importance of a centralized asset management system to track system components (servers, databases, firewalls, etc.) and their configurations. Documentation should also be managed within a centralized repository and kept-up-to-date (that's really important). The real challenge comes with managing microservice application REST API's as many development teams tend to treat API's as individual apps and not holistically as a complete application. This makes maintenance, updating and security testing quite difficult and incomplete.