Crowdstrike, il caos dovuto ad un errore di validazione: le spiegazioni lasciano interdetti

[cresg82]

Originariamente inviato da agonauta78

Comunque in Italia non paga nessuno , in primis perché la società non è italiana e poi perché non paga nessuno a prescindere

Il fatto che la società non sia italiana non sposta una virgola: negligenza = pagano. Il problema se mai potrebbe essere che prima che finisca il processo italiano questi sono già falliti.

Poi c'è da vedere quanto se singole società danneggiate vorranno andare per vie legati od opteranno per altre soluzioni(sconti sui contratti presenti e futuri).

Cmq sul guardian c'è già un articolo che parla di 5 miliardi di danni per le FORTUNE 500. Numero che per me è destinato a crescere.

[giovanni69]

Hanno dimostrato tutta la loro leggerezza ed arroganza.

[mihos]

Originariamente inviato da Tasslehoff

Un test a mano? Non automatizzato?

Ma siete impazziti? Questo violerebbe la supercazzola numero due del momento (la numero uno ovviamente è IA, quella è francamente impossibile da spodestare), ovvero: AUTOMAZIONE

Forse escludendo il fatiscente mondo dei gestionali Zucchetti non c'è ambito dell'IT che non sia pervaso dal misticismo per l'automazione, bisogna automatizzare tutto, anche cose che si fanno una tantum e non si ripeteranno mai in futuro, o cose che ad andar bene si fanno una volta l'anno.

Perchè?

Perchè è la supercazzola del momento.

L'automazione non è il male assoluto, è solo l'ennesimo strumento usato male e usato a prescindere dappertutto, anche dove non c'è la necessità.

In alcuni casi è utile, in altri indispensabile, in tanti altri ancora (moltissimi nel nostro piccolo paese che consuma IT ma praticamente non ne produce) è solo l'ennesimo "strumento utilissimo per risolvere un problema che non ha quasi nessuno" e complica solo le cose.

Dovrebbero testare a mano decine di applicazioni che hanno diversi aggiornamenti al giorno? Su più sistemi operativi e su hardware differenti?

Chi scrive questo commento non si rende conto della quantità di lavoro che c'è dietro.

Falcon è uno strumento di sicurezza che fa rapid threat containment, gli aggiornamenti devono arrivare nel più breve tempo possibile.


Il problema da risolvere è quello di validazione, non i test automatizzati.

[Tasslehoff]

Originariamente inviato da mihos

Dovrebbero testare a mano decine di applicazioni che hanno diversi aggiornamenti al giorno? Su più sistemi operativi e su hardware differenti?

Chi scrive questo commento non si rende conto della quantità di lavoro che c'è dietro.

Falcon è uno strumento di sicurezza che fa rapid threat containment, gli aggiornamenti devono arrivare nel più breve tempo possibile.

Il problema da risolvere è quello di validazione, non i test automatizzati.

Perdonami ma la validazione secondo te come la fanno?

Ci sarà qualche diavolo di pipeline su qualche servizio di CD/CI che automatizza questo processo.

Che tu la guardi dal punto di vista del patch management o della validazione delle patch sempre di automazione si tratta, e forse certi processi non dovrebbero essere automatizzati per loro stessa natura e per la loro estrema delicatezza.

Non buttiamola sul "allora torna all'età della pietra", l'ho scritto io stesso, l'automazione è uno strumento e come tutti gli strumenti va usato bene, non va usato a prescindere solo perchè è diventato una moda o perchè così permette di risparmiare a discapito della qualità del servizio.

Originariamente inviato da k0nt3

Capisco perchè i talenti scappano all'estero, in Italia non c'è proprio la mentalità adeguata per fare le cose come si deve l'importante è costare poco e impiegarci di meno giusto?

Guarda che in questo caso è proprio l'automazione di certi processi ad aver provocato un casino colossale, e questa automazione secondo te perchè è stata introdotta?

Anzitutto per risparmiare e impiegare meno tempo (leggasi per ottenere il massimo profitto possibile a discapito della qualità), perchè se la validazione della patch è fatta da un processo automatizzato invece che da dei tester veri, allora non devi pagare dei tester, metti in cottura la tua bella pipeline e la fai girare in automatico dopo ogni commit.

Semplifico chiaramente, ma la sostanza sappiamo bene che è quella.

