Quick viewing(Text Mode)

Security Basics for Financial Applications

Security Basics for Financial Applications

WHITE PAPER

SECURITY BASICS FOR FINANCIAL APPLICATIONS

Abstract is the principal requirement for online financial applications. Data privacy, customer trust, and -term growth all depend on how secure a financial application is. As these applications are accessed from various devices and through numerous channels, financial organizations strive hard to implement a foolproof security system. In this white paper, we will discuss the core security measures that can be considered while building financial applications. We will start with core design concepts for financial applications, move on to the different security techniques and best practices, and finally, provide a basic security design for financial applications. The financial applications referred in this white paper include web applications, financial portals, and other domain-related online applications. Financial applications

Finance applications include applications applications face a host of threats such as the required information aggregation as performing financial transactions such as identity theft, session hijacking, password well. They are integrated with core banking online banking portals, online hacking etc. which has long term impact systems or finance enterprise applications, applications and such for which security is on revenue and user trust. to provide domain-specific features. a prime concern. Most of the e-commerce Additionally, they also offer a wide range of Online financial applications provide a and applications invariably deal personalization and customization features variety of features, such as dashboard with payment transactions and hence that enable finance organizations to launch views, reports, personalized customer security would be an important feature of personalized campaigns and features for pages, and for particular financial domains, these applications as well. Online finance targeted segments.

Core security concerns of financial applications

The key security aspects in financial authorization, data encryption, transport- permission models, data privacy and applications include secure authentication, level security, role-based access and robust integrity, and security extensions.

Key security vulnerabilities and ways to tackle them

Based on our experience in financial Man-in-the-middle attacks and details to initiate a financial transaction. applications, we have created a list of the session hijacking An effective way to prevent this attack is common security challenges, the details of to use a security token with each request In this kind of attack, the hacker may that is validated on the server-side. We will security vulnerabilities, and the effective intercept traffic between the requestor learn more about this technique and its measures to address them: and the finance portal. The first step in implementation in the following pages. Multiple sessions preventing such an attack is to use a secure transport layer, such as HTTPS, for Injection attacks Financial applications usually do not allow all secure interactions. The rule applies for The attacker can use SQL injection multiple sessions due to security and data- finance services as well. In addition to this, techniques to gain information access. The integrity concerns. Using a combination of we must encrypt secured data (such as user vulnerability can be exploited by appending the following approaches should restrict information, finance information) during SQL keywords and comments (such as these multiple sessions: transit, and decrypt before rendering to appending ‘1=1’ to the query string). the client. • Create session filters to intercept every In to effectively mitigate this, we user request, and use a database- Request spoofing and cross-site need to: driven table to check the multiple request forgery (CSRF) session information, in order to restrict Validate all user input on the client as In such a vulnerability, the attacker may • the user sessions based on the session well as the server-side and maintain a send a forged request to the server. data blacklist of characters for this validation The attacker can gain access to request • Restricting the user sessions at the parameters using techniques such as • Encode or remove HTML and SQL- server side: Server modules (such as snooping, and can then construct an reserved characters core banking modules) keep track of attack-script to make the portal believe Use prepared statements instead user that the request is coming from a genuine • of direct SQL commands in the source. For instance, if the attacker obtains Combining these two approaches allows a application. Use object-relational the session ID or is able to intercept the truly single session-based implementation. mapping (ORM) tools, such as request, he / she can use the session Hibernate,for database interactions

External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited Key security features of online finance applications

Besides core security features such as Nonrepudiation occurs based on the Endpoint security refers to protecting the authentication, authorization, single- following two criteria– The user is the endpoint device to comply with anti- sign-on, session management, account legitimate identity that sent the content/ malware and virus protection to prevent, management, financial application should performed the transaction;the content/ detect, and remediate any malicious also deal with other security such as follows: transaction details are not modified in programming on the system. This helps the middle, as data integrity is ensured in restricting any malicious program that Federated identity and access through a hashing algorithm. might be tracking keystrokes to obtain management sensitive information. Crypto libraries The identity and access management Virtual keyboards help in reducing the risk Crypto libraries are the cryptographic can be federated across the domain, and of key loggers logging keystrokes, as the libraries used in Internet standards to the same identity store and access clicks happen only on the virtual keyboard provide encryption algorithms. manager for all user groups. This strategy to input the data. This also makes it more works best in subsidiaries and acquired The functionality includes key generation difficult for malware programs to track the entities. algorithms, key exchange agreements, and clicks and obtain the input data. However, there is a possibility that the malware Strong nonrepudiation using DS public-key cryptographic standards. For finance applications, it is recommended to can take screenshots upon each click and Nonrepudiation means that a party cannot use a salted password-hashing algorithm hence, the endpoint should be secure and deny the authenticity of their signature as discussed below. updated with respect to anti-malware upon the sending of a message. programs as well. Endpoint security – Anti-malware / In the digital world, nonrepudiation can virtual keyboards. be achieved through digital signatures.

