Salve! Posso darti maggiori informazioni
o rispondere a qualche domanda?
Come possiamo esserti utili?
Seleziona uno dei nostri esperti
Alberto Bedin
Supporto Commerciale
Sono online
Luisa Soranno
Supporto Commerciale
Sono online

Le minacce informatiche esterne stanno crescendo in volume e complessità. 

Ma non si dovrebbe trascurare il danno che gli addetti interni ai lavori possono, e fanno alle aziende ogni giorno. 

L'esperta di sicurezza Carol Woodbury ha recentemente condiviso 11 modi in cui i professionisti IBM i possono proteggere il server dalla minaccia reale posta dagli addetti ai lavori.

Woodbury, che è il vicepresidente dei servizi di sicurezza globali presso HelpSystems e in precedenza era l' architetto capo della sicurezza di IBM per l'AS/400, afferma che i aziende con IBM i si lasciano inconsapevolmente aperti agli attacchi interni attraverso una combinazione di disattenzione, incoscienza, fretta e una generale mancanza di comprensione del funzionamento dell'apparato di sicurezza della piattaforma.

"Ci sono molte cose che gli amministratori fanno nel corso della loro attività che potrebbero non pensare al fatto che sta lasciando i sistemi vulnerabili", ha detto Woodbury in un webinar di HelpSystems del 7 febbraio intitolato "Mitigazione della minaccia interna nel IBM i World.”

Ma non deve essere così. Nel webinar, Woodbury ha offerto 11 modi in cui gli amministratori IBM i possono ridurre la superficie di attacco e proteggere in altro modo il server IBM i dalle minacce interne:

Rifinire le autorità speciali

Se c'è una cosa che farà impazzire i professionisti della sicurezza di IBM i, è l'uso eccessivo di autorità speciali, come SPLCTL, JOBCTL e la più grande, ALLOBJ. E quando i profili utente comuni ricevono queste autorizzazioni speciali, il sistema può subire rapidamente gravi danni, ingannando sia i neofiti che i cattivi spietati.

"A QSYSOPR, QUSER, QPGMR viene spesso concessa più autorità di quella con cui vengono spediti e, quando ciò accade, ciò può spesso presentare agli utenti più autorità di quanto si intendesse realmente", afferma Woodbury. “[QPGMR] è anche il proprietario di molti fornitori di software, quindi questo significa che il software del fornitore potrebbe funzionare con più capacità di quanto dovrebbe. Cerchiamo davvero di aiutare i nostri clienti a comprendere i pericoli di questo e rimuoverli quando possibile".

Usa l'open source con cautela

Tutti sanno che IBM i ha una sicurezza a prova di proiettile, grazie alla sua architettura orientata agli oggetti, ed è praticamente impermeabile a tutti i malware che affliggono le macchine X86, giusto? 

Sfortunatamente, il server IBM i è più vulnerabile alle minacce alla sicurezza "comuni" di quanto si possa pensare.

"Amiamo tutti il ​​fatto che il nostro amato sistema, IBM i, sia moderno e supporti tutte le tecnologie più recenti e recenti, comprese le applicazioni Web, PHP, tutti i linguaggi per accedervi, Python e così via", spiega Woodbury. “Ma il fatto è che, nel supportare quelle tecnologie, emergono anche le vulnerabilità ad esse associate. Quindi, le app Web eseguite su IBM i sono soggette a scripting tra siti, errori di SQL injection e l'elenco potrebbe continuare."

Woodbury si rallegra del fatto che molte aziende stiano migliorando il loro gioco di sicurezza e utilizzando scanner di vulnerabilità delle applicazioni Web per identificare app codificate male che potrebbero lasciare i loro server X86 aperti agli attacchi di minacce interne ed esterne.

"Il problema è che molte persone saltano le applicazioni in esecuzione su IBM i", afferma. "E non dovrebbero essere ignorati, perché è possibile codificare e inserire un errore di SQL injection, se la pagina Web è codificata in modo errato, con la stessa facilità su IBM i come su Linux."

Ransomware e malware:attenti alle cartelle condivise dell'IFS

Grazie alle unità di rete mappate e alla propensione dei aziende con IBM i a condividere l'accesso root, è in realtà molto facile per un pezzo di ransomware o malware basato su PC infettare l'IFS, afferma Woodbury.

