Presentation is loading. Please wait.

Presentation is loading. Please wait.

Vijay KumarSecuring Banks from Authorized Users Vijay Kumar Computer Science and Informatics School of Computing and Engineering University of Missouri-Kansas.

Similar presentations


Presentation on theme: "Vijay KumarSecuring Banks from Authorized Users Vijay Kumar Computer Science and Informatics School of Computing and Engineering University of Missouri-Kansas."— Presentation transcript:

1 Vijay KumarSecuring 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

2 Vijay KumarSecuring 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.

3 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users Some Facts 646 data breaches in 2008, a 47% increase from 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 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 Vijay KumarSecuring Banks from Authorized Users 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 % 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 Vijay KumarSecuring Banks from Authorized Users The Insider (authorized user) Threat Is it easy to identify potential insider threats? No common profile 7 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 security 7 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users The Insider Attack Tree

10 Vijay KumarSecuring Banks from Authorized Users The Insider Attack Tree

11 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users Current IT Security Schemes Security through obscurity 4 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 Problems 5 : Break down of the perimeter Mobile workforce Decentralization of services Increasing value of information

13 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users Mitigation Matrix Identified 16 mitigation strategies currently in use Each organization may use a different subset of these strategies/tools 1.Static password 2.Soft token 3.Hard token 4.One time password 5.Challenge – Response 6.Biometrics 7.Knowledge-based 8.Access control 9.Anti-virus software 10.Network & Application IPS 11.Network segmentation 12.Change management 13.Source code analysis 14.Dual physical control 15.Content analysis 16.Media encryption

16 Vijay KumarSecuring Banks from Authorized Users Mobile Database Management System (MDS) A reference architecture of MDS.

17 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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.

20 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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.

22 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 = {c 1, c 2, …, c n }; where c i is a set of constraints. U = {u 1, u 2, …, u m }; where u i is a set of authorized users. For each u i (1  i  m) define P i where P i = {c|c  C and u i possess} I = {D 1, D 2, …, D k } where D i 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 Vijay KumarSecuring Banks from Authorized Users Malicious Transactions Define relation R Authorization U  I. So u i R D j if P i  D j 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 Vijay KumarSecuring Banks from Authorized Users Malicious Transactions 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.

26 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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, e j, 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 (T i ) =, where F i = {e i1,..., e in } is a set of execution fragments, L i = {l i1,..., l in } is a set of locations, and FLM i = flm i1,..., flm in } is a set of fragment location mappings, where  j, flm ij (e ij )=l ij. In addition,  j, k, l ij <> l ik.

32 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users 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

35 Vijay KumarSecuring Banks from Authorized Users 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

36 Vijay KumarSecuring Banks from Authorized Users How does Location Signature (LS) Work? MU Web Server 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 T2 Location X3 Street Y3 User ID T3 Location Signature in Log File XML Request LS XML Request LS XML Request LS

37 Vijay KumarSecuring Banks from Authorized Users 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 Vijay KumarSecuring Banks from Authorized Users Epilogue Thanks for coming and participating in this talk.


Download ppt "Vijay KumarSecuring Banks from Authorized Users Vijay Kumar Computer Science and Informatics School of Computing and Engineering University of Missouri-Kansas."

Similar presentations


Ads by Google