Information Security Con

Impacted DFS Entity Group Risk and vulnerability

DFS Provider Access Control - Inadequate controls on user sessions (SD: access control)

DFS Provider
- Inadequate controls on dormant accounts (SD:
Access Control
authentication)

DFS Provider
- Failure to perform geographical location validation (SD:
Access Control
Com- munication security)

DFS Provider
- Inadequate user ver- ification of preferred user
Access control communication channels for DFS services (SD: Commu-
nication security)

DFS Provider
- Replay session based on tokens intercepted (SD: com-
Authentica- tion
munication security)

DFS Provider
Privacy and Confidenti- - Weak encryption algorithms for pass- word storage (SD:
ality data confidentiality)

MNO Access Control - Session timeouts not specified for DFS services

- User credentials for DFS application are sent in inherently

MNO Access control insecure ways like SMS or through agents (SD: data
confidentiality)

- Failure to perform login monitoring, leaving systems

Access control
susceptible to brute force attacks (SD: access control)

- Insecure transfer of customer credentials (SD: access

MNO Authentication
control)

- Exposure of internal network to external adversaries (SD:

MNO Network Security
access control)

DFS Provider
- Insufficient pro- tection of internal systems against external
Network Security
adversaries (SD: access control)

Privacy and - Reliance by DFS application on secu- rity libraries offered

DFS Provider
Confidentiality by operating systems (SD: communication security)
 Privacy and - Reliance by DFS application on secu- rity libraries offered
DFS Provider
Confidentiality by operating systems (SD: communication security)

- Weak encryption practices or sending sensitive information

Privacy and
MNO in clear text over inse- cure traffic channels like SMS and
Confidentiality
USSD (SD: communication security)

DFS Pro- vider and Third-

party providers
Fraud Detection - Inadequate data protection controls (SD: privacy)

DFS Pro-vider and Third-

party providers Privacy and - Exposure of cus- tomer sensitive information during
Confidentiality transactions or through APIs (SD: privacy)

DFS Pro-vider and Third-

party providers

Fraud Detection - Weak encryption on the API interfaces (SD: privacy)

- Network failure due to insufficient network capacity or to

MNO Availability
maintenance or design (SD: availability)

- Network failure due to insufficient network capacity or to

MNO Availability
maintenance or design (SD: availability)

DFS Provider
- Lack of monitoring of network traffic and individual network
Network Security
packets (SD: availabil- ity, communication security)

DFS Provider
Network Security - Enabling unnec- essary services (SD: data confidentiality)

DFS Provider
Network Security - Enabling unnec- essary services (SD: data confidentiality)

- Insufficient inter- nal controls on critical operations (SD:

DFS Provider Fraud detection
access control)

DFS Provider
Fraud detection - Lack of validation of data inputs (SD: data integrity)

DFS Provider

Access Control - Insufficient privilege management (SD: access control)

 Access Control - Insufficient privilege management (SD: access control)

- Addition of test data into production data (SD: data

Network Security
integrity)
DFS Provider

DFS Provider
- Addition of test data into production data (SD: data
Fraud detection
integrity)

DFS Provider
- Addition of test data into production data (SD: data
integrity)

DFS Provider
- Absence of logging, ability to alter logs, and insufficient
Fraud detection
infor- mation in logs (SD: non-repudiation)

DFS Provider
Network Security - Inaccurate and unsynchronised clocks (SD: data integrity)

- Weak over-the-air encryption (SD: com- munication

MNO Network security
security)

- Weak Calling Line Identification filtering (SD:

MNO Fraud detection
communication security)

DFS Provider
-Missing/Inad- equate account configuration and
Authentica- tion
authorisation controls (SD: authentication)

Privacy and confidenti- - Weak encryption algorithms used on data stored in the
Third-Party Providers
ality device and data transmitted (SD: privacy)

Privacy and confidenti- - Lack of encryption of communications (SD - communication

Third-Party Providers
ality security)
- Insufficient management of certificate or key materials (SD:
Privacy and confidenti- access control)
Third-Party Providers
ality

- DFS Provider or MNO System Failure leading to agents/

Third-Party Providers Availability
third parties reverting to offline processes (SD: availability)
DFS Provider
- Insecure and inade- quate access controls on user accounts
Authentica- tion
(SD: access control)

Access Control - Untested resto- ration practices (SD: availability)

DFS Provider
Access Control - Untested resto- ration practices (SD: availability)

DFS Provider
- Inadequate data controls like failure to implement
Availability atomicity of transactions, allow- ing them to exist in a
partially completed state (SD: data integrity)

DFS Provider - Inadequate data controls like failure to implement

Availability atomicity of transactions, allow- ing them to exist in a
partially completed state (SD: data integrity)

DFS Provider - Inadequate data controls like failure to implement

atomicity of transactions, allow- ing them to exist in a
partially completed state (SD: data integrity)

