E' fondamentale ai fini della sicurezza implementare dei tools propri o utilizzare tools di terze parti che possono analizzare l'applicativo prodotto. E' altrettanto fondamentale utilizzare gli ultimi compilatori/linker/framework rilasciati e non utilizzare metodi bannati. I compilatori di ultima generazione (C e C++) tendono a scrivere un messaggio di warning nel caso in cui il metodo che stiamo utilizzando non è sicuro (vedi i vari: strcat, sprintf etc) Ricordiamoci comunque che tutti i tools che utilizzeremo non potranno mai analizzare il codice come un essere umano, sicuramente potranno venirci incontro con la maggior parte di bugs (almeno quelli più grossolani). E' utile avere una secure...

A questo punto del progetto dovreste aver pronto un prodotto con pochi bugs e un pò di tools che avete creato per testare il vostro software (o che magari avevate già). Affinchè il vostro cliente utilizzi in maniera corretta l'applicativo, dovremo rilasciare un pò di documentazione affinchè possiamo rendere noti le scelte fatte per rendere il software sicuro. Setup documentation E' il tipo di documentazione dove andremo a scrivere informazioni quali: quale porta e quale protocollo utilizzeremo, perchè le utilizziamo, su che tipo di restrizioni di accesso deve avere la nostra applicazione, che restrizione dovremmo avere nella subnet. Si continuerà con evidenziare quali sistemi...

Oggi sono venuto a conoscenza di questo utile tools che analizza i vostri progetti ASP.NET, alla ricerca di Cross-Site Scripting (XSS), si integra perfettamente con VS 2005. Per scaricarlo cliccate quì. Tags: Security | SDL

9.     Plan Mitigation Che strategia applicare per ridurre o eliminare i rischi a cui il nostro sistema va incontro: Non far nulla Per threat di basso profilo è la scelta migliore. Cmq dovremo tener presente il threat in modo da risolverlo con il prossimo update. Rimuovere la funzionalità Se si vuole ridure il rischio di attacchi a zero, questa è l’unica soluzione, sopratutto quando il rischio è elevato e la funzionalità non è utilizzata dal cliente. Settare la funzionalità inattiva di default Quando la funzionalità viene utilizzata dal cliente, ma non è fondamentale per tutti gli utenti dell’applicativo, è utile disattivarla di default e renderla attiva solamente...

7.     Identity Threats to the System Adesso che il DFD è completato, bisogna stilare una lista con tutti gli elementi del DFD, perchè dovrai difendere questi elementi dagli attacchi. Non verranno inclusi i processi complessi, invece sono inclusi i processi, i sistemi di salvataggio dati e i canali in cui i dati si muovono. Faremo sempre riferimento al pet shop di un paio di post fà: DFD...

6.     Determine Threat Types In Microsoft per identificare un threat hanno creato un classificatore (taxonomy) chiamato STRIDE. STRIDE è una sigla formata da: ·         Spoofing Identity ·         Tampering ·         Repudiation ·         Information Disclosure ·         Denial of Service ·         Elevation of Privilege   Spoofing Identity Permette a chi attacca di far finta d’esser qualcun’altro o qualcos’altro. Esempio, permette di identificarsi come Bill Gates, come il dominio Microsoft.com o come il file Ntdll.dll. Tampering L’attaccante modifica dati o parti del codice, senza che il destinatario se ne accorga. Repudiation Chi attacca nega d’aver effettuato un’azione e il sistema attaccato non può né confermare né contraddire; questo può capitare quando un utente effettua un’operazione proibita ma il...

The Threat-Modeling Process Sebbene la procedura di alto livello coinvolga numerosi elementi, molti di questi richiedono poca esperienza nel campo della sicurezza: 1.       Define use scenarios. 2.       Gather a list of external dependencies. 3.       Define security assumptions. 4.       Create external security notes. 5.       Create one or more DFDs of the application being modeled. 6.       Determine threat types. 7.       Identify the threats to the system. 8.       Determine risk. 9.       Plan mitigations.   1.     Define use scenarios A questo punto del progetto saremo in grado di determinare in quale scenario il nostro applicativo lavorerà. Se, ad esempio, è un’applicazione mobile la quale ha dati sensibili, vorremmo avere qualche sistema di sicurezza se il palmare viene...

