Security & Architecture : SDL

The Microsoft SDL : Developer Starter Kit

mfontana — Sat, 17 Oct 2009 04:15:00 GMT

This is a great news !! It’s available for download the new The Microsoft SDL Developer Starter Kit with slides, documents and labs to help you establish a standardized approach to rolling out the Microsoft Security Development Lifecycle (SDL) in your organization—or enrich your existing development practices.

You can decide to download the kit and run it into your environment or you can try it through our Security Virtual Labs.

This material is also correlated to the SDL Optimization model to introduce a gradual and cost-effective implementation of the SDL into the organization.

--Mario

Microsoft SDL : Return On Investment

mfontana — Fri, 16 Oct 2009 10:10:11 GMT

Microsoft and ISec Partners just published a joint whitepaper about Microsoft SDL and the return of Investment to help IT architects and business architects to :

· Understand and communicate the benefits of a structured approach to software security.

· Develop and use metrics for ROI to guide process improvement.

· Get meaningful results from a new program or optimize existing efforts on a limited budget.

You can read more information here.

--Mario

TAM 3.0 : Disponibile la BETA 1

mfontana — Thu, 23 Jul 2009 08:00:00 GMT

E’ disponibile la BETA 1 del Threat Analysis and Modeling Tool che porta novità in vari ambiti. Uno di questi che mi piace particolarmente è l’hosting dello store delle CTL (Common Task List) su Azure come servizi WCF. Le CTL sono una lista di contromisure condivise da Microsoft e dalla comunità di Security disponibili a tutti in forma automatica per facilitare l’adozione corretta delle contromisure rispetto agli attacchi più comuni.

Altre aree di miglioramento sono :

- Azure based CTL store
- Visio drawing surface for use cases
- Intelligent TFS Sync
- Automated tool update detection
- Modified methodology to make threat modeling simpler
- Composite Threats and single threat for a call
- Improved Automatic Threat Generation
- v2.1 Import with automated countermeasure mapping
- Updated countermeasure structure
- Other minor UI and functionality tweaks

Maggiori info qui

--Mario

The Amazing Adventures of Kevlarr and the Security Development LifeCycle 1/18

mfontana — Thu, 29 Jan 2009 20:15:00 GMT

Da grande patito di fumetti della Bonelli quale sono, non potevo che essere felice dell’iniziativa del Team del SDL che da tempo sta creando una storia a fumetti che ha come protagonista Kevlarr, un ordinary software developer, alle prese con la difesa delle proprie applicazioni… :-)

Certo non è Nathan Never, o Dylan Dog però :-)

per leggere le restanti “puntate” ci si può sottoscrivere qui : http://www.microsoft.com/security/bakingsecurityin/rss/

--Mario

Breve intervista a Steve Lipner sulle motivazioni che hanno portato Microsoft ad un forte commitment nella sicurezza

mfontana — Thu, 29 Jan 2009 08:00:00 GMT

questo video per me è un cult ! Non tanto per il contenuto ma quanto per quello che è successo dopo … tutto iniziò (seriamente) con Code Red !!!

http://www.microsoft.com/security/bakingsecurityin/video.htm

--Mario

Ingegneria del software : come prevenire le top 25 vulnerabilità nel codice di CWE/SANS con il Microsoft SDL

mfontana — Wed, 28 Jan 2009 20:10:43 GMT

Pochi giorni fa è stato presentato un lavoro congiunto CWE e SANS che riassume le 25 cause più serie e purtroppo più ricorrenti nello sviluppo del software relative alla sicurezza.

Oggi Microsoft ha rilasciato un documento che spiega come l’ SDL - il processo di ingegneria del software - Microsoft Security Development LifeCycle- , se applicato correttamente, è in grado di gestire tutti e 25 glil errori.

Questi non sono semplici esercizi di stile ma piuttosto servono a dimostrare che le fatiche (e i costi) derivati dall’implementazione del SDL nel proprio processo di sviluppo software sono ben spese. Ben vengano queste liste sugli errori di sicurezza perchè un processo orientato alla sicurezza deve essere sempre revisionato ed aggiornato perchè le tecniche e i metodi di attacco sono sempre in divenire…