Privacy and confidenti- - Inadequate mecha- nisms to assure data integrity and over-
Third-Party Provider
ality re- liance on external trust anchors (SD: non-repudiation)

- Inadequate controls for user identification and verification

MNO Authentica- tion
before SIM swap and SIM recycling (SD: Authentication)

- Inadequate controls for user identification and verification

MNO Authentica- tion
before SIM swap and SIM recycling (SD: Authentication)

- Inadequate controls for user identification and verification

MNO Authentica- tion
before SIM swap and SIM recycling (SD: Authentication)

- Inadequate controls for user identification and verification

MNO Authentica- tion
before SIM swap and SIM recycling (SD: Authentication)

- Inadequate controls for user identification and verification

MNO Authentica- tion
before SIM swap and SIM recycling (SD: Authentication)

Privacy and Confidenti-

- Mobile device theft (SD: data confidentiality)
ality

DFS Provider

- Inadequacies in SIM swap and recycling process[ii] (SD:

Access control
data integrity)
 - Inadequacies in SIM swap and recycling process[ii] (SD:
Access control
data integrity)

DFS

- Unauthorized changes to system configuration and log files

Fraud Detection
and data (SD: Data Integrity)

DFS Provider
- Inadequate user access validation or user input validation
Authentica- tion
(SD: Authentication)

DFS Provider
- Inadequate user access validation or user input validation
Authentica- tion
(SD: Authentication)

DFS Provider
- Inadequate user access validation or user input validation
Authentica- tion
(SD: Authentication)

DFS Provider
- Inadequate user access validation or user input validation
Authentica- tion
(SD: Authentication)

- Inherent SS7 secu- rity weakness[iii] (SD: Communication

MNO Network Security
Security)

- Inherent SS7 secu- rity weakness[iii] (SD: Communication

MNO Network Security
Security)

- Interception of MO-USSD
MNO Access control
transactions (SD: Communication Security)

- Unprotected sensi- tive traffic and weak encryption

MNO Network security
practices (SD: Communication Security)

- Unprotected sensi- tive traffic and weak encryption

MNO Network Security
practices (SD: Communication Security)

- Unprotected sensi- tive traffic and weak encryption

MNO Network Security
practices (SD: Communication Security)

- Unprotected sensi- tive traffic and weak encryption

MNO Network Security
practices (SD: Communication Security)

Privacy and Confidenti- - Unprotected sensi- tive traffic and weak encryption
MNO
ality practices (SD: Communication Security)

- Unprotected sensi- tive traffic and weak encryption

MNO Access Control
practices (SD: Communication Security)

- Unprotected sensi- tive traffic and weak encryption

MNO Network Security
practices (SD: Communication Security)

DFS Provider
Privacy and confidenti- - Inadequate protec- tion of DFS customer registration data.
ality (SD: Authentication)

DFS Provider Network Security - Use of weak encryption. (SD: Communication Security)
 Network Security - Use of weak encryption. (SD: Communication Security)

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Network security
Access Control)

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Access control
Access Control)

DFS Provider
Privacy and confidenti- - Inadequate DFS user access control and monitoring. (SD:
ality Access Control)

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Authentica- tion
Access Control)

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Network Security
Access Control)

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Network Security
Access Control)

DFS
- Inadequate DFS user access control and monitoring. (SD:
Access control
Access Control)
Provider

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Access control
Access Control)

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Access control
Access Control)

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Fraud detection
Access Control)

DFS Provider
- Inadequate DFS user access control and monitoring. (SD:
Fraud detection
Access Control)

DFS Provider
Privacy and confidenti- - Inadequate DFS user access control and monitoring. (SD:
ality Access Control)

- Inadequate moni- toring of the wireless network (SD: Data

Network Security
Confidentiality)
DFS Provider

Privacy and confidenti- - Failure perform data destruction/erasing before disposing

Third-party
ality of devices (SD: Privacy)

- Inadequate col- laboration with the solution provider on the

Third- Party, DFS Provider Network Security security of mobile devices purchased (SD: Availability and
Confidentiality)
 - Inadequate col- laboration with the solution provider on the
Third- Party, DFS Provider Network Security security of mobile devices purchased (SD: Availability and
Confidentiality)

- Open undetected system application weaknesses (SD: Data

Third- Party, DFS Provider Fraud detection
Confidentiality)

Third- Party, DFS Provider Network Security - Network exposure to outside attacks (SD: Availability)

MNO Availability - Network exposure to outside attacks (SD: Availability)

MNO Network Security - Network exposure to outside attacks (SD: Availability)

MNO, DFS - Discovery of new exploits against deployed systems and

Network Security the inability to deploy solutions against these exploits (SD:
providers, and Third parties Data Confidenti- ality, Access Control, Availability)

MNO, DFS - Discovery of new exploits against deployed systems and

Access control the inability to deploy solutions against these exploits (SD:
providers, and Third parties Data Confidenti- ality, Access Control, Availability)

