I had an interesting conversation with a Cloud Architect of a global enterprise who was adamant that data in the public cloud is secured by the cloud provider. He rightly pointed that Amazon, Microsoft, and Google, have security capabilities and practices in place for protecting the availability and integrity of the services they offer.
I asked who is responsible for protecting the confidentiality of data as well as the availability and integrity of applications? Our conversation led to following threats: Data breaches, inadequately secured APIs, insufficient identity, credential, and access management, shared technology vulnerabilities, denial of service (DoS), malicious insiders among others. Integration among different public clouds is difficult.
The ever-expanding corporate attack surface reduces visibility into threats and vulnerabilities for both the IT team and its internal customers. And lack of integration leads to an unnecessarily large number of manual workflows, which presents resource challenges for security teams facing tight budgets and staffing. In addition, sharing of threat intelligence among solutions cannot be automated, so proactive risk management may be nearly impossible.
To overcome these challenges, the security (cloud) architects need a cloud-centric mindset and the help of cloud security technologies that integrate tightly and automate as many processes as possible.
Common problems when security of cloud-based applications is mismanaged include unsecured directories, deployment of insecure non-production applications in the same security environment as a production server, failure to patch known vulnerabilities, and miss-configured firewalls.
End-user credentialing and passwords also continue to cause headaches for security teams. Some employees use the same credentials for an assortment of applications. They may use the same password for critical internal applications, such as finance systems, for the software they access in the public cloud. This security practice means that if the public cloud is breached, the company would be vulnerable to direct attacks of internal systems or indirect attacks using social engineering. A recent study finds that 81% of hacking-related data breaches leveraged passwords that were either weak, stolen, or simply the software’s default.
Unlike providers of public cloud infrastructure, SaaS providers are responsible for securing both the application and infrastructure. Still, content permissions are the responsibility of application users.
But this approach can open up the organization to new vulnerabilities. Line-of-business employees may set overly permissive read privileges and give the wrong people access to sensitive information. Dow Jones, as an example, lost millions of customer records last year due to poor permission management in the public cloud.17 Similarly, business users might fail to properly lock down write privileges, which can open the door to hackers changing corporate files.
Customers who run applications on Infrastructure-as-a-Service (IaaS) platforms are also taking on significant security responsibilities. While IaaS providers are responsible for keeping cloud services running, the customer is fully responsible for security of the operating systems and software running on the platform. This requires attention not only to upfront security settings, but also to ongoing patching and updates.