[Shirov]

Persino noi che non abbiamo di certo i mezzi di Crowdstrike per ogni minima modifica effettuiamo test reali su macchine in produzione e ci accordiamo con un gruppo di clienti-cavia per provarli sulle loro macchine dopo che le nuove versioni hanno passato i test sulle nostre....

[cignox1]

--la società adotterà anche un meccanismo di distribuzione degli aggiornamenti a scaglioni

Non capisco come sia possibile sviluppare software che gireranno su sistemi critici a livello kernel, e distribuire qualsiasi cosa su 8 milioni di macchine contemporaneamente.

A parte quello, non vorrei essere nel tipo a cui appartiene la riga di codice fallata. Quando viene fatto un git blame da noi per un problema, ho sempre i sudori freddi XD

[destroyer85]

Fate anche dei bei fuzz test a mano, sai che spasso!
L'automazione non è il problema, il problema è il tipo di test che fai in quei test automatici.
A quanto pare un semplice test di deploy, facilmente automatizzabile e ripetibile in poco su tutti i sistemi operativi supportati, non è stato fatto. Anche con i test fatti a mano se non segui un protocollo di test ben pensato dei test non te ne fai molto.
Ma per la mentalità da bumer che pervade ormai ogni cosa no, fatto a mano è meglio, naturale è meglio, tradizionale è meglio, non aggiornare è meglio...

[Ago72]

Originariamente inviato da destroyer85

Fate anche dei bei fuzz test a mano, sai che spasso!
L'automazione non è il problema, il problema è il tipo di test che fai in quei test automatici.
A quanto pare un semplice test di deploy, facilmente automatizzabile e ripetibile in poco su tutti i sistemi operativi supportati, non è stato fatto. Anche con i test fatti a mano se non segui un protocollo di test ben pensato dei test non te ne fai molto.
Ma per la mentalità da bumer che pervade ormai ogni cosa no, fatto a mano è meglio, naturale è meglio, tradizionale è meglio, non aggiornare è meglio...

Esattamente, Ho sempre affrontato il problema in modo indiretto. Pensare di testare a mano tutte le possibili combinazioni, Sarebbe un lavoro Molto lungo. Certo poi ci si potrebbe lamentare che non rilasciano le patch in tempo, anche quando si sa di un bug.

[v10_star]

dai, che con il buono di 10$ di uber eats si sistema tutto!

[futu|2e]

Originariamente inviato da Tasslehoff

Forse escludendo il fatiscente mondo dei gestionali Zucchetti.

Boia cosa hai tirato fuori, la peggior web application che abbia mai visto.

[Pascas]

Originariamente inviato da destroyer85

Ma per la mentalità da bumer che pervade ormai ogni cosa no, fatto a mano è meglio, naturale è meglio, tradizionale è meglio, non aggiornare è meglio...

quella è la mentalità dei conservatori

[k0nt3]

Originariamente inviato da Tasslehoff

Guarda che in questo caso è proprio l'automazione di certi processi ad aver provocato un casino colossale, e questa automazione secondo te perchè è stata introdotta?

Anzitutto per risparmiare e impiegare meno tempo (leggasi per ottenere il massimo profitto possibile a discapito della qualità), perchè se la validazione della patch è fatta da un processo automatizzato invece che da dei tester veri, allora non devi pagare dei tester, metti in cottura la tua bella pipeline e la fai girare in automatico dopo ogni commit.

Semplifico chiaramente, ma la sostanza sappiamo bene che è quella.

L'automazione non si crea da sola e non si fa in 5 minuti, serve un discreto investimento in termini di tempo e denaro per implementare una pipeline CI/CD con tutti i crismi.
Solo con il tempo si rientra nell'investimento, ma c'è comunque bisogno di manutenzione costante e un team con la giusta mentalità perchè il tutto continui a funzionare bene.
Cosa succede ai tuoi cari test manuali quando il test viene eseguito da Tizio anzichè da Caio? Darà lo stesso risultato? E se il tester con la maggiore esperienza si licenzia o va in pensione, il team potrà garantire la stessa qualità dei test? Quanto tempo si perde a trasferire informazioni dal team di sviluppo al team di tester?
Non è una moda, si chiama "lungimiranza".
Se poi in Crowdstrike si dimenticano di implementare i casi di test necessari, significa soltanto che sono stati approssimativi.
E' già successo in passato con un aggiornamento su Debian, alla fine si è scoperto che non avevano aggiunto quella distribuzione nella matrice di test. Eppure era nella lista di distribuzioni ufficialmente supportate!

