Intégrer la sécurité dans le cycle de développement logiciel, sans pour autant ralentir le projet (2022)
Un entretien avec Garett Spencley-Sales, architecte logiciel, développeur principal et spécialiste de la sécurité.
Laurent Gloaguen : La sécurité est souvent mise en œuvre après coup, en fin de cycle de développement du logiciel. Que pensez-vous de cette situation ?
Garett Spencley-Sales : La sécurité mérite une attention prioritaire. Elle doit être traitée en amont, alors que notre secteur a tendance à considérer la sécurité comme un problème technique à traiter. On part également du principe que “s’il y a un problème de sécurité, c’est un bogue, parce que les développeurs n’ont pas codé correctement”. C’est une façon désastreuse d’envisager la sécurité. Vous vous exposez à toutes sortes de problèmes. Pour aborder la sécurité de manière adéquate, vous devez en amont effectuer une analyse des risques et identifier vos actifs les plus précieux. Qu’il s’agisse de données et d’informations sur les clients, de systèmes de l’entreprise — tout ce que vous protégez, ou tout ce qui pourrait constituer une responsabilité en cas de piratage — vous devez identifier ces éléments avant même de commencer le développement.
La modélisation des risques doit également être terminée avant de commencer, de sorte que si le développement dérape, vous pourrez dire : “Bon, voici comment nous avons anticipé ces lignes de faille ; ces actifs à haut risque pourraient être attaqués et potentiellement compromis, mais voici les fonctionnalités que nous avons incluses afin de les protéger sur le plan technique”.
Et puis, bien sûr, les organisations doivent être conscientes que le risque technologique n’est qu’un des risques qu’elles encourent. Au fil des décennies, nous avons assisté à de nombreuses attaques qui s’appuyaient sur des vulnérabilités sociales plutôt que techniques. Aujourd’hui encore, les campagnes par hameçonnage, qui sont des attaques sociales et non des attaques techniques, sont l’un des moyens les plus courants de compromettre un système.
Il est clair que le souci de la sécurité commence bien avant l’écriture de la moindre ligne de code. Les considérations vont du choix des outils et des frameworks à la définition des exigences, non ?
Garett : Bien sûr. Vous devez considérer la sécurité comme une fonctionnalité essentielle. Vous ne pouvez pas simplement supposer que le système sera intrinsèquement sûr. Ce que signifie être sûr varie d’un projet à l’autre. Cela dépend des risques et de ce qui doit être protégé. Que signifie la sécurité pour votre système et pour vos données ? Il n’y a pas de recette toute faite, car chaque projet a des exigences différentes. Lorsque vous comprenez quelles sont vos priorités, vous pouvez traiter la sécurité comme une fonctionnalité et vous assurer qu’elle est prise en compte dès le départ. Ensuite, les outils, les processus et les systèmes que vous utiliserez seront les bons pour résoudre ces problèmes particuliers.
Intégrer la sécurité dans le cycle de développement logiciel sans ralentir le projet est une tâche qui a son propre coût. N’avez-vous pas besoin de renforts pour respecter les délais ? Cela ne représente-t-il pas un investissement plus important ?
Garett : Une bonne sécurité a inévitablement un coût. Développer correctement des fonctionnalités et des logiciels coûte de l’argent. Mais si nous traitons la sécurité comme une réflexion après coup et les problèmes comme des bogues, les coûts seront encore plus élevés.
En matière de sécurité, les bogues sont particulièrement dangereux, car ils représentent une énorme responsabilité pour les entreprises, qui peuvent être confrontées à des amendes réglementaires, à des poursuites pour atteinte à la vie privée si le statut des utilisateurs est compromis, ou à une perte de marché en raison d’une baisse du niveau de confiance dans leur service. La sécurité a de nombreuses implications financières pour une entreprise.
Pour éviter que les projets ne se grippent, la meilleure solution consiste à traiter la sécurité comme une fonctionnalité dès le départ. De cette façon, vous vous assurez que ces types de bogues sont détectés à un stade précoce, lorsqu’ils peuvent être traités à moindre coût, de façon rapide et efficace, au lieu de développer un système non sécurisé parce que personne n’a estimé que la sécurité était un prérequis. Vous ne voulez pas avoir à dire après coup : “Oh non, nous devons faire quelque chose pour résoudre notre problème de sécurité, mais nous ne pouvons pas le faire parce que le système n’a pas été conçu pour pouvoir réaliser ce dont nous avons besoin”.
La réponse est donc malheureusement oui, vous devez investir un peu plus au départ. Mais la raison économique pour laquelle vous devez faire cet investissement est que cela vous épargnera potentiellement un considérable somme de responsabilité. Et si vous voulez faire une analyse coûts-avantages, faites cette évaluation des risques dès le départ. Identifiez ce qui a le plus de valeur et ce que pourraient être vos responsabilités, car si vous ne le faites pas, vous prenez un risque énorme sans même savoir que vous êtes en danger. C’est ce que nous constatons actuellement avec toutes ces attaques de rançongiciels, ces intrusions, etc.
Si vous ne vous occupez pas continuellement de l’aspect sécurité, vous accumulez une sorte de dette technique, n’est-ce pas ? Peut-on parler de “dette de sécurité” et des problèmes qu’une telle dette engendre ?
Garett : On peut considérer cela comme un type de dette technique. Mais le hasard entre malheureusement en jeu. Par pure chance, certaines entreprises ne se retrouvent jamais visées. Elles ne souffrent pas de ces responsabilités et ne paient pas le coût de la dette technique. Mais si vous êtes victime d’une intrusion, s’il existe une vulnérabilité au niveau technique et que vous ne la corrigez qu’après coup, d’autres failles de sécurité dans votre système seront également mises en évidence. Il ne serait pas inapproprié de considérer cela comme une forme de dette qui finit par arriver à échéance.
Afin de minimiser cette dette, diriez-vous qu’il est préférable d’avoir plusieurs ralentissements mineurs pendant le développement qu’un seul ralentissement majeur à la toute fin ?
Garett : Eh bien, le sujet des ralentissements est intéressant, car je pense qu’il y a une attente implicite que le système soit sécurisé. Nous nous attendons à la sécurité parce que nous reconnaissons que nous avons affaire à un risque. Qu’il s’agisse d’une entreprise de produits ou d’un client qui passe un contrat avec une agence, nul n’a l’intention d’acheter un logiciel non sécurisé. Je dirais que la planification de la sécurité n’est pas un ralentissement.
La sécurité est une fonctionnalité, qu’elle soit traitée comme telle ou non. La chose intelligente à faire est de la traiter comme telle, et de l’intégrer dans le coût de développement des fonctionnalités du logiciel. Personne n’a besoin d’un système non sécurisé qui coûtera à l’entreprise en termes de responsabilité, ou aux clients, ce qui se répercute également sur l’entreprise.
Tout cela est bien beau, mais dans la pratique, comment cela fonctionne-t-il ? Vous êtes un développeur senior avec beaucoup d’expérience, vous avez connu de nombreux projets et équipes. Les choses se passent-elles toujours de cette façon ? La sécurité est-elle réellement intégrée dans le processus de développement ?
Garett : Pour être honnête, d’après mes observations et mon expérience, la sécurité est trop souvent ignorée. Elle n’entre tout simplement pas dans les discussions. Les entreprises se pressent pour mettre sur le marché des fonctionnalités brillantes qui devraient leur rapporter beaucoup d’argent, alors que la sécurité n’est jamais mentionnée. Ou si elle l’est, elle a tendance à être soulevée par des développeurs qui comprennent que “Hé, vous avez des risques ici. Cette base de données contient une quantité incroyable de données et d’informations sur les clients, mais il y a en fait très peu de contrôles d’accès et de mesures en place pour les protéger. “La réponse typique est “C’est un très bon point” et “Nous vous assurons que nous le prenons au sérieux”, mais ce n’est pas une priorité du moment. C’est quelque chose qu’ils veulent faire un jour, mais ce jour n’arrive jamais.
Ce n’est pas une surprise pour moi, car nous, les développeurs et ingénieurs, soulevons ces préoccupations depuis que je suis dans le secteur, et maintenant j’en suis à “je vous l’avais dit”. Nous avions prédit qu’il y aurait davantage d’attaques à grande échelle, de fuites de données et de brèches, comme les attaques par rançongiciels qui font l’actualité.
Pardonnez mon franc-parler, mais je ne pense pas que les choses s’amélioreront vraiment tant que les chefs d’entreprise ne seront pas imputables, voire envoyés en prison. Il n’y a tout simplement pas de conséquences. C’est une question d’évaluation des risques. Les managers, les chefs d’entreprise et les cadres qui ne sont pas particulièrement férus de technologie pensent qu’il faut une sorte de génie comme on n’en voit que dans les films pour compromettre un système. Ils pensent : “Cela ne peut pas nous arriver”. Mais toute personne qui ne prend pas cela au sérieux met le système en danger. Tout système peut être violé si quelqu’un est déterminé à y pénétrer. Si vous omettez l’évaluation des risques, vous ne savez pas ce qui est vulnérable et ce que vous devez protéger, et tout est exposé.
Nous constatons donc que l’avantage d’une mise sur le marché rapide pour offrir aux utilisateurs de nouvelles fonctionnalités l’emporte sur le risque de sanctions liées à des intrusions dans les bases de données, par exemple…
Garett : C’est loin des yeux, loin du cœur. Je pense qu’elle n’est même pas prise en compte dès le début, alors que c’est justement là qu’elle devrait être mise en avant. La sécurité devrait être incluse comme une fonctionnalité. Les clients partent du principe qu’ils achètent un système sécurisé, mais la sécurité n’est jamais mentionnée pendant la phase de découverte ou de planification. On ne nous donne jamais de documents qui décrivent l’évaluation des risques et la modélisation des menaces, et on ne nous demande jamais de faire cette modélisation. Je n’ai jamais vu de rapport disant : “Voici la modélisation des menaces, l’évaluation des risques, nos priorités, donc voici ce que nous devons mettre en place.” Les agences de conseil en sécurité sont engagées pour faire cela dans certains cas, et je l’ai fait une fois lorsque j’étais sur un projet pour une grande banque américaine qui avait ses propres systèmes en place.
De plus, j’ai récemment écouté la conférence de quelqu’un qui est engagé par des banques pour faire des évaluations de la sécurité physique. Elles l’engagent pour qu’il essaie délibérément de voler la banque, afin de voir ce que la banque ferait en cas d’attaque. Il a constaté que même la sécurité physique des banques est beaucoup plus faible que ce à quoi on pourrait s’attendre. Il affirme que si elles ne peuvent pas assurer correctement la sécurité physique, elles ne peuvent pas non plus assurer la sécurité numérique. Si la prise en compte de la sécurité n’est pas jugée importante, c’est la seule imputabilité qui devient une incitation.
On suppose que les développeurs écriront un code sécurisé, mais les politiques de contrôle de l’accès aux serveurs de bases de données n’ont pas grand-chose à voir avec le code. Il s’agit là d’un vecteur d’attaque potentiel ; il y a ensuite les vecteurs d’attaque sociaux, les vecteurs d’attaque de l’infrastructure… il existe de nombreuses façons de compromettre les systèmes. Cela varie selon les projets et les systèmes. Vous ne pouvez pas procéder à la planification en vous basant uniquement sur des hypothèses, car vous n’y arriverez pas, vous ne saurez pas quels sont les risques.
Avez-vous des recommandations spécifiques ?
Garett : Cela dépend du projet et du système. Je vais avoir l’air d’un disque rayé, mais la première recommandation est de procéder à la modélisation des menaces et à l’évaluation des risques, car sans cela, vous ne savez pas quelles sont vos exigences en matière de maintenance.
Certaines organisations ont procédé à une évaluation des risques dès le départ pour finalement décider que les systèmes existants ne représentaient pas un grand risque. Le pire des scénarios n’est pas si terrible si quelqu’un les attaque. Ces anciens systèmes peuvent être laissés en l’état, car ils ne risquent pas d’être sérieusement affectés, alors qu’il y a peut-être d’autres systèmes au sein de l’entreprise et du réseau qui sont beaucoup plus prioritaires et qui méritent toute l’attention.
L’évaluation des risques est également une mesure d’économie, car les entreprises peuvent l’utiliser pour définir leurs responsabilités et hiérarchiser ensuite leurs efforts de maintenance en conséquence.
Pour revenir à la question, qui était de savoir comment intégrer la sécurité dans le cycle de développement des logiciels sans ralentir le projet, est-ce un cercle vicieux ? Si cela demande plus de temps, de personnel et de maintenance, est-ce que nous tournons en rond ? Ou la solution est-elle de le faire en amont afin de pouvoir planifier le nombre adéquat de personnes et un calendrier réaliste, pour que tout se passe bien ?
Garett : Si l’on s’attend à ce que ce logiciel soit sécurisé, la question devient “Comment écrire un logiciel pleinement fonctionnel sans ralentir le cycle de développement ?” Et c’est le problème fondamental auquel tout chef de projet est confronté, qu’il s’agisse de sécurité ou d’autre chose. Comment planifier le développement d’un logiciel qui fonctionne correctement, et comment le développer selon un calendrier serré sans introduire de retards ? Vous y parvenez en planifiant la sécurité dès le départ. Si vous la traitez comme n’importe quelle autre fonctionnalité, si vous identifiez les exigences de sécurité importantes, vous pouvez alors planifier leur développement au lieu de revenir en arrière pour réparer un système non sécurisé.
Il est beaucoup plus efficace et rentable de faire ce petit travail en amont et de l’intégrer dans le cadre de la planification et du processus. Si vous le remettez à plus tard, vous ne faites que prendre vos désirs pour des réalités, en espérant que la sécurisation de votre système ne sera pas trop difficile, alors que vous n’avez même pas encore identifié ce que la sécurité signifie pour votre projet et votre système.
Merci beaucoup pour votre temps, Garett. Vos commentaires étaient sans détours et instructifs. Avez-vous quelque chose à ajouter ?
Garett : Je résumerai les principales recommandations et les points à retenir. Faites une évaluation des risques en amont pour identifier vos actifs de grande valeur et vos responsabilités potentielles, considérez la sécurité comme une fonctionnalité et ajoutez-la dans la planification du projet. Cela ne sera pas nécessairement très coûteux. En fait, il est probablement beaucoup moins cher de faire cela en premier. Développez en pensant à la sécurité dès le départ, plutôt que d’essayer de sécuriser un système non sécurisé après coup.
Les organisations devraient commencer à considérer les problèmes de sécurité comme une question de responsabilité potentielle. De deux choses l’une : soit les primes d’assurance élevées feront partie des coûts d’exploitation normaux, soit les entreprises prendront enfin des mesures pour assurer la sécurité en la traitant comme une priorité dès le départ.
Integrate security in the software development cycle, but slow down the project?
An interview with Garett Spencley-Sales, software architect, lead developer and security specialist.
Laurent Gloaguen: Security is often implemented as an afterthought at the end of the software development cycle. What are your thoughts on this?
Garett Spencley-Sales: Security deserves primary consideration. It needs to be dealt with upfront, whereas there’s a tendency in our industry to think of security as a technical problem to be overcome. There’s also an assumption that, “Well, if there’s a security problem, it’s a bug because the developers didn’t code correctly.” That’s a disastrous way to think about security. You’re leaving yourself wide open to all kinds of issues. In order to address security properly, you need to do the risk analysis upfront and you need to identify your most valuable assets. Whether it’s customer data and information, company systems—whatever you’re protecting, or whatever would be a liability if it were compromised—you need to identify those things before development even starts.
Threat modeling should also be complete before you get underway, so that if development goes sideways, you can say, “Okay, here’s how we anticipated these fault lines; these high-risk assets could be attacked and potentially compromised, but here are the features we included in order to protect them on the technical front.”
And then, of course, organizations need to be aware that technical risk is but one of the risks they run. Over the decades, we’ve seen so many attacks that preyed on social vulnerabilities rather than on technical ones. Even today, phishing campaigns, which are social attacks, not technical attacks, are one of the most common ways to compromise a system.
Clearly, the concern for security starts well before any line of code is written. The considerations run from the choice of tools and frameworks to the definition of the requirements, right?
Garett: Sure. You need to think of security as an important feature. You can’t just assume that the system will be inherently secure. What it means to be secure varies from project to project. It depends on what the risks are and what needs to be protected. What does security entail for your system and for your data? It’s not cookie cutter, as every project will have different requirements. When you understand what your priorities are, you can treat security as a feature and you can make sure that it’s addressed from the start. Then the tools, the processes and the systems you use will be the right ones to solve those particular problems.
Integrating security into the software development cycle without slowing down the project is a time-consuming task that comes with its own cost. Don’t you need extra hands to maintain the timeframe? Does that make it a bigger investment?
Garett: Getting security right inevitably comes at a cost. Properly developing features and software costs money. But if we treat security as an afterthought and problems as bugs, this will add even more to the cost.
When dealing with security, bugs are especially harmful because they represent a huge liability for businesses, who could face regulatory fines, lawsuits for breach of privacy if user status is compromised, or a market loss because of a decreased level of trust in their service. Security has many financial implications for a company.
So that projects don’t grind to a halt, the smart way to go is to handle security as a feature from the get-go. This way, you ensure that those types of bugs are caught early, when they can be addressed cheaply, quickly and efficiently, instead of developing an unsecured system because no-one felt security was a prerequisite. You don’t want to be saying after the fact, “Oh no, we have to do something about our security problem, but we can’t because the system wasn’t designed to do what we now need it to do.”
So the unfortunate answer is yes, you do need to invest a little bit more upfront. But the business reason to make that investment is that this will potentially save you a massive amount of liability. And if you want to do the cost-benefit analysis, then do that risk assessment upfront. Identify what’s most valuable and what your liabilities could be, because if you don’t, you’re taking a huge risk without even being aware that you’re at risk. And that’s what we’re seeing now with all these ransomware attacks, breaches and so on.
If you don’t tend to the security aspect continually, you accumulate a kind of technical debt, right? Could you talk about “security debt” and what problems such a debt creates?
Garett: You could frame it as a type of technical debt. But now, luck unfortunately enters the picture. Out of sheer dumb luck, some companies never find themselves targeted. They don’t suffer those liabilities and they don’t pay the cost of technical debt. But if you do get breached, if there is a vulnerability at the technical level and you only address it after the fact, other security vulnerabilities in your system will also come to light. It wouldn’t be inappropriate to consider that as a form of debt that eventually comes due.
In order to minimize this debt, would you say that it is better to have several minor slowdowns during development than one major one at the very end?
Garett: Well, the topic of slowdowns is an interesting one, because I think there’s an implicit expectation that the system will be secure. We expect security because we recognize that we are dealing with risk. Whether it’s a product company or a client contracting an agency, nobody commissioning a project intends to buy unsecured software. I would argue that planning for security is not a slowdown.
Security is a feature, whether it’s treated as such or not. The smart thing to do is to treat it as such, and bake that in the cost of developing the software’s features. You have to build the security and that just comes with a cost, which is that of developing the features.No one needs an unsecured system that will cost the company in terms of liability, or cost our customers, which blows back on the company as well.
That’s all well and good, but in practice, how does it work? You’re a senior developer with a lot of experience, you’ve seen many projects and teams. Do things always work out that way? Is security truly integrated into the development process?
Garett: To be honest, in my observation and experience, security is all-too-often not considered at all. It simply doesn’t enter the conversation. Companies race to go to market with shiny features that they expect will make them a lot of money, while security is never mentioned. Or if it is, it tends to be brought up by developers who understand that, “Hey, you have risks here. This database has an insane amount of customer data and information, but there are actually very few access controls and measures in place to safeguard it.” The typical answer is “That’s a very good point” and “We swear we take it seriously,” but it’s not a priority right then. It’s something they want to get to someday, but that day never comes.
It’s no surprise to me, because we software developers and engineers have been raising these concerns for the twenty years that I’ve been in the industry, and now I’m like, “I told you so.” We predicted that there would be more large-scale attacks, data leaks and breaches, such as the ransomware attacks that are making the news.
Forgive my bluntness, but I don’t think things will really improve until business leaders face jail time. There are simply no consequences. It’s a matter of risk assessment. Managers, business leaders, and executives who are not particularly tech-savvy believe that it takes some sort of genius like you only see in the movies to compromise a system. They think, “This can’t happen to us.” But anyone who doesn’t treat this seriously is putting the system at risk. Any system can be breached if someone is determined to get in. If you skip the risk assessment, you don’t know what’s vulnerable and what you need to safeguard, and everything is left exposed.
So we’re seeing that the benefit of going to market quickly to give users new features outweighs the risk of fines related to database breaches, for example…
Garett: It’s out of sight, out of mind. I think it’s not even considered early on, when in fact that’s when it should be highlighted. Security should be included as a feature. Clients assume that they’re buying a secure system, but security is never mentioned during the discovery phase or during planning. We’re never given documents that outline the risk assessment and threat modeling, nor are we ever asked to do that modeling. I’ve never seen a report that said, “Here’s the threat modeling, the risk assessment, our priorities, so here’s what we have to put in place.” Security consulting agencies are hired to do that in some cases, and I did it once when I was on a project for a major US bank that had its own systems in place.
What’s more, I recently listened to someone’s lecture who is contracted by banks to do physical security assessments. They hire him to deliberately try and rob the bank, to see what the bank would do in case of an attack. He found that even banks’ physical security is much weaker than one would expect. He argues that if they can’t do physical security right, then there’s no way they can do digital security either. If planning for security features isn’t deemed important, the liability becomes the incentive.
It’s assumed that developers will write secure code, but policies to control access to database servers have little to do with code. That’s one potential attack vector; then there are social attack vectors, infrastructure attack vectors … there are many ways to compromise systems. It varies between projects and between systems. You can’t proceed through planning with assumptions only, because you won’t get it right, you won’t recognize what the risks are.
Do you have specific recommendations?
Garett: That depends on the project and on the system. I’m going to sound like a broken record, but the primary recommendation is to do the threat modeling and risk assessment because without that, you don’t know what your maintenance requirements are.
Some organizations have done their risk assessment upfront only to decide that the legacy systems didn’t represent much of a risk. The worst-case scenario isn’t so bad if someone were to attack them. Those legacy systems can be left as-is because no serious damage could be inflicted, while there might be other systems within the company and network that are much higher priority and that deserve full attention.
Risk assessment is also a cost-saving measure, because companies can use it to define their liabilities and then prioritize their maintenance efforts accordingly.
To go back to the question, which was how to integrate security into the software development cycle without slowing down the project, is that a catch-22? If it requires more time, people, and maintenance, do we run around in circles? Or is the solution to do it upfront so that you can plan for the right amount of people and a realistic timeframe, so things go smoothly?
Garett: If this software is expected to be secure, the question becomes “How do I write fully-functioning software without slowing down the dev cycle?” And that is the fundamental problem that every project manager faces, whether they’re talking about security or anything else. How do you plan the development of software that functions correctly, and how do you develop it on a tight schedule without introducing delays? You do that by planning for security upfront. If you treat it as any other feature, if you identify the important security requirements, then you can plan their development instead of circling back to fix an unsecured system.
It’s much more efficient and cost effective to do that little bit of work upfront and to bake it in as part of the planning and process. If you leave it for later, you’re basically thinking wishfully, hoping that it’s not going to be too much work to somehow magically make your system secure when you haven’t even identified what security means for your project and your system.
Thank you so much for your time, Garett. Your advice was straightforward and enlightening. Do you have anything else to add?
Garett: I’d summarize some key recommendations and takeaways. Do the risk assessment upfront to identify what your highly valuable assets and your potential liabilities are, treat security as a feature and add that in the project planning. It won’t necessarily be hugely expensive. As a matter of fact, it’s probably much cheaper to do that first-thing. Develop with security in mind from the start, rather than trying to secure an unsecured system after the fact.
Organizations should start thinking about security concerns as a potential liability issue. One of two things will happen: either high insurance premiums will become part of normal operating costs, or companies will finally take measures to get security right by treating it as a priority from the get-go.