Teknisk skuld finns i tre former. Äldre utrustning som inte kan tillgodose dagens behov, programvaruprojekt där hörn har klippts och dåligt implementerade eller helt ignorerade ramar för styrning. Den röda tråden? Risk.
Teknisk skuld
Teknisk skuld är underskottet mellan det antagna resultatet för något och vad det faktiskt levererar. På grund av skillnaden finns det en oundviklig underprestanda. Teknisk skuld åldras inte bra. När skillnaden växer så växer din exponering för risk.
Teknisk skuld kan långsamt tillfalla. Åldrande hårdvara och operativsystem glider så småningom bakåt från sina tillverkare & # 8217; stödcykler. Den tekniska skulden är den ökande säkerhetsrisken som du utsätter din organisation för genom att köra system som inte får säkerhetsuppdateringar.
Ibland kan du ärva teknisk skuld genom en fusion eller ett förvärv. Du kan också tillverka teknisk skuld, särskilt i programvaruutvecklingsprojekt. Design- och implementeringsbeslut som ofta tvingas på utvecklingsteamet på grund av budgetbegränsningar eller orealistiska tidsfrister kan införa teknisk skuld som bakas in i applikationen och existerar, helt bildad, vid lanseringen.
IT styrningsramar som cybersäkerhet och dataskyddspolicyer och -förfaranden kan ackumulera teknisk skuld, kan skapas med tekniska skulder som redan är inbäddade i dem eller kan drabbas av båda.
Annons
i alla fall det skuld motsvarar direkt risk. Det är en säker indikator på att problemet måste uppmärksammas.
IT-utrustning och teknisk skuld
All IT-utrustning måste underhållas. Säkerhetsuppdateringar måste tillämpas på programvara och firmware, och operativsystem måste uppgraderas när de blir föråldrade och inte stöds. Hårddiskar måste bytas ut vid slutet av den förväntade livslängden eller vid de första varningssignalerna för att utveckla fel. Om hårddisken i fråga inte är en del av ett RAID-array, vänta inte på varningsskyltar. Åtgärda när enheten har uppfyllt sin förväntade arbetscykel.
Så småningom blir all utrustning och operativsystem föråldrade. Att köra gammal utrustning som inte stöds är en säkerhetsrisk. Trots detta kan det vara svårt att sälja den kommersiella sidan av verksamheten att ersätta något som, för dem, fortfarande fungerar bra. Och även när något öronmärks för att uppgraderas och ersättas kvarstår teknisk skuld tills ersättningen faktiskt har skett.
Ibland går det att köra utgångna operativsystem eller gammal hårdvara utanför din omedelbara kontroll. Laboratoriedatorer och industriella datorer är särskilt benägna att låsa in operativsystem. Detta kan hända om en viktig programvara från tredje part inte har uppdaterats sedan den släpptes. Det kan tvinga dig att köra det operativsystem som var aktuellt när produkten lanserades. det kan vara ett hårdvarubaserat problem. Om programvaran bara fungerar med ett visst, gammalt gränssnittskort som bara är kompatibelt med en viss vintage PC-maskinvara, sitter du fast med de operativsystem som dessa POC kan stödja.
Ersätter helt åldrad hårdvara och programvara är inte så enkelt som det låter. Det kan styra produktion eller andra verksamhetskritiska maskiner eller processer. Du kan inte bara dumpa de gamla grejerna om det som finns tillgängligt idag inte integreras med dina produktionssystem.
Ju äldre systemen är, desto mer troligt är det att de som implementerade dem har lämnat företaget. Det finns kanske ingen djup kunskap om de äldre systemen i dina supportteam. Ofta när dessa gamla system upptäcks vara djupare sammankopplade och inbäddade än vad man tidigare förstått.
Utvecklingsprojekt och teknisk skuld
< p> Icke-triviala utvecklingsprojekt ställs många krav på dem. Oavsett om ansökan är för intern konsumtion eller om det är en produkt som kommer att marknadsföras, är stresspunkterna likartade. De flesta av dem kretsar kring deadlines, specifikationer och budgetar.
Annonsering
Specifikationen är en lista över funktionalitet och innehåll som programvaran måste tillhandahålla. Specifikationen måste vara mer än en lång önskelista. Tiden som är tillgänglig för utveckling, testning och dokumentation dikterar vilket innehåll som realistiskt kan uppnås med den utvecklingsresurs du har tillgänglig och den teknik som de känner till.
En alltför optimistisk specifikation eller en för kort utvecklingsfas uppgår till samma sak. Arbetet passar inte in i den tillgängliga tiden. Effekten detta har på utvecklingsteamet är djupgående. Om de befinner sig under pistolen kommer kända tekniker, metoder och tekniker att föredras framför att ägna tid åt att utvärdera nya plattformar, ramar eller vad som helst.
När du är på dödsmarsch till en deadline har du inte tid att börja experimentera med ny teknik och eventuellt införa risk. Den risken kan vara funktionella problem inom programvaran som påverkar användarna eller de kan vara smygande problem som ger upphov till säkerhetssårbarheter.
Ibland kommer utvecklingen att pressas av den kommersiella sidan av verksamheten. De kan föreskriva att en ny teknik används för att säkerställa att din produkt överensstämmer med konkurrenterna. Det betyder att du tvingas försöka lära dig den nya tekniken och ändå nå deadline.
Dessa typer av självtillförda sår påverkar produktens arkitektur och kodkvaliteten. Du får inte ut det bästa av ett nytt ramverk, språk eller till och med utvecklingsparadigm tills dina utvecklare är tillräckligt bekanta med det för att förstå dess idiom och bästa praxis. Det är åtminstone sannolikt att producera kod som fungerar dåligt och är svår att underhålla. I värsta fall kan det medföra säkerhetsrisker.
Annons
Tredjepartsbibliotek och verktygslådor påskyndar utvecklingen, men de kan innehålla säkerhetsproblem och deras egna tekniska skulder. Att använda tredjepartskod förenklar utvecklingen men kan komplicera saker för ditt säkerhetsteam.
Organisationens affärsmässiga och kommersiella sidor måste involveras i tidiga samtal med utveckling så att en realistisk men ömsesidigt tillfredsställande produktbeskrivning och specifikation kan utarbetas med hänsyn till tidsfrister och teknologier både nuvarande och spetskompetens. Ditt säkerhetsteam måste också vara engagerat. Och eftersom ditt utvecklingsteam aldrig sitter och gör ingenting, måste det finnas åtgärder för forskning. Annars kommer det inte att hända.
Att planera tid och resurser för forskning “inklusive utbildning” är det enda sättet att säkerställa att nödvändig forskning sker. Du kan behöva rekrytera för att uppnå detta. utan forskning kommer du aldrig att kunna flytta till ny teknik på ett kontrollerat sätt. Och utan kontroll har du risken.
Styrning och teknisk skuld
Teknisk skuld kan smyga in i skapandet av ramar för styrning på ett liknande sätt som den gör med mjukvaruutveckling. Istället för att utveckla programvara skapar du policyer och procedurer, såsom IT-styrning eller dataskyddssystem. Du skulle inte ge ett utvecklingsprojekt till ett team som aldrig har skrivit kod förut. Samma sak gäller dokumentation för styrning.
Du kan inte förvänta dig fantastiska resultat om du ger uppgiften till någon som inte har rätt kompetens. Det är svårt att skriva goda styrelsedokument. Utan den skickligheten är det frestande att kopiera bitar från andra organisationer & # 8217; policyer och förfaranden och försök redigera dem till en sammanhängande helhet, men det fungerar inte. Resultatet är ett lapptäcke med bitar av dokument som har utformats för andra organisationer.
Dina styrelseförfattare måste känna till och förstå lagstiftningen eller standarden som du försöker tillfredsställa eller ta itu med, och ha erfarenhet av att producera styrnings- och policydokument. Om det inte är du, kontakta någon som har dessa färdigheter.
Annons
Ett annat vanligt misslyckande är att göra styrdokument imponerande istället för att göra dem faktiska. De måste vara en verklig återspegling av vad du gör och behöver kontrollera, och hur du ska göra det så att du uppfyller lagstiftningen eller standarden du arbetar med. Det är omöjligt att klara en granskning om de dokument du granskas mot inte återspeglar dina faktiska processer, arbetsflöden och säkerhetsåtgärder.
Att ha korrekta och tillämpliga styrdokument uppnår väldigt lite om de inte används. Efterlevnad av efterlevnad är när du har policyer och procedurer, men ingen använder dem. De måste antas och användas av din arbetskraft, annars genomförs inte dina procedurer i enlighet med dina policyer. Det är tillräckligt illa, men det betyder också att dina processer inte genererar ett granskningsspår. Ännu värre, att inte följa procedurer kan leda till säkerhetsfördröjningar och dataintrång.
Att upprätthålla ett styrningssystem kräver också tid och resurser. Du måste till exempel utföra interna revisioner och du måste övervaka lagstiftningslandskapet. Lagstiftningen förändras med tiden och upphävs och ersätts. Verksamheten kan välja att eller tvingas följa en standard som de inte tidigare har tvingats följa. Du kan till exempel börja ta betalningar online och måste följa PCI-DSS (Payment Card Industry Data Security Standard). Din styrdokumentation måste ändras för att återspegla de nya kraven och för att säkerställa att alla klausuler i standarderna tas upp.
Inför dina skulder
Teknisk skuld sover aldrig och den blir värre ju längre du lämnar den. Vad som krävs för att ta itu med problemet sträcker sig från lätt till mycket svårt. Det är enkelt att fastställa en lapppolicy och fastställa ett schema. Att eliminera inlåsning till äldre system kan kräva ohållbar omvälvning och utgifter.
Om du har en teknisk skuld som du inte kan ta itu med & # 8212; eller som inte kan hanteras förrän någon annan viktig händelse äger rum & # 8212; du har risken fångad och karakteriseras i dina operativa riskbedömningar och cyberriskbedömningsdokument. Registrera vilka steg som har vidtagits för att mildra risken och vilka beredskapssteg du kan om risken skulle inträffa.