DNV GL

Analisi dell'architettura rispetto alle Best Practice della sicurezza

L’Assessment, su base volontaria, analizza l'architettura proposta per i progetti software evidenziando i gap di sicurezza rispetto alle Best Practice internazionali.

Contattaci

Vuoi saperne di più?

Richiedi informazioni

Per richiedere una quotazione

Clicca qui
Condividi:
Stampa:
Digital pipeline ecosystem software

Questo tipo di assessment è applicabile ad ogni tipologia di organizzazione e, per l’individuazione dei requisiti da soddisfare, si appoggia non solo su principi chiave - come Ridondanza e Robustezza, Semplicità, Autoprotezione, Difesa in profondità -  ma anche sulle norme di riferimento:

  • norme e standard essenziali, interpretate con l'esperienza e la comprensione del business, come ad esempio il modello dei controlli del framework Cobit© 5;
  • norme internazionali, come ad esempio la famiglia ISO 27000;
  • architettura di riferimento specifica, richiesta dal fornitore.
Tra i principali obiettivi dell’attività di verifica dell'architettura software rispetto alle Best Practice della sicurezza risultano:
  • revisione di terza parte dei possibili difetti dell’architettura nel contrastare le vulnerabilità;
  • verifica della capacità dell’architettura di supportare le esigenze di business richieste in termini di sicurezza senza appensatire le performace;
  • verifica di eventuali falle nella sicurezza dell’architettura software.
L’assessment può considerare anche la verifica a valle della effettiva realizzazione dell’architettura proposta nei progetti software.

All'inizio del programma di assessment, DNV GL analizza l'architettura in base alle Best Practice della sicurezza applicabili ai campi di Architettura software del prodotto, Architettura del sistema, Architettura di rete ed evidenzia i gap da colmare rispetto ai seguenti requisiti: 
  • sicurezza integrata nell'architettura;
  • robustezza delle soluzioni proposte;
  • componenti facenti parte dell'architettura.
I vantaggi ottenibili dalle organizzazioni sono:
  • il bilanciamento dei requisiti funzionali, di qualità e di sicurezza;
  • la comunicazione delle soluzioni individuate tra le varie parti interessate;
  • un’analisi astratta e di terza parte del sistema, culminante nella stesura di un Report con le possibili debolezze riscontrate.