Data Protection - Secure Logging Standard and Guidelines

[godfreykutumela]

Goal:

The objective is to look at compliance to best practice standards with regards to audit logging within a Mojaloop implementation. We shall investigate the following:

1. Identify sources of audit logs
2. Document PII data according to GDPR and investigate PII data in Mojaloop logs
3. Document security logging standard
4. Make recommendations for audit logging configurations

Tasks:

• [x] Extract audit logs from Mojaloop services and analyze them for audit logging adequacy [ @rasputtintin ]
• [x] Explore Data Protection Standard for Data at Rest [ @rasputtintin ]
• [x] Explore Data Protection Standard for Data in Motion [ @rasputtintin ]
• [x] Identify and Document recommendations on audit logging in Mojaloop [ @rasputtintin ]
• [x] Document logging and forensic data controls [ @rasputtintin ]

Acceptance Criteria:

• [x] List of audit log sources
• [x] List and description of existing controls per area
• [x] Gaps identified and documented recommendations

Dependencies:

• Completion of Identification PII data

Accountability:

• Owner: @rasputtintin
• QA/Review: @godfreykutumela

[godfreykutumela]

PI 11 Backlog

[rasputtintin]

Task 1 - Extract audit logs from Mojaloop services and analyze them for audit logging adequacy :

• reviewed log extracts from the following scenarios: 1 - Fresh environment (infrastructure only) 2 - Environment with all Mojaloop components installed 3 - Environment after running end to end simulator tests (capture transactions in logs)

Findings:

• Mostly event logs (application behavior) captured in logs
• During environment initialization, database credentials and some identification artifacts are logged exposing sensitive information i.e. mysql root password
• There is almost nil audit information captured in the logs with default configurations
• Account lookup service and quoting service contain PII information in the logs

Mojaloop Log Analysis.docx

[rasputtintin]

Task 2 - Explore Data Protection Standard for Data at Rest: Data at rest is static data stored on hard drives that is archived or not often accessed or modified.

• Mojaloop data at rest consists of config files, information stored in databases and log files(operating system, containers, applications, infrastructure).
• This data also includes PII information as well as sensitive credentials and keys.

Data protection standard will involve access controls for the specific areas where data is stored in Mojaloop applications and infrastructure.

Recommended standards for non log information

The following protective controls are recommended for Mojaloop data at rest:

1. Conduct a data classification exercise to identify types of data at rest within Mojaloop, where they are stored and access controls for each data type.
2. Access control restrictions - Enforce access control restrictions using any of the following:
   • Application brokering via privileged account control tools
   • File based permissions
   • Network segmentation
   • Logical role based access control
3. Monitoring file access using a file integrity monitoring tool with alerts on suspicious activities
4. Exploring encryption of PII data to render it unreadable and unusable outside Mojaloop environment
5. Explore options for a vaulting solution to store sensitive authentication artifacts such as PKI keys, certificates e.t.c

OSS Data protection Standard - At Rest.docx

[rasputtintin]

Findings from Log Analysis of Mojaloop logs:

• Logging is done for infrastructure and applications
• Some application logs contain PII information
• Container/kubernetes logs do not capture user audit information - This requires a configurable audit policy to be applied
• Logs from all applications needs to be standardized preferably using a single logging framework
• Logs from Kafka do not contain audit information - This requires a configurable audit policy to be applied

Recommendations for audit logging in Mojaloop

Audit logs create records that help you track access to the Mojaloop environment. Therefore, a complete audit log needs to include, at a minimum all or a combination of:

• Event type, status, and/or error codes
• Service/command/application name
• User or system account associated with an event
• Device used (e.g. source and destination IPs, terminal session ID, web browser, etc.)
• User IDs
• Date and time records for when Users log on and off the system
• Terminal ID
• Access to systems, applications, and data – whether successful or not
• Files accessed
• Networks access
• System configuration changes
• System utility usage
• Exceptions
• Security-related events such as triggered alarms
• Protection system notifications (i.e. intrusion detection or anti-malware notifications)

OSS Audit logging Standard.docx

[godfreykutumela]

Thanks @rasputtintin I moved the story to final review.

[rasputtintin]

Made minor updates to document to add details of importance of Audit logging to the Mojaloop switch implementation:

Importance of Audit Logs Audit logging provides a historical account of all activities done by actors within a Mojaloop ecosystem. It will help Mojaloop implementations in the following ways:

1. Threat Detection Analytics – Through audit logs it is possible for Mojaloop switch operators to detect possible anomalies and identify malicious actions and trigger appropriate responses. This will go a long way in mitigating against possible fraud at DFSP and switch level.
2. Customer Forensics – In cases of queries from DFSPs, audit logs can assist give a forensic breakdown of transaction details as well as actions by authorized switch actors.
3. Compliance – Compliance standards such as GDPR have requirements to extract “all” customer data and also “delete” all customer data. For this to be possible, the audit data may also need to be extracted and preserved/deleted as appropriate. Audit logs are a critical requirement in most global best practice standards and regulatory frameworks such as PCI-DSS and GDPR.

OSS.Audit.logging.Standard v1.1.docx