CWE	Title	Education?	Manual Process?	Tools?	Threat Model?
20	Improper Input Validation	Y	Y	Y	Y
116	Improper Encoding or Escaping of Output	Y	Y	Y
89	Failure to Preserve SQL Query Structure (aka SQL Injection)	Y	Y	Y
79	Failure to Preserve Web Page Structure (aka Cross-Site Scripting)	Y	Y	Y
78	Failure to Preserve OS Command Structure (aka OS Command Injection)	Y		Y
319	Cleartext Transmission of Sensitive Information	Y			Y
352	Cross-site Request Forgery (aka CSRF)	Y		Y
362	Race Condition	Y
209	Error Message Information Leak	Y	Y	Y
119	Failure to Constrain Memory Operations within the Bounds of a Memory Buffer	Y	Y	Y
642	External Control of Critical State Data	Y			Y
73	External Control of File Name or Path	Y	Y	Y
426	Untrusted Search Path	Y		Y
94	Failure to Control Generation of Code (aka 'Code Injection')	Y	Y
494	Download of Code Without Integrity Check				Y
404	Improper Resource Shutdown or Release	Y		Y
665	Improper Initialization	Y		Y
682	Incorrect Calculation	Y		Y
285	Improper Access Control (Authorization)	Y	Y		Y
327	Use of a Broken or Risky Cryptographic Algorithm	Y	Y	Y
259	Hard-Coded Password	Y	Y	Y	Y
732	Insecure Permission Assignment for Critical Resource	Y	Y
330	Use of Insufficiently Random Values	Y	Y	Y
250	Execution with Unnecessary Privileges	Y	Y		Y
602	Client-Side Enforcement of Server-Side Security	Y			Y

--Mario

Anti-XSS 3.0 e il nuovo motore SRE - Security Runtime Engine

mfontana — Thu, 18 Dec 2008 11:55:01 GMT

Credo non sia necessario ricordare quanti problemi abbiano dato e stiano dando le varie declinazioni degli attacchi XSS (Cross Site Scripting). Per questo motivo è essenziale conoscere sia alcune tecniche di programmazione che permattano di evitare gli errori più comuni sia utilizzare delle libreria a supporto degli sviluppatori per gestire correttamente i dati di input/output. In casa Microsoft la soluzione di riferimento (utilizzata anche internamente) è senza dubbio la libreria Anti-XSS che da pochi giorni è stata resa disponibile in versione beta. E' possibile scaricare Anti-XSS 3.0 (download e source code) con il nuovo motore "Security Runtim Engine" e la libreria per l'analisi statica di codice .NET dal nome : CAT.NET (32 bit e 64 bit ).

