Schmidt all'assalto degli sviluppatori

Secondo il guru della sicurezza informatica l?attribuzione di responsabilità è lo strumento che permetterà di rendere le applicazioni più sicure: gli sviluppatori sono avvertiti, chi sbaglia.. paga


Londra – Un errore nella programmazione di un software, rilevante nel settore della sicurezza, dovrebbe tradursi in una responsabilità diretta per lo sviluppatore che quel software ha realizzato. Si potrebbe sintetizzare così il pensiero espresso da Howard Schmidt, guru della sicurezza informatica, dal pulpito dell’ultima SecureLondon 2005 Conference .

Schmidt non sembra pensare all’ideale utopico di un “software senza bug” quanto invece ad un processo di responsabilizzazione di chi produce software. Secondo l’ex advisor per la Sicurezza informatica della Casa Bianca, il problema sarebbe legato alla formazione e in qualche modo anche alla mancanza di talento. “Nello sviluppo software abbiamo bisogno di garanzie personali da parte degli sviluppatori sui codici che implementano”, ha sottolineato Schmidt. In pratica un cambio dei codici di responsabilità stimolerebbe le imprese ad intervenire sul problema. “Recentemente ho incontrato dei professionisti che hanno creato un’applicazione Web legata ad un back-end database tramite SSL . Ebbene, non mancava l’autenticazione, le password e un sistema di criptazione. Quando hanno spedito i dati all’ufficio acquisti l’hanno fatto con un normale file di testo. Questa certamente non era una soluzione end-to-end. Abbiamo bisogno di responsabilità”, ha dichiarato Schmidt.

L’ultima indagine effettuata da Microsoft sull’argomento ha evidenziato che il 64% dei tecnici intervistati ammette tranquillamente di non sentirsi in grado di sviluppare applicazioni sicure. Per Schmidt la soluzione è solo esclusivamente nella formazione, fondamentale per valutare un’assunzione.

“La maggior parte dei corsi universitari riguardano l’usabilità, la scalabilità, la gestione e non la sicurezza. Adesso molte si stanno concentrando sull’assicurazione e la sicurezza delle informazioni ma, tradizionalmente, lo sviluppo delle applicazioni Web è stato misurato in click di mouse – come fare cliccare gli utenti”, ha concluso Schmidt.

Con sorpresa di qualcuno, The British Computer Society si è detta dello stesso avviso di Schmidt, sebbene i suoi esponenti abbiano tenuto a sottolineare come la responsabilità, più che cadere direttamente sugli sviluppatori, debba riguardare le loro aziende.

“Howard ha sicuramente estremizzato la questione dichiarando che gli sviluppatori dovrebbero essere responsabili direttamente, ma la direzione è giusta. Conosco un buon numero di sviluppatori che si sentirebbero a disagio. E’ una responsabilità dell’azienda comunque che le caratteristiche di sicurezza dei loro software siano testate con rigore. Il codice non è statico. Una volta comprato può essere modificato”, ha affermato un rappresentante della British Computer Society.

Allo stesso tempo tutti concordano sul fatto che gli stessi manager e acquirenti dovrebbero accettare un minimo di responsabilità, sufficiente per preoccuparsi di eventuali aggiornamenti o patch da applicare ai software acquistati.

