{"id":3224,"date":"2014-03-28T16:03:45","date_gmt":"2014-03-28T16:03:45","guid":{"rendered":"http:\/\/kasperskydaily.com\/italy\/?p=3224"},"modified":"2020-02-26T17:22:45","modified_gmt":"2020-02-26T15:22:45","slug":"kaspersky-anti-virus-6","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/kaspersky-anti-virus-6\/3224\/","title":{"rendered":"La regola del “Sei”"},"content":{"rendered":"

Una delle pi\u00f9 importanti pietre miliari che hanno contribuito a far diventare Kaspersky Lab uno dei principali rappresentanti dell\u2019industria della sicurezza informatica \u00e8 stata la release della \u201callora\u201d rivoluzionaria versione di Kaspersky Anti-Virus 6.0<\/a>. Ufficialmente lanciato nel 2006, il prodotto ha riscosso un grande successo nel mercato internazionale degli antivirus, ponendo le basi della sua leadership per gli anni a venire. Pu\u00f2 apparire poco modesto da parte nostra considerare i nostri prodotti le migliori soluzioni antivirus<\/a> sul mercato, ma non siamo noi a dirlo, bens\u00ec numerose riviste e diversi studi di mercato indipendenti<\/a>.<\/p>\n

\"KASPERSKY\"<\/a><\/p>\n

Il cammino che ci ha portato al successo \u00e8 stato lungo, pieno di curve e difficolt\u00e0 \u2013 magari un giorno qualche sceneggiatore di Hollywood prender\u00e0 in considerazione la nostra storia per farci qualcosa. Per il momento, cercheremo di raccontarvi le tappe del nostro successo con l\u2019aiuto delle foto, degli appunti e dei ricordi del nostro originale team di sviluppatori (a cui spesso ci riferiremo come dev team o dev team di \u201cSei\u201d<\/i>). Speriamo che questa storia servir\u00e0 da esempio per i giovani sviluppatori di oggi, desiderosi di creare nuove app e servizi, dando loro la stessa forza e\u00a0 voglia di diventare i migliori che avevano i creatori di \u201cSei\u201d.<\/p>\n

\n
\n
\"\"<\/dt>\n
\n

\u00a0Una vecchia foto scattata il giorno della release tecnica della versione 6<\/i><\/p>\n<\/dd>\n<\/dl>\n<\/div>\n

2003: un anno difficile
\n<\/b><\/h2>\n

Il successo di \u201cSei\u201d \u00e8 dovuto in parte alla catastrofe della versione precedente. Infatti, la quinta versione non ha mai visto la luce del giorno.<\/p>\n

Per capire l\u2019essenza della catastrofe, dobbiamo viaggiare indietro nel tempo, nel 2002: Windows XP aveva appena battuto ogni record, i CPU erano in grado di\u00a0 raggiungere 1 GHz di segnali di clock e la relativamente giovane industria antivirus aveva appena iniziato a scoprire tutta una serie di nuove minacce. Tutte le aziende antivirus stavano ansiosamente ampliando le capacit\u00e0 dei loro prodotti: al tempo, una soluzione competitiva doveva includere un firewall, un sistema di monitorizzazione costante dei file in esecuzione e una dozzina di altre funzionalit\u00e0.<\/p>\n

Con un potente sistema di scansione costruito nel 1990, il developer team<\/i> di Kaspersky Lab si reso conto che includere nella soluzione antivirus altre funzionalit\u00e0 lo avrebbe inevitabilmente rallentato \u2013 persino l\u2019allora esistente versione 4.0 era stata condannata dall\u2019utente (l\u2019accusa \u201cl\u2019AV Kaspersky Lab \u00e8 lento\u201d faceva parte del \u201cfolklore informatico\u201d dell\u2019epoca). Per questa ragione abbiamo dedicato molta attenzione al processo di sviluppo della nuova V 5.0: venne assunto un nuovo Chied Technology Officer, impiegata una nuova framework<\/i> di sviluppo e scelta una nuova architettura antivirus.<\/p>\n

L\u2019azienda impieg\u00f2 tutte le sue risorse per supportare il progetto. E dopo un anno si era giunti alla conclusione che tutte queste nuove regole di sviluppo non sarebbero state sufficienti per garantire la creazione di un prodotto competitivo. Il risultato fu un sistema che imitava le app aziendali client-server<\/i> (era la scelta dell\u2019architettura fatta dal CTO) e che non era in grado di rispondere ai parametri dal mercato AV dell\u2019epoca. Era lento e pesante, una volta eseguiti i test, il numero dei bug non diminuiva \u2013 anzi, aumentava.<\/p>\n

\u201cHo iniziato a chiedere alle persone, ai veterani della nostra azienda, cosa pensassero. Dissero che \u00e8 colpa dell\u2019architettura. \u00c8 come un castello di carte: toccandone una, si potrebbe finire col farle cadere tutte\u201d, afferma Eugene Kaspersky. Ecco perch\u00e9 non aveva senso continuare il progetto cos\u00ec com\u2019era. Doveva essere demolito e ripensato daccapo.<\/p>\n

Ce la faremo!<\/h2>\n

Il team degli sviluppatori di Kaspersky Lab si separ\u00f2 i due gruppi: uno si occupava della riparazione del prodotto, indipendentemente dall\u2019architettura scelta, forse imprudentemente, e un altro della trasformazione della versione precedente, la V 4.0, in una pi\u00f9 idonea.<\/p>\n

Allo stesso tempo, un gruppo di 4 persone decise di creare un prodotto nuovo, completamente diverso, che rispondesse non solo ai parametri del mercato, ma che possa durare nel tempo. L\u2019obiettivo fissato dal dev team<\/i> di \u201cSei\u201d era facile da spiegare, ma difficile da raggiungere. La nuova versione doveva essere a prova di virus, minacce e furti di dati di sistema; doveva essere veloce, agile, trasparente e\u2026 beh, gradevole alla vista.<\/p>\n

\u201cVolevamo creare il miglior prodotto esistente\u201d ricordano ora gli sviluppatori della versione \u201cSei\u201d. Si trattava di un team ridotto, ma con un compito enorme: questa era anche la percezione degli altri 200 membri dello staff. Proprio per questo il team doveva essere positivo: i fondatori dell\u2019azienda, Eugene Kaspersky e Alexey De-Monderik, stavano al tempo cercando alternative per nuove architetture e stavano per scoprire che un\u2019alternativa c\u2019era \u2013 e sarebbe stata scoperta da niente po po\u2019 di meno che lo stesso team di Kaspersky Lab.<\/p>\n

Aiuto da Praga<\/h2>\n

\"\"<\/p>\n

Bisogna dire che i due nuclei core<\/i> dell\u2019antivirus (quelli che vengono chiamati in inglese engine<\/i>) operavano insieme alla versione 4.0. La verifica dei file veniva eseguita dal vecchio, ma efficiente, V 3.0 (apprezzato da diverse compagnie internazionali, da G-Data a F-Secure), sviluppato nel lontano 1996. Il nuovo e difficile compito, quello di filtrare il traffico web, fu gestito e concepito nel corso del brainstorming di Praga, nel 1998.<\/p>\n

Il sistema (engine<\/i>) sviluppato venne chiamato \u201cPraga\u201d, nonostante fosse stato sviluppato a Mosca da Andrey Doukhvalov, che non partecip\u00f2 al brainstorming tenutosi nella capitale della Repubblica Ceca. Le idee principali, comunque, furono concepite a Praga, e Andrey si un\u00ec all\u2019azienda per mettere a punto e implementare le idee emerse a Praga.<\/p>\n

Praga doveva diventare il nucleo dell\u2019anti-virus; gli obiettivi erano cos\u00ec ambiziosi che la flessibilit\u00e0 e l\u2019ingegno del nuovo sistema che venne sviluppato furono sufficienti per dare potenza anche ai sistemi pi\u00f9 complicati. La questione (se fosse possibile implementare l\u2019intero prodotto basandolo su Praga oppure no)\u00a0 pesava fortemente su Eugene Kaspersky, cos\u00ec come emerse dal suo discorso agli sviluppatori.<\/p>\n

Inizialmente fu un piccolo team a lavorare sul trial, scrivendo le prime righe di codice: questi programmatori sarebbero diventati in seguito i programmatori di \u201cSei\u201d.<\/div>\n

\u201cUna volta ho chiesto a Victor Matyushenko come stesse funzionando Praga all\u2019interno del prodotto e lui rispose \u2018Solido come una roccia!\u2019. Si trattava di un momento critico, il momento della fatidica Domanda (con la D maiuscola). Raggiunsi la stanza dove Graf [De-Monderik] e Petrovich [Doukhvalov] stavano lavorando e feci loro la Domanda: \u2018Perch\u00e9 non basiamo interamente il prodotto su Praga?\u2019 Graf farfugli\u00f2 qualcosa che assomigliava a \u2018Impossibile. Praga non \u00e8 stato pensato per questo\u201d, ma Petrovich esit\u00f2. Il giorno dopo arriv\u00f2 in ufficio con una pila di fogli e mi disse \u2018Ho pensato a qualche caso d\u2019uso di Praga\u2019. Graf lo guard\u00f2 e disse \u2018Dobbiamo parlare\u2019. Poi, dopo la chiacchierata, ci riunimmo di nuovo tutti insieme e mi confermarono che ne valeva la pena.\u201d<\/p>\n

Inizialmente fu un piccolo team a lavorare sul trial, scrivendo le prime righe di codice: questi programmatori sarebbero diventati in seguito i programmatori di \u201cSei\u201d.<\/p>\n

\u201cIniziammo a guardarci attorno per trovare persone creative che potessero dare il loro contributo, e finimmo col formare un grande team\u201d, ricorda De-Monderik. \u201cPrendi il programmatore Pavel Mezhuev, era un novellino \u2013 anche se brillante. Poi c\u2019era Mike Pavlyuschik con cui abbiamo lavorato per molto tempo. Era capace di generare idee e concetti pronti all\u2019uso in pochi secondi. Credo fosse uno dei creatori con pi\u00f9 talento\u201d.<\/p>\n

\"\"<\/p>\n

Dopo due mesi di aperte discussioni e sperimentazioni di codici, decidemmo che il progetto doveva prendere la forma di una soluzione commerciale. Ora avevamo bisogno di un project manager<\/i>.<\/p>\n

\u201cVi ricordate di Nikolay Grebennikov, quello dell\u2019ufficio accanto? Legge molto, \u00e8 giovane e nuovo nell\u2019azienda. Andiamo a parlare con lui!\u201d racconta Andrey Doukhvalov, ricordandosi di una conversazione tenuta con De-Monderik. Andrey Sobko, driver software engineer<\/i>, si sarebbe presto \u201cunito alla festa\u201d.<\/p>\n

Cos\u2019 \u00e8 \u201cPraga\u201d<\/h2>\n

Questa parte susciter\u00e0 soprattutto l\u2019interesse dei software engineer<\/i>. Il resto dei lettori, se vuole, la pu\u00f2 saltare.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

All\u2019inizio degli anni novanta, quando l\u2019industria antivirus stava emergendo, c\u2019erano virus che non era possibile individuare attraverso le normali signature. Per esempio, un virus polimorfo che per ogni infezione crittografava il suo codice in diverse forme, non era identificabile con l\u2019approccio delle signature (signature approach<\/i>). Nella misura in cui i software si facevano pi\u00f9 complessi, in un mondo in cui Internet stava entrando sempre di pi\u00f9 nelle vite di tutte le persone e gli scrittori di malware, dal puro divertimento stavano iniziando a prestare i propri servigi al mercato criminale, anche i malware iniziavano a diventare sempre pi\u00f9 sofisticati e multiforme. Persino con un sistema che incorpori capacit\u00e0 aggiuntive all\u2019algoritmo di individuazione basato su signature (signature-based detect algorithm<\/i>), come il caso dei prodotti Kaspersky Lab, gli sviluppatori si videro obbligati ad aggiornare costantemente ogni antivirus, non solo i database delle signature, alla ricerca di malware che utilizzassero nuove regole. Tutto questo rallentava il tempo di reazione dei nuovi virus e il successo di Kaspersky Lab arriv\u00f2 dopo essere stata la prima azienda a curare il terribile virus CIH\u00a0 (Chernobyl) dimostrando che ridurre il tempo di reazione contava davvero.<\/p>\n

Con questo in mente, nel 1998, Eugene Kaspersky sugger\u00ec ai colleghi che era giunto il momento di iniziare a lavorare su di un nuovo sistema anti-virus. Dove voleva arrivare?<\/p>\n

\u201cL\u2019azienda era a corto di denaro,\u201d afferm\u00f2 l\u2019attuale CEO \u201cdovevamo lasciare la citt\u00e0 e trovare un posto economico fuori\u00a0 Mosca dove poter lavorare con tranquillit\u00e0, lontano dal rumore e dal trambusto. Il posto doveva essere interamente disconnesso; non c\u2019era nemmeno la Wi-Fi\u00a0 all\u2019epoca. Il posto pi\u00f9 economico risult\u00f2 essere una capitale europea, Praga.\u201d<\/p>\n

Dopo un brainstorming sulla nuova versione del sistema dell\u2019antivirus, il team di Kaspersky Lab raggiunse la conclusione che un object-oriented approach<\/i> (approccio \u201corientato all\u2019oggetto\u201d) era la migliore soluzione per il sistema. Con questo si intendeva che ogni file o oggetto analizzato doveva essere dissezionato in base alla sua struttura, e gli oggetti al suo interno dovevano essere individuati, analizzati e controllati. La gestione degli oggetti (object management<\/i>), nella sua interezza, doveva essere eseguita in run-time<\/i>.<\/p>\n

Tutti gli ambienti di oggetti esistenti venivano discussi e rifiutati perch\u00e9 inflessibili, lenti o divoravano la memoria. Nel corso della discussione, emerse quindi un\u2019idea: sviluppare un proprio ambiente che potesse includere capacit\u00e0 di gestione della memoria e altre procedure di servizio, che potesse dare all\u2019antivirus la capacit\u00e0 di esaminare e analizzare un potenziale codice malware in un modo veloce ed efficace.<\/p>\n

L\u2019idea complessiva era nata a Praga da De-Monderik e Andrey Krykov ed era supportata dalle prime righe di codice create da Doukhvalov e Kryukov.<\/p>\n

In seguito, per circa un anno, fu soprattutto Doukhvalov a continuare a lavorare su Praga \u2013 questa \u00e8 la ragione per cui era stato assunto, dopo tutto. Avendo un architetto esperto, Doukhvalov assicur\u00f2 che Praga sarebbe stato flessibile, scalabile e facile da utilizzare in un prodotto, senza nessuna limitazione a livello di architettura. Alla fine, l\u2019obiettivo era costruire una soluzione multipiattaforma.<\/p>\n

Era impegnativo eseguire il debug sulla gerarchia degli oggetti, ma un sistema a scambio di messaggi tra oggetti adeguato e un\u2019interfaccia di programmazione minimalista rese Praga un\u2019architettura integrata da usare on-demand<\/em>, dove applicabile.<\/p>\n

\u201cEra pensata per un c<\/i>omponent approach<\/i> (approccio di tipo componente)\u201d, afferma Doukhvalov orgoglioso. \u201cQuesto significa che un componente potrebbe essere aggiunto a un programma esistente. Il sistema era aperto, con l\u2019opportunit\u00e0 di aggiungere elementi e cambiare le regole di comportamento\u201d.<\/p>\n

Un\u2019architettura che si basa sul componente, compatta e che non consuma troppe risorse, era la base per applicare a KAV 6.0 una serie di nuove tecnologie. Erano facilmente implementabili. Inoltre, dopo che Praga venne leggermente modificato per fungere da base per l\u2019intero progetto \u2013 quindi non solo come engine<\/i> per l\u2019antivirus \u2013 Pavel Mezhuev contribu\u00ec a rifinire la sua architettura:<\/p>\n

\u201cImplementammo una soluzione di architettura, utilizzando un modello di business logic separato e un\u2019interfaccia. Inoltre, Doukhvalov and Mezhuev crearono un task manager in grado di controllare ogni singolo processo all\u2019interno del prodotto e il processo di reciprocit\u00e0 era molto semplice\u201d constata Nikolay Grebennikov, project manager di KAV 6.0.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

Il principio di \u201cSei\u201d<\/strong><\/h3>\n

Considerando il trial e la fase di sviluppo iniziale, entrambi gestiti da un gruppo di persone ridotto, divenne immediatamente chiaro che i mostruosi approcci di sviluppo del nuovo progetto non avrebbero funzionato con il team. Di conseguenza, venne implementato un approccio simile a SCRUM: gli sviluppatori si sarebbero seduti in un open space<\/i>, interagendo simultaneamente tra di loro, cos\u00ec da poter rispondere prontamente a tutti gli aspetti del processo di sviluppo. Questo fu il modo in cu il dev team<\/i> di \u201cSei\u201d inizi\u00f2 a ingranare.<\/p>\n

Una piccola parentesi: SCRUM<\/b><\/p>\n

SCRUM \u00e8 un metodo di project management<\/i> per la creazione di ambienti con metodologia agile (per \u201cmetodologia agile\u201d si intende un particolare metodo per lo sviluppo del software). SCRUM si basa sul principio che il cliente (l\u2019utente) non sappia necessariamente di cosa ha bisogno. Ci\u00f2 significa che il processo di sviluppo \u00e8 caratterizzato dalla presenza di numerosi cicli sequenziali: costruzione \u2013 dimostrazione \u2013 analisi del feedback \u2013 aggiornamento della versione.<\/p>\n

Tuttavia, noi ristrutturammo completamente la distribuzione dei ruoli del metodo SCRUM. Eugene Kaspersky defin\u00ec 6 ruoli:<\/p>\n

Architetto<\/b><\/p>\n

Si tratta di una persona, attivamente coinvolta nel processo di creazione dei codici, che sa quello che deve costruire e come.<\/p>\n

Technical designer<\/b><\/i><\/p>\n

Non c\u2019\u00e8 nessuna definizione illuminante per questo ruolo; tra i compiti del technical designer<\/i> vi \u00e8 assicurarsi che le soluzioni prendano vita e, forse l\u2019aspetto pi\u00f9 importante, sapere come NON si devono fare le cose.<\/p>\n

Inventore<\/b><\/p>\n

L\u2019inventore applica soluzioni non convenzionali alla risoluzione dei problemi. Nel caso di \u201cSei\u201d, i problemi erano moltissimi. La soluzione doveva offrire il pi\u00f9 alto livello di protezione e consumare il minimo della risorse del computer.<\/p>\n

Project Manager\u00a0 <\/i><\/b><\/i><\/p>\n

Il ruolo del project manager<\/i>, in relazione al metodo SCRUM, non ha bisogno di grandi spiegazioni. Controlla le risorse umane e le scadenze, ma non \u00e8 un leader diretto. Non comanda i programmatori su quello che si deve fare, ma li motiva a condurre loro stessi il lavoro.<\/p>\n

\u201cIl team era piccolo; all\u2019inizio non avevamo nemmeno un responsabile\u201d afferma Doukhvalov. \u201cIl manager pianificava, organizzava e si occupava del reporting<\/i>, ma le decisioni si prendevano in modo collettivo.\u201d<\/p>\n

Marketing manager<\/b><\/i><\/p>\n

Il prodotto viene creato per i clienti, non per il team di sviluppatori. \u00c8 fondamentale farsi un\u2019idea delle aspettative degli utenti, del loro giudizio sul prodotto e del modo in cui lo useranno. Mentre i principi operativi vengono definiti da coloro che comprendono la natura dell\u2019anti-virus, per quanto riguarda alcuni aspetti minori, come le impostazioni, i messaggi o l\u2019UI (l\u2019interfaccia utente) \u00e8 bene prendere in considerazione le opinioni degli utenti.<\/p>\n

Psicologo<\/b><\/p>\n

Lavorare sotto pressione, dormire poco, conflitti di gruppo, instabilit\u00e0: qualcuno deve assicurarsi che l\u2019ambiente di lavoro sia amichevole e produttivo. Questo ruolo venne assegnato allo stesso Eugene Kaspersky a cui spettava il compito di aiutare i suoi collaboratori, a gestire le risorse del team e a proteggerlo dalle influenze esterne.<\/p>\n

Ma c\u2019\u00e8 un altro ruolo che \u00e8 di vitale importanza per i progetti SCRUM: \u00e8 lo \u201cscriba\u201d, colui che prende appunti sul processo. Tuttavia questa posizione non era occupata da nessuno, e ci\u00f2 costitu\u00ec un problema.<\/p>\n

\u201cDavvero, non sappiamo perch\u00e9 abbiamo preso questa decisione solo un anno fa\u201d afferma Kaspersky.<\/p>\n

In base a questo principio, il numero dei ruoli non corrispondevano al numero dei membri del team. Un ruolo poteva essere diviso tra diverse persone, mentre un singolo membro poteva realizzare diversi ruoli.<\/p>\n

\u201cAnche se eravamo organizzati formalmente ognuno con i propri ruoli, in realt\u00e0 eravamo un unico team; per questo talvolta non si poteva tracciare un contorno netto tra i ruoli: in particolare, durante il brainstorming, le persone assumevano ruoli diversi\u201d, confessa Nikolay Grebennikov. \u201cAd esempio, una persona stava programmando, ma al tempo stesso esprimeva il suo punto di vista rispetto al design \u2013\u00a0 e\u00a0 il suo parere veniva preso in grande considerazione. Io, per esempio, come project manager<\/i>, partecipavo anche alla discussione;\u00a0 fu questo approccio a contribuire al nostro successo. Ci preoccupammo per ogni singolo elemento dei nostri progetti.\u201d<\/p>\n

<\/p>\n

<\/p>\n

Secondo De-Monderik, i programmatori erano altamente intercambiabili: \u201cIl 50% delle abilit\u00e0 di ogni membro del team si sovrapponeva a quelle di qualcun\u2019altro. Mike era in grado di programmare driver se Sobko non era presente, gli specialisti dell\u2019interfaccia utente potevano gestire compiti relazionati con l\u2019engine<\/i> e vice versa. Io potevo occuparmi del design al posto di Max Yudanov, e anche Kolya Grebennikov poteva farlo\u201d.<\/p>\n

Nel modello SCRUM, ogni ruolo \u00e8 fondamentale in relazione a ogni specifica fase del progetto. Durante la fase iniziale, l\u2019architettura \u00e8 la figura centrale. L\u2019inventore entra in azione durante la fase centrale del processo di sviluppo, quando vengono create e sviluppate le funzionalit\u00e0. Durante l\u2019ultima fase, la figura chiave \u00e8 il manager, dato che il progetto ora ha un sacco di risorse che richiedono un\u2019ottima gestione per aiutare il team a raggiungere la deadline.<\/p>\n

Alla ricerca della perfezione<\/b><\/p>\n

Dato l\u2019approccio \u201cSCRUM-iesco\u201d e la complessiva \u201cambiziosit\u00e0\u201d del progetto, la versione \u201cSei\u201d non aveva nessuna lista fissa di requisiti. Secondo i requisiti standard, il prodotto doveva contenere le seguenti funzionalit\u00e0:<\/p>\n