Anti-XSS 3.0 (disponibile su codeplex con licenza MS-PL) è una encoding library per aiutare gli sviluppatori ASP.NET a mitigare i rischi legati ai molteplici attacchi di tipo Cross-Site Scripting (XSS). A differenza di molte altre librerie Anti-XSS 3.0 utilizza la tecnica della white list o del principio di inclusione (definisce tutti i caratteri validi ed effettua l'encoding di tutto il resto) a differenza dell'approccio della black-list che esclude a priori i caratteri pericolosi permettendo tutto il resto. La lista di tutti i caratteri ammessi e relative lingue supportate è disponibilie all'interno dell' Help della libreria.

La nuova versione del Microsoft comprende le seguenti novità :

An expanded white list that supports more languages
Performance improvements
Performance data sheets (in the online help)
Support for Shift_JIS encoding for mobile browsers
A sample application
Security Runtime Engine (SRE) HTTP module

Ovviamente il solo uso di una libreria non può risolvere tutti i problemi di Cross-Site Scripting e tanto meno di sicurezza. La libreria non può sostituire un processo strutturato come il SDL (Security Development LifeCycle) e le attività di Threat Modeling. Detto questo, come esplicitato nell'help, i passi per utilizzare correttamente la libreria all'interno di applicazioni ASP.NET sono:

Determinare tutti i punti in cui la nostra applicazione genera dei dati di output.
Su questa analisi verificare quando tale output è prodotto da untrusted input (anche indiretti o a cascata) come ad esempio inpunt utente,Cookies,DB,Query String,variabili di sessioni,ecc...
Determinare il tipo di encoding che si vuole utilizzare.
Fare l'encoding dell'output.

questo da un punto di vista del processo. Da un punto di vista operativo aggiungiamo la reference agli assembly AntiXSSLibrary.dll e AntiXSSModule.dll e nel Web.Config referenziamo il modulo

<httpModules>
<add name="AntiXssModule" type="Microsoft.Security.Application.SecurityRuntimeEngine.AntiXssModule"/>
</httpModules>

<system.WebServer>
<modules>
<httpModules> <add name="AntiXssModule" type="Microsoft.Security.Application.SecurityRuntimeEngine.AntiXssModule"/> </httpModules>
</modules>
</system.WebServer>

e creiamo il file antixssmodule.config tramite l'utility ConfigGen.exe oppure copiamo il seguente file:

antixssmodule.config

<Configuration>
<ControlEncodingContexts>
      <ControlEncodingContext FullClassName="System.Web.UI.Page" PropertyName="Title" EncodingContext="Html" />
      <ControlEncodingContext FullClassName="System.Web.UI.WebControls.Label" PropertyName="Text" EncodingContext="Html" />
      <ControlEncodingContext FullClassName="System.Web.UI.WebControls.CheckBox" PropertyName="Text" EncodingContext="Html" />
   </ControlEncodingContexts>
<DoubleEncodingFilter Enabled="True" />
<EncodeDerivedControls Enabled="True" />
<MarkAntiXssOutput Enabled="False" Color="Yellow"/>
</Configuration>

In questo modo abbiamo configurato e attivato anche il SRE (Security Runtime Engine) che fa un override delle impostazioni di encoding del framework .NET per avere una maggiore protezione senza dover modificare il codice applicativo.

A questo punto siamo pronti per poter utilizzare la libreria Anti-XSS direttamente dal nostro codice sorgente:

Anti-XSS mette a disposizione alcuni metodi interessanti : HtmlEncode e HtmlAttributeEncode per lavorare con input di tipo HTML, XmlEncode,XmlEncodeAttribute per codice XML, UrlEncode per la gestione delle URL ed infine JavaScriptEncode e VisualBasicScriptEncode a seconda del linguaggio di scripting utilizzato.

Quindi, ad esempio la potenziale vulnerabilità XSS della seguente riga di codice:

Literal1.Text = ?<hr size='[untrusted input here]'></hr>?;

può essere mitigata con:

Literal1.Text = ?<hr size='+Microsoft.Security.Application.AntiXss.HtmlAttributeEncode([untrusted input here])+'></hr>?;

Questa versione esce anche con uno strumento veramente interessante : l' Anti-XSS Test Harness, ovvero una console app che ci permette di fare dei test di vulnerabilità e di performance sull'uso della liberia Anti-XSS. Su questo argomento estremamente importante però voglio dedicare un post ad-hoc!!

--Mario

Nuovo documento da SafeCode : Fundamental Practices for Secure Software Development

mfontana — Thu, 09 Oct 2008 18:49:47 GMT

Ieri SafeCode ha rilasciato un nuovo whitepaper introduttivo sulle best practices per lo sviluppo di codice sicuro. Lo scopo di questo breve documento (22 pagine - quindi non ci sono scuse per non leggerlo :-) è appunto quello di sintetizzare in modo pragmatico e schematico le corrette procedure di sicurezza durante tutto il ciclo di vita dello sviluppo del software : Requirements, Design, Programming, Testing, Code Handling e Documentation.

Questi principi possono essere ovviamente applicati indipendentemente dagli ambienti di sviluppo e dal processo di ALM adottato.

Per chi si fosse perso la prima uscita : Software Assurance: An Overview of Current Industry Best Practices

--Mario

Best practices per l'analisi dei rischi architetturali

mfontana — Sat, 05 Apr 2008 08:28:59 GMT

Continua la serie dei consigli di Roberto Scaccia sull' Application Security ...

--Mario

Sintesi della Sicurezza Applicativa

mfontana — Mon, 11 Feb 2008 07:00:55 GMT

Roberto Scaccia fornisce una chiara e sintetica overview della sicurezza applicativa, delle linee guida e alcuni riferimenti.

Da leggere assolutamente!!

--Mario

TechED Breaking News #1 : Threat Modeling UPDATES

mfontana — Wed, 07 Nov 2007 19:27:01 GMT

Ieri pomeriggio, finite le fatiche dell' ATE ho fatto 4 chiacchiere con Michael Howard. Le prime 2 erano per aggiornarlo su alcuni progetti che stiamo portando avanti in Italia ma le altre 2 sono state molto più ... divertenti ... :-)

Infatti ... insieme a Raffaele lo abbiamo letteralmente "martellato" sul discorso Threat Modeling e approccio all'analisi. Infatti rispetto alle prime versioni del Threat Modeling l'approccio all'analisi dei rischi è cambiata in modo radicale (e lo si nota soprattutto nel tool TAM) ... si è passata da una visione Attack-Oriented ad una visione diametralmente opposta di tipo Defense-Oriented. Quindi non più una analisi dal punto di vista di chi attacca una applicazione ma dal punto di vista di chi la difende...Un cambio non da poco, che spesso disorienta le persone che magari da tempo si sono avvicinati alla nobile arte del Threat Modeling !!! Il problema dove nasce... dal fatto che le persone si possono confondere facilmente se da una versione del tool di riferimento all'altra cambia radicalmente la logica con cui si analizzano le minacce nel sofware.. Non è una cosa da poco...tanto più che la maggior parte delle nuove informazioni (post, presentazioni, ecc...) parlano ancora del modello precedente. A bit confusing no??
Comunque... alla fine Michael ha confermato che la strada è sicureamente quella del Defense-Oriented perchè più semplice e comprensibile anche per i non esperti di sicurezza.

Invece per chi ha già esperienza di Threat Modeling e ha una certa padronanza della sicurezza applicativa (e quindi analizza le minacce dal punto di vista di chi attacca) c'è una importante novità per quanto riguarda il modello D.R.E.A.D (Damage, Reproducibility, Exploitability, Affected Users, Discoverability)!!! Il calcolo della minaccia con D.R.E.A.D viene o meglio veniva calcolata dando un valore da 1 a 10 ad ogni voce che compone D.R.E.A.D e calcolandone la media... alla fine esce semplre un numero tra 0 e 10 dove più alto è il numero più grave è la minaccia. Il modello D.R.E.A.D viene rimpiazzato con una classificazione derivata dal ranking dei bollettini di sicurezza MSRC: Critical, Important, Moderate e Low per garantire una minore discrezionalità. Infatti con D.R.E.A.D era troppo facile spostare (certe volte con troppa leggerezza) il valore per declassare automaticamente il threat. Con il nuovo modello è necessario definire una macro classificazione per facilitare la suddivisione. Ad esempio:

Inoltre il metodo ha sicuramente un altro grandissimo vantaggio su D.R.E.A.D : ha una scala di valori che trasmette in modo non ambiguo la criticità del threat!!
Infatti è sicuramente di più facile comprensione avere un threat calcolato Critical rispetto ad uno calcolato ad esempio 8 o 9 o 10 a seconda della classificazione dei singoli elementi di D.R.E.A.D.

--Mario

Slides del Panel Sicurezza a WPC 2007

mfontana — Sat, 27 Oct 2007 12:42:56 GMT

Qui potete trovare le slides che ho utilizzato per il Panel Sicurezza : "SOA e Sicurezza Applicativa. Le sfide di oggi e di domani".

Durante i giorni del WPC ho avuto modo di parlare con molte persone interessate alle problematiche di sicurezza in SOA e ho raccolto e "consolidato" una serie di aree tematiche di interesse comune sulle quali farò dei post di approfondimento.

--Mario

La riscossa del Tester

mfontana — Wed, 24 Oct 2007 19:35:58 GMT

Ovviamente non sto parlando dello strumento x misurare le tensioni e correnti elettriche :-) ma bensì di colui che testa e verifica il funzionamento e la qualità del codice prodotto dagli sviluppatori. Una bella responsabilità :-) !!!