Originariamente inviato da cignox1

A parte quello, non vorrei essere nel tipo a cui appartiene la riga di codice fallata. Quando viene fatto un git blame da noi per un problema, ho sempre i sudori freddi XD

In un team di sviluppo serio questo non dovrebbe essere un problema. Esiste una cosa chiamata "blameless culture", ovvero se succede un disastro non è mai responsabilità di una singola persona.
Dietro ogni errore umano c'è una mancanza di processo (e.g. mancanza di revisione delle modifiche, procedure di rilascio, documentazione, ecc..).

[DjLode]

Originariamente inviato da v10_star

dai, che con il buono di 10$ di uber eats si sistema tutto!

Che in alcuni casi viene revocato/annullato. Non si può commentare...

[Mazzulatore]

Originariamente inviato da Tasslehoff

Un test a mano? Non automatizzato?

Ma siete impazziti? Questo violerebbe la supercazzola numero due del momento (la numero uno ovviamente è IA, quella è francamente impossibile da spodestare), ovvero: AUTOMAZIONE

Forse escludendo il fatiscente mondo dei gestionali Zucchetti non c'è ambito dell'IT che non sia pervaso dal misticismo per l'automazione, bisogna automatizzare tutto, anche cose che si fanno una tantum e non si ripeteranno mai in futuro, o cose che ad andar bene si fanno una volta l'anno.

Perchè?

Perchè è la supercazzola del momento.

L'automazione non è il male assoluto, è solo l'ennesimo strumento usato male e usato a prescindere dappertutto, anche dove non c'è la necessità.

In alcuni casi è utile, in altri indispensabile, in tanti altri ancora (moltissimi nel nostro piccolo paese che consuma IT ma praticamente non ne produce) è solo l'ennesimo "strumento utilissimo per risolvere un problema che non ha quasi nessuno" e complica solo le cose.

Però fa tanto figo, da una parte i manager di pavoneggiano (pur non avendo capito a cosa serva nel 99% dei casi), dall'altro anche i dev si pavoneggiano perchè si sentono padroni di ambiti dove fino ieri non avrebbero mai messo il becco, dove non sanno nulla e su cui capiscono ben poco, e dove sarebbe meglio che non lo mettessero per il bene di tutti (vedasi appunto il caso Crowdstrike).

Magari fosse così.... Prima si parla di IA (ma più frequentemente specificatamente di MACHINE LEARNING), poi BIGDATA (qualunque cosa voglia dire tanto vendono anche previsioni di terremoti e l'origine dell'universo fatte grazie ai BIGDATA), poi CLOUD, poi CYBERSECURITY poi AGILE (ma inteso esclusimanente come management), poi DEVOPS (idem cone AGILE) e poi forse qualcuno come te solleva la questione della qualità del software ma dopo la martellata per fixare il problema non è rimasto più tempo e tutti tornano in giacca e cravatta ad occuparsi delle prime 6 supercazzole.

[Ripper89]

Il problema secondario sono le competenze medie del personale che in generale lavora in questo settore aldilà che si chiami Crowstrike o altro.
Il problema PRINCIPALE invece è quella relativa a tutto il resto del pianeta, ovvero la mancanza di sanzioni adeguate in caso di errori.

[Piedone1113]

Originariamente inviato da Ripper89

Il problema secondario sono le competenze medie del personale che in generale lavora in questo settore aldilà che si chiami Crowstrike o altro.
Il problema PRINCIPALE invece è quella relativa a tutto il resto del pianeta, ovvero la mancanza di sanzioni adeguate in caso di errori.

Oltre a pene severissime a chi si ingegna per scrivere malware.
Non è un semplice malfunzionamento del PC se blocchi sale operatorie, torre di controllo, gestione traffico su rotaia ecc.
La verità è che il malware cresce di numero in maniera esponenziale e diventa sempre più difficile e complicato star dietro agli aggiornamenti dei software di sicurezza e delle firme.
Non voglio giustificare l'accaduto, ma ormai tutti pretendono azioni immediate al rilevamento di un nuovo malware ( o meglio tecniche di intrusione)

