Your SlideShare is downloading. ×
0
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Security Summit Rome 2011
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Security Summit Rome 2011

964

Published on

Attacchi Di Banking Malware: Analisi Minaccie e Identificazione di Countromisure

Attacchi Di Banking Malware: Analisi Minaccie e Identificazione di Countromisure

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
964
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Gliscenarisonocambiatiradicalmentenegliultimidiecianni, inziutto I motivichesonodenaro e profitto in nuovi hackers fannao parte di organizazzioni dedicate allaperperpetuazione di crimine ma ancheallosviluppo di strumenti di attaccco molto sofisticati. I principalivittimesono le aziiendeed in particolareilsettorefinanziarioFinancial losses due to malware-based attacks are rising:In the U.S.A. alone, according to data from FDIC (Federal Deposit Insurance Corporation), during the third quarter of 2009 malware-based online banking fraud rose to over $ 120 millionIn the UK, according to data from the Cards Association, losses from the online banking sector in UK during 2009 totaled 60 million UK pounds.
  • Gliattacchi di malvareContribuisconoallamaggioranzadelleperditadeidati (2010) e sono le due minaccieprincipalli per tipologia di attacco
  • Qualisono I principlai target e I datisensiibilipiurichiesti. Web application represenato la maggioranaze per % deidaticompormessimentre in % dii tipologiaattaccosono al terzopostoI tipi di datipiu a rischiosono I records di carte di creditoseguitidalle login di autenticazione
  • Qualisono glia attori di Il presunto hacker si e’ appenasvegliato e sorseggiando l caffe (o tea o magari vodka) inizia la suagiornata di lavoro con unabellalista di indirizzi IP di computer compromessiassieme a logins per autenticarsiaisiti. Lo step successivoconsiistenelspenderealcune ore a distibuire malware nei PC compromessi e rivedere I PIC vittimadellasettimanascorsa per aggirnarsi sui daticollezionati.Dopo di che’ e ‘ ora di andare a casa ad accudiremoglie e figli. Tuttobenefiinche non sono poi statipresi dal FBI per la compromissione di decine di account e per iltrasferrimento di circa 3 millioni di dollari ad altricontiaperti sotto falsaidentita
  • Citrovianoquindi ad hackers di mestiere ma checonduconoviteapparentementenormalii e mettersisullelorotraccie non e’facileanche se dalla nostra parte abbiamouno come shrelockholmes
  • Un’ altroapprocciotipico e’ quello di agire da soli pensandocheilproblema di security e’ di sola comptenza del diprtimento e questo e’ anche un approccioantagonisticoche non facilita’ la comuncazione e la collaborazione
  • STRIDE e’ un modo di categorizarre I threats e associarliglielementidellaarchitectrurachesonoevidenziati qui nel data flow diagram
  • Oggi ci troviamo ad usaremethodolgie diverse con diverso focus e limitatenelloscopo di mitigazione del rischio, non interfacciiano con altriprocessi come secure code review etc e sonoisloate da altriprocessi come risk management, fraud e incident respone e sibasano molto sull’espereienza di chi conduce l’assessment
  • La nostraricetta e’ unametodolgiacheconsidera la mitigazionedelleminacie un problema di busienss, considera I processi di analisis del rischiostragetico per l’aziendapermette di analizzaregliattachi e siimplementa a stadisuccessivin
  • Stage I-Define the objectives: Identify business objectives and ensure an appropriate level of security requirements to support the business goals for the application yet meeting compliance with security standards. Identify preliminary security and compliance risks and their business impacts to the application.Stage II- Define the technical scope: Define the technical scope/boundaries of threat modeling as dependency on the various technologies, software and hardware, components and services used by the application. Categorize any architectural and technologies/components whose function is to provide security controls (e.g. authentication, encryption) and security features (e.g. protection of CIA)Stage III- Decompose the application: Decompose the application in essential elements of the application architecture (e.g. users, servers, data-assets) that can be further analyzed for attack simulation and threat analysis from both the attacker and the defender perspective.Stage IV- Analyze the threats: Enumerate the possible threats targeting the application as an asset. Identify the most probable attack scenarios based upon threat agent models, security event monitoring and fraud mapping and threat intelligence reports. The final goal is to analyze the threat and attack scenarios that are most probable and need to prioritize later for attack simulation.Stage V-Vulnerabilities & Weaknesses Analysis: The main goal of this stage of the methodology is to map vulnerabilities identified for different assets that include the application as well as the application infrastructure to the threats and the attack scenarios previously identified in the previous threat analysis stage. Formal methods that map threats to several generic types of vulnerabilities such as threat trees will be used to identify which ones can be used for attacking the application assets. Once these vulnerabilities are identified, will be enumerated as and scored using standard vulnerability enumeration (CVE, CWE) and scoring methods ( CVSS, CWSS)Stage VI: Analyze the Attacks: The goal of this stage is to analyze how the application and the application context that includes the users-agents, the application and the application environment, can be attacked by exploiting vulnerabilities and using different attack libraries and attack vectors. Formal methods for the attack analysis used at this stage include attack surface analysis, attack trees and attack libraries-patterns. The ultimate outcome of this stage is to map attacks to vulnerabilities and document how these vulnerabilities can be exploited by different attack vectors.Stage VII:Risk and Impact Analysis: The goal of this final stage is to derive risk and impact values for the application environments, determine the residual risks to the business after countermeasures are applied and existing compensating security controls-measures are considered and provide risk mitigation strategies for informed risk management decisions.
  • P.A.S.T.A allows architects to understand how vulnerabilities to the application affect threat mitigation, identify the trust boundaries and the classification of the data assets, identify vulnerabilities and apply countermeasures via proper design, developers are helped to understand which components of the application are vulnerable and the learn on how to mitigate vulnerabilities, security testers can use security requirements derived through the methodology as well as use and abuse to create positive and negative test cases, project managers can prioritize the remediation of security defects according to risks, business managers can determine which business objectives have impact on security while information risk officers can make strategic risk management decisions by mitigating technical risks yet considering costs of countermeasures vs. costs associated with business impact as risk mitigation factors
  • E possibiledimostrare la metodologiasulcasodelll’analisidelleminaccie dal banking malware Explain the rationale of P.A.S.T.A and why this new framework is being used The seven steps of the P.A.S.T.A process will be covered by looking first and for most at malware-based threat mitigation as a business problem, followed by the definition of the technical scope of existing security controls and their dependencies, the analysis of the effectiveness of these controls using use and abuse cases, the analysis of malware-based threats using threat agent models and threat intelligence reports, the vulnerability and weaknesses analysis of multi-factor authentication, transaction integrity and session management controls, the model of the banking Trojan attacks using attack surface analysis, attack trees and identification of attack paths and the final risk and impact analysis that qualifies and quantifies the negative impact to the financial institution for these kind of attacks and the residual risk after different countermeasures are applied to protect online banking transactions as well as to detect the occurrence of the attacks. The ultimate goal of this presentation is to be able to provide application security-risk managers-officers and application security architects, an example on how P.A.S.T.A. threat modeling can be used to making informed risk management decisions and devise risk mitigation strategies to protect online banking applications from banking Trojans, malware-based type of attacks.
  • Application architecture:The architecture of the application with respect to the “end to end” deployment scenario The location of servers on which the application functionality resides to (e.g. the network topology)The end to end data flows and the protocol/services being used/exposed from/to the user to/from the back end (e.g. data flow diagrams)The use case scenarios (e.g. sequence diagrams) Extract essential information in support of security architecture risk analysisThe exposure of the assets: servers hosting the application and the data including any external, DMZ and internal/GRN linksAll major application software/system components in all the application iers(e.g. front end, middle-tier, back end) and the protocols being used between tiersThe data interactions between the user of the application and between servers for the main use case scenarios (e.g. login, registration, query etc)
  • Login help functionsUser registration, change userID/password, forgot userID/password, change of challenge/question/answersOnline profile management functionsChange of account profiles, emails, address, phone numbersHigh risk loginsAuthentication with Challenge/Questions, KBALogging from high risk location/machine, countryTransactions involving validation of Sensitive Customer InformationValidations of CCN#, CVV, ACC# and PINs for registration/ account openingAccess of PII and Sensitive Customer InformationRetrieval of PII such as SSNs, TaxIDs, DOB (e.g. account opening, tax statements)Access to Sensitive Customer Information such as ACC#, CCN#, PINsHigh Risk Financial TransactionsAccess of Sensitive Customer Information (e.g. ACC#, CCN#, SSN, DOB)ACHWires,Bill-payments
  • Alivello di transaction e’ importanteidentificare I controlliilrlivello di rischiodellatarnsazione e la classificazionedeidati in uso
  • Questiesempi di MiTBservonoanche a caratterizzareiltipo di malware e a determinareunaazione di incident response
  • Web-based attacks take on all comersWhile targeted attacks frequently use zero-day vulnerabilities and social engineering to compromiseenterprise users on a network, similar techniques are also employed to compromise individual users. Inthe late 1990s and early 2000s, mass-mailing worms were the most common means of malicious codeinfection. Over the past few years, Web-based attacks have replaced the mass-mailing worm in thisposition. Attackers may use social engineering—such as in spam messages, as previously mentioned—tolure a user to a website that exploits browser and plug-in vulnerabilities. These attacks are then used toinstall malicious code or other applications such as rogue security software on the victim’s computer.15Of the top-attacked vulnerabilities that Symantec observed in 2009, four of the top five being exploitedwere client-side vulnerabilities that were frequently targeted by Web-based attacks (table 2). Two of thesevulnerabilities were in Adobe Reader, while one was in Microsoft Internet Explorer and the fourth was in anActiveX® control. This shows that while vulnerabilities in other network services are being targeted byattackers, vulnerabilities in Web browsers and associated technologies are favored. This may be becauseattacks against browsers are typically conducted through the HTTP protocol that is used for the majority ofWeb traffic. Since so much legitimate traffic uses this protocol and its associated ports, it can be difficultto detect or block malicious activity using HTTP .The top Web-based attacks observed in 2009 primarily targeted vulnerabilities in Internet Explorer andapplications that process PDF files (table 3). Because these two technologies are widely deployed, it islikely that attackers are targeting them to compromise the largest number of computers possible. Of theWeb browsers analyzed by Symantec in 2009, Mozilla® Firefox® had the most reported vulnerabilities, with169, while Internet Explorer had just 45, yet Internet Explorer was still the most attacked browser. Thisshows that attacks on software are not necessarily based on the number of vulnerabilities in a piece ofsoftware, but on its market share and the availability of exploit code as well.16
  • The Threats (e.g. the causes) Fraudster targeting on-line banking application for data theft and to commit fraud (e.g. un-authorized money transfer to fraudulent accounts)The Vulnerabilities (e.g. the application weakness) Flaws in authentication and session management; Vulnerabilities in data confidentiality and integrity; Gaps in auditing and logging fraudsters actions and security eventsThe Technical impacts (e.g. breaking security controls) Bypassing authentication with Challenge/Questions, KBA, OTPs; Bypassing customer validations to authorize financial transactions; Tampering web forms for account takeover Abuse session by impersonating the authenticated userThe Business Impact (e.g. financial loss, fraud, unlawful compliance etc) Financial loss due to fraud and un-authorized money transfer to money mules; Reputation loss due to disclosure of breaches of customer data, PII; Lawsuits from businesses victim of business account compromise, un-covered money losses; Unlawful non-compliance with regulations
  • Detective ControlsDetect and monitor application functions/transactions targeted by banking malwareAnomaly detection to detect anomalies in login/account transactions and misuse/signature based detection to match with known attack patternsLogs of malware targeted functions such as logins, account management, financial transactions involving wires, billpay, ACH, external transfersIdentify malware by detecting clues of malware initiated transactionsJavascript to capture user’s actions to detect HTML injected data fields with hidden/encrypted codes validated on the serverDetection of specific cookies and web form variables set by malware in HTTP transaction flowsHave customers to subscribe to alerts/notifications OOB (e.g. SMS) for financial transaction
  • Transcript

    • 1. Metodologiaper la simulazionedegliattacchi e per l’ analisidelleminacciecontrole applicazioni web
      Marco Morana
      OWASP
      Security Summit
      Roma
      9 Giugno 2011
    • 2. What is OWASP?
      2
    • 3. 3
      Agenda Della Presentazione
      PARTE I: I nuoviscenari di attaccoaisiti web: dati e statistiche
      PARTE II: La metodologiaper la simulazionedegliattacchi e delleminaccie
      PARTE III: Esempiodell’usodellemethodologia per l’analisidelleminaccie, attachi e calcolodeirischicausati da banking-malware
    • 4. 4
      PARTE I: I nuoviscenari di attacco: dati e statistiche
    • 5. Il cambiamentodello scenario delleminacciealleapplicazioni
      5
      • Lo scenario delleminaccie e’ cambiatodrammaticamenterispetto a dieciannifa, alcuniesempi:
      • 6. Gliattori di attaccosonomotivati dal denaro(e.g. furto di dati di carta di cerdito per vendita, frodifinanziarie)
      • 7. Gliattoridi attaccofanno parte del crimineorganizzato(e.g. spiedeisegreti/proprieta’ intelletuale e gruppiterroristici)
      • 8. I target sono le aziende e in particolareilsettorefinanza
      SOURCE: Cisco: Threat Control and Containment: New Strategies For A Changed Threat Landscape
    • 9. Datisulleminaccie del malware e hacking
      6
      • Contribuisconoallamaggioranzadelleperditadeidati (2010)
      • 10. Cosituiscono le minaccieprincipaliper tipologia di attacco
      Source: Verizon Data Breach investigation Report: http://www.verizonbusiness.com/Products/security/dbir/
    • 11. I targets delleminaccie malware e hacking
      7
      • I siti e le applicazioni web costituiscono la percentualepiualtapresa di miradagliattacchidi malware e hacking
      • 12. I tipi di datipiu’ a rischiosonodatisensibili (e.g. carte di credito)
      Source: Verizon Data Breach investigation Report: http://www.verizonbusiness.com/Products/security/dbir/
    • 13. 8
      GliAttoriDelleMinaccieDietroGliAttacchi di Hacking e Malware
      Il presunto hacker si e’ appenasvegliato e sorseggiandoilcaffe(o tea o magari vodka) inizia la suagiornata di lavorocon unabellalista di indirizzi IP di computer compromessie di logins per autenticarsiaisiti. Lo step successivoconsistenelspenderealcune ore a distibuire malware nei PC compromessi e rivederela listadei PC dellasettimanascorsa per aggiornarsisui daticollezionati.
      Dopo di che’ e ‘ ora di andare a casa ad accudiremoglie e figli.
      CyberCrime& Doing Time A Blog about Cyber Crime and related Justice issues: http://garwarner.blogspot.com
    • 14. Sherlock Holmes vs. DrJerkill/Mr Hyde
      9
    • 15. L’ approccio al rischio “conosco ma non faccionulla”
    • 16. L’ approccio al rischio “PauraIncertezza e Dubbio”
      Paura di esserefuorinorma=> multe e restrizioni e controlli (e.g. SEC, PCI etc)
      Paura di perdere la reputazione=> nelcaso di perdita di datisensibili, forzato a notificareilpubblico (SB 1386)
      Paura di cause penali =>nelcaso la vittimadellafrode e’ il business-clienteinvecechel’utente
      Incertosulle cause e le conseguenze=> Siamonoiil target? Se lo siamoquantodenaropotremmoperdere?
      Dubbisullaefficaciadellecontromisure=> Non ci fidiamodellenostremezzi, processi e persone
    • 17. L’ approccio al rischio “come antagonista a chi ilrischio lo deve mitigate”
      “Noi vs. Loro” (Dept. Sicurezza vs. Dev/IT/BusinessUnits):
      Mitigazionefaccendoricorsoallapillolamagica
      Non c’edimostrazione di come gliattachiavvengono e impattano i business
      Non c’e’ nessunincentivo a collaborarefra chi ilrischio lo identifica e chi lo devemitigare con le contromisure
    • 18. L’ approccio al rischio ”Persone, Processi e Technologie”
      Personalepreparato e qualificato per rispondereagliincidenti
      Processiadequati per l’identificazionedeglierrori di design e le vulnerabilita’ chevengonosfruttatidaglihackers
      Technologie e contromisureper la mitigazionedelleminaccie del malware e hackers
      13
    • 19. 14
      PARTE II-Introduzione al metodo di Threat Modeling PASTA™ (Process for Attack Simulation and Threat Analysis)
    • 20. La Methodologia Per L’AnalisiDelleMinaccie
      [Application] Threat Modeling
      Un processostrategicochepunta a considerare le minaccie, ipossibiliscenari di attacco e le vulnerabilitachepossonoesseresfruttatenell’ambienteapplicativo con lo scopodigestirerischi e livelli di impatto.
      • Si basasudiversimetodologie per la determinazionedelleminaccie e correlazione con le vulnerabilita’
      • 21. Si focalizzasudiversiaspetti per la mitigazionedelleminaccie:
      • 22. Architettura & Software (design)
      • 23. Gliassetti a rischio (dati, server, applicazioni)
      • 24. Prospettiva di attacco o di difesa
    • Metodologia Threat Modeling di OWASP
      Methodolgiasimplificata:
      Focalizzatasulleminaccie al software
      Non include l’analisiedilcalcolodeirischi
      L’analisidelleminaccie e’ fatta a diversilivelli
      OWASP Threat Risk Modeling http://www.owasp.org/index.php/Threat_Risk_Modeling
    • 25. Metodologia Threat Modeling STRIDE di Microsoft
      17
      Spoofing
      Repudiation
      Tampering
      Repudiation
      Info Disclosure
      Denial OF service
    • 26. LimitazioniDelleMetodologie Di Threat Modeling UsateOggi
      Diverse metodologiema nessuna e’ adottata a largascala
      STRIDE & DREAD non sonometodologie ma modelli per la classificazionedelleminaccie e deirischi
      Limitatenelloscopo(e.g. assetto, attacco, software, security centriche) non tuttigliapprocciconsideranol’analisideglierrori di design
      Limitatenell’adozionenella SDLC sopratuttorispetto ad altreattivita (e.g. review codicesicuro, pen testing)
      Non sono parte deiprocessi di InfoSec (e.g. information security risk management, fraud, incident response)
      Processisoggettivied ad-hoc sibasanosull’esperienza di chi fal’analisi SMEs (Subject Matter Experts)/Security Architects/Consultants
    • 27. La ricetta per la P.A.S.T.A™ Threat Modeling
      • Si focalizzasugli asset di business come target degliattacchi
      • 28. Include tutti i processi per la (e.g. intelligence)mitigazionestrategicadeirischi
      • 29. Si basasullaanalisidegliscenari di attacco
      • 30. Si focalizzanelleminimizzazionedeirischidelleapplicazionie degliimpatti per il business
    • 20
      1. Define Objectives
      • Identify Business Objectives
      • 31. Identify Security & Compliance Requirements
      • 32. Business Impact Analysis
      The P.A.S.T.A™ Threat Modeling Methodology
      2. Define Technical Scope
      • Capture the boundaries of the technical environment
      • 33. Capture Infrastructure | Application | Software Dependencies
      3. Application Decomposition
      • Identify Use Cases | Defin App Entry Points & Trust levels
      • 34. Identify Actors | Assets| Services | Roles| Data Sources
      • 35. Data Flow Diagramming (DFDs) | Trust Boundaries
      4. Threat Analysis
      • Probabilistic Attack Scenarios Analysis
      • 36. Regression Analysis on Security Events
      • 37. Threat Intelligence Correlation & Analytics
      5. Vulnerability & Weaknesses Analysis
      • Queries of Existing Vulnerability Reports & Issues Tracking
      • 38. Threat to Existing Vulnerability Mapping Using Threat Trees
      • 39. Design Flaw Analysis Using Use & Abuse Cases
      • 40. Scorings (CVSS/ CWSS) | Enumerations (CWE/CVE)
      6. Attack Modeling
      • Attack Surface Analysis
      • 41. Attack Tree Development | Attack Library Mgt
      • 42. Attack to Vulnerability & Exploit Analysis using Attack Trees
      7. Risk & Impact Analysis
      • Qualify & quantify business impact
      • 43. Countermeasure Identification & Residual Risk Analysis
      • 44. ID risk mitigation strategies
    • Gliutentidellametodologia P.A.S.T.A™
      21
      • Business managers che in questomodopossonoincorporare i requisiti di sicurezza per mitigare i rischi
      • 45. Architettidelle applicationschecosipossonoidentificareglierrori del design e identificare le contromisure per rimediarli e per proteggere i dati e gli assets
      • 46. Sviluppatorichecosipossonocapire se ilsoftware e’ vulnerabileedespostoagliattacchi
      • 47. Security testerschepossonousare i casi di use e abuso e le librerie di attacco per testarel’applicazione
      • 48. Project managers checosipossonogestire la remediazionedeidiffetti in modopiu’ efficace
      • 49. CISO checosipossonoprenderedecisionisu come mitigate i rischi a livelloapplicativo
    • 22
      PART III-Usodellamethodologia PASTA™ per l’analisidelleminaccie, attacchi e deirischi del banking-malware
    • 50. Gli steps dellaanalisi del banking malware usando la metodologia P.A.S.T.A.
      23
      Documentazionedeirequisitiper l’analisideirischidelleminacciebanking malware, attachi e vulnerabilita’
      Definizionedelloscopotecnicodell’ analisi
      Analisidellasicurezza del sitodal punto di vista deicontrolli di sicurezza a livelloarchitetturale e di funzione
      Studio e analisidelleminacciedaidati di intelligence
      Analisidellevulnerabilita’ chepossonoesseresfruttatedalleminaccie per causare un impatto
      Modellidegliscenari di attacco
      Formulazionedellastrategia per la mitigazione del rischio e per la riduzione dell’ impatto a livello di business
    • 51. STAGE I DefinizioneDegliObbiettivi di Sicurezza e Del Business: “Catturadeirequisiti per l’ analisi e la gestionedeirischi di banking malware”
      24
    • 52. AnalisiPreliminareDegliImpatti
      Impatti per l’azienda/business
      Perdita di denaro a causa di frodi(e.g. transferimentoillegale di denaro) e perdita di datisensibili del cliente
      Non responabilita’ legaleper frodicontroclienti-business e’ causa di azionilegali da parte deglistessi
      Perdita di reputazione/immaginea causadellanotificazione al pubblicodellaperditadeidatisensibilideiclienti, questo ha anche un impattosullafedelta’ deiclienti
      Non in regola con la legge e la regolamentazione di sicurezza(e.g. PCI-DSS, FFIEC/OCC, GLBA, SB 1386, FACT Act, PATRIOT Act) e’ causa di multe e controllicostosi compliance
      Impatti per I clienti
      Furto di login per l’accesso a siti di on-line banking
      Furtodeidatisensibili
      Perdita di denarodal contonelcaso di contiaziendali/privati
    • 53. Obbiettivi Dell’ Analisi e Requisiti Di Sicurezza e di Regolamentazione
    • 54. STAGE II Definizionedello Scope TecnicoDell’Analisi ”Definizionedelloscopo di threat modeling relativoairequisitidell’analisi”
      27
    • 55. Profilo Della Applicazione In Scopo Dell’ Analisi: Sito Online Banking
    • 56. DefinizioneDelloScopoTecnicoDell’Analisi
      Informazioneestrattadaidocumenti di progetto:
      Componentidellaapplicazione web in funzionedeilivellifunzionali(presentazione, logica, dati)
      Topologiadella rete (firewall, servers, routers etc)
      Protocolli e processichesono parte dell’ architettura “end to end” (diagrammi del flow deidati)
      Scenari e funzionid’uso(diagrammi di sequenza)
      Modellodellaapplicazione in supportodell’analisi:
      Gli assets dell’ applicazione(e.g. dati/servizi a diverse sezionidellaarchitetturaapplicativa)
      I controlli di sicurezzadell’applicazione(autenticazione, autorizzazione, crittografia, gestionedella session, validazionedell’input, archivio e logs)
      Le interazionifral’utente e l’applicazione per le varietransazioni web (e.g. login, registrazione, query deidati etc)
    • 57. 30
      ScopodellaArchitettura: On-line Banking Application Architecture Diagram
    • 58. Transazioni di On-Line Banking in Scopo Per L’Analisi
      31
      • Identifica le transazioni on-line chesonopossibili targets per malware e hacking (e.g. transazioni ad alto rischio):
      • 59. Funzioni di login (e.g. registrazione, reset userId/pwd)
      • 60. Funzioni per la gestione del profilo(e.g. cambio del profilo/account email, indirizzo, telefonoetc)
      • 61. Funzioni di autenticazione con fattore multi-factor
      • 62. Transazioniriguardandivalidazione del customer con datisensibili(e.g. validazione di CCN#, CVV, ACC# and PINs for registrazione e per apertura di conto)
      • 63. Accesso a daticonfidenziali e sensibili(e.g. ACC#, CCN#, SSN, DOB)
      • 64. Transazionibancarie as alto rischio:
      • 65. Transfermienti di denaro a contiesterni
      • 66. ACH
      • 67. Bonifici,
      • 68. Pagamenti
    • STAGE III Analisi dell’ applicazione:”Identificazionedeicontrolli di protezionedeidati/assets e efficacia del controllistessinellamitiazione del rischio di attacchi da banking malware”
      32
    • 69. Analisi del data flow di processodellaapplicazione di Online Banking
      33
    • 70. Analisi Dell Efficacia Dei Controlli di Sicurezza a LivellodelleTransazioni Online
      34
    • 71. STAGE IV IdentificazioneDelleFonti Di Intelligence Per L’AnalisidelleMinaccie: “Identificazioneedelaborazione di informazionisulleminacciedallefonti di intelligence al fine di poteranalizzaregliscenari e vetori di attaccousati dal banking malware“
      35
    • 72. IdentificazioneDelleFonti Di Intelligence
      Esempio di cosasipuoapprenderedallefonti di intelligence:
      Un nuovobanking trojane’ distribuito via sitivulnerabili a iniezione di data in frames oppourevia spear phishing direttamenteaiclienti di banca(targeted)
      Il malware iniettacodice HTML nelbrowser duranteunasessioneautenticata di on-line banking aifini di rubaredatisensibilidall’utente
      Il malware comunica con il server botnet Commando e Controllo C&C
      Il C&C serve codice al trojan e permetteall’hacker di condurretransazioniimpersonandol’utente
      Il malware mantiene li contobancario “in balance” per non esserenotatodaisistemi anti-frode
      Fontiesternedi informazionisuattacchi di banking malware
      Fonti interne, per esempio da frodi e attacchi/incidenti (SIRT)
      Fonti di informazionepublica e a pagamento:
      APWG
      CERT
      Digital PhisNet
      FS-ISAC
      IC3
      Internet Fraud Alerts (ifraudalert.org)
    • DatiStatistici Sui Banking Trojan Targets
      Source
      Domini target del Zeus trojan
    • 77. Trends di Banking Malware
    • 78. Scenario di Attacco Del Banking Malware
      39
    • 79. Esempi Di Incidenti Di Banking Malware RiportatiDagliUtenti
      40
    • 80. Esempi Di Vettori Di AttaccoEstrattiDall’Intelligence
      41
    • 81. Profilo Di Minaccia Del Banking Malware
      42
      E’ configurabile per diversi target di banche
      Utilizzadiversi tipi di attacco per infettareil PC utente/browser
      Accetta e mandacomandi al command control server
      Evade le difese di client e applicazionecome Anti-Virus, SS/TLS, MFA C/Q efraud detection systems
      Iniettacodice HTML nel browserdellavittima al fine di catturareconti, logins, data i sensitibiliin sessioneautenticata
      Ruba is certificati diautenticazione
      Ruba input allatastierausandokey-loggers e form grabbers
      Permette all hacker di transferiredenaro dal contovittima
    • 82. STAGE VAnalisidellevulnerabilita’:Analisidellevulnereabilita’ e dei gap deicotnrolli di sicurezzachesonosfrutatte per condurregliattacchi
      43
    • 83. CorrelazioneDelleMinaccie di Banking Malware con lo sfruttamentodellevulnerabilita’
      Minacciedi Social Engineering/Phishing
      Sfruttanodebolezze in anti-phishing controls (e.g. EV SSL)
      Mancanza diinformazione al client circa minaccie di banking malware
      Minacciediimposessamentodelle login e datisensibili
      Mancanza di protezionedeidati (e.g. unsecure cookies, tokens, unsecured secrets and certificates for authentication)
      Injection di malware via Iframe, SQL injvulns (e.g. per il dropping),
      Errori di implementazione di autorizzazione
      Error nellalogica di validazione del customer (e.g. PINs, ACC#)
      Minaccie verso transazioni ad alto rischio (bonifici)
      Sfruttanoerroridell’implementazione e progetto di authenticazionedelletransazione (e.g. MFA bypass, weak authentication)
      Vulnerabilita’ session management dellatransazione (e.g. session fixation, session riding/CSRF)
      Vulnerabilita in non repudiazione (e.g. one-way SSL)
      44
    • 84. Vulnerabilita’ Client- Servers A LivelloArchitettura
      45
      Weak Anti-Phishing and Anti-UI- Spoofing Controls
      & Warnings
      Browser Vulnerabilities & Flaws
      Authentication, Authorization, Identification and
      Session Mgmt. Vulnerabilities and Design Flaws
      Flaws and Vulnerabilities While Protecting Data/Transaction Confidentiality and Integrity
    • 85. Top Malware Propagation Vulnerabilities
      46
    • 86. Vulnerabilta’ potenzialmentesfruttate da banking malware
      Black Box Testing
      White Box Testing
    • 87. STAGE VIModelloDegliAttacchi:“Modellodegliattacchi di banking malware”
      48
    • 88. Analisi Banking Malware Con Attack Trees
      49
    • 89. Analisi di Attacco a Login Con Use and Abuse Cases
      50
    • 90. AttacchiAlleTransazioni e Sfruttamento Di Vulnerabilita’
      51
    • 91. Threat Modeling Con ThreatModeler™
      52
    • 92. STAGE VIIAnalisideiRischi e DegliImpatti: “Identificazionedellastrategia per la mitigazione del rischio del banking malware”
      53
    • 93. Fattori Per L’Analisi Del Rischio
      54
      • Le minaccie (le cause) hacker prende di mira on-line banking application per i dati e per condurrefrodi (transferimento non autorizzato di denaro)
      • 94. Le vulnerabilita’ (debolezzedell’applicazione) Errorinel design di autenticazione e session management; Vulnerabilita’ in garantireconfidenzialita’ e integrity deidati; mancanza di logs e di tracciabilita’ deglieventi e azionidegli hackers sui sistemi
      • 95. L’impattotecnico (compromissionedeicontrolli) By-passamentodiauthenticazione multi-fattore (Challenge/Questions, KBA, OTPs;) By-passamentoiogicadiidentificazione del client prima di autorizzaretransazioni; Compromissionedelle web forms al fine di otteneredatidall’utente. Abuso session di autenticazione.
      • 96. L’impatto per il business (perditadenaro) Perdite per Frodi/transferimento di denaro a mules; Perdita di data sensibili; Azionilegali per coperturadanni account; Multe per non essere a norma con standards di sicurezza
    • Factori Per Il Calcolo Del Rischio
      Calcolo del rischiobasandosisumodellioggettivi:
      Qualitativo (e.g. Likelihood x Impact (H, M, L), Threat Source (STRIDE) x Severity (DREAD), Threat X Vulnerability X Impact (OWASP))
      Quantitativo (e.g. ALE = SLE X ARO)
      Strategia di mitigazioneholistica e multi-layer
      Controlli per prevenzione e detection
      Contromisure a diversilivelli(e.g. browser web application, infrastructure)
      Processi di Governance (e.g. risk based testing, improved fraud detection, threat analysis, cyber intelligence)
      55
    • 97. Banking Malware: Application Risk Framework
    • 98. Contromisure per la mitigazione del rischio
      57
      ALERTA & MONITORAGGIO
      Sistemi di monitoraggio e alertafrodi
      Anomaly detection
      Identificazione di cookies e di variables settate dal malware
      Logs delle sessions/transactions
      Controlli anti-automation, man vs.script/botnet
      Catturanoil profile del browser e glieventi
      CAPTCHA
      • Alerts al cliente via SMS
      Notifica in tempo reale di azionisulconto
      PREVENZIONE
      Misure Anti Contraffazione UI/HTML
      Watermarks nelle web forms chesonodifficili da riprodurre
      Informazioni al clienti al fine di identificarepagine web contraffatedal malware
      Authentificazione/VerificaFuoriCanale On-Line (e.g. SMS)
      Cellularericeverichiesta di confermadellatransazione on-line. Uso di tokens per firmare la transazione
    • 99. 58
      Q
      &
      Q U E S T I O N S
      A N S W E R S

    ×