Tips For Cloud Engineers To Get Rid Of From Silly Cloud Security Errors

By Jyoti Nigania |Email | Apr 24, 2019 | 2175 Views

In a world where data breaches dominate the headlines, I find myself in a lot of conversations on the topic of cloud security. People often assume these hacks are pulled off by brilliant programmers exploiting obscure vulnerabilities. Some CIOs I've worked with as the founder of a cloud and DevOps automation company has even held back on leveraging public cloud services due to these concerns.

The truth is, I've found that cloud security issues are typically less dramatic than most people think. For example, security issues could be related to simple misconfigurations due to human error. The public cloud is secure. Vendors like Microsoft, Amazon, Google, and IBM have many cloud security experts maintaining and supporting their platforms.

I believe leaders need to recognize that cloud security is a shared responsibility between both the provider and the customer. IT teams should take ownership of their role in supporting cloud resources and make sure they're following vendor-recommended security best practices. Here are some of the most common cloud security mistakes I've seen repeated consistently by customers in the real world that should be avoided at all costs and what you can do instead. 

Revealing Secrets:
Developers and operations engineers need to stop storing secrets in application source code and configuration files. Typically, I see this mistake happen out of pure laziness. Applications and automation scripts often need to connect and authenticate to other systems like database servers, storage services or platform APIs. Developers may include those credentials within the source code to connect to external systems because it takes less effort. Source code with embedded secrets can create a liability. According to The Register, one developer learned this lesson the hard way after his access keys were used to rack up $2,375 in charges in his Amazon Web Services account.

Businesses should protect their secrets using a key management service. On the Azure platform, Microsoft offers Key Vault, which can be used to store secrets securely in hardware security modules (HSMs). Amazon Web Services (AWS) also provides a managed service called Secrets Manager that provides a similar capability. Developers can leverage these services to retrieve secrets at application run-time instead of embedding them in application code.

Using Highly Privileged Accounts For Day-to-Day Administration
For optimum security, root accounts with full access to the platform should not be used for general maintenance or ongoing administrative tasks. When someone creates a new account with a provider like Azure or AWS, the first login has full control and unlimited access to every service available inside the account. Sometimes the account creator will continue using that highly privileged login for routine administrative tasks, which opens them up to countless potential security-related incidents.

Imagine if the credentials for the root account are exposed. An attacker could change the password, lock everyone else out, max out the credit card tied to the account, steal sensitive data and destroy resources. Businesses can create specific administrative accounts for staff who support their cloud services. Administrative accounts can then be given limited access through strategies like role-based access control and developing fine-grained security policies. Highly privileged accounts should be limited and monitored for all activity.

Not Using Multifactor Authentication For Administrative Accounts
Creating individual accounts for admins with role-based access is only the first step toward securing a public cloud subscription. I recommend that teams also require multifactor authentication (MFA) for administrative accounts as a best practice. MFA adds a second layer of security to the login process. In addition to a username and password, MFA might require a random code generated by something the admin owns, like a hardware key fob, a USB security key, or a smartphone with virtual MFA device software. Even a text message can be used as a second factor of authentication in most cases.

Every major cloud platform I've used supports MFA. Industry-leading platforms like Azure and AWS along with Google Cloud Platform (GCP) and IBM Cloud provide MFA, along with some advanced controls and features for additional security.

Failing To Implement The Principle Of Least Privilege
Cloud platforms can make it possible to deploy things in minutes that used to take months in traditional data center environments. The side effect is that it's often easier than ever to make a mistake and increase the attack surface of an application.

To implement the principle of least privilege, teams can be explicit about the access they allow to cloud resources. Administrative accounts should only be given the exact security permissions they require. Granular, role-based policies can be used to delegate control. For some organizations, it might make sense to grant users access for specific periods of time only using just-in-time access.
Virtual machines may need to allow inbound access to the HTTPs protocol to serve up a public web application. But that doesn't mean the SSH protocol a method used for remote administration should be unrestricted as well. I believe inbound rules should only allow access to specific sources identified by IT teams.

Conclusion:
Cloud security mistakes can be avoided by adhering to best practices published by each respective vendor. Platform services like the Azure Security Center, AWS Trusted Advisor, GCP's Cloud Security Command Center, and other third-party security tools can be invaluable for monitoring security and compliance and aiding in incident response.

Source: HOB