Cloud Security Framework

Summary

BeeTcore protects the confidentiality, integrity, and availability of every platform in its care through layered controls at the edge, platform, application, and access levels. The framework is aligned to the principles of ISO 27001, addresses the OWASP Top 10 in every build, and follows the data protection laws that apply to each client, including the GDPR and the Nigeria Data Protection Act 2023. Responsibilities between BeeTcore, hosting providers, and clients are defined for every engagement.

1. Framework alignment

• ISO 27001 principles: security is managed as a system of defined controls, clear ownership, and continual improvement.
• OWASP Top 10: every build addresses the most critical web application security risks, as set out in the Secure Web Development Framework.
• Data protection law: the EU and UK GDPR, the Nigeria Data Protection Act 2023, and other laws that apply to each client’s data and users.

2. Shared responsibility

Security on a hosted platform is shared, and each party’s role is confirmed in the project agreement:

• Hosting provider: physical data centres, network infrastructure, and, depending on the hosting model, the underlying servers, as set out in Section 4.
• BeeTcore: platform configuration, application security, access control, patching, backups, and monitoring.
• Client: their own user accounts and credentials, the content they publish, and approval of changes.

3. Edge and network protection

Cloudflare sits in front of platforms to filter traffic before it reaches the server: web application firewall, DDoS mitigation, and bot management. All traffic is protected by TLS encryption (the standard behind SSL certificates). Details are set out in the Denial of Service Detection and Mitigation Controls and the Intrusion Detection or Prevention Systems documents.

4. Patching and updates

• Applications, plugins, themes, dependencies, and platform cores are monitored for security updates and published vulnerabilities.
• Updates are tested before they are applied, following the Change Management Framework. Fixes for actively exploited vulnerabilities are applied as emergency changes.

Responsibility for operating system and server patching depends on the hosting model, and is confirmed in the project agreement:

• Self-managed servers: BeeTcore patches the operating system and server software.
• Managed hosting: the hosting provider patches the underlying servers.
• Major cloud platforms: responsibility is shared. The provider secures the physical infrastructure, and BeeTcore secures the servers, configuration, and access it controls.

5. Identity and access control

• Administrator, hosting, and code repository accounts use multi-factor authentication.
• Access follows least privilege: each person has only the access their role needs, through their own account, never shared.
• Access is reviewed regularly and removed when an engagement or role ends.
• Team credentials are held in an approved team password manager.
• Team members are trained in safe use of devices, browsers, and email, as set out in the Strategic Information Security Awareness Program.

6. Platform hardening and application control

• Only vetted plugins, packages, and components are installed. Unused ones are removed.
• Administrative file editing and debug output are disabled in production.
• WordPress platforms are protected at the application level by Wordfence and MalCare: firewall, malware scanning, and login protection.
• Custom applications are scanned for code and dependency vulnerabilities before release.

7. Data protection and encryption

• Data in transit is encrypted with TLS on every page and endpoint.
• Backups are stored encrypted. Data at rest is encrypted where the hosting environment supports it or the project agreement requires it.
• Platforms collect only the personal data their purpose needs.
• Data moves between systems only through secure channels, as set out in the Data Transfer Protocols.

8. Data location

Data residency is the country or region where a platform’s data is physically stored. Some organisations must keep their data in a particular place, because of the law, their industry’s regulations, or their own policies. For example, the GDPR restricts moving personal data about people in the EU to other countries without safeguards.

Hosting location is chosen for each project in this order:

• Requirements first: any legal, regulatory, or client-policy rule about where the data must be stored.
• Then performance: as close as practical to the client’s main audience, so the platform loads faster for the people using it.
• Confirmed per project: the chosen location is recorded in the project agreement.

9. Backups and recovery

Backups are held independently of the hosting environment, encrypted, and tested by restoring them, as set out in the Backup and Recovery Standards. Recovery follows the Service Continuity and Disaster Recovery Strategy.

10. Monitoring, incidents, and review

Platforms are monitored continuously, as set out in Security Continuous Monitoring. Incidents follow the Incident Management Response Strategy. This framework is reviewed annually and after any significant incident or change in threats, and findings feed into Continuous Service Improvement.

Frequently asked questions