🤔 WSO2 InfoSec Reco

Salut, let's catch up with you, to yesterday's post, let's look at the information security requirements that will help us with integrations.

These requirements will reduce the risks associated with cybercrimes, leaks, and non-compliance. We are taking a closer look at the requirements for fintech integrations.

I’ll share my selection, which will help you anticipate a lot of problems that you won’t have to deal with further.

• Consider Open API security standards

— STO BR FAPI.SEC‑1.6‑2024 (OpenID API security)

— STO BR FAPI.PAOK‑1.0‑2024 (authentication via a separate channel)

• GOST 57580.1 and processes

— For financial information and personal data, apply the measures of GOST 57580.1: channel protection, access control, event registration, vulnerability management, ensuring software integrity and relevance

— Logs of WSO2 and backend services via API should go to a centralized log

— For each API processing personal data, an information security risk assessment must be carried out within the framework of 57580.1 and internal policies under 152-FZ

• Requirements for personal data

— The fact of personal data transfer via WSO2 must be reflected in contractual documents and in the list of personal data information systems and cross-border transfers

— Internal documents should describe the procedure for notifying Roskomnadzor about incidents with personal data (72 hours for investigation and reporting) and the responsibilities of the roles

— For APIs where the volume of personal data is minimal, minimization, masking and depersonalization should be used: transfer only the necessary set of attributes, and also, where possible, use tokens/aliases instead of direct client identifiers

• Architectural requirements

— Configure WSO2 using HTTPS/ TLS 1.2+ with Forward Secrecy for all public endpoints, enable verification of client certificates if mutual TLS is used

— Use OAuth 2.0 + OpenID Connect as the main authentication mechanism for API clients (in accordance with FAPI.SEC), limit access by scope/role and, if necessary, by IP/ASN

— Provide protection against typical attacks on the API: rate limiting, throttling, protection against replay attacks, CSRF, injection, as well as JSON/REST schema validation

• Supplement

— For each integration case, a threat model and risk assessment must be completed, with security measures recorded in the architecture

— A separate regulation “Management of external integrations” is required, describing: the API life cycle, responsibility of the Integration Layer, the procedure for reviewing information security and architects, requirements for logging and monitoring

— We need regulations for vulnerability management and integration services: frequency of scans, procedure for installing updates, SLA for eliminating critical vulnerabilities

- Access from BYOD to the internal loop should be limited by controlling privileged users using Segregation-of-Duties

— It is necessary to implement the lack of access rights in internal systems

— Previous authentication is necessary for data sources and in its absence, the communication channels used and the resources used must be encrypted (integrity locking, encryption, source control, etc.)

— All files that are transferred (also for subsequent cases - in both directions, if used) must be encrypted and go through a sandbox

— Access to data by id from the outer perimeter should exclude incremental id

— When designing an API via WSO2, focus on OpenID/OAuth2 security profiles: TLS is mandatory, secure storage and transfer of tokens, protection against request/response spoofing

#reco #devsecops #pmicases #specialty #techsolution #compliance #paper