È normale che i revisori richiedano tutte le password aziendali?

290

La mia azienda è attualmente impegnata in un controllo di sicurezza inquadrato come un pentimento. Hanno richiesto tutte le password di amministratore per ognuno dei nostri servizi e tutti i codici sorgente del nostro software. Vogliono login per Google Apps, processori di carte di credito, GitHub, DigitalOcean, credenziali SSH, accesso al database e molto altro. Nota, non abbiamo mai firmato una sola NDA (ma è stata fornita una dichiarazione di lavoro) e sono molto riluttante a fornire queste informazioni a loro per questo.

È normale per un pentito? Immaginavo che fosse per lo più scatola nera. Come devo procedere?

"AGGIORNAMENTO * Ora abbiamo una NDA. Il contratto, tuttavia, dice che non possiamo ritenerli responsabili di nulla, ma non sono sicuro se questa sia la mossa giusta per continuare con loro. Nella mia esperienza, le loro richieste non sono normali nemmeno nei controlli della scatola bianca e la loro dichiarazione di lavoro si legge in un modo che non chiarisce se si tratta di una verifica con scatola bianca o scatola nera.

    
posta Zachary Iles 25.10.2017 - 19:20
fonte

7 risposte

425

Is this normal for a pentest?

Assolutamente no . Scenario migliore: stanno eseguendo test di penetrazione di "ingegneria sociale" e vogliono vedere se si può essere spinti a compiere un'azione molto pericolosa. Scenario di caso medio, non sanno come fare il loro lavoro. Nella peggiore delle ipotesi, stanno solo fingendo di essere una società di revisione e soddisfare la loro richiesta si tradurrà in una costosa violazione.

Nel caso di un controllo del codice, l'azienda avrà ovviamente bisogno di accedere al codice sorgente. Tuttavia, mi aspetterei che una società che fornisce tali servizi capisca già la sensibilità di tale necessità e abbia lotti di moduli da firmare e che offra di lavorare in un ambiente strettamente controllato. Una società di sicurezza stimabile sarà interessata non solo a proteggerti (perché è il loro lavoro) ma anche a proteggersi da clienti inaffidabili (il nostro codice sorgente è trapelato subito dopo che ti abbiamo assunto: stiamo citando in giudizio !!!!) . Tutto questo per dire: qualsiasi società di sicurezza stimabile che non ha firmato molti contratti prima di andare a lavorare non è una società di sicurezza affidabile.

Non riesco a immaginare nessuna circostanza in cui trasferire l'accesso a una di queste cose sarebbe una buona idea.

Modifica RE: contratti nascosti

Alcuni hanno suggerito che l'azienda potrebbe semplicemente non aver detto all'OP di eventuali contratti / accordi rilevanti / NDA. Suppongo che sia possibile, ma voglio chiarire che la mancanza di un contratto non è l'unica bandiera rossa che vedo.

