Parce que la complaisance en matière de conformité est une autre forme de dette technique - CloudSavvy IT

  • Principal
  • Nouvelles
  • Parce que la complaisance en matière de conformité est une autre forme de dette technique - CloudSavvy IT

La montée

La dette technique se présente sous trois formes. Des équipements obsolètes qui ne peuvent pas répondre aux besoins actuels, des projets logiciels où les virages ont été tournés et des structures de gouvernance mal implantées ou complètement ignorées. Le fil conducteur ? Risque.

dette technique

La dette technique est l'écart entre les performances supposées de quelque chose et ce qu'il offre réellement. En raison de la disparité, de mauvaises performances sont inévitables. La dette technique vieillit mal. À mesure que les inégalités augmentent, leur exposition au risque augmente également.

La dette technique peut lentement s'accumuler. Le matériel et les systèmes d'exploitation obsolètes finissent par prendre du retard sur les cycles de support des fabricants. La dette technique est le risque de sécurité accru auquel votre organisation s'expose en exécutant des systèmes qui ne reçoivent pas de correctifs de sécurité.

Parfois, vous pouvez hériter d'une dette technique par le biais d'une fusion ou d'une acquisition. Il peut également produire de la dette technique, notamment dans les projets de développement de logiciels. Les décisions de conception et de mise en œuvre, souvent imposées à l'équipe de développement en raison de contraintes budgétaires ou de délais irréalistes, peuvent introduire une dette technique qui est intégrée à l'application et existe, entièrement formée, à la sortie.

Les cadres de gouvernance informatique, tels que les politiques et procédures de cybersécurité et de protection des données, peuvent accumuler une dette technique, peuvent être créés avec une dette technique déjà intégrée ou peuvent souffrir des deux.

dans tous les cas, la dette technique est directement assimilée au risque. C'est un indicateur certain qu'il faut prêter attention au problème.

Matériel informatique et dette technique

Tout le matériel informatique doit être entretenu. Les correctifs de sécurité doivent être appliqués aux logiciels et micrologiciels, et les systèmes d'exploitation doivent être mis à jour lorsqu'ils sont obsolètes et non pris en charge. Les disques durs doivent être remplacés à la fin de leur durée de vie prévue ou dès les premiers signes avant-coureurs d'erreurs en développement. Si le disque dur en question ne fait pas partie d'une matrice RAID, n'attendez pas les signes avant-coureurs. Intervenez lorsque le disque a satisfait au cycle de service attendu.

Finalement, tous les ordinateurs et systèmes d'exploitation deviennent obsolètes. L'utilisation d'équipements obsolètes et non pris en charge constitue un risque pour la sécurité. Malgré cela, il peut être difficile de vendre au côté commercial de l'entreprise pour remplacer quelque chose qui, pour eux, fonctionne toujours bien. Et même lorsque quelque chose est destiné à être modernisé et remplacé, la dette technique demeure jusqu'à ce que le remplacement ait effectivement eu lieu.

Parfois, l'exécution de systèmes d'exploitation obsolètes ou de matériel obsolète échappe à votre contrôle immédiat. Les PC de laboratoire et de contrôle industriel sont particulièrement sujets aux blocages du système d'exploitation. Cela peut se produire si un logiciel tiers crucial n'a pas été mis à jour depuis sa sortie. Cela peut vous obliger à exécuter le système d'exploitation actuel au moment de la sortie du produit. il peut s'agir d'un problème matériel. Si le logiciel ne fonctionne qu'avec une ancienne carte d'interface particulière qui n'est compatible qu'avec un ancien matériel informatique particulier, vous êtes bloqué avec les systèmes d'exploitation que ces POC peuvent prendre en charge.

Remplacer complètement le matériel et les logiciels obsolètes n'est pas aussi simple qu'il y paraît. Il pourrait contrôler la production ou d'autres machines ou processus critiques. Vous ne pouvez pas vous contenter de jeter de vieux éléments si ce qui est disponible aujourd'hui ne s'intègre pas à vos systèmes de production.

Plus les systèmes sont anciens, plus il est probable que les personnes qui les ont mis en œuvre aient quitté l'entreprise. Vos équipes d'assistance peuvent ne pas comprendre parfaitement les systèmes obsolètes. Souvent, lorsqu'il s'avère que ces anciens systèmes sont plus profondément interconnectés et intégrés qu'on ne le pensait auparavant.

Projets de développement et dette technique

Les projets de développement non triviaux sont soumis à de nombreuses exigences. Qu'il s'agisse d'une demande de consommation interne ou d'un produit à commercialiser, les points de tension sont similaires. La plupart tournent autour des délais, des spécifications et des budgets.

La spécification est une liste de fonctionnalités et de contenu que le logiciel doit fournir. La spécification devrait être plus qu'une longue liste de souhaits. Le temps disponible pour le développement, les tests et la documentation détermine quel contenu peut être réalisé de manière réaliste avec les ressources de développement disponibles et les technologies avec lesquelles ils sont familiers.

Un cahier des charges trop optimiste ou une phase de développement trop courte, c'est la même chose. Le travail ne rentre pas dans le temps disponible. L'impact que cela a sur l'équipe de développement est profond. S'ils sont maîtrisés, les techniques, méthodologies et technologies connues seront préférées au temps passé à évaluer de nouvelles plateformes, frameworks ou autres.

Lorsque vous êtes sur la marche de la mort vers une échéance, vous n'avez pas le temps de commencer à expérimenter de nouvelles technologies et à introduire potentiellement des risques. Ce risque peut être des problèmes fonctionnels au sein du logiciel qui affectent les utilisateurs, ou il peut s'agir de problèmes insidieux qui conduisent à des vulnérabilités de sécurité.

