Digital Financial Services Security Audit Guideline

SECURITY, INFRASTRUCTURE AND TRUST WORKING GROUP
Digital Financial Services

security audit guideline
REPORT OF SECURITY WORKSTREAM
a • Technical report on SS7 vulnerabilities and mitigation measures for digital financial services transactions
b • Technical report on SS7 vulnerabilities and mitigation measures for digital financial services transactions
Security, Infrastructure and Trust Working Group

03/2021
DISCLAIMER
The Financial Inclusion Global Initiative (FIGI) is a three-year program implemented in

partnership by the World Bank Group (WBG), the Committee on Payments and Market
Infrastructures (CPMI), and the International Telecommunication Union (ITU) funded by
the Bill & Melinda Gates Foundation (BMGF) to support and accelerate the implemen-
tation of country-led reform actions to meet national financial inclusion targets, and
ultimately the global 'Universal Financial Access 2020' goal. FIGI funds national imple-
mentations in three countries – China, Egypt and Mexico; supports working groups to
tackle three sets of outstanding challenges for reaching universal financial access: (1) the
Electronic Payment Acceptance Working Group (led by the WBG), (2) The Digital ID for
Financial Services Working Group (led by the WBG), and (3) The Security, Infrastructure
and Trust Working Group (led by the ITU); and hosts three annual symposia to gather
national authorities, the private sector, and the engaged public on relevant topics and to
share emerging insights from the working groups and country programs.
This report is a product of the FIGI Security, Infrastructure and Trust Working Group, led
by the International Telecommunication Union.
The findings, interpretations, and conclusions expressed in this work do not necessar-
ily reflect the views of the Financial Inclusion Global Initiative partners including the
Committee on Payments and Market Infrastructures, the Bill & Melinda Gates Foundation,
the International Telecommunication Union, or the World Bank (including its Board of
Executive Directors or the governments they represent). The mention of specific compa-
nies or of certain manufacturers' products does not imply that they are endorsed or
recommended by ITU in preference to others of a similar nature that are not mentioned.
Errors and omissions excepted; the names of proprietary products are distinguished by
initial capital letters. The FIGI partners do not guarantee the accuracy of the data includ-
ed in this work. The boundaries, colours, denominations, and other information shown
on any map in this work do not imply any judgment on the part of the FIGI partners
concerning the legal status of any country, territory, city or area or of its authorities or
the endorsement or acceptance of such boundaries.
© ITU 2021
Some rights reserved. This work is licensed to the public through a Creative Commons
Attribution-Non-Commercial-Share Alike 3.0 IGO license (CC BY-NC-SA 3.0 IGO).
Under the terms of this licence, you may copy, redistribute and adapt the work for
non-commercial purposes, provided the work is appropriately cited. In any use of this
work, there should be no suggestion that ITU or other FIGI partners endorse any specific
organization, products or services. The unauthorized use of the ITU and other FIGI part-
ners' names or logos is not permitted. If you adapt the work, then you must license your
work under the same or equivalent Creative Commons licence. If you create a translation
of this work, you should add the following disclaimer along with the suggested citation:
"This translation was not created by the International Telecommunication Union (ITU).
ITU is not responsible for the content or accuracy of this translation. The original English
edition shall be the binding and authentic edition". For more information, please visit
https://creativecommons.org/licenses/by-nc-sa/3.0/igo/
About this report
This report was written by Kevin Butler, University of Florida. The author would like to
thank Vijay Mauree and Arnold Kibuuka, ITU and Rehan Masood, State Bank of Pakistan
for their guidance and assistance in the report's review and edits. The author would also
like to thank the FIGI Security Infrastructure and Trust working group members for their
contributions and comments.
If you would like to provide any additional information, please contact Vijay Mauree at
tsbfigisit@itu.int.
Digital Financial Services security audit guideline 3

Contents
About this report�� 3
Acronyms ��6
1 Introduction�� 7
2 DFS security audit guideline�� 7
3 DFS security assurance framework controls and audit guideline��9
4 Security audit checklist�� 20

4.1 Access Control ��20
4.2 Authentication��20
4.3 Availability�� 21
4.4 Fraud Detection �� 21
4.5 Network Security �� 21
4.6 Privacy & Confidentiality�� 22
5 Bibliography��24

Acronyms
API Application Programming Interface

DFS Digital Financial Services
DMZ Demilitarized Zone
IMEI International Mobile Equipment Identity
IMSI International Mobile Subscriber Identity
MD Message Digest
MFA Multi-Factor Authentication
MNO Mobile Network Operator
MSISDN Mobile Station International Subscriber Directory Number
NTP Network Time Protocol
OTP One Time Password
PKI Public Key Infrastructure
POS Point of Sale
RBAC Role Based Access Control
SD Security Dimension
SHA Secure Hash Algorithms
Secure Element - A formally certified, tamper-resistant, stand-alone integrated
SE circuit often referred to as a "chip" as defined by the European Payments Council
or other recognized standards authority.
SIM Subscriber Identity Module
SMS Short Messaging Service
STK SIM Toolkit
XML Extensible Markup Language
USSD Unstructured Supplementary Service Data
6 Digital Financial Services security audit guideline

1 INTRODUCTION
The Digital Financial Services (DFS) Security Audit DFS provider, mobile network operator, and other
Guidelines complements the DFS Security Assur- third parties within the ecosystem.
ance Framework [1], to help stakeholders determine In a DFS application, a deficiency in any one of the
and identify security control deficiencies within the controls increases the likelihood of a breach of priva-
DFS infrastructure. The guidelines are based on the cy, access to DFS data, confidentiality, user authen-
DFS Security Assurance Framework which provides tication and authorisation, DFS service availabili-
a systematic security risk management process for ty, fraud (internal and external) network security.
identifying threats and vulnerabilities. The DFS Secu- The audit checklist can be used by DFS regulators,
rity Assurance Framework also proposes security providers, and operators in assessing whether the
control measures that should be implemented by the controls in the DFS Security Assurance Framework
are present and functioning as intended.
2 DFS SECURITY AUDIT GUIDELINE
The DFS security audit guidelines are categorised DFS Security audit Guidelines are categorised into
into six different groups that a regulator, internal/ the following groups:
external application security auditor, mobile network
operator, or DFS provider can use to assess the imple- i) Access control
mented DFS security assurance control measures.
Each group provides a series of questions that the Audit guidelines in this group assess wheth-
auditor can use as a checklist for the security audit of er sufficient selective restrictions on appro-
the DFS infrastructure. priate access to DFS associated systems,
services, resources, and controls are in place
to guarantee protection against unautho-
rized use of network resources.

ii) Authentication customer personal data and steal customer
funds from a DFS system.
Audit guidelines in this group assess a DFS
application's capability to verify the authen- v) Network security
ticity of the users.
Audit guidelines in this group assess the
iii) Availability controls in place to protect the underlying
network infrastructure from unauthorized
Audit guidelines in this group assess the DFS access, misuse, malfunction, modification,
infrastructure and application for reliability destruction, or improper disclosure. These
and ability to grant timely access to autho- can also be used to test whether information
rised DFS users. The application and infra- only flows between authorized endpoints
structure are validated for resistance to deni- without being diverted or intercepted.
al-of-service attacks.
vi) Privacy and confidentiality
iv) Fraud detection
Audit guidelines in this group assess the
Audit guidelines in this group to assess the controls in place to protect DFS partici-
controls in place within the DFS systems to pants/user's data from unauthorised disclo-
detect intentional and unlawful intercep- sure, including data protection that might be
tion by internal or external entities to obtain derived from observing network activity.
The DFS security audit guideline is structured in the format below:
Impacted DFS Group Risk and Vulner- Control Security audit Applicable policy or
Entity ability question procedure
The table above shows the DFS security risks and vulnerabilities, the DFS entities affected by those risks,
controls to mitigate the risks, the security audit question an auditor would ask and the respective policy and
procedure.
• The "Impacted DFS entity" lists the entity affected by the risk and vulnerability within the DFS ecosystem.
• The "Risk and vulnerability" column outlines the threats that an entity within the DFS ecosystem will face
based on the eight security dimensions (SD).
• The "control" column lists the DFS controls for each of the DFS entities within the ecosystem.
• The "Security audit question" column outlines the auditor's question for compliance checking of the specif-
ic control.
• The "Applicable policy or procedure" column suggests the applicable policy or procedure documents that
guide the day-to-day actions and strategies of a particular entity based on ISO/IEC 27001- Information
Security Management [2].
The structure table above is elaborated in section 3 and includes the detailed audit checklist for all the security
controls in DFS security assurance framework. The table outlines the various security checks that need to be
undertaken at the DFS provider and mobile network operator level to verify compliance. This table can be used
as a guideline by telco and financial services regulators, security auditors, and DFS providers for internal and
external security audits.
Section 4 describes the process the security auditors may adopt by outlining a series of questions from Table 1
grouped by category for easy reference.

