Un revisore della sicurezza per i nostri server ha richiesto quanto segue entro due settimane:

• Un elenco di nomi utente e password in chiaro per tutti gli account utente su tutti i server
• Un elenco di tutte le password modificate negli ultimi sei mesi, sempre in testo normale
• Un elenco di "tutti i file aggiunti al server da dispositivi remoti" negli ultimi sei mesi
• Le chiavi pubbliche e private di qualsiasi chiave SSH
• Una e-mail inviata a lui ogni volta che un utente cambia la propria password, contenente la password di testo normale

Stiamo eseguendo scatole Red Hat Linux 5/6 e CentOS 5 con autenticazione LDAP.

Per quanto ne so, tutto ciò che è in quella lista è impossibile o incredibilmente difficile da ottenere, ma se non fornisco queste informazioni dovremo perdere l'accesso alla nostra piattaforma di pagamenti e perdere entrate durante un periodo di transizione mentre passiamo a un nuovo servizio. Qualche suggerimento su come posso risolvere o falsificare queste informazioni?

L'unico modo in cui riesco a pensare di ottenere tutte le password di testo semplice è quello di indurre tutti a reimpostare la password e prendere nota di ciò che hanno impostato. Ciò non risolve il problema degli ultimi sei mesi di modifiche della password, poiché non riesco a registrare retroattivamente quel tipo di cose, lo stesso vale per la registrazione di tutti i file remoti.

Ottenere tutte le chiavi SSH pubbliche e private è possibile (anche se fastidioso), dal momento che abbiamo solo pochi utenti e computer. A meno che non abbia perso un modo più semplice per farlo?

Gli ho spiegato molte volte che le cose che sta chiedendo sono impossibili. In risposta alle mie preoccupazioni, ha risposto con la seguente email:

Ho oltre 10 anni di esperienza nel controllo della sicurezza e una piena comprensione dei metodi di sicurezza redhat, quindi ti consiglio di controllare i tuoi fatti su ciò che è e non è possibile. Dici che nessuna azienda potrebbe possedere queste informazioni ma ho eseguito centinaia di audit in cui queste informazioni sono state prontamente disponibili. Tutti i clienti del [fornitore di servizi di elaborazione di carte di credito generici] devono conformarsi alle nostre nuove politiche di sicurezza e questo audit ha lo scopo di garantire che tali politiche siano state implementate * correttamente.

* Le "nuove politiche di sicurezza" sono state introdotte due settimane prima del nostro controllo e la registrazione cronologica di sei mesi non era richiesta prima che le politiche cambiassero.

In breve, ho bisogno;

• Un modo per "falsificare" sei mesi di modifiche alla password e renderlo valido
• Un modo per "falsificare" sei mesi di trasferimenti di file in entrata
• Un modo semplice per raccogliere tutte le chiavi pubbliche e private SSH utilizzate

Se falliamo il controllo di sicurezza perdiamo l'accesso alla nostra piattaforma di elaborazione delle carte (una parte critica del nostro sistema) e ci vorrebbero due settimane buone per spostarci altrove. Quanto sono fregato?

Aggiornamento 1 (sabato 23)

Grazie per tutte le tue risposte, mi dà un grande sollievo sapere che questa non è una pratica standard.

Attualmente sto programmando la mia risposta via email a lui spiegando la situazione. Come molti di voi hanno sottolineato, dobbiamo rispettare PCI, che afferma esplicitamente che non dovremmo avere alcun modo per accedere alle password in chiaro. Pubblicherò l'e-mail quando avrò finito di scriverlo. Sfortunatamente non penso che ci stia solo testando; queste cose sono ora nella politica di sicurezza ufficiale dell'azienda. Tuttavia, per il momento, ho messo le ruote in moto per allontanarmi da loro e su PayPal.

Aggiornamento 2 (sabato 23)

Questa è l'e-mail che ho redatto, qualche suggerimento su cose da aggiungere / rimuovere / cambiare?

Ciao [nome],

Sfortunatamente non c'è modo per noi di fornirti alcune delle informazioni richieste, principalmente password in chiaro, cronologia delle password, chiavi SSH e registri di file remoti. Non solo queste cose sono tecnicamente impossibili, ma anche essere in grado di fornire queste informazioni sarebbe sia contro gli standard PCI, sia una violazione della legge sulla protezione dei dati.
Per citare i requisiti PCI,

8.4 Rendere tutte le password illeggibili durante la trasmissione e l'archiviazione su tutti i componenti del sistema utilizzando una crittografia avanzata.

Posso fornirti un elenco di nomi utente e password con hash utilizzati sul nostro sistema, copie delle chiavi pubbliche SSH e file degli host autorizzati (Questo ti fornirà informazioni sufficienti per determinare il numero di utenti unici che possono connettersi ai nostri server e la crittografia metodi utilizzati), informazioni sui nostri requisiti di sicurezza della password e sul nostro server LDAP ma queste informazioni potrebbero non essere rimosse dal sito. Ti consiglio caldamente di rivedere i tuoi requisiti di audit in quanto al momento non è possibile per noi superare questo controllo pur rimanendo in conformità con PCI e la legge sulla protezione dei dati.

Saluti,
[io]

