Perché il compiacimento della conformità è un'altra forma di debito tecnico?

0
139
Den Rise/Shutterstock.com< /figure>

Il debito tecnico si presenta in tre forme. Apparecchiature legacy che non possono soddisfare le esigenze odierne, progetti software in cui sono stati tagliati gli angoli e framework di governance mal implementati o completamente ignorati. Il filo conduttore? Rischio.

Debito tecnico

Il debito tecnico è il disavanzo tra la performance ipotizzata di qualcosa e ciò che effettivamente offre. A causa della disparità, c'è un'inevitabile sottoperformance. Il debito tecnico non invecchia bene. Man mano che la disparità cresce, aumenta anche la tua esposizione al rischio.

Il debito tecnico può accumularsi lentamente. L'hardware e i sistemi operativi obsoleti alla fine scivolano indietro dai loro produttori’ cicli di supporto. Il debito tecnico è il crescente rischio per la sicurezza a cui stai esponendo la tua organizzazione eseguendo sistemi che non ricevono patch di sicurezza.

A volte puoi ereditare il debito tecnico attraverso una fusione o un'acquisizione. Puoi anche produrre debiti tecnici, specialmente nei progetti di sviluppo software. Le decisioni di progettazione e implementazione—spesso imposte al team di sviluppo a causa di vincoli di budget o scadenze irrealistiche—possono introdurre un debito tecnico che è integrato nell'applicazione ed esiste, completamente formato, al momento del lancio.

IT i quadri di governance come le politiche e le procedure di sicurezza informatica e protezione dei dati possono accumulare debito tecnico, possono essere creati con debito tecnico già incorporato in essi o possono risentirne di entrambi.

Pubblicità

in tutti i casi, il tecnico il debito equivale direttamente al rischio. È un indicatore sicuro che occorre prestare attenzione al problema.

Attrezzature informatiche e debiti tecnici

Tutte le attrezzature informatiche devono essere mantenute. Le patch di sicurezza devono essere applicate al software e al firmware e i sistemi operativi devono essere aggiornati quando diventano obsoleti e non sono supportati. I dischi rigidi devono essere sostituiti alla fine della loro vita utile prevista o ai primi segnali di allarme di sviluppo di errori. Se il disco rigido in questione non fa parte di un array RAID, non attendere i segnali di avvertimento. Agire quando l'unità ha soddisfatto il ciclo di lavoro previsto.

Alla fine, tutte le apparecchiature e i sistemi operativi diventano obsoleti. L'utilizzo di apparecchiature obsolete e non supportate rappresenta un rischio per la sicurezza. Nonostante ciò, può essere difficile vendere al lato commerciale del business per sostituire qualcosa che, per loro, funziona ancora bene. E anche quando qualcosa è destinato a essere aggiornato e sostituito, il debito tecnico persiste fino a quando la sostituzione non è effettivamente avvenuta.

A volte, l'esecuzione di sistemi operativi scaduti o hardware obsoleto è al di fuori del tuo controllo immediato. I PC di controllo da laboratorio e industriali sono particolarmente soggetti al blocco del sistema operativo. Questo può accadere se un software di terze parti cruciale non è stato aggiornato da quando è stato rilasciato. Ciò può costringerti a eseguire il sistema operativo corrente al momento del lancio del prodotto. potrebbe essere un problema basato sull'hardware. Se il software funziona solo con una scheda di interfaccia particolare e antica che è compatibile solo con un particolare hardware del PC vintage, sei bloccato con i sistemi operativi che quei POC possono supportare.

Sostituzione completa hardware e software obsoleti non sono così facili come sembra. Potrebbe controllare la produzione o altri macchinari o processi mission-critical. Non puoi semplicemente scaricare le vecchie cose se ciò che è disponibile oggi non si integra con i tuoi sistemi di produzione.

Più vecchi sono i sistemi, più è probabile che le persone che li hanno implementati abbiano lasciato l'azienda. Potrebbe non esserci una conoscenza approfondita dei sistemi obsoleti nei tuoi team di supporto. Spesso, quando si scopre che questi vecchi sistemi sono più profondamente interconnessi e integrati di quanto si pensasse in precedenza.

Progetti di sviluppo e debito tecnico

< p>I progetti di sviluppo non banali hanno molte richieste. Sia che l'applicazione sia per il consumo interno o sia un prodotto che sarà commercializzato, i punti di stress sono simili. La maggior parte ruota attorno a scadenze, specifiche e budget.

Pubblicità

La specifica è un elenco di funzionalità e contenuti che il software deve fornire. La specifica deve essere più di una lunga lista dei desideri. Il tempo disponibile per lo sviluppo, il test e la documentazione determina quali contenuti possono essere realisticamente realizzati con le risorse di sviluppo disponibili e le tecnologie con cui hanno familiarità.

Una specifica troppo ottimistica o una fase di sviluppo troppo breve sono la stessa cosa. Il lavoro non rientra nel tempo a disposizione. L'impatto che questo ha sul team di sviluppo è profondo. Se si trovano sotto tiro, le tecniche, le metodologie e le tecnologie conosciute saranno preferite al tempo dedicato alla valutazione di nuove piattaforme, framework o altro.

Quando sei sulla marcia della morte verso una scadenza, non hai tempo per iniziare a sperimentare nuove tecnologie e potenzialmente introdurre rischi. Questo rischio può essere rappresentato da problemi funzionali all'interno del software che hanno un impatto sugli utenti o possono essere problemi insidiosi che danno origine a vulnerabilità di sicurezza.