3 DFS SECURITY ASSURANCE FRAMEWORK CONTROLS AND AUDIT GUIDELINE
The guideline includes a checklist with questions that the auditor can use to evaluate the security controls.
Impacted Group Risk and vulner- Control Security audit question Applicable policy
DFS Entity ability or procedure
DFS Access - Inadequate controls C1: Set timeouts and auto logouts user Are the following logical controls set for DFS Access control
Provider Control on user sessions (SD: sessions on DFS applications (logical user sessions: Policy - System and
access control) sessions). Within the application, ensure application access
i) auto logouts and session time out
support for password complexity (enforced control
by the server), set maximum unsuccessful ii) Maximum failed password login attempts
login attempts, password history and reuse
iii) Password and PIN complexity.
periods, account lock-out periods to a
reasonably minimal value to minimize the iv) Password/PIN reuse periods
potential for offline attack
DFS Access - Inadequate controls C2: Require user identity validation for Is there a sufficient way of validating user Access control
Provider Control on dormant accounts dormant DFS accounts users before re-acti- identity before activating previously dormant Policy - User access
(SD: authentication) vating accounts. accounts for example biometric validation? management
DFS Access - Failure to perform C3: Limit access to DFS services based on Does the DFS system have capability to detect Access control
Provider Control geographical location user locations (for example disable access out-of-pattern transactions based on cus- Policy - System and
validation (SD: Com- to DFS USSD codes while roaming, STK tomer profile? application access
munication security) and SMS for merchants and agents) where control
For example: Does the DFS provider check
possible restrict access by region for DFS
authenticity of transactions using loca-
agents, where possible check that agent
tion-based validation of transactions, for
and number performing a deposit or with-
example through geo-velocity tracking or
drawals are within the same serving area.
other means?
DFS Access - Inadequate user ver- C4: Restrict DFS services by commu- Has the DFS provider limited concurrent user Access control
Provider control ification of preferred nication channels (during registration logins and provided the option for customers Policy - System and
user communication customers should optionally choose ser- to opt into other login channels? application access
channels for DFS vice access channel, USSD only, STK only, control
For example, are customers who use USSD
services (SD: Commu- app only, or a combination) attempted DFS
able to optionally choose to use a DFS app
nication security) access through channels other than opted
channel before the DFS provider activates
should be blocked and red-flagged.
access through this channel?
DFS Authentica- - Replay session C5: The DFS system should not trust any Does the DFS provider enforce server-based Access control
Provider tion based on tokens client-side authentication or authorization authentication for all access requests? Policy - System and
intercepted (SD: com- tokens; validation of access tokens must be application access
munication security) performed at the server-side. control
DFS Privacy and - Weak encryption C6: Store DFS user passwords using strong Is there a mechanism in place to ensure that Data Security and
Provider Confidenti- algorithms for pass- salted cryptographic hashing algorithms. data-at-rest is encrypted and stored securely? Data Leakage Pre-
ality word storage (SD: vention Standard
data confidentiality)
MNO Access - Session timeouts C7: Add session timeouts for USSD, STK Has the DFS provider set USSD and STK DFS Access control
Control not specified for DFS application, and web access to DFS sessions to automatically disconnect after a Policy - System and
services services. set period of user inactivity? application access
control
MNO Access - User credentials for C8: Where possible, DFS users should set Is the password transmitted securely? Is the Access control
control DFS application are their own passwords at registration and user required to change password after first Policy - User access
sent in inherently they should be encrypted throughout the time login? management
insecure ways like transmission to the DFS system. Where
SMS or through first-time credentials are sent to the users,
agents (SD: data ensure DFS application credentials are
confidentiality) sent to users directly without third parties/
agents. Users should then be required
to set new passwords after the first-time
login.
Access - Failure to perform C12: Enforce a maximum number of login Is there a maximum number of failed login Access control
control login monitoring, attempts to DFS accounts for back-end attempts set before account is locked? Policy - System and
leaving systems users, merchants, agents and DFS cus- application access
susceptible to brute tomers on DFS systems (database, OS, control
force attacks (SD: application)
access control)
MNO Authentica- - Insecure transfer of C14: DFS providers should transmit the Are DFS user authentication credentials trans- Access control
tion customer credentials user authentication credentials securely mitted via a different channel/out-of-band? Policy - System and
(SD: access control) over a different channel (out of band). (e.g. if account setup is done via USSD chan- application access
nel are one-time passwords transmitted via control
e-mail or voice calls?)