Farò CC nel CTO della società e nel nostro account manager e spero che il CTO possa confermare che queste informazioni non sono disponibili. Contatterò anche il Consiglio per gli standard di sicurezza PCI per spiegare cosa ci richiede.

Aggiornamento 3 (26)

Ecco alcune email che abbiamo scambiato;

RE: la mia prima email;

Come spiegato, queste informazioni dovrebbero essere facilmente disponibili su qualsiasi sistema ben gestito a qualsiasi amministratore competente. La tua incapacità di fornire queste informazioni mi porta a credere che tu sia a conoscenza dei difetti di sicurezza nel tuo sistema e non sei disposto a rivelarli. Le nostre richieste sono in linea con le linee guida PCI ed entrambe possono essere soddisfatte. La crittografia avanzata significa solo che le password devono essere crittografate mentre l'utente le sta immettendo, ma dovrebbero essere spostate in un formato recuperabile per un uso successivo.

Non vedo problemi di protezione dei dati per queste richieste, la protezione dei dati si applica solo ai consumatori e non alle imprese, quindi non dovrebbero esserci problemi con queste informazioni.

Solo, cosa, non posso, nemmeno ...

"La crittografia avanzata significa solo che le password devono essere crittografate mentre l'utente le sta inserendo, ma devono essere spostate in un formato recuperabile per un uso successivo."

Ho intenzione di incorniciarlo e metterlo sul mio muro.

Mi sono stufato di essere diplomatico e l'ho indirizzato a questo thread per mostrargli la risposta che ho ottenuto:

Fornire queste informazioni DIRETTAMENTE contraddice diversi requisiti delle linee guida PCI. La sezione che ho citato dice anche storage (implicando dove archiviamo i dati sul disco). Ho iniziato una discussione su ServerFault.com (una community online per professionisti sys-admin) che ha creato un'enorme risposta, suggerendo tutti che queste informazioni non possono essere fornite. Sentiti libero di leggere te stesso

https://serverfault.com/questions/293217/

Abbiamo finito di passare al nostro sistema su una nuova piattaforma e cancelleremo il nostro account con te entro il giorno successivo o giù di lì, ma voglio che tu ti renda conto di quanto siano ridicole queste richieste e nessuna azienda che implementa correttamente le linee guida PCI dovrà o dovrebbe, essere in grado di fornire queste informazioni. Ti consiglio vivamente di ripensare i tuoi requisiti di sicurezza in quanto nessuno dei tuoi clienti dovrebbe essere in grado di conformarsi a questo.

(In realtà avevo dimenticato di averlo definito un idiota nel titolo, ma come detto ci eravamo già allontanati dalla loro piattaforma, quindi nessuna vera perdita.)

E nella sua risposta, afferma che apparentemente nessuno di voi sa di cosa stai parlando:

Ho letto in dettaglio attraverso quelle risposte e il tuo post originale, tutti i rispondenti devono ottenere i loro fatti giusti. Sono stato in questo settore più a lungo di chiunque altro su quel sito, ottenere un elenco di password degli account utente è incredibilmente semplice, dovrebbe essere una delle prime cose che fai quando impari a proteggere il tuo sistema ed è essenziale per il funzionamento di qualsiasi sistema sicuro server. Se davvero non hai le capacità per fare qualcosa di così semplice, suppongo che non hai PCI installato sui tuoi server in quanto poter recuperare queste informazioni è un requisito fondamentale del software. Quando hai a che fare con qualcosa come la sicurezza non dovresti porre queste domande su un forum pubblico se non hai una conoscenza di base di come funziona.

