Sembra un problema di silos

Ciò che la tua domanda significa è che la tua azienda potrebbe soffrire di silos aziendali

descrivono i silos organizzativi l'isolamento che si verifica quando i dipendenti o interi reparti all'interno di un'organizzazione non vogliono o non hanno i mezzi adeguati per condividere informazioni o conoscenze tra loro. I team in silos spesso finiscono per lavorare isolati dal resto dell'azienda, portando a una pletora di problemi interni ed esterni per dipendenti, dirigenti, partner e clienti.

Diamo un'occhiata alla tua domanda

Il nostro team è autorizzato dalla direzione a condurre scansioni di vulnerabilità della sicurezza e l'approvazione è documentata in un documento di policy. Sono state inviate notifiche adeguate prima dell'inizio del test.

La direzione ha detto al tuo team di testare la sicurezza, così hai fatto. A chi sono stati inviati gli avvisi? Se la tua risposta è alla direzione , hai un problema a silo.

Un altro team dell'azienda che possiede questa applicazione mi ha interrogato sulle modifiche non intenzionali. Ho spiegato che il test era autorizzato dalla direzione di entrambi i team, ma durante la scansione automatica, la modifica che hanno visto non era intenzionale a causa di un errore e non ha tentato di hackerare / sabotare. Non erano contenti / convinti e hanno inviato un'email al mio manager che è in vacanza.

Il tuo silo è la sicurezza. Il loro è il sito web. Il tuo silo ha rotto il loro silo. Diamine, potrebbero non aver mai sentito parlare di te prima di questo incidente. Non dovrebbe sorprenderti che non siano felici. Qualcuno li sgriderà per il sito web non funzionante e loro, a loro volta, ti indicheranno. Indicherai la direzione e il tuo mandato per testare la sicurezza. A questo punto la gestione inizia a sembrare scadente, quindi faranno alcune cose superficiali e faranno sparire tutto assicurando a tutte le parti coinvolte che stanno andando alla grande!

Almeno fino a quando il sito web non si rompe di nuovo ...

Riconosci i silos

Devi essere proattivo qui. La prima cosa è capire tutti i silos. Non puoi aggiustare l'infrastruttura aziendale da solo. Quello che devi fare è sapere tutte le dita dei piedi che calpesterai se il tuo silo si rompe un altro. L'ultima cosa che vuoi è un altro allenatore che urla al tuo allenatore.

Per farlo, inizia a parlare con le altre squadre. Non farlo durante una riunione, cerca di essere informale. Questo è solo a tuo vantaggio. Chiacchierare con altri dipendenti in altri team può dirti cosa stanno facendo. Prendi nota del punto in cui i tuoi processi si intersecano con i loro.

Difendi il tuo lavoro

A questo punto, le persone frustrate potrebbero dire "Non abbiamo bisogno di quel lavoro /", soprattutto se silo sembra più importante. La sicurezza è una delle prime cose da fare in molti ambienti aziendali. Assicurati di poter spiegare perché esiste il tuo lavoro.

Proponi di riparare il tuo silo

Se non hai mai sentito parlare di DevOps prima (Chef, Docker, Kubernetes, ecc.), Ti suggerisco lo proponi come soluzione per la prossima volta. DevOps ti consente di avviare gli ambienti su richiesta, quindi puoi modificare / testare / interrompere questi ambienti di spin-up senza interrompere nessuno di quelli attivi.

DevOps dovrebbe comunque essere importante per l'implementazione mission-critical, per timore che tu non riescono a distribuire le cose correttamente e accadono cose brutte.

Gli eventi del 1 ° agosto 2012 dovrebbero essere una lezione per tutti i team di sviluppo e operativi. Non è sufficiente creare un ottimo software e testarlo; devi anche assicurarti che venga consegnato correttamente sul mercato in modo che i tuoi clienti ottengano il valore che offri (e quindi non manderai in bancarotta la tua azienda). Gli ingegneri che hanno implementato SMARS non sono i soli da biasimare qui: il processo che Knight aveva impostato non era appropriato per il rischio a cui erano esposti.

