Categoria: Security (IT)

E di come la sicurezza deve passare attraverso processi precisi e invalicabili

L’incredulità, gli occhi sbarrati di fronte alle prime notizie.
I brividi veri, quelli che ti scuotono fin dentro le ossa, quando ti rendi conto che potrebbe non essere stata una tragedia imprevedibile, ma c’è il tragico sospetto che sia stata frutto di decisioni od omissioni umane. 

Ero indeciso se scrivere queste parole. 

Non sono un esperto di funivie, non voglio sputare sentenze già troppo proclamate da ogni dove. 

Non voglio condannare e puntare il dito, non spetta a me. 

Vorrei solo analizzare le possibili soluzioni in termini di procedure.

Non quelle “a caldo”. Quelle saranno una danza di controlli a tappeto. 

Abbiamo oltre 1477 impianti a fune in Italia.

In quanti altri luoghi potrebbe ancora accadere?

Quanti altri boati immensi e innaturali potrebbero interrompere la quiete di quei paesi? 

Si susseguiranno verifiche, analisi, manutenzioni straordinarie. 

Se qualcun altro (e mi auguro proprio di no) aveva avuto la malaugurata idea di omettere dei controlli di sicurezza del genere, si sarà spaventato a morte pensando alle ben più gravi conseguenza a cui sarebbe andato incontro. 

Quindi, come ti dicevo, non importa molto la soluzione “a caldo”, ma quella a freddo, quando si saranno calmate le acque. 

Quando il boato assordante avrà finito di riecheggiare nelle nostre orecchie e ci sarà un altro problema all’ordine del giorno. 

Le soluzioni a lungo termine: quelle che davvero possono evitare le disgrazie

Facciamo una piccola premessa. 

Read More

HAI MAI CONSEGNATO UN TEMA, UN ARTICOLO, UN LIBRO SENZA RILEGGERLO?

    OPPURE LO HAI MAI MANDATO IN STAMPA COSI’ COM’ERA, SPERANDO CHE IL LETTORE O IL PROFESSORE TROVASSERO LORO I TUOI ERRORI ?

    SE LO RILEGGI: OGNI QUANTO LO FAI?

 

Tu normalmente quando scrivi cosa fai, aspetti di avere scritto 300 pagine per dare una rilettura? O 50? Ovviamente la risposta è uguale per tutti: NO.

Questo è un esempio che faccio spesso ai miei clienti più digiuni dell’importanza teorica e pratica dell’attività di test del software.

 

Scrivere un software è come scrivere un libro: soprattutto quando si tratta di rileggerlo

 

Prendiamo uno studente, un professionista di un altro settore, un giornalista, uno scrittore. Possiamo prendere noi stessi come esempio, perché nella vita a partire dai banchi di scuola in poi, qualcosa l’abbiamo scritta: quando rileggiamo quello che abbiamo scritto?

Read More

Recentemente è stato scoperto un software nascosto in grado di registrare ogni lettera digitata su un laptop HP. L’impatto è di vasta portata, con molti modelli attuali di laptop HP che sono affetti dal problema. In questo post analizzeremo prima il problema del key-logging, quindi discuteremo un metodo migliore per impedire che ciò accada in futuro.

Un ricercatore di sicurezza informatica Michael Myng ha trovato del codice di keylogging nei driver software preinstallati sui laptop HP per far funzionare la tastiera. Ha scoperto il codice keylogger durante l’ispezione del software Synaptics Touchpad, mentre cercava di capire come controllare la retroilluminazione della tastiera sul portatile HP. Mr Myng ha dichiarato: “Il keylogger era disabilitato di default, ma un utente malintenzionato con accesso al computer avrebbe potuto abilitare la registrazione di ciò che un utente stava digitando.”

Secondo HP, è stato originariamente integrato nel software Synaptics per aiutare a correggere gli errori. HP ha riconosciuto che questo software di debug potrebbe essere sfruttato per provocare una “perdita di riservatezza”, ma ha affermato che né Synaptics né HP hanno avuto accesso ai dati dei clienti a causa del difetto.