Vorrei anche suggerire che qualsiasi tentativo di rivelarmi, o [nome dell'azienda] sarà considerato diffamazione e saranno prese le opportune azioni legali

Punti chiave idioti se li hai persi:

• È stato un revisore della sicurezza più a lungo di chiunque altro qui (o indovina o ti insegue)
• Essere in grado di ottenere un elenco di password su un sistema UNIX è "di base"
• PCI è ora un software
• Le persone non dovrebbero usare i forum quando non sono sicuri della sicurezza
• Presentare informazioni fattuali (di cui ho una prova tramite e-mail) online è diffamazione

Eccellente.

PCI SSC ha risposto e sta indagando su di lui e sull'azienda. Il nostro software è ora passato a PayPal, quindi sappiamo che è sicuro. Aspetterò prima che PCI torni da me, ma mi preoccupo un po 'che potrebbero aver usato queste pratiche di sicurezza internamente. In tal caso, penso che sia una grande preoccupazione per noi poiché tutta la nostra elaborazione delle carte li ha attraversati. Se lo facessero internamente, penso che l'unica cosa responsabile da fare sarebbe informare i nostri clienti.

Spero che quando PCI realizzerà quanto è brutto indagheranno sull'intera società e sul sistema, ma non ne sono sicuro.

Quindi ora ci siamo allontanati dalla loro piattaforma e supponendo che ci vorranno almeno alcuni giorni prima che PCI mi ritorni, qualche suggerimento inventivo su come trollarlo un po '? =)

Una volta che ho ottenuto l'autorizzazione dal mio legale (dubito fortemente che tutto ciò sia in realtà diffamazione ma volevo ricontrollare) pubblicherò il nome dell'azienda, il suo nome e l'e-mail e, se lo desideri, puoi contattarlo e spiegare perché non capisci le basi della sicurezza di Linux come come ottenere un elenco di tutte le password degli utenti LDAP.

Piccolo aggiornamento:

Il mio "ragazzo legale" ha suggerito di rivelare che la società avrebbe probabilmente causato più problemi del necessario. Posso dire però che questo non è un fornitore importante, hanno meno di 100 clienti che usano questo servizio. Inizialmente abbiamo iniziato a usarli quando il sito era minuscolo e funzionante con un po 'di VPS, e non volevamo fare tutto lo sforzo di ottenere PCI (eravamo abituati a reindirizzare al loro frontend, come PayPal Standard). Ma quando siamo passati all'elaborazione diretta delle carte (incluso ottenere PCI e buon senso), gli sviluppatori hanno deciso di continuare a utilizzare la stessa azienda solo con un'API diversa. La società ha sede nella zona di Birmingham, nel Regno Unito, quindi dubito fortemente che chiunque qui sarà interessato.

Innanzitutto, NON capitolare. Non è solo un idiota, ma è PERICOLAMENTE sbagliato. In effetti, il rilascio di queste informazioni violerebbe lo standard PCI (che è ciò per cui presumo sia l'audit poiché è un processore di pagamento) insieme a tutti gli altri standard là fuori e semplicemente buon senso. Esporrebbe inoltre la tua azienda a tutti i tipi di responsabilità.

La prossima cosa che farei è inviare una e-mail al tuo capo dicendo che deve coinvolgere un consulente aziendale per determinare l'esposizione legale che la società si troverebbe ad affrontare procedendo con questa azione.

Questo ultimo pezzo è a voi, ma io avrebbe contattato dei visti con queste informazioni e ottenere il suo status di revisore PCI tirato.

Come qualcuno che ha superato la procedura di audit con Price Waterhouse Coopers per un contratto governativo classificato, posso assicurarti che questo è totalmente fuori discussione e questo ragazzo è pazzo.

Quando PwC ha voluto verificare la validità della nostra password:

• Chiesto di vedere i nostri algoritmi di sicurezza della password
• Ho testato le unità di test con i nostri algoritmi per verificare che avrebbero negato password scadenti
• Chiesto di vedere i nostri algoritmi di crittografia per garantire che non possano essere invertiti o non crittografati (anche dalle tabelle arcobaleno), anche da qualcuno che avesse pieno accesso a ogni aspetto del sistema
• Ho verificato che le password precedenti fossero memorizzate nella cache per garantire che non potessero essere riutilizzate
• Ci ha chiesto il permesso (che abbiamo concesso) per tentare di entrare nella rete e nei sistemi correlati usando tecniche di ingegneria non sociale (cose come xss e exploit non-0 day)

Se avessi anche lasciato intendere che avrei potuto mostrare loro quali erano le password degli utenti negli ultimi 6 mesi, ci avrebbero immediatamente escluso dal contratto.

Se fosse possibile fornire questi requisiti, si fallirebbe immediatamente ogni singolo audit che vale la pena avere.

Aggiornamento: l'e-mail di risposta sembra buona. Molto più professionale di qualsiasi cosa avrei scritto.

Onestamente, sembra che questo ragazzo (il revisore dei conti) ti stia organizzando. Se gli dai le informazioni che ti sta chiedendo, gli hai appena dimostrato che puoi essere socialmente ingegnerizzato per rinunciare a informazioni interne critiche. Fallire.

Ho appena notato che sei nel Regno Unito, il che significa che ciò che ti sta chiedendo di fare è infrangere la legge (il Data Protection Act in effetti). Anch'io sono nel Regno Unito, lavoro per una grande società fortemente controllata e conosco la legge e le pratiche comuni in quest'area. Sono anche un lavoro molto brutto che sarà felice di frenare questo ragazzo per te se ti piace solo per divertimento, fammi sapere se ti piacerebbe aiutare ok.

Sei socialmente ingegnerizzato. O è per "metterti alla prova" o è un hacker che si pone come un auditor per ottenere alcuni dati molto utili.

Sono seriamente preoccupato per la mancanza di abilità etiche nella risoluzione dei problemi dei PO e per la comunità di errori del server che ignora questa palese violazione della condotta etica.

In breve, ho bisogno;

• Un modo per "falsificare" sei mesi di modifiche alla password e renderlo valido
• Un modo per "falsificare" sei mesi di trasferimenti di file in entrata

Vorrei essere chiaro su due punti:

1. Non è mai appropriato falsificare i dati nel corso di normali attività commerciali.
2. Non dovresti mai divulgare questo tipo di informazioni a nessuno. Mai.

Non è compito tuo falsificare i record. È tuo compito assicurarti che tutti i record necessari siano disponibili, accurati e sicuri.

La comunità qui su Server Fault deve trattare questo tipo di domande poiché il sito stackoverflow tratta le domande dei "compiti a casa". Non è possibile affrontare questi problemi solo con una risposta tecnica o ignorare la violazione della responsabilità etica.

Vedere così tante risposte di utenti di alto livello qui in questo thread e nessuna menzione delle implicazioni etiche della domanda mi rattrista.

Incoraggerei tutti a leggere il Codice etico degli amministratori di sistema di SAGE .

A proposito, il tuo revisore della sicurezza è un idiota, ma ciò non significa che devi sentire la pressione per non essere etico nel tuo lavoro.

Modifica: i tuoi aggiornamenti non hanno prezzo. Tieni la testa bassa, la polvere asciutta e non prendere (o dare) nichel di legno.

Non puoi dargli quello che vuoi, e i tentativi di "fingere" è probabile che torni a morderti nel culo (possibilmente in modo legale). O hai bisogno di fare appello alla catena di comando (è possibile che questo revisore sia diventato un ladro, anche se i controlli di sicurezza sono notoriamente idioti - chiedimi del revisore che voleva essere in grado di accedere a un AS / 400 tramite SMB) o ottenere l'inferno fuori da sotto questi requisiti onorosi.

Non sono nemmeno una buona sicurezza - un elenco di tutte le password in chiaro è un incredibilmente cosa pericolosa da sempre la produzione, a prescindere dai metodi utilizzati per proteggerli, e scommetto questo tizio vorrà loro via e-mail in chiaro . (Sono sicuro che lo sai già, devo solo sfogarmi un po ').

Per cazzate e risatine, chiedigli direttamente come soddisfare le sue esigenze - ammetti che non sai come fare e che vorrai sfruttare la sua esperienza. Una volta usciti e usciti, una risposta alla sua "Ho più di 10 anni di esperienza nel controllo della sicurezza" sarebbe "no, hai 5 minuti di esperienza ripetuti centinaia di volte".

Nessun auditor dovrebbe fallire se trovano un problema storico che ora hai risolto. In realtà, questa è la prova di un buon comportamento. Con questo in mente, suggerisco due cose:

a) Non mentire o inventare cose. b) Leggi le tue politiche.

L'affermazione chiave per me è questa:

Tutti i client [provider di elaborazione di carte di credito generici] sono tenuti a conformarsi alle nostre nuove politiche di sicurezza

Scommetto che c'è una dichiarazione in quelle politiche che dice che le password non possono essere scritte e non possono essere passate a chiunque che non sia l'utente. In tal caso, applica tali criteri alle sue richieste. Suggerisco di gestirlo in questo modo:

• Un elenco di nomi utente e password in chiaro per tutti gli account utente su tutti i server

Mostragli un elenco di nomi utente, ma non permettere che vengano portati via. Spiega che fornire password in chiaro è a) impossibile in quanto è a senso unico eb) contro la politica, contro la quale ti sta controllando, quindi non obbedirai.

