Che cosa deve includere un rapporto di controllo di sicurezza?

Ci sono un paio di modi in cui ho visto questo fatto, ognuno ha i suoi pro e contro.

Come notato da @RoryAlsop sotto un punto comune per entrambi gli approcci è che il sommario esecutivo dovrebbe, per quanto possibile, essere scritto per un pubblico aziendale (supponendo che si tratti di un test che stai facendo per una terza parte o il rapporto sarà passato alla gestione).

• Segnalazione trovando. Qui elencherai i risultati, solitamente classificati in base alla gravità (ad esempio, punteggio CVSS o qualche altra scala come gravità / verosimiglianza). Elencherai quindi i dettagli tecnici del ritrovamento e le potenziali attenuazioni se disponi di tali informazioni. Questo tipo di report arriva al punto abbastanza rapidamente e funziona bene con l'output dello strumento.
• Rapporti sulla base della metodologia. Supponendo che stai seguendo una metodologia di test definita, il rapporto è strutturato secondo le linee della metodologia e include una sezione per ogni area della revisione. Le sezioni descrivono in dettaglio cosa sono stati effettuati i test e il risultato (ad esempio, una constatazione o il fatto che in questa sezione non è stato trovato alcun risultato). Il vantaggio qui è che stai mostrando il tuo funzionamento e che qualcuno che legge il rapporto può avere una buona idea che tu abbia effettivamente provato qualcosa ed è stato ok piuttosto che te lo sei perso. Lo svantaggio è che tende ad essere un rapporto più lungo e più difficile da automatizzare. Un altro trucchetto è che devi assicurarti che i tester non seguano semplicemente la metodologia e in realtà impegnino il cervello a cercare altre cose.

In termini di formato per i risultati, di solito includo i seguenti

