12 Best Practices for Application Data Security

Building a robust and secure application is non-negotiable for any financial services firm because the industry has stringent regulations that mandate how these applications should be built and operated. Today's financial applications are accessed online using various devices by customers, internal staff and third-party vendors. They are integrated with multiple internal and external systems using API's. The application security landscape constantly evolves due to this highly complex environment with new threats.

To build robust and secure applications, financial services firms must have proper tools, processes, and design principles. However, this is not easy as security has multiple dimensions covering the application's build and runtime aspects; These include infrastructure architecture, operations, physical environment access, application design, governance & controls, cyber security and data security. This article explores twelve basic guidelines for designing a secured application.

#1 Implementation of Identify and Access Management Solution (IAM)

Top-tier financial services firms have their application integrated with a solid IAM solution. IAM systems provide robust identity protection by requiring users to log in with a username, password, and other information. They are a method for regulating and monitoring access to the company's resources. Security across all digital assets is one of its primary features; this includes managing client IDs and passwords, integrating third-party applications, and more.

#2 Access Control & Password Management

A good security design must implement robust access control and password management framework which implements industry standards and meets the regulatory expectation. It should enforce password policies that force users to set stringent passwords and reset passwords beyond certain days. They should be policy-driven and implements controls such as user id length, ID revocation on a certain number of failed attempts, and auto logoff when a session is inactive for a certain period. The user management module must have provisions to generate various audit and security control reports, such as activity logs, inactive user lists etc. and have the ability to disable unused ID's beyond a certain number of days. Basic user management features must include:

• Managing users.
• Assigning them to groups based on their job roles.
• Setting user limits.
• Monitoring user activities and generating security matrix and access reports.

 

#3 Audit Logs

A financial services application must provide detailed audit logs covering the application and system logs across all business and infrastructure components. Audit activities must log every critical operation performed, such as system maintenance, setup and configuration changes etc. All audit logs must be stamped with sufficient information to link to the event, such as the date, time, operation performed, user details etc. The records must comply with the data retention policy governed by the companies / regulatory policies.

#4 Additional Controls & Multifactor Authentication

Security involves safeguarding against any system compromise, phishing or man-in-the-middle attacks. Top banks have used security design techniques such as biometric login, multifactor authentication, security phrase and security image, device binding, and geolocation fencing.

• Biometric Enabled Login: To use biometric authentication, a user must register for the bank's service and link an existing fingerprint or facial recognition to their online banking account.
• Multifactor Authentication: Banks use a security feature requiring the user to supply more than one piece of information before gaining access to an account. It consists of something you know (password), something you have (security token), and something you are (biometric authentication) (your fingerprint).
• Security Phrase: Numerous banks utilise a security phrase to authenticate. For instance, the bank could require the customer to enter/confirm the word "bank" or "safe" followed by the bank's password before allowing login.
• Geolocation Fencing: An example of geolocation-based control would be generating a security alert when a user attempts to log in from a location other than their normal one. For instance, a Malaysian user who suddenly logs in from Canada could trigger an alert requesting the second verification level.

 

#5 High-Risk Transactions

When a high-risk transaction or event occurs, such as when a customer's data is modified or a large money transfer, good financial services apps increase their security requirements. The second factor may be an OTP, biometric authorisation, In-App approval, or Soft Token Authenticators. Identifying and combining Approval, One-Time Password, and Soft Token Authenticators should be a top priority for businesses. Users must be able to authorise an event or transaction before its occurrence. Every country's regulators have specific guidelines around what is considered a high-risk transaction; some examples are below:

1. Transfer above a certain amount threshold
2. Adding a new beneficiary
3. Change in card settings
4. Third-Party fund transfer

Financial services applications expect to give their customers the flexibility to configure some of the risk settings based on their requirements example, a customer could higher or lower the transaction limit to what they think is best for this purpose. Good security design provides users with precise transaction details when requesting authentication rather than generic messages.

#6 Threat Detection Solutions (TDS)

Online threat detection systems are essential components of any organisation's defence system. They lessen the attack's impact by taking pre-emptive measures to limit additional damage. Applications must integrate TDS solutions into their customer journeys. The advantages include:

• Detecting sophisticated dangers before they can materialise
• Identifying specific attacks and their origin
• Automatically detecting data exfiltration operations within the organisation's network.
• Maintain tactical control over the operational area (AO) and mitigate collateral damage.

#7 Tightening the Processes

A secure application leverages automation across the development cycle for testing, deployment, code quality, version control and change management. Developers must understand the significance of making their systems as secure as feasible and adhering to industry standards to meet compliance requirements with various security concerns. Among these specifications are OWASP, PCI, etc. As a good practice, any code change must be reviewed and comply with coding standards. Development teams must perform regular application vulnerability assessments to detect existing and novel methods through which hackers or fraudsters can exploit security flaws. The application developers and client technology teams must regularly perform security audits to check for outdated or end-of-life system software to identify and apply the latest patches before any security threats become a liability for the company.

#8 Data Security Design Principles

Application security, data security, and privacy must be integral components of the architecture of a financial application. Development teams must apply the concepts of data consent, minimisation, accuracy, and storage. An application based on these principles will assure compliance with the regulatory requirements of most markets; the design must consider the end-right users to know and grant permissions regarding the data gathered and the intended purpose or process using the data. The application must delete data from all storage once it is no longer in need beyond its original intended purpose.

#9 Design for Trust

The design should prioritise gathering only the essential data and include the processes necessary to maintain data consistency and accuracy. The design must allow users to opt-in or opt-out of aspects, such as marketing, data sharing with third parties, etc., and share data with internal staff or third parties on a need-to-know basis.

#10 Runtime security risks

Some of the leading institutions employ RASP security to safeguard their applications. The application's architecture must incorporate tamper detection techniques to detect unauthorised code modifications. These solutions are required to protect against harmful changes to the application's code, which could result in data leaks, privacy violations, or unauthorised software modifications. The application must not record any sensitive data as part of any logs generated during runtime.

#11 API Security

Application Programming Interface (API) is one of the most critical components of an application's design. API security is a strong and thorough process encompassing technical and non-technical factors, such as identifying all interfaces that need to be secured, determining the right level of security for each interface, and providing authentication and authorisation mechanisms.

#12 Data Retention, Encryption & Masking

The application design must delete data after the required retention term or when they are no longer required. The application must utilise powerful encryption techniques, such as AES 256-bit ciphers, to encrypt data at rest and in transit. The design must incorporate data masking for sensitive fields and display unmasked data only when necessary and according to the user's profile. Design must adhere to the principle of least data disclosure to the greatest extent possible and use algorithms to reduce data revelation via default settings, particularly when the application has backend modules used directly by operational employees. The application must implement industry-standard encryption algorithms, authentication, hashing algorithms and digital signature. All cryptographic keys must be managed robustly through the entire lifecycle, from generation to destruction.

The above are the twelve basic application and data security guidelines that should meet the expectation of regulators in most countries. The purpose of this article was to share some of the application and data security principles based on experience. There is so much happening in the security world, and the applications continuously adapt to new security design patterns and frameworks beyond what this article covers. Please share your perspective and experience, and feel free to add to the list.