SlideShare a Scribd company logo

05 sicurezza delle applicazioni per le aziende nel settore della pubblica utilità

•Download as PPS, PDF•
•
I
IBM Italia Web Team

Related slideshows

Inspiring Spaces, Celebrating 25 Years of MTA Arts for Transit
Inspiring Spaces, Celebrating 25 Years of MTA Arts for TransitInspiring Spaces, Celebrating 25 Years of MTA Arts for Transit
Inspiring Spaces, Celebrating 25 Years of MTA Arts for Transit
 
Understanding the misconception
Understanding the misconceptionUnderstanding the misconception
Understanding the misconception
 
Eroi di impresa - presentazione percorso 2016
Eroi di impresa - presentazione percorso 2016Eroi di impresa - presentazione percorso 2016
Eroi di impresa - presentazione percorso 2016
 
1 of 24
IBM Security Services Application Security per Utility Simone Riccetti IBM Security Services
Agenda Perchè la sicurezza delle applicazioni? Secure Engineering Security & SDLC
Vulnerabilità riportate dai vendor Rispetto all’H1 2009 c’è stato un incremento delle vulnerabilità del 36% . Le vulnerabilità più critiche scoperte in H1 2010 sono sfruttabili da remoto. Diverse vulnerabilità critiche sono state pubblicate prima della disponibilità di patch.
Vulnerabilità riportate dai vendor Il 55% di tutte le vulnerabilità riguarda le applicazioni web. Le vulnerabilità che permettono il Cross-Site Scripting & SQL injection sono le più diffuse. I’ 88% delle vulnerabilità di applicazioni web riguarda i plug-in e non la piattaforma base.
Le vulnerabilità più importanti per le Utilities Buffer overflows Format string vulnerabilities Race conditions Resource leaks Input/ Output validation and encoding errors SQL injection Cross-site scripting Cross-site request forgery OS injection Error handling and logging vulnerabilities Insecure error handling Insecure or inadequate logging Data storage vulnerability Insecure Components Malicious Code Unsafe native methods Unsupported methods Custom Cookies/ hidden fields Cryptography Network communication Application configuration Access control Database and file system use Access control and authentication errors Errori nel codice Errori nell’architettura e configurazione
 
La provenienza del software cambia il problema Sviluppato internamente I team di sviluppo devono spesso sviluppare “deliverables” complessi in tempi ristretti e la sicurezza è solo uno dei tanti requisiti critici Applicazioni a pacchetto Anche se configurate in base alle esigenze del cliente, sono normalmente sviluppate su standard del fornitore che può non essere in linea con i requisiti delle Utility Sviluppo in outsourcing Vengono utilizzati sviluppatori esterni per skill e abbattimento dei costi, questo consiste in un elevato dettaglio di requisiti di sicurezza da chiedere al fornitore, che non sempre viene fatto Free and open source (FOSS) Soluzioni a basso costo ma sono realizzati da gruppi di sviluppatori che possono non applicare i requisiti necessari
Secure Engineering Una serie di concetti, principi e best practice con l’obiettivo di integrare la sicurezza nel software progettato. Riguarda tutte le fasi del ciclo di sviluppo del software Definizione dei requisiti Design dell’architettura Implementazione Test Deploy Post deployment Secure Engineering non riguarda solo la fase di implementazione, ma è un approccio end-to-end
Security & Software Development Life Cycle Security education Strategia di sicurezza e metriche
 
Categorie e proprietà dei requisiti di sicurezza Es. proprietà SMART+ Specifici Misurabili Adeguati Ragionevoli Tracciabili Ref. http://www.owasp.org
 
Principi di Secure Design
Definire le priorità: Risk Analysis Analizzare software complessi può risultare un’impresa molto lunga e costosa E’ necessario focalizzare l’attenzione sul codice più a rischio (es. componente che gestisce il login degli utenti, componente accessibile via rete, codice legacy etc.) L’analisi dei rischi permette di: Definire le priorità di analisi in funzione della criticità e della funzioni di business Definire l’approccio all’analisi delle vulnerabilità “ misurare” il livello di sicurezza del software prodotto (KPI) Individuare le contromisure più efficaci
 
