How Secure Is Your Online Banking App?
When it comes to developing applications that handle such sensitive information, making sure security is baked into every step of the SDLC is crucial.
Join the DZone community and get the full member experience.Join For Free
Banking has gone digital. Nearly every major bank offers both an online portal as well as a mobile app, and people seem to prefer it that way. A recent PwC survey found that 46% of consumers only use online banking, a massive jump from their previous survey in 2012, in which only 27% used online banking exclusively.
For banks and other financial institutions, offering an online app that allows either online or mobile banking access is now a necessity when looking at those numbers. Users crave the convenience that comes with banking on the go, and while the advantages that come with being able to perform personal banking on your mobile or computer is undeniable, another question still persists: Just how secure are these online banking apps?
Research that was released at the end of 2017 may offer an answer to that question. The research, carried out at the University of Birmingham, found security issues in mobile banking apps that could leave millions of their users open to attacks. The main issue they found pertains to a flaw in certificate pinning, which meant that tests were failing to detect "a serious vulnerability that could let attackers take control of a victim's online banking," The Register said.
It's security issues like this that show just how important it is to cover all your bases when developing digital banking apps. While digital banking can help foster new connections and offer new and innovative services, thus bringing more gains for financial institutions, digital banking also carries plenty of risk.
7 Critical Steps for Banking App Developers
While consumers carry a burden of security that includes using secure wifi to access their banking app, locking their devices when not using them, using a unique password, and not using public computers to access their accounts, the main burden of ensuring customers' security is on the banks. Or rather, the developers and teams working on the applications.
Developing an SDLC, or software development lifecycle, is vital to the continued development of secure applications. The SDLC will put in place a strategy for making sure security is built into the product, without slowing the development process down. Here are seven critical steps in the SDLC that developers and security teams should work together on to ensure the release of a secure online or mobile banking app.
1. Establish Security Requirements
The first step is to understand the security requirements of the banking app. Because of the sensitive nature of banking apps, it is important to assign at least one member of the security team to work with the build team - and this partnership needs to begin before development does.
During this part of the SDLC, development and security should identify the key security risks within the software, including what standards (both organizational and legal/regulatory) the software must follow. Stakeholders from both development and security teams should be identified to make sure communication is clear from the outset, and any gaps in the process should be noted. Only once security requirements have been established and agreed upon by all parties can development begin.
2. Analyze the Attack Surface
Any banking software will come with areas of risk, referred to as your attack surface. The attack surface, OWASP writes, is compiled of:
- The sum of all paths for data/commands into and out of the application.
- The code that protects these paths.
- All valuable data used in the application, including secrets and keys, intellectual property, critical business data, personal data, and PII.
- The code that protects these data.
Various organizations have come up with methods for quantifying the attack surface: Microsoft's Michael Howard has designed a Relative Attack Surface Quotient, and researchers at Carnegie Mellon have created the Attack Surface Metric. It may be helpful to start by using one of these methods while creating one that works best for your organization.
Analyzing the attack surface is a complex yet crucial part of securing any application because it pinpoints the most critical and potentially vulnerable areas of the code to ensure they're properly secured during development and testing.
For more on analyzing the attack surface, check out OWASP's cheat sheet.
3. Implement Threat Modeling
The next step in the secure SDLC is to perform threat modeling. Threat modeling helps developers understand which security controls are required for the app to further ensure security is built in from the start. The threat modeling process involves defining which assets and resources need to be protected, the entry and access points at which these assets and resources could be obtained, along with the development of mitigation strategies for each threat once they've been prioritized.
Go deeper in threat modeling with OWASP's dedicated cheat sheet.
The relationship between threat modeling and attack surface analysis is a close one, and this means that any changes to the attack surface will require threat modeling, and that threat modeling helps stakeholders better understand the attack surface.
4. Perform Static Analysis Security Testing
Continue reading with our Beginner's Guide to Security Testing in the SDLC
At its most basic, Static Analysis Security Testing, or SAST, tests the source code of an application to detect critical vulnerabilities. Advanced SAST tools do this automatically, securing the code from the root, and can be implemented in the initial stages of the development process. SAST testing is an important part of the SDLC because it detects flaws well before the application goes into production, meaning bugs can be found and fixed where it's both easiest and cheapest to do so. SAST works by pointing developers to specific areas in the code where issues are present.
Interested in learning more about IAST? Check out our webinar "What About IAST?"
In addition to detecting vulnerabilities included in the OWASP Top 10 and well beyond, SAST also checks code for compatibility issues related to legal and regulatory standards including PCI-DSS, which many banks are required to comply with.
5. Perform Interactive Application Security Testing
Whereas SAST interacts with code, IAST, the next step in the Secure SDLC, tests a live version of the software. In essence, whereas SAST is a security person ensuring secure code, IAST is a hacker, working to get access to areas in the app it's not supposed to be able to. IAST does not require a deep understanding of the application, only looking at it as if it is vulnerable and how that vulnerability may be exploited.
Using a mix of static and dynamic security testing is the best way to ensure vulnerabilities are wiped out of the code and application before it goes live. Especially for more sensitive applications like banking software, this combination is crucial for reducing vulnerabilities and the risk of attack to as low as possible.
6. Create Security Gates
Perhaps the most important part of the SDLC is to make sure software with medium or high vulnerability flaws doesn't make it to production. Microsoft's SDL process refers to security gates as 'bug bars,' but the idea is the same. Security gates establish a minimum level of security, and code is checked for high-risk vulnerabilities. Any code marked as high-risk should be sent back to developers to implement a fix. These checks are best performed while still in development using static analysis testing, as a platform like CxSAST can automatically detect these vulnerabilities while developers are still writing the code to help them fix it at the source.
It is essential that once security gates are established, they are not broken, no matter how close to release the app is: A medium- or high-risk vulnerability should never be allowed to go into production, and the security gate helps define what those are and what to do when they're discovered.
Read more about raising your developers' security awareness.
7. Introduce Ongoing Secure Development Education
While not a part of the traditional SDLC, developer education is a part of the Secure SDLC. Developer training is quickly gaining ground in secure development organizations because of its effectiveness in turning developers who know little to nothing about security into secure developers who consider security at every turn.
Especially in a highly sensitive environment like a banking app, having developers who understand the security process will go far in more quickly releasing secure software.
Any modern application now demands a much higher level of security awareness than it once did. Customers want to be able to do everything on their phones and computers, and that requires more thought into how we secure our organizations and our customers. When it comes to digital banking, those considerations are even greater, requiring strong planning and execution in order to maintain a high level of security. With a secure SDLC leading the way, banking apps can be released securely, giving customers a high level of confidence in your organization and software.
Published at DZone with permission of Sarah Vonnegut, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.