VO for Banking

1. VO for Banking Dmitriy Yanin Kashif Haider Nnaemeka Akabogu Shen-Jung Pai Robert Wambura

2. Introduction • Secure Portal for Multinational Banking • Problem Definition, Virtual Organization • Organization Structure, Business Requirements, Marketing and Customer Support • Integration • Security • Middleware • Infrastructure • Conclusion • Q & A

3. Problem Definition

4. Why VO? • Easy way to organize and communicate • Cost efficient • Teleconferencing, Voice Chat over travelling • Saves Time • Virtual Capability • Easy to Switch geographically

5. Organizational Structure

6. Business Requirements • Transactional Functions • Transfer (private, individual) • Payment (credit card, mobile companies, or public utility companies) • Non- Transactional Functions • View statement • Change their information (usernames, passwords, pin numbers, and email addresses) • Other services (ordering card reader, USB finger print device, and cheque book)

7. Transaction Procedures

8. Login Requirements: NatWest - customer number, pin, and Password Lloyds TSB – Online ID, password, memorable data e-banking portal – user name, password, and Biometrics

9. Marketing & Customer Support • Goal:all or majority of the national banks are willing to corporate– the success depends on the number of cooperated banks and users • Main targets: Banks • Sub-targets: individual customers (achieve customer satisfaction) • Premium services: online assistant and 24-hour telephone banking service

10. Integration • Data Integration • Information Integration • Increase Organization Efficiency • Information Integrity maintenance across multiple Systems • Ease of Development and Scalability Issues • Elimination of Inefficiencies

11. Security • Towards Client Side • Towards Bank Databases • Towards own Database

12. Securing The Web Portal • One of the main concerns of our virtual organization is to provide a robust security solution with limited vulnerabilities. To achieve this, the possible areas of attack were categorized in three perimeters: • Perimeter 1 • Protecting the customer and the web servers. • Perimeter 2 • Preventing unauthorized access to the storage servers on • local VO network. • Perimeter 3 • Securing the data exchange between the VO’s DBMS and • DBMS of the participating banks.

13. SecuringPerimeter 1 • A double factor authentication mechanism incorporating biometrics (fingerprint) and password encryption will be used for user authentication. • Regular updates related to trend of attacks, their features and how to avoid them will be published on the portal. • A security system cluster will be installed at the gateway . This cluster will incorporate an intrusion detection system based on artificial immunity and a web application firewall to provide robust security across the OSI layers. • The cluster framework will also provide constant backup/availability of the security system in event of failure of any of the servers.

14. Securing Perimeter 2 • Security here will be managed by the Extract Transform Load (ETL) tools which oversee the exchange of information between the data warehouse, knowledge base and the network administrators. • Information exchange will be in an encrypted format and classified information and access control levels will be stored in separate tables in the data warehouse.

15. Securing Perimeter 3 • The security of the packet exchange between the portal and the bank will be provided by layer 2 tunneling protocol (L2TP) – a Virtual private network option. This will ensure improved confidentiality, integrity, encryption and authentication of data transferred.

16. Middleware Characteristics Existing IT systems at the participating banks should undergo as little modification as possible. So, the introduced middleware will need to link and work on top of a set of heterogeneous databases across networks. The participating banks would have: • Their own strategies and security policies for handling customer data • Different database management system (DBMS) • Different operating systems (OS) Replacing the above – not possible or requires very high investments and may negate the financial benefits brought by the united e-banking portal.

17. Middleware Characteristics cont…. • Therefore, there is a need for a set of software tools (middleware) that would: • Access the dispersed data • Access the data across WAN • Be non-intrusive, i.e. not access the data directly but via the local DBMSs, honouring the local security policies • Ensure data integrity • Provide secure transmission of data between the banks and the portal • Work with different (heterogeneous) DBMSs and OS’s

18. Data Integration Approach We decide to use Federated approach to data integration. • Data from dispersed sources is kept at those sources, and not duplicated anywhere else • Middleware virtualises the view of the data and acts as a façade to the dispersed data sources • Applications that need access to the data utilize facilities provided by the middleware • Middleware translates requests from these applications, passes them to the data sources, retrieves the returned data, translates and formats it, and passes it back to the applications • Middleware also handles security and networking • Applications using the middleware see it as a local database management system

19. Data Integration Approach cont….. The major advantages of the Federated approach: • Access to the remote databases is transparent to users: • Location Transparency • Invocation Transparency • Physical data independence and fragmentation • Replication Transparency • Network Transparency • No need for data synchronisation • Time-to-market advantage for newly-developed applications • Improved governance • Reduced development and maintenance costs • Reusability

20. Concepts Data-federating middleware utilizes five concepts: • Wrapper • Server • Catalogue • Nickname • User Mapping

