Transcript Here - Computer Science

Securing Banks from Authorized Users
Vijay Kumar
Computer Science and Informatics
School of Computing and Engineering
University of Missouri-Kansas City
Kansas City, MO 64110,USA
[email protected]
Securing Banks from Authorized Users
Vijay Kumar
Securing Banks from Authorized Users
Our data processing infrastructure
We assume that users have access to their accounts through
mobile database system. We, therefore, discuss security scheme
for this setup.
Securing Banks from Authorized Users
Vijay Kumar
We will talk about
Why is Security Important in Banking?
Some Facts
The Insider (authorized user) Threat
Insider Attack Tree
Current Security Schemes
Mitigation Matrix
Mobile Database System (MDS)
Malicious Transactions
A Reference Malicious Transaction Model
Our Scheme for its Identification in MDS
Your thoughts and suggestions
Securing Banks from Authorized Users
Vijay Kumar
Why is Security Important in Banking?
That’s where the money is…
Evolution from standalone to standards-based networks
Evolution from hackers to organized crime
Significant increase in security breaches and threats
Proliferation of attack schemes and sophisticated gadgets
Changing attack mode: individual to organized
Increased vulnerability as a result of increased services
Securing Banks from Authorized Users
Vijay Kumar
Some Facts
646 data breaches in 2008, a 47% increase from 20071
At Heartland, the fourth largest card processor, a breach potentially revealed
100 million credit card numbers
Average cost per computer security incident of financial fraud close to $500,000
A manager at a military base learned she is about to be dismissed so she
enciphers critical files and offers to sell the key to her boss of $10,000 and
immunity from prosecution
A system admin at a bank reviewing a log notices a $10 million transaction to
an account that ends in 6734. Their account ends in 6834, so they move the
money and alter the log
At a regional ISP an employee re-programs wireless access points to deny
customers access for three weeks
Fidelity National suffered a major loss of customer data in 2008, which the
company blamed on a DBA
A former UnitedHealth Care employee was charged in an identity theft case
involving the company’s customer data
Securing Banks from Authorized Users
Vijay Kumar
The Insider (authorized user) Threat
What is an “insider”?
A current or former employee, contractor, or business partner who
has an authorized level of network, system, or data access that could
affect the security of the organizations’ data, systems or daily
business operations.
Research may make further distinctions
Are insiders a threat?
Where perpetrator was identified, in 2007 31% of electronic crimes
reportedly committed by insiders
In a bank study between 1996 and 2002:
30% of cases of insider incidents resulted in losses >$500,000
91% of cases had at least one other adverse impact
70% of incidents took place during normal work day
Securing Banks from Authorized Users
Vijay Kumar
The Insider (authorized user) Threat
Is it easy to identify potential insider threats?
No common profile7
Age range from 18 to 59
Variety of positions (only 23% technical)
Only 15% were considered difficult to manage, only 4% untrustworthy
61% were detected by people not responsible for security7
35% by customers
13% by supervisors
13% other non-security personnel
Involves a range of customers
Checking account holders
Credit card holders
Loan customers
Prospects
Securing Banks from Authorized Users
Vijay Kumar
The Insider Attack Tree
What is an Attack Tree?
“A formal, methodical way of describing security systems, based
on varying attacks.”
Root, Branch and Leaf node structure
Designed to give a perspective of the entire system
Structure of Insider Attack Tree
Root node: Insider Attacks
Major branches:
Intentional attacks
Unintentional opportunities
Minor branches: based on intent
Leaf nodes: Actual attack methods
Securing Banks from Authorized Users
Vijay Kumar
The Insider Attack Tree
Insider
Attacks
Unintentional
Intentional
Directly Steal
Money
Steal
Information
Malicious
Actions
Careless
Employee
Securing Banks from Authorized Users
Inadequate
Policies &
Procedures
Vijay Kumar
The Insider Attack Tree
Insider Attacks
Intentional
Directly Steal Money
Steal Information
Steal Customer List
Sell Customer List
Sell Customer
Inside Information
Sell Dealing
Malicious Postings
Insider Trading
Transfer Fund
Valid Transaction
-- Bypass Secondary
Authorization
-- Steal Credential
-- Physical Access
Steal Identity
Steal Identity
Resell Identity
Account Fraud
-- Statement Fraud
-- Card Protection Fraud
Malicious Action
Database Attack
Data Destruction
Data & Schema Manipulation
Take Data Off-line
Vulnerability Exploit SQLi
Account Fraud
-- Steal Identity
-- Statement Fraud
-- Dormant Account
-- Card Protection Fraud
Altered Transaction
-- Man in The Middle
-- Session Hijacking
Extortion
Document Fraud
-- Threat of Info. Release
-- Kiting
-- Threat of Account Fraud
-- Official Checks
> Steal Identity
-- By Pass Secondary
> Statement Fraud
Authorization
-- Card Protection Fraud > Dormant Account
> Card Protection Fraud
Application Attack
-- Vulnerability Exploit
-- Source code Modification
> Transaction modification
> Skimming
> Account Manipulation
> Time Bomb
Database Attack
-- Manufacturing Data & Schema
-- Vulnerability Exploit SQLi
Application Attack
Vulnerability Exploit
Take Off-line
Source Code Modification
-- Transaction Modification
-- Account Manipulation
-- Time Bomb
Network Attack
Sync/Ack Attack
TCP Flood Attack
QOS Changes
Cache Poisoning
Change Routing Protocol
Bandwidth Restrictions
Locks Hubs or Routers
Unintentional
Careless Employees
Losing Sensitive Data
Causing Security Compromises
Downloading Malware
Ignoring Security Protocols
Not Reviewing Logs
Loosing Hardware
Install Untested Software
Inadequate Policies & Procedures
Password
-- Selection Restriction
-- Change Cycle
-- Complexity
Awareness
-- Social Engineering
-- Policies
Securing Banks from Authorized Users
Vijay Kumar
The Insider Attack Tree
Attack tree summary
Directly stealing money
Transfer funds – 13 attack methods
Account fraud – 4 attack methods
Document fraud – 3 attack methods
Extortion – 5 attack methods
Stealing information
Identity theft – 2 attack methods
Customer list theft – 2 attack methods
Insider information – 3 attack methods
Malicious actions
Network attack – 8 attack methods
Application attack – 5 attack methods
Database attack – 5 attack methods
Carelessness – 9 attack methods
Inadequate policies and procedures – 8 attack methods
Securing Banks from Authorized Users
Vijay Kumar
Current IT Security Schemes
Security through obscurity4
A few experts have knowledge
Outside connectivity is minimal
Problems:
Increasingly interconnected environment
eCommerce
De facto standardization on Windows and Linux
Perimeter defense
Control external access points
Authenticate users
Problems5:
Break down of the perimeter
Mobile workforce
Decentralization of services
Increasing value of information
Securing Banks from Authorized Users
Vijay Kumar
Current IT Security Schemes
Defense in Depth (based on military concept)
Definitions:
“Defense in Depth is the systematic security management of people,
processes and technologies, in a holistic risk-management approach.”5
“…use of multiple computer security techniques to help mitigate the risk of
one component of the defense being compromised or circumvented.” 6
Systematic layering of encryption, authentication and authorization
Level 1: workstations
Level 2: servers
Level 3: network devices
Level 4: perimeter devices
Level 5: centralized reporting and control
Problems:
Expensive; how much is enough?
Still vulnerable to insider attack
Securing Banks from Authorized Users
Vijay Kumar
Current IT Security Schemes
Purpose
Indentify weaknesses in current mitigation strategies against insiders
Indentify where layered strategies could defeat an insider
Determine where location-based authentication would strengthen
security
Design
Assess attack methods versus mitigation strategies
Ranked mitigation on a scale from 0 to 2
0 provides no protection
1 provides some protection but can be circumvented
2 provides strong protection
Identified 16 mitigation strategies currently in use
Securing Banks from Authorized Users
Vijay Kumar
Mitigation Matrix
Identified 16 mitigation strategies currently in use
Each organization may use a different subset of these strategies/tools
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Static password
Soft token
Hard token
One time password
Challenge – Response
Biometrics
Knowledge-based
Access control
Anti-virus software
Network & Application IPS
Network segmentation
Change management
Source code analysis
Dual physical control
Content analysis
Media encryption
Securing Banks from Authorized Users
Vijay Kumar
Mobile Database Management System (MDS)
A reference architecture of MDS.
PSTN
HLR
VLR
MSC
MSC
DB
DB
DBS
DBS
Fixed Host
BSC
BSC
Fixed Host
C2
Cn
C1
BS
MU
MU
BS
BS
MU
MU
MU
Wireless connection
Wired connection
Securing Banks from Authorized Users
Vijay Kumar
Malicious Transactions
An attack is an inconspicuous activity initiated by a user—
legal or illegal—which may or may not destroy the ACID
properties, but it is very hard to identify this so one assumes
that it would destroy database correctness and eliminates it
before it manipulates the database. This activity may be
initiated through a transaction (which is always correct) or by
some other means. We are only interested in the initiation of
malicious activity through transactions.
We argue that the current ACID model is not equipped to
identify and manage an attack on the database from a source
(external or internal).
Securing Banks from Authorized Users
Vijay Kumar
Solution Approaches
External:
A solution approach can be external where
the
existing
transaction
processing
discipline is wrapped with some kind of
shield to detect and protect the database
from malicious activity.
Transaction model: Our approach is to enhance the ACID model
to incorporate the identification mechanism.
We identify a “fifth element” whose
presence in the database processing
domain defines a fifth property of a
transaction which we refer to as “Safe”. We
ask the question “Is it not possible to
incorporate “Safe” as a basic property of an
ACID transaction?”
We think it is possible so we say ACID to ACIDS.
Securing Banks from Authorized Users
Vijay Kumar
User Categories
We categorize users as follows:
Authorized User (AU): A user who can initiate any
transaction such a human operator, database administrator,
etc.
However, an AU is not supposed to run some
transactions and if he tries then he is downgraded to an
illegal user.
Legal User (LU): A user who can only initiate a pre-defined
set transaction called Legal Transactions (LT). Every LU has
it own LT. An AU is always a legal user but a legal user may
not be an AU in some cases. Thus, a legal user is a special
(restricted) class of AU. For example, a bank manager (AU)
can make a teller a LU for running transactions only for a set
of accounts.
Securing Banks from Authorized Users
Vijay Kumar
User Categories
Illegal User (IU): A user who tries to run transactions that
are not present in his LT. For example, a teller operator is
authorized to execute transactions to deposit money into
customer’s accounts but he executes a transaction to
deposits money into his own account.
Authorized-Unauthorized user (AUU):
An AU can be
downgraded to UU category by revoking all AU’s privileges.
Legal-Illegal User (LIU): A legal user downgrades to IU if the
LU tries to run a transaction which is not present in LT. For
example, the teller is downgraded to LIU if he executes
transactions for customers other than his own.
Securing Banks from Authorized Users
Vijay Kumar
Transactions Set
We define the following types of transaction sets:
Unauthorized Transaction Set (UT): It is a set of transactions
which should not be executed either by an Au or by a legal
user. A LT is associated with a type of user. Thus a UT for
user A may me a LT for user B.
Legal Transaction set (LT): A transaction set for each LU. A
LU downgrades to IU if the LU tries to run a transaction
which is not present in his LT. For example, the teller is
downgraded to LIU if he executes transactions for
customers other than his own.
Securing Banks from Authorized Users
Vijay Kumar
ACID Transaction
Conventional ACID transaction model is not appropriate for MDs
for a variety of reasons. Some of them can be identified as
follows:
It does not support location property.
Too rigid for mobile environment.
Securing Banks from Authorized Users
Vijay Kumar
Malicious Transactions
These user types are interchangeable and the change will
happen during the identification and management of malicious
activities. Thus, under a set of constraints, a AU can be
downgraded to UU, an IU can be upgraded to LU, and so on.
We formally define the setup as follows:
C = {c1, c2, …, cn}; where ci is a set of constraints.
U = {u1, u2, …, um}; where ui is a set of authorized users.
For each ui (1  i  m) define Pi where
Pi = {c|c  C and ui possess}
I = {D1, D2, …, Dk} where Di is a subset of C which must be
satisfied for safely performing the desired activity i. It is
possible to perform a number of activities (i = 1, i = 5, i = 9,
etc.) with the same Di.
Securing Banks from Authorized Users
Vijay Kumar
Malicious Transactions
Define relation R
Authorization U  I. So ui R Dj if Pi  Dj
What we have tried to formulate is that a user executes
transactions under a set of constraints defined for him. If the
user does not satisfy any of the defined constraints then his
action can be interpreted as malicious.
One of our tasks now is to assimilate these into the fifth property
“Safe”. A UU cannot have access privileges so he may try to
initiate an activity (malicious by default) through AU or LU or UU.
This may create denial of service.
Securing Banks from Authorized Users
Vijay Kumar
Malicious Transactions
The structure of our ACIDS transaction is as follows:
Atomicity:
This property is satisfied by roll-forward or
roll-back actions.
Consistency: This property is satisfied by consistency
constraints.
Isolation:
This property is enforced by concurrency
control schemes.
Durability:
This property is satisfied through commit
operation.
Safe:
This property is satisfied through user and
transaction analysis.
Under our approach then a transaction requires the support
of a protocol similar to concurrency control or recovery to
commit.
Securing Banks from Authorized Users
Vijay Kumar
SAFE – One of our Fifth element
Safe property is satisfied through user and transaction analysis.
Similar to concurrency control and recovery schemes Safe
Analysis Protocol (SAP) will be active during the execution life
of a transaction. SAP will detect any interference and either
HOLD the execution of the transaction or let it run to commit.
HOLD: This state tries to discover the source of malicious
activity and adds the information to the log.
Concurrency control resolves conflicts for serialization. SAP
will also analyze a data request and its for the presence of any
malicious activity. In this way SAP will monitor and analyze
vulnerable activities during transaction execution for keeping
database safe.
Securing Banks from Authorized Users
Vijay Kumar
SAFE – One of our Fifth element
User analysis
Through user profile.
Our user profile includes user
geographical movement and database interaction history.
The database interaction provides us with user’s preferred
transactional activities. Any diversion from this pattern is
enough to trigger a transaction analysis
Securing Banks from Authorized Users
Vijay Kumar
SAFE – One of our Fifth element
Transaction analysis
A user analysis triggers a transaction analysis where transaction’s
data requirements and their values are examined. For example, a
large amount of withdrawal, deposit or transfer, etc., will trigger
further analysis. In this next level of analysis we will check if such
transaction was executed any time before and if yes then its
execution and user histories will be examined. This will provide us
the data values and the final result which will be helpful in detecting
the intention of the user. This conditional analysis will continue until
a value for SAFE is identified.
Securing Banks from Authorized Users
Vijay Kumar
SAFE – One of our Fifth element
The following figure illustrates SAP operation:
BT
Read
lock
Write
lock
T
ET
Control is
transferred to SAP
Abort
SAP
Lock
Start analysis
Lock
analysis
Update user profile, update
log, increment or decrement
SAFE value (SAFE credit)
ET
analysis
Commit
We propose to use the value of SAFE credit to guess user’s
intention. A higher value means the user is less likely to
initiate malicious activity. For example, multiple incorrect
entry of a request may indicate malicious intention.
Securing Banks from Authorized Users
Vijay Kumar
SAFE – One of our Fifth element
Similar to Degrees of Isolation (Degree 0, 1, 2, and 3), we have
SAFE degree 0, 1, 2, 3; degree 3 being completely maliciousfree transaction and user, conceptually similar to the notion
of Isolation degree 3.
Our idea is to make Safe (S), Consistency (C) and Isolation (I)
complementary and Durability (D) a part of S. This is one of
the ways we can integrate the management of malicious
action a part of transaction model.
At present there are approaches which analyze transaction
access pattern and conflicts to identify malicious behavior.
Our idea, however, is to move the entire process to
transaction structure to make it self-sufficient.
Securing Banks from Authorized Users
Vijay Kumar
Mobile Transaction Model - Mobilaction
To process mobile databases we have developed a Mobile
transaction model called “Mobilaction”. We have added a new
property called ``location (L)“ to ACID model extending it to
ACIDL to manage location based processing. The ``location (L)"
property is managed by a Fragment Location Mapping (FLM)
function. Each execution fragment, ej, of a Mobilaction, is
associated with a unique location. Given a set of execution
fragments E, FLM is a mapping FLM : E  L.
A Mobilaction (Ti) = <Fi,Li,FLMi>, where Fi = {ei1, ... , ein} is a set
of execution fragments, Li = {li1, ... , lin} is a set of locations, and
FLMi = flmi1, ... , flmin} is a set of fragment location mappings,
where j, flmij(eij)=lij. In addition, j,k,lij <> lik.
Securing Banks from Authorized Users
Vijay Kumar
Location in Mobilaction
We now include the location of Mobilaction also as a part of the
fifth element. Thus, the location of Mobilaction is an important
property for detecting a malicious activity. We argue that the
“Safe” property of our model can be enforced with location and
user analysis. User analysis can be done through user profile
and location analysis can be performed through transaction
initiation.
We claim that if two Mobilactions are issued by the same account
at two different locations then the properties of these locations
will provide important information to identify the malicious
Mobilaction from the “Safe” Mobilaction.
Securing Banks from Authorized Users
Vijay Kumar
An Example
Ali is a valid user. Vijay got hold of his login data and credit card
number (s). The user profiles of Ali and Vijay are known to MDS.
Ali issues a money Mobilaction from L/L (MST) and Vijay posing
as Ali issues money Mobilaction from L/L (UMKC). Suppose
these Mobilactions were issues within 5 minutes apart. Ali
cannot be at MST and at UMKC in this time duration. One of
these Mobilactions then is malicious.
I agree that it is not a perfect scheme yet but I argue that it gives
us a powerful starting point for developing a good detection
scheme.
Securing Banks from Authorized Users
Vijay Kumar
Our Location-Based Authentication
Location Signature
We propose the use of “Symbolic Location Coordinates”
identifying the real time location information of a user into
existing security mechanisms to improve the efficacy of
authentication, authorization, and access controls.
We refer to this real time location information which is unique
for a user as “Location Signature (LS)”.
Securing Banks from Authorized Users
Vijay Kumar
Our Location-based Authentication
Location Signature
Symbolic Location information (building, street, area ID, base
station id, etc.) of a mobile device adds a fourth dimension to
wireless application security.
It can supplement or complement existing security mechanisms.
The LS can still be used as a security mechanism when other
systems have been compromised as it is and will always be
unique for a user at any point of time.
For highly sensitive wireless applications, a real time LS can be
generated so that authorities can trace any malicious activity back
to the location of the intruder. Without the incorporation of LS, it
will be difficult to trace the origin of malicious activity.
Securing Banks from Authorized Users
Vijay Kumar
How does Location Signature (LS) Work?
Location Signature in Log File
Location X1 Street Y1 User ID T1
Location X1 Street Y1 User ID T1
Location X2 Street Y2 User ID T2
Web Server
Location X1 Street Y1 User ID T1
Location X2 Street Y2 User ID T2
Location X3 Street Y3 User ID T3
XML Request
LS
XML Request
XML Request
LS
LS
MU
Securing Banks from Authorized Users
Vijay Kumar
Location-Based Security and Authentication
It is almost impossible to replicate a LS because a user cannot
exist at two places at the same time.
Even if the information is intercepted during communications, an
intruder cannot replicate that data from some other place.
A LS is continuously generated from location information on
real-time basis and is unique to a particular place and time.
It is cumulative, i.e., the new LS is a set of old LS plus the new
signature recently added.
Such information becomes invalid after a short time interval,
which means that the intercepted Location Signature cannot be
used to mask unauthorized access especially when it is bound to
the wireless protocol messages as checksums or digital
signatures.
Even if the perpetrator uses other means to masquerade as a
legitimate user, the complete set of LS can be used to log the
access trail.
Securing Banks from Authorized Users
Vijay Kumar
Epilogue
Thanks for coming and participating in this talk.
Securing Banks from Authorized Users
Vijay Kumar