Buongiorno a tutti,
sto supportando un cliente nella stesura del documento, e sorgono alcuni dubbi:
3.4.1 Eseguire tutte le operazioni di amministrazione remota di server, workstation, dispositivi di rete e analoghe apparecchiature per mezzo di connessioni protette (protocolli intrinsecamente sicuri, ovvero su canali sicuri).
Per i dispositivi che non supportano protocolli sicuri (es. router di vecchia generazione che accettano solo Telnet) è sufficiente dichiarare di preparare un piano che valuta impatti, costi e benefici della loro sostituzione, o è richiesto che vengano sostituiti subito?
4.5.1 Installare automaticamente le patch e gli aggiornamenti del software sia per il sistema operativo sia per le applicazioni.
E’ richiesta l’installazione automatica delle patch anche sui sistemi e le applicazioni in produzione, lato server (non PdL)? Dato che questo è molto critico in termini di continuità del servizio, non è sufficiente scrivere una procedura che descrive modalità e tempi per il controllo e l’applicazione della patch rilasciate?
5.1.2 Utilizzare le utenze amministrative solo per effettuare operazioni che ne richiedano i privilegi, registrando ogni accesso effettuato.
Posto che gli ambienti di sviluppo e collaudo sono distinti sia come utenze sia per i dati da quelli di produzione, è sufficiente registrare le operazioni solo in ambiente di produzione?
5.7.4 Impedire che credenziali già utilizzate possano essere riutilizzate a breve distanza di tempo (password history).
Laddove il sistema non impedisca in automatico il riutilizzo delle vecchie password, è sufficiente emanare una policy che vieti il riutilizzo delle ultime tre password utilizzate?
8.1.1 Installare su tutti i sistemi connessi alla rete locale strumenti atti a rilevare la presenza e bloccare l’esecuzione di malware (antivirus locali). Tali strumenti sono mantenuti aggiornati in modo automatico.
Tutti i sistemi? Anche UPS, condizionatori, telecamere ecc. che hanno un indirizzo IP? E se non supportano l’installazione si richiede di cambiarli?
Grazie
Maurizio Sapora
Premessa: il piano deve indicare la tua situazione “ALLA DATA IN CUI STAI REDIGENDO L’ALLEGATO”.
Quindi dici quello che c’è in questo momento.
Nel tuo caso, io personalmente direi: tutti gli apparati che supportano il protocollo SSL (HTTPS, TELNETS) sono stati abilitati e bloccati per il normale traffico non cifrato.
Gli apparati più vecchi che non supportano tale protocollo e non hanno firmware che permettano l’upgrade, verranno progressivamente sostituiti compatibilmente con le disponibilità economiche e criticità dell’apparato.
Dall’esterno, gli accessi avvengono unicamente tramite VPN
nota a margine: questa regola secondo me è scritta male e intende "tutte le attività che vengono effettuate DA FUORI DELLA RETE LAN. Tuttavia essendo scritta così, non si può interpretare
Il mio punto di vista è giocare sulla parola automaticamente: automaticamente si installano, dopo che manualmente sono approvate sul sistema WSUS oppure cliccando su “installa aggiornamento” sulle singole postazioni
No.
Tutto il lavoro (non solo questo punto) deve essere appoggiato a un disciplinare che deve essere approvato.
Grazie della risposta Alessandro, ma mi rimangono alcune perplessità:
3.4.1 OK, dichiaro che valuterò compatibilmente…ma il requisito non mi dà l’opzione di valutare, quindi così come è rimango non compliant: chi mi assicura che a fronte di un incidente la mia dichiarazione venga ritenuta sufficiente? E’ vero che non ci sono sanzioni, ma uno si aspetta che se mi dai una regola tu mi chieda anche di rispettarla.
4.5.1 Se si tratta di PdL il discorso può essere affrontato, ma come sai in ambienti complessi di produzione a volte le patch ad esempio sul DB non possono essere installate pena il funzionamento magari di un’applicazione, oppure a volte non puoi patchare il virtualizzatore perché magari il sistema ospitato poi ha problemi … quindi io non conosco nemmeno un cliente che automatizza il rilascio delle patch sui server, sui DB e sulle applicazioni di produzione. Ha senso richiedere che venga fatto, senza specificare in dettaglio? Anche qui, se le misure mi chiedono di farlo immagino che ci si aspetti che lo si faccia…
5.1.2 Qui c’è un discorso generale: gli ambienti di sviluppo e collaudo spesso non hanno, per questioni di budget, disponibilità degli stessi strumenti disponibili in produzione, quindi richiedere lo stesso livello di sicurezza in questi ambienti è piuttosto oneroso. Mi chiedevo se non fosse sufficiente assicurare che gli ambienti sono segregati, le utenze che operano in sviluppo e collaudo non sono le stesse che accedono in produzione e che in sviluppo e collaudo non risiedono informazioni di produzione e/o dati soggetti a RID. In questo caso l’exploit di una vulnerabilità non avrebbe impatto sulla produzione; ma anche qui, se la norma mi chiede una cosa, io in teoria la devo soddisfare, sobbarcandomi i costi non banali per allineare le contromisure allo stesso livello di quelle di produzione.
5.7.4 Non ho capito la risposta: mi stai dicendo che il sistema di policies approvato e pubblicato è ritenuto adeguato laddove la contromisura non può essere implementata per via tecnologica?
8.1.1 a me pare un caso analogo alla 3.4.1 ovvero si tratta di capire se dove i vincoli tecnologici impediscono l’applicazione della misura è sufficiente dichiararlo e documentarlo o viene richiesto il loro superamento anche a costo di cambiare il dispositivo non compliant
Purtroppo non potremo mai saperlo finchè non arriverà un giudice a deciderlo.
Ad ogni modo tu metti l’attuale condizione, altro non puoi fare.
Oppure prendi e compri gli switch nuovi.
Alternative non ne vedo
Allora condivido in toto (vedi mio post).
Se non puoi farlo, e specificatamente sai che quella patch non puoi applicarla, documenti il rischio e lo consideri accettabile.
In soldoni “la macchina XY che contiene il prodotto AYZ non verrà patchata in modo automatico in quanto è necessaria di volta in volta una valutazione umana, pena il blocco dell’intero sito produttivo”.
Che poi a me lascia perplesso come si possa automatizzare il deploy delle patch di java, di acrobat, di flash, ecc…
Io credo che gli ambienti di test siano un sistema “a se stante”.
Se dovressi guardare la norma strettamente, direi “no, devi per forza implementare il log degli accessi”.
Visto che parli di ambiente di test, imho si può leggermente defilare motivando nella colonna.
Magari, considerando che il problema degli exploit riguarda fondamentalmente l’intrusione e, in caso di test, di furto del dato, documenterei che l’ambiente di test non userà mai dati presi dall’ambiente di produzione (penso ad esempio a tentativi di conversione di un ambiente di anagrafe) e che la rete è completamente separata.
Penso siano misure più che sufficienti. Altre idee non ne ho.
Ritengo che se guardi il punto sullo share cifrato (13.1.1) siamo del gatto se io tiro su un bellissimo disco di rete con lo stato dell’arte della crittografia, ma poi resta inesorabilmente vuoto perchè i colleghi caricano tutto, chessò, su dropbox.
Quindi è indubbio che i colleghi andranno istruiti, avvertiti e formati, a valle di un disciplinare che deve essere approvato.
Non so dirti se la misura sia sufficiente, di certo aiuta in caso di controllo.
Inoltre valuterei di far modificare quei sistemi che non permettono di gestire la password history (per curiosità potresti dirmi quali? onestamente ne conosco pochi…)
Può essere. Il quesito è: se un NAS (tipo qnap o sinology per non fare nomi) ha un vero e proprio S.O. che gira, può il sistema di controllo dell’ups essere considerato tale per cui possa essere infettato da software malevolo? (si certo raspberry docet…)
I QNAP e Synology vanno aggiornati, vengono rilasciate regolarmente delle patch di sicurezza dai produttori (purtroppo se usi QNAPo Synology come sistema di storage per le VM iniziano le rogne in quanto quasi sempre risulta necessario effettuare un riavvio a fine aggiornamento e questo significa fermare tutte le VM per il tempo necessario all’aggiornamento).
Per quanto riguarda quanto hai scritto nel thread riguardo al firmware degli ups, io direi dipende:
se le interfacce degli ups sono collegate alla rete lan i firmware vanno aggiornati, con tutti gli eventuali scazzi che ne possono derivare
se le interfacce degli ups sono “isolate” (ad esempio in una rete a parte protetta da un fw, es. il tuo gateway) è sufficiente indicarlo nelle misure minime di sicurezza specificando che i firmware di tali apparati non vengono aggiornati per evitare potenziali problemi e conflitti con i sw utilizzati per il monitoraggio degli ups e che gli stessi sono opportunamente protetti da un fw (della serie: almeno dove posso, dove le cose funzionano, non tocco nulla !).
Io aggiungerei alla categoria degli UPS anche le interfacce ILO dei server.
Ciao Marco, hai ragione sul discorso firmware ma la misura dice “Installare su tutti i sistemi connessi alla rete locale strumenti atti a rilevare la presenza e bloccare l’esecuzione di malware”.
Quindi mi chiedo “come posso installare un antivirus (su di un ups attaccato in rete)?”