Qualcuno dovrebbe essere in grado di offrirti un ambiente live separato dall'ambiente reale. In caso contrario, interromperai di nuovo il sito web. E di nuovo. A questo punto, brevi riunioni possono essere utili. Assicurati di avere linee di comunicazione dirette con gli altri silos e non fare affidamento sulla direzione per informarli di ciò che sta facendo il tuo silo.

Ripristina le modifiche.

Dal post & i commenti sembra che tu possa facilmente ripristinare le modifiche ma non vuoi:

ha pensato di ripristinare le modifiche in PROD, ma temo che si tratterebbe di una modifica non autorizzata

Oltre a ottenere l'approvazione della richiesta di modifica per il rollback ....

ma sarebbe considerata una modifica non autorizzata? Molto probabilmente questo sarà un cambiamento di emergenza. Questo rollback non era previsto né esplicitamente autorizzato

Nota: presumo che tu abbia eseguito un backup subito prima di iniziare

Smetti di giocare alle regole della polizia e ripristina la modifica. Se lo ripristini subito, c'è una buona probabilità che nessuno se ne sia nemmeno accorto (ma dovresti comunque avvisare qualcuno in modo che possa apportare modifiche / precauzioni appropriate per la prossima volta).

Nessuno si lamenterà con te erano autorizzati a deturpare il sito web ma non autorizzati a ripristinare tali modifiche.

Si prega di ottenere la pre-autorizzazione per ripristinare le modifiche per questo tipo di cose prima che si verifichino. Ad esempio, sembra che apportare modifiche non autorizzate sia una sorta di regola scritta, è necessario aggiungere una clausola per annullare questo tipo di errori.

Nota aggiuntiva : a volte è necessario eseguire test di sicurezza da eseguire nel proprio ambiente di produzione, non in un ambiente di test. Dove mi trovo, troviamo sempre piccoli casi limite o modi in cui l'ambiente di test non corrisponde esattamente all'ambiente di produzione, indipendentemente da quanto ci sforziamo.

Quindi, anche se spero che tu abbia un ambiente di test, posso capire perché vorresti testare l'ambiente di produzione. Tuttavia, il test della penna dovrebbe essere prima eseguito nell'ambiente di test, se fallisce, puoi presumere che lo faccia anche l'ambiente di produzione.

Qual è il miglior modo per spiegare che la mia intenzione non era dannosa ma un vero errore?

Questa è la tua prima domanda.

il cambiamento che hanno visto era involontario a causa di un errore e non ha tentato di hackerare / sabotare. Non erano contenti / convinti e hanno inviato un'email al mio manager che è in vacanza.

Pensano che tu abbia deliberatamente deturpato il sito web? A che scopo? Non sapevano che il test era autorizzato? Queste persone sono il tipo da indossare cappelli di carta stagnola?

Ho emesso per sbaglio un comando che ha deturpato il sito web. Se qualcuno non è a conoscenza, alcuni moduli all'interno di Burp Suite come Spider o Intruder, sono estremamente potenti, consentendo attacchi completamente automatizzati contro vulnerabilità comuni.

Da ciò, deduco che il deturpamento sia avvenuto perché un esiste una vulnerabilità di sicurezza sul sito Web di produzione. In che modo risolvere questo problema non ha la precedenza sul gioco della colpa? Perché un principe nigeriano casuale non ha potuto deturpare il sito web nello stesso modo in cui lo hai fatto tu?

Ovviamente, sarebbe stato l'ideale per rilevare la vulnerabilità senza il deturpamento, ma questo potrebbe essere accaduto da un vandalo casuale.

Ho pensato di annullare le modifiche in PROD, ma temo che si tratterebbe di una modifica non autorizzata, il che sarebbe in senso stretto.

Che tipo del posto di lavoro in cui trovare una vulnerabilità di sicurezza (anche se accidentalmente) viene trattata con questo livello di sospetto? Che tipo di posto di lavoro ti trovi in ​​cui hai la capacità di fare un rollback ma non sai se ti è permesso fare quella correzione? Quali sono le regole se il prodotto scende? Non c'è nessuno di guardia?

Finora non ho davvero risposto perché sembra assurdo dover convincere la tua azienda che non hai deliberatamente vandalizzato il sito. Se hai davvero bisogno di convincere la tua azienda di questo, il primo documento che dovresti aggiornare è il tuo curriculum.