• Un elenco di tutte le password modificate negli ultimi sei mesi, sempre in testo normale

Spiega che questo non era storicamente disponibile. Forniscigli un elenco degli ultimi tempi di modifica della password per mostrare che ora questo è stato fatto. Spiegare, come sopra, che le password non saranno fornite.

• Un elenco di "tutti i file aggiunti al server da dispositivi remoti" negli ultimi sei mesi

Spiegare cosa è e non viene registrato. Fornisci ciò che puoi. Non fornire nulla di confidenziale e spiegare per politica perché no. Chiedere se è necessario migliorare la registrazione.

• Le chiavi pubbliche e private di qualsiasi chiave SSH

Guarda la tua politica di gestione delle chiavi. Dovrebbe indicare che le chiavi private non sono autorizzate a uscire dal loro contenitore e hanno condizioni di accesso rigide. Applicare tale criterio e non consentire l'accesso. Le chiavi pubbliche sono felicemente pubbliche e possono essere condivise.

• Una e-mail inviata a lui ogni volta che un utente cambia la propria password, contenente la password di testo normale

Dì semplicemente di no. Se si dispone di un server di registro sicuro locale, consentirgli di vedere che questo viene registrato in situ.

Fondamentalmente, e mi dispiace dirlo, ma devi giocare a pallone con questo ragazzo. Segui esattamente la tua politica, non deviare. Non mentire. E se ti delude per qualcosa che non rientra nella politica, lamentati con i suoi anziani della compagnia che lo ha inviato. Raccogli una traccia cartacea di tutto ciò per dimostrare che sei stato ragionevole. Se infrangi la tua politica, sei a sua mercé. Se li segui fino alla lettera, finirà per essere licenziato.

Sì, il revisore è un idiota. Tuttavia, come sai, a volte gli idioti sono posti in posizioni di potere. Questo è uno di quei casi.