Nella realtà italiana sono ben poche le società che hanno istituzionalizzato la figura del tester diversificandola da quello dello sviluppatore sebbene gli skill di entrambi i ruoli siano alquanto diversi. E' comunque fuor di dubbio che all'interno del processo di ALM (Application LifeCycle Management) la parte di testing DEBBA essere presente ed eseguita in modo automatico su tutti i componenti/servizi implementati.

Anche nel "famoso" SDL (Security Development LifeCycle) la parte di Secure Testing è un'attore di primissimo piano. Infatti i Solutions Architects possono disegnare una soluzione applicativa sicura by design e gli sviluppatori implementarla scrivendo il codice secondo le best practices del "Writing Secure Code" ma è solo durante la fase di testing che si può determinare se il prodotto è realmente sicuro e aderente agli standard aziendali.

Da ieri è live sul sito Microsoft l' MSDN Test Center un'area dedicata alla disciplina del tester dove poter imparare e condivedere tecniche ed esperienze nell'arte del testing.
Un link utile quindi anche a tutti i programmatori :-)

Ritorneremo molto presto su questo argomento importantissimo...

--Mario

Panel Security al WPC 2007 : SOA e Sicurezza Applicativa. Le sfide di oggi e di domani.

mfontana — Fri, 19 Oct 2007 17:37:14 GMT

Per chi di voi sarà al WPC 2007 spero di incontrarvi al panel sulla sicurezza "SOA e Sicurezza Applicativa. Le sfide di oggi e di domani" che terrò martedi 23 Ottobre dalle 19.15 alle 20.00. Come orario un po' tardino... a mo' di aperativo prima della cena :-)

Il formato del panel è pensato apposta per sessioni interattive... poche slides (tanto per inquadrare i punti chiavi) e poi via con le domande e un confronto tra noi e le nostre esperienze sui progetti...
E per chi non ne avesse abbastanza la sera dopo cena, questa volta a mo' di digestivo, sarò nell'area "Technical Afterhour" per fare quattro chiacchiere...

--Mario

Agenda del WebCast sull' Identity & Access Management

mfontana — Thu, 27 Sep 2007 01:11:51 GMT

Questa è la versione definitiva dell'agenda del Webcast che ho fatto sull' Identity & Access Management presentato qui.

Agenda

Identity & Access Management Overview.
Cosa intendiamo per Digital Identity.
Identity Design Patterns.
Scenari architetturali.
Identity MetaSystem.
Identity LifeCycle Management.

Potete scaricare le slides mentre l'intero WebCast è disponibile per il download qui.

--Mario