Endpoint, Mobile and Cloud Security

Endpoint, mobile and cloud security. Data now lives on laptops, on phones, and in the cloud, and each carries a responsibility that is easy to misplace.

The scene. The company has moved its customer data to a cloud platform and considers security handled, the provider takes care of that. Staff access it from personal phones with no controls, and a storage bucket has been left open to the internet for months. When the exposure is found, the first instinct is to blame the cloud provider. But the provider secured the building and the hardware. The open door was the organisation’s own.

Start with endpoints, laptops, desktops, servers, where users and data meet, and a primary target. Protecting them combines several controls: anti-malware and endpoint detection, timely patching and hardening, disk encryption so a lost device does not leak its data, and a host firewall. Endpoints are not low-risk background devices; they are frequently where an attack begins.

Mobile extends the endpoint problem to hardware the organisation may not own. Bring your own device, B-Y-O-D, is the sharp case: organisational data sitting on an employee’s personal phone, a device the organisation does not fully control. The data can be lost with the device, mixed with personal apps, or exposed if the phone is compromised, often with no way to enforce controls or remove the data.

Mobile device management, M-D-M, and containerisation mitigate this: separating corporate data into a managed container, enforcing encryption and passcodes, and enabling remote wipe of the corporate data if the device is lost. The risk to weigh is always the organisational data on an uncontrolled device.

Now the most tested cloud concept: the shared responsibility model. Responsibility is split. The provider secures the cloud infrastructure, the physical facilities, hardware, and core platform, security of the cloud. The customer is responsible for security in the cloud: their data, its classification, access management, and configuration.

So who secures what. The provider handles the physical facilities, the hardware and core platform. The customer handles their data and its classification, their access management, and their configuration. The exact line shifts with the service model, but the customer’s own data, access and configuration are always the customer’s responsibility.

Which makes the open bucket the customer’s. A publicly exposed storage bucket is a customer configuration failure, squarely in the customer’s half of the model. The provider secured the infrastructure; the organisation misconfigured its own access. When a question asks who is responsible for the customer’s data and access in the cloud, it is the customer.

And underneath the model is a principle straight from Domain two’s third-party lesson: moving to the cloud does not transfer accountability for your data. You can outsource the infrastructure and the running of the platform, but the obligation to classify, protect and correctly configure access to your own data stays with you.

So the provider takes care of security is the wrong answer. It is the same wrong answer as we outsourced it, so the risk is theirs. The provider secures the cloud; you remain accountable for what you put in it and how you configure it.

This is the recurring theme of the whole domain, and the course: the work moves, but the accountability stays. Endpoints, mobile, cloud, in each, responsibility for the data does not move just because the hardware or platform does.

So carry this away. Under shared responsibility the customer owns their data, access and configuration, and a misconfiguration like an open bucket is the customer’s failure. And organisational data on a device the organisation cannot control is the risk, managed by M-D-M, containerisation and remote wipe. In both, the accountability for the data does not move.