Improper Input Validation Improper Encoding or Escaping of Output Failure to Preserve SQL Query Structure (aka 'SQL Injection') Failure to Preserve Web Page Structure (aka XSS) Failure to Preserve OS Command Structure Clear text Transmission of Sensitive Information Cross-Site Request Forgery (CSRF) Race Condition Error Message Information Leak Failure to Constrain Operations within the Bounds of a Memory Buffer External Control of Critical State Data External Control of File Name or Path Untrusted Search Path Es. Vulnerabilità comuni (SANS/MITRE Top 25)
Failure to Control Generation of Code (aka 'Code Injection') Download of Code Without Integrity Check Improper Resource Shutdown or Release Improper Initialization Incorrect Calculation Improper Access Control (Authorization) Use of a Broken or Risky Cryptographic Algorithm Hard-Coded Password Insecure Permission Assignment for Critical Resource Use of Insufficiently Random Values Execution with Unnecessary Privileges Client-Side Enforcement of Server-Side Security Es. Vulnerabilità comuni (SANS/MITRE Top 25)
 
Code Review/Testing Tools Esistono tre approcci fondamentali per analizzare le vulnerabilità di un’applicazione: White Box : viene analizzato il codice sorgente e l’applicazione NON viene eseguita Black Box : NON si ha accesso al codice sorgente e l’applicazione viene eseguita Gray Box : si ha parzialmente accesso al codice sorgente e l’applicazione viene eseguita L’analisi delle vulnerabilità può essere fatta a mano o con tool automatici La revisione manuale è efficace per porzioni limitate di applicazione e codice. Spesso non è la strada corretta Richiede skill elevati di sicurezza Richiede molto tempo (pensate cosa significa controllare 500K LoC…)
Tipologie di Analisi I potenziali Problemi di sicurezza Dynamic Analysis Static Analysis Problemi di configurazione Problemi di Patch Level Problemi di privileges escalation Problemi di autenticazione Problemi in external 3 rd party components Null Pointer Dereference Problemi di qualità del codice Problemi di Dead Code Crypto Functions non sicure Problemi nel codice delle Back-End Application (Applicazioni Multi-Tier) SQL Injection Cross Site Scripting HTTP Response Splitting OS Commanding LDAP Injection … Application Logic Issues Runtime Analysis Runtime Analysis utilizza sia la Static che Dynamic Analysis correlandone i risultati
// ... String password = request.getParameter( "password" ); // ... " userid='" + u sername + "' " + " AND password='" + password + "'" ; // ... String username = request.getParameter ( "username" ) ; String query = "SELECT …" + username ResultSet rs = stmt.executeQuery(query); String username = request.getParameter( "username" ); String query = "SELECT * from tUsers where " +' ResultSet rs = stmt.executeQuery(query); Sistemi White-Box (es. SQL Injection) … a un Sink da un Source …
IBM Rational AppScan Ecosystem AppScan Standard Ed (desktop) AppScan Enterprise user (web client) AppScan Source Ed for Automation IBM Rational Web Based Training for AppScan AppScan Source Ed for Developer / Remediation AppScan Ent. QuickScan (web client) AppScan Tester Ed (scanning agent) (QA clients) Rational Build Forge Rational Quality Manager Rational Application Developer Rational Software Analyzer Rational ClearCase Rational ClearQuest / Issue Management CODE Build security testing into the IDE* BUILD Automate Security / Compliance testing in the Build Process QA Security / compliance testing incorporated into testing & remediation workflows SECURITY Security & Compliance Testing, oversight, control, policy, audits AppScan Source Ed for Security AppScan Enterprise / Reporting Console / Source Ed Core
Informazioni utili NERC CIP-003 R5 (Access control) CIP-004 (Personnel & Training) CIP-007-1 R5 (Account Management) NIST NISTIR 7628 1.0 DHS Software Assurance working group and “Build Security In” MITRE CVE and CWE Common Vulnerabilities and Exploits , and Common Weakness Enumeration OWASP Open Web Application Security Project Cigital BSIMM Building Security in Maturity Model IBM X-Force Worldwide cyber threat and risk analysis team
Grazie! [email_address]

