GiuRus's Blog: Blogging on Technology & Security by Giuseppe Russo

Ci sono dei momenti della propria attività lavorativa nei quali si deve effettuare la scelta se adottare o meno un sistema operativo che sia certificato secondo lo schema Common Criteria. In questi casi  la prima domanda da farsi è se abbiamo davvero l'esigenza di inserire nel nostro ambiente un tale sistema. Se la risposta è sì allora occorre proseguire verso una scelta consapevole che non tenga conto solamente delle caratteristiche intrinseche della piattaforma, ma sopratutto che tipologia di Protection Profile sono associati al sistema operativo che sto valutando.

 

Una volta identificati i sistemi che meglio si adattano al nostro ambiente occorre evitare di fare un confronto di tipo funzionalità vs funzionalità in quanto il problema non è andare a verificare cosa fa uno e cosa fa l'altro. Invece occorre considerare l'ambiente nel il sistema Common Criteria compliant sarà esercito ed in particolare bisogna considerare:

1. quale è lo scenario nel quale inserisco un sistema CC EAL4+?
2. a quale threat model sto facendo riferimento?

Ci sono degli ambiti dove un controllo accessi, seppur rigoroso, degli utenti autorizzati può non essere sufficiente. Se l'ambiente è caratterizzato da elevati requisiti di sicurezza, si pensi ad un ambiente dove occorre implementare sia politiche di sicurezza tipo Need to Know che una vera Separation of Duty, bisogna allora cominciare a guardare a quei sistemi nei quali sono stati formalmente verificati, secondo lo schema Common Criteria, i concetti di sicurezza sui ruoli e sicurezza multilivello.

Se quello precedente è il nostro scenario di riferimento capiamo che di conseguenza il Threat Model associato presenta una situazione nella quale bisogna sia impedire l'accesso ad utenti non autorizzati sia mitigare la possibiltà che utenti autorizzati sfruttino debolezze del sistema per ottenere accessi privilegiati allo stesso.

In un tale scenario di riferimento allora la scelta da fare non è "quale sistema o prodotto classificato devo adottare", ma "quali sono i protection profile che meglio si adattano al mio scenario di riferimento e al mio threat model" .

Dunque devo andare a d approfondire i contenuti dei Protection Profile.

Se si dà un occhiata all'interno, si vede che il protection profile CAPP (Control Access Protection Profile) afferma esplicitamente che il CAPP NON copre quelle situazioni nelle quali un utente autorizzato di un sistema tenti di usare tecniche e strumenti per innalzare, in modo non autorizzato, i suoi privilegi su quel sistema.

Il protection profile che rafforza e formalizza il concetto di sicurezza basata sui ruoli e i privilegi è il RBACC (Role Base  Access Control Protection Profile). Se un sistema certificato CC EAL 4+ ha associato un RBACPP significa che è stata formalmente verificata la sicurezza della gestione in sicurezza dei ruoli all'interno del sistema.

Infine se il sistema che sto andando ad adottare, per ovvie ragioni, deve poter essere utilizzato in modalità multilivello allora l'unico protection profile che mi garantisce un tale livello di utilizzo è il LSPP (Labelled Security Protection Profile).

Riassumendo, se la scelta di un sistema certificato va fatta in funzione di dello scenario di riferimento e del thread model allora deve essere una scelta strategica di una organizzazione. Pertanto non ha senso concentrarsi su funzionalità di base che più o meno tutti hanno o possono avere con pochi investimenti, ma bisogna guardarsi intorno e capire chi ha invistito sulla certificazione CC e a che livello.

Detto questo consideriamo il caso del sistema operativo Solaris 10:

1. Solaris 10 CC EAL4+. Solaris 10 CC EAL 4+ possiede tre protection profile sullo stesso sistema operativo (CAPP, RBACPP, LSPP). Sun ha investito sulle certificazioni di sicurezza a partire dal 1990 passando per Orange  Book, ITsec, Common Criteria assicurando la contunità delle stesse e l'accurata associazione HW/SW certificato. Inoltre le architetture Sun Microsystems basate su Solaris Certificato CC sono state accreditate in diversi ambiente di Intelligence secondo le direttive Director of Central Intelligence Directive 6/3 (DCID) with Protection Levels 4 and 5 (PL4 and PL5) e in multipli ambienti DOD quali: Secret and Below Information (SABI) e Top Secret and Below Information (TSABI)
   

Inoltre occorre pensare non solo alle componenti di sicurezza coperte dai Protection Profile, ma anche di tutte quelle funzionalità di Sicurezza messe a disposizioni dal sistema per aumentarne la sicurezza intrinseca. Nel caso di Solaris si pensi a tutto il sottoinsieme di User and Process Privileg Management che va a rafforzare il già CC Certificato RBACPP. Ancora si pensi al Crypto Framework di Solaris 10 che consente di firmare i binari e mandarli in esecuzione solo se in accordo alla Politica di Sicurezza..... e tante tante altre funzionalità di Sicurezza.