Risk Analysis Scrivere un corretto threat modelling, controllato tutti i giorni della settimana può far risparmiare tempo/denaro alla realizzazione di un progetto. La motivazione è semplice, un corretto threat modelling permette di trovare problemi di sicurezza durante il ciclo di vita del progetto. La seguente tabella è stata stilata da Steve McConnell nel suo libro Code Complete (McConnell 2004) per far capire i costi relativi al fixing di difetti trovati nel codice: ...

Stima rischi Lo scopo della stima dei rischi del prodotto è chiarire il livello di impegno necessario al compimento dei requisiti SDL. Sarà quindi necessario identificare: ·         Quale parte del progetto richiede un threat model prima del rilascio ·         Quale parte richiede un security design review ·         Quale parte ha bisogno di test funzionali ...

Definire e seguire il design del prodotto Tutti i prodotti che sviluppate dovrebbero avere un secure-design best practices. Il secure-design principalmente aiuta nel prevenire eventuali errori di sicurezza. Bisogna tener presente che, ogni Threat modelling che svilupperete sarà, diverso per ogni prodotto e differente dal secure-design ma complementare. Nel Thread modelling determinerete i metodi per ridurre i problemi della sicurezza del vostro sistema e nel secure-desing i metodi migliori per tenere pulito il vostro prodotto. Un’altra best practices nella quale la fase di design può venir in aiuto è ridurre l’area di attacco. ...

Inzio del progetto All’inizio di un progetto bisogna seguire pochi ma importanti passi: ·         Determinare se l’applicazione è coperta dal SDL ·         Dichiarare un Security Advisor ·         Creare un team di Security Leadership ·         Creare il processo di bug-tracking, security e privacy bug ·         Creare una bug bar    Determinare se l’applicazione è coperta dal SDL Utilizzare una procedura SDL non può far altro che creare benefici per il ...

Conoscere In Microsoft sono fieri di ciò che stanno ottenendo con SDL. Secondo loro le motivazioni principali allo sviluppo di software sempre più sicuro sono: ·         Supporto ·         Conoscenza (cit: education and awareness) Per Microsoft bisogna educare i propri sviluppatori sulla sicurezza del software. Non possiamo pensare che tutti sappiano come fare software sicuro ne, tanto più, capire se il software che stiamo producendo sia sicuro o no. Come hanno fatto in Microsoft In Microsoft per educare adeguatamente i propri dipendenti, hanno tenuto alcuni corsi interni su i seguenti punti: ·         Software engineering principles ·         Lessons learned from past projects ·         Software architecture ·         Testing methods ·         Transaction technology ·         Relibility ·         Scalability ·         Understanding...

Di necessità virtù! Abbiamo bisogno di SDL? Dipende! Sicuramente ci sono dei prodotti a cui una spruzzata di SDL non fa per nulla male: ·         Sistemi operativi ·         Database ·         Server (email, ftp, etc) ·         E-commerce ·         Applicazioni per il business (line-of-business) Insomma, tutte le applicazioni che trattano dati sensibili. Quando si considera di applicare SDL a un prodotto di tipo line-of-business è importante capire l’impatto negativo che si può avere se i dati venissero letti, modificati o cancellati.   Ancora no! Un’aspetto importante a cui SDL da una parte principale è capire quando un progetto non è pronto per la distribuzione; e in quel caso rimandarne la produzione. Quando bisogna rimandare una...

Eric Raymond nel suo libro “The Cathedral and the Bazaar” scrisse: “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.” Oggi sappiamo che tutto ciò non è vero. Il software prodotto dalla comunità open source non è sicuro dagli attacchi! Per l’autore del libro, il concetto di Eric Raymond risulta fallimentare in due punti: 1.       Non si conoscono le motivazioni di chi riguarda il codice. 2.       Non si conoscono le capacità tecniche di chi è alla ricerca di bugs.   Motivazione Il primo punto e facilmente riassumibile. Uno sviluppatore è un creativo e creare...

Al ritorno del TechEd tenuto quest'anno, in quel di Barcellona, un mio amico ha avuto l'insana idea di portarmi il seguente libro: The Security Development Lifecycle - Microsoft - Michael Howard, Steve Lipner Premettendo che ancora non l'ho finito di leggerlo, ho voluto fare il sunto di qualche parti che, per alcuni potranno essere scontate mentre per altri potranno tornare utili. Introduzione: SDL Applicare SDL a un progetto è un processo alquanto dispendioso ed ad oggi poco quantificabile. Perchè allora un'azienda dovrebbe applicare SDL? Un'azienda spesso è composta da personale tanto orgoglioso del proprio codice che difficilmente ammetterà la necessità di doverne...