(continued)
MNO Network - Exposure of internal C15: Use Network Address Translation to Are there technical controls in place to limit Communications
Security network to external limit external exposure of DFS IP address exposure of internal DFS systems addresses Security Policy
adversaries (SD: and routing information. (like database IP addresses? - Network security
access control) management
DFS Network - Insufficient pro- C16: Avoid direct access by external Are there logical boundaries that limit access Communications
Provider Security tection of internal systems to the DFS backend systems by to the DFS systems from all other systems? Security Policy
systems against setting up a DMZ that logically separates (For example, are other unauthorized inter- - Network security
external adversaries the DFS system from all other internal and nal users logically and/physically limited on management
(SD: access control) external systems. the network from accessing DFS processing
systems)
DFS Privacy and - Reliance by DFS C17: Ensure that security libraries offered Are the cryptographic libraries used by the Cryptography policy
Provider Confidenti- application on secu- by the operating system are correctly operating system or by the application cor- - Cryptographic
ality rity libraries offered designed and implemented and that the rectly designed and implemented and are controls
by operating systems cipher suites they support are sufficiently they up to date? Do the cryptographic librar-
(SD: communication strong. ies support strong cryptographic ciphersuites
security) and do they prevent or discourage use of
weak ciphersuites? Are hashing algorithms
used that have not been deprecated and are
adequate digest lengths supported? (Any-
thing less than SHA512 is considered weak
today. MD5 and SHA1 have been broken.)
For symmetric encryption ciphers, are strong
ciphers used and are adequate key lengths
supported? (For example, AES is considered
secure to use while 3-DES is no longer a pre-
ferred cipher because of the SWEET-32 attack,
and it is encouraged to move away from it
to AES as soon as possible.) - For public-key
encryption, are key lengths chosen to be an
appropriate size for the public key algorithm
being used?
Are the criteria used for selecting cryp-
tographic algorithms and key sizes based on
public and well-examined standards? (For
example, NIST 800-57 special publication has
guidelines on minimum key sizes for each
algorithm and how long this key size is good
for)
MNO Privacy and - Weak encryption C18: Ensure all sensitive consumer data Has all sensitive consumer data been Cryptography policy
Confidenti- practices or sending such as PINs and passwords are encrypted, encrypted by the application or the operating - Cryptographic
ality sensitive information when traversing the network and while the system? Are unencrypted versions of the controls
in clear text over inse- data is at rest. data accessible in the device, for example,
cure traffic channels in temporary buffers or in memory? Is all
like SMS and USSD information sent over a network connection
(SD: communication encrypted with a strong encryption cipher?
security) (See C17 for more discussion of what com-
prises a strong encryption cipher.)
DFS Pro- Fraud - Inadequate data C19: Remove customer sensitive data from Do trace logs and event data records capture/ Operations secu-
vider and Detection protection controls trace logs. Examples of data that should store sensitive user data? (e.g. are customer rity - Logging and
Third-party (SD: privacy) be removed include cash retrieval voucher PINs stored in EDRs) monitoring
providers codes, bank account numbers, credentials.
Instead, use place holders, where possible,
to represent this data in logs.
DFS Pro- Privacy and - Exposure of cus- C20: DFS providers should restrict sharing Is there limitation on customer sensitive infor- Operations security
vider and Confidenti- tomer sensitive of DFS user information to the minimum mation shared during transaction processing policy - Operational
Third-party ality information during amount required for transactions with with third parties? (e.g. Only information procedures and
providers transactions or third parties and service providers. needed for processing the transaction is responsibilities
through APIs (SD: shared with the third party)
privacy)

(continued)
DFS Pro- Fraud - Weak encryption C21: Monitor the use of APIs and encrypt Are there sufficient mechanisms to monitor Operations security
vider and Detection on the API interfaces all data shared with third parties. Addi- transactions processed through payment policy - Logging and
Third-party (SD: privacy) tionally, put into place data management APIs? monitoring
providers procedures and controls such as signed
Does the DFS provider have nondisclosure
non-disclosure agreements with payment
agreements pertaining to customer sensitive
service providers to avoid information/
data with third parties?
data leakage.
Are there strong cryptographic algorithms
used when transferring data with third
parties?
MNO Availability - Network failure C22: The mobile network operator should Are there systems in place to ensure service Information
due to insufficient take steps to ensure high network avail- availability? Example (service redundancy) security incident
network capacity ability to allow access to DFS services management
Are there reports and utilities to measure
or to maintenance through USSD, SMS, and the Internet. - Redundancies
system response time and down time?
or design (SD:
availability)
MNO Availability - Network failure C23: The MNO should perform technical Are there systems to measure quality of ser- System acquisition,
due to insufficient capacity tests simulating different trans- vice and quality of experience? development,
network capacity actions based on customer numbers, and maintenance
Do the QoS and QoE conform to the stan-
or to maintenance expected growth, expected number of - Security in devel-
dards for DFS?
or design (SD: transactions, and expected peak periods to opment and support
availability) ensure continued system performance. processes
DFS Network - Lack of monitoring C24: The DFS provider should protect Are there adequate protections against net- Operations security
Provider Security of network traffic and against network attacks by the use of fire- work attacks like firewalls and traffic filters - Protection from
individual network walls and traffic filters and protect against with proper configurations? malware
packets (SD: availabil- DFS infrastructure threats by challenging
ity, communication suspicious traffic through network admis-
security) sion techniques and mechanisms such as
CAPTCHAs.
DFS Network - Enabling unnec- C25: Inbound internet traffic should be Is there adequate monitoring of traffic for Operations security
Provider Security essary services (SD: limited and continuously monitored. internet facing DFS applications? - Protection from
data confidentiality) malware
DFS Network - Enabling unnec- C26: Set restrictive firewall rules by default, Are the firewall rules adequately configured? Operations security
Provider Security essary services (SD: use port whitelisting, use packet filters, e.g., port whitelisting, packet filtering - Protection from
data confidentiality) and continuously monitor access to malware
whitelisted/permitted ports and IP's.
DFS Fraud - Insufficient inter- C27: Where possible, limit critical changes Are there sufficient controls to review and Access control
Provider detection nal controls on using the four-eye principle (mak- approve for critical changes on accounts? e.g., Policy - System and
critical operations er-checker/two-person rule) for critical is there maker-checker and approval process application access
(SD: access control) actions including (but not limited to) before changes are made? control
an administrator creating, modifying, or
deleting another administrator account,
changing, attaching and detaching of DFS
account from mobile number/user ID, and
transaction reversal.
DFS Fraud - Lack of validation of C28: DFS providers should ensure sufficient Is there more than one person required to Access control
Provider detection data inputs (SD: data separation of duties for maker-approver; complete a critical DFS tasks? Policy - System and
integrity) for example, an administrator may not application access
have access rights to both create and control
activate a DFS account.
DFS Access - Insufficient privilege C29: Limit, control, and monitor physical Are there sufficient physical and logical barri- Physical and envi-
Provider Control management (SD: access to sensitive physical DFS infrastruc- ers to limit access to DFS infrastructure? ronmental security
access control) ture. Physically isolate and put in place - Secure areas
logical and physical deterrents/barriers to
DFS infrastructure from other infrastruc-
ture. Employ least privilege techniques
such that preventative access is allowed
for authorized persons, supplanted by
detection and enforcement (e.g., alarms if
forced). Monitor system activity by logging
all access (e.g., who accessed, what they
accessed, where they accessed from, and
when they accessed it).

(continued)
DFS Network - Addition of test data C30: The DFS provider should employ Is the DFS provider performing input valida- System acquisition,
Provider Security into production data robust input validation routines on tion checks? development,
(SD: data integrity) external-facing services by checking and maintenance
out-of-range values and unpermitted char- - Security in devel-
acters in fields, and by constraining and opment and support
sanitizing input. Input validation should processes
happen at the earliest possible point and
should be done both on the client, and
server-side, however, the server should not
rely solely on client-side validation. Addi-
tionally, block, log and review all requests
that violate the Web Services Description
Language (WSDL) and schemas.
DFS Fraud - Addition of test data C31: Use database fingerprinting to detect Are there mechanisms in place to detect data Operations secu-
Provider detection into production data tampering and modification of data after it modification and tampering on the database? rity - Logging and
(SD: data integrity) has been stored monitoring
DFS - Addition of test data C32: Ensure all test data is removed from Is test data and test user accounts deleted System acquisition,
Provider into production data code before it is migrated to the produc- from the production environment? development, and
(SD: data integrity) tion environment. maintenance - Test
data
DFS Fraud - Absence of logging, C33: DFS systems should use logging Are DFS logs stored securely in a tamper proof Operations secu-
Provider detection ability to alter logs, mechanisms, including capturing the prov- module? e.g., SIEM rity - Logging and
and insufficient infor- enance of user actions or logging of critical monitoring
mation in logs (SD: actions into tamper-proof storage, secure
non-repudiation) DFS system logs from tampering, editing,
deleting, stopping.
DFS Network - Inaccurate and C34: Ensure clock accuracy synchroniza- Are the clocks within the DFS ecosystem Operations secu-
Provider Security unsynchronised tion on all systems connected to the DFS synchronized? rity - Operational
clocks (SD: data system. NTP and SNTP are some of the pro- procedures and
integrity) tocols used to sync accurate time; however, responsibilities
these must be deployed securely.
MNO Network - Weak over-the-air C38: Discontinue the use of A5/0, A5/1, Has the use of known weak ciphers been Communications
security encryption (SD: com- and A5/2 GSM encryption ciphers. Closely discontinued? Has the deployment been security: Informa-
munication security) monitor results from the security and prepared for new ciphers? tion transfer
cryptographic community regarding the
feasibility and ease of compromising A5/3
and A5/4 and begin considering stronger
ciphers. Have a deployment strategy ready
for these newer ciphers.
MNO Fraud - Weak Calling Line C39: MNOs should do CLI analysis for calls/ Are there mechanisms to detect SMS and call Communications
detection Identification filtering SMS to detect calls and SMS that may be spoofing? E.g., CLI analysis? security: Informa-
(SD: communication spoofed to appear like DFS provider calls. tion transfer
security)
DFS Authentica- -Missing/Inad- C40: Require user authentication and Is there additional authorisation and authen- Access control
Provider tion equate account authorization for high-risk account tication for high value transactions and Policy - User access
configuration and changes and transaction and deny per- changes on DFS user accounts? For example, management
authorisation controls forming of transactions even when the what additional checks are done when
(SD: authentication) device is logged in until knowledge of PIN increasing transaction limits?
or password has been demonstrated.
Third-Party Privacy and - Weak encryption C41: Sufficiently secure encryption should Have strong encryption ciphers and integrity
Providers confidenti- algorithms used on be employed for both data protection protection mechanisms such as message
Cryptography policy
ality data stored in the within the mobile application and com- authentication codes been used for data
- Cryptographic
device and data munication with backend DFS systems stored on the device and when data is com-
controls
transmitted (SD: and whenever possible, mask, truncate or municated to backend DFS systems? (See
privacy) redact customer confidential information. C17 for a discussion of strong encryption
algorithms.) Are policies in place to assure the
reaction of sensitive customer confidential
information?
Third-Party Privacy and - Lack of encryption C42: Use digital signatures to identify third Are digital signatures used to identify third Access control
Providers confidenti- of communications parties connected to the DFS system when party providers that connect to the DFS Policy - System and
ality (SD - communication transactions are performed. systems? application access
security) control

(continued)
Third-Party Privacy and - Insufficient manage- C43: Use trusted keys and certificates to Are procedures in place to assure the trust- Access control
Providers confidenti- ment of certificate allow data exchange between DFS provid- worthiness and protection of private and Policy - System and
ality or key materials (SD: ers and third parties, and they should be secret keys? Are certificates and other cryp- application access
access control) protected from disclosure. tographic information protected by operating control
system controls?
Third-Party Availability - DFS Provider or C44: Set procedural and technical controls Are there policies in place to assure manage- Operations secu-
Providers MNO System Failure for effective management during system ment during system downtime? rity - Operational
leading to agents/ downtime with related service providers. procedures and
third parties reverting For example, set controls to manage offline responsibilities
to offline processes transactions (e.g., SIM swaps) when access
(SD: availability) to the DFS system is intermittent. Have
additional checks for remittances and
third-party payments when DFS system or
3rd party system access is intermittent.
DFS Authentica- - Insecure and inade- C45: Use multi-factor or multi-model Is multifactor authentication used when Access control
Provider tion quate access controls authentication for access to DFS accounts. connecting to DFS accounts? Policy - User access
on user accounts (SD: management
access control)
Access - Untested resto- C46: Deactivate and remove default Are default system accounts removed from Access control
Control ration practices (SD: accounts and credentials from databases, the DFS system and all systems that connect Policy - User access
availability) applications, operating systems, and other to DFS systems? management
access interfaces that interact with the
production DFS system.
DFS Access - Untested resto- C47: Review installation, vendor, support Are DFS vendor and support system Access control
Provider Control ration practices (SD: accounts, and access points to DFS systems accounts deactivated after support duties are Policy - User access
availability) and infrastructure. All of those accounts completed? management
should be deactivated or assigned appro-
priate user profiles.
DFS Availability - Inadequate data C48: Perform end-to-end tests after any Are end to end tests been performed after System acquisition,
Provider controls like failure to changes to the DFS, MNO, SP, and third- changes or upgrades to the DFS systems? development,
implement atomicity party systems, include regression and End to end tests may include capacity tests, and maintenance
of transactions, allow- capacity tests in the acceptance tests. Also, security tests, Quality of Service tests, user - Security in devel-
ing them to exist in a ensure there is a fall-back/blackout plan. acceptance tests etc. opment and support
partially completed processes
state (SD: data
integrity)
DFS Availability - Inadequate data C49: Have scheduled, regular backups for Does the DFS provider have regular sched- Operations security
Provider controls like failure to DFS systems. Regularly test and securely uled backups? - Backup policy
implement atomicity store backups offline and offsite in an
Are the backups encrypted and stored on an
of transactions, allow- encrypted form.
offsite location?
ing them to exist in a
partially completed
state (SD: data
integrity)
DFS - Inadequate data C50: Use standard ACID (Atomicity, Consis- Are there pending transactions, duplicate Operations secu-
Provider controls like failure to tency, Isolation, Durability) functionality of transactions in the DFS system? rity - Operational
implement atomicity the databases to ensure transaction integ- procedures and
Has the transaction been fully executed?
of transactions, allow- rity. DFS operations should either succeed responsibilities
ing them to exist in a completely or fail completely. DFS provider
partially completed should also ensure there are checks to
state (SD: data prevent duplicate transactions (unique
integrity) transaction IDs, timestamps and use of
cryptographic nonce)
Third-Party Privacy and - Inadequate mecha- C51: DFS applications/3rd parties should Are digital signatures used by DFS appli- Access control
Provider confidenti- nisms to assure data support the use of digital signatures; a cations or by third-party providers? Are the Policy - System and
ality integrity and over-re- secure digital signature provides irrefut- digital signatures based on sufficiently strong application access
liance on external able evidence of the transaction's origin. cryptographic algorithms and key sizes? Are control
trust anchors (SD: Digital signatures are only valid as long as the implementations of the cryptographic
non-repudiation) the PKI has not been compromised and algorithms secure and up to date and do they
must be tested with plans for assuring agil- provide sufficient randomness? (For example,
ity. By demonstrating that signing keys are strong digital signature algorithms include
adequately protected up to the root key, RSA, DSA, and ECDSA. Elliptic-curve cryp-
the DFS provider can withstand legal chal- tographic algorithms can use shorter keys to
lenges about the authenticity of a specific provide equivalent security to other ciphers.)
user and disputed transactions.

(continued)
MNO Authentica- - Inadequate controls C52: MNOs should ensure that an identity Are processes and policies in place to ensure Access control
tion for user identification verification process is in place before SIM that identity verification is in place prior to Policy - User access
and verification swaps is performed. SIM swap operations? Are there technical management
before SIM swap and mechanisms in place to prevent any leakage
SIM recycling (SD: or transfer of information until the SIM swap
Authentication) has been confirmed?
MNO Authentica- - Inadequate controls C53: The user's identity should be verified Does the mobile network operator perform Access control
tion for user identification using a combination of something they biometric authentication before SIM swaps or Policy - User access
and verification are, something they have, or something SIM replacement? management
before SIM swap and they know. For example, with the presen-
SIM recycling (SD: tation of a valid ID, biometric verification,
Authentication) and knowledge about the DFS account
details before a SIM swap/ SIM replace-
ment is performed.
MNO Authentica- - Inadequate controls C54: DFS and Payment Service Providers Is the DFS provider able to detect a SIM swap Access control
tion for user identification should be able to detect real-time when- or SIM change for a DFS account? Policy - System and
and verification ever a SIM card with DFS services has application access
before SIM swap and swapped or replaced. And perform further control
SIM recycling (SD: verification before any high-value trans-
Authentication) action or account changes are authorised
with new SIM.
MNO Authentica- - Inadequate controls C55: The mobile operator should safeguard Does the mobile network operator securely Asset management
tion for user identification and securely store SIM data like IMSI and store SIM data like IMSI, Kc and Ki? - Media handling
and verification SIM secret key values (KI values).
before SIM swap and
SIM recycling (SD:
Authentication)
MNO Authentica- - Inadequate controls C56: A mobile number recycling pro- Is the DFS provider involved in the SIM recy- Asset management
tion for user identification cess should be in place that involves cling process for DFS accounts? - Media handling
and verification communicating with DFS providers on
before SIM swap and Mobile Subscriber Identification Numbers
SIM recycling (SD: (MSIDN) being churned or recycled. (in
Authentication) this context: number recycling is when
the MNO reallocates a dormant/inactive
Mobile Subscriber Identification Number
(MSISDN) to a new customer). When a SIM
is recycled, the mobile operator will report
a new IMSI of the related account phone
number. The DFS provider should block
the account until the identity of the new
person holding the SIM card is verified as
the account holder.
Privacy and - Mobile device C57: DFS users should have the ability to Does the application or underlying operating Operations secu-
Confidenti- theft (SD: data perform remote wipes on a mobile device system provide support for remote wipes rity - Operational
ality confidentiality) and encrypting their data in case the of DFS data or of the mobile device, and are procedures and
device is lost or stolen. there mechanisms in place to ensure that responsibilities
data is encrypted in the event of device loss
or theft?
DFS Access - Inadequacies in SIM C58: DFS providers should ensure they Are there procedures in place for the DFS Operations secu-
Provider control swap and recycling have procedures in place to detect and provider to detect suspicious SIM swaps and rity - Operational
process[ii] (SD: data avert suspicious SIM swaps and SIM recycle SIM recycling? procedures and
integrity) by: responsibilities
a) Check if the IMSI associated with the
phone number has changed, this is an
indication of SIM swap.
b) If there is an indication of a SIM swap,