More Related Content

05 sicurezza delle applicazioni per le aziende nel settore della pubblica utilità

  • 1. IBM Security Services Application Security per Utility Simone Riccetti IBM Security Services
  • 2. Agenda Perchè la sicurezza delle applicazioni? Secure Engineering Security & SDLC
  • 3. Vulnerabilità riportate dai vendor Rispetto all’H1 2009 c’è stato un incremento delle vulnerabilità del 36% . Le vulnerabilità più critiche scoperte in H1 2010 sono sfruttabili da remoto. Diverse vulnerabilità critiche sono state pubblicate prima della disponibilità di patch.
  • 4. Vulnerabilità riportate dai vendor Il 55% di tutte le vulnerabilità riguarda le applicazioni web. Le vulnerabilità che permettono il Cross-Site Scripting & SQL injection sono le più diffuse. I’ 88% delle vulnerabilità di applicazioni web riguarda i plug-in e non la piattaforma base.
  • 5. Le vulnerabilità più importanti per le Utilities Buffer overflows Format string vulnerabilities Race conditions Resource leaks Input/ Output validation and encoding errors SQL injection Cross-site scripting Cross-site request forgery OS injection Error handling and logging vulnerabilities Insecure error handling Insecure or inadequate logging Data storage vulnerability Insecure Components Malicious Code Unsafe native methods Unsupported methods Custom Cookies/ hidden fields Cryptography Network communication Application configuration Access control Database and file system use Access control and authentication errors Errori nel codice Errori nell’architettura e configurazione
  • 6.  
  • 7. La provenienza del software cambia il problema Sviluppato internamente I team di sviluppo devono spesso sviluppare “deliverables” complessi in tempi ristretti e la sicurezza è solo uno dei tanti requisiti critici Applicazioni a pacchetto Anche se configurate in base alle esigenze del cliente, sono normalmente sviluppate su standard del fornitore che può non essere in linea con i requisiti delle Utility Sviluppo in outsourcing Vengono utilizzati sviluppatori esterni per skill e abbattimento dei costi, questo consiste in un elevato dettaglio di requisiti di sicurezza da chiedere al fornitore, che non sempre viene fatto Free and open source (FOSS) Soluzioni a basso costo ma sono realizzati da gruppi di sviluppatori che possono non applicare i requisiti necessari
  • 8. Secure Engineering Una serie di concetti, principi e best practice con l’obiettivo di integrare la sicurezza nel software progettato. Riguarda tutte le fasi del ciclo di sviluppo del software Definizione dei requisiti Design dell’architettura Implementazione Test Deploy Post deployment Secure Engineering non riguarda solo la fase di implementazione, ma è un approccio end-to-end
  • 9. Security & Software Development Life Cycle Security education Strategia di sicurezza e metriche
  • 10.  
  • 11. Categorie e proprietà dei requisiti di sicurezza Es. proprietà SMART+ Specifici Misurabili Adeguati Ragionevoli Tracciabili Ref. http://www.owasp.org
  • 12.  
  • 14. Definire le priorità: Risk Analysis Analizzare software complessi può risultare un’impresa molto lunga e costosa E’ necessario focalizzare l’attenzione sul codice più a rischio (es. componente che gestisce il login degli utenti, componente accessibile via rete, codice legacy etc.) L’analisi dei rischi permette di: Definire le priorità di analisi in funzione della criticità e della funzioni di business Definire l’approccio all’analisi delle vulnerabilità “ misurare” il livello di sicurezza del software prodotto (KPI) Individuare le contromisure più efficaci
  • 15.  
  • 16. Improper Input Validation Improper Encoding or Escaping of Output Failure to Preserve SQL Query Structure (aka 'SQL Injection') Failure to Preserve Web Page Structure (aka XSS) Failure to Preserve OS Command Structure Clear text Transmission of Sensitive Information Cross-Site Request Forgery (CSRF) Race Condition Error Message Information Leak Failure to Constrain Operations within the Bounds of a Memory Buffer External Control of Critical State Data External Control of File Name or Path Untrusted Search Path Es. Vulnerabilità comuni (SANS/MITRE Top 25)
  • 17. Failure to Control Generation of Code (aka 'Code Injection') Download of Code Without Integrity Check Improper Resource Shutdown or Release Improper Initialization Incorrect Calculation Improper Access Control (Authorization) Use of a Broken or Risky Cryptographic Algorithm Hard-Coded Password Insecure Permission Assignment for Critical Resource Use of Insufficiently Random Values Execution with Unnecessary Privileges Client-Side Enforcement of Server-Side Security Es. Vulnerabilità comuni (SANS/MITRE Top 25)
  • 18.  
  • 19. Code Review/Testing Tools Esistono tre approcci fondamentali per analizzare le vulnerabilità di un’applicazione: White Box : viene analizzato il codice sorgente e l’applicazione NON viene eseguita Black Box : NON si ha accesso al codice sorgente e l’applicazione viene eseguita Gray Box : si ha parzialmente accesso al codice sorgente e l’applicazione viene eseguita L’analisi delle vulnerabilità può essere fatta a mano o con tool automatici La revisione manuale è efficace per porzioni limitate di applicazione e codice. Spesso non è la strada corretta Richiede skill elevati di sicurezza Richiede molto tempo (pensate cosa significa controllare 500K LoC…)
  • 20. Tipologie di Analisi I potenziali Problemi di sicurezza Dynamic Analysis Static Analysis Problemi di configurazione Problemi di Patch Level Problemi di privileges escalation Problemi di autenticazione Problemi in external 3 rd party components Null Pointer Dereference Problemi di qualità del codice Problemi di Dead Code Crypto Functions non sicure Problemi nel codice delle Back-End Application (Applicazioni Multi-Tier) SQL Injection Cross Site Scripting HTTP Response Splitting OS Commanding LDAP Injection … Application Logic Issues Runtime Analysis Runtime Analysis utilizza sia la Static che Dynamic Analysis correlandone i risultati
  • 21. // ... String password = request.getParameter( "password" ); // ... " userid='" + u sername + "' " + " AND password='" + password + "'" ; // ... String username = request.getParameter ( "username" ) ; String query = "SELECT …" + username ResultSet rs = stmt.executeQuery(query); String username = request.getParameter( "username" ); String query = "SELECT * from tUsers where " +' ResultSet rs = stmt.executeQuery(query); Sistemi White-Box (es. SQL Injection) … a un Sink da un Source …
  • 22. IBM Rational AppScan Ecosystem AppScan Standard Ed (desktop) AppScan Enterprise user (web client) AppScan Source Ed for Automation IBM Rational Web Based Training for AppScan AppScan Source Ed for Developer / Remediation AppScan Ent. QuickScan (web client) AppScan Tester Ed (scanning agent) (QA clients) Rational Build Forge Rational Quality Manager Rational Application Developer Rational Software Analyzer Rational ClearCase Rational ClearQuest / Issue Management CODE Build security testing into the IDE* BUILD Automate Security / Compliance testing in the Build Process QA Security / compliance testing incorporated into testing & remediation workflows SECURITY Security & Compliance Testing, oversight, control, policy, audits AppScan Source Ed for Security AppScan Enterprise / Reporting Console / Source Ed Core
  • 23. Informazioni utili NERC CIP-003 R5 (Access control) CIP-004 (Personnel & Training) CIP-007-1 R5 (Account Management) NIST NISTIR 7628 1.0 DHS Software Assurance working group and “Build Security In” MITRE CVE and CWE Common Vulnerabilities and Exploits , and Common Weakness Enumeration OWASP Open Web Application Security Project Cigital BSIMM Building Security in Maturity Model IBM X-Force Worldwide cyber threat and risk analysis team

Editor's Notes

  2. Although the number of vulnerabilities affecting Web applications has grown at a staggering rate, the growth demonstrated in the first half of 2009 and continuing through the second half may indicate the start of a plateau, at least in standard (off-the-shelf) software applications for the Web. These figures do not include custom-developed Web applications or customized versions of these standard packages, which also introduce vulnerabilities.