Financial application key design considerations

Listed below are some of the key design • Adoption of services-oriented iteratively to ensure that the aspects that need to be kept in mind while architecture for integration – An ESB desired performance service-level developing finance applications. These middleware can be used to handle agreement (SLA) is met complex and multiple services and are additional design factors along with Scalability can be achieved by enable service-oriented integration security. using the appropriate infrastructure between different banking systems and hardware • Open standards-based technology Leveraging open-source technologies and integrations – This includes using wherever applicable Incorporation of a governance standards related to HTML, CSS, and model to proactively check the Continuous build and integration accessibility to name a few • heartbeat of the systems to ensure approach for execution –Tools such as system availability and uptime • Layered architecture using MVC Jenkins Continuous Integration can be pattern – This provides a clear layer- used to maintain build quality • Reusability and automation: Reusing wise separation of components the existing components and Performance, availability, and with each layer handling a distinct • frameworks will profoundly impact scalability –Performance should responsibility. MVC enables loose developer productivity, faster time- be thought through, right from coupling, separation of concerns, and to-, and significantly increase the component design to the flexibility to change the components in the overall quality. Based on the given performance testing stage. In addition each layer independently requirements, the following to performance-based design, other components are marked for reuse, • Modular and extensible component performance optimization techniques partially/completely: design –Each of the solution can be adopted, including: components will be designed such that High Level architecture of finance it can be reused for future needs The solution will also be tested applications

External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited A high level overview of a sample finance web application is shown below:

Support, Management Client Application Content Information, Widgets Widgets Governance, Presentation Common & Layer Server Security Presentation Content Services Publishing Services Users & Roles REST

Authentication Business Process Rules Processes Process Layer Orchestration

Authorization

Single Sign On Service Mediation Adaptors Transformation Validation Routing (ESB)

Con guration

Logging Business Service Business Services Service Aggregation Layer

Caching

Exception Integration Data Access Components Service Gateways Handling Layer

User Store Database Data File System Services Services 1 Services 2 Services 3 Sources

A typical, n-tier MVC architecture here. Presentation layer consists of financial be used for service mediation and to for finance applications has various widgets, portlet, reports, and handle handle concerns such as routing, protocol components, with MVC architecture other presentation concerns. Business transformation, validation etc. Business providing separation of concerns for the layer processes business logic, rules and layer exposes various business services and various layers. Service-oriented integration business processes. Typically a message integration layer integrates with necessary is the de-facto standard for integration oriented middleware such as ESB would enterprise interfaces.

The different security aspects of financial applications

After having discussed core security Here, we provide comprehensive coverage security issues. Let us start by looking at concerns, let us deep-dive into the other of security techniques and proven core security features required in a typical security aspects of financial applications. methodologies to effectively address financial application:

External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited Authentication

Authentication is all about allowing a enough for a typical banking or financial authentication mechanism should not stop user to login based on a username and application? at validating the user credentials. So what credentials. However, would that be In banking applications, the primary else would be required?

Password policy

Let us go with an encryption algorithm to encrypted value. Thus, it is easy to maintain What is the solution now? encrypt and store the password. SHA, MD5 a lookup table of all possible combination Salted Password Hashing are some of the encryption algorithms of passwords. In some cases, if not most, that generate an encrypted password of the user’s password will be one of a Salted password hashing algorithms– these the user and store them in the database. dictionary word. Hackers can thus create a algorithms, such as the BCrypt Password We all agree that it will never be possible lookup table for each dictionary word with Encoder, generate different encryption to decrypt the encrypted password from a mapping encrypted password. If they values for the same password input. How these secure encryption algorithms, but gain access to the encrypted password, is it possible? For every password, the hackers will not try the obvious. Would they can easily crack the password using algorithm generates a random ‘salt’ that is they? They would try to identify any this lookup table. inserted to the original password before loopholes in these secure encryption it is encrypted. Thus, different encryption Although this vulnerability can be limited algorithms and exploit them instead. The values are generated for the same to a certain extent, by introducing stronger authentication mechanism should thus password input, and lookup tables can password policies that restrict the use of be foolproof against brute force attacks. If never be created for such algorithms. The direct dictionary words. Hackers have gone you wonder what brute force attack is, it salt is embedded along with the encrypted a step further already– they have begun to is a trial-and-error method used by hacker value, and only the algorithms themselves suffix, prefix, or insert the possible special application programs to decode encrypted can gain access to the salt, and validate the characters, numeric values, as well as the data such as passwords. supplied password. And these can never be appropriate casing around it. They are thus decrypted. For the same password input, these able to create the lookup table regardless. encryption algorithms generate the same