check the IMEI of the phone holding the
SIM. If the IMEI has also changed, there is a
high probability of a SIM swap. In that case,
the DFS provider should block the account
until performing account verification
procedures, for example, via a voice call or
an agent.

(continued)
DFS Fraud - Unauthorized C59: Protect against tampering and allow Does the app store transactions for later Operations secu-
provider Detection changes to system only online transactions transmission? rity: Operational
configuration and procedures and
a) Protect and monitor DFS application
log files and data (SD: responsibilities
files from tampering and changes using
Data Integrity)
file integrity monitors, e.g., by calculating
checksums or validating digital signatures.
b) By policy, the DFS provider or merchant
should not use the mobile payment solu-
tion to authorize transactions offline or
store transactions for later transmission.
DFS Authentica- - Inadequate user C60: Use strong multi-factor authentication Is multi factor used for authenticating users? Access control
provider tion access validation or for user and 3rd party provider access to Policy - System and
user input validation DFS systems, e.g., token or biometrics, the application access
(SD: Authentication) use of multi-factor authentication to verify control
system users increases non-repudiation
of origin.
DFS Authentica- - Inadequate user C61: Check incoming data against Is the DFS provider performing XML valida- Communications
provider tion access validation or expected values in API related data tion of data through APIs and USSD requests? security - Informa-
user input validation schema, for USSD, perform XML validation . E.g., input validation, amounts, special charac- tion transfer
(SD: Authentication) ters in amounts, currency checks etc.
DFS Authentica- - Inadequate user C62: Use analytics systems to check user Does the DFS system have capability to detect Access control
provider tion access validation or velocity between transactions, transaction out-of-pattern transactions based on cus- Policy - System and
user input validation time of day access tracking for additional tomer profile? application access
(SD: Authentication) authorization validation checks. control
Are the DFS provider performing checks
based on user transactions profile? E.g. agent
shops performing late transactions, DFS
users perfuming transactions in two different
locations?
DFS Authentica- - Inadequate user C63: Regardless of the method used for Does the DFS app stores or transmits Personal Asset management
provider tion access validation or producing receipts (e.g., e-mail, SMS, or Account Number/Sensitive Authentication - Media handling
user input validation attached printer), the method should mask Data in plain text over SMS/email?
(SD: Authentication) the Primary Account Number (PAN) in sup-
port of applicable laws, regulations, and
payment-card policies. By policy and prac-
tice, the DFS Provider/merchant should
not permit the use of non-secure channels
such as e-mail and SMS to send PAN or
Sensitive authentication data (SAD).
MNO Network - Inherent SS7 secu- C70: Ensure all sensitive consumer data Are the encryption algorithms and keys used Cryptography
Security rity weakness[iii] such as PINs and passwords are securely are strong enough to protect customer PINs - Cryptographic
(SD: Communication stored with strong encryption algorithms and data? controls
Security) within the internal network and while at
rest to mitigate internal threats against
this data.
MNO Network - Inherent SS7 secu- C71: Use firewalls to detect and limit Does the MNO have a firewall in place to Communica-
Security rity weakness[iii] attacks based on SS7 security flaws. detect and protect against external SS7 based tions security
(SD: Communication attacks? For example (firewall protection - Network security
Security) against subscriber traffic interception, unau- management
thorized USSD and SM use)
MNO Access - Interception C72: Check if the IMEI of the device Is the DFS provider performing real time Access control
control of MO-USSD performing the transaction matches the device validation before transaction Policy - System and
transactions (SD: registered IMEI of the account holder's processing? application access
Communication phone (a MITM system may clone the SIM control
Security) with a different IMEI)
MNO Network - Unprotected sensi- C73: Monitor user velocity by comparing Is the DFS provider performing user transac- Access control
security tive traffic and weak the location of the phone used to perform tion geo-velocity checks before transaction Policy - System and
encryption practices transactions to the last reported location of processing? application access
(SD: Communication the phone (last in/out SMS or call). control
Security)
MNO Network - Unprotected sensi- C74: MNO's should enforce the use of the Does the MNO enforce use of the Personal Communications
Security tive traffic and weak Personal Unlocking Key (PUK) on the SIM Unlock Key on SIM cards to reduce the risk security - Informa-
encryption practices card for additional security in case the associated with stolen SIMs that are used for tion transfer
(SD: Communication mobile device is lost or stolen. DFS?
Security)

