Re: [ml] Hardening, si ma sempre? (cont. Mi hanno bucato il sever)

> Spesso e' piu' efficiente (nel senso costi/benefici)  semplicemente
> monitorare e reprimere il comportamento dopo, altre volte e' l'unica
> soluzione se non puoi toccare il codice di certi applicativi.

Dipende dal singolo caso concreto da valutare, comunque, in un contesto pià ampio di analisi e gestione dei rischi.

In ogni caso il monitoraggio e la repressione di cui parli possono essere pià utili con finalità di rafforzamento delle policies piuttosto che in un ottica di riduzione del rischio di violazione della confidenzialitÃ, integrità e disponibilità dei dati.

E poi secondo me à riduttivo parlare soltanto di applicativi in quanto, cosà facendo, si corre forse il rischio di dare per scontato che le interfacce software siano l'unico modo possibile di accedere ai dati.

> Mi riferivo proprio a questo. Che senso ha hardenizzare, nel senso di
> metter Grsec e Pax, una macchina interna se poi non hai capito a che
> serve e l'applicazione che ci installi (SAP/Oracle/ecc) ha buchi grandi
> come case che possono essere sfruttati per ottenere cio' che conta di
> quella macchina (I dati appunto contenuti in SAP/Oracle/ecc..) ?

Non ritengo corretto parlare delle tecnologie che hai citato in termini di semplici applicazioni.
Si tratta di tecnologie RDBMS di complessità tale da poter essere considerate dei sistemi informativi a sà stanti e per i quali potrebbe dunque aver senso parlare di un processo di hardening di cui la componente applicativa à solo un aspetto.

Stefano Bendandi
Socio ANIP,AIPSI