Dario d’Elia

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Anonimo scrive:
    Link interessante
    Spiega nel dettaglio la situazione, e i possibili risvolti futurihttp://radar.oreilly.com/archives/2005/10/your_money_or_your_mysql_1.html
  • Anonimo scrive:
    MA...
    l'antitrust verso Oracle no eh? solo verso zio bill?Alla faccia dell'imparzialità....a me sembra che la cricca Sun-Google-Oracle-cassamortari ex netscape la stiano passano un pò troppo liscia
  • Anonimo scrive:
    Fork di InnoDB.
    E' open source.E' GPL.E' possibile fare un fork di InnoDB e proseguire senza Oracle?
    • Anonimo scrive:
      Re: Fork di InnoDB.
      Me lo auguro....Sono veramente stanco di queste "rapine" operate dai monopolisti del settore (Oracle,IBM).
    • Anonimo scrive:
      Re: Fork di InnoDB.
      Un fork della versione GPL si puo' fare ma tutto cio' che ne uscirebbe sarebbe GPL. Attualmente MySQL AB offre anche una versione a pagamento (che comprende InnoDB) che puoi usare per applicazioni commerciali senza i vincoli della GPL.Dopo il fork non potrebbe piu' farlo, almeno per InnoDB.
      • Anonimo scrive:
        Re: Fork di InnoDB.
        - Scritto da: Anonimo
        Dopo il fork non potrebbe piu' farlo, almeno per
        InnoDB.*Leggi* *meglio* sul sito di MySQL, per piacere, e controlal effettivamente cosa è che vendono, e con quale licenza...
  • Anonimo scrive:
    MySQL AB avrà grossi problemi
    Oracle vuole evidentemente distruggere il mercato di MySQL. Se viene scaricato da Internet, MySQL è sotto GPL, e può essere usato solamente con software GPL. Lo stesso vale per InnoDB.MySQL AB, perà, commercializza una versione a pagamento di MySQL+InnoDB, che può essere utilizzata anche con applicazioni proprietarie. Questo è possibile grazie a un accordo commerciale tra MySQL AB e Innobase OY. Buona parte dei guadagni di MySQL AB viene dalla vendita di licenze. Senza InnoDB, però, MySQL diventa un giocattolo senza transazioni e integrità referenziale, e sicuramente non vale l'acquisto.Che succederà ora? Oracle non ha bisogno di InnoDB, una tecnologia già obsoleta anche nel settore open source (date un'occhiata a http://www.postgresql.org/ per rendervene conto). Non ha neanche bisogno di accordi commerciali, visto quanto fattura. Oracle potrebbe quindi decidere di far morire InnoDB, rendendo inutile MySQL (specie nella versione a pagamento) e distruggendo il mercato di un suo concorrente.MySQL AB ha però stretto un accordo commerciale con SAP (che alcuni mesi fa rese GPL il suo database), e potrebbe decidere di investire maggiormente in questa direzione, con il prodotto MaxDB.Un bel riassunto della situazione in questo articolo:http://jeremy.zawodny.com/blog/archives/005490.html
    • iced scrive:
      Re: MySQL AB avrà grossi problemi
      Non so se davvero MySQL AB avrà problemi. Dopotutto MySQL AB non è InnoDB. Nel mondo dell'open source, "morto un papa, se ne fa un altro", e potrebbero (e l'hanno già fatto!) allearsi con qualcun altro per portare avanti il loro progetto. Oppure potrebbero creare un fork di InnoDB e crearsi un InnoDB2 (boh!). La situazione mi sembra fluida. Di sicuro MySQL AB dovrà stare attenta a non farsi soffocare dall'abbraccio interessato di Oracle...Adirittura anche se Oracle comprasse anche MySQL AB, per far morire MySQL, qualcun altro potrebbe prendersi i sorgenti e fare un MySQL2.Che ne dite???ciao, iced
  • Anonimo scrive:
    A che pro?
    MySQL senza transazioni non lo puoi utilizzare in applicazioni "serie" cioe' di classe enterprise, dove Oracle regna sovrana. Considerando che InnoDB e' l'unico DB engine per MySQL che le supporta ......Mi domando quale interesse possa avere Oracle nel continuare lo sviluppo di InnoDB visto che e' gratis e nutre la concorrenza.
    • Anonimo scrive:
      Re: A che pro?
      Chi ti dice che abbia voglia di rinnovare il contratto?Forse esprime l'intenzione di rinnovarlo per evitare che mysql in quest'anno sviluppi un nuovo motore transazioni.E' un mondo di squali...Oppure visto che mysql non serve a niente senza innodb se questo diventa a pagamento gli utenti mysql saranno obbligati a comprarlo oppure a migrare ad un altro db .. ad esempio .. oracle.Insomma oracle tiene per le palle mysql.
    • KC scrive:
      Re: A che pro?
      - Scritto da: Anonimo
      Mi domando quale interesse possa avere Oracle nel
      continuare lo sviluppo di InnoDB visto che e'
      gratis e nutre la concorrenza.La licenza Oracle è decisamente onerosa e x kuesto le pikkole aziende preferiskono appoggiarsi a SqlServer d Mikro$oft (o a MySql).Mi pare ovvio ke spingere MySql implicitamente serva a rosikkiare kuote d merkato a Bill 8)
      • Anonimo scrive:
        Re: A che pro?
        - Scritto da: KC
        Mi pare ovvio ke spingere MySql implicitamente
        serva a rosikkiare kuote d merkato a Bill 8)A parte le k che violentano l'italiano, a naso direi che c'hai preso in pieno. Visto che MS è un polipo che si allarga su tutto, e visto che con il prossimo SQL Server tenteranno l'attacco ad alto livello ad Oracle, questi contrattaccano cercando di entrare nel segmento più florido di MSSQL, ovvero la media impresa.
    • Anonimo scrive:
      Re: A che pro?
      - Scritto da: Anonimo
      MySQL senza transazioni non lo puoi utilizzare in
      applicazioni "serie" cioe' di classe enterprise,
      dove Oracle regna sovrana. Considerando che
      InnoDB e' l'unico DB engine per MySQL che le
      supporta ......Non è vero, a memoria mi vengono in mente almeno gli engine BDB e NDBCLUSTER che supportano transazioni.
      • Anonimo scrive:
        Re: A che pro?

        Non è vero, a memoria mi vengono in mente almeno
        gli engine BDB e NDBCLUSTER che supportano
        transazioni.Io li ho provati, e non c'è paragone. I motori sono proprio diversi, e sono incompatibili anche per la sintassi SQL riconosciuta.Su un blog legato a MySQL avevo poi letto che BDB, viste le sue carenze, sarà presto abbandonato in favore di InnoDB. Ma questo lo si diceva prima dell'acqisto di InnoDB da parte di Oracle......purtroppo ora non trovo più il link...
  • Anonimo scrive:
    Oracle....
    Pensi all' American' s Cup e non triti le palle alla Comunità Open Sorcio se non vuole avere brutte soprese.
    • Anonimo scrive:
      Re: Oracle....
      certo perche' e' la comunita' open sorcio a detenere le quote di mercato di Oracle...
    • Anonimo scrive:
      Re: Oracle....
      Io sono decisamente a favore dell'opensource, e ti vorrei suggerire di accendere il cervello prima di pigiare tasti a caso sul tuo computer
Chiudi i commenti