(continued)
MNO Network - Unprotected sensi- C75: Control and monitor the use of MSC Does the MNO operator have controls in Access control
Security tive traffic and weak MAP tracing and protocol analysers on place to limit access to MAP tracing and use Policy - User access
encryption practices USSD, SMS infrastructure to internal limit of protocol analysers on the internal network? management
(SD: Communication access to plain text SMS and USSD traffic (SMS and USSD messages are transmitted in
Security) in transit plain text in the MAP protocol)
MNO Network - Unprotected sensi- C76: Use 2-way Secure OTP to the original Is transaction validation performed using Access control
Security tive traffic and weak phone number to verify the legitimacy of secure OTP? Policy - User access
encryption practices the transaction[iv] management
(SD: Communication
Security)
MNO Privacy and - Unprotected sensi- C77: Employ strong cryptography practices Are the encryption algorithms and keys used Cryptography
Confidenti- tive traffic and weak to assure confidentiality and integrity of are strong enough to protect customer PINs - Cryptographic
ality encryption practices data as it enters the DFS provider network and data? controls
(SD: Communication and as it is processed and stored within
Security) this environment.
MNO Access - Unprotected sensi- C78: Limit number of DFS sessions per user. Are there controls in place to prevent mul- Access control
Control tive traffic and weak Allow a single session per user at a time tiple simultaneous logons through multiple Policy - System and
encryption practices irrespective of the access channel (STK, channels? application access
(SD: Communication USSD, or https); a DFS user account should control
Is the DFS provider only allowing a single ses-
Security) not be accessible using multiple channels
sion per user at a time to connect to the DFS
simultaneously.
network? (multiple sessions through different
channels could be an indication of a breach)
MNO Network - Unprotected sensi- C79: The mobile operator should deploy Has MNO implemented the SS7 and diameter Communica-
Security tive traffic and weak SS7 and diameter signaling security con- signaling controls to protect against SS7 tions security
encryption practices trols specified by the GSMA (FS.11, FS.07, vulnerabilities? - Network security
(SD: Communication IR.82, and IR.88) to limit threats due to SS7 management
Security) attacks [3]
DFS Privacy and - Inadequate protec- C80: Protect and guard customer data Is the DFS data and forms used for customer Asset management
Provider confidenti- tion of DFS customer used for DFS registration, where physical registration securely stored, transmitted, and - Media handling
ality registration data. (SD: forms are used, store, and transmit the stored to prevent any data leakages using
Authentication) data securely. RBAC, data encryption etc.?
DFS Network - Use of weak C81: Use strong encryption standards like Is TLS encryption used secure? i.e., v.12 or Communications
Provider Security encryption. (SD: TLS encryption v1.2 and higher for API higher (July 2020) security - Informa-
Communication communication. tion transfer
Does the app use latest versions of TLS?
Security)
Does the app use any deprecated TLS version?
DFS Network - Inadequate DFS C82: Extend threat detection to explicitly Are there operational controls to detect Operations security
Provider security user access control incorporate threats associated with APIs. threats associated with APIs? - Technical vulnera-
and monitoring. (SD: bility management
Are there controls in place to detect rouge/
Access Control)
malicious APIs?
DFS Access - Inadequate DFS C83: Limit remote login access and mini- Are there controls to limit access to DFS sys- Access control
Provider control user access control mize privileges to remote login sessions to tems especially for remote login users? Policy - User access
and monitoring. (SD: backend DFS systems. management
Access Control)
DFS Privacy and - Inadequate DFS C84: Limit the lifetime of TLS certificates Is the TLS lifetime certificate up to date? I.e. Communica-
Provider confidenti- user access control to 825 days. the certificate age should be less than 825 tions security
ality and monitoring. (SD: days - Network security
Access Control) management
DFS Authentica- - Inadequate DFS C85: Authenticate user IP, device, and login Are there controls to check validate privileged Access control
Provider tion user access control time for all privileged users, agents, and users? For example, through IP validation and Policy - User access
and monitoring. (SD: merchants connecting to the DFS system. checking login time? management
Access Control) For example, configure a merchant and
agent access to the DFS system to be
accessible only during open trading hours.
DFS Network - Inadequate DFS C86: Code and changes should be tested in Are code changes tested and approved before System acquisition,
Provider Security user access control the test environment before moving to the moving it into production? For example, user development
and monitoring. (SD: production platform; the test environment and internal acceptance certificates that show and maintenance
Access Control) should be physically and logically sepa- that the code was tested. - Security in devel-
rated from the production environment. opment and support
processes

