The Problem: One-Size-Fits-All Security
Finovara previously treated all sensitive user actions identically. Whether a user was logging in, changing their email address, or performing another critical operation, the system demanded a secondary authentication code. This approach, while functional, was inflexible and potentially cumbersome for legitimate users under normal circumstances. It lacked the nuance to differentiate between low-risk and high-risk activities, leading to a less-than-optimal user experience.
The Solution: A Dedicated Risk Engine
To address this, Finovara developed a new microservice named security-monitoring-backend. This service's sole purpose is to evaluate the risk associated with every sensitive event within the Finovara system. It answers a single, crucial question: What is the risk score of this action, and what level of user verification is necessary before proceeding? This post details the scoring mechanism, its integration with the broader Finovara architecture, and the challenges encountered, including a deep dive into OAuth2 complexities.
The Core Idea: A Dynamic Risk Score
The fundamental principle behind the new security model is a risk score. Every action deemed sensitive in Finovara—ranging from initial login attempts to password resets, adding significant financial transactions, or modifying account details—is now funneled through a process that results in one of four distinct outcomes:
- Allow: The action is deemed low-risk and requires no further authentication beyond the initial session.
- Challenge: The action presents a moderate risk. The system will prompt the user for additional verification, such as a one-time password (OTP) or biometric confirmation.
- Deny: The action is flagged as high-risk and is immediately blocked.
- Review: The action is unusual or falls into a grey area, requiring manual review by a security analyst.
This tiered approach allows Finovara to tailor security measures to the actual threat level of each operation, moving away from the rigid, blanket requirement of secondary authentication for every sensitive event.
Scoring Risk: Factors and Logic
The security-monitoring-backend service calculates a risk score based on a variety of factors. While the exact algorithms are proprietary, common indicators for risk assessment in financial systems include:
- User Behavior Analysis: Deviations from typical user patterns, such as logging in from an unusual geographic location, at an atypical time, or from a new device.
- Transaction Details: The amount of money involved in a transaction, the recipient, or the frequency of similar transactions.
- Device Information: The integrity and reputation of the device used for the action (e.g., known malware, jailbroken device).
- IP Address Reputation: Whether the IP address is associated with known malicious activity or VPNs used to mask location.
- Account History: Recent security events, failed login attempts, or changes to account settings.
The system aggregates these signals into a numerical score. This score is then mapped to the four possible outcomes (Allow, Challenge, Deny, Review). For instance, a login from a user's usual device and location might result in an 'Allow' outcome, while the same user attempting a large transfer from a new device in a different country would likely trigger a 'Challenge' or even 'Deny' outcome, depending on the precise score.
System Integration and Communication
Integrating this new microservice required careful consideration of how existing Finovara services would interact with it. When a sensitive action is initiated, the originating service (e.g., the authentication service, the transaction processing service) sends a request to the security-monitoring-backend. This request typically includes relevant context about the action, such as user ID, action type, transaction amount, and device details.
The security-monitoring-backend processes this information, computes the risk score, and returns one of the four defined outcomes. The originating service then acts upon this response. If the outcome is 'Challenge', it initiates the appropriate secondary authentication flow. If it's 'Deny', the action is immediately rejected. If it's 'Allow', the action proceeds without interruption. For 'Review' outcomes, a notification is sent to the security operations team.
This architecture decouples the complex risk assessment logic from individual services, centralizing it within the dedicated microservice. This promotes cleaner code, easier maintenance, and more consistent security policy enforcement across the platform.
The OAuth2 Rabbit Hole
Implementing the communication between services, particularly ensuring secure and standardized interactions, led the developer down the OAuth2 rabbit hole. OAuth2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. In this context, it was likely used to manage the permissions and secure communication channels between the security-monitoring-backend and other Finovara services.
Challenges within OAuth2 implementation often involve correctly defining scopes, managing access tokens, handling refresh tokens, and ensuring compliance with security best practices. For instance, determining the appropriate scopes for the security monitoring service—what data it truly needs access to and what actions it's authorized to trigger—is critical. Misconfigurations can lead to either overly permissive access, undermining security, or overly restrictive access, breaking functionality. The developer's journey suggests that setting up secure, efficient, and compliant OAuth2 flows for inter-service communication can be a non-trivial undertaking, requiring a deep understanding of the protocol's nuances.
Future Implications and Benefits
The introduction of this risk engine represents a significant maturation of Finovara's security posture. The benefits are manifold:
- Enhanced Security: More targeted security measures adapt to real-time threats, reducing the attack surface.
- Improved User Experience: Legitimate users face fewer unnecessary authentication hurdles, leading to smoother workflows.
- Scalability: A dedicated microservice simplifies scaling security monitoring independently of other application components.
- Auditability: Centralized risk assessment provides a clearer audit trail for security-related decisions.
By moving to a dynamic, risk-based authentication model, Finovara aligns itself with modern security best practices, offering a more robust and user-friendly platform.