Come qualcuno che ha costruito siti di e-commerce e software aziendale che ha richiesto l'integrazione con molti Processori CC, non vedo assolutamente alcun vantaggio nel fornire a qualcun altro l'accesso al proprio Processore CC. A quel punto nel tempo non sono più test di penetrazione dei tuoi sistemi: sono penetrazioni che testano i sistemi di qualcun altro che usi. In effetti, fornire le credenziali di accesso in modo tale da violare i termini del servizio che hai firmato quando hai iniziato a utilizzare il tuo Processore CC (per non parlare degli altri sistemi ai quali si richiede l'accesso). Quindi, a meno che tu non abbia il permesso dal tuo Processore CC di consegnare le tue credenziali a una società di controllo della sicurezza (suggerimento: non ti darebbero mai il permesso), dando loro che l'accesso è una enorme responsabilità.

Molti altri qui hanno fatto un ottimo lavoro articolando le differenze tra i test white-box e black-box. È certamente vero che quanto maggiore è l'accesso ai revisori della sicurezza, tanto più efficacemente possono svolgere il proprio lavoro. Tuttavia, l'aumento dell'accesso si traduce in un aumento dei costi: sia perché fanno pagare di più per un controllo più approfondito, sia perché aumentano i costi in termini di aumento della responsabilità e maggiore fiducia che si deve estendere a questa azienda e ai suoi dipendenti. Stai parlando di dare loro liberamente il controllo completo su tutti dei tuoi sistemi aziendali. Non riesco a immaginare nessuna circostanza in base alla quale sarei d'accordo.

    
risposta data 25.10.2017 - 19:41
fonte
112

How should I proceed?

Non procedere con loro. Il modo in cui agiscono è poco professionale. I pentiti comportano rischi per entrambe le parti e non sembra che abbiano fatto nulla per affrontarli.

Per prima cosa, non dovresti assolutamente consegnare nulla senza un contratto scritto (inclusa una NDA). È sorprendente che abitualmente facciano affari del genere. Come fanno a sapere l'ambito esatto? Sotto quali termini vengono pagati? Si limiteranno a "chiudere" a un certo punto o c'è un orario? Hai un rapporto adeguato? Chi paga se causa danni? Sono assicurati nel caso in cui perdano le vostre credenziali a terzi? Come farai a sapere se una futura violazione fa parte del test o un attacco effettivo da parte di qualcun altro? Anche se ti fidi di loro, queste domande dovrebbero essere risolte prima di dare il via a un pentimento.

E non sono solo te, si stanno mettendo a rischio. Se non hai mai chiarito l'ambito, potrebbero attaccare alcuni dei tuoi sistemi senza autorizzazione, con potenziali implicazioni legali.

I assumed it would mostly be black box.

Entrambi i test in bianco e nero sono comuni e ogni approccio ha i suoi vantaggi . Ma se la modalità di test non è mai venuta fuori, sembra che non ci sia mai stata una discussione su cosa si dovrebbe ottenere conducendo un pentest in primo luogo. Un appaltatore professionista ti avrebbe aiutato a capire le giuste condizioni e metodi.

(Un'ottima prima domanda a un potenziale appaltatore è quella di chiedere un rapporto di pentest esemplare che ti darà un'idea iniziale di come funzionano e quali risultati potresti aspettarti.)

    
risposta data 25.10.2017 - 19:58
fonte
38

Prima di ogni test di penetrazione devono essere presenti un documento di Scoping e regole di ingaggio firmato da entrambe le parti. Questi documenti dovrebbero descrivere in dettaglio ciò che verrà testato e quali metodi sono stati concordati dalla vostra azienda e dal contraente. Se non hai affrontato questa discussione con il tuo appaltatore, interrompi il fidanzamento e cerca altri professionisti.

Come tester di penetrazione, ho chiesto alle aziende di fornire account o laptop che avrebbero fornito a un utente normale. Ciò consente di testare da una prospettiva di dipendente malintenzionato. Tuttavia, questo è tutto concordato prima del test in Scoping e Regole di ingaggio.

Solo i miei 2cents.

    
risposta data 25.10.2017 - 23:11
fonte
25

MAI MAI !!

Stiamo facendo un pentimento al mio lavoro. È stato esplicitamente dichiarato dai pentesters che non hanno nemmeno bisogno del login / password per nulla. Abbiamo dichiarato che era grandioso dal momento che non avremmo mai pubblicato nulla per loro in mano. Ci sono 3 tipi principali di pentiti: scatola bianca, scatola grigia, scatola nera.

White Box è che tu dai loro tutte le informazioni e loro trovano problemi con il tuo software, la rete, ecc.

Grey Box è che dai loro alcuni dettagli su ciò che vuoi che pentano. Lo usavamo dal momento che non avevano idea di quale ISP wireless esterno stavamo usando. Gli abbiamo detto di fare un test esterno per primo, così abbiamo dato loro alcuni IP e loro si sono lasciati facilmente.

Black Box è che non fornisci loro nulla e devono trovare tutto da solo. Dopo di ciò possono fare il loro pentest sugli IP esterni. Per i test interni, è diverso. Saranno all'interno della tua rete eseguendo nmap e altre scansioni intense su ogni target che incontrano. Questo è il più difficile, ma il migliore secondo me.

    
risposta data 25.10.2017 - 23:42
fonte
20

My company is currently engaged in a security audit framed as a pentest.

e

Note, we've never signed a single NDA or other contract with them yet, and I'm very reluctant to provide this info to them because of this.

L'uso di "impegnati" in questo contesto implica una definizione di "stipulare un contratto per fare qualcosa". Questo mi lascia chiedermi se le dichiarazioni contrastanti sono accidentali o se non sei l'entità all'interno della tua azienda che ha ingaggiato la compagnia di sicurezza.

Se quest'ultimo, potrebbero esserci dei contratti / accordi di cui non sei stato informato. Ciò non sarebbe inusuale, in quanto molti dei test di penetrazione in cui sono stato sul lato ricevente nascondono i dettagli specifici del test da parte dei dipendenti in modo da non intraprendere azioni "anormali" da proteggere contro i test.

Se questo è il caso, allora fai con la richiesta cosa faresti normalmente con tale richiesta. Dì loro "no" e se respingono ("ma è necessario per noi eseguire il test di penetrazione"), quindi esegui la richiesta (per iscritto) al tuo supervisore fornendo i tuoi dubbi. Se il tuo supervisore ti dice (per iscritto) di rilasciare queste informazioni, dovresti essere chiaro perché potrebbero avere una migliore comprensione del test rispetto a te. Se i tuoi superiori non sono chiari, procedi con la catena di comando e / o spingi affinché possano chiedere indicazioni all'entità che ha ingaggiato la compagnia di sicurezza.

Tuttavia, se sei l'entità che ha ingaggiato la società di sicurezza, io (come le altre risposte qui) avrei serie preoccupazioni. Se ritieni che possa valere la pena perseguire (o sei preoccupato che facciano una sorta di richiesta di "violazione del contratto"), ti suggerirei di utilizzare un mezzo per valutare se si tratta di un test di ingegneria sociale. Ad esempio, è possibile generare un elenco di account amministratore e password falsi. Fornisci questo a loro, dì che stai ancora lavorando al resto, e lo invierai mentre è pronto. Quindi vedi come rispondono.

Se si tratta solo di un test di ingegneria sociale, tutto ciò di cui hanno bisogno è vedere la prova di questo tipo di informazioni trapelate (che è possibile mostrare successivamente sono account falsi). Una società di sicurezza responsabile non dovrebbe aver bisogno di più delle informazioni richieste e dovrebbe impedirti di fornirle ("Guardando a ciò che hai fornito, penso che questo dovrebbe essere sufficiente per farci procedere, non preoccuparti del resto a meno che non si trasformi ne abbiamo davvero bisogno "). Se non interrompono ulteriori informazioni, disinnestare immediatamente.

Altre informazioni potrebbero solo sospettare qualsiasi penetrazione che eseguono da quel momento in poi (ovvero è facile penetrare in un sistema se si ha accesso amministrativo) e / o esporle a potenziali cause legali sulla proprietà intellettuale (ad esempio codice sorgente trapelato, ecc. ).

    
risposta data 26.10.2017 - 01:00
fonte
8

Venendo alla domanda da un'angolazione leggermente diversa:

Sei l'amministratore delegato o CTO?

No? Quindi non dare agli auditor alcuna password. Mai.

Metti insieme un pacchetto di informazioni e inoltralo alla catena al tuo responsabile IT, CTO, CEO o altro. Per dirla senza mezzi termini, è compito loro prendere quelle decisioni (e prenderne le conseguenze), non le vostre.

Se il tuo capo dice "No, lo mandi". quindi rispondi: "Come dipendente, non mi sento a mio agio nel rilasciare informazioni così pericolose a terzi".

Se sei, infatti, il CTO, quindi consulta le risposte sopra.

    
risposta data 02.11.2017 - 03:24
fonte
3

Convalida le tue ipotesi.

Se questo dovrebbe essere un test della scatola nera, non dovrebbero ottenere o richiedere alcuna password.

Se questa dovrebbe essere una recensione di configurazione, o test di white box, alcune password dovrebbero essere consegnate. La procedura corretta è cambiarli prima del test con qualcosa di unico (stringa casuale), e quindi cambiarli di nuovo dopo il test.

Rivolgiti alla direzione e chiedi esplicitamente se sono state firmate le NDA e i contratti appropriati.

Is this normal for a pentest?

Lo scenario che hai descritto è insolito, ma non del tutto inverosimile. Tutto dipende da cosa è stato esattamente concordato per lo scopo e le attività del test.

I assumed it would mostly be black box. How should I proceed?

Verificare con il manager responsabile della firma di questa squadra di pentesting. Il tuo CISO o CSO o responsabile IT o chiunque esso sia. Parla delle tue preoccupazioni e chiedi se questo approccio è stato concordato.

Assegnazione di password / codice sorgente

Personalmente, non darei alcuna password o codice sorgente a nessuno senza un adeguato NDA firmato. Inoltre, non darei mai e poi mai le password effettive. In tutti i pentests in cui sono stato coinvolto, da entrambe le parti come cliente e project manager (non sono un pentester, ma ho gestito pentesters) c'erano sempre account utente creati per il pentest e password cambiate. Consigliamo persino ai nostri clienti di cambiarli dopo che il test è stato eseguito (alcuni non lo fanno, è sempre una triste scoperta per il prossimo rapporto).

Forza password

Per quanto riguarda ciò che alcune risposte hanno scritto su "valutare la forza della password" - questo è un carico di hogwash. Sì, c'è una "buona pratica" su buone password, che qualche ragazzo ha tirato fuori dal nulla qualche decennio fa ed è terribilmente dispiaciuto per oggi. Tutta la matematica sull'argomento è piena di buchi e ipotesi non verificate e molte policy sulle password riducono lo spazio di ricerca invece di ingrandirlo. L'unico vero test per la robustezza della password ha due parti: una, ottenere le prime 10.000 password da una delle circa 20 liste che galleggiano su Internet e usarle come lista nera. Due, esegui lo stesso software di cracking che i malintenzionati usano (molti di questi sono software libero) sugli hash delle password. Se la tua istanza di John la incrina, lo farà anche loro.

    
risposta data 26.10.2017 - 14:51
fonte

Leggi altre domande sui tag