PCI DSS 3.0 - Sono richieste restrizioni di SSH e / o RDP in uscita?

Question

PCI DSS 3.0 - Sono richieste restrizioni di SSH e / o RDP in uscita?

#1 da (1 voti)

1

Questa domanda appare molto mentre faccio valutazioni per clienti diversi. Attualmente raccomando quanto segue:

Tutto in uscita SSH e amp; RDP bloccato per impostazione predefinita dalla rete utente (non CDE)
Tutto in uscita SSH e amp; RDP bloccato per impostazione predefinita dalla rete di produzione (non CDE)
Tutto in uscita SSH e amp; RDP bloccato per impostazione predefinita da Card Data Environment (CDE)
Tutto in uscita SSH e amp; RDP per le aziende richiede ticket di controllo delle modifiche e ticket delle eccezioni

Cito PCI DSS 3.0 sezione 1.2.1 come giustificazione. Tuttavia, non è esplicitamente dichiarato che questo è richiesto. Ricevo ulteriore conferma del fatto che questo è troppo lontano.

Motivi per i requisiti nelle mie conclusioni:

SSH consente la connessione in uscita dagli host pivot delle comunicazioni sicure, soprattutto se connessi alla produzione
La disabilitazione dovrebbe far parte di una strategia di protezione DLP
Segue i principal di deny-all per maggiori protezioni
Impedisce il chiaro di luna ad altri clienti / clienti durante il tempo in cui questa società

Ma ci sono dei requisiti espliciti, che possono essere articolati, che PCI DSS richiede questo modello?

ssh pci-dss

posta hackajar 13.11.2014 - 19:03

fonte

1 risposta

Leggi altre domande sui tag ssh pci-dss

Microsoft OneNote viene rilevato come malware Mail usa e getta per l'anonimato

score 1 · Accepted Answer

È possibile isolare completamente la rete utente e la rete di produzione dal CDE, ad esempio un compromesso totale dell'ambiente non CDE non può in alcun modo compromettere, ridurre la sicurezza o, in qualche altro modo, influire sull'ambiente CDE.

Se lo fai, la rete utente e la rete di produzione saranno considerate al di fuori dell'ambito PCI.

Tuttavia, la sua buona igiene del computer blocca ancora il default in uscita SSH / RDP per impedire al malware di "telefonare a casa". Ma isolando il CDE dall'ambiente non CDE per ottenere fuori campo per la rete utente e di produzione, non è necessario avere procedure "rigide" per l'apertura delle porte. Ad esempio, non è necessario seguire le procedure PCI-DSS per aprire le porte sulla parte non-CDE della rete.

Quindi puoi chiudere SSH / RDP, ma quelli che hanno bisogno di SSH / RDP per le aziende devono semplicemente telefonare e avere la porta aperta di fronte a loro.

Quindi posiziona il CDE con il proprio firewall, su una connessione Internet WAN pubblica e sulla rete di produzione / utente della rete, su un'altra connessione WAN con il proprio firewall. Ciò renderà la rete CDE e la rete utente / di produzione completamente separate.

Nessuna parte della rete utente o di produzione può essere autorizzata a passare il firewall CDE, Tutto prima che il firewall CDE venga trattato come WAN quando si parla di conformità PCI-DSS.

Si noti che anche il firewall CDE deve essere inserito all'interno dei limiti fisici dell'ambiente CD-DSS PCI, in modo che il firewall CDE stesso abbia la stessa sicurezza fisica dell'ambiente CDE.

Si noti che la parte "moonlighting" non è definita da PCI-DSS. PCI-DSS riguarda la protezione dei tuoi clienti, non te stesso. Guadagnando fuori campo per la tua rete di utenti e di produzione, non devi preoccuparti di proteggere i tuoi clienti mentre giochiamo con la rete di utenti e di produzione, devi solo preoccuparti di te.

Quindi, se si desidera avere una protezione "al chiaro di luna", è compito dell'azienda. Non hanno bisogno di pensare un po 'più a proposito di PCI-DSS quando si gioca con la rete utente / di produzione se l'ambiente CDE è correttamente segmentato.