Pourquoi la complaisance en matière de conformité est une autre forme de dette technique - CloudSavvy IT
Agence web » Actualités du digital » Pourquoi la complaisance en matière de conformité est une autre forme de dette technique –

Pourquoi la complaisance en matière de conformité est une autre forme de dette technique –

Den Rise/Shutterstock.com

La dette technique se présente sous trois formes. Des équipements hérités qui ne peuvent pas répondre aux besoins d’aujourd’hui, des projets logiciels où les coins ont été coupés et des cadres de gouvernance mal mis en œuvre ou complètement ignorés. Le fil conducteur ? Risque.

Dette technique

La dette technique est le déficit entre la performance supposée de quelque chose et ce qu’elle offre réellement. En raison de la disparité, il y a une sous-performance inévitable. La dette technique vieillit mal. Au fur et à mesure que la disparité augmente, votre exposition au risque augmente.

La dette technique peut lentement s’accumuler. Le matériel et les systèmes d’exploitation vieillissants finissent par sortir des cycles de support de leurs fabricants. La dette technique est le risque de sécurité croissant auquel vous exposez votre organisation 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. Vous pouvez également fabriquer des dettes techniques, 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, au lancement.

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 que l’attention doit être accordée au problème.

Équipement informatique et dette technique

Tout le matériel informatique doit être entretenu. Des correctifs de sécurité doivent être appliqués aux logiciels et aux micrologiciels, et les systèmes d’exploitation doivent être mis à niveau lorsqu’ils deviennent 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 aux premiers signes avant-coureurs de développement d’erreurs. Si le disque dur en question ne fait pas partie d’une matrice RAID, n’attendez pas les signes avant-coureurs. Agir lorsque le variateur a rempli son cycle de service prévu.

Finalement, tous les équipements et systèmes d’exploitation deviennent obsolètes. L’utilisation d’équipements anciens 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 très bien. Et même lorsque quelque chose est destiné à être amélioré et remplacé, la dette technique persiste jusqu’à ce que le remplacement ait effectivement eu lieu.

Parfois, l’exécution de systèmes d’exploitation expirés ou d’anciens matériels échappe à votre contrôle immédiat. Les PC de laboratoire et de contrôle industriel sont particulièrement sujets au verrouillage du système d’exploitation. Cela peut arriver 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 qui était en cours lorsque le produit a été lancé. 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 millésime particulier de matériel PC, 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 peut contrôler la production ou d’autres machines ou processus critiques. Vous ne pouvez pas vous contenter de vous débarrasser de l’ancien 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. Il se peut qu’il n’y ait pas de connaissance approfondie des systèmes obsolètes dans vos équipes de support. Souvent, lorsque ces anciens systèmes sont découverts comme étant plus profondément interconnectés et intégrés qu’on ne le croyait auparavant.

Projets de développement et dette technique

Les projets de développement non triviaux sont soumis à de nombreuses exigences. Que l’application soit destinée à la consommation interne ou qu’il s’agisse d’un produit qui sera commercialisé, les points de stress sont similaires. La plupart d’entre eux 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 doit être plus qu’une longue liste de souhaits. Le temps disponible pour le développement, les tests et la documentation dicte le contenu qui peut être réalisé de manière réaliste avec les ressources de développement dont vous disposez et les technologies avec lesquelles ils sont familiers.

Un cahier des charges trop optimiste ou une phase de développement trop courte revient au même. Le travail ne rentre pas dans le temps disponible. L’impact que cela a sur l’équipe de développement est profond. S’ils se retrouvent sous le feu des projecteurs, les techniques, méthodologies et technologies connues seront préférées au temps consacré à l’évaluation de nouvelles plates-formes, cadres 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 d’introduire potentiellement des risques. Ce risque peut être des problèmes fonctionnels au sein du logiciel qui ont un impact sur les utilisateurs ou il peut s’agir de problèmes insidieux qui donnent lieu à des failles de sécurité.

Parfois, le développement subit la pression du côté commercial de l’entreprise. Ils peuvent stipuler qu’une nouvelle technologie est utilisée pour garantir que votre produit se compare à la concurrence. Cela signifie que vous êtes obligé d’essayer d’apprendre la nouvelle technologie tout en respectant la date limite.