- Insecure devices connected to the DFS infrastructure (SD:

MNO Network Security
Data Integrity)

- Overly permissive access to the DFS infrastructure (SD:

Authentica- tion
Authentication)

Third-Party Provider Fraud detection - Inadequate transac- tion verification (SD: Non-Repudiation)

DFS Provider
Privacy and Confidenti- - Inadequate over- sight and controls in test environments
ality (SD: privacy)

Privacy and Confidenti- - Exposure of cus- tomer-sensitive information in trans-

Third-Party Provider
ality actions or through APIs (SD: privacy)

Privacy and Confidenti-

Third-Party Provider - Insufficient data protection controls (SD: privacy)
ality
Information Security Control Checkpoints- DFS
Control

C1: Set timeouts and auto logouts user sessions on DFS applications (logical
sessions). Within the application, ensure support for password complexity (enforced
by the server), set maximum unsuccessful login attempts, password history and reuse
periods, account lock-out periods to a reasonably minimal value to minimize the
potential for offline attack

C2: Require user identity validation for dormant DFS accounts users before re-acti-
vating accounts.

C3: Limit access to DFS services based on user locations (for example disable access
to DFS USSD codes while roaming, STK and SMS for merchants and agents) where
possible restrict access by region for DFS agents, where possible check that agent
and number performing a deposit or with- drawals are within the same serving area.

C4: Restrict DFS services by commu- nication channels (during registration customers
should optionally choose ser- vice access channel, USSD only, STK only, app only, or a
combination) attempted DFS access through channels other than opted should be
blocked and red-flagged.

C5: The DFS system should not trust any client-side authentication or authorization
tokens; validation of access tokens must be performed at the server-side.

C6: Store DFS user passwords using strong salted cryptographic hashing algorithms.

C7: Add session timeouts for USSD, STK application, and web access to DFS services.

C8: Where possible, DFS users should set their own passwords at registration and
they should be encrypted throughout the transmission to the DFS system. Where first-
time credentials are sent to the users, ensure DFS application credentials are sent to
users directly without third parties/ agents. Users should then be required to set new
passwords after the first-time login.

C12: Enforce a maximum number of login attempts to DFS accounts for back-end
users, merchants, agents and DFS cus- tomers on DFS systems (database, OS,
application)

C14: DFS providers should transmit the user authentication credentials securely over
a different channel (out of band).

C15: Use Network Address Translation to limit external exposure of DFS IP address
and routing information.

C16: Avoid direct access by external systems to the DFS backend systems by setting
up a DMZ that logically separates the DFS system from all other internal and external
systems.

C17: Ensure that security libraries offered by the operating system are correctly
designed and implemented and that the cipher suites they support are sufficiently
strong.
C17: Ensure that security libraries offered by the operating system are correctly
designed and implemented and that the cipher suites they support are sufficiently
strong.

C18: Ensure all sensitive consumer data such as PINs and passwords are encrypted,
when traversing the network and while the data is at rest.

C19: Remove customer sensitive data from trace logs. Examples of data that should
be removed include cash retrieval voucher codes, bank account numbers, credentials.
Instead, use place holders, where possible, to represent this data in logs.

C20: DFS providers should restrict sharing of DFS user information to the minimum
amount required for transactions with third parties and service providers.

C21: Monitor the use of APIs and encrypt all data shared with third parties. Addi-
tionally, put into place data management procedures and controls such as signed
non-disclosure agreements with payment service providers to avoid information/ data
leakage.

C22: The mobile network operator should take steps to ensure high network avail-
ability to allow access to DFS services through USSD, SMS, and the Internet.

C23: The MNO should perform technical capacity tests simulating different trans-
actions based on customer numbers, expected growth, expected number of
transactions, and expected peak periods to ensure continued system performance.

C24: The DFS provider should protect against network attacks by the use of fire- walls
and traffic filters and protect against DFS infrastructure threats by challenging
suspicious traffic through network admis- sion techniques and mechanisms such as
CAPTCHAs.

C25: Inbound internet traffic should be limited and continuously monitored.

C26: Set restrictive firewall rules by default, use port whitelisting, use packet filters,
and continuously monitor access to whitelisted/permitted ports and IP's.

C27: Where possible, limit critical changes using the four-eye principle (mak-

er-checker/two-person rule) for critical actions including (but not limited to) an
administrator creating, modifying, or

deleting another administrator account, changing, attaching and detaching of DFS

account from mobile number/user ID, and transaction reversal.

C28: DFS providers should ensure sufficient separation of duties for maker-approver;
for example, an administrator may not have access rights to both create and activate
a DFS account.

C29: Limit, control, and monitor physical access to sensitive physical DFS infrastruc-
ture. Physically isolate and put in place 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).
C29: Limit, control, and monitor physical access to sensitive physical DFS infrastruc-
ture. Physically isolate and put in place 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).

