Analysis of How Banking Malware Like Zeus Exploit Weakenesses In On-Line Banking Applications and Security Controls. This prezo is a walkthrough the attack scenarion, the attack vectors, the vulnerability exploits and the techniques to model the threats so that countermeasures can be identified
2. Agenda For Today’s Presentation
PART I: Threat Scenario of Hacking and Malware
PART II: Presenting The PASTA™ Risk Based Threat
Modeling Methodology
PART III: Use of PASTA™ for the analysis of threats,
attacks and the managing of risks posed by
banking-malware
OWASP 2
3. PART I – Malware and Hacking: The Threat
Scenario
OWASP 3
4. The Threat Landscape
The threat landscape of cyber attacks has changed
dramatically in the last ten years:
Attackers are now financially motivated examples include theft
of credit card data for sale, fraud of bank accounts
Attackers are part of organized crime that includes gangs of
fraudsters, corporate spies, cyber-terrorist groups
Attackers are targeting financial businesses because is where
the money is
SOURCE: Cisco: Threat Control and Containment: New Strategies For A Changed Threat Landscape OWASP 4
5. Hacking and Malware Threats Stats
Are the most common threat actions for 2010 data breaches
Include the top three attack vectors
Source: Verizon Data Breach investigation Report: http://www.verizonbusiness.com/Products/security/dbir/
OWASP 5
6. Hacking and Malware Attack Paths & Targets
Web applications are the attack path sought for the highest
percentage of data records breached
The top 5 types of data sought by attackers are credit card
and authentication data
Source: Verizon Data Breach investigation Report: http://www.verizonbusiness.com/Products/security/dbir/
OWASP 6
7. The Threat Actors Behind Hacking & Malware
Source: Verizon Data Breach investigation Report: http://www.verizonbusiness.com/Products/security/dbir/
CyberCrime & Doing Time A Blog about Cyber Crime and related Justice issues: http://garwarner.blogspot.com OWASP 7
8. The New vs. the Old or Dr Jerkill/Mr Hyde
vs. Sherlock Holmes
OWASP 8
9. Lesson #1 From Business Risk Management: I
Know it By I Ignore it
OWASP
10. Lesson #2: Act By Fear, Doubt, Uncertainty
Fear of failing audit/non
compliance => additional fines,
restrictions and controls (e.g. SEC,
PCI etc)
Fear of bad reputation/press =>
public disclosure of data breach of
PII in most US states (SB1386)
Fear of lawsuits from
businesses => fraud losses from
private’s business and customers
Doubts on risk mitigation
measures => Not trusting our own
security technology, people,
processes
Uncertainty on business
impacts => Are we the target?
How much money we loose from OWASP
fraud incidents?
11. Lesson #3: Adopting An Adversarial Approach
Toward Risk Management
“Us vs. Them”
(Security vs.
Dev/IT/Business)
Problem:
Remediation is
drudgery
Demonstrating Threats
& Mitigation
Techniques is Absent
Does not foster
collaboration amongst
those whose ID risk
and those who
mitigate it.
OWASP
12. Lesson #4 There is a Mature Approach to
Risk Management: People, Process, Tools”
People prepared to
learn/deal/respond to
cyber threats
Processes for identifying
security flaws that exploit
weaknesses in
applications/controls
Tools and
countermeasures to
mitigate the risk posed to
cyber threats
OWASP 12
13. PART II-Introducing PASTA™ (Process for
Attack Simulation and Threat Analysis)
Risk Based Threat Modeling Methodology
OWASP 13
14. Threat Modeling Defined
[Application] Threat Modeling
A strategic process aimed at considering possible
attack scenarios and vulnerabilities within a proposed
or existing application environment for the purpose
of clearly identifying risk and impact levels.
Use formal models to categorize threats, map
them to vulnerabilities and identify
countermeasures
Different focus for the analysis:
Software centric
Asset centric
Security centric
OWASP
15. The Limitations of Threat Modeling Today
Several methodologies, none is widely accepted
STRIDE & DREAD are not methodologies, threat and risk
classification respectively
Narrow focus on risk mitigation (e.g. asset, attack,
software, security centric) not all geared toward secure
architecture analysis
Limited in the adoption within the S-SDLC
comparing with other assessments (e.g. secure code
reviews, application pen testing)
Not part of IS governance (e.g. information security
risk management, fraud, incident response)
Subjective and ad-hoc process reliant on application
security knowledge of SMEs (Subject Matter
Experts)/Security Architects/Consultants
OWASP
16. The PASTA™ Recipe For Threat Modeling
Focus on the application
as business-asset target
Embodies all strategic
process for mitigating
cybercrime risks
Simulates attacks and
analyzes targets
Implemented in tactical
stages each with pre-
determined steps
Focused on minimizing
risks to applications and
associated impacts to
business OWASP
18. The Beneficiaries of PASTA™ Threat Modeling
Business managers can
incorporate which security
requirements that impact business
Architects understand
security/design flaws and how
countermeasure protect data assets
Developers understand how
software is vulnerable and exposed
Testers can use abuse cases to
security tests of the application
Project managers can manage
security defects more efficiently
CISOs can make informed risk
management decisions OWASP 18
20. Applying P.A.S.T.A for Banking Malware Threat
Modeling, Goals of the VII Stages:
I. Capture requirements for the risk assessment of banking
malware threats, attacks and vulnerabilities
II. Define the technical scope for the analysis application
and transactions
III.Conduct architecture level and transactional level
security control analysis
IV. Identify and extract threat information from the
sources of intelligence/incidents
V. Analyze weaknesses and vulnerabilities
VI. Model attacks scenarios and exploits
VII.Formulate a risk mitigation strategy to reduce the
impact of banking malware to the business
OWASP 20
21. STAGE I
Define The Business & Security Objectives:
“Capture requirements for the analysis and
management of banking malware risks”
OWASP 21
22. Analysis Of Preliminary Impacts Of Banking
Malware
Impacts to Business
Lose money over fraud (e.g. illegal money transfers) and loss
of customer’s sensitive information
Non-liability for fraud against business accounts triggers
lawsuits
Reputation loss due to either public disclosure of loss of
customer’s PII (e.g. affect company reputation and customer’s
loyalty)
Unlawful compliance, due diligence and failing audit impacts
(e.g. PCI-DSS, FFIEC/OCC, GLBA, SB 1386, FACT Act, PATRIOT
Act)
Impacts to the Customers
Theft of credentials
Theft of sensitive and confidential information
Loss of money from business accounts (Business Accounts)
OWASP
23. Business Objectives & Security Requirements
Project Business Objective Security and Compliance Requirement
Perform an application risk Risk assessment need to assess risk from attacker
assessment to analyze malware perspective and identify on-line banking transactions targeted
banking attacks by the attacks
Identify application controls Conduct architecture risk analysis to identify the application
and processes in place to security controls in place and the effectiveness of these
mitigate the threat controls. Review current scope for vulnerability and risk
assessments.
Comply with FACT Act of 2003 Develop a written program that identifies and detects the
and FFIEC guidelines for relevant warning signs – or “red flags” – of identity theft.
authentication in the banking Perform a risk assessment of online banking high risk
environment transactions such as transfer of money and access of
Sensitive Customer Information
Analyze attacks and the targets Analyze attack vectors used for acquisition of customers’PII,
that include data and high risk logging credentials and other sensitive information. Analyze
transactions attacks against user account modifications, financial
transactions (e.g. wires, bill-pay), new account linkages
Identify a Risk Mitigation Include stakeholders from Intelligence, IS, Fraud/Risk, Legal,
Strategy That Includes Business, Engineering/Architecture. Identify application
Detective and Preventive countermeasures that include preventive, detective (e.g.
Controls/Processes monitoring) and compensating controls against malware-
based banking Trojan attacks
OWASP
24. STAGE II
Define The Technical Scope: ”Definition of the
scope of the threat modeling exercise”
OWASP 24
25. The Online Banking Application Profile
Application Profile: Online Banking Application
General The online banking application allows customers to perform
Description banking activities such as financial transactions over the
internet. The type of transactions supported by the
application includes bill payments, wires, funds transfers
between customer’s own accounts and other bank institutions,
account balance-inquires, transaction inquires, bank
statements, new bank accounts loan and credit card
applications. New online customers can register an online
account using existing debit card, PIN and account
information. Customers authenticate to the application using
username and password and different types of Multi Factor
Authentication (MFA) and Risk Based Authentication (RBA)
Application Type Internet
Data Public, Non Confidential, Sensitive and Confidential PII
Classification
Inherent Risk HIGH
High Risk YES
Transactions
User roles Visitor, customer, administrator, customer support
representative
Number of users 3 million registered customers
OWASP
26. The Definition of The Technical Scope
Design artifacts used for defining the scope:
Application components with respect to the application tiers
(presentation, application, data)
Network topology
Protocol/services being used/exposed from/to the user
to/from the back end (e.g. data flow diagrams)
Use case scenarios (e.g. sequence diagrams)
Application design information to be extracted to define
the scope:
The application assets (e.g. data/services at each tier)
The security controls of the application (e.g.
authentication, authorization, encryption, session management,
input validation, auditing and logging)
The data interactions between the user of the application
and between servers for the main use case scenarios (e.g.
login, registration, query etc)
OWASP
28. The Application Functions in Scope
All financial transactions that are possible targets for
banking malware attacks:
Login help functions (e.g. registrations, reset userId/pwd)
Customer profile management functions (e.g. Change of
account profiles, emails, address, phone numbers)
High risk logins (e.g. authentication with multi-factor
authentication)
Transactions involving validation of Sensitive Customer
Information (e.g. Validations of CCN#, CVV, ACC# and PINs
for registration/ account opening)
Access of PII and Sensitive Customer Information (e.g.
ACC#, CCN#, SSN, DOB)
High Risk Financial Transactions (e.g.
Money transfers to external accounts
ACH
Wires,
Bill-payments)
OWASP 28
29. STAGE III
Decompose the Application :”Identify the security
controls that protect the application
data/assets/servers/components”
OWASP 29
30. Data Flow Diagramming
MFA RBA/
Application Fraud
HTTPs Calls (.do) Detection
User/ Request XML/HTTPS
Browser Web Server Financial
Application XML/HTTPS
HTTPs Transactions (ACH, wires
Responses
external transfer)
(App & DB Server/Financial Server Boundary)
Responses Messaging
Internal (Web Server/ App & DB Server Boundary)
Message Bus
XML/JMS
Application
DMZ (User/Web Server Boundary)
Server
Service
Message
Restricted Network
Response
SQL Query Call/
Auth Data JDBC Financial
Transaction
Processing
MainFrame
Authentication
Credential
Store
OWASP 30
32. STAGE IV
Identify And Analyze The Threats:
“Identifying and extracting threat information from
sources of intelligence to learn about the threat-attack
scenarios and attack vectors used by banking malware“
OWASP 32
33. Identification of the Sources Of Intelligence
Internal sources of fraud
cases, attacks and incidents
(e.g. SIRT)
External sources of gathering
and sharing information about
banking malware attacks and
incidents, these includes
public/free and private/at cost
services some examples:
APWG Trusteer
CERT UK Payments Administration
Digital PhisNet Verizon
FS-ISAC Verisign iDefense
IC3 Zeus Tracker
Internet Fraud Alerts
(ifraudalert.org) OWASP
34. Statistical Data Of Banking Malware Targets
Source
The top-level domains most commonly targeted by ZeuS
OWASP
38. Analysis of Attack Vectors Used By Different
Types of Banking Malware
OWASP 38
39. Characterizing The Banking Malware Threat Profile
1. Targeted and customizable
2. Uses multiple avenues of infection
and different attack vectors
3. Takes & sends commands from
command and control server
4. Evades defenses for client and web
application such as Anti-Virus, SS/TLS,
MFA C/Q and fraud detection systems
5. Injects HTML code into the victim’s
browser to harvest accounts, login and
PII data while user is logged
6. Steals certificates for authentication
7. Steals user input with key-loggers and
form grabbers
8. Allows fraudster to transfer money
from the victim machine by riding the
OWASP
user session 39
40. STAGE V
Weakness and Vulnerabilities Analysis:
Analyzing application weaknesses and vulnerabilities
exploited by banking malware attacks
OWASP 40
41. Banking Malware Threats, Vulnerabilities & Application
Weaknesses Exploits
Social Engineering/Phishing Threats
Exploit weak anti-phishing site to user controls (e.g. EV SSL)
Lack of information to customer on banking malware threats
Account Takeover & Identify Theft Threats
Exploit weak data protection transit & storage (e.g. unsecure cookies,
tokens, unsecured secrets and certificates for authentication)
Authorization flaws (e.g. RBAC bypass/elevation of privileges)
Business logic flaws (e.g. PINs, ACC# validations across channels)
Financial Loss & Fraud Threats
Exploit authentication flaws for transactions (e.g. MFA bypass, weak
authentication/factor per transactions),
Session management flaws and vulns. (e.g. session fixation, session
riding/CSRF)
Non repudiation flaws (e.g. one-way SSL no digital signing for
transactions) OWASP 41
42. Architecture Level View Of Security Flaws &
Vulnerabilities
>
Presentation Tier > Get MY Account
Info And Account
Account#:***8765
Balance: 45,780 $ Weak Anti-Phishing
Activity Last Transaction:
Represents the top most level 5/25/09 and Anti-UI-
of the application. Spoofing Controls
The purpose of this tier is to translate
commands from the user interface
& Warnings
into data for processing to other tiers and Browser
present back the processed data
` ` Vulnerabilities &
Flaws
browser browser
Authentication,
Logic Tier Authorization,
This layer processes commands and Identification and
makes decisions based upon
Session Mgmt.
the application business logic
It also moves and processes data Vulnerabilities and
Servers
Servers Design Flaws
between the presentation and the data tier
Account#,
Query Balance,
Data Tier Transaction
History Flaws and
Is the layer responsible for data storage and Vulnerabilities
retrieval from a database or file system While Protecting
Query commands or messages are processed
Data/Transaction
by the DB server, retrieved from the datasource
and passed back to the lo the logical tier for Confidentiality
processing before being presented to the user and Integrity
Database Storage
OWASP 42
43. The Top 5 Malware Propagation
Vulnerabilities & The Top 10 Attacks
OWASP 43
45. STAGE VI
Model The Attacks and The Exploit Of
Weaknesses and Vulnerabilities:
“Modeling of banking malware attacks”
OWASP 45
46. Banking Malware Attack Analysis Using
Attack Trees
Fraudster Fraudster
Upload Malware on Attack Victim’s Phishing Email, Use Stolen Banking
Vulnerable Site Vulnerable Browser FaceBook Social Credentials/
Engineering Challenge C/Q
Drive-by Download/ Upload Banking Remote Access To
Phish User To Click
Malicious Ads Malware on Compromised PC
Link With Malware
Customer’s Pc Through Proxy
Steal Digital Steals Keystrokes Logs into Victim’s
Certificates For Man In The
with Online Bank
Authentication Browser
Key-logger Account
Delete Cookies Modifies UI Perform Un-
Forcing to Login To Rendered By The Redirect Users To
authorized Money
Steal Logins Browser Malicious Sites
Transfer to Mule
Harvest
Confidential Data/ Sends Stolen Data Money Transferred
Credentials From to Fraudster’s From Mule to
Victim Collection Server Fraudster
OWASP 46
47. Banking Malware Attack Analysis Using “Use
and Abuse Cases”
Key logger/From grabber
Threatens captures keystrokes Includes
Login With UserID Drops Banking
password incl. credentials Malware on victims/PC Includes
over SSL
Includes
Includes Set IP with Proxy/MiTM to Includes
same IP gelocation Includes
of the victim Fraudster
User Threatens
Includes
Trust connection by IP and
machine tagging/browser Communicate
attributes Hijacks SessionIDs, with fraudster C&C
Includes
Cookies, Machine Tagging
Includes Threatens
Includes
Capture
OTP on web channel
Threatens and authenticate
Enter One Time Password
(OTP) to authenticate on behalf of the user
transaction
Includes
Capture C/Qs in transit and
Threatens authenticate on behalf of user
Enter Challenge Question
(C/Q) to authenticate
transaction Threatens
Man In The Browser Injected
HTML to capture C/Q
OWASP 47
49. PASTA ™ Threat Analysis With The Help of The
ThreatModeler™ Tool
OWASP 49
50. Factors for Managing Risks of Banking
Malware Attacks
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 events
The Technical impacts (e.g. compromising 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 user
The Business Impact (e.g. financial loss, fraud, fees/fines
due to 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-
OWASP 50
covered money losses; Unlawful non-compliance with regulations
51. Risk Analysis and Risk Mitigation Strategy
Calculate risks objectively using
different models for calculating risk:
Quantitative (e.g. Likelihood x Impact
(H, M, L), Threat Source (STRIDE) x
Severity (DREAD), Threat X Vulnerability X
Impact (OWASP))
Quantitative (e.g. ALE = SLE X ARO)
Devise a risk mitigation strategy based
upon holistic measures:
Preventive and detective controls
Countermeasures at different
layers/tiers of mitigation (e.g. browser
web application, infrastructure)
Processes-Governance (e.g. risk based
testing, improved fraud detection, threat
OWASP
analysis, cyber intelligence) 51
52. The Banking Malware Risk Management
Framework
Threat Misuses and Vulnerabilities & Countermeasures Technical Business
Agents & Attack Vectors Weaknesses Impacts Impacts
Motives
Dropper of Attacker targets Input validation vulnerabilities Identification and Site integrity is Reputation loss.
Malware seeking vulnerable sites to allowing for Frame injection remediation of common violated, visitors of Money loss/site
to upload it to upload malware for of fraudster's URL, file injection vulnerabilities the site get malware taken down,
vulnerable sites drive by download upload via flaws exploits and and data /input downloaded via lawsuits
SQL injection attacks validation flaws malicious ads
Fraudster Attacker target Phishing and social Consumer education Once user selects Fraud, money
attacking bank banking customer engineering attacks via campaigns, EV-SSL malicious link, JS on losses, reputation
customers and with phishing to different channels (email, certificates to prove client, install banking loss, data breach
institutions exploit browser Facebook, SMS). Lack of authenticity, site to user malware/trojan disclosure,
vulnerabilities and customer information about controls, browser compromising the
upload banking banking malware threats, lack controls browser
trojan keylogger on of site to user trust controls
his PC/browser (e.g. EV SSL)
Banking malware Banking Browser vulns. allowing MiTB, Customer education on Once customer enter Loss of customer
harvest s malware/trojan, gaps in anti-automation spoofed Uis, anti-forgey extra data in the PII, credentials,
viictim’s account inject HTML form detection controls, virtual controls, CAPTCHA, Man HTML form it is sent PII. Reputational
Data and logins fields in session keyboard bypassed by form present controls, anti- to C&C: loss of data loss via public
using MiTB attack , grabbing forgery controls confidentiality and disclosure of
keylogger to stead data integrity since breach,
data, sends data to outside application Compliance audit
C&C and receives control lawsuits, account
commands replacement cost
Fraudster Attacker sends and Authentication flaws in Architecture risk analysis Loss of data Money losses
attacking bank receives data to protecting transaction with to identify flaws, OOBA, confidentiality and associated to
customers and banking malware to adequate strength, session OOBV, transaction transaction integrity, fraud from
institutions perform un- management flaws and signatures, fraud session hijacking, money transfers.
authorized financial vulnerabilities (e.g. session detection/monitoring, missing logging, Lawsuits
transactions using riding/CSFR, fixation), non- event correlation from detection/monitoring compliance/audit
MiTM and session repudiation flaws logs and fraud alerts
OWASPrisks
riding attacks
53. Examples of Countermeasures Against
Banking Malware Threats
PREVENTIVE DETECTIVE
Anti UI Spoofing/Forging Fraud detection/transaction
Web Form Controls Monitoring
Watermarks on web forms Anomaly detection
that are difficult to spoof Detection of cookies HTTP param.
by the fraudster without Logs of session information x high
the user noticing risk transactions
Customer information to
help identify forgery of Malware vs. Man Present
HTML/injected fields Detection
Two-Way Out of Band Capture/profile browser
actions/events
(OOB) Auth & Verification
Anti-automation/CAPTCHA
/ Transaction Signing
SMS, phone to send and Customer alerts (e.g. SMS)
receive authorization and Real time notification for financial
verification of transaction transactions /account changes 53
OWASP
This is to highlight that the threat has changed in terms of attacker motives, the sophistication of the attacks and the impact.APTattacks are focused on a single target, lastinguntil “they are in,” and are meant to collectinformation over a long period of time. They leavefew signs of their success, wanting to stay hiddenfor as long as possible in order to acquire largeamounts of sensitive information.Financial 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.
Slide to convey how the threat landscape changed to qualify the type of attacks and the attack. Also mention other data not included on the slide such as the most sought type of data and the attack vectors
Are with credentials as a mean to get the data ?
Slide to convey how the threat landscape changed to qualify the type of attacks and the attack. Also mention that
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
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
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
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