Parfois, le développement est soumis à la pression du côté commercial de l'entreprise. Ils peuvent déterminer que la nouvelle technologie est utilisée pour s'assurer que leur produit se démarque de la concurrence. Cela signifie que vous êtes obligé d'essayer d'apprendre la nouvelle technologie tout en respectant le délai.

Ces types de blessures auto-infligées affectent l'architecture du produit et la qualité du code. Vous ne tirerez pas le meilleur parti d'un nouveau framework, d'un nouveau langage ou d'un nouveau paradigme de développement tant que vos développeurs ne se seront pas familiarisés avec lui pour comprendre ses idiomes et ses meilleures pratiques. Au minimum, il est susceptible de produire du code peu performant et difficile à maintenir. Dans le pire des cas, cela peut présenter des risques de sécurité.

Les bibliothèques et les boîtes à outils tierces accélèrent le développement, mais peuvent héberger des vulnérabilités de sécurité et leur propre dette technique. L'utilisation de code tiers facilite le développement, mais peut compliquer les choses pour votre équipe de sécurité.

Les aspects commerciaux et commerciaux de l'organisation doivent être impliqués dans les premières discussions avec le développement afin qu'une description et des spécifications de produit réalistes mais mutuellement satisfaisantes puissent être développées, en tenant compte des délais et des technologies actuels et de pointe. Votre équipe de sécurité devrait également être impliquée. Et puisque votre équipe de développement ne reste jamais assise à ne rien faire, des mesures doivent être prises pour la recherche. Sinon ça n'arrivera pas.

La planification formelle du temps et des ressources pour l'enquête, y compris la formation, est le seul moyen de s'assurer que l'enquête essentielle est menée. Vous devrez peut-être embaucher du personnel pour y parvenir. sans recherche, vous ne pourrez jamais basculer vers les nouvelles technologies de manière maîtrisée. Et sans contrôle, vous vous retrouvez avec le risque.

Gouvernance et dette technique

La dette technique peut se glisser dans la création de structures de gouvernance de la même manière que le développement de logiciels. Au lieu de développer des logiciels, vous créez des politiques et des procédures, telles que la gouvernance informatique ou des systèmes de protection des données. Je ne confierais pas un projet de développement à une équipe qui n'a jamais écrit de code auparavant. Il en va de même pour la documentation de gouvernance.

Vous ne pouvez pas vous attendre à de grands résultats si vous confiez la tâche à quelqu'un qui n'a pas les bonnes compétences. Rédiger des documents de bonne gouvernance est difficile. Sans cet ensemble de compétences, il est tentant de copier des parties des politiques et procédures d'autres organisations et d'essayer d'en faire un tout cohérent, mais cela ne fonctionne pas. Le résultat est une mosaïque de fragments de documents conçus pour d'autres organisations.

Les auteurs de votre gouvernement doivent connaître et comprendre la législation ou la norme que vous essayez de respecter ou de traiter et avoir de l'expérience dans la production de documents gouvernementaux et politiques. Si ce n'est pas vous, interagissez avec quelqu'un qui possède ces compétences.

Une autre erreur courante consiste à rendre les documents de gouvernance impressionnants plutôt que concrets. Ils doivent refléter avec précision ce que vous faites et devez contrôler, et comment vous le ferez pour vous conformer à la législation ou à la norme avec laquelle vous travaillez. Il est impossible de réussir un audit si les documents audités ne reflètent pas vos processus, flux de travail et mesures de sécurité réels.

Disposer de documents de gouvernance précis et exécutoires n'apporte pas grand-chose s'ils ne sont pas utilisés. La complaisance, c'est quand vous avez les politiques et les procédures, mais que personne ne les utilise. Ils doivent être adoptés et utilisés par votre personnel ; dans le cas contraire, vos démarches ne seront pas effectuées conformément à vos politiques. C'est déjà assez grave, mais cela signifie également que vos processus ne généreront pas de piste d'audit. Pire encore, le non-respect des procédures peut entraîner des failles de sécurité et des violations de données.

Le maintien d'un système de gouvernance nécessite également du temps et des ressources. Il est nécessaire de réaliser des audits internes, par exemple, et de surveiller le paysage législatif. La législation change avec le temps, est abrogée et remplacée. L'entreprise peut choisir ou être contrainte de se conformer à une norme qu'elle n'a pas été contrainte de respecter auparavant. Par exemple, vous pouvez commencer à recevoir des paiements en ligne et vous devez vous conformer à la norme de sécurité des données de l'industrie des cartes de paiement (PCI-DSS). Votre documentation de gouvernance devra être modifiée pour refléter les nouveaux besoins et s'assurer que toutes les clauses des normes sont respectées.

faire face à vos dettes

La dette technique ne dort jamais et s'aggrave au fur et à mesure que vous la laissez. Ce qui est nécessaire pour résoudre le problème varie de facile à très difficile. La définition d'une politique de correctifs et d'un calendrier est facile. L'élimination des blocages dans les systèmes hérités pourrait nécessiter des pannes et des dépenses insoutenables.

Si vous avez une dette technique que vous ne pouvez pas traiter, ou ne pouvez pas traiter jusqu'à ce qu'un autre événement important se produise, assurez-vous d'avoir capturé et caractérisé le risque dans vos documents d'évaluation des risques opérationnels et d'évaluation des risques cybernétiques. Enregistrez les mesures qui ont été prises pour atténuer le risque et les mesures d'urgence que vous pouvez prendre en cas de risque.

Qu'est-ce que tu penses?