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.
| L’area di attacco è la somma di tutto il codice e di tutte le funzionalità accessibili da un utente. |
SDL si propone di ridurre il numero di vulnevaribilità presente nei vostri prodotti e di ridurre la pericolosità di tutti i bugs di sicurezza non trovati.
Principi comuni del Secure-Design
I seguenti principi sono stati scritti da Saltzer e Schroeder nel 1975 e continuano ad esser validi:
· Economy of mechanism: scrivere il codice il più semplice possibile e solamente quello che serve
· Fail-safe defaults: Le azioni di defaults per qualisiasi richiesta devono essere negate
· Complete mediation: Tutti gli accessi a tutti gli oggetti protetti devono essere validati
· Open design: legge di Kerchoff: The system should not depend on secrecy, and it should be able to fall into enemy hands without disadvantage
· Separation of privilege: Non permettere operazioni basate su una singola condizione
· Least privilege: Operare con il livello più basso per il task in esecuzione
· Least common mechanism: Ridurre all’osso le risorse condivise (file, variabili etc)
· Psychological acceptability: Il prodotto è semplice da usare?
Analisi e riduzione della superfice d’attacco
L’analisi e la riduzione della superfice d’attacco è un processo che si evolve nel tempo all’evolversi dei problemi di sicurezza che vengono scovati giornalmente.
Se il tuo prodotto risulta sicuro oggi, bisogna ricordare che è sicuro per gli standard odierni.
La superfice d’attacco di un prodotto è l’unione del codice, interfacce, servizi e protocolli accessibili dagli utenti.
ASA (Attack Surface Analysis) è il processo con il quale verranno enumerate tutte le interfacce, protocolli e codice eseguibile da parte dell’utente.
ASR (Attack Surface Reduction) è il processo che trova i compromessi tra un prodotto totalmente sicuro (impossibile) e i pericoli non ridotti, minimizzando il codice eseguibile da parte di utenti non riconosciuti.
I suoi obbiettivi sono:
· Ridurre il codice eseguibile di default
· Restringere l’aria di accesso al codice
· Restringere l’aria di accesso al codice da parte di chi viene identificato
· Ridurre i privileggi
Step 1: Questa feature è realmente importante?
Un buon esempio che ci vien in aiuto per rispodere a questa domanda è IIS6 su server 2003.
Di default non è installato su server 2003.
Disabilitare una feature di default non significa realizzare un software povero di idee; ma significa ridurre la possibilità che molti utenti possano cadere in potenziali bugs.
Una feature porta con se molte domande (come si può vedere ne diagramma si flusso) e molti problemi.
Una feature è composta da micro-feature e per ognuna di queste potremmo avere un bug.
Basti pensare che installando IIS6, questo installerà o potrebbe installare a sua volta altre sotto feature:
· SOAP
· ASP.NET
· CGI
· ISAPI
Step 2: Chi ha bisogno di accedere alla funzionalità e da dove?
Un processo indispensabile alla sicurezza del vostro prodotto è l’analisi di ogni singola funzionalità dell’applicazione in modo da determinare chi vi ha bisogno di accedervi (anonymous, user, admin) e da dove (remoto, remoto su specifica subset di indirizzi o subnet, site-local o link-local se IPv6, solo locale).
Non bisogna mai affidare le difese del vostro sistema solamente ai firewall.
Questi sono ottimi per difendere il sistema se gli utenti li configurassero adeguatamente e non li disattivassero.
Step 3: Ridurre i privileggi
È obbligatorio far girare il codice solamente con i privileggi necessari all’esecuzione del task, NULLA DI PIU’.
Per far ciò le soluzioni sono due:
1. Creare un account con i permessi di cui ha bisogno l’applicativo per eseguire solamente il task
2. Eseguire il servizio tramite un account ben conosciuto, come NETWORK SERVICE, e dopo eliminare i permessi di cui non ha bisogno.
Servizi e bassi privilegi
Tutti i servizi che creerete per i vostri clienti devono girare su account a basso rischio come: NETWORK SERVICE o LOCAL SERVICE.
Se non è possibile usare gli account di cui sopra, allora usate LOCAL SYSTEM.
Spesso un servizio ha una form per la configurazione o per i task relativi alla sicurezza.
In questi casi si utilizza un account di tipo LOCAL SYSTEM.
In realtà per migliorare la sicurezza del proprio servizio possiamo dividerlo in più di un processo di esecuzione, eseguendo solamente la parte di configurazione con un alto livello di privilegi e la parte dedicata agli utenti a basso privilegio (come i web service, vedi figura):
Altri elementi da tenere in considerazione
Di seguito un lista di elementi da tener di conto per ridurre l’area di attacco.
UDP vs TCP
UDP ha una elevata superfice d’attacco perchè venire a conoscenza dell’indirizzo di chi spedice il pacchetto (spoofed) è abbastanza semplice, l’udp è un datagram con protocollo di tipo “fire and forget”, ovverro il pacchetto viene spedito però non abbiamo la sicurezza che questo venga ricevuto.
Ciò non significa di non usare l’UDP ma che questo aumenta l’area di attacco, quindi deve essere usato scrupolosamente.
A differenza dell’UDP, il TCP esegue un”three-way handshake” il quale verifica l’indirizzo e la porta del chiamante e del chiamato.
Permessi deboli vs Permessi forti
Permessi deboli o un ACL (access contro list) mal configurato possono rendere un sistema operativo alquanto debole.
I permessi di default di Windows sono buoni, ma bisognerebbe sempre riguardare l’ACL per configurare opportunamente oggetti, da dover usare con i propri applicativi, per renderli sicuri.
Anche nel mondo *nix la logica utilizzata è la stessa.
Ecco un esempio di ciò che può capitare quando i permessi sono deboli: un utente ha i diritti di cambiare i driver di una periferica.
Una volta che il sistema operativo caricherà i driver relativi alla periferica, questi andranno all’interno del kernel, e il codice dei driver potrebbe essere malizioso.
.NET vs ActiveX
Gli ActiveX controls non hanno resistrizioni di permessi; quindi hanno una grande superfice d’attacco.
Bisogna quindi pensare sempre allo sviluppo con codice managed, se questo non può rispondere alle necesessità allora, e soltanto allora, penseremo alle ActiveX.
ActiveX Safe for Scripting
Se non possiamo far a meno di un ActiveX allora stiamo attenti almeno che il controllo non sia identificato come “safe for scripting”, perchè potrebbe eseguire del codice JavaScript presente nel Web browser, del quale non conosciamo la provenienza.
Un ActiveX con questa opzione abilitata ha una superfice d’attacco immensa, basti pensare che ha la possibilità di eseguire: reboot della macchina, installare update e eseguire codice come amministratore del sistema.
Un’opzione che può venirci in aiuto quando abilitiamo il “safe for scripting” è la “SiteLocking”, la quale permette allo sviluppatore di ridurre l’aria di attacco, specififcando una lista predeterminata di domini a cui l’ActiveX ha accesso.
Managed code AllowPartiallyTrustedCallers Attribute
Gli assemblies strong-name e con l’attributo AllowPartiallyTrustedCallers (APTCA) possono essere chiamati da codice non sicuro, ciò aumenta la superfice d’attacco del nostro prodotto.
Per strong-name intendiamo un assembly con una propria identità, basata su: nome, versione, cultura, una chiave pubblica e una firma digitale.
Per concludere
Non attendete di ridurre la superfice d’attacco solamente alla fine dello sviluppo del prodotto, invece lavorate sin da subito per tenerla bassa.
Di seguito una tabella dove identifichiamo alte superfici d’attacco e basse superfici d’attacco:
| Higher Attack Surface | Lower Attack Surface |
| Feature running by default | Feature not running by default |
| Open network connection | Closed network connection |
| Listening for UDP and TCP traffic | Listening only for TCP traffic |
| Anonymous access | Authenticated user access |
| Authenticated user access | Administrator access (attenzione a non mettere troppo codice eseguibile solo dall’amministratore perchè potresti violare il principio di least privilege) |
| Internet access | Subnet, link-local, site-local access |
| Subnet, link-local, site-local access | Local machine access |
| Code running with Administrator, Local System or root privileges | Code running with Network Service, Local Service, or custom low-privilege account |
| Weak object permission | Strong object permission |
| ActiveX control | .NET code |
| ActiveX control marked safe for scripting | ActiveX control not safe for scripting |
| Non-SiteLocked ActiveX control | SiteLocked ActiveX control |
Tags: SDL
posted @ mercoledì 2 gennaio 2008 22:46