Home > Blog > Security Table Stakes: A Blueprint for Securing Your Cloud Environment

Security Table Stakes: A Blueprint for Securing Your Cloud Environment

Security Table Stakes: A Blueprint for Securing Your Cloud Environment

Photo by Chris Liverani on Unsplash

Security teams who are responsible for their organization’s workloads running in the cloud must first understand the layers that make up the components of their cloud stack. While different in structure from on-premises stacks, a cloud environment is still dependent upon each layer performing its key functions. Those layers must also be monitored, analyzed and secured so that the entirety of the activity in the cloud is being protected.

What’s perplexing to many is that the threats faced by organizations are not necessarily always complex. To be sure, there are brilliant hackers coding super complex algorithms aimed at breaking through to secure data repositories. But all that’s really needed is access. Once malicious code, a bot, or any other threat has a channel into infrastructure, the damage can be swift.

It’s important for a security strategy to pay attention to the different pieces of the cloud stack and address their unique security needs with the following approach and actions. Doing so will render your environment far more resistant to threats:

Identity management: Protect and manage users

Impersonating a legitimate user, gaining access through a dead account, or hacking credentials are all different ways of using identity to gain access. Make sure you’ve applied these best practices to ensure a secure environment for your identity layer:

  • Make Multi-factor Authentication (MFA) a requirement: Having a strong password is not enough these days, you need multiple layers of protection. Using a second validation or authentication method provides another layer of protection around your user login.
  • Password policies: CERN says, “Your password should be treated like a toothbrush: you do not share it and you change it regularly!” Combine that with advice from NIST, which suggests that the length of the password is more important than complexity and mix of letters, numbers, and symbols. The NIST guidelines make sense and provide a logical template to use in your own organization.
  • Adopt least privilege policies: Provide users with access to the least amount of accounts and systems that allow them to be productive – no more, no less. This limits the potential damage if an accident is made or a hacker accesses an account.
  • Remove dead accounts: Make it a policy to disable access to all systems and access keys immediately after an employee leaves your organization. Dead accounts are not monitored because of lack of activity.

Systems and data: Secure the compute layer

Getting to the compute layer can spread malware and other threats rapidly. Securing your compute layer means protection of your systems and data, and ensures they are available and impenetrable.

  • Harden the OS: Remove unnecessary programs and applications; they broaden the attack surface and create a much greater potential for risk. Update service packs and patches and make it mandatory for all users to comply with these updates.
  • Enable secure login: First off, issue SSH keys to individuals, which will protect assets and data as they move in and out of unsecured networks and environments.
  • Use Jump Host: The jump host can be used in a different security zone from your cloud environment. It offers the only means of getting to other servers or hosts in your system. The security groups for your other cloud assets should be set up to only allow SSH access from the jump host. It is an extra step that might make keep the hackers out of your system.
  • Only use trusted images: Create images or templates from scratch or get them from very trusted sources like AWS or Microsoft. Don’t use the ones that are available on Stack Overflow or developer message boards or communities.

Protect stored data

All organizations are dependent upon their intellectual property, so you want to be sure to protect your precious resources to ensure your business is viable for years to come. If attackers are able to access your storage layer they have the ability to delete or expose entire buckets of data. 

  • Manage access: Identity and Access Policies (IAM) policies and ACLs help you centralize the management of permissions to your storage. Rigorous bucket policies let you to enable or deny permissions by accounts, users, or based on certain conditions like date, IP address, or whether the request was sent with SSL.
  • ..always: This is not new, but it needs to be reiterated: encrypt your data both in transit and at rest. Pay attention to the fact that metadata is often not encrypted; don’t overlook that and inadvertently store sensitive assets in your cloud storage metadata.
  • Versioning & logging: Versioning allows you to preserve, retrieve and restore data if something goes wrong. With versioning turned on, you can always restore from an older version of the data if a threat or application failure causes loss of data. Maintaining access logs provides an audit trail in case someone or something gets into your system.
  • No delete rights or MFA for delete: You can set up roles in your cloud infrastructure that do not allow the user to delete any data; that right is reserved for authorized administrators. In most cloud storage solutions you can enable a feature that requires that the six-digit code and serial number from your MFA token to delete any version of data stored in your storage layer. This means that attackers won’t be able to delete your data if they get access unless they’ve got your MFA key.

Protect cloud services

After you’ve enforced smart policies, you then need to emphasize security specifically for your services in the cloud.

  • Use good source control management: Use a source control to secure versions, access to builds, and deployment instances. This will reduce the surface area of your code and limit the potential for attacks across your entire network.
  • Don’t allow services to call home to SaaS systems like GitHub: All it takes is for a bad actor to get access to your repo, and they can infect and potentially get access to more of your systems the next time one of your systems calls home. It’s better to store your Git or code repositories securely in your cloud environment.

Your business data is your most valuable currency, and if not protected, it can create a deep, irrevocable level of damage to your operations and brand. With the application of these best practices, along with continuous monitoring and automation, organizations will have deep insight and the ability to rectify issues immediately upon being detected.

 

 

 

 

Share this with your network
FacebookTwitterLinkedInShare