C30: The DFS provider should employ robust input validation routines on external-
facing services by checking out-of-range values and unpermitted char- acters in fields,
and by constraining and sanitizing input. Input validation should 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.

C31: Use database fingerprinting to detect tampering and modification of data after it
has been stored

C32: Ensure all test data is removed from code before it is migrated to the produc-
tion environment.

C33: DFS systems should use logging mechanisms, including capturing the prov-
enance of user actions or logging of critical actions into tamper-proof storage, secure
DFS system logs from tampering, editing, deleting, stopping.

C34: Ensure clock accuracy synchroniza- tion on all systems connected to the DFS
system. NTP and SNTP are some of the pro- tocols used to sync accurate time;
however, these must be deployed securely.

C38: Discontinue the use of A5/0, A5/1, and A5/2 GSM encryption ciphers. Closely
monitor results from the security and 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.

C39: MNOs should do CLI analysis for calls/ SMS to detect calls and SMS that may be
spoofed to appear like DFS provider calls.

C40: Require user authentication and authorization for high-risk account changes and
transaction and deny per- forming of transactions even when the device is logged in
until knowledge of PIN or password has been demonstrated.

C41: Sufficiently secure encryption should be employed for both data protection
within the mobile application and com- munication with backend DFS systems and
whenever possible, mask, truncate or redact customer confidential information.

C42: Use digital signatures to identify third parties connected to the DFS system when
transactions are performed.

C43: Use trusted keys and certificates to allow data exchange between DFS providers
and third parties and they should be protected from disclosure.

C44: Set procedural and technical controls for effective management during system
downtime with related service providers. For example, set controls to manage offline
transactions (e.g., SIM swaps) when access 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.
C45: Use multi-factor or multi-model authentication for access to DFS accounts.

C46: Deactivate and remove default accounts and credentials from databases,
applications, operating systems, and other access interfaces that interact with the
production DFS system.

C47: Review installation, vendor, support accounts, and access points to DFS systems
and infrastructure. All of those accounts should be deactivated or assigned appro-
priate user profiles.

C48: Perform end-to-end tests after any changes to the DFS, MNO, SP, and third- party
systems, include regression and capacity tests in the acceptance tests. Also, ensure
there is a fall-back/blackout plan.

C49: Have scheduled, regular backups for DFS systems. Regularly test and securely
store backups offline and offsite in an encrypted form.

C50: Use standard ACID (Atomicity, Consis- tency, Isolation, Durability) functionality of
the databases to ensure transaction integ- rity. DFS operations should either succeed
completely or fail completely. DFS provider should also ensure there are checks to
prevent duplicate transactions (unique transaction IDs, timestamps and use of
cryptographic nonce)

C51: DFS applications/3rd parties should support the use of digital signatures; a
secure digital signature provides irrefut- able evidence of the transaction's origin.
Digital signatures are only valid as long as the PKI has not been compromised and
must be tested with plans for assuring agil- ity. By demonstrating that signing keys
are adequately protected up to the root key, the DFS provider can withstand legal
chal- lenges about the authenticity of a specific user and disputed transactions.

C52: MNOs should ensure that an identity verification process is in place before SIM
swaps is performed.

C53: The user's identity should be verified using a combination of something they are,
something they have, or something they know. For example, with the presen- tation
of a valid ID, biometric verification, and knowledge about the DFS account details
before a SIM swap/ SIM replace- ment is performed.

C54: DFS and Payment Service Providers should be able to detect real-time when-
ever a SIM card with DFS services has swapped or replaced. And perform further
verification before any high-value trans- action or account changes are authorised
with new SIM.

C55: The mobile operator should safeguard and securely store SIM data like IMSI and
SIM secret key values (KI values).

C56: A mobile number recycling pro- cess should be in place that involves
communicating with DFS providers on

Mobile Subscriber Identification Numbers (MSIDN) being churned or recycled. (in 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.

C57: DFS users should have the ability to perform remote wipes on a mobile device
and encrypting their data in case the device is lost or stolen.

C58: DFS providers should ensure they have procedures in place to detect and avert
suspicious SIM swaps and SIM recycle by:
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.

C59: Protect against tampering and allow only online transactions

a) Protect and monitor DFS application files from tampering and changes using 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.

C60: Use strong multi-factor authentication for user and 3 rd party provider access to
DFS systems, e.g., token or biometrics, the use of multi-factor authentication to verify
system users increases non-repudiation

of origin.

C61: Check incoming data against expected values in API related data schema, for
USSD, perform XML validation .

C62: Use analytics systems to check user velocity between transactions, transaction
time of day access tracking for additional authorization validation checks.

C63: Regardless of the method used for producing receipts (e.g., e-mail, SMS, or
attached printer), the method should mask 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).
C70: Ensure all sensitive consumer data such as PINs and passwords are securely
stored with strong encryption algorithms within the internal network and while at rest
to mitigate internal threats against this data.

C71: Use firewalls to detect and limit attacks based on SS7 security flaws.