Includere in fase di sviluppo del software come il keylogging è una pratica comune e viene inizialmente creato per aiutare gli sviluppatori a eseguire il debug del software. Questo codice può anche essere chiamato “codice di debug”. Tuttavia, quando il codice viene inserito nel software di rilascio ed esiste un semplice meccanismo per attivarlo, diventa un potenziale rischio per la sicurezza. Il codice di debug, una volta scoperto, verrebbe normalmente registrato come CWE (Common Weakness Enumeration). CWE è un dizionario online universale di punti deboli che sono stati trovati nel software per computer. Il dizionario è gestito dalla MITRE Corporation e può essere consultato gratuitamente su base mondiale.

Tuttavia, a causa della possibilità che possa essere sfruttato sul campo da alcuni software dannosi, è più che probabile che sia registrato come CVE (vulnerabilità ed esposizioni comuni). CVE è un catalogo di minacce alla sicurezza conosciute. Il catalogo è sponsorizzato dal Department of Homeland Security degli Stati Uniti (DHS) e le minacce sono suddivise in due categorie: vulnerabilità ed esposizioni.

Read More

Il software è stato inizialmente visto come qualcosa che poteva essere scritto una volta e usato molte volte senza mai “rompersi”. Tuttavia, quell’illusione svanì quando iniziarono ad apparire problemi, in ultima analisi causati da uno sviluppo continuo senza i giusti processi di controllo della qualità. Ciò era in genere dovuto a pressioni aziendali incredibili per rilasciare nuovi prodotti e funzionalità in un tempo compresso per essere sul mercato.

Questi problemi hanno portato ad applicazioni software che trasportano un’enorme quantità di problemi che hanno un nome ben preciso:

DEBITO TECNOLOGICO

Una metafora dei difetti latenti introdotti durante l’architettura, la progettazione o lo sviluppo del sistema. La difettosità accumulata quando le organizzazioni adottano queste scorciatoie di progettazione e test, al fine di raggiungere gli obiettivi a breve termine, alla fine rende il software difficile da mantenere. Con l’aumento del debito tecnologico, gli sviluppatori dedicano la maggior parte del loro tempo a correggere bug e a lottare con codice fragile, invece di concentrarsi sul core business e creare nuove funzionalità.

Molte organizzazioni ora stanno scoprendo che il software legacy ha in genere una diminuzione della durata della vita utile; dopo averlo creato e rilasciato, sono costretti a decidere se buttarlo via e ricominciare da zero, o cercare di recuperarlo. Nella maggior parte dei casi, è stato fatto un notevole investimento finanziario nella base di codice, quindi c’è una tremenda pressione per riutilizzarlo. La chiave per ridurre il debito tecnologico consiste nel rifattorizzare i componenti (il processo di ristrutturazione dei componenti di un’applicazione senza modificarne il comportamento esterno) nel tempo, ma gli sviluppatori sono spesso riluttanti a farlo per paura di corrompere le funzionalità esistenti. Uno dei maggiori ostacoli al refactoring è la mancanza di test che caratterizzano il comportamento esistente di un componente.

Questo è un problema crescente in quanto vi sono molte applicazioni distribuite basate su basi di codice legacy che non hanno i testcase necessari. Questo è aggravato quando il codice legacy viene distribuito su una nuova piattaforma o prodotto, poiché la mancanza di artefatti di test significa che il debito tecnologico continua a crescere senza possibilità di “ripagarlo”. C’è un enorme gap di qualità che deve essere affrontato, ma molte aziende non sanno da dove iniziare o non hanno le risorse necessarie per affrontare il problema.

Read More

Il software è uno dei prodotti più complessi mai prodotti dall’uomo, senza paragoni. Non esiste prodotto letterario, programma scientifico, opera architettonica che possa eguagliare il numero di ore/uomo o anni/uomo necessari a produrre un software di grande complessità come quello che equipaggia un moderno aereo, un’automobile di ultima generazione, il computer o smartphone che state utilizzando, un social come Facebook.

Ed il software è talmente complesso che spesso sbaglia… anzi, uccide.

 

Il software uccide le persone, brucia capitali enormi, fa saltare in aria le aziende, crea irreparabili danni di immagine

 

Nel 1982, si sospetta che la CIA abbia volutamente introdotto un bug (errore software) all’interno del codice di controllo della condotta di gas transiberiana in Russia. Per motivi di contro-spionaggio, gli USA hanno deciso di far esplodere tale condotta una volta operativa con il risultato di provocare la più grande esplosione non-nucleare della storia.

Read More