At many companies, security is not central to their development lifecycle. They often consider security in their applications as part of the QA process, after their software has been fully developed. As a result, engineers and developers end up working reactively, fixing shipped code, instead of treating security as a primary concern.
Hackers, in contrast, are always lurking behind the dark corners of the web, waiting for companies to make mistakes.
When we talk about payment applications, the obvious concern is regarding sensitive information, both from customers and the company itself. But it can also result in unauthorized transactions, financial loss, and industrial espionage. Underestimating the ingenuity and tenacity of hackers may result in incalculable damage for organizations.
By putting security first, companies can anticipate breaches, fix them, and prevent exploits from attackers.
In this article, we’ll talk about payment application security and discuss the security lifecycle, best practices, and technology that enables them.
What is Application Security?
Testing application security involves two main approaches:
- Static Testing
- Dynamic Testing
Each of these techniques analyzes different aspects of an app, so they’re different, yet complementary to each other.
Static application security testing (SAST) is a type of white-box testing to analyze source code against vulnerabilities. It can help remediate situations where unsafe code may lead to unintended code execution. The application data is analyzed for security weaknesses. SAST tests the internal (rather than functional) structure of the application.
Dynamic Application Security Testing (DAST), in contrast, is executed while a program is in execution. It analyzes the application from the outside in by examining it in runtime to discover security vulnerabilities. For example, DAST can assess a web app’s response to simulated attacks, thus identifying vulnerable security points.
Security Vulnerability Categories
Most of the authentication security issues arise when you try to implement your own authentication solution. Just don’t. It is tough to get it right, and you may face many pitfalls ahead, such as failing to enforce password policies and missing two-factor authentication.
Prefer open-source frameworks maintained by active communities and frequently patched against possible new vulnerabilities.
Sensitive Information Exposure arises when applications access sensitive data, particularly unencrypted personal information. In this case, an attacker can perform an injection attack to expose confidential information in plain text. Sensitive data in your systems must always be protected by AES and RSA encryption, both at storage and while on transit.
Broken Access Control vulnerability happens when inconsistent access constraints are applied in different places of an application. The “security through obscurity” approach falsely assumes that resources that remain hidden from most users are safe from potential attackers. Access control vulnerabilities may be avoided by protecting data with multiple layers of defense and tightening access to resources through a single mechanism.
Security misconfiguration issues affect network services, application servers, and storage systems. Some examples include error messages revealing sensitive information, unpatched, or outdated services. You can mitigate application misconfiguration by following a consistent configuration process, and reviewing security notes, updates, and patches.
Cross-Site Scripting (XSS) flaws arise when untrusted user input is executed as part of the HTML, or when users can be influenced to interact with malicious links. Attackers can steal credentials, or deliver malware by performing remote code execution on the user’s machine. Once this security breach is exploited, attackers can succeed in taking over the victim’s account, retrieving web app data, or modifying the content on the web page for malicious purposes.
Components with known vulnerabilities present problems when introduced into an application and run with the same privileges. This vulnerability provides attackers with some of the most feared breaches in the industry, known as Heartbleed and Shellshock. Backdoors in vulnerable components can hand total control of the machine to the attacker.
When application security is carried out as just a tiny part of the testing phase, it means too little thought and effort has been put into creating secure products. Unforeseen vulnerabilities arise and pose an increased threat to private customer data and the probability of data breaches that can be exploited by attackers.
Microsoft helped pioneer some best practices for development teams with the Security Development Lifecycle (SDL). These practices help developers build more secure software by mitigating potential vulnerabilities from the very start of development and at regular points during the development process.
Here’s a brief list of SDL best practices:
- Provide training to ensure everyone follows security best practices.
- Define security requirements to reflect changes in functionality and to the regulatory and threat landscape.
- Define metrics and compliance reporting. Also, define acceptable levels of security and assign team accountability.
- Use threat modeling to identify security vulnerabilities, determine risk, and how to mitigate them.
- Define standard security design for features to be used by engineers. Imagine an attacker is brute-forcing a password on the user login form on your website. Fortunately, the security design had already helped identify potential breaches at your application login process, which was then patched by the development team. The attacker will now be locked out of your website after a given number of failed login attempts.
- Define and Use Cryptography Standards to ensure the right solutions are used to protect data.
- Manage the Security Risk of Using Third-Party Components by keeping an inventory and consistently evaluate reported vulnerabilities. Attackers are happy to hear any announcement of weaknesses within the components your company uses. But thanks to the Secure Software Development Lifecycle (SDLC), your team can follow standardized development procedures, which include upgrading any components to new, secure-patched versions.
- Enforce the use of only Approved Tools throughout your organization.
- Perform SAST and DAST tests to verify the security of both static and running code. Hackers can make use of vulnerability SAST and DAST scanning tools to find breaches in your system. By running these tools early at the verification phase as part of the secure SDLC and fixing vulnerabilities, your company will be ahead of potential attackers.
- Perform penetration testing to uncover potential vulnerabilities resulting from coding errors, system configuration faults, or other operational deployment weaknesses.
- Establish a Standard Incident Response Process to address new threats that can emerge over time.
Security Tools and Payment-Related Technologies
Developing successful and secure projects depends on changing the mindset of the corporation staff and creating a new culture that puts security first. But it also requires specialized technology and tools. Let’s dive into some of the standards tools used these days in payment security:
- 3D Secure (3DS and 3DS2) are fraud prevention standards that add a layer of security in online payments. These standards help prevent fraudulent payments and ensure that only the rightful card owner makes the online payment. This is done by requiring the cardholder to provide a password, an SMS code, and a temporary PIN. 3DS2 also leverages smartphone biometrics capabilities like fingerprint, voice, or facial features.
- 3DS Flex and 3DS Flex Premium are advanced 3D Secure products from WorldPay, featuring detection and issuer monitoring by default. 3DS Flex Premium also offers a dedicated 3DS consultant to help you design your security strategy, and advanced reporting to analyze shopper behaviors.
Besides 3DS standards, let’s briefly discuss some security concepts applied to different aspects and processes of secure payment solutions:
- EMV chip cards. This technology helps merchants protect their business against fraud liability of potential counterfeit schemes.
- Network security. To prevent breaches that compromise sensitive card data, merchants can implement firewalls and segment communication networks.
- Data security. This technique will make the data worthless if stolen. Encryption and tokenization are EMV strategies for a small merchant looking to invest in a POS technology upgrade.
- Physical security. Physical access to the POS should always be limited and secure. Card numbers and other customer information must never be written down.
When it comes to security engineering for businesses, there is too much at stake. In this article, we covered many security tools, techniques, and practices, but you can go further. Making good use of information and action, you can always eliminate or mitigate security risks in your operations.
Small businesses are particularly vulnerable to attackers, but the Small Business Guide to Preventing Data Breaches from WorldPay blog shows us how to deal with these threats. This guide examines why data breaches happen, the implications for businesses like yours, and most importantly how to reduce the risks to your business.
3DS Flex from Worldpay helps increase issuer approvals for transactions controlled by laws and regulations while reducing friction at checkout and improving the shopper experience. Get your free consultation or talk with an Enterprise Specialist today: https://www.fisglobal.com/merchant-solutions-worldpay/large-enterprise-business/get-started
Worldpay offers superior security for merchants and customers alike, helping to reduce fraud and increase genuine transactions.
Article posted by Andrew Harris.
This article was originally published on the FIS Developer Community Blog.