abbiamo chiuso il post precedente parlando di come possiamo pensare alla nostra struttura interna al fine di implementare un processo di security per la navigazione web.
qualsiasi ragionamento si possa fare rimane legato alla seguente fondamentale questione:
quali sono le policy di riferimento di sicurezza interne?
paradossalmente senza direttive di sicurezza chiare qualsiasi approccio di sicurezza risulta abbastanza inutile.
“La sicurezza è un processo, non un prodotto” (Bruce Schneier)
Cosa si può e non può fare deve risultare da un set coordinato di processi di cui la soluzione di sicurezza è solo uno degli aspetti. Qualsiasi introduzione di tecnologia comporta una variazione delle procedure di sicurezza in termini di comportamenti, ma anche remediation e mitigation.
In questo senso le componenti di compliancy e DLP del security policy book devono essere modificate per tenere traccia della introduzione delle nuove tecnologie di sicurezza.
Purtroppo è uso comune non avere un security policy book anche nelle organizzazioni più avanzate, e soprattutto di solito la sicurezza informatica è considerata una componente estranea alle altre procedure di sicurezza.
Auditing, reporting e strumenti di sicurezza invece sono da intendere come una struttura unica che si interfaccia con le varie componenti della attività aziendale.
Un esempio classico di questa tendenza a tenere separate, per oscuri motivi, le varie componenti di sicurezza è dato dalla mail.
Quasi tutte le realtà danno delle limitazioni all’uso della mail; i vincoli più comuni sono:
- dimensione massima della mailbox – per risparmiare spazio di storage tipicamente
- dimensione massima del messaggio di posta – qui le giustificazioni sono le più disparate, dal consumo di banda al risparmio di storage a, mi si blocca l’antivirus, sic
- massimo numero di destinatari per mail – qui di solito ci si appoggia ai default dati dai vari server di posta che sono, solitamente, un mix tra la esigenza di evitare lo spamming ed il mantenere le prestazioni ad un livello accettabile.
- limitazione sul tipo di attachment –tipicamente vengono banditi gli eseguibili nelle varie forme e talvolta i file compressi 🙁
- limitazione tramite filtri antispam eo antivirus.
le considerazioni e le inerenze di queste policy si estendono ovviamente alla sicurezza come nel caso degli attachment di posta eseguibili, o addirittura vincoli di DLP, si pensi alla compliancy PCI.
Curiosamente non viene utilizzato lo stesso criterio per le webmail private cui speso si concede l’accesso agli utenti.
è prassi comune mandarsi grossi attachment tramite account Google e magari zip ed eseguibili, mentre la cosa non risulta possibile via posta aziendale. E questo anche per uso aziendale in barba alle norme di sicurezza implementate.
Il risultato è avere delle policy di sicurezza asimmetriche e non omogenee.
Una politica corretta di security dovrebbe prevedere un approccio alle webmail comparabile a quello definito per la mail standard, il che significa porre una serie di limitazioni analoghe: limitazioni sul tipo e dimensione degli attachment, filtri antivirus e antimalware e cosi via.
Per fare ciò la soluzione di web security deve essere in grado di discriminare il traffico inerente alle webmail, ad esempio tramite url filtering, ma, soprattutto, essere in grado di:
1) limitare la dimensione degli oggetti di cui si consente il download tramite httpftp
2) limitare il tipo di oggetto di cui si consente il download
3) essere in grado di effettuare la operazioni prima del raggiungimento della postazione client
4) poter effettuare questa operazione anche su flussi HTTPS
la ragione del primo e secondo punto sono evidenti, vanno a fare match con le esigenze di compliance gestite per la posta tradizionale.
Il terzo e quarto punto traggono origine dal fatto che queste analisi, in particolare le analisi antimalware, raggiungono la maggiore efficacia se effettuate per layer con tecnologie differenti. Il tipo di protezione al client dovrebbe essere diverso per tecnologia e modalità di uso dal tipo di protezione lato gateway. Va da se che la ispezione HTTPS è necessaria per permettere di evitare che i contenuti indesiderati siano consegnati al punto di arrivo senza ispezioni di sorta.
Del resto evitare che arrivi sull’end point un oggetto non conforme è uno dei punti focali delle policy di sicurezza.
Curiosamente però questo aspetto viene di solito non considerato.
Ciao
A
Nessun commento:
Posta un commento