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.
97.
98.
99.
Notes de l'éditeur
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