Il ransomware può atterrare sulla tua unità cartelal condivisa di IFS.

"Se qualcuno è mappato su root e il suo laptop o PC è infetto da ransomware, a quel punto qualsiasi unità mappata assomiglia a qualsiasi altra unità sul PC", afferma Woodbury. "E il ransomware non è diverso dal fatto che si tratta di un IBM i, quindi può attraversare e iniziare a crittografare quelle directory."

Autorità adottata

Sarebbe difficile trovare un fan dell'autorità adottata più grande di Carol Woodbury. Il professionista della sicurezza lo applica liberamente nei suoi impegni con i clienti perché, se utilizzato correttamente, può effettivamente ridurre l'esposizione di sicurezza di un sistema IBM i.

"Sono un grande fan dell'autorità adottata", afferma Woodbury. "Ci sono solo alcune cose di cui devi essere consapevole in modo da non propagare l'autorità adottata in luoghi che non intendi."

Se utilizzata in modo errato, l'autorità adottata potrebbe inavvertitamente consentire a un utente interno sofisticato l'accesso a una riga di comando, dove potrebbe fare cose che non dovrebbe essere in grado di fare, come accedere direttamente al database. "Dobbiamo assicurarci di non propagare l'autorità adottata fino alla riga di comando", afferma.

C'è un secondo avvertimento sull'autorità adottata che a volte porta fuori strada chi è attento alla sicurezza, e che ha a che fare con l'autorità di ALLOBJ. Secondo Woodbury, c'è un'errata percezione diffusa che un programma configurato per utilizzare l'autorizzazione adottata debba essere eseguito con un profilo utente che dispone dell'autorizzazione ALLOBJ.

"Il profilo che possiede i programmi che adottano non deve avere alcuna autorità speciale", afferma Woodbury. "Quindi fai attenzione a non autorizzare eccessivamente il profilo proprietario dei programmi che adotta".

Postazioni di lavoro non presidiate

Ottenere la sicurezza di IBM i nel modo giusto può essere difficile. Ci sono così tante manopole e interruttori da tenere sotto controllo che, troppo spesso, gli amministratori configurano male qualcosa, o semplicemente alzano le mani per la frustrazione e assecondano lo status quo (non sicuro). 

Quindi eccone uno facile e ha a che fare con la sicurezza fisica.

Non dimenticare di bloccare la tua postazione di lavoro quando esci.

"Se te ne vai, e labbandoni la postazione chiunque ha un parco giochi per fare tutto ciò che vuole, che verrà registrato come se l'avessi fatto tu", dice. Sarebbe la tua parola contro la parola del QAUDJRN e il QAUDJRN vincerà.

La soluzione: bloccare la tastiera quando non ci sei. Ottieni un timeout del dispositivo che disabilita automaticamente la workstation dopo pochi minuti e ti costringe a riaccedere. "Disciplina te stesso quando te ne vai", afferma Woodbury.

Rivedere gli account di servizio

Molti aziende con IBM i funzionano con una serie di account di servizio che sono stati installati molto tempo fa e che spesso vengono utilizzati più raramente. Il problema è che molti di questi account di servizio hanno ALLOBJ.

"Se riesci a disciplinarti per avere una revisione regolare dei programmi con ALLOJB, lo capirai piuttosto che aspettare una valutazione annuale del rischio o che qualcuno venga a vedere quel profilo che ha ALLOJB che probabilmente non ne aveva bisogno, "dice Woodbury.

I aziende con IBM i che hanno eseguito l'aggiornamento a IBM i 7.3 possono avvalersi di un potente strumento che aiuterà con gli account di servizio. La funzione di raccolta mostrerà automaticamente al responsabile della sicurezza una serie di informazioni pertinenti sugli account di servizio, incluse le autorità utilizzate, gli oggetti toccati e così via.

Applica quelle PTF!

IBM è davvero brava a rilasciare patch per correggere le vulnerabilità di sicurezza nel suo software. 

Sfortunatamente, i clienti non sono altrettanto bravi a stare al passo con le PTF e questo può lasciare i sistemi aperti a malintenzionati interni e criminali informatici da lontano. 