Request identification Banking applications need to go that one- request is allowed, and another Request ID • Sophisticated attacks like CSRF (Cross step extra – they should also authenticate is generated and sent to the portal client, Site Request Forgery) can also be each request and authenticate the request which also stores the new unique identifier prevented using Request IDs even after post-login. This will prevent any in server cache or persistence storage. Once again, browser refresh is not session hijack. Now how is this achieved? This process repeats for every request, • possible, and a user cannot resubmit enhancing the security measures at each Immediately after validating user the same request, as the valid unique step. credentials, a unique identifier (let us call identifier cannot be supplied to the it a Request ID) can be generated and • Session hijacking is not possible as server for validating the request mapped to the customer ID in the server every request needs to have the Simultaneous sessions can be cache or persistence storage. The same Request ID,which the server expects • prevented in the same way, as the new value would be returned to the portal from the portal client session cannot provide the Request client, which would be appended to this The refresh, back, and forward ID the server expects – thus, no new Request ID for the subsequent requests. • navigation within the history is not session can be established. If security The request filter would then validate possible on browsers as the session is highly critical, both simultaneous the Request ID sent by client, against the is destroyed when a valid unique session can be destroyed, prompting unique identifier stored in the server cache identifier cannot be supplied to the users to authenticate themselves again or persistence storage. If they match the server for validating the request

External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited A sample secure user-registration and user-authentication flow is shown in the following diagram:

or successful assord encoded it tore te salted as e ser reistration user is crytassord Encoder assord in dataase eistration ased to set roides salt on to of e salted as assord u assord ased assord can neer e decryted

alidate te assord aainst enerate ecure es andom ID tore te ID in Loin te encoded serer cace crytassord in If exists reenerate dataase o Deny ccess end uuid as reuest aram

useuent ae alidate reuest uid access Initiatin alidate te ID in is same as serer uid transaction te reuest for te customer

eenerate anoter E alidation ID and store in te serer cace end uuid as reuest aram

LE useuent ae Deny ccess access Initiatin transaction lo eeats

Authorization Authorization implements fine-grained request to access the application is • Access privileges to internal resources access control by providing role-based allowed only if the user has privileges within the application can be access to resources (such as functions, maintained within the application Identity Governance Administration pages, and widgets). • database itself can be used to govern the degree of • Access manager acts as a centralized access each identity (user) has to each control center to enforce all aspect / module of the application authorization policies and rules • The application can be integrated with • Once the authorization policies are the access manager to check for user defined in the access manager, the privileges

External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited Identity and Access Management (IDAM)

• The finance application can be configured in the IDAM using two table, and be able to create or integrated with the identity and access approaches: update the users in the table. management application to enable Integrating the application with the • All security aspects to access the user single sign-on, as well as role-based user store authentication provider management API or user database access should be established to ensure Where productized solutions identity management is secure • Identity Management: For a newly adopted for the finance application joined employee, the identity can be depend on a user table in the • Fine-grained access management: The created through IDAM, and the thus- database for all their operations, application has greater control on the created user would flow to the user we have two additional options to internal resources each user can access. store. A random password can also be achieve the goal: pushed through IDAM to the user store. How can an IDAM provide this If security is the primary concern, then • API access: The user can be kind of fine-grained access half of the password can be sent to his created in the application management? reporting manager, and the remaining using the API call from the It can be achieved by updating the half to the HR manager. The new IDAM. For this to be feasible, user and role-mapping table of the employee can collect the password the application should expose application either via API, or directly in fragments from both, login to the an API, through which the user the database table from the IDAM. As corporate system, and then be required table can be updated mentioned earlier, all security aspects to change the password • Database access: IDAM would for accessing the API or the database • Application Access Management: The have to access a database view, should be established to ensure access provided to each user can be with write access to the users identity management security

