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

758 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
758
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • 05 sicurezza delle applicazioni per le aziende nel settore della pubblica utilità

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

    ×