Technische schulden zijn er in drie vormen. Verouderde apparatuur die niet kan voldoen aan de huidige behoeften, softwareprojecten waar het moeilijk is en slecht geïmplementeerde of volledig genegeerde governancekaders. De rode draad? Risico.
Technische schuld
Technische schuld is het tekort tussen de veronderstelde prestatie van iets en wat het daadwerkelijk oplevert. Door de ongelijkheid is er een onvermijdelijke underperformance. Technische schuld veroudert niet goed. Naarmate de ongelijkheid groter wordt, groeit uw blootstelling aan risico's.
Technische schulden kunnen langzaam oplopen. Verouderde hardware en besturingssystemen schuiven uiteindelijk achteruit uit hun fabrikanten’ ondersteuning cycli. De technische schuld is het toenemende beveiligingsrisico waaraan u uw organisatie blootstelt door systemen te gebruiken die geen beveiligingspatches ontvangen.
Soms kunt u technische schulden erven door een fusie of overname. U kunt ook technische schuld produceren, vooral in softwareontwikkelingsprojecten. Ontwerp- en implementatiebeslissingen die vaak aan het ontwikkelteam worden opgedrongen vanwege budgetbeperkingen of onrealistische deadlines, kunnen technische schuld veroorzaken die in de applicatie is ingebakken en die bij de lancering al volledig bestaat.
IT governancekaders zoals beleid en procedures voor cyberbeveiliging en gegevensbescherming kunnen technische schulden opstapelen, kunnen worden gecreëerd met technische schulden die er al in zijn ingebed, of kunnen last hebben van beide.
Advertentie
in alle gevallen is de technische schuld direct gelijk aan risico. Het is een duidelijke indicatie dat er aandacht moet worden besteed aan het probleem.
IT-apparatuur en technische schuld
Alle IT-apparatuur moet worden onderhouden. Beveiligingspatches moeten worden toegepast op software en firmware, en besturingssystemen moeten worden geüpgraded als ze verouderd raken en niet meer worden ondersteund. Harde schijven moeten worden vervangen aan het einde van hun verwachte levensduur, of bij de eerste tekenen van het ontwikkelen van fouten. Als de betreffende harde schijf geen deel uitmaakt van een RAID-array, wacht dan niet op waarschuwingssignalen. Handel wanneer de schijf zijn verwachte werkcyclus heeft volbracht.
Uiteindelijk raken alle apparatuur en besturingssystemen verouderd. Het gebruik van oude, niet-ondersteunde apparatuur is een veiligheidsrisico. Desondanks kan het moeilijk zijn om aan de commerciële kant van het bedrijf te verkopen om iets te vervangen dat voor hen nog steeds prima werkt. En zelfs als iets is geoormerkt om te worden geüpgraded en vervangen, blijft de technische schuld bestaan totdat de vervanging daadwerkelijk heeft plaatsgevonden.
Soms heeft u geen directe controle over het uitvoeren van verlopen besturingssystemen of oude hardware. Laboratorium- en industriële controle-pc's zijn bijzonder gevoelig voor lock-in van het besturingssysteem. Dit kan gebeuren als een stukje cruciale software van derden niet is bijgewerkt sinds het is uitgebracht. Dat kan u dwingen om het besturingssysteem uit te voeren dat actueel was toen het product werd gelanceerd. het kan een hardwareprobleem zijn. Als de software alleen werkt met een bepaald, oud interfacebord dat alleen compatibel is met een bepaalde vintage pc-hardware, zit je vast aan de besturingssystemen die deze POC's kunnen ondersteunen.
Volledig vervangen verouderde hardware en software is niet zo eenvoudig als het klinkt. Het kan de productie of andere bedrijfskritieke machines of processen aansturen. Je kunt de oude dingen niet zomaar dumpen als wat vandaag beschikbaar is niet integreert met je productiesystemen.
Hoe ouder de systemen zijn, hoe groter de kans dat de mensen die ze hebben geïmplementeerd het bedrijf hebben verlaten. Er is mogelijk geen diepgaande kennis van de verouderde systemen in uw ondersteuningsteams. Vaak, wanneer wordt ontdekt dat deze oude systemen dieper met elkaar verbonden en ingebed zijn dan eerder werd begrepen.
Ontwikkelingsprojecten en technische schulden
< p>Niet-triviale ontwikkelingsprojecten stellen veel eisen. Of de toepassing nu voor eigen consumptie is of een product is dat op de markt zal worden gebracht, de stresspunten zijn vergelijkbaar. De meeste draaien om deadlines, specificaties en budgetten.
Advertentie
De specificatie is een lijst met functionaliteit en inhoud die de software moet bieden. De specificatie moet meer zijn dan een lange wensenlijst. De beschikbare tijd voor ontwikkeling, testen en documentatie bepaalt welke inhoud realistisch kan worden bereikt met de ontwikkelingshulpmiddelen die u beschikbaar hebt en de technologieën waarmee ze vertrouwd zijn.
Een te optimistische specificatie of een te korte ontwikkelfase komt op hetzelfde neer. Het werk past niet in de beschikbare tijd. De impact die dit heeft op het ontwikkelteam is groot. Als ze zich onder het geweer bevinden, krijgen bekende technieken, methodologieën en technologieën de voorkeur boven tijd besteden aan het beoordelen van nieuwe platforms, frameworks of wat dan ook.
Als je op de dodenmars naar een deadline zit, heb je geen tijd om te gaan experimenteren met nieuwe technologieën en mogelijk risico's te introduceren. Dat risico kunnen functionele problemen zijn binnen de software die van invloed zijn op de gebruikers of het kunnen verraderlijke problemen zijn die aanleiding geven tot beveiligingsproblemen.
Soms staat de ontwikkeling onder druk van de commerciële kant van het bedrijf. Ze kunnen bepalen dat er een nieuwe technologie wordt gebruikt om ervoor te zorgen dat uw product het opneemt tegen de concurrentie. Dat betekent dat je gedwongen wordt om te proberen de nieuwe technologie te leren en toch de deadline te halen.
Dit soort zelf toegebrachte wonden beïnvloeden de architectuur van het product en de codekwaliteit. U haalt het beste uit een nieuw framework, taal of zelfs ontwikkelingsparadigma totdat uw ontwikkelaars er voldoende vertrouwd mee zijn om de idiomen en best practices te begrijpen. Op zijn minst zal het waarschijnlijk code produceren die slecht presteert en moeilijk te onderhouden is. In het ergste geval kan het beveiligingsrisico's met zich meebrengen.
Advertentie
Bibliotheken en toolkits van derden versnellen de ontwikkeling, maar ze kunnen kwetsbaarheden in de beveiliging en hun eigen technische schuld bevatten. Het gebruik van code van derden vereenvoudigt de ontwikkeling, maar kan de zaken voor uw beveiligingsteam bemoeilijken.
De zakelijke en commerciële kant van de organisatie moeten worden betrokken bij vroege gesprekken met ontwikkeling, zodat een realistische maar wederzijds bevredigende productbeschrijving en specificatie kan worden opgesteld, rekening houdend met deadlines en technologieën, zowel huidige als geavanceerde. Uw beveiligingsteam moet ook worden betrokken. En omdat uw ontwikkelteam nooit niets doet, moeten er voorzieningen worden getroffen voor onderzoek. Anders gebeurt het niet.
Formeel plannen van tijd en middelen voor onderzoek, inclusief training, is de enige manier om ervoor te zorgen dat essentieel onderzoek plaatsvindt. Mogelijk moet u rekruteren om dit te bereiken. zonder onderzoek kun je nooit op een gecontroleerde manier overstappen op nieuwe technologieën. En zonder controle houdt u risico's.
Bestuur en technische schuld
Technische schuld kan op dezelfde manier binnensluipen in het creëren van bestuurskaders als bij softwareontwikkeling. In plaats van software te ontwikkelen, creëer je beleid en procedures, zoals IT-governance of gegevensbeschermingssystemen. Je zou een ontwikkelingsproject niet geven aan een team dat nog nooit eerder code heeft geschreven. Hetzelfde geldt voor governancedocumentatie.
Je kunt geen geweldige resultaten verwachten als je de taak aan iemand geeft die niet over de juiste vaardigheden beschikt. Het schrijven van documenten voor goed bestuur is moeilijk. Zonder die vaardigheden is het verleidelijk om brokken uit andere organisaties te kopiëren. beleid en procedures en probeer ze te bewerken tot een samenhangend geheel, maar het werkt niet. Het resultaat is een lappendeken van stukjes documenten die voor andere organisaties zijn ontworpen.
Uw governance-auteurs moeten de wetgeving of norm kennen en begrijpen waaraan u probeert te voldoen of die u wilt aanpakken, en ervaring hebben met het opstellen van governance- en beleidsdocumenten. Als jij dat niet bent, neem dan contact op met iemand die deze vaardigheden heeft.
Advertentie
Een andere veelvoorkomende tekortkoming is het indrukwekkend maken van bestuursdocumenten in plaats van ze feitelijk te maken. Ze moeten een echte weerspiegeling zijn van wat u doet en moet controleren, en hoe u het gaat doen, zodat u voldoet aan de wetgeving of norm waarmee u werkt. Het is onmogelijk om voor een audit te slagen als de documenten waarop u wordt gecontroleerd niet uw werkelijke processen, workflows en waarborgen weerspiegelen.
Het hebben van nauwkeurige en toepasbare bestuursdocumenten levert weinig op als ze niet worden gebruikt. Nalevingszelfgenoegzaamheid is wanneer u het beleid en de procedures heeft, maar niemand ze gebruikt. Ze moeten worden aangenomen en gebruikt door uw personeel, anders worden uw procedures niet uitgevoerd in overeenstemming met uw beleid. Dat is al erg genoeg, maar het betekent ook dat uw processen geen audittrail zullen genereren. Erger nog, het niet volgen van procedures kan leiden tot beveiligingslekken en datalekken.
Het onderhouden van een governancesysteem vereist ook tijd en middelen. U moet bijvoorbeeld interne audits uitvoeren en u moet het wetgevingslandschap bewaken. Wetgeving verandert in de loop van de tijd en wordt ingetrokken en vervangen. Het bedrijf kan ervoor kiezen om zich te houden aan een norm die ze nog niet eerder hebben moeten naleven, of worden gedwongen. U kunt bijvoorbeeld beginnen met het aannemen van online betalingen en u moet voldoen aan de Payment Card Industry Data Security Standard (PCI-DSS). Uw governancedocumentatie moet worden aangepast om de nieuwe eisen weer te geven en om ervoor te zorgen dat aan alle clausules van de normen wordt voldaan.
Uw schulden onder ogen zien
Technische schuld slaapt nooit, en het wordt erger naarmate je er langer mee stopt. Wat er nodig is om het probleem aan te pakken, varieert van gemakkelijk tot zeer moeilijk. Het opstellen van een patchbeleid en het opstellen van een planning is eenvoudig. Het uitroeien van de lock-in aan legacy-systemen kan onhoudbare omwentelingen en uitgaven vergen.
Als u een technische schuld heeft die u niet kunt oplossen—of die niet kan worden opgelost totdat een andere belangrijke gebeurtenis plaatsvindt—zorg ervoor dat u u hebt het risico vastgelegd en gekarakteriseerd in uw operationele risicobeoordeling en cyberrisicobeoordelingsdocumenten. Leg vast welke stappen zijn genomen om het risico te beperken en welke noodmaatregelen u kunt nemen als het risico zich voordoet.