Task # | Task Description | Responsible | Notes / Doc | Jira Ticket | Review Result | Priority |
|---|---|---|---|---|---|---|
1 | Build the IT Governance / Management | SaFi | Link to Epic | Must have | ||
1.1 | Build the IT Steering Committee | SaFi | Link to User Story | Must have | ||
1.1.a | Assign members of the Steering Committee | SaFi | Link to Task | Must have | ||
1.1.b | Assign members to govern each guild | SaFi | Link to Task | Must have | ||
1.2 | Build the IT Audit Guild | SaFi | Link to User Story | Must have | ||
1.2.a | Assign members of this guild | SaFi | Link to Task | Must have | ||
1.2.b | Set expectations to this guild | SaFi | Link to Task | Must have | ||
1.3 | Build the IT Risk Guild | SaFi | Link to User Story | Must have | ||
1.3.a | Assign members of this guild | SaFi | Link to Task | Must have | ||
1.3.b | Set expectations to this guild | SaFi | Link to Task | Must have | ||
1.4 | Build the IT Project Guild | SaFi | Link to User Story | Must have | ||
1.4.a | Assign members of this guild | SaFi | Link to Task | Must have | ||
1.4.b | Set expectations to this guild | SaFi | Link to Task | Must have | ||
1.5 | Build the IT Operations Guild | SaFi | Link to User Story | Must have | ||
1.5.a | Assign members of this guild | SaFi | Link to Task | Must have | ||
1.5.b | Set expectations to this guild | SaFi | Link to Task | Must have | ||
1.6 | Build the Information Security Guild | SaFi | Link to User Story | Must have | ||
1.6.a | Assign members of this guild | SaFi | Link to Task | Must have | ||
1.6.b | Set expectations to this guild | SaFi | Link to Task | Must have | ||
1.7 | Build the IT Outsourcing / Vendor Management Guild | SaFi | Link to User Story | Must have | ||
1.7.a | Assign members of this guild | SaFi | Link to Task | Must have | ||
1.7.b | Set expectations to this guild | SaFi | Link to Task | Must have | ||
1.8 | Develop the IT KPI metrics | SaFi | Link to User Story | Can be planned | ||
1.8.a | for IT Audit KPI | SaFi | Link to Task | Can be planned | ||
1.8.b | for IT Risk KPI | SaFi | Link to Task | Can be planned | ||
1.8.c | for IT Project KPI | SaFi | Link to Task | Can be planned | ||
1.8.d | for IT Operations | SaFi | Link to Task | Can be planned | ||
1.8.e | for Information Security | SaFi | Link to Task | Can be planned | ||
1.8.f | for IT Outsourcing / Vendor Management | SaFi | Link to Task | Can be planned | ||
1.8.g | Approve all the IT KPI (c/o IT Steering Committee) | SaFi | Link to Task | Can be planned | ||
2 | Document IT policies, procedures, and standards | SaFi, VacuumLabs | Link to Epic | Can be planned | ||
2.1 | for IT Audit, aligned with MORB 148 Appendix 74 | SaFi | Link to User Story | Can be planned | ||
2.1.a | Develop audit program | SaFi | Link to Task | Can be planned | ||
2.1.b | Document audit process | SaFi | Link to Task | Can be planned | ||
2.1.c | Develop audit plan | SaFi | Link to Task | Can be planned | ||
2.2 | for IT Risk, aligned with MORB 148 | SaFi | Link to User Story | Can be planned | ||
2.2.a | Develop risk assessment process per IT Guild aligned with SaFi Risk | SaFi | Link to Task | Can be planned | ||
2.2.b | Document risk assessment process | SaFi | Link to Task | Can be planned | ||
2.3 | for IT KPI | SaFi | Link to User Story | Can be planned | ||
2.3.a | IT Steering Committee set expectations per IT Guild’s KPI | SaFi | Link to Task | Can be planned | ||
2.3.b | IT Guild’s align and document their KPI to IT Steering Committee | SaFi | Link to Task | Can be planned | ||
2.4 | for IT Project, aligned with MORB 148 Appendix 76 | SaFi | Link to User Story | Can be planned | ||
2.4.a | Develop IT Project framework - related to Task 4.1 | SaFi | Link to Task | Can be planned | ||
2.4.b | Document Project Methodology | SaFi | Link to Task | Can be planned | ||
2.4.c | Document Project Planning | SaFi | Link to Task | Can be planned | ||
2.4.d | Document Systems Development | SaFi | Link to Task | Can be planned | ||
2.4.e | Document System Acquisition | SaFi | Link to Task | Can be planned | ||
2.4.f | Document Change Management | SaFi | Link to Task | Can be planned | ||
2.4.g | Document System Testing | SaFi | Link to Task | Can be planned | ||
2.4.h | Document System Migration | SaFi | Link to Task | Can be planned | ||
2.4.i | Document Code Management | SaFi | Link to Task | Can be planned | ||
2.4.j | Systems Documentation | SaFi | Link to Task | Can be planned | ||
2.4.k | Document Post-Implementation Review | SaFi | Link to Task | Can be planned | ||
2.4.l | Document Disposal | SaFi | Link to Task | Can be planned | ||
2.5 | for IT Operations, aligned with MORB 148 Appendix 77 | SaFi | Link to User Story | Can be planned | ||
2.5.a | Document Technology Inventory Management | SaFi | Link to Task | Can be planned | ||
2.5.b | Document Patch Management | SaFi | Link to Task | Can be planned | ||
2.5.c | Document Network Management | SaFi | Link to Task | Can be planned | ||
2.5.d | Document Disposal of Media | SaFi | Link to Task | Can be planned | ||
2.5.e | Document Imaging Process | SaFi | Link to Task | Can be planned | ||
2.5.f | Document Event / Problem Management | SaFi | Link to Task | Can be planned | ||
2.5.g | Document User Support / Help Desk | SaFi | Link to Task | Can be planned | ||
2.5.h | Document Systems and Data Back Up | SaFi | Link to Task | Can be planned | ||
2.5.i | Document Systems Reliability Plan and Availability Metrics | SaFi | Link to Task | Can be planned | ||
2.5.j | Document Technology Recovery Plan and Recoverability Metrics | SaFi | Link to Task | Can be planned | ||
2.5.k | Document Disaster Recovery Testing | SaFi | Link to Task | Can be planned | ||
2.5.l | Document SLA’s | SaFi | Link to Task | Can be planned | ||
2.5.m | Document Self Assessment and Performance Monitoring | SaFi | Link to Task | Can be planned | ||
2.5.n | Document Capacity Planning | SaFi | Link to Task | Can be planned | ||
2.6 | for Information Security, aligned with MORB 148 Appendix 75 | SaFi | Link to User Story | Can be planned | ||
2.6.a | Develop Info Sec strategic plan | SaFi | Link to Task | Can be planned | ||
2.6.b | Develop Info Sec Program | SaFi | Link to Task | Can be planned | ||
2.6.c | Establish Security Culture | SaFi | Link to Task | Can be planned | ||
2.6.d | Compliance to PCI-DSS | SaFi | Link to Task | Can be planned | ||
2.6.e | Develop Info Sec Risk Management (ISRM) - related to 4.3 | SaFi | Link to Task | Can be planned | ||
2.6.f | Develop situational awareness and threat monitoring | SaFi | Link to Task | Can be planned | ||
2.7 | for IT Outsourcing / Vendor Management, aligned with MORB 148 Appendix 78 | SaFi | Link to User Story | Can be planned | ||
2.7.a | Develop and Document Outsourcing / Vendor Risk Management Program | SaFi | Link to Task | Can be planned | ||
2.7.b | Develop and Document Cloud Outsourcing Model | SaFi | Link to Task | Can be planned | ||
2.8 | for Electronic Banking / Electronic Products and Services aligned with MORB 148 Appendix 79 | VacuumLabs | Link to User Story | Must have | ||
2.8.a | Develop the Risk Assessment Plan for #3.5 | SaFi / VacuumLabs | Link to Task | Can be planned | ||
2.8.b | Implementation of Minimum Security Controls required by BSP | VacuumLabs | Link to User Story | Must have | ||
1. Implement Account Origination and Customer Verification | VacuumLabs | ONB & CUS:
| Must have | |||
2. Implement Authentication | VacuumLabs | https://safibank.atlassian.net/wiki/spaces/ITArch/pages/71434533/Authorize+an+action#Technical-Assessment (this is authentication verification despite the misleading title) | APP:
TX:
| Must have | ||
3. Implement MFA for transactions | VacuumLabs | https://safibank.atlassian.net/wiki/spaces/ITArch/pages/71762598/Authorize+with+face+matching+Step+up#Technical-Assessment | IAM:
TX:
TX:
| Must have | ||
4. Implement PKI assisted authentication and verification to uniquely identify the user session | VacuumLabs | covered by 2, 9, 19 | Must have | |||
5. Implement Authorization controls and Access privileges in Back Office | VacuumLabs |
| Must have | |||
6. Implement Attribute based access control on top of Role Based Access Control to Back Office features (Fine-grained user access rights appropriate to role matrix and implement in Okta) | VacuumLabs |
| Must have | |||
7. Implement input validation techniques to user inputs (both mobile and back office) | VacuumLabs | ONB & CUS:
BO:
TX:
NFR:
| Must have | |||
8. Implement high level or generic error messaging, no trace possible in user perspective. | VacuumLabs | TX:
NFR:
| Must have | |||
9. Implement secure session management during user activities | VacuumLabs | TODO: User b6b4a Verify if this is about security or user experience. Micronaut is escaping the input strings by default unless NativeQuery is used. |
| Accepted | Must have | |
10. Implement Vulnerability management | VacuumLabs | Note: Integration with trivvy, snyk, sonarcube upon every merge in GH. |
| Must have | ||
11. Implement Hardening practices | VacuumLabs | TODO: design workflow and tools Depends on the output of 10. Document the process of handling issues/vulnerabilities found in nr 10. Evidence of actually addressing the vulnerabilities found, or evidence that the current code is without vulnerabilities. Both infra & App. To be looked into after nr 10 is implemented. | To be looked into after task 10. is implemented. Depends on the output of 10. | Can be planned | ||
12. Establish SIEM (Creation of use cases in Grafana for security alerts and fraud detection) | VacuumLabs | TODO: design the SIEM platform User b6b4a to discuss the concrete requirements with Peter Luknár (Unlicensed) . Peter to provide options available with current tech stack (prometheus). Recommended minimum use cases in comment. | Link to Task | Can be planned | ||
13. Implement Audit trails to all components of SaFi applications | VacuumLabs | TX:
| Must have | |||
13.a Audit trails for user activities in mobile app (login, transactions, etc.) | VacuumLabs |
| Must have | |||
13.b Audit trails for back office user activities in Back office app (login, access to user details, performed activities) | VacuumLabs |
| Must have | |||
14. Implement RBAC to Back Office based on user Role matrix | VacuumLabs | is it covered in 5, 6 ? |
| Must have | ||
15. Implement customer awareness program | SaFi | Link to Task | Can be planned | |||
16. Implement Service Availability and Business Continuity (Disaster Recovery, Fail over mechanisms) | VacuumLabs | Link to Task | Can be planned | |||
17. Establish incident response and management procedures | VacuumLabs | Link to Task | Can be planned | |||
18. Implement customer privacy and confidentiality controls | VacuumLabs | TX: Encrypted bank statement PDF:
| Can be planned | |||
18.a Customer data masking in SIEM | VacuumLabs | Planned to be implemented: Data privacy |
| Can be planned | ||
18.b Encryption of customer data during exports from our databases, bank statements, ledgers, journals etc. | VacuumLabs | If the export contains PIIs, it needs to be password protected. | TX: Encrypted bank statement PDF:
| Must have | ||
18.c Customer privacy awareness | SaFi | Link to Task | Can be planned | |||
18.d Mechanism to authenticate official website to protect customers from spoofed or faked websites. |
SaFi | TODO: User b6b4a find out who will create the website. | Link to Task | Can be planned | ||
19. Implement data protection mechanism during data transmission in m-banking | VacuumLabs | transport: HTTPS | request signature:
| Can be planned | ||
20. Implement adoption of dual authentication process in transactions to ensure the security per level of risks | VacuumLabs |
| Must have | |||
21. Require customers to download its mobile online services and payment applications directly from third party repositories (e.g., Apple store, Google Play and Windows Market Place) | VacuumLabs |
| Must have | |||
22. Implement encryption of Sensitive data in storage, transmission and during processing (pointing to microservices processing of business logic) | VacuumLabs | TODO: Add documentation about:
| https://cloud.google.com/docs/security/encryption-in-transit https://cloud.google.com/docs/security/encryption/default-encryption | Must have | ||
23. Implementation of mandatory fund transfer transaction notification to customers through SMS and/or email for transactions exceeding a predefined amount; b. | VacuumLabs | TODO: Link a task which is specifically about fund transfer notification. If through email, the account number needs to be masked. Based on discussion with User b6b4a , there is no need for any masking of account numbers in the SMS. | TX :
Accounts:
| Must have | ||
24. Implementation of Holding period or delay before activation of a new soft token on a mobile device (BSP Memorandum M-2022-015) | VacuumLabs | Note: The customer should have some period of time to dispute the change. | Onboarding data collection: | Can be planned | ||
25. Implementation of Cooling-off period before the implementation of requests for key account changes such as those for the mobile number and email address. (BSP Memorandum M-2022-015) | VacuumLabs | The key account changes considered are now the changes in phone number and email. After a key account change request, a ticket should be created which would automatically apply the change after the cool-off period (e.g. 24hs), unless it is disputed by customer and cancelled via BOFE. Hence, BOFE should have functionality to see and cancel such requests. | ONB & CUS:
| Can be planned | ||
26. Implementation of Personalized SMS/Email OTP messages for device registration, fund transfer, and profile update, among others. (BSP Memorandum M-2022-015) | VacuumLabs | Neither phone numbers nor emails are used as authenticators. The OTPs are being sent to the phone number through SMS only when changing (or setting for the first time) the phone number. They are not being sent when authenticating any kind of operation. | Can be planned | |||
27. Customer notification through existing mobile or email registered with the BSFI whenever there is a request to change a customer’s mobile number, email address, or account credentials. (BSP Memorandum M-2022-015) | VacuumLabs | Note: Related to 25. | ONB & CUS:
| Must have | ||
28. Removal of clickable links in emails or SMS sent to retail customers followed by an information campaign that the BSFI will no longer be sending clickable links. (BSP Memorandum M-2022-015) | VacuumLabs / SaFi ? | TODO: User b6b4a Who should be doing this? Shouldn’t this be with the marketing team? | Link to Task | Can be planned | ||
29. Ensure strong authentication and authorization mechanisms through in-depth evaluation of API architecture and security standards. (M-2022-016) | VacuumLabs | VIDA use SHA-256 and ECDSA: signature verifier code constants in VidaConstants.kt |
updated by:
| Can be planned | ||
30. Encrypt sensitive API payload data using industry accepted encryption standards and versions. (M-2022-016) | VacuumLabs | Based on discussion with User b6b4a this should be about login credentials. As we are using asymmetric keys to authenticate, there is no shared secret and nothing to additionally encrypt on the application layer. This doesn’t affect logging in to BOFE through OKTA. See point 2 about Authentication | No work to be done | Must have | ||
31. Ensure that only necessary data/information are contained in API responses. (M-2022-016) | VacuumLabs | Part of the Data privacy requirements. |
| Must have | ||
32. Perform validation, filtering, and sanitization of all client-provided data and other data originating from integrated and partner systems. (M-2022-016) | VacuumLabs | Similar to point 7, but for integrations. The point is to protect our systems from harmful requests (security), not to help the integrators identify the issue (UX) |
| Must have | ||
33. Ensure that system and audit logs capture failed attempts, denied access, input validation failures, or any failures in security policy checks. (M-2022-016) | VacuumLabs | Login failed attempts: The app should send log requests to the backend whenever a wrong PIN was provided. TODO: Specify which use cases are subject to input validation failures - User b6b4a Recommended minimum use cases for input validation failures | TX:
TX:
| Must have | ||
34. Regularly update API inventory, purpose, and documentation to appropriately manage deprecated API versions and unintentional endpoint exposure. (M-2022-016) | VacuumLabs | We have a generated API documentation. The OpenAPI yaml spec is binding for the providers and consumers. | Documentation added | Must have | ||
35. Conduct regular assessments, hardening, and patching of all API servers. (M-2022-016) | SaFi | Note: Owner of the process should be SaFi ( User b6b4a ). TODO: Implement application vulnerability checking with snyk.io | Link to Task | Must have | ||
36. Enforce thresholds and rate-limiting API calls to prevent distributed denial-of-service (DDoS) attacks. (M-2022-016) | VacuumLabs | Note: Cloudflare does DDoS protection out of the box. All traffic from the public internet is coming in through Cloudflare | Link to Task | Must have | ||
3 | Perform Risk Process to IT (Governed by IT Risk Guild) | SaFi | Link to Epic | Can be planned | ||
3.1 | for IT Project | SaFi | Link to User Story | Can be planned | ||
3.2 | for IT Operations | SaFi | Link to User Story | Can be planned | ||
3.3 | for Information Security | SaFi | Link to User Story | Can be planned | ||
3.4 | for IT Outsourcing / Vendor Management | SaFi | Link to User Story | Can be planned | ||
3.5 | for Electronic Banking / Electronic Products and Services (c/o Information Security) | SaFi | Link to User Story | Can be planned | ||
3.5.a | identify Operational Risks and the controls to address it | SaFi | Link to Task | Can be planned | ||
3.5.b | identify Strategic Risks and the controls to address it | SaFi | Link to Task | Can be planned | ||
3.5.c | identify Reputational Risks and the controls to address it | SaFi | Link to Task | Can be planned | ||
3.5.d | identify Compliance Risks and the controls to address it | SaFi | Link to Task | Can be planned | ||
4 | Develop the IT Framework (Governed by IT Steering Committee) | SaFi | Link to Epic | Can be planned | ||
4.1 | for IT Project Framework | SaFi | Link to User Story | Can be planned | ||
4.2 | for IT Operations Framework | SaFi | Link to User Story | Can be planned | ||
4.3 | for Information Security Risk Management Framework | SaFi | Link to User Story | Can be planned | ||
4.4 | for IT Outsourcing / Vendor Management Framework | SaFi | Link to User Story | Can be planned | ||
4.5 | Approve the IT Framework (c/o IT Steering Committee) | SaFi | Link to User Story | Can be planned | ||
5 | Establish IT Reporting and Notification process and standard (c/o, IT Audit and Risk) | SaFi | Link to Epic | Must have | ||
5.1 | IT Operations Reporting | SaFi | Link to User Story | Must have | ||
5.2 | Information Security Reporting | SaFi | Link to User Story | Must have |
SM-39
SM-1835
SM-1129
SM-7167
SM-6119