"Il mio incoraggiamento è di rimanere aggiornati sulle vostre PTF, siano esse PTF del sistema operativo, PTF Java o qualsiasi PTF che ha a che fare con la tecnologia open source, e certamente l'uso di SSL/TLS", afferma Woodbury. "Lasciare il sistema aperto quando c'è una patch per la vulnerabilità ti lascia sicuramente aperto per quella minaccia interna".

Evita le password predefinite

È doloroso leggere il rapporto annuale sullo "stato della sicurezza" di PowerTech e vedere quanti sistemi IBM i eseguono profili utente con password predefinite. Qualsiasi hacker degno del suo IBM i sa che la password predefinita è l'ID utente. Il problema della password predefinita è particolarmente critico quando si ha a che fare con addetti ai lavori potenzialmente squallidi che conoscono già la convenzione di denominazione per l'ID utente.

"Quando conoscono la convenzione di denominazione del nome utente, conoscono metà dell'equazione", afferma Woodbury. “E se ci sono profili con password predefinite, hanno anche la seconda metà di quell'equazione. Ed è molto facile da provare".

Blocca le partizioni di prova

Gli sviluppatori spesso creano copie dei dati di produzione e utilizzano tali dati per testare nuove applicazioni o modifiche alle applicazioni esistenti in una LPAR di sviluppo o test separata. Questa è una parte necessaria del processo di sviluppo, ma troppo spesso i dati vengono lasciati vulnerabili.

"Posso affermare con sicurezza che per la stragrande maggioranza delle volte i dati non sono così protetti come in produzione", afferma Woodbury. “Una delle cose che ci piace fare è assicurarci che i dati siano protetti. Ciò include la rimozione di ALLOBJ per gli sviluppatori su un sistema di test".

Woodbury si avvale anche di nuove funzionalità che semplificano la crittografia e la mascheratura dei dati, come il field proc, che ha debuttato in IBM i 7.1, o il controllo dell'accesso a righe e colonne (RCAC), che ha debuttato in IBM 7.2.

La linea di fondo è che i dati devono essere protetti, ovunque si trovino. "O proteggilo allo stesso modo [del database di produzione] o prendi ulteriori misure per assicurarti che non sia disponibile nello stesso formato in cui è in produzione", afferma.

Attenzione allo Shadow IT

Li hai visti in agguato con i loro fogli di calcolo nell'ombra o nascosti sotto le loro scrivanie con le dashboard di Tableau . Sono le persone dello Shadow IT e stanno venendo a prendere i tuoi dati.

Lo chiami, stanno elaborando i dati in qualche modo”, dice Woodbury. “Ma stanno memorizzando quei dati in un modo che non è sicuro. Si dimenticano di bloccare la cartella su SharePoint. Oppure le informazioni crittografate su IBM i in genere non sono crittografate perché non seguono nessuna delle regole.

La soluzione: portare l'IT ombra alla luce, dove le regole possono essere applicate.

Attenzione all'IT dimenticato

Mentre alcuni schermi dimenticati aperti nelle vendite e nel marketing creano vulnerabilità.

Evitando di proposito il lungo braccio del CISO, lo squallido insider può anche avvalersi di dati e logica applicativi dimenticati da tempo.

Questo ha il pretesto di "Sei impegnato e non volevi lasciarlo così, ma ti sei completamente dimenticato di tornare e ripulire'", dice Woodbury. 

“Una delle cose che accade è che il processo fallisce, quindi viene assegnato ALLOBJ. Viene rieseguito e sei alla fase successiva e ALLOBJ non viene rimosso o l'autorità pubblica non viene nuovamente bloccata o il file di gruppo non viene rimosso dall'autorità.

È fondamentale rendere la sicurezza un principio architetturale di prim'ordine dei sistemi che stai costruendo, non un ripensamento o un mai pensato. "Per quanto puoi, aumenta la consapevolezza della sicurezza all'inizio di un processo, non alla fine", consiglia Woodbury, "e sottolinea il fatto che questo sta lasciando il tuo sistema vulnerabile e i tuoi dati aperti a perdita o furto di insider. "

Traduzione dell'articolo di IT Jungle Top 11 Ways to Protect Your IBM i from Insider Threats