C72: Check if the IMEI of the device performing the transaction matches the
registered IMEI of the account holder's phone (a MITM system may clone the SIM with
a different IMEI)

C73: Monitor user velocity by comparing the location of the phone used to perform
transactions to the last reported location of the phone (last in/out SMS or call).

C74: MNO's should enforce the use of the Personal Unlocking Key (PUK) on the SIM
card for additional security in case the mobile device is lost or stolen.

C75: Control and monitor the use of MSC MAP tracing and protocol analysers on
USSD, SMS infrastructure to internal limit access to plain text SMS and USSD traffic in
transit

C76: Use 2-way Secure OTP to the original phone number to verify the legitimacy of
the transaction[iv]

C77: Employ strong cryptography practices to assure confidentiality and integrity of

data as it enters the DFS provider network and as it is processed and stored within
this environment.

C78: Limit number of DFS sessions per user. Allow a single session per user at a time
irrespective of the access channel (STK, USSD, or https); a DFS user account should
not be accessible using multiple channels simultaneously.

C79: The mobile operator should deploy SS7 and diameter signaling security con- trols
specified by the GSMA (FS.11, FS.07, IR.82, and IR.88) to limit threats due to SS7
attacks [3]

C80: Protect and guard customer data used for DFS registration, where physical forms
are used, store, and transmit the data securely.

C81: Use strong encryption standards like TLS encryption v1.2 and higher for API
communication.
C81: Use strong encryption standards like TLS encryption v1.2 and higher for API
communication.

C82: Extend threat detection to explicitly incorporate threats associated with APIs.

C83: Limit remote login access and mini- mize privileges to remote login sessions to
backend DFS systems.

C84: Limit the lifetime of TLS certificates to 825 days.

C85: Authenticate user IP, device, and login time for all privileged users, agents, and
merchants connecting to the DFS system. For example, configure a merchant and
agent access to the DFS system to be accessible only during open trading hours.

C86: Code and changes should be tested in the test environment before moving to
the production platform; the test environment should be physically and logically sepa-
rated from the production environment.

C87: To improve security, use a trusted tamper-resistant device like a Hardware

Security Module (HSM) to Securely manage the process and store cryptographic keys
to protect user PINs, transactions, tokens, money vouchers.

C88: Set user roles to define access rights based on the principle of least privilege.

C89: After termination of a user, agent, merchant, payment service providers or third
parties disable/deactivate respective accounts

C90: Set account dormancy period and disable dormant accounts at dormancy
maturity.

C91: Set schedules for logons and session limitations based on DFS roles. (session
limitations can include the maximum number of reversals per day based on the role)

C92: Limit control, monitor, and period- ically review privileged access to DFS
systems, including user addition, modifica- tion, and deletion.

C93: Monitor the use of APIs, and encrypt all data shared with third parties, put in
place data management procedures and controls like signed non-disclosure agree-
ments with payment service providers to avoid information/data leakage.

C94: Protect wireless transmissions per PCI DSS Requirements. Controls should
include, but are not limited to, the following:
- 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.

C95: DFS Providers/Merchants should consistently dispose of old devices. When the
solution provider provides guidance, 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.
C99: Merchants and DFS providers should require the following from their solution
provider:

- The solution provider should regularly update their payment application and indicate
to the merchant when updates are 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.

C100: The merchant should work with its solution provider to ensure that any audit or
logging capability is enabled. The solu- 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.

C101: DFS Applications should be sub- jected to regular security penetration scans
and penetration testing. In particular, applications should be designed to be robust
against phishing software.

C107: Perform regular vulnerability scans and penetration tests on MNO infrastruc-
ture to check exposure to attacks that could affect system availability.

C108: Install and regularly update the latest anti-malware software (if available) and
make this available to end-users.

Consider application wrapping, which can be employed with an MDM (Mobile Device
Management) solution to prevent and remove malicious software and applications.

C109: MNOs along with DFS providers and payment services providers should patch
systems to the latest versions provided
by the vendor to defend against attacks that have been developed from older
vulnerabilities

C110: Providers and MNOs should have contingency plans in place with vendors to
quickly acquire patches and system reme- diation if a zero-day attack has been found
in the wild. Part of this strategy involves the proper use of backups.

C111: MNOs should monitor devices used to connect to or otherwise access the DFS
system to ensure that such devices have the latest patches, updated antivirus
software, are scanned for rootkits and

key loggers, and do not support network extenders.

C115: Before authenticating DFS users, when possible, validate the IMSI, device, and
location, and IP address of the user to establish their identity and to prevent
unauthorized access to the network infrastructure.

C116: Payment service providers should ensure that companion general-purpose

reloadable cards linked to DFS accounts 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.

C117: DFS providers should ensure that customer data in production environments is
not used in test environments unless anonymized according to best practices.

Conversely, test data should not be migrated to the product.