A volte lo sviluppo subisce pressioni dal lato commerciale dell'azienda. Potrebbero stabilire che una nuova tecnologia venga utilizzata per garantire che il tuo prodotto si affermi rispetto alla concorrenza. Ciò significa che sei costretto a provare ad apprendere la nuova tecnologia e rispettare comunque la scadenza.

Questi tipi di ferite autoinflitte influenzano l'architettura del prodotto e la qualità del codice. Non otterrai il meglio da un nuovo framework, linguaggio o paradigma di sviluppo finché i tuoi sviluppatori non avranno familiarità con esso per comprenderne gli idiomi e le migliori pratiche. Come minimo, è probabile che produca codice con prestazioni scadenti ed è difficile da mantenere. Nel peggiore dei casi, può introdurre rischi per la sicurezza.

Pubblicità

Librerie e toolkit di terze parti accelerano lo sviluppo, ma possono ospitare vulnerabilità di sicurezza e il proprio debito tecnico. L'utilizzo di codice di terze parti semplifica lo sviluppo ma può complicare le cose per il tuo team di sicurezza.

Gli aspetti aziendali e commerciali dell'organizzazione devono essere coinvolti nelle prime conversazioni con lo sviluppo in modo da poter redigere una descrizione e una specifica del prodotto realistiche ma reciprocamente soddisfacenti, tenendo conto delle scadenze e delle tecnologie attuali e all'avanguardia. Anche il tuo team di sicurezza deve essere coinvolto. E poiché il tuo team di sviluppo non è mai seduto a non fare nulla, devono essere previste disposizioni per la ricerca. Altrimenti, non accadrà.

La programmazione formale di tempo e risorse per la ricerca—compresa la formazione—è l'unico modo per garantire che la ricerca essenziale abbia luogo. Potrebbe essere necessario reclutare per raggiungere questo obiettivo. senza ricerca, non sarai mai in grado di passare alle nuove tecnologie in modo controllato. E senza controllo, sei lasciato con il rischio.

Governance e debito tecnico

Il debito tecnico può insinuarsi nella creazione di strutture di governance in modo simile a quanto avviene con lo sviluppo del software. Invece di sviluppare software, stai creando policy e procedure, come la governance IT o i sistemi di protezione dei dati. Non daresti un progetto di sviluppo a un team che non ha mai scritto codice prima. La stessa cosa vale per la documentazione sulla governance.

Non puoi aspettarti grandi risultati se assegni il compito a qualcuno che non ha le competenze adeguate. Scrivere documenti di buona governance è difficile. Senza questo set di competenze, si è tentati di copiare pezzi da altre organizzazioni’ politiche e procedure e prova a modificarle in un insieme coeso, ma non funziona. Il risultato è una trapunta patchwork di frammenti di documenti progettati per altre organizzazioni.

I tuoi autori di governance devono conoscere e comprendere la legislazione o lo standard che stai cercando di soddisfare o affrontare ed essere esperti nella produzione di documenti di governance e policy. Se non sei tu, interagisci con qualcuno che ha queste capacità.

Pubblicità

Un altro errore comune è rendere i documenti di governance impressionanti invece di renderli concreti. Devono riflettere fedelmente ciò che fai e devi controllare, e come lo farai in modo da soddisfare la legislazione o lo standard con cui stai lavorando. È impossibile superare un controllo se i documenti su cui sei sottoposto a revisione non riflettono i tuoi processi, flussi di lavoro e misure di sicurezza effettivi.

Avere documenti di governance accurati e applicabili ottiene molto poco se non vengono utilizzati. Il compiacimento della conformità è quando si hanno le politiche e le procedure, ma nessuno le usa. Devono essere adottati e utilizzati dalla tua forza lavoro, altrimenti le tue procedure non vengono condotte in conformità con le tue politiche. Questo è già abbastanza grave, ma significa anche che i tuoi processi non genereranno un audit trail. Ancora peggio, non seguire le procedure può portare a falle di sicurezza e violazioni dei dati.

Anche il mantenimento di un sistema di governance richiede tempo e risorse. È necessario eseguire audit interni, ad esempio, e monitorare il panorama legislativo. La legislazione cambia nel tempo, viene abrogata e superata. L'azienda può scegliere o essere obbligata a rispettare uno standard a cui non è stata costretta a conformarsi prima. Ad esempio, potresti iniziare a ricevere pagamenti online e dover rispettare lo standard PCI-DSS (Payment Card Industry Data Security Standard). La tua documentazione sulla governance dovrà essere modificata per riflettere le nuove esigenze e per garantire che tutte le clausole degli standard siano soddisfatte.

Facing Your Debts

Il debito tecnico non dorme mai e peggiora man mano che lo lasci. Quello che serve per affrontare il problema varia dal facile al molto difficile. Stabilire una politica di patch e stabilire una pianificazione è facile. Sradicare il blocco dei sistemi legacy potrebbe richiedere sconvolgimenti e spese insostenibili.

Se hai un debito tecnico che non puoi affrontare—o che non può essere affrontato fino a quando non si verifica qualche altro evento significativo—assicurati hai il rischio catturato e caratterizzato nei tuoi documenti di valutazione del rischio operativo e di valutazione del rischio informatico. Registra quali misure sono state intraprese per mitigare il rischio e quali misure di emergenza puoi eseguire in caso di rischio.