Security-By-Contract: Monitorare un'applicazione con la Tecnica di Inline Monitoring


    25/03/2008

    Autori:

    Nicola Dragoni, Fabio Massacci Dipartimento di Ingegneria e Scienza dell'Informazione - Università  di Trento.

    3. Monitorare un'Applicazione con la Tecnica di Inline Monitoring

    Cose succede se scarichiamo un'applicazione che non ha un contratto? Possiamo eseguirla in modo sicuro? Oppure l'approccio SxC richiede che tutte le applicazioni abbiano necessariamente un contratto? E cosa succede se il contratto di un'applicazione non rispetta la policy del dispositivo mobile?

    L'approccio SxC gestisce tutte queste situazioni utilizzando una tecnica chiamata inline monitoring.

    Per mezzo di questa tecnica è possibile far rispettare una policy da un'applicazione inserendo opportuni controlli nel codice dell'applicazione. In questo modo un utente può scaricare qualsiasi applicazione software (anche sprovvista di un contratto) ed eseguirla in modo sicuro nel proprio dispositivo.

    La tecnica di inline monitoring sviluppata nel contesto di SxC viene eseguita direttamente sul dispositivo e quindi non dipende da nessun servizio sviluppato da terze parti.

    Il risultato è che ogni azione rilevante per l'utente in termini di sicurezza (ovvero ogni azione dichiarata nella policy) viene automaticamente controllata durante l'esecuzione dell'applicazione.

    Esempio 2. Consideriamo due utenti che giocano con l'applicazione introdotta nell'esempio 1 (gioco degli scacchi) utilizzando i loro telefoni (Figura 4). Assumiamo che tale applicazione non abbia un contratto oppure che il contratto non rispetti la policy dei due telefoni. Nel PDA di sinistra non c'è alcun sistema di inline monitoring, quindi l'applicazione è eseguita senza alcun controllo di sicurezza. Nel PDA di destra invece è installato un sistema di inline monitoring che tra le varie azioni controllate verifica che l'applicazione non spedisca più di un certo numero di messaggi (per non far spendere troppo all'utente). Quando si verifica la violazione (cfr Figura) il sistema di monitoring se ne accorge e l'azione incriminata non verrà eseguita ed il problema segnalato all'utente. L'utente potrà scegliere se visualizzare i dettagli della violazione o chiudere direttamente l'applicazione.

    Figura 4: Due cellulari che giocano a scacchi.

    Figura 4: Due cellulari che giocano a scacchi. Il cellulare di destra cattura la violazione di una policy.

    Lo scenario seguente illustra un ulteriore esempio di possibile utilizzo del servizio, con alcuni dettagli su ciò che avviene realmente e in maniera del tutto trasparente per l'utente.

    Scenario 1. Un utente definisce la propria policy o, se non si sente abbastanza competente, seleziona una policy predefinita dall'operatore. La policy selezionata è formalizzata nel dispositivo in un linguaggio logico chiamato 2D-LTL. Questo permette al dispositivo di compilare la policy in uno specifico formato che verrà  poi utilizzato nella fase di inline monitoring. Tale operazione avviene completamente in automatico, ovvero l'utente non è coinvolto (non è necessario che l'utente conosca un linguaggio tecnico come 2D-LTL). A questo punto la policy è pronta per essere utilizzata. Ipotizziamo ora che l'utente scarichi un'applicazione, ad esempio un gioco di scacchi, che non ha un contratto e quindi non può avvenire il controllo automatico tra la policy del dispositivo e il contratto dell'applicazione. Ma all'utente piace molto questa applicazione e vuole installarla comunque. Per eseguirla in modo sicuro, l'utente seleziona da un elenco una policy da applicare all'applicazione, come mostrato precedentemente in Figura 2. Una volta selezionata la policy, il dispositivo modifica l'applicazione inserendo tutti i controlli dichiarati nella policy (fase di inline monitoring). A questo punto l'applicazione è pronta per essere eseguita in modo sicuro: ogni volta che l'applicazione violerà una delle regole della policy dell'utente, il sistema non permetterà l'esecuzione dell'azione e segnalerà  la violazione all'utente. Tale segnalazione può avvenire in modo più o meno drastico a seconda di come l'applicazione gestisce queste eccezioni di sicurezza. Per esempio, se l'applicazione non gestisce tali eccezioni, allora l'applicazione terminerà bruscamente. Se invece l'applicazione prevede la gestione delle eccezioni di sicurezza, l'applicazione potrebbe ad esempio terminare solo dopo aver segnalato all'utente cosa è successo.

    4. Conclusioni

    In questo articolo è stato introdotto il paradigma Security-By-Contract (SxC), un approccio per migliorare la sicurezza nei dispositivi mobili sviluppato nel contesto del progetto europeo S3MS (www.s3ms.org).

    L'intuizione di base è che un'applicazione software viene scaricata insieme ad un "contratto" che descrive tutte le interazioni rilevanti, in termini di sicurezza, che l'applicazione avrà col dispositivo mobile sul quale verrà eseguita. Il contratto dovrà essere quindi accettato dal dispositivo in funzione di una policy di sicurezza definita dall'utente o dall'operatore della rete.

    Tale paradigma non sostituirà gli attuali sistemi di sicurezza ma li migliorerà, fornendo un meccanismo di sicurezza flessibile, semplice e scalabile per i dispositivi mobili del futuro.

    Sitografia:

    Riferimenti Documenti tecnici e pubblicazioni scientifiche possono essere liberamente scaricate dal sito Web del progetto S3MS: www.s3ms.org.

    Nomadic devices, the freedom to compute www.lswn.it/en/press_releases/2008/nomadic_devices_the_freedom_to_compute


    1. Il Problema della Sicurezza nei Dispositivi Mobili 2. L'approccio Security-By-Contract (SxC)

    «Previous 1 2 3