C118: Third-party providers should restrict the sharing of information with other par-
ties such as payment service providers and DFS providers to the minimum required to
assure the integrity of the transaction.

C119: Providers should ensure that cus- tomer-sensitive data is removed from
environments such as trace logs (for exam- ple, cash retrieval voucher codes, bank
account numbers, and credentials). Use place holders whenever possible to repre-
sent this data in log files.
Checkpoints- DFS
Security audit question Applicable policy or procedure

Are the following logical controls set for DFS user sessions:

i) auto logouts and session time out

Access control Policy - System and application access
ii) Maximum failed password login attempts
control
iii) Password and PIN complexity.

iv) Password/PIN reuse periods

Is there a sufficient way of validating user identity before activating previously

Access control Policy - User access management
dormant accounts for example biometric validation?

Does the DFS system have capability to detect out-of-pattern transactions

based on cus- tomer profile?
Access control Policy - System and application access
For example: Does the DFS provider check authenticity of transactions using control
loca- tion-based validation of transactions, for example through geo-velocity
tracking or other means?

Has the DFS provider limited concurrent user logins and provided the option for
customers to opt into other login channels?
Access control Policy - System and application access
For example, are customers who use USSD able to optionally choose to use a control
DFS app channel before the DFS provider activates access through this
channel?

Does the DFS provider enforce server-based authentication for all access Access control Policy - System and application access
requests? control

Is there a mechanism in place to ensure that data-at-rest is encrypted and Data Security and Data Leakage Pre- vention
stored securely? Standard

Has the DFS provider set USSD and STK DFS sessions to automatically Access control Policy - System and application access
disconnect after a set period of user inactivity? control

Is the password transmitted securely? Is the user required to change password

Access control Policy - User access management
after first time login?

Is there a maximum number of failed login attempts set before account is Access control Policy - System and application access
locked? control

Are DFS user authentication credentials trans- mitted via a different

channel/out-of-band? (e.g. if account setup is done via USSD chan- nel are one-
Access control Policy - System and application access
time passwords transmitted via
control
e-mail or voice calls?)

Communications Security Policy - Network security

Are there technical controls in place to limit exposure of internal DFS systems management
addresses (like database IP addresses?

Communications Security Policy - Network security

management
Are there logical boundaries that limit access to the DFS systems from all other
systems? (For example, are other unauthorized inter- nal users logically
and/physically limited on the network from accessing DFS processing systems)

Are the cryptographic libraries used by the operating system or by the

application cor- rectly designed and implemented and are they up to date? Do
the cryptographic librar- ies support strong cryptographic ciphersuites 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.)

Cryptography policy - Cryptographic controls

For symmetric encryption ciphers, are strong ciphers used and are adequate
key lengths supported? (For example, AES is considered secure to use while 3-
Cryptography policy - Cryptographic controls
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)

Has all sensitive consumer data been encrypted by the application or the
operating system?

Are unencrypted versions of the data accessible in the device, for example, in Cryptography policy- Cryptographic controls
temporary buffers or in memory? Is all information sent over a network
connection encrypted with a strong encryption cipher? (See C17 for more
discussion of what com- prises a strong encryption cipher.)

Do trace logs and event data records capture/ store sensitive user data? (e.g.
Operations secu- rity - Logging and monitoring
are customer PINs stored in EDRs)

Is there limitation on customer sensitive infor- mation shared during transaction

Operations security policy - Operational procedures
processing with third parties? (e.g. Only information needed for processing the
and responsibilities
transaction is shared with the third party)

Are there sufficient mechanisms to monitor transactions processed through

payment APIs?
Does the DFS provider have nondisclosure agreements pertaining to customer
Operations security policy - Logging and monitoring
sensitive data with third parties?
Are there strong cryptographic algorithms used when transferring data with
third parties?
Are there systems in place to ensure service availability? Example (service
Information security incident management
redundancy)
Are there reports and utilities to measure system response time and down
- Redundancies
time?

Are there systems to measure quality of ser- vice and quality of experience?
System acquisition, development, and maintenance-
Security in development and support processes

Do the QoS and QoE conform to the stan- dards for DFS?

Operations security- Protection from malware

Are there adequate protections against net- work attacks like firewalls and
traffic filters with proper configurations?

Operations security- Protection from malware

Is there adequate monitoring of traffic for internet facing DFS applications?

Are the firewall rules adequately configured? e.g., port whitelisting, packet
Operations security- Protection from malware
filtering

Are there sufficient controls to review and approve for critical changes on
Access control Policy - System and application access
accounts? e.g., is there maker-checker and approval process before changes
control
are made?

Access control Policy - System and application access

Is there more than one person required to complete a critical DFS tasks?
control

Physical and environmental security - Secure areas

Are there sufficient physical and logical barri- ers to limit access to DFS
infrastructure?
Are there sufficient physical and logical barri- ers to limit access to DFS
infrastructure?

System acquisition, development,- Security in devel-