(continued)
DFS Network - Inadequate DFS C87: To improve security, use a trusted Does the DFS provider have a mechanism in Cryptography
Provider Security user access control tamper-resistant device like a Hardware place to securely store cryptographic keys? - Cryptographic
and monitoring. (SD: Security Module (HSM) to Securely manage controls
Access Control) the process and store cryptographic keys
to protect user PINs, transactions, tokens,
money vouchers.
DFS Access - Inadequate DFS C88: Set user roles to define access rights Does the DFS provider use Role Based Access Access control
Provider control user access control based on the principle of least privilege. Controls? Policy - User access
and monitoring. (SD: management
Access Control)
DFS Access - Inadequate DFS C89: After termination of a user, agent, Are login credentials of terminated DFS Access control
Provider control user access control merchant, payment service providers or administrators, agents and users deactivated? Policy - User access
and monitoring. (SD: third parties disable/deactivate respective Are dormant DFS accounts deactivated? management
Access Control) accounts
DFS Access - Inadequate DFS C90: Set account dormancy period and Has the DFS provider set a dormancy period Access control
Provider control user access control disable dormant accounts at dormancy after which inactive admin accounts are deac- Policy - User access
and monitoring. (SD: maturity. tivated? Are all inactive dormant internal staff management
Access Control) and API accounts deactivated?
DFS Fraud - Inadequate DFS C91: Set schedules for logons and session Does the DFS provider implement Role Based Access control
Provider detection user access control limitations based on DFS roles. (session Access Controls? Policy - User access
and monitoring. (SD: limitations can include the maximum management
Access Control) number of reversals per day based on the
role)
DFS Fraud - Inadequate DFS C92: Limit control, monitor, and period- Is there a mechanism in place to review Access control
Provider detection user access control ically review privileged access to DFS administrative privileges? Policy - User access
and monitoring. (SD: systems, including user addition, modifica- management
Access Control) tion, and deletion.
DFS Privacy and - Inadequate DFS C93: Monitor the use of APIs, and encrypt Is there a monitoring mechanism in place to Communica-
Provider confidenti- user access control all data shared with third parties, put in track data sharing through APIs? tions security
ality and monitoring. (SD: place data management procedures and - Network security
Are there controls in place to prevent data
Access Control) controls like signed non-disclosure agree- management
leakage?
ments with payment service providers to
avoid information/data leakage.
DFS Network - Inadequate moni- C94: Protect wireless transmissions per Are encryption keys were changed from Communica-
Provider Security toring of the wireless PCI DSS Requirements. Controls should default at installation? Are default SNMP tions security
network (SD: Data include, but are not limited to, the strings changed? - Network security
Confidentiality) following: management
- Ensure vendor default encryption keys,
passwords, and SNMP community strings
are changed.
- Facilitate the use of industry best prac-
tices to implement strong encryption for
authentication and transmission.
- Ensure that clear-text account data is
not stored on a server connected to the
Internet.
Third-party Privacy and - Failure perform data C95: DFS Providers/Merchants should Are there security guidelines followed when Operations security
confidenti- destruction/erasing consistently dispose of old devices. When disposing of DFS related data? - Protection from
ality before disposing of the solution provider provides guidance, malware
devices (SD: Privacy) the merchant should follow it. Some items
to consider include:
- Remove all tags and business identifiers.
- Where possible, develop a contract
with an authorized vendor who can help
securely dispose of electronic materials
and components.
- Do not dispose of devices in trash con-
tainers or dumpsters associated with your
business.

(continued)
Third- Network - Inadequate col- C99: Merchants and DFS providers should Are there procedures in place to monitor soft- Operations security
Party, DFS Security laboration with the require the following from their solution ware updates and are the updates installed in - Technical vulnera-
Provider solution provider on provider: a securely? bility management
the security of mobile
- The solution provider should regularly
devices purchased
update their payment application and
(SD: Availability and
indicate to the merchant when updates are
Confidentiality)
available and are safe to install.
- The solution provider should have restric-
tions on their payment application so
that it only functions on a device running
approved firmware.
- The solution provider should supply
documentation that details any update
procedures the merchant needs to follow.
- The DFS solution provider should com-
municate with the DFS provider and
make them aware of newly discovered
vulnerabilities in their payment-accep-
tance solution. Additionally, the solution
provider should guide merchants when
new vulnerabilities are discovered, as well
as provide tested patches for any of these
vulnerabilities.
Third- Fraud - Open undetected C100: The merchant should work with its Do the audit logs provided sufficiently track Operations security
Party, DFS detection system application solution provider to ensure that any audit all changes on the DFS system or MNO sys- - Technical vulnera-
Provider weaknesses (SD: Data or logging capability is enabled. The solu- tems that affect DFS services? bility management
Confidentiality) tion provider should ensure that logging
capabilities exist with enough granularity
to detect abnormal events.
The solution provider should guide the
merchant on the merchant's responsi-
bility to review the logs. Additionally,
regularly inspect system logs and reports
for abnormal activity. If abnormal activity
is suspected or discovered, discontinue
access to the mobile device and its pay-
ment application until the issue has been
resolved. Abnormal activities include, but
are not limited to, unauthorized access
attempts, escalated privileges, and unau-
thorized updates to software or firmware.
Third- Network - Network exposure C101: DFS Applications should be sub- Is there regular penetration testing of the DFS Operations security
Party, DFS Security to outside attacks jected to regular security penetration systems? - Technical vulnera-
Provider (SD: Availability) scans and penetration testing. In particular, bility management
applications should be designed to be
robust against phishing software.
MNO Availability - Network exposure C107: Perform regular vulnerability scans Are there regular vulnerability scans that are Operations security
to outside attacks and penetration tests on MNO infrastruc- performed on the DFS systems? - Technical vulnera-
(SD: Availability) ture to check exposure to attacks that bility management
could affect system availability.
MNO Network - Network exposure C108: Install and regularly update the Are the DFS systems updated to the latest Operations security
Security to outside attacks latest anti-malware software (if available) versions to protect against new threats? - Protection from
(SD: Availability) and make this available to end-users. malware
Consider application wrapping, which
can be employed with an MDM (Mobile
Device Management) solution to prevent
and remove malicious software and
applications.

(continued)
MNO, DFS Network - Discovery of new C109: MNOs along with DFS providers and Are the DFS systems patched against known Operations secu-
providers, Security exploits against payment services providers should patch vulnerabilities? rity - Technical
and Third deployed systems systems to the latest versions provided vulnerability
parties and the inability to by the vendor to defend against attacks
deploy solutions that have been developed from older
against these exploits vulnerabilities
(SD: Data Confidenti-
ality, Access Control,
Availability)
MNO, DFS Access - Discovery of new C110: Providers and MNOs should have Are there policies and processes in place to Operations security
providers, control exploits against contingency plans in place with vendors to manage a new threats and attacks to the DFS - Technical vulnera-
and Third deployed systems quickly acquire patches and system reme- systems? bility management
parties and the inability to diation if a zero-day attack has been found
deploy solutions in the wild. Part of this strategy involves
against these exploits the proper use of backups.
(SD: Data Confidenti-
ality, Access Control,
Availability)
MNO Network - Insecure devices C111: MNOs should monitor devices used Are all devices used to connect to DFS sys- Operations security
Security connected to the DFS to connect to or otherwise access the tems scanned for threats and checked for the - Technical vulnera-
infrastructure (SD: DFS system to ensure that such devices latest software patches? bility management
Data Integrity) have the latest patches, updated antivirus
software, are scanned for rootkits and
key loggers, and do not support network
extenders.
Authentica- - Overly permissive C115: Before authenticating DFS users, Is the DFS provider checking the IMSI of Access control
tion access to the DFS when possible, validate the IMSI, device, mobile numbers used for DFS transactions to Policy - User access
infrastructure (SD: and location, and IP address of the user protect against SIM swaps? management
Authentication) to establish their identity and to prevent
unauthorized access to the network
infrastructure.
Third-Party Fraud - Inadequate transac- C116: Payment service providers should Do the DFS customers get alerts when DFS Access control
Provider detection tion verification (SD: ensure that companion general-purpose transactions are performed on their accounts? Policy - User access
Non-Repudiation) reloadable cards linked to DFS accounts management
require the use of EMV chips with card-
holder verification methods, such as PINs
or biometrics, when practical, and that all
transactions result in an alert to customers.
DFS Privacy and - Inadequate over- C117: DFS providers should ensure that Is there proper segregation of data Asset management
Provider Confidenti- sight and controls in customer data in production environments implemented for tests and production - Media handling
ality test environments is not used in test environments unless environments?
(SD: privacy) anonymized according to best practices.
Are there processes that limit the use of
Conversely, test data should not be
customer data for test purposes? Such as data
migrated to the product.
anonymization.
Third-Party Privacy and - Exposure of cus- C118: Third-party providers should restrict Are there processes that limit the data shared Asset management
Provider Confidenti- tomer-sensitive the sharing of information with other par- with third parties when transactions are being - Media handling
ality information in trans- ties such as payment service providers and performed?
actions or through DFS providers to the minimum required to
APIs (SD: privacy) assure the integrity of the transaction.
Third-Party Privacy and - Insufficient data C119: Providers should ensure that cus- Do event logs contain customer-sensitive Operations secu-
Provider Confidenti- protection controls tomer-sensitive data is removed from data such as PINs? rity - Logging and
ality (SD: privacy) environments such as trace logs (for exam- monitoring
ple, cash retrieval voucher codes, bank
account numbers, and credentials). Use
place holders whenever possible to repre-
sent this data in log files.
This audit checklist table [4] above is available to download in excel using this link: https://itu.int/en/ITU-T/extcoop/
figisymposium/Documents/Digital%20Financial%20Services%20security%20audit%20checklist.xlsm