[WarDuck]

Originariamente inviato da k0nt3

L'automazione non si crea da sola e non si fa in 5 minuti, serve un discreto investimento in termini di tempo e denaro per implementare una pipeline CI/CD con tutti i crismi.
Solo con il tempo si rientra nell'investimento, ma c'è comunque bisogno di manutenzione costante e un team con la giusta mentalità perchè il tutto continui a funzionare bene.
Cosa succede ai tuoi cari test manuali quando il test viene eseguito da Tizio anzichè da Caio? Darà lo stesso risultato? E se il tester con la maggiore esperienza si licenzia o va in pensione, il team potrà garantire la stessa qualità dei test? Quanto tempo si perde a trasferire informazioni dal team di sviluppo al team di tester?
Non è una moda, si chiama "lungimiranza".
Se poi in Crowdstrike si dimenticano di implementare i casi di test necessari, significa soltanto che sono stati approssimativi.
E' già successo in passato con un aggiornamento su Debian, alla fine si è scoperto che non avevano aggiunto quella distribuzione nella matrice di test. Eppure era nella lista di distribuzioni ufficialmente supportate!

In un team di sviluppo serio questo non dovrebbe essere un problema. Esiste una cosa chiamata "blameless culture", ovvero se succede un disastro non è mai responsabilità di una singola persona.
Dietro ogni errore umano c'è una mancanza di processo (e.g. mancanza di revisione delle modifiche, procedure di rilascio, documentazione, ecc..).

In pratica quello che succede tipicamente in Italia nel pubblico: nessuno si prende mai la responsabilità e paga per i suoi errori

[giovanni69]

Originariamente inviato da WarDuck

In pratica quello che succede tipicamente in Italia nel pubblico: nessuno si prende mai la responsabilità e paga per i suoi errori

Ma poi avviene anche la depenalizzazione perchè - si ritiene- che sia l'unico modo percorribile affinchè il dipendente pubblico si metta a decidere di sua competenza senza percepire la spada di Damocle e dunque, diversamente, fermare tutto e burocratizzare ogni questione. Ovvero la logica non è la responsabilità sulla base della formazione e conoscenza del proprio lavoro ma efficienza della P.A. = depenalizzazione.

[k0nt3]

Originariamente inviato da WarDuck

In pratica quello che succede tipicamente in Italia nel pubblico: nessuno si prende mai la responsabilità e paga per i suoi errori

Tu non sbagli mai forse? Se l'errore di un impiegato qualunque può danneggiare una multinazionale, il problema non è che quella persona abbia sbagliato (tutti sbagliano), ma piuttosto che sono mancati i processi che avrebbero dovuto evitare l'errore. I processi non sbagliano a differenza degli esseri umani. Sto parlando di quello che avviene nelle aziende IT serie, lascia stare i paragoni con altri ambiti.

[Ripper89]

Originariamente inviato da Piedone1113

Oltre a pene severissime a chi si ingegna per scrivere malware.
Non è un semplice malfunzionamento del PC se blocchi sale operatorie, torre di controllo, gestione traffico su rotaia ecc.
La verità è che il malware cresce di numero in maniera esponenziale e diventa sempre più difficile e complicato star dietro agli aggiornamenti dei software di sicurezza e delle firme.
Non voglio giustificare l'accaduto, ma ormai tutti pretendono azioni immediate al rilevamento di un nuovo malware ( o meglio tecniche di intrusione)

Non centra nulla se è semplice o meno e non stiamo parlando di malware.
Stiamo parlando della fase di test di un update che NON è stato testato.
Potevo capire se 1 server o 1 pc su 1 milione ne fosse stato afflitto, ma quì è la quasi totalità, il che significa che NESSUNO si è degnato di installarlo su un campionario ( anche ridotto ) di macchine.

Se un dipendente o dirigente non si sente all'altezza lo deve segnalare e dimettersi altrimenti si prende le responsabilità degli errori che commette.
Il motivo per cui accade questo è perchè tanto non gli succede nulla o viene semplicemente degradato o al massimo viene invitato a dimettersi e basta.

Imponigli sanzioni economiche da contratto da pagare, con diversi zeri e vedrai che stanno tutti più attenti a come si muovono.