Oltre a ciò, raccogli tutta la documentazione che hai sull'approvazione del test e vedi quanto puoi spostare la conversazione concentrandoti sulla vulnerabilità della sicurezza. Se la cultura è come sembra, potrebbe valere la pena parlare dei pericoli della vulnerabilità e del motivo per cui il team di sviluppo potrebbe aver bisogno di formazione sulla sicurezza.

Data la portata delle nostre applicazioni, il test manuale sarebbe inefficiente / richiederebbe tempo. Come posso mitigare la probabilità che tale istanza vada avanti?

Non disponi di ambienti di test duplicati? È lì che avrebbe dovuto essere eseguita la maggior parte di questi test. Clona il sito esistente e picchialo con qualsiasi cosa sapendo che esiste solo per test di sicurezza. Nel mio lavoro, abbiamo diversi sottodomini che ospitano cloni utilizzati per vari test.

Come posso mitigare la probabilità che tale istanza vada avanti?

Non testare mai in produzione a meno che non ci sia un altro metodo praticabile. Utilizza un sistema di backup, almeno per il test iniziale.

Se devi eseguire il test in produzione, fallo durante le ore non lavorative con un piano di ripristino scritto, approvato e testato.

Assicurati che i backup di tutti i dati e il codice siano completamente aggiornati e pronti per essere ripristinati prima.

In qualità di persona che lavora nella gestione dei servizi IT, vorrei chiarire una domanda che hai posto sul fatto che un rollback sia una modifica autorizzata -

Un problema (deturpazione del sito Web di produzione) che richiede una modifica immediata per essere risolta. Questa è classificata come richiesta di modifica di emergenza e dovresti identificare e implementare la procedura per questo.

Per essere chiari, il bug / errore / errore che ha alterato e deturpato il sito web era una modifica involontaria / non autorizzata. È ora necessario ripristinare tale modifica, seguendo qualunque sia il processo di richiesta di modifica di emergenza della propria azienda. qualsiasi organizzazione più grande (250 dipendenti o più) avrà un processo chiaramente definito e stabilito per questo.

Ora: non apportare modifiche senza comunicare ai proprietari del prodotto - Se hai apportato una modifica a un sito web di "proprietà" da qualcun altro, è necessario tenerli aggiornati. Se sono arrabbiati, questo è probabilmente il componente che li turba ... le persone si stressano quando sono responsabili di cambiamenti o problemi che sono stati creati da qualcun altro. La cosa migliore che puoi fare qui è assicurarti che siano a conoscenza di ciò che è accaduto e tenerli al corrente di ciò che stai facendo per risolvere il problema, delle tempistiche previste, ecc .

Inoltre, se la modifica è quella che possono apportare loro, dovresti comunicare con il proprietario del prodotto di questo sito web e chiedere se desidera che tu risolva il problema (se hai il capacità di, tramite la tua app burp suite) o se desiderano lavorare per apportare le modifiche necessarie per risolvere il problema. Fallo in modo molto, molto educato, senza implicare che "è il loro lavoro" e stai stringendo la mano della situazione; Idealmente, avranno la sensazione che tu li tenga aggiornati e che consenta loro in modo appropriato di prendere le decisioni su ciò che accadrà con il loro prodotto.

