Secure software development and threat modeling approaches for Financial Technology (FinTech)

Developing secure software in one of the most secure and regulated industries in cyberspace

Working through threat modeling and a secured software development life cycle (SSDLC) plan, for Cybersecurity Architecture this past week allowed me to describe how SSDLC or security development lifecycle (SDL) can lead to implementing software in a more secure fashion. The frequency of data breaches, spoofing, and privilege escalation that occurs day to day has increased, seemingly at the rate that software has been developed.

There is no shortage of businesses looking to automate and increases their daily task offloading to software and automated systems that can reach across the globe. In the demand for software engineers and technological dependance brought on by consumers, there is also a wide range of coding skills, looking to take on the work as a career. If not through in-house, learning on the job code work, even if not the low price and speedy delivery coders from anywhere, there is still a risk to the most professional coding environments and their developers code.

A future state of mind for a zero-trust model of threats on the horizon

As cybersecurity teams take on the process of advancing applications and infrastructure to develop the latest software enhancements, it is important to create processes for the team, identified through application and industry specific planning sessions. The methods to the approach fits into an evolving set of principles that are structured to advance the methods of software development. In the ever-changing threat landscape. When developing software and information technology every team must prepare for threats from the beginning.

In an approach to architect infrastructure and harden the software utilized by a financial technology firm, the team plans to following SSDLC. SSDLC is a framework for developing secure software, a set of processes and activities to follow that ensure the software is developed with security in mind. The SDDLC framework includes a series of steps as follows --- planning, requirements and analysis, design and prototyping, development, deployment, and maintenance to validate each procedure along the way.

When analysis and preparing a threat model diagram, you can see the various actors, the boundaries, and sensitive information stores which provide integration and long-term memory to the software for the financial services application. The team should plan a series of controls that limits the reach of any one user other than administrators of the system, layering the infrastructure for defense, while also applying best practices in data validation and sanitization for assuring quality information. In this consideration, the Payment Card Industry Data Security Standard (PCI DSS) requires the team to work with the card vendor to handle inbound request and outbound responses for limiting any systems interaction with payment information.

Achieving secure by design principles through each step of the SSDLC:

1. Incorporating least privilege to each of these considerations as a zero-trust model for devising customer, employee, manager, and administrator privileges can enable a separation of duties. Through a divided responsibility matrix, including the shared responsibility mode, the content of the customers is protected. The actions of the employees should only visible upon confirmation, and the managers have direct access to the system, but indirect access to the data, which is the responsibility of the administrators to oversee.
2. Infrastructure, layered with boundaries and integrations can segment the network, data, and operational activities, leaving it out of reach of the public and in most cases, the employees to limit bias or misuse through access to Personally Identifiable Information (PII) or Sensitive Personally Identifiable Information (SPII). In the creation of a threat model and planning the team can recognized the importance of this data and the volume in which this application will intake and store. As a very secure and audited industry, it is beneficial to detect intrusions throughout the application with layered security. Tools like the Microsoft Threat Modeling Tool and OWASP Threat Dragon will be used to document these considerations and ahead of time remediations.
3. Enabling data validation and sanitization is integrated through the form-based UI components with libraries for informing the user of defective information and monitored by intrusion detection systems. The form integrations can monitor for Cross Site Scripting (XSS) attacks with the addition of the Web Application Firewall (WAF) for SQL injection and dynamic code manipulation. The user-friendly libraries that validate form and API payload inputs, also support detection of malicious actors, documenting their attempts to disrupt the system if they occur.
4. In a Payment Card Industry Data Security Standard (PCI DSS) compliance consideration, establishing enhanced card data security will facilitate adoption of consistent data security measures globally. As customers use their financial tools and instruments, their information and data must be protected with above board operations and in-depth security. The payment card information in addition to the metadata collected with transactions could leave a footprint of digital history that in nefarious hands could be misused. It is important not only to protect the customers financial information, but also their information regarding PII/SPII stored for an accurate knowledge of the customer. Through risk transference, the financial technology firm reduces their vulnerability and attack surface, as their digital services can be secured and purchased through a provider to offload the immense security requirements of finical data. These measures should be heavily considered in the threat model and weighed as opportunities that may reduce the overall cost of the platform in the longterm, considering the cost of accepted risks that could turn into breaches.
5. Firewalls are imperative measures for safekeeping technology and have long stood as an infrastructural outer layer. From the WAF firewall that protects from scripting and injection to unidentified vulnerabilities, to the virtual private network blocks and port detection for various services that may be integrated into the digital campus platform. There are a series of configurations that work as allow lists across different boundaries, which can be documented in the threat model and planned to restrict illicit access and support the containerized application in sustaining services. As requests from the UI enter through the application load balancers (ALBs) they are filtered at the web server and WAF, down to the security protocols, monitoring the packets that flow through each port by request. These subtitles are what enables a platform to remain secure and mitigate the attack surface of the University's digital campus.
6. Identity providers (IdPs) like Microsoft Entra Id provide scalable identity services with enhanced multi-factor authentication security. Customers accessing their financial services, can be protected, sometimes even restricted conditionally if there is variance in their normal baseline practices, such as location, device, and method that can be abnormal and require more validation for security.

Incorporating the threat model and analysis in the SSDLC:

While in the planning phase of the SSDLC the team should work though the various user identities, the core users such as the customers, employees, managers, and administrators that would use the platform. The processes of the team should identify the high-fidelity flows in Authentication, Accounts, Transactions, and Customer Navigation, as these common user flows are the building blocks for the application and will often be replicated in nuance. The high regard of the information and the financial services firm's, reputation should influence considerations on increased separation across the application layers and services with responsibilities.

When working on requirements and analysis, the team should scope the application to take the least number of steps across each interaction so that they can structure actions in universal ways for performance and security observability. The threat model evolves at this point as the team can opt to transfer risk, in example, to the payment provider and the identity provider, reducing the internal and direct data store of critical application information. These steps and processes as providing a very resilient and scalable application by creating repeatable and durable processes that store their dependencies outside of the code.

Through the design and prototype phase the team can look at methods of error handling that obfuscated critical system information and increased the user experience (UX). They can also introduced the libraries after testing the forms and wiring up the WAF to monitor its effectiveness for de-risking the customer inputs. Through development the software development team can create unit tests for the happy and unhappy paths of each component as they build onto an individually auditable component library. In the accessibility tools, and in favor of accessibility they should build out wizard type automations that reduce complexity and incomplete data, while simplifying form entry, and spoofing, with locked down or pre-filled fields. The software should also written on meticulously established computer systems with monitoring that reduces the ability of any developer or employee of from becoming an insider threat.

When deploying the software the development, security and operations (DevSecOps) should follow best practices in applying code linting, vulnerability scanning, and automated testing to assure the quality of the code moving to the environment. As this team plans for the customers base to fluctuate around the clock, they should focus on scaled infrastructure that will allow for cost savings and high-demand, whenever needed. Tools like Azure DevOps and Azure Monitor allow for CI/CD and analytics for reviewing the infrastructure and resources to continuously monitor the SSDLC's planning effectiveness.

For maintenance and lifespan, the components, software, designs, and infrastructure should be tagged, documented, and labeled for quickly referencing and identifying the source of the issues. Through a verbose logging platform, on going monitoring, and incident tracking any team performing the maintenance will have a clearly identified cause to begin analyzing and repairing the system.