Securing Banks from Authorized Users

1. 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 kumarv@umkc.edu

2. Securing Banks from Authorized Users We assume that users have access to their accounts through mobile database system. We, therefore, discuss security scheme for this setup. Our data processing infrastructure

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

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

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

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

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

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

9. The Insider Attack Tree

10. The Insider Attack Tree

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

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

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

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

15. Mitigation Matrix • Identified 16 mitigation strategies currently in use • Each organization may use a different subset of these strategies/tools • 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

16. Mobile Database Management System (MDS) A reference architecture of MDS.

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

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

19. User Categories • 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. We categorize users as follows:

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

21. Transactions Set • 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. We define the following types of transaction sets:

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

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

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

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

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

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

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

29. SAFE – One of our Fifth element The following figure illustrates SAP operation: 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.

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

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

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

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

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

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

36. 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 XMLRequest LS XMLRequest LS MU

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

38. Epilogue Thanks for coming and participating in this talk.