Securing Banks from Authorized Users

Vijay KumarSecuring Banks from Authorized Users

Securing Banks from Authorized Users

Vijay KumarComputer Science and Informatics

School of Computing and EngineeringUniversity of Missouri-Kansas City

Kansas City, MO 64110,[email protected]


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.


We will talk about

Why is Security Important in Banking?Some FactsThe Insider (authorized user) ThreatInsider Attack TreeCurrent Security SchemesMitigation MatrixMobile Database System (MDS)Malicious TransactionsA Reference Malicious Transaction ModelOur Scheme for its Identification in MDSYour thoughts and suggestions


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


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 numbersAverage cost per computer security incident of financial fraud close to $500,000A 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 prosecutionA 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 logAt a regional ISP an employee re-programs wireless access points to deny customers access for three weeksFidelity National suffered a major loss of customer data in 2008, which the company blamed on a DBAA former UnitedHealth Care employee was charged in an identity theft case involving the company’s customer data


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 insidersIn a bank study between 1996 and 2002:

30% of cases of insider incidents resulted in losses >$500,00091% of cases had at least one other adverse impact70% of incidents took place during normal work day


The Insider (authorized user) Threat

Is it easy to identify potential insider threats?No common profile7

Age range from 18 to 59Variety 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 customers13% by supervisors13% other non-security personnel

Involves a range of customersChecking account holdersCredit card holdersLoan customersProspects


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 structureDesigned to give a perspective of the entire system

Structure of Insider Attack TreeRoot node: Insider AttacksMajor branches:

Intentional attacksUnintentional opportunities

Minor branches: based on intentLeaf nodes: Actual attack methods



Directly Steal Money

Insider Attacks

Malicious Actions

Steal Information

Careless Employee

Intentional Unintentional

Inadequate Policies &

Procedures



Directly Steal Money

Insider Attacks

Unintentional

Intentional

Steal Information

Malicious Action

-- Bypass Secondary Authorization-- Steal Credential-- Physical Access

Transfer Fund

Valid Transaction

-- Manufacturing Data & Schema-- Vulnerability Exploit SQLi

-- Man in The Middle-- Session Hijacking

-- Vulnerability Exploit-- Source code Modification > Transaction modification > Skimming > Account Manipulation > Time Bomb

Network Attack

Database Attack

Application Attack

Careless Employees

Inadequate Policies & Procedures

Sync/Ack AttackTCP Flood Attack

Cache PoisoningQOS Changes

Change Routing ProtocolBandwidth RestrictionsLocks Hubs or Routers

-- Transaction Modification-- Account Manipulation-- Time Bomb

Source Code ModificationTake Off-lineVulnerability Exploit

Data DestructionData & Schema Manipulation

Vulnerability Exploit SQLiTake Data Off-line

Losing Sensitive DataCausing Security Compromises

Ignoring Security ProtocolsDownloading Malware

Not Reviewing LogsLoosing HardwareInstall Untested Software

Extortion-- Threat of Info. Release-- Threat of Account Fraud > Steal Identity > Statement Fraud > Dormant Account > Card Protection Fraud

Altered Transaction

Application Attack

Database Attack

Document Fraud-- Kiting-- Official Checks-- By Pass Secondary Authorization-- Card Protection Fraud

Password-- Selection Restriction-- Change Cycle-- Complexity

Awareness-- Social Engineering-- Policies

Steal Identity

Steal Customer List

Inside Information

-- Statement Fraud-- Card Protection Fraud

Steal IdentityResell IdentityAccount Fraud

Sell DealingMalicious PostingsInsider Trading

Sell Customer ListSell Customer

Account Fraud-- Steal Identity-- Statement Fraud-- Dormant Account-- Card Protection Fraud



Attack tree summaryDirectly stealing money

Transfer funds – 13 attack methodsAccount fraud – 4 attack methodsDocument fraud – 3 attack methodsExtortion – 5 attack methods

Stealing informationIdentity theft – 2 attack methodsCustomer list theft – 2 attack methodsInsider information – 3 attack methods

Malicious actionsNetwork attack – 8 attack methodsApplication attack – 5 attack methodsDatabase attack – 5 attack methods

Carelessness – 9 attack methodsInadequate policies and procedures – 8 attack methods


Current IT Security Schemes

Security through obscurity4

A few experts have knowledgeOutside connectivity is minimalProblems:

Increasingly interconnected environmenteCommerceDe facto standardization on Windows and Linux

Perimeter defenseControl external access pointsAuthenticate usersProblems5:

Break down of the perimeterMobile workforceDecentralization of servicesIncreasing value of information



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 authorizationLevel 1: workstationsLevel 2: serversLevel 3: network devicesLevel 4: perimeter devicesLevel 5: centralized reporting and control

Problems:Expensive; how much is enough?Still vulnerable to insider attack



PurposeIndentify weaknesses in current mitigation strategies against insidersIndentify where layered strategies could defeat an insiderDetermine where location-based authentication would strengthen security

DesignAssess attack methods versus mitigation strategies

Ranked mitigation on a scale from 0 to 20 provides no protection1 provides some protection but can be circumvented2 provides strong protection

Identified 16 mitigation strategies currently in use


Mitigation Matrix

Identified 16 mitigation strategies currently in useEach organization may use a different subset of these strategies/tools

1. Static password2. Soft token3. Hard token4. One time password5. Challenge – Response6. Biometrics7. Knowledge-based8. Access control9. Anti-virus software10. Network & Application IPS11. Network segmentation12. Change management13. Source code analysis14. Dual physical control15. Content analysis16. Media encryption


Mobile Database Management System (MDS)

A reference architecture of MDS.

BSC

MUBS

MU

MU

BS

MU

PSTN

C1C2

MSC

HLR

Fixed Host

Fixed HostDBS

DB

DBS

DB

BSC

BS

MU

Cn

MSC

VLR

Wireless connectionWired connection


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).


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.


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.


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.


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.


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.



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.



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.



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.

The structure of our ACIDS transaction is as follows:

Under our approach then a transaction requires the support of a protocol similar to concurrency control or recovery to commit.


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.



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



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.



The following figure illustrates SAP operation:

BT

SAPStart

T

Readlock

Lockanalysis

Writelock

Lockanalysis

ET

ETanalysis

Control istransferred to SAP

Commit

Abort

Update user profile, updatelog, increment or decrementSAFE value (SAFE credit)

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.



Similar to Degrees of Isolation (Degree 0, 1, 2, and 3), we have SAFE degree 0, 1, 2, 3; degree 3 being completely malicious-free 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.


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.


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.


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.


Our Location-Based Authentication

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)”.

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.

Location Signature

Our Location-based Authentication


How does Location Signature (LS) Work?

MU

Web Server

Location X1 Street Y1 User ID T1

Location X1 Street Y1 User ID T1 Location X2 Street Y2 User ID T2

Location X1 Street Y1 User ID T1 Location X2 Street Y2 User ID T2Location X3 Street Y3 User ID T3

Location Signature in Log File

XML Request

LSXML Request

LS

XML Request

LS


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.


Epilogue

Thanks for coming and participating in this talk.

Securing Banks from Authorized Users

Documents

Transcript of Securing Banks from Authorized Users