Spiegazione della sicurezza fin dalla progettazione (SbD)
La sicurezza fin dalla progettazione è un approccio allo sviluppo del software che mira a stabilire la sicurezza come un pilastro, non un ripensamento, ovvero l'integrazione dei controlli di sicurezza nei prodotti software fin dalla fase di progettazione. SbD crea software sicuro che le aziende possono implementare immediatamente senza incorrere in costi aggiuntivi per le funzionalità di sicurezza.
Per comprendere meglio l'SbD, immagina uno scenario in cui devi costruire un magazzino sicuro per le tue merci multimilionarie. Potresti costruire un edificio con legno facile da violare, fortificarlo con caratteristiche di sicurezza, ad esempio sensori e telecamere a circuito chiuso, e persino assumere una società di sicurezza. Oppure potresti costruire il tuo magazzino in mattoni, utilizzare porte di metallo pesante e installare le stesse funzionalità di sicurezza.
Il magazzino di mattoni sarà, ovviamente, più sicuro, poiché indipendentemente dalle caratteristiche di sicurezza, è meglio avere un sistema inviolabile, e questo è l'approccio che esemplifica SbD.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet
Perché la sicurezza fin dalla progettazione?
Le app rivolte al Web erano vulnerabili per progettazione (VbD) perché i fornitori di software distribuivano il software prima di integrarvi la sicurezza. Ciò significava che le aziende dovevano acquistare funzionalità di sicurezza come componenti aggiuntivi e correggere le principali vulnerabilità man mano che si presentavano: un approccio redditizio per i fornitori, poiché più funzionalità equivalevano a più soldi.
Ma in quanto obiettivi primari degli attacchi alla supply chain, le aziende sono quelle che affrontano le conseguenze legali, finanziarie e reputazionali quando si verificano violazioni (e spesso lo fanno).
SbD affronta questo problema "penalizzare l'utente aziendale, risparmiare il fornitore" promuovendo una cultura dello sviluppo del software in cui sia l'utente che il fornitore sono ritenuti responsabili delle loro azioni o inazioni. Ciò migliora sia il software dei fornitori che quello degli utenti Postura di sicurezza riducendo la loro superficie di attacco e facilitando altri risultati chiave.
Patch più semplici ed economiche
L'applicazione rapida di correzioni di sicurezza mentre il software è in uso (per prevenire violazioni dei dati e danni finanziari e reputazionali associati) può essere una spina nel fianco, costosa e piena di errori.
I prodotti progettati per essere sicuri fin dall'inizio richiedono meno patch critiche, rendendo il processo molto più economico e semplice.
Prodotti convenienti
L'unico modo per proteggere i sistemi vulnerabili fin dalla progettazione è quello di aggiungere più componenti aggiuntivi. Tuttavia, gli aggressori possono ancora sfruttare il Porte posteriori creato dal difetto VbD per infiltrarsi nei sistemi.
La protezione dei sistemi per impostazione predefinita è più conveniente rispetto a un rischio maggiore di violazioni dei dati e dei relativi costi, cause legali e multe.
Conformità normativa
Poiché il software sviluppato utilizzando l'approccio SbD ha la sicurezza al centro, è più probabile che sia conforme per impostazione predefinita. Ciò facilita il processo di controllo di diversi componenti software per garantire conformità con varie normative.
Come funziona la sicurezza fin dalla progettazione?
L'approccio SbD ha quattro fasi chiave, che esploriamo di seguito.
Fase 1: Definire i requisiti di sicurezza
SbD inizia con uno studio chiaro del software da sviluppare, delle sue potenziali vulnerabilità e dei corrispondenti requisiti di sicurezza. Per un servizio di database, i requisiti di sicurezza includono la crittografia, il controllo degli accessi in base al ruolo e altre tecniche di autorizzazione.
Fase 2: Condurre valutazioni dei rischi e modellazione delle minacce
Questa fase comporta l'utilizzo di un scanner di vulnerabilità per mappare i potenziali percorsi di attacco del software.
Ad esempio, un provider di servizi di database è esposto a possibili percorsi di attacco, ad esempio indirizzi IP pubblici o account con privilegi, a causa di informazioni personali sensibili e informazioni sanitarie protette archiviate nei database.
Free Cloud Risk Assessment
Connect with a Wiz expert for a personal walkthrough of the critical risks in each layer of your environment.
Request Assessment
Fase 3: Scrivere codice e creare misure di sicurezza contemporaneamente
In questa fase, il team di ingegneri abbandona le procedure di codifica convenzionali per sviluppare software con Misure di sicurezza. Per il provider di database, ciò potrebbe includere la scrittura di codice che:
Impedisce l'apertura al pubblico dei database per impostazione predefinita
Convalida automaticamente l'input dell'utente senza che gli utenti aziendali debbano acquistare componenti aggiuntivi
Richiede più meccanismi di autenticazione prima di concedere qualsiasi forma di accesso
Limita i punti di accesso per gli account con privilegi
Fase 4: Monitoraggio continuo e applicazione di patch
Infine, il software viene testato e, se risulta sicuro per progettazione, spedito. Man mano che gli utenti implementano il software, il fornitore monitora, verifica e invia continuamente gli aggiornamenti SbD in base alle nuove minacce e Vulnerabilità emergere.
Principi di sicurezza fin dalla progettazione
La Cybersecurity and Infrastructure Security Agency (CISA) incoraggia i produttori di software ad adottare tre principi fondamentali durante lo sviluppo di un prodotto.
Responsabilità condivisa
Sia il venditore che il cliente dovrebbe condividere l'onere della sicurezza. I produttori di software sono tenuti a creare prodotti sicuri e ad applicare regolarmente patch al proprio software man mano che il panorama delle minacce si evolve. I clienti, nel frattempo, sono tenuti a configurare i loro prodotti utilizzando questo software in modo sicuro e a mantenere i loro dati al sicuro.
Trasparenza radicale
I produttori di software dovrebbero condividere le informazioni su ciò che rende i loro prodotti sicuri fin dalla progettazione. Sono responsabili nei confronti dei loro clienti per gli avvisi accurati sulle vulnerabilità, i record CVE (Common Vulnerability and Exposure) associati e i meccanismi di autenticazione, per citare alcune delle cose che ci si aspetta da un prodotto SbD.
Struttura organizzativa
SbD richiede l'impegno a livello di C-suite e la comunicazione tra tutte le parti interessate, la collaborazione è fondamentale tra fornitori e clienti, nonché tra sviluppatori e team di sicurezza. Ciò faciliterà l'implementazione di controlli di sicurezza quasi impenetrabili e consentirà una pianificazione del budget e un'allocazione delle risorse basate su insight.
Sfide dell'implementazione della sicurezza fin dalla progettazione
Discutiamo le tre principali sfide dell'adozione di SbD.
| Challenge | Description |
|---|---|
| Short-term costs vs. long-term profits | The cost of restructuring legacy software and switching programming languages to embed security—rather than bolt it on—is discouraging for most vendors. Even in modern systems, embedding security is a complex and costly process. Still, in the long run, fewer and less complicated patches, fewer attacks, etc. will mean the initial cost pays for itself. |
| Marketability | The motivation—for cloud vendors—to implement SbD is low, as there are no direct monetary returns for them. It is difficult to market restructured SbD products on the “now secure-by-design” premise, as this will leave enterprise users with the presupposition that the products weren’t properly built and secured earlier on. It is easier to sell legacy software as is, alongside aftersales/add-on security products like firewalls and antivirus. |
| Third-party vendor liability | An important implication of SbD is that software vendors are liable for supply chain vulnerabilities. For example, a single security flaw can affect several enterprise customers who would want the vendor to take the blame, i.e., face the financial and reputational consequences. Getting all parties onboard with the shared responsibility model is thus critical, as discussed above. This makes it clear that security is in fact a shared burden between the vendor and the customer. |
Best practice per la sicurezza fin dalla progettazione
CISA offre alcune tattiche SbD selezionate dal Framework di sviluppo software sicuro (SSDF) del National Institute of Standards and Technology (NIST): SP 800-218. Le organizzazioni dovrebbero integrare queste pratiche in ogni fase del ciclo di vita dello sviluppo del software (SDLC).
Utilizza componenti software sicuri
Distribuisci componenti software ben protetti, tra cui librerie, framework e middleware, solo da provider verificati. Inoltre, evita il software con vulnerabilità note, inclusi errori di crittografia e autenticazione, controlli di accesso interrotti, vulnerabilità di iniezione e problemi di registrazione.
Una piattaforma di protezione delle applicazioni nativa per il cloud (CNAPP) tornerà utile per rilevare componenti non protetti.
Adotta buone pratiche di progettazione
Le organizzazioni possono ridurre i rischi per i loro sistemi software implementando la difesa in profondità, ad esempio, avere più di un livello di misure di sicurezza. Nel frattempo, il sandboxing isola il software e i componenti di sicurezza per evitare che la compromissione di un singolo componente influisca sull'intero sistema.
I fornitori dovrebbero anche progettare software che rendano facile l'applicazione di patch; Ridurre al minimo i tempi di inattività derivanti dagli aggiornamenti software incoraggerà gli utenti aziendali ad applicare le patch più velocemente.
Utilizza linguaggi di programmazione sicuri per la memoria
Il NIST incoraggia Gli sviluppatori implementare mitigazioni comuni mirate alla memoria, ad esempio l'integrità del flusso di controllo (CFI) e la randomizzazione del layout dello spazio degli indirizzi (ASLR). Ma oltre a questo, il NIST osserva anche che dovrebbero adottare linguaggi moderni sicuri per la memoria, ad esempio Rust, Go, Java, C#, Swift e Python, evitando le loro controparti non sicure per la memoria, C e C++.
Ciò contribuirà a mitigare le vulnerabilità di sicurezza della memoria come SlammerWorm, Ghost Engine e Stagefright.
Adotta query parametrizzate e framework di modelli Web
Le query con parametri sono query SQL con parametri che separano l'input dell'utente dalla query stessa. I framework dei modelli Web contengono informazioni sensibili al contesto che impediscono automaticamente l'input sospetto dell'utente. Insieme, questi meccanismi aiutano a prevenire l'SQL injection e attacchi di cross-site scripting (XSS).
Fornire SBOM
I fornitori di software devono fornire agli utenti un elenco dei componenti, delle librerie e degli strumenti software proprietari e di terze parti che hanno utilizzato per sviluppare il software. Questo elenco, che può essere generato tramite un scanner SBOM senza agente: consente una facile risoluzione delle vulnerabilità.
Elimina le password predefinite
I fornitori devono evitare di implementare prodotti con password predefinite. Invece, dovrebbero adottare l'autenticazione a più fattori e richiedere agli utenti di impostare password complesse immediatamente dopo aver configurato il software.
Fornire profili di autorizzazione software
Questi profili designano ruoli utente e casi d'uso per limitare l'accesso non necessario ai dati utente e agli account privilegiati. I produttori di software devono fornire profili dettagliati di autorizzazione del software, implementare il principio del privilegio minimo ed emettere avvisi contro la deviazione dai limiti designati.
Conclusione
Security by design implementa in modo proattivo i protocolli di sicurezza sin dalla fase di progettazione del software. Sostenuto dalla CISA e da altri attori chiave del settore, SbD incoraggia a condurre valutazioni delle vulnerabilità, analisi del percorso di attacco e analisi dei componenti software per determinare e risolvere potenziali vulnerabilità del software prima che le app vengano distribuite e in ogni fase dell'SDLC.
L'obiettivo è quello di eliminare i costosi strumenti di sicurezza e le complicate modifiche al codice post-vendita che non proteggono adeguatamente i sistemi dagli attacchi perché sono già vulnerabili per progettazione.
SbD è un approccio più economico, veloce e affidabile per la creazione e la protezione delle app. Questo è il motivo per cui Wiz è uno dei principali sostenitori Codice di sicurezza per la spedizione. La sua soluzione:
Facilita la visibilità del software end-to-end
Fornisce SBOM aggiornati
Consente Analisi del percorso di attacco
Iscriviti per un Demo personalizzata per vedere come Wiz può aiutarti a iniziare il tuo percorso verso prodotti sicuri fin dalla progettazione.
See for yourself...
Learn what makes Wiz the platform to enable your cloud security operation