Is the DFS provider performing input valida- tion checks?
opment and support processes

Are there mechanisms in place to detect data modification and tampering on

Operations security - Logging and monitoring
the database?

System acquisition, development, and maintenance -

Is test data and test user accounts deleted from the production environment?
Test data

Are DFS logs stored securely in a tamper proof module? e.g., SIEM Operations security - Logging and monitoring

Operations secu- rity - Operational procedures and

Are the clocks within the DFS ecosystem synchronized?
responsibilities

Has the use of known weak ciphers been discontinued? Has the deployment
Communications security: Informa- tion transfer
been prepared for new ciphers?

Are there mechanisms to detect SMS and call spoofing? E.g., CLI analysis? Communications security: Informa- tion transfer

Is there additional authorisation and authen- tication for high value transactions
and changes on DFS user accounts? For example, what additional checks are Access control Policy - User access management
done when increasing transaction limits?

Have strong encryption ciphers and integrity protection mechanisms such as

message authentication codes been used for data stored on the device and
when data is com- municated to backend DFS systems? (See C17 for a
discussion of strong encryption
Cryptography policy- Cryptographic controls
algorithms.) Are policies in place to assure the reaction of sensitive customer
confidential information?

Are digital signatures used to identify third party providers that connect to the Access control Policy - System and application access
DFS systems? control

Are procedures in place to assure the trust- worthiness and protection of private
Access control Policy - System and application access
and secret keys? Are certificates and other cryp- tographic information
control
protected by operating system controls?

Operations secu- rity - Operational procedures and

Are there policies in place to assure manage- ment during system downtime?
responsibilities
Is multifactor authentication used when connecting to DFS accounts? Access control Policy - User access management

Are default system accounts removed from the DFS system and all systems that
Access control Policy - User access management
connect to DFS systems?

Are DFS vendor and support system accounts deactivated after support duties
Access control Policy - User access management
are completed?

System acquisition, development,and maintenance -

Security in devel- opment and support processes
Are end to end tests been performed after changes or upgrades to the DFS
systems? End to end tests may include capacity tests, security tests, Quality of
Service tests, user acceptance tests etc.

Does the DFS provider have regular sched- uled backups?

Operations security- Backup policy
Are the backups encrypted and stored on an offsite location?

Are there pending transactions, duplicate transactions in the DFS system?

Operations secu- rity - Operational procedures and
responsibilities
Has the transaction been fully executed?

Are digital signatures used by DFS appli- cations or by third-party providers? Are
the digital signatures based on sufficiently strong cryptographic algorithms and
key sizes? Are the implementations of the cryptographic algorithms secure and
Access control Policy - System and application access
up to date and do they provide sufficient randomness? (For example, strong
control
digital signature algorithms include RSA, DSA, and ECDSA. Elliptic-curve cryp-
tographic algorithms can use shorter keys to provide equivalent security to
other ciphers.)

Are processes and policies in place to ensure that identity verification is in place
prior to SIM swap operations? Are there technical mechanisms in place to
Access control Policy - User access management
prevent any leakage or transfer of information until the SIM swap has been
confirmed?

Does the mobile network operator perform biometric authentication before SIM
Access control Policy - User access management
swaps or SIM replacement?

Access control Policy - System and application access

Is the DFS provider able to detect a SIM swap or SIM change for a DFS account?
control

Does the mobile network operator securely store SIM data like IMSI, Kc and Ki? Asset management- Media handling

Is the DFS provider involved in the SIM recy- cling process for DFS accounts? Asset management- Media handling

Does the application or underlying operating system provide support for remote
wipes
Operations security - Operational procedures and
of DFS data or of the mobile device, and are there mechanisms in place to responsibilities
ensure that data is encrypted in the event of device loss or theft?

Are there procedures in place for the DFS provider to detect suspicious SIM Operations security - Operational procedures and
swaps and SIM recycling? responsibilities
Are there procedures in place for the DFS provider to detect suspicious SIM Operations security - Operational procedures and
swaps and SIM recycling? responsibilities

Operations security: Operational procedures and

Does the app store transactions for later transmission?
responsibilities

Access control Policy - System and application access

Is multi factor used for authenticating users?
control

Is the DFS provider performing XML valida- tion of data through APIs and USSD
requests? E.g., input validation, amounts, special charac- ters in amounts, Communications security - Information transfer
currency checks etc.

Does the DFS system have capability to detect out-of-pattern transactions

based on cus- tomer profile?
Access control Policy - System and application access
Are the DFS provider performing checks based on user transactions profile? E.g. control
agent shops performing late transactions, DFS users perfuming transactions in
two different locations?

Does the DFS app stores or transmits Personal Account Number/Sensitive

Asset management- Media handling
Authentication Data in plain text over SMS/email?

Are the encryption algorithms and keys used are strong enough to protect
Cryptography- Cryptographic controls
customer PINs and data?

