L'esperienza di T&E consiste nel fornire consapevolezza tempestiva dei punti di forza e di debolezza del sistema durante il processo di sviluppo durante il ciclo di vita del sistema.

Consapevolezza necessaria per gestire il rischio

Dati empirici per la validazione di modelli e simulazioni

Test delle prestazioni tecniche e della maturità del sistema

Determinazione dell'efficienza operativa e della manutenzione, dell'adattabilità e della sopravvivenza

Identificare, gestire e ridurre i rischi

Consapevolezza necessaria per gestire il rischio

Dati empirici per la validazione di modelli e simulazioni

Test delle prestazioni tecniche e della maturità del sistema

Determinazione dell'efficacia operativa, dell'adattabilità e della sopravvivenza.

Collaborare con le organizzazioni sponsor per stabilire o valutare strategie T&E per supportare l'acquisizione/sviluppo del programma;

Fornire metodi T&E in grado di gestire in modo approfondito i rischi;

Monitorare i processi T&E e le modifiche che potrebbero essere necessarie;

Valutare e fornire raccomandazioni sull'idoneità dei piani di test e delle procedure per i test di sviluppo o i test operativi;

Si prevede inoltre di comprendere la logica alla base delle procedure di acquisizione/sviluppo per stabilire ed eseguire strategie di T&E;

Aspettarsi di comprendere le attività specifiche dei test T&E, come i test di interoperabilità;

Questo gruppo è spesso chiamato team del prodotto integrato T&E ed è composto da esperti T&E, rappresentanti degli utenti dei clienti e altre parti interessate;

La strategia T&E è un documento vivo e il team è responsabile del suo aggiornamento quando necessario;

Il team deve garantire che il processo T&E includa strategie di acquisizione e che il sistema soddisfi i requisiti operativi in ​​base alle capacità utilizzate;

Ad esempio, l'analisi del registro di routing è utile per identificare incidenti di sicurezza, violazioni delle policy, comportamenti fraudolenti e problemi operativi.

Condurre audit e indagini forensi;

Supportare le indagini interne;

Stabilire una linea di base;

Identificare le tendenze operative e identificare i problemi a lungo termine;

Necessità di bilanciare le risorse limitate di gestione dei log con i dati di log generati continuamente

Produzione e archiviazione dei registri

Necessità di proteggere l'integrità, la riservatezza e la disponibilità dei registri

Garantire la sicurezza, gli amministratori di sistema e di rete analizzano i dati di registro regolarmente ed in modo efficace.

Definire i requisiti e gli obiettivi di registrazione

I requisiti e le raccomandazioni di registrazione dovrebbero essere generati insieme alle risorse e alle tecniche di analisi dettagliate necessarie per implementare e mantenere la registrazione

Protezione dei tronchi originali

Ottimizzare registri e requisiti, in base alla riduzione del rischio organizzativo percepito e alle risorse e al tempo previsto necessari per eseguire la gestione dei registri.

Stabilire responsabilità e ruoli di gestione dei log

Un'architettura di gestione dei log comprende l'hardware, il software, la rete e i supporti utilizzati per generare, trasmettere, archiviare, analizzare ed elaborare i log.

La progettazione di un framework di gestione dei log dovrebbe considerare le esigenze attuali e future del framework di gestione nonché le fonti di log indipendenti all'interno dell'organizzazione.

Gli amministratori del sistema dovrebbero ricevere un sostegno adeguato;

Comprendere la diffusione di informazioni, l'offerta di formazione, la fornitura di un punto di contatto per domande e risposte, Fornire indicazioni tecniche specifiche, strumenti e documentazione corrispondenti, ecc.

Responsabilità dell'amministratore del registro

Processo di gestione del registro

Origine registro

sfida

pratiche chiave

Metodi di monitoraggio Web progettati per acquisire o analizzare ogni transazione di ogni utente sul Web o sull'app

Conosciuto anche come misurazione dell'utente reale, metrica dell'utente reale o monitoraggio dell'esperienza dell'utente finale (EUM) monitoraggio dell'esperienza dell'utente finale