L'informazione ha chiesto ha nulla incidenza sulla sicurezza attuale del sistema. Spiega al revisore che stai utilizzando LDAP per l'autenticazione e che le password sono archiviate utilizzando un hash unidirezionale. A meno di fare uno script di forza bruta contro gli hash delle password (che potrebbero richiedere settimane (o anni), non sarai in grado di fornire le password.

Allo stesso modo i file remoti - mi piacerebbe sentire, forse, come pensa che dovresti essere in grado di distinguere tra i file creati direttamente sul server e un file che è SCPed al server.

Come diceva @womble, non fingere nulla. Questo non farà nulla di buono. O abbandona questo audit e multa un altro broker, o trova un modo per convincere questo "professionista" che il suo formaggio è scivolato via dal suo cracker.

Chiedi al tuo "revisore della sicurezza" di indicare qualsiasi testo di uno qualsiasi di questi documenti che ha i suoi requisiti e osserva come si sforza di trovare una scusa e alla fine si scusa per non essere più ascoltato.

WTF! Scusa ma questa è la mia unica reazione a questo. Non ho mai sentito parlare di requisiti di audit che richiedono una password in chiaro, figuriamoci di dar loro le password mentre cambiano.

1 °, chiedigli di mostrarti il ​​requisito che fornisci.

In secondo luogo, se questo è per PCI (che tutti presumiamo poiché si tratta di una domanda sul sistema di pagamento) vai qui: https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php e ottieni un nuovo revisore.

3 °, segui quello che hanno detto sopra, contatta la tua direzione e fagli contattare la compagnia QSA con cui sta lavorando. Quindi ottenere immediatamente un altro revisore.

Stati del sistema di audit dei revisori, standard, processi, ecc. Non sono necessarie informazioni che consentano loro di accedere ai sistemi.

Se desideri revisori dei conti raccomandati o colo alternativi che lavorano a stretto contatto con i revisori dei conti contattami e sarei felice di fornire riferimenti.

In bocca al lupo! Fidati del tuo istinto, se qualcosa sembra sbagliato probabilmente lo è.

Non c'è motivo legittimo per lui di conoscere la password e avere accesso alle chiavi private. Ciò che gli avrebbe richiesto gli avrebbe dato la possibilità di impersonare i tuoi clienti in qualsiasi momento e sottrarre tutti i soldi che voleva, senza alcun modo di rilevarli come una possibile transazione fraudolenta. Sarà esattamente il tipo di minacce alla sicurezza per cui dovrebbe controllarti.

Avvisare la direzione che il revisore ha richiesto la violazione delle politiche di sicurezza e che la richiesta è illegale. Suggerire che potrebbero voler scaricare l'attuale società di revisione e trovarne una legittima. Chiama la polizia e consegna l'auditor per la richiesta di informazioni illegali (nel Regno Unito). Quindi chiamare il PCI e consegnare l'Auditor per la loro richiesta.

La richiesta è simile a chiederti di uccidere qualcuno a caso e consegnare il corpo. Lo faresti? o chiameresti gli sbirri e li consegneresti?

Rispondi con una causa . Se un revisore chiede password in chiaro (dai adesso, non è così difficile forzare o rompere gli hash delle password deboli), probabilmente ti hanno mentito sulle loro credenziali.

Solo un consiglio per quanto riguarda il modo in cui esprimi la tua risposta:

Sfortunatamente non c'è modo per noi di fornirti alcune delle informazioni richieste, principalmente password in chiaro, cronologia delle password, chiavi SSH e registri di file remoti. Queste cose non sono solo tecnicamente impossibili ...

Lo riformulerei per evitare di entrare in una discussione sulla fattibilità tecnica. Leggendo la terribile prima e-mail inviata dal revisore, sembra che questo è qualcuno che può prendersela con dettagli che non sono legati al problema principale, e potrebbe sostenere che si poteva salvare le password, account di accesso di log, ecc Quindi, o dicono :

... A causa delle nostre rigide politiche di sicurezza, non abbiamo mai registrato le password in testo semplice. Pertanto, sarà tecnicamente impossibile fornire questi dati.

O

... Non solo abbasseremmo significativamente il nostro livello di sicurezza interno rispondendo alla tua richiesta, ...

Buona fortuna e tienici aggiornati su come finisce!

A rischio di continuare la corsa degli utenti di alto livello che saltano su questa domanda, ecco i miei pensieri.

Riesco a capire vagamente il motivo per cui vuole le password in chiaro, e questo per giudicare la qualità delle password in uso. È un modo schifoso per farlo, la maggior parte dei revisori che conosco accetteranno gli hash criptati e faranno funzionare un cracker per vedere che tipo di frutta a bassa pendenza possono estrarre. Tutti andranno oltre la politica di complessità della password e rivedranno quali misure di sicurezza sono in atto per applicarlo.

Ma devi consegnare alcune password. Suggerisco (anche se penso che tu l'abbia già fatto) chiedendogli quale sia l'obiettivo della consegna della password in chiaro. Ha detto che è per convalidare la tua conformità rispetto alla politica di sicurezza, quindi fagli dare quella politica. Chiedigli se accetterà che il tuo regime di complessità della password è abbastanza solido da impedire agli utenti di impostare la loro password P@55w0rde di essere stato in vigore per i 6 mesi in questione.

Se lo spinge, potresti dover ammettere che non puoi consegnare le password in chiaro poiché non sei impostato per registrarle (cosa che rappresenta un grave fallimento della sicurezza), ma puoi tentare di farlo in futuro se lo richiede verifica diretta del funzionamento dei criteri per le password. E se vuole dimostrarlo, fornirai felicemente il database di password crittografato per lui (o per te! Mostra volentieri! Aiuta!) Per eseguire un passaggio di cracking.

I "file remoti" possono probabilmente essere estratti dai registri SSH per le sessioni SFTP, il che è ciò di cui sospetto stia parlando. Se non hai 6 mesi di syslogging, questo sarà difficile da produrre. L'uso di wget per estrarre un file da un server remoto mentre si accede tramite SSH è considerato un "trasferimento di file remoto"? I PUT HTTP sono? File creati dal testo degli Appunti nella finestra del terminale dell'utente remoto? Semmai, puoi assillarlo con questi casi limite per avere un'idea migliore delle sue preoccupazioni in questo settore e forse instillare il sentimento "So più di questo di te", così come a quali tecnologie specifiche sta pensando. Quindi estrarre ciò che è possibile dai registri e dai registri archiviati nei backup.

Non ho nulla sulle chiavi SSH. L'unica cosa che mi viene in mente è che sta cercando chiavi senza password per qualche motivo, e forse forza cripto. Altrimenti, non ho niente.

Per quanto riguarda ottenere quelle chiavi, raccogliere almeno le chiavi pubbliche è abbastanza facile; troll semplicemente le cartelle .ssh che le cercano. Ottenere le chiavi private comporterà indossare il cappello BOFH e aggredire i tuoi utenti come "Inviami le tue coppie di chiavi SSH pubbliche e private. Tutto ciò che non ottengo verrà eliminato dai server in 13 giorni" e se qualcuno squawks (vorrei) indicarli al controllo di sicurezza. Lo scripting è il tuo amico qui. Almeno causerà un sacco di chiavi di ricerca senza password per ottenere le password.

Se insiste ancora su "password in chiaro nell'e-mail" almeno sottoponi quelle e-mail alla crittografia GPG / PGP con la propria chiave. Qualsiasi revisore della sicurezza degno del suo sale dovrebbe essere in grado di gestire qualcosa del genere. In questo modo se le password perdono, sarà perché le ha lasciate uscire, non tu. Ancora un'altra cartina di tornasole per la competenza.

Sono d'accordo con Zypher e Womble su questo. Idiota pericoloso con conseguenze pericolose.

Probabilmente ti sta testando per vedere se sei un rischio per la sicurezza. Se gli fornisci questi dettagli, probabilmente verrai immediatamente respinto. Porta questo al tuo capo immediato e passa il dollaro. Fai sapere al tuo capo che coinvolgerai le autorità competenti se questo culo ti verrà di nuovo vicino.

Ecco per cosa vengono pagati i capi.

Ho una visione di un pezzo di carta lasciato sul retro di un taxi con un elenco di password, chiavi SSH e nomi utente su di esso! Hhhmmm! Puoi vedere i titoli dei giornali in questo momento!

Aggiornare

In risposta ai 2 commenti qui sotto, suppongo che entrambi abbiate buoni punti da fare. Non c'è modo di scoprire davvero la verità e il fatto che la domanda sia stata postata mostra un po 'di ingenuità da parte del poster, oltre al coraggio di affrontare una situazione avversa con potenziali conseguenze sulla carriera in cui gli altri si metterebbero la testa nel carteggia e scappa.

La mia conclusione per ciò che vale è che questo è un dibattito assolutamente interessante che probabilmente ha indotto la maggior parte dei lettori a chiedersi cosa farebbero in questa situazione, indipendentemente dal fatto che le politiche del revisore o dei revisori siano competenti. La maggior parte delle persone dovrà affrontare questo tipo di dilemma in qualche forma nella loro vita lavorativa e questo non è davvero il tipo di responsabilità che dovrebbe essere spinto sulle spalle di una sola persona. È una decisione aziendale piuttosto che una decisione individuale su come gestirla.

Chiaramente ci sono molte buone informazioni qui, ma mi permettono di aggiungere il mio 2c, come qualcuno che scrive software che viene venduto in tutto il mondo dal mio datore di lavoro a grandi aziende principalmente per aiutare le persone a rispettare le politiche di sicurezza della gestione degli account e passare audit; per quello che vale.

Innanzitutto, sembra molto sospetto, come hai notato tu (e altri). O il revisore sta solo seguendo una procedura che non capisce (possibile) o ti mette alla prova della vulnerabilità in modo da social engineering (improbabile dopo scambi di follow-up), o un social engineering frodi tu (anche possibile), o solo un idiota generico (probabilmente più probabilmente). Per quanto riguarda i consigli, offrirei che dovresti parlare con la tua direzione e / o trovare una nuova società di revisione contabile e / o segnalarla a un'agenzia di sorveglianza appropriata.

Per quanto riguarda le note, un paio di cose:

• È possibile (in condizioni specifiche) fornire le informazioni richieste, se il sistema è impostato per consentirle. Tuttavia, non è in alcun modo una "migliore pratica" per la sicurezza, né sarebbe affatto comune.
• In generale, gli audit riguardano le pratiche di convalida, non l'esame delle informazioni sicure effettive. Sarei altamente sospettoso di chiunque chieda password o certificati in chiaro, piuttosto che i metodi usati per garantire che siano "buoni" e protetti in modo adeguato.

Spero che sia d'aiuto, anche se in gran parte ribadisce ciò che gli altri hanno consigliato. Come te, non ho intenzione di nominare la mia azienda, nel mio caso perché non sto parlando per loro (account personale / opinioni e tutto il resto); si scusa se ciò toglie credibilità, ma così sia. In bocca al lupo.

Questo potrebbe e dovrebbe essere registrato in IT Security - Stack Exchange .

Non sono un esperto nel controllo della sicurezza, ma la prima cosa che ho imparato sulla politica di sicurezza è "NEVER GIVE PASSWORDS AWAY". Questo ragazzo forse è stato in questo settore per 10 anni, ma come ha detto Womble"no, you have 5 minutes of experience repeated hundreds of times"

Ho lavorato con il personale IT bancario per un po 'di tempo e quando ti ho visto pubblicare, l'ho mostrato a loro ... Stavano ridendo così tanto. Mi hanno detto che quel ragazzo sembra una truffa. Si occupavano di questo genere di cose per la sicurezza del cliente bancario.

Chiedere password chiare, chiavi SSH, registri delle password è chiaramente una grave condotta professionale. Questo ragazzo è pericoloso.

Spero che tutto vada bene ora e che tu non abbia alcun problema con il fatto che possano aver tenuto traccia della tua precedente transazione con loro.

Se è possibile fornire una qualsiasi delle informazioni (con la possibile eccezione delle chiavi pubbliche) richieste ai punti 1,2,4 e 5, si dovrebbe prevedere di fallire la verifica.

Rispondere formalmente ai punti 1,2 e 5 dicendo che non è possibile rispettare poiché la propria politica di sicurezza richiede che non si mantengano password di testo semplice e che le password vengano crittografate utilizzando un algoritmo non reversibile. Al punto 4, ancora una volta, non è possibile fornire le chiavi private in quanto violerebbe la politica di sicurezza.

Quanto al punto 3. Se disponi dei dati, forniscili. Se non lo fai perché non hai dovuto raccoglierlo, dillo e dimostra come stai ora (lavorando per) soddisfare il nuovo requisito.

Un revisore della sicurezza per i nostri server ha richiesto quanto segue entro due settimane :

...

Se falliamo il controllo di sicurezza perdiamo l'accesso alla nostra piattaforma di elaborazione delle carte (una parte critica del nostro sistema) e ci vorrebbero due settimane per spostarsi altrove . Quanto sono fregato?

Sembra che tu abbia risposto alla tua domanda. (Vedi il testo in grassetto per i suggerimenti.)

Viene in mente solo una soluzione: convincere tutti a scrivere la loro ultima e attuale password e poi cambiarla immediatamente con una nuova. Se vuole testare la qualità della password (e la qualità delle transizioni da password a password, ad esempio per assicurarsi che nessuno usi rfvujn125 e quindi rfvujn126 come password successiva), l'elenco delle vecchie password dovrebbe essere sufficiente.

Se ciò non fosse ritenuto accettabile, allora sospetterei che il ragazzo sia un membro di Anonymous / LulzSec ... a quel punto dovresti chiedergli qual è la sua maniglia e dirgli di smettere di essere un tale scrub!

Come ha affermato oli: la persona in questione sta cercando di farti infrangere la legge (protezione dei dati / direttive UE sulla riservatezza) / regolamenti interni / standard PCI. Non solo dovresti avvisare la direzione (come già pensavi), ma puoi chiamare la polizia come suggerito.

Se la persona in questione possiede un qualche tipo di accreditamento / certificazione, ad esempio CISA (Certified Information Systems Auditor) o l'equivalente nel Regno Unito del CPA statunitense (una designazione di contabile pubblica), è possibile anche informare le organizzazioni di accreditamento per indagare su questo. Non solo quella persona sta cercando di farti infrangere la legge, ma è anche un "audit" estremamente incompetente e probabilmente in violazione di ogni standard di audit etico con cui i revisori accreditati devono attenersi a pena di perdita dell'accreditamento.

Inoltre, se la persona in questione è membro di una società più grande, le suddette organizzazioni di controllo spesso richiedono un qualche tipo di dipartimento di controllo qualità che sovrintende alla qualità degli audit e alla presentazione degli audit e indaga sui reclami. Quindi potresti anche provare a lamentarti con la società di revisione in questione.

Sto ancora studiando e la prima cosa che ho imparato durante la configurazione dei server è che se rendi possibile la registrazione di password in chiaro, ti stai già mettendo in pericolo per una gigantesca violazione. Nessuna password deve essere conosciuta se non per l'utente che la utilizza.

Se questo ragazzo è un auditor serio, non dovrebbe chiederti queste cose. Per me suona un po ' come un malfattore . Verificherei con l'organo regolatore perché questo ragazzo sembra un completo idiota.

Aggiornare

Aspetta, crede che dovresti usare una crittografia simmetrica solo per trasmettere la password, ma poi memorizzarli in chiaro nel tuo database o fornire un modo per decrittografarli. Quindi, fondamentalmente, dopo tutti gli attacchi anonimi ai database, in cui mostravano password degli utenti in chiaro, è ANCORA convinto che questo sia un buon modo per "proteggere" un ambiente.

È un dinosauro bloccato negli anni '60 ...

• Un elenco di nomi utente e password in chiaro per tutti gli account utente su tutti i server
  • I nomi utente attuali POSSONO rientrare nell'ambito di "siamo in grado di rilasciare questo" e dovrebbero rientrare nell'ambito di "possiamo mostrarlo, ma non è possibile portarlo fuori sede".
  • Le password in testo normale non dovrebbero esistere più a lungo di quanto non siano necessarie per l'hash unidirezionale e certamente non dovrebbero mai lasciare memoria (nemmeno attraversare i cavi), quindi la loro esistenza in una memoria permanente è un no-no.
• Un elenco di tutte le password modificate negli ultimi sei mesi, sempre in testo normale
  • Vedere "la memorizzazione permanente è un no-no".
• Un elenco di "tutti i file aggiunti al server da dispositivi remoti" negli ultimi sei mesi
  • Questo può essere per garantire che si registrino i trasferimenti di file da / verso server (s) di elaborazione dei pagamenti, se si dispone dei registri dovrebbe essere OK per passare. Se non si dispone dei registri, controllare cosa dicono le relative politiche di sicurezza sulla registrazione di tali informazioni.
• Le chiavi pubbliche e private di qualsiasi chiave SSH
  • Forse un tentativo di verificare che "le chiavi SSH debbano avere una passphrase" è nella policy e seguito. Vuoi passphrase su tutte le chiavi private.
• Una e-mail inviata a lui ogni volta che un utente cambia la propria password, contenente la password di testo normale
  • Questo è sicuramente un no-no.

Risponderei con qualcosa in linea con le mie risposte, supportato da conformità PCI, conformità SOX e documenti di politica di sicurezza interna, se necessario.

Questi ragazzi chiedono insulti al paradiso, e concordo sul fatto che qualsiasi corrispondenza da qui in poi dovrebbe passare attraverso il CTO. O sta cercando di farti diventare il ragazzo fallito per non essere stato in grado di soddisfare tale richiesta, per aver rilasciato informazioni riservate, o è gravemente incompetente. Spero che il tuo CTO / manager faccia una doppia presa su questa richiesta di ragazzi e che si facciano azioni positive, e se sono coinvolti dietro le azioni di questo ragazzo .... beh, i buoni amministratori di sistema sono sempre richiesti sugli annunci, come sembra che sia il momento di iniziare a cercare un posto dove succede.

Gli direi che ci vuole tempo, fatica e denaro per costruire l'infrastruttura cracking per le password, ma poiché usi un forte hashing come SHA256 o qualsiasi altra cosa, potrebbe non essere possibile fornire le password entro 2 settimane. Inoltre, vorrei dire che ho contattato l'ufficio legale per confermare se è lecito condividere questi dati con nessuno. PCI DSS anche una buona idea da menzionare come hai fatto. :)

I miei colleghi sono scioccati dalla lettura di questo post.

Sarei fortemente tentato di dargli un elenco di nome utente / password / chiavi private per gli account honeypot, quindi se mai verifica gli accessi per questi account gli facciano accedere non autorizzato a un sistema informatico. Tuttavia, sfortunatamente, questo probabilmente ti espone almeno a una sorta di illecito civile per aver fatto una rappresentazione fraudolenta.

Basta rifiutare di rivelare le informazioni, affermando che non è possibile trasmettere le password in quanto non si ha accesso ad esse. Essendo io stesso un revisore dei conti, deve rappresentare qualche istituzione. Tali istituzioni generalmente pubblicano linee guida per tale audit. Verifica se tale richiesta è conforme a tali linee guida. Puoi persino lamentarti con tali associazioni. Metti anche in chiaro al revisore che in caso di eventuali errori la colpa può tornare a lui (il revisore) in quanto ha tutte le password.

Direi che non c'è modo per te di fornirgli QUALSIASI delle informazioni richieste.

• I nomi utente gli forniscono una visione degli account che hanno accesso ai tuoi sistemi, un rischio per la sicurezza
• La cronologia delle password fornirebbe una panoramica dei modelli di password utilizzati, dandogli una possibile via di attacco indovinando la password successiva nella catena
• I file trasferiti al sistema possono contenere informazioni riservate che potrebbero essere utilizzate in un attacco contro i tuoi sistemi, oltre a fornire loro una visione della struttura del tuo file system
• Chiavi pubbliche e private, che diavolo avrebbe senso se le avessi distribuite a qualcuno che non fosse l'utente previsto?
• Un'e-mail inviata ogni volta che un utente cambia una password gli darebbe password aggiornate per ogni account utente.

Questo ragazzo sta attirando il tuo compagno di plonker! È necessario mettersi in contatto con il suo manager o qualche altro revisore contabile dell'azienda per confermare le sue richieste oltraggiose. E allontanati al più presto.

Il problema è ormai risolto, ma a beneficio dei futuri lettori ...

Considerando che:

• Sembra che tu abbia speso più di un'ora su questo.

• Hai dovuto consultare il legale della compagnia.

• Stanno chiedendo molto lavoro dopo aver modificato il tuo accordo.

• Sarai fuori soldi e più tempo a passare.

Dovresti spiegare che avrai bisogno di molti soldi in anticipo e c'è un minimo di quattro ore.

Le ultime volte ho detto a qualcuno che improvvisamente non erano così bisognosi.

È comunque possibile fatturarli per eventuali perdite subite durante la commutazione e per il tempo impiegato, poiché hanno modificato il contratto. Non sto dicendo che pagheranno entro due settimane, proprio come pensavano che avresti rispettato entro quel tempo - saranno unilaterali, non ho dubbi.

Li scuoterà se l'ufficio del tuo avvocato invia l'avviso di riscossione. Dovrebbe attirare l'attenzione del proprietario della società di revisione.

Vorrei sconsigliare eventuali ulteriori rapporti con loro, solo per discutere ulteriormente la questione comporterà un deposito per il lavoro richiesto. Quindi si può essere pagati per averli respinti.

È strano che tu abbia un accordo in vigore e quindi qualcuno dall'altra parte andrebbe fuori dai binari - se non è un test di sicurezza o intelligenza è sicuramente un test della tua pazienza.