Does the MNO have a firewall in place to detect and protect against external
Communica- tions security- Network security
SS7 based attacks? For example (firewall protection against subscriber traffic
management
interception, unau- thorized USSD and SM use)

Is the DFS provider performing real time device validation before transaction Access control Policy - System and application access
processing? control

Is the DFS provider performing user transac- tion geo-velocity checks before Access control Policy - System and application access
transaction processing? control

Does the MNO enforce use of the Personal Unlock Key on SIM cards to reduce
Communications security - Information transfer
the risk associated with stolen SIMs that are used for DFS?

Does the MNO operator have controls in place to limit access to MAP tracing
and use of protocol analysers on the internal network? (SMS and USSD Access control Policy - User access management
messages are transmitted in plain text in the MAP protocol)

Is transaction validation performed using secure OTP? Access control Policy - User access management

Are the encryption algorithms and keys used are strong enough to protect
Cryptography- Cryptographic controls
customer PINs and data?

Are there controls in place to prevent mul- tiple simultaneous logons through
multiple channels?
Access control Policy - System and application access
Is the DFS provider only allowing a single ses- sion per user at a time to connect control
to the DFS network? (multiple sessions through different channels could be an
indication of a breach)

Communica- tions security- Network security

Has MNO implemented the SS7 and diameter signaling controls to protect management
against SS7 vulnerabilities?

Is the DFS data and forms used for customer registration securely stored,
transmitted, and stored to prevent any data leakages using RBAC, data Asset management- Media handling
encryption etc.?

Is TLS encryption used secure? i.e., v.12 or higher (July 2020)

Does the app use latest versions of TLS? Communications security - Information transfer
 Communications security - Information transfer

Does the app use any deprecated TLS version?

Are there operational controls to detect threats associated with APIs?

Operations security- Technical vulnerability
management
Are there controls in place to detect rouge/ malicious APIs?

Are there controls to limit access to DFS sys- tems especially for remote login
Access control Policy - User access management
users?

Is the TLS lifetime certificate up to date? I.e. the certificate age should be less Communica- tions security- Network security
than 825 days management

Are there controls to check validate privileged users? For example, through IP
Access control Policy - User access management
validation and checking login time?

Are code changes tested and approved before moving it into production? For
System acquisition, developmentand maintenance-
example, user and internal acceptance certificates that show that the code was
Security in development and support processes
tested.

Cryptography- Cryptographic controls

Does the DFS provider have a mechanism in place to securely store
cryptographic keys?

Does the DFS provider use Role Based Access Controls? Access control Policy - User access management

Are login credentials of terminated DFS administrators, agents and users

Access control Policy - User access management
deactivated? Are dormant DFS accounts deactivated?

Has the DFS provider set a dormancy period after which inactive admin
accounts are deac- tivated? Are all inactive dormant internal staff and API Access control Policy - User access management
accounts deactivated?

Does the DFS provider implement Role Based Access Controls? Access control Policy - User access management

Is there a mechanism in place to review administrative privileges? Access control Policy - User access management

Communications security- Network security

Is there a monitoring mechanism in place to track data sharing through APIs?
management

Are there controls in place to prevent data leakage?

Are encryption keys were changed from default at installation? Are default
SNMP strings changed? Communica- tions security- Network security
management

Operations security- Protection from malware

Are there security guidelines followed when disposing of DFS related data?

Are there procedures in place to monitor soft- ware updates and are the Operations security- Technical vulnerability
updates installed in a securely? management
Are there procedures in place to monitor soft- ware updates and are the Operations security- Technical vulnerability
updates installed in a securely? management

Do the audit logs provided sufficiently track all changes on the DFS system or Operations security- Technical vulnera- bility
MNO sys- tems that affect DFS services? management

Operations security- Technical vulnera- bility

management
Is there regular penetration testing of the DFS systems?

Operations security- Technical vulnera- bility

management
Are there regular vulnerability scans that are performed on the DFS systems?

Operations security- Protection from malware

Are the DFS systems updated to the latest versions to protect against new
threats?

Are the DFS systems patched against known vulnerabilities? Operations secu- rity - Technical vulnerability

Operations security- Technical vulnera- bility

Are there policies and processes in place to manage a new threats and attacks management
to the DFS systems?

Operations security- Technical vulnera- bility

Are all devices used to connect to DFS sys- tems scanned for threats and management
checked for the latest software patches?

Is the DFS provider checking the IMSI of mobile numbers used for DFS
Access control Policy - User access management
transactions to protect against SIM swaps?

Do the DFS customers get alerts when DFS transactions are performed on their
Access control Policy - User access management
accounts?

Is there proper segregation of data implemented for tests and production

Asset management- Media handling
environments?

Are there processes that limit the use of customer data for test purposes? Such
as data anonymization.

Asset management- Media handling

Are there processes that limit the data shared with third parties when
transactions are being performed?

Do event logs contain customer-sensitive data such as PINs? Operations security - Logging and monitoring