Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building a Fool Proof Security Strategy for PSD2 Compliance


Published on

PSD2 is centered around exposing sensitive customer data. This means the security measures you take to expose this data cannot have any loopholes. Just like your API management strategy, your security strategy is critical to implementing successful compliance.

WSO2 Open Banking comes with inbuilt capabilities to support Strong Customer Authentication (SCA) and access management. Built around the key requirements of the Regulatory Technical Standards (RTS) it provides the end to end security requirements for compliance, while ensuring that customer experience is not compromised.

This webinar will cover

The key requirements of the RTS for PSD2 Compliance - Strong Customer Authentication (SCA), federated authentication, consent management and more
The capabilities of WSO2 Open Banking to meet these security requirements
How to ensure a secure yet frictionless customer experience
A demonstration of WSO2 Open Banking

Published in: Technology
  • Login to see the comments

  • Be the first to like this

Building a Fool Proof Security Strategy for PSD2 Compliance

  1. 1. Building a Fool Proof Security Strategy for PSD2 Compliance Pushpalanka Jayawardhana Financial Solutions - WSO2
  2. 2. Line Up • PSD2 • PSD2 RTS on SCA and Secured Communication • Compliance Requirements – API Security • Specifications to meet recommandations Eg. OpenBanking Org UK specification/ Berlin Group/ STET/ FAPI - OIDC Hybrid Flow - Private Key JWT authentication – Strong Customer Authentication – Consent Management – Fraud Detection • Implicit Requirements – Conditional Authentication – Adaptive Authentication – Fine Grained Authorization
  3. 3. PSD2 Mandates Banks to - securely expose - customer Account and Payment data - with customer consent - to regulated third parties - via APIs
  4. 4. With the Objective of ● Providing a frictionless user experience ● Making electronic payments more secure ● Establish a platform for effective and integrated payment services ● Providing openness required for innovations in the domain, with enhanced competition.
  5. 5. Timeline
  6. 6. PSD2 RTS on SCA and Secured Communication ● Two factor Authentication ● Strong authentication is required with at least two factors from below, i. Knowledge factors (username and password, pin) ii. Possession factors (mobile, security device, token generator) iii. Inherence factors (fingerprint, voice, iris pattern) ● Open secured APIs for payment initiation and account information ● Access delegation with explicit user consent ● Secured Communication ● Fraud detection and audit logs
  7. 7. More Requirements ● Conditional Authentication ● Adaptive Authentication ● Fine grained authorization ● Federated Authentication ● Continued security procedures
  8. 8. WSO2 Open Banking
  9. 9. Strong Customer Authentication (SCA) ● Correctly identifying and authenticating the end user is a necessity. ● More secure than just having basic authentication. ● WSO2 Open Banking Solution provides, ○ Multi Factor Authentication (MFA ) support with SMS/OTP, FIDO, DUO, MePin etc. ■ WSO2 connector store - ○ Extensible to support any other mechanism preferred by banks to authenticate users. Knowledge Ownership Inherence Password, PIN, ID number Mobile device, token or Smart card Fingerprint, face or voice recognition
  10. 10. API Security ● Exposing confidential internal data to external parties ● Inbuilt OAuth2 security layer provided by IAM capabilities ensures secure API invocations through WSO2 Open Banking Solution. ● Supports common grant types such as Client Credentials, Authorization Code, Password, Implicit, SAML Bearer, JWT assertion bearer and Integrated Windows Authentication (IWA) allowing APIs to be used by different types of Applications. ● Applicable entitlement management and enforcement layer Our recent webinar on API Mgt :
  11. 11. Standards JSON REST OAuth OpenID Connect Sources - ODI OBWG : Open Banking Standard 2016 & Ⓒ By 2016 Nomura Research Institute
  12. 12. Specifics for OIDC • OIDC Hybrid flow • Request object • s_hash • Private_key_jwt client authentication ➢ Less round trips than authorization_code ➢ Avoid multiple mix up attacks Eg. IDP mixup ➢ Protection from ‘state’ parameter injection ➢ Strengthen source authentication
  13. 13. Consent Management ● Comprehensive support to manage user consent ○ For payment transactions or account information aggregations ○ Revoking consents ○ Operations from custom care officers ● GDPR Implications (May 2018)
  14. 14. System is breach proof? Data Breaches Frequency 998 Incidents, 471 with confirmed data disclosure Top 3 patterns Denial of Service, Web Application Attacks and Payment Card Skimming represent 88% of all security incidents within Financial Services Threat actors 94% External, 6% Internal, <1% Partner (all incidents) Actor motives 96% Financial, 1% Espionage (all incidents) Data compromised 71% Credentials, 12% Payment, 9% Personal - DoS attacks were the most common incident type. Summary Confirmed data breaches were often associated with banking Trojans stealing and reusing customer passwords, along with ATM skimming operations. Source : Verizon 2017 Data Breach Investigations Report - 10th Edition
  15. 15. Fraud Detection • Allows Organizations to – Detect known anomalies via contextually evolving rules – Detect unknown anomalies via Machine Learning – Detect Anomalous event sequences via Markov Modelling – Reduce False Positives via Fraud Scoring – Further investigate and identify complex relationships using Interactive Analytics Quantity Value Anomaly
  16. 16. Conditional Authentication
  17. 17. Adaptive Authentication ● Adaptive Authentication allows the solution to adjust the authentication strength ● This is based on the feedback from analytics engine. ● Maked the authentication stronger or relax it based on the context at hand. ● Provides better user experience, enforcing strong authentication only when it’s necessary. Transaction amount > 10000 EUR Transaction amount < 10000 EUR Basic Authentication SMS OTP Authentication Basic Authentication Authenticated Authenticated
  18. 18. Fine Grained Authorization ● In the Authentication Flow ○ WSO2 IS can support fine grained authorization with XACML 2.0/3.0 ○ User authentication decision can be affected by other factors ■ Eg. In a specific time interval, users cannot login ● In the API calls ○ WSO2 AM can intercept the flows to apply fine grained authorization ○ Consume authorization decisions from IS, acting as a PEP ■ Eg. API response can be further customized according to user attributes. ● If the user belongs to ‘Platinum’ tier let them take online loans below an amount x.
  19. 19. Continued Assurance Process • Proactive strategy (Continuous Integration) – WSO2 Security Guidelines based on OWSAP – Commercial static code and dynamic security scan tools – Third party dependency scans • Reactive strategy – Any vulnerabilities reported are addressed with the highest priority – Issue fixes to customers before public disclosure Resources :
  20. 20. Creates an “Open Banking” platform to be PSD2 compliant and as a result become a Digitally Transformed Bank. API Specification ○ API Definitions ○ WSO2 Open Banking Customer TPP (AISP/PISP) FinTech Merchants Core Banking Internal Payment Services Bank Internal Network ISO 8583 (TCP/IP) HTTP HTTPS Other Banks HTTPS
  21. 21. WSO2 Open Banking ● API Specification ● API Security + SCA ● API Analytics ● API Monetization PSD2 Compliance ● API Integration ● Fraud Detection ● API Analytics ● Dashboards TPP Provider ● Web/Mobile App Suite ● Insight Sales ● Required Integration Digital Transformation
  22. 22. Demo
  23. 23. Resources More Information Try out WSO2 Open Banking On Demand Webinars 2-compliance/ Open Banking White Paper
  24. 24. THANK YOU