{"id":29139,"date":"2024-08-01T14:39:43","date_gmt":"2024-08-01T12:39:43","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=29139"},"modified":"2024-08-01T14:39:43","modified_gmt":"2024-08-01T12:39:43","slug":"product-updates-best-practices","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/product-updates-best-practices\/29139\/","title":{"rendered":"Come ridurre al minimo i problemi legati agli aggiornamenti software"},"content":{"rendered":"

Secondo Microsoft, la \u201cschermata blu\u201d causata da un aggiornamento della soluzione di sicurezza CrowdStrike Falcon ha colpito pi\u00f9 di 8,5 milioni di computer in tutto il mondo. Questo incidente \u00e8 costato caro a molte aziende<\/a> e ha sollevato un dibattito su come evitare che situazioni simili si ripetano.<\/p>\n

Prima di tutto, gli errori esistono. \u00c8 impossibile garantire la totale assenza di bug nei sistemi di software complessi. Tuttavia, un processo strutturato per lo sviluppo, il testing e la consegna dei prodotti e dei loro aggiornamenti agli utenti pu\u00f2 ridurre significativamente il rischio di un problema grave. E noi abbiamo messo in atto questo processo da anni.<\/p>\n

Anche noi abbiamo avuto incidenti direttamente collegati agli aggiornamenti dei nostri prodotti. Tuttavia, l\u2019ultima volta che abbiamo avuto un problema di questo tipo su larga scala risale al 2013. Dopo quello spiacevole episodio, abbiamo eseguito un\u2019analisi approfondita delle cause principali, che ha portato a una revisione completa del nostro approccio alla creazione e al testing degli aggiornamenti sia nei prodotti per le aziende che per gli utenti privati. Il sistema che abbiamo costruito si \u00e8 dimostrato molto affidabile: in 11 anni non abbiamo avuto un solo problema della stessa portata.<\/p>\n

Non ci sono segreti sui meccanismi legati al rilascio degli aggiornamenti che abbiamo sviluppato e siamo pronti a condividerli con i colleghi del settore. Senza il libero scambio delle best practice e delle soluzioni sviluppate dalle diverse aziende, il progresso del settore della cybersecurity sar\u00e0 notevolmente penalizzato. Tra i principali meccanismi di salvaguardia del rilascio degli aggiornamenti vi sono i test multilivello, il rollout graduale degli aggiornamenti e il monitoraggio automatico delle anomalie. Oggi ve ne parliamo in dettaglio.<\/p>\n

Testing multilivello<\/p>\n

Esistono due tipi di aggiornamenti per i nostri prodotti: alcuni sono utilizzati per aggiungere nuova logica di rilevamento, altri per modificare le funzionalit\u00e0 di un determinato prodotto. L\u2019aggiunta di nuove funzioni comporta potenzialmente maggiori rischi, ma a volte anche gli aggiornamenti legati alla logica possono causare problemi. Per questo motivo, testiamo attentamente le due tipologie di aggiornamenti in fasi diverse.<\/p>\n

Controllo dei falsi positivi<\/p>\n

Quando creiamo e rilasciamo le regole di rilevamento (sia quelle generate automaticamente che quelle scritte dagli analisti), le testiamo su un ampio database di oggetti legittimi (o \u201cpuliti\u201d) come file, pagine web, modelli di comportamento e cos\u00ec via. In questo modo, possiamo identificare e filtrare i falsi positivi<\/a>. Disponiamo di una raccolta vasta e costantemente aggiornata di oggetti legittimi, sia software che risorse web pulite, su cui vengono testate tutte le regole create.<\/p>\n

Uno dei modi in cui questa raccolta viene alimentata \u00e8 il nostro programma Allowlist<\/a>, che consente agli sviluppatori di software (sia clienti che sviluppano e utilizzano le proprie soluzioni, sia fornitori indipendenti) di fornirci il loro software. Questo riduce il numero di potenziali falsi positivi e il rischio di una classificazione errata del software.<\/p>\n

Altri metodi per ottenere file e metadati sono lo scambio di informazioni con i partner tecnologici, l\u2019utilizzo del nostro portale Threat Intelligence Portal<\/a>, e cos\u00ec via. In totale, il nostro database di oggetti legittimi contiene informazioni su circa 7,2 miliardi di oggetti.<\/p>\n

Testing su macchine virtuali<\/p>\n

Tuttavia, il testing degli aggiornamenti non si limita alla verifica delle raccolte di file. Se non vengono rilevati problemi nella prima fase, tutti i componenti aggiornati vengono sottoposti a test automatici multi-fase su macchine virtuali dotate di varie configurazioni di prodotti di sicurezza, software e sistemi operativi. Vengono eseguiti varie prove relative ai nostri prodotti e al funzionamento dei meccanismi di sicurezza, nonch\u00e9 l\u2019imitazione di azioni tipiche dell\u2019utente.<\/p>\n

Per quanto riguarda in particolare le situazioni relative ai prodotti, queste includono una scansione del file system, il processo di installazione dell\u2019aggiornamento del prodotto, il riavvio dopo l\u2019aggiornamento e cos\u00ec via. In questo modo ci assicuriamo che il prodotto funzioni normalmente dopo l\u2019aggiornamento, che non si blocchi e che non influisca sulla stabilit\u00e0 del sistema. Ogni aggiornamento viene sottoposto a questo controllo.<\/p>\n

I controlli a livello utente simulano il tipico comportamento umano su un computer: aprire un browser, visitare una pagina web, scaricare un file, avviare un programma. Questa verifica ci permette di assicurarci che il prodotto non abbia un impatto negativo sulle prestazioni, sulla velocit\u00e0 di lavoro o sulla stabilit\u00e0 del computer.<\/p>\n

Inoltre, gli aggiornamenti vengono automaticamente testati per verificarne la compatibilit\u00e0 con i software industriali (ad esempio, i sistemi SCADA). Qualsiasi impatto negativo sulle soluzioni relativo a questo ambito pu\u00f2 comportare un arresto inammissibile dei processi produttivi e un potenziale danno finanziario.<\/p>\n

Controllo qualit\u00e0<\/p>\n

Oltre ai controlli di cui sopra, disponiamo anche di un team di controllo qualit\u00e0 separato. Non viene consegnata ai nostri clienti una sola release di aggiornamento di un prodotto senza che i nostri esperti ne abbiano confermato la disponibilit\u00e0. Inoltre, se necessario, adatta e migliora costantemente i processi di verifica e monitora l\u2019emergere di possibili rischi operativi.<\/p>\n

Rilascio graduale degli aggiornamenti delle tecnologie di protezione<\/p>\n

Naturalmente, siamo realisti e ammettiamo che questo intero sistema di controlli a multilivello potrebbe non essere comunque sufficiente. Ad esempio, alcuni software di terze parti saranno aggiornati contemporaneamente ai nostri e questo potrebbe causare un conflitto imprevisto. In generale, \u00e8 impossibile prevedere tutte le combinazioni di configurazioni di programmi e sistemi diversi. Per questo motivo, dopo che un aggiornamento che influisce sulla funzionalit\u00e0 delle soluzioni di sicurezza \u00e8 pronto e approvato, non viene inviato a tutti i computer dei nostri utenti in un colpo solo. Gli aggiornamenti vengono piuttosto rilasciati in pi\u00f9 fasi.<\/p>\n

Prima di essere pubblicato sui server di aggiornamento pubblici, un aggiornamento viene sottoposto a test preliminari sui computer della nostra rete. Se non vengono rilevati problemi, l\u2019aggiornamento viene prima ricevuto da un numero molto ristretto di utenti selezionati a caso. Se non si riscontrano problemi o guasti, il numero di computer che ricevono l\u2019aggiornamento aumenta in modo graduale e ad intervalli regolari, e cos\u00ec via fino a quando l\u2019aggiornamento \u00e8 disponibile per tutti gli utenti.<\/p>\n

Monitoraggio automatico delle anomalie<\/p>\n

Cosa succede se un aggiornamento causa problemi? Monitoriamo il comportamento delle soluzioni aggiornate utilizzando i dati anonimi trasmessi in maniera volontaria attraverso il nostro KSN e interrompiamo immediatamente la distribuzione degli aggiornamenti se qualcosa va storto.<\/p>\n

Ma soprattutto, grazie alla combinazione del monitoraggio automatico delle anomalie e del rilascio graduale degli aggiornamenti, un errore colpirebbe solo un numero molto ridotto di computer: decine, non milioni o addirittura migliaia.<\/p>\n

Verifica degli aggiornamenti lato client<\/p>\n

Offriamo la possibilit\u00e0 di verificare nuovamente gli aggiornamenti ricevuti, ma questa volta sul lato client attraverso la console di gestione Kaspersky Security Center.<\/p>\n

Gli amministratori di sistema del cliente possono creare un gruppo di test di computer isolati (o macchine virtuali) con la configurazione e il set di software pi\u00f9 comune per la rete dell\u2019 azienda, e quindi creare un\u2019attivit\u00e0 di controllo degli aggiornamenti, specificando questo gruppo di test come target. In questo caso tutti gli aggiornamenti in arrivo vengono prima installati solo sulle macchine di prova, testati in azione e solo dopo il test vengono distribuiti sull\u2019intera rete aziendale. Potete trovare maggiori informazioni su come impostare questo tipo di controllo sul nostro sito web nella sezione dedicata all\u2019assistenza tecnica.<\/a><\/p>\n

Analizziamo a fondo ogni singolo problema legato agli aggiornamenti del software che pu\u00f2 presentarsi (compresi quelli identificati nei test preliminari), cerchiamo di capire le ragioni del loro verificarsi e poi adottiamo misure per garantire che non si verifichino pi\u00f9. Inoltre, abbiamo implementato la pratica di identificare e valutare proattivamente i rischi di possibili problemi, affrontandoli sistematicamente. Grazie a questa prassi, abbiamo creato un sistema multi-livello che ci permette di ridurre in modo significativo il rischio che emergano nuovi problemi.<\/p>\n

Naturalmente, in un solo post del blog \u00e8 impossibile illustrarvi tutte le sfumature del nostro sistema multi-livello per il controllo degli aggiornamenti dei prodotti. Tuttavia, se questo argomento suscita interesse nel settore, siamo pronti a continuare a condividere ulteriori informazioni. Solo la cooperazione aperta tra tutti gli operatori del settore della information security pu\u00f2 creare una barriera efficace alle azioni dei criminali informatici.<\/p>\n","protected":false},"excerpt":{"rendered":"

Oggi vi parliamo delle nostro modus operandi riguardante il lancio di nuovi prodotti e gli aggiornamenti di quelli esistenti, metodo che riduce il rischio di incidenti su larga scala.<\/p>\n","protected":false},"author":2706,"featured_media":29140,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[74,941,3840,3841],"class_list":{"0":"post-29139","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-aggiornamenti","11":"tag-prodotti","12":"tag-strategie","13":"tag-testing"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/product-updates-best-practices\/29139\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/product-updates-best-practices\/27781\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/product-updates-best-practices\/23111\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/product-updates-best-practices\/30463\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/product-updates-best-practices\/27991\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/product-updates-best-practices\/27580\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/product-updates-best-practices\/30273\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/product-updates-best-practices\/37988\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/product-updates-best-practices\/51817\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/product-updates-best-practices\/22096\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/product-updates-best-practices\/22851\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/product-updates-best-practices\/31523\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/product-updates-best-practices\/28132\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/product-updates-best-practices\/33924\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/product-updates-best-practices\/33589\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/strategie\/","name":"strategie"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/29139","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2706"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=29139"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/29139\/revisions"}],"predecessor-version":[{"id":29141,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/29139\/revisions\/29141"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/29140"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=29139"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=29139"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=29139"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}