Non andrei fuori di testa per questo: queste cose accadono. Comunica onestamente e apertamente con tutte le persone coinvolte, e fintanto che non stavi seriamente facendo nulla fuori linea (come cercare di fare il lavoro di qualcun altro per sovvertire l'autorità di persone diverse o fare qualcosa che non dovresti), la maggior parte del ora andrà tutto bene.

Ora, per quanto riguarda se il rollback di quel sito web deturpato è una modifica approvata o meno ... All'interno di Change Management , la maggior parte delle organizzazioni ha un concetto di Richiesta di modifica di emergenza.

Una modifica di emergenza è in genere una modifica / problema che richiede un IMMEDIATO la correzione e, in alcune organizzazioni, può avvenire con una severa riduzione o anche con nessuna approvazione preventiva.

La procedura per una richiesta di modifica di emergenza dipenderà fortemente dalla tua organizzazione - Alcuni potrebbero dire "Vai avanti e apporta la tua modifica per riportare i sistemi online, ecc. e poi documenta con una richiesta di modifica di emergenza dopo il fatto", e alcuni potrebbero dire "invia la tua risposta predefinita per le emergenze e informa il direttore del tuo dipartimento immediato [o la persona coinvolta nell'approvazione dei cambiamenti di emergenza, di solito a livello di direttore] in modo che possano approvarli immediatamente; Se non sono disponibili, avvisa il direttore nella prossima area adiacente apartment per ottenere l'approvazione "

Questa è una buona opportunità per conoscere qual è la politica di gestione del cambiamento di emergenza del tuo dipartimento e come potrebbe differire dalla normale procedura di gestione del cambiamento.

Perché la realtà è: le cose accadono. I sistemi potrebbero non funzionare, i database potrebbero essere danneggiati ... Se si verifica un problema che si è verificato involontariamente in produzione e si desidera risolverlo immediatamente, è probabile che sia necessario implementare la procedura di richiesta di modifica di emergenza della propria organizzazione, poiché richiede modifiche che non si adattano nei processi e nelle finestre di richiesta di modifica regolarmente pianificati.

Chiedi al tuo manager o al suo manager (se è fuori sede) qual è la procedura di gestione del cambiamento di emergenza della tua organizzazione e spiega cosa è successo. Ti guideranno attraverso cosa fare dopo.

PIÙ IMPORTANTE: non nascondere nulla di ciò che hai fatto. Non mentire mai su quello che è successo, non lasciare che la paura ti convinca a cambiare il modo in cui gestiresti questa situazione. Succede, e il 99% delle volte, a patto di adottare misure ragionevoli per comunicare e gestire il problema che si è verificato, non dovresti preoccuparti di essere licenziato a meno che tu non abbia una gestione davvero incompetente oa meno che la modifica che hai apportato non abbia avuto un impatto estremamente grave sull'azienda.

Preparati a spiegare al tuo manager (che trasmetterà al suo manager e / o all'altro dipartimento che ha interessato l'applicazione) perché si è verificato il problema e cosa sarà fatto per prevenire o ridurre la probabilità che accada di nuovo in futuro. Dovrebbe essere intrapresa un'azione chiara al riguardo; O una procedura in fase di implementazione, la creazione di conoscenze / formazione per impedire alle persone di commettere questo errore in futuro, ecc., Qualcosa per garantire che qualcuno non finisca per deturpare altri siti Web di produzione in futuro.

Per esempio: si sarebbe potuto fare questo in un ambiente di test, senza sacrificare l'accuratezza dei risultati? Il pulsante che ha deturpato il sito Web (o lo script automatizzato, se automatizzato), potrebbe essere disabilitato? È possibile implementare un rollback automatico dopo che si è verificato ed è stato testato? Queste sono cose utili da identificare e da guardare per sviluppare un piano per il futuro per evitare che ciò accada di nuovo. Questo è il tipo di cose che la direzione sopra di te e l'altro gruppo saranno soddisfatte di sentire dopo che il problema sarà stato risolto, per consentire loro di tornare ad altri mal di testa.

In qualità di penetration tester con più di 5 anni di esperienza, anch'io ho commesso errori simili e ho visto altri farlo, quindi credo di avere alcune informazioni che potrebbero essere utili.

Per affrontare cosa Immagino che il punto principale della tua domanda sia che è successo qualcosa di brutto, ha avuto conseguenze per un'altra squadra, nessuno sapeva come gestirlo, e sia tu che il team del sito web siete rimasti un po 'confusi e sbalorditi da tutto ciò. Questo è in realtà un caso "classico" di aspettative mal gestite riguardo a cosa sia il test di sicurezza, alle potenziali conseguenze negative di esso e alla scarsa pianificazione riguardo a cosa fare quando qualcosa si rompe.

Una migliore pianificazione ovviamente non annullerà il danno già fatto, ma questa è un'opportunità eccellente per te e la tua azienda per imparare come prepararti meglio per un test di sicurezza in futuro. Il team del sito web probabilmente si aspettava che i tuoi test fossero innocui e privi di rischi, mentre ti aspettavi che avessero un sito web resiliente che non fosse facilmente deturpato da strumenti automatizzati e che avessero un modo per ripristinare facilmente uno stato buono conosciuto se qualcosa di cattivo ha accadere.

Avere questo tipo di riunione di pianificazione prima di un test di sicurezza è solitamente chiamato "riunione di scoping" nel gergo dei test di penetrazione, e viene utilizzato per prevenire questo tipo di situazioni. Non sono sicuro se hai avuto un incontro con il team del sito web prima di iniziare il test, ma in futuro dovresti sempre iniziare un nuovo test di sicurezza con esso in modo da poter concordare i dettagli del test e avere un quadro di riferimento comune . I punti seguenti delineano ciò su cui credo sia necessario concordare prima di iniziare qualsiasi test di sicurezza:

1. Spiega cos'è in realtà un test di sicurezza! È possibile chiarire molta confusione spiegando di cosa si tratta e cosa si intende effettivamente fare. Se usi una parola come test di penetrazione, potrebbe non essere nel vocabolario di tutti, e francamente suona un po 'sporco. Quindi spiega cos'è, perché lo stiamo facendo, perché è vantaggioso per loro e, forse, cosa più importante, cosa non può non fare poiché è spesso visto come un rituale magico che farà in modo che il tuo l'applicazione è al 100% a prova di hacker. Dire loro che viene utilizzato per scoprire le vulnerabilità di sicurezza in modo che il team del sito web possa risolverle prima che gli hacker malvagi le sfruttino di solito funziona bene.
2. Qual è l'effettivo scopo del test? C'è qualcosa che è rigorosamente off-limits e non dovrebbe essere toccato? Annotalo e assicurati che tutte le parti lo abbiano per iscritto e siano d'accordo.
3. In che tipo di ambiente dovrebbe avvenire il test? Hai eseguito dei test in produzione e talvolta non ci sono altre opzioni. Ma se stai testando in un ambiente ad alta posta in gioco, assicurati che tutte le parti ne siano consapevoli e concordino sul fatto che accadrà lì, e che siano consapevoli che gli scenari peggiori potrebbero includere la perdita di dati e / o la loro integrità. Questo è spesso il luogo in cui è necessario porre le domande "ovvie" come: "Hai un backup?" e "Cosa farai se rompo qualcosa sul tuo sito web?". Se non riescono a rispondere a queste domande in modo rassicurante, forse è il momento di pensare se sono veramente pronti per i test di sicurezza. Se il tuo test di sicurezza pianificato e controllato può portarli a uno stato non recuperabile, molto probabilmente la tua azienda ha problemi più grandi e dovresti cercare di risolverli prima di procedere con un test ad alto rischio. Se li hanno, assicurati che sia documentato e concordato sul fatto che hanno la responsabilità di ripristinare le cose se qualcosa si rompe nel test.
4. Se sei una parte americana e / o esterna, assicurati di aver creato e firmato tutta la documentazione legale necessaria. Chiedi al tuo ufficio legale di aiutarti in quanto potrebbero esserci trappole legali interessanti, come obblighi della società madre e sub-società, parti dei server in altri paesi con leggi diverse, domande sulla responsabilità personale, ecc. Questo è per proteggere entrambi voi personalmente da eventuali reclami e per proteggere l'azienda da se stessa.
5. Concordare come, chi, quando e cosa fornire informazioni sull'inizio, l'arresto e lo stato di avanzamento del test. Ad alcune persone piace essere informate quando si avvia il test e rispetto a cosa, in modo che possano tenere d'occhio ciò che sta accadendo. Fornire informazioni è sempre fondamentale in modo da non dare l'impressione di essere "impazzito".

Quanto sopra non è un elenco esaustivo, ma credo che possa aiutarti ad andare avanti per evitare trovarsi di nuovo in situazioni simili. I test di sicurezza sono purtroppo intrinsecamente pericolosi in quanto si tratta di dimostrare che un sistema informatico può fare qualcosa per cui non era previsto, mentre il resto dell'informatica è principalmente interessato a dimostrare che i computer possono fare quello che era previsto e non lasciare che questa brutta esperienza scoraggia te o la tua azienda dal fare futuri test di sicurezza. Una migliore pianificazione ridurrà al minimo il rischio e, come per qualsiasi cosa nuova, ci sono sempre problemi crescenti, ma nel tempo dimostrerai valore e sarai visto come un vantaggio e non solo come un nuovo potenziale incidente di sicurezza.