Navigating Cloud Security - M-Tiba Case Study (Part 2)

 Disclaimer. The views, assessments, and observations presented in this article are provided strictly for educational and analytical purposes, based on publicly available information and professional expertise. Defthon is not affiliated with, funded by, or acting on behalf of M-TIBA, any of its partners, competitors, government agencies, or any other stakeholder mentioned or implied.

This analysis is vendor-neutral and non-partisan. It does not seek to assign blame, validate unverified claims, or reach definitive conclusions while official investigations are ongoing. All references to entities, systems, or potential impacts are intended solely to support high-level risk awareness, resilience building, and the advancement of cybersecurity best practices.

Still referring to the case of  M-TIBA, the platform likely operates on a hybrid infrastructure with services distributed across multiple environments, including different cloud providers with diverse underlying technologies, as well as several third-party integrations. This level of complexity introduces a wide range of risks, and as a result, defining and managing security responsibilities becomes significantly more challenging.

Shared responsibility in Cloud Computing

Graphic created by the Cloud Security Alliance (CSA). 

In an Infrastructure as a Service (IaaS) model, the cloud provider (CSP) is responsible for securing the core infrastructure, while the customer(CSC) must safeguard everything they deploy on it. For Platform as a Service (PaaS), responsibility is shared; the provider secures the platform itself, and the customer handles how they configure and secure their applications on that platform. In a Software as a Service ( SaaS) model, the provider manages the majority of security controls, and the customer’s primary role is to oversee user access, permissions, and application-level entitlements.

It is crucial to note that the involvement of cloud brokers or other intermediaries can further blur responsibility boundaries. For example, let us assume that  M-TIBA uses a service like Cloudflare as an additional security for DDoS protection. While Cloudflare enhances security, it also introduces another stakeholder in the ecosystem.

In such situations, it becomes essential to clearly define each party’s obligations at a detailed level. Best practice in Cloud security recommends that:

• The Cloud Customer should develop a detailed responsibility matrix for every cloud deployment, ensuring it aligns with relevant compliance requirements.
• Cloud service providers (CSP) should thoroughly outline the security measures they offer. 

Shared Responsibility Example  (M-Tiba Case)

Using M-Tiba as our case study, security responsibilities will spread across different parties as illustrated below: 

A. M-Tiba as a Service (SaaS):
In this case, M-Tiba customers/users e.g patients and healthcare centers will be  responsible for protecting their data in the platform, configuring security controls such as 2FA, managing their profile just to name a few. On the other hand, M-TIBA will be responsible for securing the application itself, which includes protecting backend systems, enforcing strong API and data-governance controls, managing encryption, monitoring for fraud or abuse, and ensuring compliance with healthcare and financial regulations such as HIPAA and PCI-DSS where applicable. M-TIBA will also be required to maintain secure integrations with cloud providers, telcos, and third-party partners, while continually monitoring configurations, access, and platform-wide risks.

B. Cloud service providers (E.g AWS /Azure /Safaricom Cloud)

Referring the best practice recommendation by CSA, the specific responsibilities of the CSP will depend on the cloud service model M-TIBA subscribes to: 

• In an Infrastructure-as-a-Service (IaaS) model, the CSP will secure the infrastructure while M-TIBA will manage the operating system, applications, data, and configurations.
• in a Platform-as-a-Service (PaaS) model, the CSP will also secure the platform environment, while M-TIBA will focus on securing their applications, data, and API configurations. 

The Risk: Assumed Security

A major cloud-security failure point arises when parties assume that another stakeholder has implemented a specific control, when in reality:

• No one has implemented it.
• It exists only partially.
• It exists but is misconfigured.
• Or it exists but no one is monitoring it.

This leads to gaps such as:

• Missing encryption responsibilities (e.g., AWS handles storage encryption, but platform owners must encrypt in-transit APIs).
• Undefined incident response roles: who responds first when a breach is detected—cloud provider, telco, or the platform operator?
• Data residency uncertainty: cloud providers offer regions, but platform owners must enforce where PHI and financial data actually sit.
• Undefined responsibilities for log retention, audit trails, and fraud analytics.
• Weak API security when each party assumes the other is validating or rate-limiting requests.

Why Shared Responsibility Breakdown is Critical 

Organizations like M-Tiba or any other related Fintech and Healthcare organizations carry sensitive personally identifiable information (PII) , medical records,  financial information, and insurance data.
In such a sensitive environment:

• A single misconfigured S3 bucket can leak millions of records.
• A poorly secured telco connection can allow SIM-swap-based fraud.
• An insecure integration layer can be vulnerable to attacks.

When responsibility lines are not explicit and continually monitored, risks multiply across all integrated systems. 

Call to Action for Organization using Similar Deployments

The Cloud Service Provider (CSP) hosting similar deployments can adopt these best practices to ensure a secure and compliant environment:

• Clear responsibility matrices between M-TIBA (CSC), the CSP, and third-party integrations.
• Compliance with legal and regulatory frameworks such as ODPC, DPA 2019, GDPR, HIPAA, and PCI-DSS, depending on jurisdiction and sector.
• Contractual SLAs defining incident response, data handling, and escalation procedures.
• Regular joint security testing across all integrations, including penetration testing and configuration reviews.
• End-to-end visibility across all connected platforms and systems.
• Risk management to identify, assess, and mitigate potential security threats proactively.
• Identity and Access Management (IAM), including role-based access controls, least-privilege enforcement, and periodic review of permissions.
• Data encryption and key management, ensuring data is encrypted both in transit and at rest, with secure management of encryption keys.
• Monitoring, logging, and incident detection, with centralized audit trails for compliance and forensic purposes.
• Backup and disaster recovery testing, including automated backups and periodic recovery drills.
• Security awareness and training for M-TIBA users, healthcare staff, and administrators to reduce human error and phishing risks.
• API security and integration controls, including authentication, validation, and rate-limiting for all internal and third-party API calls.
• Patch and vulnerability management, ensuring timely updates and regular vulnerability scans for both infrastructure and applications.
• Third-party risk management, assessing the security posture of partners such as telcos, hospitals, and payment providers.
• Compliance reporting and auditing, with tools to generate reports for internal governance and regulatory audits.

Joke of the Day: After a life of cybercrime, how did the hacker get to heaven?

The password hadn’t been changed in 2000 years. 

For Help Write to: info@defthon.org