• Titolo (descrittivo viene utilizzato nella tabella e collegato al dettaglio)
• Descrizione: descrizione tecnica del problema e, soprattutto, in quali circostanze è probabile che causi un problema di sicurezza (ad esempio per Cross-Site Scripting uno dei potenziali problemi è utilizzare i token di sessione che potrebbero consentire a un utente malintenzionato di ottenere accesso non autorizzato all'applicazione)
• Consigli - Come risolvere il problema, se possibile includere dettagli specifici sulla guida del fornitore per risolverlo (ad esempio, cose come la rimozione di versioni del server web dalle intestazioni hanno istruzioni specifiche per Apache / IIS ecc.)
• Riferimenti - Collegamenti a informazioni aggiuntive rilevanti per il rilevamento (ad esempio collegamenti alla pagina OWASP pertinente per problemi relativi alle app Web)
• Gravità. Come ho detto sopra, questo potrebbe essere CVSS o qualcosa di più generale come Alta / Media / Bassa in base all'impatto e alla verosimiglianza.
• Altre classificazioni secondo necessità del cliente. Ad esempio, alcuni clienti potrebbero aver bisogno di cose allineate a uno standard o una politica o qualcosa come OWASP Top 10.

Un altro punto da sottolineare è che se fai molti test vale la pena avere un database di risultati precedenti per evitare di dover cercare ripetutamente i riferimenti e assicurarti che le severità siano coerenti.

Domanda interessante! Troppo spesso ritengo che la nostra industria si impegni per l'ultima e più grande moda della sicurezza. Seguiamo gli ultimi exploit, spendiamo molto denaro sugli ultimi strumenti e incolpiamo lo strato 8 per le lacune. So che è una grossolana generalizzazione, ma volevo sottolineare l'importanza di questo argomento - Reporting!

Ho le mie opinioni su cosa dovrebbe essere incluso in un rapporto sulla vulnerabilità. Dal punto di vista della struttura, un rapporto approfondito avrà il seguente:

• Una pagina del titolo : indica il nome del rapporto, l'agenzia o il reparto per cui è, la data in cui è stato pubblicato il rapporto.

• Un sommario : sembra ovvio, ma questi documenti possono essere lunghi, includerlo come cortesia.

• Un sommario esecutivo : si tratta di un riepilogo di alto livello dei risultati, di ciò che è stato trovato e di ciò che è la linea di fondo.

• Un'introduzione : una semplice dichiarazione delle tue qualifiche, lo scopo dell'audit e ciò che era nell'ambito.

• Risultati : questa sezione conterrà i risultati e elencherà le vulnerabilità o problemi che dovrebbero essere re-mediate. Questo elenco dovrebbe essere ordinato in base a livelli critici, dei quali si spera siano definiti da politiche interne (cioè se lo scanner di vulnerabilità rileva una vulnerabilità critica elevata, basata su come viene implementata tale vulnerabilità nel proprio ambiente, potrebbe non essere un vero fattore critico, quindi le politiche interne dovrebbero aiutare a definire i livelli critici)

• Metodologie : qui discuterai gli strumenti usati, come sono stati esclusi i falsi positivi, quali processi hanno completato questo audit. Questo per garantire coerenza e consentire la ripetibilità dei controlli nel caso in cui un risultato sia contestato o ritenuto non degno di essere risolto dalla direzione.

• Conclusione : conclusione di base, riepilogare le informazioni che hai già messo insieme.

• Appendici : si tratterà di eventuali allegati aggiuntivi necessari per riferimento.

Alcune persone che lavorano sul PTES stanno gettando alcune buone basi. Mentre l'attenzione è focalizzata sui test di penetrazione, ritengo che molte delle metodologie, in particolare le relazioni, potrebbero essere recepite per un audit. Puoi verificarli all'indirizzo link .

Dopo un test di penetrazione o un'analisi delle applicazioni ibride, il rapporto risultante è centrato sui risultati. Ci dovrebbe essere una panoramica di alto livello che discute i difetti e il loro impatto collettivo sul sistema.

Un risultato è una violazione della sicurezza. Ciò include qualsiasi violazione CWE , ma i risultati delle applicazioni Web più comuni rientrano nella top 10 OWASP. dovrebbero avere dei passaggi per riprodurre il problema, una gravità, l'impatto di questo difetto, consigli per risolvere il problema e collegamenti con maggiori informazioni. Ad esempio, se si riscontra una vulnerabilità XSS, mostrare una schermata iniziale di una casella di avviso e l'URL utilizzato per attivare il problema e collegarsi alla pagina OWASP su XSS. Se è possibile accedere al cookie con XSS, il problema può essere utilizzato per dirottare una sessione, altrimenti potrebbe essere utilizzato per compromettere la protezione CSRF.

Che cosa succede se non riesci a trovare nulla? Continuare a cercare! Il sistema CWE è enorme e anche gli sviluppi più stagionati commettono errori. Ci sono vulnerabilità che riguardano letteralmente ogni applicazione che ho toccato. Clickjacking, mancanza di protezione da forza bruta e divulgazione di informazioni è probabilmente il più comune. Ad esempio la divulgazione del nome utente / indirizzo e-mail tramite la password dimenticata o la funzione di registrazione. Visualizzazione dei numeri di versione (intestazioni http o altrove). Messaggi di errore dettagliati, percorsi locali, indirizzi IP interni .... tutto ciò che potrebbe essere utile a un utente malintenzionato.

Penso che ciò che Rook dice sia vero, anche se questo riguarda più il nucleo del report, piuttosto che la sua struttura, da collocare dopo che il formato del report è stato progettato.

Prova il modello STAR (Situazione, Attività, Azione e risultato): ho visto ottime relazioni scritte con questo modello sotto il cofano. Il bello è che può essere utilizzato in quasi tutti i contesti: dovresti solo adattarti a ciò che è rilevante per te. In questo caso, puoi strutturare il tuo rapporto su questo modello e utilizzare ciò che Rook ha descritto per riempire la struttura.

Inoltre, anche se non disponi di risultati effettivi, puoi ancora scrivere un rapporto completo basato sul modello STAR e comunque offrire qualcosa di professionale e coerente.

Non ho mai scritto un rapporto sui controlli di sicurezza, sebbene nel mio ruolo tendo a riceverli. Il migliore che abbiamo esaminato il nostro intero prodotto in specifiche aree di interesse. Il rapporto è stato suddiviso in quelle aree. Nel complesso, il formato era:

1. Titolo
2. Sommario esecutivo: una breve panoramica dello scopo e della portata dell'audit. E i commenti di alto livello, sulle principali aree di interesse e, soprattutto, riguardano quelle aree che sono state fatte bene
3. Metodologia di valutazione
4. Descrizione del sistema - che copre la distribuzione oggetto di indagine
5. Quindi sezioni su ogni area / target
6. Riepilogo e consigli

La sezione 5 è stata suddivisa per ciascun obiettivo come:

1. Introduzione
2. Obiettivo
3. Significato
4. Valutazione (che copre metodologie e vulnerabilità reali)
5. Conclusione

In primo luogo: è come scrivere un libro, la prima riga manterrà il lettore o no. (L'introduzione è di scrivere almeno.)

Qualcosa come introduzione, inizio, contenuto, fine.

• Introduzione
• Obiettivi
  • Aggiorna i termini del contratto.
  • Descrizione degli obiettivi
  • Descrizione dei metodi
• Esecuzione
  • Passo dopo passo: obiettivo, azione, reazione
  • Osservazioni - > domande
  • ulteriori operazioni, passo dopo passo
  • Nuove osservazioni ...
  • ancora una volta ... e ancora se per caso
• Conclusione
  • successo o no
  • cosa chiaramente sbagliato, dovendo cambiare
  • ciò che fallisce, deve essere corretto
  • scopi

Qualche trucco da tenere a mente:

1. Il tuo lavoro non è inteso per essere letto da tecnici, quindi cerca di rimanere semplice, ma
2. Il tuo lavoro deve essere letto da tecnici, per la convalida o l'applicazione dei tuoi consigli, quindi non dimenticare nulla !! Il tuo lavoro deve essere preciso, completo e incontestabile .
3. Dato che il tuo lavoro riguarda problemi di sicurezza, qualche confusione, come l'utilizzo di John Doe: XXXXX per il nome utente coppia, la password potrebbe essere una buona pratica, devono essere menzionate all'inizio, ma potrebbe essere utile per ulteriori discussioni.

Quindi per rimanere leggeri per gli amministratori, l'introduzione e la conclusione devono essere spiegate in modo semplice, magari usando il linguaggio pittorico, e

per essere sempre alla portata di tecnici che devono aggirare il testo, essere precisi e dettagliati. Forse un semplice dump della console con alcuni commenti potrebbe essere sufficiente.

Questo può sembrare un errore, ma non lo è, e basta chiedere quale formato preferiscono. Ho eseguito tutti i tipi di recensioni e la maggior parte delle aziende ha un formato di quali informazioni piace e come gli piace. Chiedi di vedere i rapporti precedenti come modello, ti farà risparmiare un sacco di tempo.

Come faccio a riconvertire questa situazione & che cosa sto esattamente indirizzando?

I construct & architect security operations for a living. I had been addressing Application Security Reports for a decade now & quite sure about what's to be included & where to have them included. Presentation will Matter.

Ho dato una buona dose di pensiero. Guardando tutte le risposte, sento che le parti mancanti accanto alla risposta più definitiva & la conoscenza dovrebbe essere focalizzata.

Per iniziare, vorrei dire: "Per favore non confondere tra un Assessment & un controllo . Audit ha Audit Trails, una valutazione ha dettagli tecnici nitty gritty. The Original Post dice che è stato fatto un audit alle applicazioni che non poteva essere. Più tecnicamente erano valutazioni.

Ne ho raccolti diversi tra cui la metodologia seguita in CERN , ref: link . Con mio grande stupore, il più delle volte - i dettagli tecnici che sono come una valutazione della sicurezza potrebbero essere più utili allo sviluppatore & It Operations piuttosto che gli stakeholder aziendali. Quando provi a verificare un'applicazione o un insieme di applicazioni su un'interfaccia pubblica, la porti allo stakeholder dell'applicazione.

Venendo ai punti del mio esempio di rapporto sull'applicazione, ecco come appare (mi scuso per gli scarabocchi che erano assolutamente necessari ma dovevano essere tolti secondo le norme NDA):

Spieghiamo quali sono questi componenti nei puntatori chiave:

1. Il primo è Classificazione delle vulnerabilità : ad es. per XSS, potrebbe essere scritto come codice di iniezione. Per Iniezione Shell, l'Iniezione interprete è un termine più accurato. Allo stesso modo, per le Iniezioni SQL, piuttosto MS-SQLi o MySQli, la Classificazione dovrebbe essere Database Injection .
2. Il prossimo è Titolo della vulnerabilità : per l'iniezione del database, potrebbe sempre essere più accurato in un liner come UNION BASED MySQL Injection Leads to Command Level Compromise .
3. Il prossimo è Rating del rischio : a mio avviso, vorrei passare da WASC o altro, ma ho preferito il nostro circuito di valutazione personalizzato. Uno può cercare OWASP , WASC o altri se ti è stato detto di attenersi a una particolare metodologia. NIST sarebbe uno se hai a che fare principalmente con la sicurezza della rete.
4. Descrizione : dovrebbe essere il più dettagliato possibile. A volte può accadere che non venga trovato un set di classificazione a causa del fatto che la natura di Business Logic è minacciata. Per quelli, è necessario avere un grande senso di comprensione del contesto e perché lo scenario di attacco è messo come tale.
5. Impatto : ancora una volta, direi che questo è un duro indicatore nei proiettili. Questo è sano e amp; anche dal punto di vista igienico agli stakeholder aziendali.
6. Dimostrazione del concetto : penso che questo sia abbastanza auto esplicativo. Ma includi dettagli inclusi screenshot. Un altro input sarebbe che includi i parametri che sono interessati e amp; annotare anche l'endpoint nel caso in cui si tratti di un'API che è interessata insieme ai suoi parametri POST, se presenti.
7. Consigli e amp; Risanamento : Penso che anche questo sia esplicativo. Mantieni un modello generico per OWASP Top 10 , SANS 15 & WASC Top 26 ones. Per il resto, utilizza raccomandazioni scritte basate sul contesto scritte in quanto aiuta le tue operazioni IT.
8. Risolvi la responsabilità : chi sta risolvendo. Nel tuo caso, sei tu!

Spero che questo ti sia d'aiuto.

Se l'obiettivo di un rapporto di verifica della sicurezza è convincere la direzione a rimediare alle debolezze di sicurezza rilevate, allora descrivere l'impatto di non risolvere i problemi. Come revisore IT, incontro spesso resistenza dai membri non tecnici della direzione riguardo alle raccomandazioni che faccio come:

1. È troppo costoso da implementare
2. Non c'è abbastanza ritorno all'azienda per giustificare lo sforzo
3. Nessun vantaggio economico tangibile

Vuoi descrivere nel tuo rapporto quale sia l'impatto di non risolvere le vulnerabilità della sicurezza nei termini aziendali come:

1. Il costo di affari persi sarà di circa $ X dollari se una vulnerabilità di sicurezza viene sfruttata da un avversario.
2. X ore di downtime (RTO) risulteranno durante il quale non saremo in grado di assistere i nostri clienti a seguito di una minaccia che sfrutta una vulnerabilità alla disponibilità dei nostri sistemi.

In sintesi, il tuo obiettivo è ottenere il buy-in aziendale in modo che la sicurezza venga trasformata da una funzione IT a una funzione con conseguenze negative economiche e non economiche (ad esempio: reputazione danneggiata) se le vulnerabilità non vengono prese in considerazione.