Ces types de blessures auto-infligées affectent l’architecture du produit et la qualité du code. Vous ne tirerez le meilleur parti d’un nouveau framework, d’un nouveau langage ou même d’un nouveau paradigme de développement tant que vos développeurs ne le connaîtront pas suffisamment pour comprendre ses idiomes et ses meilleures pratiques. À tout le moins, il est susceptible de produire du code qui fonctionne mal et est difficile à maintenir. Dans le pire des cas, cela peut introduire des risques de sécurité.

Les bibliothèques et boîtes à outils tierces accélèrent le développement, mais elles peuvent contenir des failles de sécurité et leur propre dette technique. L’utilisation de code tiers simplifie 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 conversations avec le développement afin qu’une description et des spécifications de produit réalistes mais mutuellement satisfaisantes puissent être rédigées, en tenant compte des délais et des technologies à la fois actuelles et de pointe. Votre équipe de sécurité doit également être impliquée. Et parce que votre équipe de développement n’est jamais assise à ne rien faire, des dispositions doivent être prises pour la recherche. Sinon, cela n’arrivera pas.

La planification formelle du temps et des ressources pour la recherche, y compris la formation, est le seul moyen de garantir que la recherche essentielle a lieu. Vous devrez peut-être recruter pour y parvenir. sans recherche, vous ne pourrez jamais passer aux nouvelles technologies de manière contrôlée. Et sans contrôle, vous vous retrouvez avec un risque.

Gouvernance et dette technique

La dette technique peut s’insinuer dans la création de cadres de gouvernance de la même manière qu’elle le fait avec le développement de logiciels. Au lieu de développer des logiciels, vous créez des politiques et des procédures, telles que des systèmes de gouvernance informatique ou de protection des données. Vous ne donneriez pas un projet de développement à une équipe qui n’a jamais écrit de code auparavant. La même chose s’applique à la documentation de gouvernance.

Vous ne pouvez pas vous attendre à d’excellents résultats si vous confiez la tâche à quelqu’un qui n’a pas les compétences appropriées. La rédaction de documents de bonne gouvernance est difficile. Sans cet ensemble de compétences, il est tentant de copier des morceaux des politiques et procédures d’autres organisations et d’essayer de les modifier en un tout cohérent, mais cela ne fonctionne pas. Le résultat est un patchwork de morceaux de documents qui ont été conçus pour d’autres organisations.

Vos auteurs de gouvernance doivent connaître et comprendre la législation ou la norme que vous essayez de satisfaire ou de traiter, et être expérimentés dans la production de documents de gouvernance et de politique. Si ce n’est pas vous, engagez-vous avec quelqu’un qui a ces compétences.

Un autre échec courant est de rendre les documents de gouvernance impressionnants au lieu de les rendre factuels. Ils doivent refléter fidèlement ce que vous faites et devez contrôler, et comment vous allez le faire afin de respecter la législation ou la norme avec laquelle vous travaillez. Il est impossible de réussir un audit si les documents sur lesquels vous êtes audité ne reflètent pas vos processus, flux de travail et protections réels.

Disposer de documents de gouvernance précis et applicables n’apporte que très peu de résultats s’ils ne sont pas utilisés. La complaisance en matière de conformité, c’est lorsque 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, sinon vos procédures ne sont pas mené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. Vous devez effectuer des audits internes par exemple, et vous devez surveiller le paysage législatif. La législation change au fil du temps et est abrogée et remplacée. L’entreprise peut choisir ou être obligée d’adhérer à une norme à laquelle elle n’a pas été forcée de se conformer auparavant. Par exemple, vous pouvez commencer à accepter des paiements en ligne et devoir 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 nouvelles exigences et pour garantir que toutes les clauses des normes sont prises en compte.

Faire face à vos dettes

La dette technique ne dort jamais, et elle empire à mesure que vous la laissez. Ce qu’il faut pour résoudre le problème va du facile au très difficile. Il est facile d’établir une politique de correctifs et d’établir un calendrier. Éradiquer le verrouillage des systèmes existants peut nécessiter des bouleversements et des dépenses intenables.

Si vous avez une dette technique que vous ne pouvez pas régler, ou qui ne peut pas être réglée jusqu’à ce qu’un autre événement important se produise, assurez-vous que le risque est capturé et caractérisé dans vos documents d’évaluation des risques opérationnels et d’évaluation des cyber-risques. Enregistrez les mesures qui ont été prises pour atténuer le risque et les mesures d’urgence que vous pouvez prendre si le risque se produit.

★★★★★