E 'OK fare un test di sicurezza in parallelo con un test di controllo qualità?

Question

E 'OK fare un test di sicurezza in parallelo con un test di controllo qualità?

#1 da (2 voti)
#2 da (1 voti)

4

Questa potrebbe non essere una domanda molto tecnica di per sé, quindi non esitare a spostarla nel rispettivo forum / stack. Tuttavia, mi piacerebbe davvero apprezzare chiunque abbia esperienza o esperienza di una situazione simile e le soluzioni adottate.

Quindi lavoro come ingegnere della sicurezza con una piccola start-up. Ora, nella mia precedente organizzazione, una tipica azienda, avevo il mio capo che si occupava di convincere ecc. Con la gestione di alto livello e ottenere le cose necessarie per far funzionare senza problemi. Tuttavia, nel mio attuale ruolo, essendo una start-up, sono l'unico ingegnere responsabile della sicurezza delle informazioni di tutta l'azienda. Ora come travolgente, come diventa, sta diventando una straordinaria curva di apprendimento per me di giorno in giorno. Raccolgo diversi aspetti della sicurezza come piccoli passi, uno alla volta, iniziando con le risorse più importanti che devono essere protette e che si trovano al massimo rischio / nella zona delle minacce. Sto cercando di dare la priorità a cose e vedere dove è necessario un pen-test e dove è necessario un VA.

Ci sono molte sfide che sto affrontando di cui vorrei discutere nel seguito: Ora, data la situazione di cui sopra, una delle principali sfide che sto affrontando ora è che continuo a spingere dai lead della tecnologia per assicurarmi che ogni nuova funzionalità che dovrei testare debba prima verificare il QA prima Posso prenderlo per un VA / PT / test di sicurezza. Il motivo è che ci sono stati un paio di casi in cui, a causa di un QA incompleto sulla funzione, i miei casi di test di sicurezza hanno fornito falsi negativi, in quanto la funzionalità stessa è stata interrotta in modo contrario alle aspettative. Ora questo è qualcosa che i responsabili della tecnologia non trovano abbastanza convincente da consentire i test di sicurezza solo dopo l'approvazione del QA. Hanno bisogno di più esempi / casi di test per supportare questo Loro argomento è,

security test can be done in parallel to QA and that I need not really wait on the QA as it is simply pushing the release date un-necessarily.

Ho ragione nel mio argomento? Se sì, cos'altro potrei fare per convincerli sui miei punti. Se non ho ragione, per favore aiutami a capire perché la mia argomentazione non è corretta.

vulnerability appsec penetration-test

posta qre0ct 18.05.2016 - 12:24

fonte

2 risposte

Leggi altre domande sui tag vulnerability appsec penetration-test

Quali cose può vedere l'altra persona sul mio telefono quando lo accoppio usando bluetooth? Come rilevare l'algoritmo di crittografia dei file zip

score 2 · Answer 1

Al momento lavoro come sviluppatore, con una certa responsabilità per la pianificazione dello sprint ecc. quindi la mia risposta si basa principalmente su un approccio "come dovrebbe essere valutato l'esame". Qui parlerò di agile, ma vale lo stesso principio.

Non riesco a vedere niente di sbagliato in principio con i test in parallelo al QA, supponendo che sia chiaro che qualsiasi cosa che fallisca nel QA richiederà un nuovo test.

Supponendo che il business assegni le stime al lavoro (si pensi allo sviluppo agile), il tempo di sviluppo, il tempo di QA e il tempo di test di sicurezza dovrebbero essere sommati per fornire il tempo totale stimato per il completamento di un'attività. Senza sprecare troppa profondità nello sviluppo agile, lo sprint è composto da una serie di attività (carte), che la stima totale si adatta alla lunghezza dello sprint.

Una volta che una carta è completa, passa al QA e ai test di sicurezza. Se uno di questi due passi fallisce, tornerà indietro per la rielaborazione ecc.

Ora, in un mondo ideale, tutte le carte passeranno QA e test di sicurezza. Ciò che effettivamente accade è che alcune carte passano e alcune falliscono (o al QA o test di sicurezza). Supponendo che il business non giri e accetti solo il rischio, ci sarà qualche rielaborazione e la scheda dovrebbe tornare al QA e alla sicurezza.

Eseguendo i test in parallelo, dovresti risparmiare un po 'di tempo nello sprint. Quando le carte falliscono nel QA, l'azienda deve capire / accettare che la carta richieda un nuovo test dal QA e dalla sicurezza. Si può finire per spendere il tempo pieno di ri-test stimati, o meno / più tempo. Quella volta poi influisce sullo sprint e sulla data di rilascio.

Per poter discutere su entrambi i lati, dovresti considerare la quantità di rilavorazioni che ottieni normalmente. Se la maggior parte delle tue carte fallisce il QA, allora ha senso che tu esegua i test di sicurezza una volta che il QA è stato firmato. Se la maggior parte delle tue carte passa al QA, allora ha senso eseguire i test in parallelo.

Ho basato questa risposta agile, dove tutto dovrebbe avere una stima ecc. Lo stesso principio si applica a prescindere, ogni fase di sviluppo avrà un costo temporale associato ad essa, anche se non è scritta da nessuna parte.

Il mio suggerimento sarebbe quello di vedere quante carte di solito falliscono il QA e capire se è vantaggioso eseguire i test in parallelo o meno.

score 1 · Answer 2

"due to an incomplete QA on the feature, my security test cases gave false negatives"

Non capisco davvero cosa stai cercando di dire qui. Il test non modifica la funzionalità, la sicurezza, la capacità o le prestazioni del sistema. Tuttavia, l'intero punto di test è identificare dove il sistema non fornisce alcuno di questi aspetti (insieme ad altri attributi come l'usabilità) che dovrebbe quindi richiedere modifiche al codice / architettura / configurazione. Le modifiche dovrebbero tornare indietro nel ciclo di test.

Gli unici argomenti veramente giustificabili per l'ordine in cui ogni aspetto è valutato sono i costi e il tempo. I test precedenti potrebbero ridurre i costi più avanti nel processo se falliscono, ma dovranno essere ripetuti quando il codice verrà rielaborato. Di conseguenza, i test che probabilmente falliranno dovrebbero essere presto bilanciati in modo da favorire il test che è meno costoso fare prima nel ciclo contro la disponibilità di risorse per fare il test.

Chiunque sia l'ultimo nel processo prima che una funzionalità venga pubblicata è sempre impopolare. Poterti lanciare deliberatamente in questo ruolo potrebbe essere inteso come un senso gonfiato di importanza personale.