21. Wrappers • Software modules within the federated system • Are used to communicate with remote data sources • Contain characteristics about their corresponding data sources, such as their relational models • Are designed to support query processing by sending sub-queries to the data sources.

22. Servers and Catalogues Server: • the representation of a collection of data on the remote data source • must be registered on the system • contains appropriate information about it needs to be stored • includes the name of the database, its type and version All this information is stored in Catalogues

23. Nickname • Is used to access data • Is a representation of a data set, such as a table or a view • When a nickname is registered on the federated system, the name of the corresponding remote table, the names of its columns, their data types, indexes are stored in the catalogues.

24. User Mapping • Controls access to remote data sources • Provides security: • Each remote database has at least one user account with sufficient privileges to access all the data necessary • These user IDs and passwords are stored on the federation system and used for DB transactions

25. Data Integrity Cases when data integrity is under threat: • Data sources going down • Data feeds interrupted because of hardware or network problems • Remote data sources get manipulated or restructured Identifying potential problems and taking corrective actions early. Solutions: • Autonomic features - capability to dynamically adapt to changes in structures. • Two-phase SQL commit - all SQL statements in a transaction spread across more than one remote database are either committed or rolled back as an atomic unit.

26. Communication Use connectors: • software agents installed on top of each remote data source and acting as interfaces • Each connector speaks natively to its corresponding database and passes data to and from it.

27. Communication Connectors used to work on proprietary protocols; however, there has been a shift towards Web Services. The Web Services: • Application components that communicate using open protocols • Self-contained and self-describing and can be used by other applications. • Simple, interoperable, messaging framework • Use XML as data exchange format The main advantages of using the Web Services: • Reduced cost of development and maintenance because of consolidation and standardization of system interfaces • Faster time to market because of the re-usable interface elements

28. SOLUTION

29. Custom-Built Vs Existing Against a custom-built solution: • No real advantage over existing offers • Very lengthy development time • Likely lack of expertise of developers if the system is to be developed in-house • High probability of lengthy debugging due to the software complexity Existing solutions are provided by companies with years of experience of developing the heterogeneous distributed database solutions

30. Major Market Players

31. Choice: IBM Information Integrator Advantages over Sybase offer: • Proper metadata management • Data quality functions • Data profiling/analysis Advantages over Oracle offer: • Company size and worldwide presence • Experience in collaborative software (important for organisations) • Market strategy to promote and support software from other vendors that works with IBM products instead of insisting on using their own software

32. Infrastructure • Networking Based • Towards Client Side • Towards Bank Side • Towards own Database of System • Web Portal Hosting • Single Sign In • Apache as a Web Server • Cluster Management

33. Why Apache? • Apache contains Load Balancer • Avoidance of Single Point of Failure • Load Balancer vs Round Robin DNS • Load Balancer takes care of Load on server nodes • Session Management in Load Balancer • Failure Transparency is practically implementable in Load Balancer over Round Robin DNS

34. Cluster Management • Condor as a Solution • Supports most of platforms like UNIX, Windows, and MAC etc • Best choice for High throughput Computing • Supports MPI and PVM • “DAGman” which supports the functionality to highlight job dependencies

36. Conclusion • Purpose of this online e-Banking is to make transactions • Smoother and Faster • Secure • Commercial Software

37. References • TekPlus Ltd., 2001: The Emergence of Virtual Organisations. A White Paper. http://www.tekplus.com/TP0033R02V01.pdf: accessed on 23/10/08 • McClure, Steve, 2003: Oracle's Solution for Heterogeneous Data Integration. http://www.oracle.com/technology/products/dataint/pdf/idc_integration_wp.pdf: accessed on 24/10/08 • Wikipedia, 2004: Enterprise application integration. http://en.wikipedia.org/wiki/Enterprise_application_integration: accessed on 25/10/08 • H. P. Luhn. "A Business Intelligence System." 1958. IBM Journal. 05 Nov. 2008 <www.research.ibm.com/journal/rd/024/ibmrd0204H.pdf>. • Wüeest, C. (2005). Threats to online banking. In: Symantec security response. Curpertino: Symantec. • Stuttard, D. and Pinto, M. (2008). The web application hacker’s handbook. Discovering and exploiting security flaws. 1st edition. Indianapolis: Wiley publishing Inc. • Greensmith, J., Aickelin, U. and Cayzer, S. (2008). Detecting danger: The dendritic cell algorithm. In: Robust intelligent systems. (A. Schuster ed.) New York: Springer. • Rietta, F. S. (2006). Application layer intrusion detection for SQL injection. In: Association for computer machinery. (1st ed). New York: ACM Press.