4 SECURITY AUDIT CHECKLIST
4.1 Access Control 4.1.14 Has the DFS provider set USSD and STK DFS
4.1.1 Are login credentials of terminated DFS sessions to automatically disconnect after a set peri-
administrators, agents and users deactivated. Are od of user inactivity?
dormant DFS accounts deactivated? 4.1.15 Is the DFS provider performing real time
4.1.2 Are default system accounts removed from device validation before transaction processing?
the DFS system and all systems that connect to DFS 4.1.16 Is the password transmitted securely? Is the
systems? user required to change password after first time
4.1.3 Are DFS vendor and support system login?
accounts deactivated after support duties are 4.1.17 Is there a maximum number of failed login
completed? attempts set before account is locked?
4.1.4 Are the following logical controls set for DFS 4.1.18 Is there a sufficient way of validating user
user sessions: i) auto logouts and session time out identity before activating previously dormant
ii) Maximum failed password login attempts iii) Pass- accounts for example biometric validation?
word and PIN complexity. iv) Password/PIN reuse
periods 4.2 Authentication
4.1.5 Are there procedures in place for the DFS 4.2.1 Are processes and policies in place to ensure
provider to detect suspicious SIM swaps and SIM that identity verification is in place prior to SIM swap
recycling? operations? Are there technical mechanisms in place
4.1.6 Are there controls in place to prevent multi- to prevent any leakage or transfer of information
ple simultaneous logons through multiple channels? until the SIM swap has been confirmed?
Is the DFS provider only allowing a single session per 4.2.2 Are DFS user authentication credentials
user at a time to connect to the DFS network? (multi- transmitted via a different channel/out-of-band?
ple sessions through different channels could be an (e.g., if account setup is done via USSD channel are
indication of a breach) one-time passwords transmitted via e-mail or voice
4.1.7 Are there controls to limit access to DFS calls?)
systems especially for remote login users? 4.2.3 Are there controls to check validate privi-
4.1.8 Are there policies and processes in place leged users? For example, through IP validation and
to manage a new threats and attacks to the DFS checking login time?
systems? 4.2.4 Does the DFS app stores or transmits
4.1.9 Are there sufficient physical and logical Personal Account Number/Sensitive Authentication
barriers to limit access to DFS infrastructure? Data in plain text over SMS/email?
4.1.10 Does the DFS provider use Role Based 4.2.5 Does the DFS provider enforce server-based
Access Controls? authentication for all access requests?
4.1.11 Does the DFS system have capability to 4.2.6 Does the mobile network operator perform
detect out-of-pattern transactions based on custom- biometric authentication before SIM swaps or SIM
er profile? For example: Does the DFS provider check replacement?
authenticity of transactions using location-based 4.2.7 Does the mobile network operator securely
validation of transactions, for example through store SIM data like IMSI, Kc and Ki?
geo-velocity tracking or other means? 4.2.8 Is multi factor used for authenticating users?
4.1.12 Has the DFS provider limited concurrent 4.2.9 Is multifactor authentication used when
user logins and provided the option for customers connecting to DFS accounts?
to opt into other login channels? For example, are 4.2.10 Is the DFS provider able to detect a SIM
customers who use USSD able to optionally choose swap or SIM change for a DFS account?
to use a DFS app channel before the DFS provider 4.2.11 Is the DFS provider checking the IMSI of
activates access through this channel? mobile numbers used for DFS transactions to protect
4.1.13 Has the DFS provider set a dormancy period against SIM swaps?
after which inactive admin accounts are deactivat- 4.2.12 Is the DFS provider involved in the SIM recy-
ed? Are all inactive dormant internal staff and API cling process for DFS accounts?
accounts deactivated? 4.2.13 Is the DFS provider performing XML vali-
dation of data through APIs and USSD requests?

E.g., input validation, amounts, special characters in 4.4.7 Do the DFS customers get alerts when DFS
amounts, currency checks etc. transactions are performed on their accounts?
4.2.14 Is there additional authorisation and authen- 4.4.8 Do trace logs and event data records
tication for high value transactions and changes on capture/store sensitive user data? (e.g., are customer
DFS user accounts? For example, what additional PINs stored in EDRs)
checks are done when increasing transaction limits? 4.4.9 Does the app store transactions for later
4.2.15 Does the DFS system have capability to transmission?
detect out-of-pattern transactions based on custom- 4.4.10 Does the DFS provider implement Role
er profile? Are the DFS provider performing checks Based Access Controls?
based on user transactions profile? E.g., agent shops 4.4.11 Is there a mechanism in place to review
performing late transactions, DFS users perfuming administrative privileges?
transactions in two different locations? 4.4.12 Is there more than one person required to
complete a critical DFS tasks?
4.3 Availability
4.3.1 Are there policies in place to assure manage- 4.5 Network Security
ment during system downtime? 4.5.1 Are all devices used to connect to DFS
4.3.2 Are there end to end tests been performed systems scanned for threats and checked for the
after changes or upgrades to the DFS systems? End latest software patches?
to end tests may include capacity tests, security 4.5.2 Are code changes tested and approved
tests, QoS tests, user acceptance tests etc. before moving it into production? For example, user
4.3.3 Are there regular vulnerability scans that are and internal acceptance certificates that show that
performed on the DFS systems? the code was tested.
4.3.4 Are there systems in place to ensure service 4.5.3 Are encryption keys were changed from
availability? Example (service redundancy) Are there default at installation? Are default SNMP strings
reports and utilities to measure system response changed?
time and down time? 4.5.4 Are the clocks within the DFS ecosystem
4.3.5 Are there systems to measure quality of synchronized?
service and quality of experience? Do the QoS and 4.5.5 Are the DFS systems patched against known
QoE conform to the standards for DFS? vulnerabilities?
4.3.6 Does the DFS provider have regular sched- 4.5.6 Are the DFS systems updated to the latest
uled backups? Are the backups encrypted and stored versions to protect against new threats?
on an offsite location? 4.5.7 Are the encryption algorithms and keys used
are strong enough to protect customer PINs and
4.4 Fraud Detection data?
4.4.1 Are DFS logs stored securely in a tamper 4.5.8 Are the firewall rules adequately configured?
proof module? E.g., SIEM e.g. port whitelisting, packet filtering
4.4.2 Are there mechanisms in place to detect 4.5.9 Are there adequate protections against
data modification and tampering on the database? network attacks like firewalls and traffic filters with
4.4.3 Are there mechanisms to detect SMS and proper configurations?
call spoofing? E.g., CLI analysis? 4.5.10 Are there logical boundaries that limit
4.4.4 Are there sufficient controls to review and access to the DFS systems from all other systems?
approve for critical changes on accounts? e.g., is (For example, are other unauthorized internal users
there maker-checker and approval process before logically and/physically limited on the network from
changes are made? accessing DFS processing systems)
4.4.5 Are there sufficient mechanisms to monitor 4.5.11 Are there operational controls to detect
transactions processed through payment APIs? Does threats associated with APIs? Are there controls in
the DFS provider have nondisclosure agreements place to detect rouge/malicious APIs?
pertaining to customer sensitive data with third 4.5.12 Are there pending transactions, duplicate
parties? Are there strong cryptographic algorithms transactions in the DFS system? Has the transaction
used when transferring data with third parties? been fully executed?
4.4.6 Do the audit logs provided sufficiently track 4.5.13 Are there procedures in place to moni-
all changes on the DFS system or MNO systems that tor software updates and are the updates installed
affect DFS services? securely?