Single sign-on (SSO)

Banking application can have several access manager generates the SSO token the SSO token is authenticated and the internal applications that are managed by and sends it to the client browser cookie. user has the right privileges, the access internal users. If the user has the privilege The SSO token then remains in the browser manager provides access to the application to access these applications, single sign-on cookie and enables the user to login to seamlessly. becomes a handy as he/she does other applications seamlessly. The authorization policies would also not have to enter separate credentials for Additionally, a webserver security plug-in be defined in the access manager and accessing each application. can be installed on the webserver, which the request to access other application When the user logs into one of the will intercept the request and redirect the would be allowed only if the user has the applications, the user credentials can be user to the login page if the SSO token privilege. A sample SSO flow is shown in sent to the access manager, which will parameter is absent in the request. If following diagram: verify the credentials from the user identity the SSO token exists, it will be passed to store. After validating the credentials, the the access manager for validation. Once

External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited eateay

lication eateay Is oen es L Intercets euest aailale

o

ccess anaer

et ser Identity Loin alidate credentials credentials tore

enerate oen and store in roser cooie

Launc te alidate alication credentials

Deny ccess

Two-factor authentication is needed to calls the OTP server through an ESB that have already been setup by the step up the primary authentication along service call .The OTP server then user. Once the security answers are with a supplementary authentication for connects with the SMS gateway validated, the transaction is allowed to financially critical operations. In some to send the generated OTP to the proceed. cases, the regulatory body makes two- customer’s device. Once the customer Hard tokens – When the transaction factor authentication mandatory for enters the OTP, it is validated again by • is initiated, the application prompts transactions such as fund transfers. the application through a service call for a token number generated on to the OTP server via the ESB. Once the Two-factor authentication can be the hard token held by the user. The OTP is authenticated, the transaction is implemented with any fool-proof token is authenticated and then the allowed to proceed. mechanism, such as - user is allowed to proceed with the Security questions – When the transaction. One-Time Password (OTP) – When the • • transaction is initiated, the application transaction is initiated, the application prompts few security questions

External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited Alerts and notification

Alerts and notifications are also a key The alert mechanism ensures that the The notification mechanism keeps the part of the security measures that customer remains informed of all the customer informed of future events that take. In case of a fund transfer, beneficiary critical events that can have a financial may require some action to be taken. For addition, modification, or deletion, the impact, such as beneficiary addition, example, a password expiry notification customer should be alerted through SMS fund transfer, change password/security or renewal notification, through SMS or and Email. Generally, banks provide a questions and answers, and eDemand Email, can keep the customer informed and cooling period to perform a fund transfer, draft. This can help the customer react prepared to act. when a beneficiary is added. The user can quickly if the account is compromised in perform a fund transfer only after this any way – for example, a lost ATM card or cooling period. an unauthorized swipe.

External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited About the Authors

Shailesh Kumar Shivakumar Infosys

Shailesh Kumar Shivakumar has over 14 years of experience. He currently works as a Senior Technology Architect at Digital Practice in Infosys Technologies. His areas of expertise includeEnterprise Java technologies, portal technologies, web technologies, and performance . He has published two books related to enterprise web architecture,enterprise portals, and UXP and has four patent applications. He has published several papers and presented talks in IEEE conferences in the areas of web technologies and performance engineering. He has successfully lead several large-scale enterprise engagements for Fortune 500 clients.

Babu Krishnamurthy Infosys

Babu Krishnamurthy has over 11 years of industry experience. He currently works as a Technology Architect at Digital Practice in Infosys Technologies. His domain expertise includesbanking, ecommerce, and networking. His areas of expertise in technology include Enterprise Java technologies, portal technologies, eCommerce technologies, and web technologies.

or more information contact asusinfosyscom

© 2018 Infosys Limited enaluru India ll its esered Infosys eliees te information in tis document is accurate as of its ulication date suc information is suect to cane itout notice Infosys acnoledes te rorietary rits of oter comanies to te trademars roduct names and suc oter intellectual roerty rits mentioned in tis document Excet as exressly ermitted neiter tis documentation nor any art of it may e reroduced stored in a retrieal system or transmitted in any form or y any means electronic mecanical rintin otocoyin recordin or oterise itout te rior ermission of Infosys Limited and or any named intellectual roerty rits olders under tis document

Infosyscom E I tay onnected