“Send it to the cloud” has been the increasingly common response over the years for dealing with the issue of how to handle massive amounts of data.On one side, I understand it. Another infrastructure owned by a third party who has teams dedicated to implementing security by design, continuous testing and validation – this all sounds attractive.
However, what many clients don’t realize is that whilst the third party’s infrastructure is secured and regularly tested, your implementation of the environment is not. Take AWS, one of the popular cloud service and infrastructure providers, for example. They work on a Shared Responsibility Model. Their (AWS) backend is secured, but the client is responsible for the configuration of their own environment, services and even encryption setting.
If we look at the 2020 Verizon Data Breach Investigation Report (DBIR), we see that misconfigurations saw a 4.9% increase from the 2019 report. It’s been on the rise since 2017.
If you’re following breach media at all, you have likely come across at least one database with unauthorized access due to no password being required. How could they be so foolish?
It goes back to the Shared ResponsibilityMmodel that essentially all cloud providers have.
Cloud deployments aren’t reducing your responsibilities of data protection. They’re increasing your attack surface and threat landscape of data you’re still responsible for protecting. Whilst it might reduce other costs, it’s important to do a proper risk and cyber security assessment of the solution prior to launching. Otherwise, you may end up spending the ‘cost savings’ in security add-ons or incident response.
Right now, many of us are working within a forced remote environment. For some, this is a positive. There’s even a few saying they have more time! However, for others, this has been a hard transition, especially those supporting the rapid deployment of remote technical support.