4.5.14 Are there technical controls in place to limit Are certificates and other cryptographic information
exposure of internal DFS systems addresses (like protected by operating system controls?
database IP addresses? 4.6.3 Are digital signatures used to identify third
4.5.15 Does the DFS provider have a mechanism in party providers that connect to the DFS systems?
place to securely store cryptographic keys? 4.6.4 Are the cryptographic libraries used by the
4.5.16 Does the MNO enforce use of the Personal operating system or by the application correct-
Unlock Key on SIM cards to reduce the risk associat- ly designed and implemented and are they up to
ed with stolen SIMs that are used for DFS? date? Do the cryptographic libraries support strong
4.5.17 Does the MNO have a firewall in place to cryptographic ciphersuites and do they prevent or
detect and protect against external SS7 based discourage use of weak ciphersuites? Are hashing
attacks? For example (firewall protection against algorithms used that have not been deprecated and
subscriber traffic interception, unauthorized USSD are adequate digest lengths supported? (Anything
and SM use) less than SHA512 is considered weak today. MD5 and
4.5.18 Does the MNO operator have controls SHA1 have been broken.) For symmetric encryption
in place to limit access to MAP tracing and use of ciphers, are strong ciphers used and are adequate
protocol analysers on the internal network? (SMS key lengths supported? (For example, AES is
and USSD messages are transmitted in plain text in considered secure to use while 3-DES is no longer
the MAP protocol) a preferred cipher because of the SWEET-32 attack,
4.5.19 Has MNO implemented the SS7 and diame- and it is encouraged to move away from it to AES
ter signaling controls to protect against SS7 vulnera- as soon as possible.) - For public-key encryption,
bilities? are key lengths chosen to be an appropriate size for
4.5.20 Has the use of known weak ciphers been the public key algorithm being used? Are the criteria
discontinued? Has the deployment been prepared used for selecting cryptographic algorithms and key
for new ciphers? sizes based on public and well-examined standards?
4.5.21 Is the DFS provider performing input valida- (For example, NIST 800-57 special publication has
tion checks? guidelines on minimum key sizes for each algorithm
4.5.22 Is the DFS provider performing user transac- and how long this key size is good for)
tion geo-velocity checks before transaction process- 4.6.5 Are the encryption algorithms and keys used
ing? are strong enough to protect customer PINs and
4.5.23 Is there adequate monitoring of traffic for data?
internet facing DFS applications? 4.6.6 Are there processes that limit the data
4.5.24 Is there regular penetration testing of the shared with third parties when transactions are being
DFS systems? performed?
4.5.25 Is TLS encryption used secure? i.e., v.12 or 4.6.7 Are there security guidelines followed when
higher (July 2020) Does the app use latest versions disposing of DFS related data?
of TLS? Does the app use any deprecated TLS 4.6.8 Do event logs contain customer-sensitive
version? data such as PINs?
4.5.26 Is transaction validation performed using 4.6.9 Does the application or underlying operat-
secure OTP? ing system provide support for remote wipes of DFS
data or of the mobile device, and are there mecha-
4.6 Privacy & Confidentiality nisms in place to ensure that data is encrypted in the
4.6.1 Are digital signatures used by DFS appli- event of device loss or theft?
cations or by third-party providers? Are the digital 4.6.10 Has all sensitive consumer data been
signatures based on sufficiently strong cryptograph- encrypted by the application or the operating
ic algorithms and key sizes? Are the implementa- system? Are unencrypted versions of the data
tions of the cryptographic algorithms secure and up accessible in the device, for example, in temporary
to date and do they provide sufficient randomness? buffers or in memory? Is all information sent over a
(For example, strong digital signature algorithms network connection encrypted with a strong encryp-
include RSA, DSA, and ECDSA. Elliptic-curve cryp- tion cipher? (See C17 for more discussion of what
tographic algorithms can use shorter keys to provide comprises a strong encryption cipher.)
equivalent security to other ciphers.) 4.6.11 Have strong encryption ciphers and integrity
4.6.2 Are procedures in place to assure the trust- protection mechanisms such as message authentica-
worthiness and protection of private and secret keys? tion codes been used for data stored on the device

and when data is communicated to backend DFS 4.6.16 Is there a monitoring mechanism in place to
systems? (See C17 for a discussion of strong encryp- track data sharing through APIs? Are there controls
tion algorithms.) Are policies in place to assure the in place to prevent data leakage?
reaction of sensitive customer confidential informa- 4.6.17 Is there limitation on customer sensitive
tion? information shared during transaction processing
4.6.12 Is test data and test user accounts deleted with third parties? (e.g., Only information needed for
from the production environment? processing the transaction is shared with the third
4.6.13 Is the DFS data and forms used for customer party)
registration securely stored, transmitted, and stored 4.6.18 Is there proper segregation of data imple-
to prevent any data leakages using RBAC, data mented for tests and production environments? Are
encryption etc.? there processes that limit the use of customer data
4.6.14 Is the TLS lifetime certificate up to date? I.e., for test purposes? Such as data anonymization.
the certificate age should be less than 825 days
4.6.15 Is there a mechanism in place to ensure that
data-at-rest is encrypted and stored securely?

5 BIBLIOGRAPHY
[1] K. Butler and V. Mauree, "Digital Financial Service Security Assurance Framework," https://www.itu.int/en/
ITU-T/extcoop/figisymposium/Documents/ITU_SIT_WG_Technical%20report%20on%20Digital%20Financial
%20Services%20Security%20Assurance%20Framework_f.pdf.
[2] "Information Security Management" https://www.iso.org/isoiec-27001-information-security.html .
[3] A. Klinger, "SS7 vulnerabilities and mitigation measures for Digital Financial Services transaction," http://itu
.int/en/ITU-T/extcoop/figisymposium/Documents/ITU_SIT_WG_Technical%20report%20on%20the%20SS7
%20vulnerabilities%20and%20their%20impact%20on%20DFS%20transactions_f.pdf .
[4] "Digital Financial Services audit checklist,"https://itu.int/en/ITU-T/extcoop/figisymposium/Documents/Digital
%20Financial%20Services%20security%20audit%20checklist.xlsm.

International Telecommunication Union
Place des Nations
CH-1211 Geneva 20
Switzerland

Digital Financial Services Security Audit Guideline

Uploaded by

Copyright:

Available Formats

Digital Financial Services Security Audit Guideline

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Digital Financial Services Security Audit Guideline

Uploaded by

Copyright:

Available Formats

SECURITY, INFRASTRUCTURE AND TRUST WORKING GROUP

Digital Financial Services

REPORT OF SECURITY WORKSTREAM

Digital Financial Services

The Financial Inclusion Global Initiative (FIGI) is a three-year program implemented in

Digital Financial Services security audit guideline 3

3 DFS security assurance framework controls and audit guideline����������������������������9

Digital Financial Services security audit guideline 5

API Application Programming Interface

6 Digital Financial Services security audit guideline

2 DFS SECURITY AUDIT GUIDELINE

Digital Financial Services security audit guideline 7

The DFS security audit guideline is structured in the format below:

8 Digital Financial Services security audit guideline

Digital Financial Services security audit guideline 9

10 Digital Financial Services security audit guideline

Digital Financial Services security audit guideline 11

12 Digital Financial Services security audit guideline

Digital Financial Services security audit guideline 13

b) If there is an indication of a SIM swap,

14 Digital Financial Services security audit guideline

Digital Financial Services security audit guideline 15

16 Digital Financial Services security audit guideline

Digital Financial Services security audit guideline 17

18 Digital Financial Services security audit guideline

Digital Financial Services security audit guideline 19

20 Digital Financial Services security audit guideline

Digital Financial Services security audit guideline 21

22 Digital Financial Services security audit guideline

Digital Financial Services security audit guideline 23

24 Digital Financial Services security audit guideline

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

3 DFS security assurance framework controls and audit guideline��9