Settembre 2014
■
Automazione e Strumentazione
SECURITY
tecnica
74
i servizi. L’accessibilità remota, infine,
permette di considerare l’esecuzione di
quelle azioni che sono invocate via rete
su risorse situate su nodi differenti.
Nel nostro modello gli effetti dell’ese-
cuzione di un’azione su una risorsa sono
tenuti in conto tramite opportune post-
condizioni. Un esempio di post-con-
dizione è l’acquisizione di un accesso
locale alle risorse ospitate da un disposi-
tivo dell’impianto a seguito dell’esecu-
zione con successo di un’operazione di
login sul dispositivo stesso.
Nel modello d’impianto prototipale gli
slave Modbus ospitano la risorsa “web_
server” che consente la configurazione
remota del dispositivo tramite l’azio-
ne “amministra”. La stessa risorsa con-
sente di avviare il funzionamento con-
venzionale dello slave tramite l’azione
“opera”. L’operazione “amministra” è
soggetta al soddisfacimento di una pre-
condizione di tipo “remoto” con speci-
fici parametri di comunicazione (porta/
protocollo). L’operazione richiede inol-
tre una credenziale e non ha particolari
post-condizioni. L’azione “opera”, è de-
scritta in modo simile ma prevede diffe-
renti parametri di comunicazione e non
richiede il possesso di credenziali.
Un altro esempio è costituito dalla risor-
sa “sistema operativo” di ogni PC collo-
cato nell’area di processo. L’operazione
“login”, per essa definita (<login, siste-
ma_operativo>), richiede quale precon-
dizione l’accesso fisico al PC e il pos-
sesso di una password appropriata (cre-
denziale) al fine di far ottenere all’uten-
te che la esegue con successo un accesso
locale alle risorse del dispositivo (post
condizione).
Verifica delle policy di accesso
La costruzione delle due viste del
modello, consente di condurre un’a-
nalisi semi-automatica del corretto
mapping tra le policy di alto livello e
la configurazione dei dispositivi. L’a-
nalizzatore software, infatti, utilizza la
vista specifica (descrizione dei ruoli,
loro gerarchia, utenti, permessi associati
ecc.) per enumerare tutti i permessi in
possesso di ogni utente del sistema in
base ai ruoli assegnati.
La vista implementazione, invece, è uti-
lizzata per costruire l’insieme di tutte le
possibili azioni da parte di tutti gli utenti
sulle risorse del sistema. Il procedimento
seguito in questo caso è più complesso,
dovendosi considerare la situazione del
sistema e delle sue interazioni con gli
utenti, da un punto di vista sia statico
sia dinamico. Senza entrare in dettagli,
lo strumento software costruisce un dia-
gramma esaustivo di tutte le possibili
sequenze di azioni che ogni utente può
compiere sulle risorse del sistema utiliz-
zando, per far ciò, la descrizione statica
del sistema stesso e un insieme di regole
(regole di inferenza) che dettano il com-
portamento dell’utente e le sue modalità
di interazione con i vari oggetti a cui
può accedere. In pratica, l’analisi di cia-
scuna vista produce un insieme di triple
del tipo <oggetto, operazione, utente>
relative alle sole azioni permesse rispet-
tivamente dalla specifica e dall’imple-
mentazione. Il confronto dei due insiemi
di triple permette quindi di evidenziare
eventuali differenze (violazioni) tra ciò
che è definito come “lecito” nella spe-
cifica e quello che invece è realmente
consentito nel sistema reale.
Ad esempio un comune utente Carneade,
che a livello di specifica non è previsto
possegga i permessi <amministra, web_
server> e <opera, web_server> relativi
agli slave Modbus del sistema reale,
potrebbe riuscire ad eseguire le suddette
operazioni utilizzando legittimamente il
nodo PC in Area1. La prima condizione
sarebbe resa possibile se l’accesso al
servizio “web_server” utilizzasse la pas-
sword di default, cioè una credenziale
nota a tutti (le password di default sono
note a tutti gli utenti per definizione). La
seconda violazione potrebbe verificarsi
in assenza di idonei filtri di comunica-
zione tra l’area di processo (Area1) e
l’area di campo (Cabinet X). L’utente
Carneade, infatti, può accedere leci-
tamente al PC di Area1 e, conseguen-
temente, agli slave Modbus tramite il
canale di comunicazione diretto con l’a-
rea di campo che non è esplicitamente
filtrato. Per correggere simili violazioni,
identificabili dall’analizzatore, è pos-
sibile modificare le configurazioni dei
servizi coinvolti, ad esempio cambiando
la password di default per “web_server”
e/o introducendo dispositivi filtranti
(firewall) per impedire le comunicazioni
tra il nodo PC e i dispositivi ospitati nei
cabinet. In ogni caso, tuttavia, l’effetto
di una modifica deve essere preventiva-
mente verificato con un nuovo passo di
analisi.
Conclusioni
La sicurezza dei sistemi distribuiti di
controllo e automazione richiede lo svi-
luppo di soluzioni tecniche innovative,
in grado di tenere in considerazione le
peculiarità e i requisiti tipici delle appli-
cazioni industriali. Quest’articolo ha
introdotto le caratteristiche salienti di
un nuovo modello in grado di descri-
vere contemporaneamente le due possi-
bili viste (specifica e implementazione)
di un sistema ICS per quanto attiene
la definizione delle policy di controllo
d’accesso. Su tale modello si fonda lo
sviluppo di strumenti software di ana-
lisi automatica che operano mediante
opportuno confronto delle viste. In que-
sto modo è possibile evidenziare e cor-
reggere possibili differenze (violazioni)
tra la definizione delle policy di accesso
ad alto livello e la configurazione dei
meccanismi di sicurezza a basso livello
presenti nel sistema reale.
Bibliografia
[1]
M. Cheminod, L. Durante, and A.
Valenzano, “Review of Security Issues
in Industrial Networks,”
IEEE Trans.
Ind. Informat.
, Vol. 9, n. 1, pp. 277-293,
2013.
[2]
Ansi Incits, “Role Based Access
Cotnrol”,
Ansi Incits,
359/2012, 2012.
[3]
R. S. Sandhu, E. J. Coyne, H. L.
Feinstein, and C. E. Youman, “Role-
Based Access Control Models,”
IEEE
Computer
, vol. 29, n. 2, pp. 38–47,
1996.
[4]
M. Cheminod, L. Durante, L. Se-
no, and A. Valenzano, “On the Descrip-
tion of Access Control Policies in Net-
worked Industrial Systems”,
Proc. of
the 10th IEEE Int. Workshop on Factory
Communication Systems
(WFCS 2014),
pp. 1-10, 2014
■
RINGRAZIAMENTI
Questo lavoro è stato svolto nell’ambito del
Progetto Bandiera CNR “Fabbrica del Futuro”
- sottoprogetto “Generic Evolutionary Control
Knowledge-based mOdule” (GECKO).