monitoraggio passivo Metodo di monitoraggio passivo

Modalità di monitoraggio

monitoraggio proattivo Approccio di monitoraggio proattivo o pre-reattivo

Non tiene traccia delle sessioni utente effettive

Completamente controllabile dal cliente pieno controllo sul cliente

Software di gestione delle operazioni di Microsoft System Center

Aumentare il valore

Modelli di programmazione inappropriati come controlli mancanti che interessano i dati utente, SQL injection (convalida dell'input)

Mancata corrispondenza dell'infrastruttura di sicurezza: controllo eccessivo degli accessi o configurazione di crittografia debole;

Errori funzionali nell'infrastruttura di sicurezza: le stesse strutture di controllo degli accessi non limitano l'accesso al sistema;

Errori logici nel processo di implementazione: ad esempio, l'utente effettua un ordine senza pagare

Primi 25

White box (test strutturale/test a scatola aperta) vs. test black box (test funzionale/test a scatola chiusa)

Test dinamici VS. test statici Test dinamici e test statici

Manuale vs. Automazione Test manuali e test automatizzati

superficie di attacco

Tipi di app

qualità

Tecnologia di supporto

Prestazioni e utilizzo delle risorse

Revisione della sicurezza dell'architettura

Modellazione delle minacce -

Analisi statica del codice sorgente (SAST) e revisione manuale del codice (analisi statica del codice e revisione manuale del codice)

Analisi statica del codice binario e revisione binaria manuale (analisi statica del codice binario e revisione binaria manuale)

Test di penetrazione manuali o automatizzati

Scansione automatizzata delle vulnerabilità

Strumenti per il test Fuzz Strumenti per il test Fuzz

Si consiglia di utilizzare la tecnologia di test di sicurezza passiva per monitorare il comportamento del sistema e analizzare i registri di sistema

Durante la manutenzione del software, il test delle patch è molto importante

Il test del software ha i suoi limiti ed è impossibile completare il test al 100%.

I piani di test e i casi di test dovrebbero essere sviluppati il ​​più presto possibile nella fase di sviluppo del software

I test sulla sicurezza del software generalmente iniziano con test a livello di unità e terminano con test a livello di sistema.

Test strutturati (test "scatola bianca") Prova di unboxing

I casi di test si basano sulla conoscenza acquisita dal codice sorgente, dalle specifiche di progettazione dettagliate e da altri documenti di sviluppo;

Copertura della dichiarazione Copertura della dichiarazione

Copertura della decisione (ramo) Copertura della decisione

Copertura delle condizioni copertura delle condizioni,

Copertura multicondizione Copertura multicondizione

Copertura del circuito Copertura del circuito

Copertura del percorso Copertura del percorso

Copertura del flusso di dati Copertura del flusso di dati

I casi di test sono definiti in base a ciò che il prodotto software dovrebbe fare specificamente;

Le principali sfide per i casi di test sono l'uso previsto e la funzionalità del programma, nonché le interfacce interne ed esterne del programma;

Il test funzionale dovrebbe essere applicato a qualsiasi livello di test del software, dal test unitario al test a livello di sistema

Caso normale Caso di uso comune

Uscita Forzatura dei requisiti di uscita,

Robustezza Robustezza

Combinazioni di ingressi Combinazioni di ingressi

debolezza debolezza

Fornisce un'elevata copertura strutturale

Generare dati casuali da una distribuzione definita in base all'ambiente operativo (uso previsto, uso pericoloso o uso dannoso del prodotto software);

Generare grandi quantità di dati di test e utilizzarli per coprire aree specifiche o aree di interesse, fornendo una maggiore probabilità di identificare condizioni operative singole ed estremamente rare che non erano state previste da progettisti e tester;

motivo

Scopo

Test a livello di unità (modulo o componente). prova unitaria

Test del livello di integrazione Test di integrazione (test delle interfacce tra i moduli)

Test a livello di sistema Prova del sistema

Test d'ingresso

Il test del sistema presenterà il comportamento del prodotto software in un ambiente specifico;

Le procedure di test, i dati dei test e i risultati dei test dovrebbero essere documentati in modo tale da consentire decisioni di superamento/fallimento;

I prodotti software aziendali sono complessi e il test dei prodotti software deve mantenere coerenza, completezza ed efficacia;

Le attività di manutenzione del software sono diverse dalla manutenzione dell'hardware. L'hardware prevede misure di manutenzione preventiva, ma il software no;

Richiede una verifica valida delle modifiche

Revisione del piano di validazione del softwareRevisione del piano di validazione del software,

Verifica eccezione valutazione anomalia,

Identificazione dei problemi e monitoraggio della risoluzione Identificazione dei problemi e monitoraggio della risoluzione,

Valutazione della modifica proposta Richiedi una valutazione della modifica

Iterazione dell'attività iterazione dell'attività,

Aggiornamento della documentazione Aggiornamento della documentazione

Casi di test dal punto di vista dei normali utenti che utilizzano il sistema

Casi d'uso dal punto di vista di qualcuno con intenti dannosi nei confronti del sistema.

Assicurati che l'applicazione funzioni come previsto e fallisca se vengono rilevati errori durante i test futuri

Assicurati che la tua app gestisca in modo appropriato input non validi o comportamenti imprevisti degli utenti.

Controlla principalmente se i diversi componenti dell'applicazione o dello sviluppo del sistema sono sincronizzati tra loro;

A livello tecnico, il test dell'interfaccia viene utilizzato principalmente per determinare diverse funzioni come Se i dati vengono trasferiti come previsto tra i diversi elementi del sistema.

Utilizzato per garantire la qualità del software

Discovery, raccolta di informazioni sul target (discovery)

Enumerare, eseguire la scansione delle porte e i metodi di identificazione delle risorse

Esplorazione delle vulnerabilità, identificazione delle vulnerabilità nei sistemi e nelle risorse identificati

exploit, tentativo di sfruttare una vulnerabilità per ottenere un accesso non autorizzato

Riferire alla direzione e inviare rapporti e raccomandazioni sulla sicurezza alla direzione

Test della scatola nera, comprensione zero, test del team di penetrazione senza comprendere gli obiettivi del test

Test con scatola grigia, test basato sulla conoscenza di alcune informazioni relative all'obiettivo del test

Test white box, test basati sulla comprensione dell'essenza del target

0 conoscenza

conoscenza parziale

tutta la conoscenza

Comporre una serie di numeri di telefono per trovare i modem disponibili

Alcune organizzazioni utilizzano ancora i modem per il backup delle comunicazioni

Il war dialing è una forma di intrusione nella rete di un'organizzazione progettata per aggirare i firewall e i sistemi di rilevamento delle intrusioni (IDS)

Gli attacchi War Dial implicano tentativi di ottenere l'accesso alle risorse informatiche e di rete interne di un'organizzazione tramite accesso dial-in, Ciò porta comodità agli hacker.

test di autoverifica

Ci sono vulnerabilità nel livello del kernel

Contromisura: garantire che le patch di sicurezza del sistema operativo vengano implementate tempestivamente dopo adeguati test nell'ambiente per mantenere la finestra di vulnerabilità quanto più piccola possibile.

Contromisure: buone pratiche di programmazione ed educazione allo sviluppo, codice sorgente per scanner automatici, Libreria di programmazione migliorata per utilizzare un linguaggio di digitazione avanzato per impedire gli overflow del buffer

Gli hacker reindirizzano i collegamenti simbolici per ottenere l'accesso non autorizzato.

Contromisura: quando si scrivono programmi (soprattutto script), non c'è modo di evitare il percorso completo del file

Un descrittore di file è un numero utilizzato da molti sistemi operativi per rappresentare i file aperti in un processo. Alcuni numeri di descrittore di file sono universali e hanno lo stesso significato per tutti i programmi.

Se un programma utilizza descrittori di file in modo non sicuro, potrebbe consentire a un utente malintenzionato di sfruttare i privilegi del programma per fornire input inaspettati al programma o far sì che l'output vada in una posizione inaspettata.

Contromisure: buone pratiche di programmazione e formazione sullo sviluppo, scanner automatizzati del codice sorgente e test di sicurezza delle applicazioni sono tutti modi per ridurre questo tipo di vulnerabilità.

Mancata eliminazione dei fattori di vulnerabilità ambientale prima dell’esecuzione delle procedure

Può consentire a un utente malintenzionato di leggere o scrivere dati imprevisti o eseguire comandi non autorizzati

Contromisure: buone pratiche di programmazione e formazione sullo sviluppo, scanner automatizzati del codice sorgente e test di sicurezza delle applicazioni

Quando un processo genitore crea un processo figlio, è necessario prestare attenzione alle condizioni di competizione e all'autorizzazione minima.

Autorizzazioni di file o directory non corrette

Contromisura: controllo dell'integrità dei file, controllare anche le autorizzazioni dei file e delle directory previsti

Consapevolezza utilizzata per definire la sicurezza delle informazioni, le vulnerabilità e i pericoli attuali per supportare le decisioni organizzative sui rischi per la sicurezza delle informazioni;

Qualsiasi impegno e processo utilizzato per supportare il monitoraggio della sicurezza delle informazioni all'interno dell'organizzazione deve iniziare con una sofisticata strategia ISCM definita dalla leadership senior;

Si basa su una chiara comprensione della tolleranza al rischio organizzativo e aiuta le aziende a stabilire le priorità e a gestire la coerenza del rischio all’interno dell’organizzazione;

Includere parametri per fornire un significato reale del livello di sicurezza a tutti i livelli organizzativi;

Garantire la continua efficacia di tutti i controlli di sicurezza;

Verificare la conformità ai requisiti di sicurezza delle informazioni guidati dalla missione organizzativa/funzioni aziendali, dalle leggi e dai regolamenti nazionali, dalle linee guida, dagli standard di guida;

Tutte le risorse IT dell'organizzazione vengono informate e viene assistita la visibilità sulla sicurezza delle risorse;

Garantire la conoscenza e il controllo dei cambiamenti nei sistemi organizzativi e nell'ambiente;

Mantenere la consapevolezza delle minacce e delle vulnerabilità.

Monitoraggio continuo della sicurezza dell'informazione (ISCM) dei sistemi e delle organizzazioni informatiche federali

I programmi ISCM sono istituiti per raccogliere dati sulla base di indicatori di misurazione preimpostati, rendendo più semplice sfruttare i cambiamenti delle informazioni in parte attraverso i controlli di sicurezza che sono stati implementati.

Il monitoraggio dei rischi a livello di organizzazione non può essere raggiunto in modo efficace facendo affidamento su processi manuali separati o esclusivamente su processi automatizzati:

Le misurazioni includono tutte le informazioni relative alla sicurezza derivanti dalla valutazione e dal monitoraggio prodotti da strumenti automatizzati e da procedure manuali, organizzate in informazioni significative per supportare i requisiti decisionali e di reporting.

Le metriche dovrebbero essere guidate da obiettivi specifici per mantenere o migliorare il livello di sicurezza.

Le metriche sviluppano dati a livello di sistema che danno un senso alla missione/contesto aziendale o alla gestione del rischio organizzativo;

Metriche di misurazione delle informazioni rilevanti per la sicurezza ottenute da tempi diversi e con diversi livelli di latenza.

Volatilità del controllo di sicurezzaVolatilità del controllo di sicurezza

Categorie di sistema/Livelli di impatto Categorie di sistema/Livelli di impatto

Controlli di sicurezza o oggetti di valutazione specifici che forniscono funzioni criticheControlli di sicurezza o oggetti di valutazione specifici che forniscono funzioni critiche

Controlli di sicurezza con punti deboli identificati Controlli di sicurezza con punti deboli identificati

Tolleranza al rischio organizzativo Tolleranza al rischio organizzativo,

Informazioni sulle minacce Informazioni sulle minacce

Informazioni sulla vulnerabilità

Risultati della valutazione del rischio Risultati della valutazione del rischio

Requisiti di segnalazioneRequisiti di notifica

Ad esempio, il Federal Information Security Management Act degli Stati Uniti (FISMA Federal Information Security Management Act) richiede alle agenzie federali di condurre autocontrolli e audit indipendenti di terze parti del sistema di sicurezza delle informazioni dell'organizzazione almeno una volta all'anno;

I professionisti della sicurezza informatica devono comprendere i requisiti delineati negli standard legali per fornire protezione, ma raramente si ottiene una protezione completa o una gestione del rischio dei sistemi informativi;

I professionisti della sicurezza delle informazioni devono garantire la portata e la personalizzazione adeguate per ottenere il numero appropriato di controlli al livello corretto per il sistema target

Per concentrarsi sulle competenze chiave, ridurre le spese e implementare più rapidamente nuove funzioni applicative, le organizzazioni Outsourcing continuo di sistemi, processi aziendali ed elaborazione dati a fornitori di servizi;

L'organizzazione aggiorna frequentemente il processo di monitoraggio e la gestione dei rischi dell'outsourcing da parte del fornitore di servizi di outsourcing;

Storicamente, molte organizzazioni si sono affidate ai report Statement on Auditing Standards (SAS) 70 per acquisire familiarità con le attività di outsourcing. Tuttavia, SAS 70 si concentra sul controllo interno sul reporting finanziario (ICOFR) piuttosto che sulla disponibilità e sicurezza del sistema.

Il report SAS70 è stato ritirato nel 2011 e sostituito dal report SOC (Service Organization Control);

Hanno familiarità con i processi di lavoro all'interno dell'organizzazione.

alta efficienza lavorativa

In grado di individuare con precisione i punti più problematici

Può rendere il lavoro di audit più flessibile e la direzione può modificare costantemente le esigenze di audit, consentendo al team di audit di adattare di conseguenza il piano di audit.

Il loro accesso ai sistemi informativi è relativamente limitato

Esiste la possibilità di un conflitto di interessi che impedisce l’obiettività.

Ha controllato molti sistemi informativi diversi e ha una ricca esperienza

Non sono consapevoli delle dinamiche e delle politiche all’interno dell’organizzazione target. rimarrà obiettivo e neutrale

costo alto

Devi ancora occuparti delle risorse aggiuntive per organizzarli e supervisionare il loro lavoro anche con una NDA.

Mancanza di comprensione del funzionamento interno dell’organizzazione.

Contrariamente al report SOC 1/SOC 2, il report SOC 1 richiede al fornitore di servizi di descrivere il proprio sistema e definire gli obiettivi di controllo e i controlli relativi al controllo interno sull'informativa finanziaria;

I report SOC1 generalmente non coprono servizi e controlli che non sono rilevanti per il reporting ICOFR degli utenti.

I report SOC1 hanno iniziato ad essere utilizzati da molti fornitori di servizi per i principali servizi di elaborazione finanziaria nel 2011;

Rapporti sul periodo di tempo riguardanti la progettazione e l'efficacia operativa Rapporti che coprono la progettazione e l'efficacia operativa in un periodo di tempo

I principi e le linee guida definiscono specificatamente sicurezza, disponibilità, riservatezza, integrità del trattamento e privacy;

Fornire oltre il controllo interno sul reporting finanziario (ICOFR);

In base alle esigenze dei fornitori di servizi e dei loro utenti, è possibile utilizzare un approccio modulare per facilitare I report SOC2/SOC3 possono coprire uno o più principi;

Se il fornitore di servizi IT non ha alcun impatto o ha un impatto indiretto sul sistema finanziario dell'utente, verrà utilizzato il report SOC2;

I report SOC3 vengono generalmente utilizzati per informare un'ampia gamma di utenti sui propri livelli di garanzia senza rivelare controlli dettagliati e risultati dei test;

1. I nuovi dipendenti devono leggere e firmare la Politica di utilizzo accettabile (AUP)

2. Confermare la conformità dei dipendenti all'AUP controllando i conti dei dipendenti.

3. Recupera l'elenco dei nuovi dipendenti dal dipartimento delle risorse umane e confrontalo con i conti dei dipendenti aperti nel sistema dal dipartimento IT per garantire l'efficacia della comunicazione tra i due dipartimenti.

4. La policy dovrebbe inoltre chiarire la data di scadenza dell'account, la policy relativa alla password e l'ambito delle informazioni a cui gli utenti possono accedere.

Problemi con l'utilizzo di account privilegiati

1. Normalmente, ogni account utente del computer ha diritti di amministratore locale e il personale di gestione e manutenzione del server ha diritti di amministratore di dominio, entrambi rischiosi.

2. L'aggiunta, la cancellazione o la modifica degli account deve essere rigorosamente controllata e documentata.

3. Implementare la gestione gerarchica delle autorizzazioni dell'account amministratore.

4. Utilizzare gli account privilegiati solo quando necessario e utilizzare account limitati per il lavoro di manutenzione quotidiana.

1. Sospendere gli account che non sono più in uso.

2. Ottenere un elenco di coloro che lasciano il lavoro a breve e lungo termine presso il Ministero delle Risorse Umane, Confronta lo stato dell'account con il sistema informatico e cancella gli account dei dipendenti disoccupati da molto tempo. E sospendere l'utilizzo dei conti per le partenze brevi.

file utente

Banca dati

Dati e-mail

Testare la situazione del backup dei dati

Analizzare vari scenari di minacce che l'organizzazione potrebbe dover affrontare

Sviluppare un piano per testare tutti i backup dei dati mission-critical in ogni scenario

Sfrutta l'automazione per ridurre al minimo il carico di lavoro dei revisori e garantire che i test vengano eseguiti regolarmente

Ridurre al minimo l'impatto del piano di test del backup dei dati sui processi aziendali in modo che possa essere eseguito regolarmente

Garantire la copertura in modo che ogni sistema venga testato, ma non necessariamente all'interno dello stesso test.

Registra i risultati in modo da sapere cosa ha funzionato e cosa necessitava di lavoro

Correggere o migliorare eventuali problemi documentati.

Test della lista di controllo Test della lista di controllo

Test walk-through strutturato Test walk-through strutturato

Test di simulazione Test di simulazione

Prova parallela Prova parallela

Test di interruzione completa Test di interruzione completa

La formazione sulla sicurezza si riferisce al processo di insegnamento di un’abilità o di un insieme di abilità che consentono alle persone di svolgere meglio funzioni specifiche.

La formazione sulla consapevolezza della sicurezza è il processo che espone le persone ai problemi di sicurezza in modo che possano riconoscerli e rispondervi meglio.

Nel contesto della sicurezza delle informazioni, è il processo di manipolazione degli individui per indurli a compiere azioni che violano i protocolli di sicurezza.

Il phishing è l’ingegneria sociale attraverso le comunicazioni digitali.

Il download di un driver è un attacco automatizzato che viene attivato semplicemente visitando un sito Web dannoso.

Gli indicatori chiave di prestazione (KPI) misurano l'efficacia con cui un'organizzazione esegue un determinato compito in un dato momento

Una misura del rischio inerente all'esecuzione di una determinata azione o insieme di azioni.

Un rapporto tecnico dovrebbe essere qualcosa di più del semplice risultato di uno strumento di scansione automatizzata o di un inventario generico.

Elementi di una buona relazione tecnica di audit

I rapporti destinati ai dirigenti senior dovrebbero essere concisi e facili da comprendere e concentrarsi sui risultati e sulle raccomandazioni principali

Il rischio è meglio descritto quantitativamente e un modo per quantificare il rischio è esprimere il rischio in termini monetari.

Metodi comuni di misurazione del rischio

I riesami della direzione dovrebbero essere effettuati periodicamente, altrimenti il ​​rischio di ispezione cambierà da proattivo a reattivo.

La frequenza delle riunioni dovrebbe inoltre essere sincronizzata con il tempo necessario per attuare le decisioni del riesame precedente.

rivedere l'input

azione gestionale