Si ricorda che la maggior parte dell’alta Direzione Aziendale è convinta che l’affidabilità e la sicurezza dei propri server sia costantemente sotto controllo; una piccola statistica ci ha consentito di stimare che i Manager Aziendali siano convinti che il loro sistema si affidabile, dal punto di vista della sicurezza, oltre il 90%, mentre i criteri di sicurezza applicati all’IT erano limitati all’assegnazione di password individuali, e il profilo QPGMR aveva password conosciuta dalla maggior parte degli operatori IT.
Auditing standard?
Ogni operazione di Auditing applicata a qualsiasi server, iSeries compresi, è soggetta a specializzazioni e diversità dettate dall’ambiente operativo ed organizzativo del reparto IT .
D’altro canto è indiscutibile che vi siano delle regole generali al quale attenersi per realizzare, o attivare, un sistema di buona affidabilità e, soprattutto, un sistema di monitoraggio efficace, tempestivo e di semplice attivazione e consultazione.
E’ altresì importante evitare che, in un’ottica di esasperata applicazione dei sistemi di protezione, si proceda con applicazione di norme e regole severe, le quali di fatto possono "blindare" il sistema, causando un blocco delle attività.
Sicuramente, quindi, la soluzione ancora una volta sta nel mezzo: una serie di restrizioni per sanare le falle maggiori, accompagnata da un severo sistema di monitoraggio e verifica costante. L’applicazione di questa duplice formula di Auditing costituisce inoltre sia un metodo di dissuasione ad eventuali azioni di malintenzionati, sia il richiamo a un’attenzione costante alla sicurezza da parte degli operatori IT.
Il prodotto software di gestione dell’Auditing e della Security
Edoss Consulenze è una software-house italiana con sede in Milano. Il nome Edoss è un acronimo che riflette la propria attività anche nel campo della sicurezza logica dei sistemi e della relativa consulenza in merito. Edoss Consulenze possiede dei prodotti finalizzati al controllo del iSeries IBM, oltre al sistema di generazione e manutenzione della Documentazione del Software iSeries ottenibile anche mediante processi di reverse engineering.
Il prodotto base per il controllo e l’Auditing iSeries è: Audit Master 400
Il prodotto per la generazione e la documentazione del software applicativo è: DocMaster 400
Il prodotto Audit Master 400 assolve a numerosi compiti; I principali sono qui evidenziati (l’indicazione "soon" significa che alla data odierna la funzione è in fase di completamento oppure di test, quindi disponibile entro breve tempo):
Edoss Consulenze mette inoltre a disposizione il suo know-how culturale per l’attivazione dei sistemi di protezione applicabili agli iSeries. A tal fine esiste una check-list delle principali azioni da intraprendere per limitare i pericoli e i danni.
La check list è fornita congiuntamente al prodotto Audit Master 400.
Segue la lista delle principali funzioni di Security e Auditing di Audit Master 400.
| Problema | Report | Interattivo |
|---|---|---|
| Identificare I DB files e le librerie di programmi che non sono stati salvati secondo pianificazione, evidenziando gli oggetti non salvati |
☑ | |
| Identificare ed evidenziare gli User Profile che hanno accesso non ristretto al sistema |
☑ | |
| Identificare gli User Profile che hanno privilegi (gestione della data security controls) |
☑ | |
| Evidenziare gli User Profile che non sono stati utilizzati nelle ultime settimane (probabilmente sono Profili che possono essere cancellati o disabilitati) |
☑ | |
| Identificare gli User Profiles che possono aprire più sessioni di lavoro contemporaneamente (un sistema che concede accessi multipli contemporanei è un sistema non affidabile) |
☑ | |
| Evidenziare i tentativi di sign-on falliti per User Profile e/o Password errati |
☑ | |
| Generare una lista di tutti I programmi e files di nuova creazione o ri-creazione, oppure ripristinati da un precedente salvataggio rispetto l’ultima analisi di Auditing |
☑ | |
| Evidenziare i programmi che sono stati cancellati o rigenerati rispetto l’ultima di Auditing |
☑ | |
| Identificare i profili di Auditing o di "Emergenza" (di I e II livello) per monitorare gli utilizzi ed le azioni compiute (comandi) |
☑ | |
| Evidenziare i dati che sono stati variati, da quale Utente e in quale data, mediante utilities quali il DFU, UPDDTA, KUPDF, ecc. (alcune utilities non consentono il log dei dati) |
☑ | |
| Evidenziare tutti i messaggi di sistema che sono stati prodotti da operazioni che hanno comportato delle "Security Failure" (dati/oggetti) |
☑ | |
| Evidenziare le istruzioni e le circostanze (chi e quando) di creazione, cancellazione, modifica oggetti e profili eseguiti dalla riga comandi, dall’SQL, da CLP ed altre utilities |
☑ | |
| Prossimi nuovi rilasci, upgrades ed implementazioni | ||
| Evidenziare in un log storico l’utilizzo del Query | ||
| Identificare i database files molto grandi presenti sul sistema evidenziando da quanto tempo non sono utilizzati | Soon | |
| Identificare i database files che devono essere riorganizzati | Soon | |
| Generare una lista dei programmi iniziali eseguibili da ogni User Profile | Soon | |
| Generare una lista dei programmi iniziali eseguibili da ogni User Profile | Soon | |
| Gestione guidata per disattivare (*DISABLED) gli user profiles che non sono utilizzati da un certo numero di giorni |
☑ |
Una nuova attenzione
Esistono tre circostanze in cui si attiva un sistema di Auditing sui server iSeries:
- in via preventiva e proattiva, quando l’IT Manager rappresentando la volontà della Direzione Aziendale è consapevole dei rischi accidentali che possono colpire il sistema
- in via imposta quando esiste un sistema o servizio di Auditing Aziendale o di gruppo, talvolta anche su incarico della Direzione a Terze Parti consulenti, che impongono regole di controllo e monitoraggio della sicurezza applicata ai server
- in via "troppo tardi" in quanto è accaduto un incidente, in cui si sono verificate perdite o manipolazioni di dati critici, o più semplicemente per danni causati da ritardi nell’esecuzione di procedure applicative, rinviate a causa di lunghi tempi di ripristino dati.
Appare ovvio ed evidente che i casi 1 e 2 sono più semplici ed economici da gestire rispetto alla terza situazione; semplicemente anche per la mancanza di costi determinati da un incidente probabile e non ancora accaduto, quindi evitabile.
E’ da considerare con altrettanta importanza che la potenzialità di danno di un incidente è tanto più grande (e di maggior costo) quanto più grande e pervaso è il Sistema Informatico (o semplicemente il server centrale). Al crescere della complessità del Sistema Centrale cresce in misura esponenziale il costo di un incidente accaduto ai dati, o più in generale alla sicurezza.
Se un PC è attaccato da un virus o da un trojan è probabile che l’impatto in termini di danni e o disservizi sia poco rilevante (e quindi non incide sui costi), in quanto di norma i dati critici del business risiedono sul server (si confida che esso sia protetto almeno da un antivirus e da un firewall).
Diversamente, se un tecnico è arrabbiato col mondo intero ancorché con l’Azienda, oppure semplicemente si è distratto per un attimo di troppo, eseguendo ad esempio un comando CLRPFM (invece di DSPPFM) può causare un danno all’Azienda che comporterà dei costi relativi al ripristino dei dati al giorno prima (se ne era stato fatto il salvataggio), altri costi ingenti per il ricarico dei dati giornalieri, oltre ad altre perdite di economicità, non quantificabili monetariamente, per l’avvenuta mancata disponibilità del servizio dati (sospeso per l’incidente).
Conclusioni
Nel mondo dell’Auditing vi sono nove domande che consentono di determinare se l’EDP gode di un livello di sicurezza affidabile. Esse sono:
- Esistono dei controlli sulla sicurezza che limitano gli accessi a comandi di sistema sensibili? Il Security Officer è informato in caso di disattivazione di detti controlli?
- E’ possibile superare totalmente o parzialmente i controlli di sicurezza? Esiste la possibilità di sapere se tali controlli sono stati superati?
- Esistono sistemi di controlli per il monitoraggio dei cambiamenti e variazioni apportati al software applicativo? Si è informati puntualmente delle variazioni e delle eventuali eccezioni intenzionali e non?
- Esiste un controllo meccanico che identifica coloro che sono abilitati a superare o disattivare i controlli sulla security?
- Si ha certezza che tutti i dati e i programmi sono puntualmente salvati (back-up) su supporti affidabili e puntualmente archiviati in luoghi sicuri? Si conoscono quali sono i dati o programmi che per vari motivi non sono stati salvati secondo pianificazione?
- Si ha certezza che tutti i database files contenenti dati aziendali abbiano accessi consentiti a solo una ristretta e dovuta cerchia di utenti e non a "everyone" (public)?
- Vi è certezza che il software utilizzato per connettersi da un PC a iSeries sia sufficientemente controllato e che gli accessi (FTP, ODBC) sia sotto controllo?
- Se i sistemi di sicurezza del server è temporaneamente disattivata e successivamente riattivata, il Security Officer è informato dell’accaduto?
Se vi è possibile rispondere positivamente a tutte queste domande, la vostra organizzazione è probabilmente in "ottima posizione". Diversamente, già solo un solo NO, indica che dei cambiamenti sono necessari nel vostro sistema di sicurezza.
Audit Master 400 consente l’attivazione della maggior parte di sistemi che consentono di rispondere positivamente alle domande di cui in precedenza. Malgrado la complessità del tema, il nostro programma è molto semplice nell’utilizzo e nella presentazione dei dati risultanti. Inoltre offriamo una check list delle "cose da fare" per soddisfare la problematica della sicurezza sugli iSeries.
