What the savvy security practitioner needs to know about today’s multi-cloud environment (Guest blog from Check Point)

Author: Stuart Green, Cloud Security Architect, Check Point Evangelist.

The cloud is a rapidly changing domain, with new services, architectures and deployment tools to join everything together. Yet, many of the challenges faced by cloud consumers of all sizes are still the same as they have been for many years.

Businesses of all shapes, sizes and maturity still struggle with some of the most common challenges in security, which are often exacerbated by a drive toward public cloud adoption. The majority of businesses coming from a traditional data center background will have a lot of existing technology and mature strategies to help them in extending their services into public cloud without introducing excessive risk, but not all of these tools were designed with public cloud in mind. Some of them simply are not relevant for use in newer, cloud-native architectures.

Businesses that are deploying brand new services into cloud without the influence of traditional on-premises experiences aren’t immune to these challenges either. A lot of modern applications are built and deployed with speed and functionality in-mind, with very little focus put on security, for fear of slowing things down.

In this article, I will cover some of the most common challenges facing businesses when considering moving to or extending their presence in a public cloud platform, and what you can do to help address them.

Data leaks are as prominent as ever and Microsoft is the latest name in high-volume data loss, with 38TB being offered up to the public through a single leaked secret. No nation-state actors, no zero-day exploits, no social engineering. Just a regular URL saved to a publicly accessible repository which would let anyone with that link access anything contained in the storage account it led to. It is the cloud equivalent of leaving the key in the door to your home.

Misconfiguration is still a huge challenge in public cloud environments. As cloud providers continue to innovate and release new services, cloud consumers tend to live on the bleeding edge and will investigate relevant services very quickly. In stark contrast to the risk-averse approach taken by most businesses operating in a traditional manner with data centre deployments, being an early adopter not only opens you up to potential issues in the service itself, but also in terms of not having much information to lean on from the community with regards to best practice.

Even for well-established services like S3 and Azure Storage accounts — users still favour function and accessibility over security; usually owing to pressure from the business to deliver a project without much regard for delivering anything securely.

Visibility underpins most security strategies, and rightly so. If you have no idea as to what your exposure is across cloud or on-premises workloads, you also have no idea as to what your attack surface looks like.

This is one area however where a number of businesses are seeing success. The native tools for each of the major platforms all offer some tooling to give you an insight into what you have deployed and how it’s being used. The tools are somewhat inconsistent however, and lead to many enterprises extracting the data in a raw format through logs or even scraping the APIs to process themselves in an SIEM type of solution.

This addresses the visibility challenge to a degree, but often causes secondary challenges in terms of what to do with such a large amount of raw, incoherent data. This where the CNAPP comes in. The catchily-named Cloud Native Application Protection Platform (our industry really needs to work harder on creating better acronyms) is defined by Gartner and includes a set of integrated technologies to help offer key strategic features around managing cloud native deployments. The technology aspects are very broad and cover a typical cloud native application from ‘the left’ when the application only exists as code, through to deployment and monitoring when it exists as some type of cloud workload; whether it’s a virtual machine, container or Serverless function.

From technologies such as shift-left tooling to assist with scanning code in a CI/CD pipeline, CSPM to give broad visibility of cloud assets, through to workload protection for your Kubernetes environments — there is a lot of technology here to take advantage of in protecting your cloud applications. But in the definition of CNAPP, one of the most important parts is that these technologies should be integrated.

If you invest in something that only offers a selection of tools, you now have a similar challenge to what you have with the native tools, in that you have to put in the hard work to join the tools together and somehow correlate the data from the different tools.

Our customers have seen great success with our own CNAPP around our Effective Risk Management feature. Behind the scenes, each of the technologies in our CNAPP works independently as a full-fledged product offering great potential for customization; but out of the box they deliver the most important findings from your cloud deployments into our risk analysis engine. This automatically assigns a risk score to each of the parts of your cloud deployment and allows you focus on those that leave you most exposed to abuse and attack. For cloud consumers who are not quite ready to invest in a CNAPP, there are still approaches you can adopt for your cloud security strategies that follow the same principles as CNAPP, but that can be implemented with the native tools and bolstered with your own or open-source code.

Visibility cannot be overstated and should be the first challenge you aim to address by any means possible. Make sure you have a constant, up-to-date inventory of any assets in your cloud estate. This will help immensely when your security strategy matures to implementing controls and restrictions into your cloud accounts, as it will ensure that you have the data required to make informed decisions on what services are really being used by your applications. Visibility extends into usage analysis as well, so make sure you have a picture of not only what you have deployed, but also of how it fits into your architecture and how it is being used. Applications are somewhat organic and change regularly; so too do their requirements and by extension, what privileges they require to do complete their function.

Another foundational element of many security strategies is logging. Knowing who has access to what, but more importantly what they’re doing with that access. A genuine key or identity is only genuine while it belongs to a legitimate owner. If a secret or token is leaked, do you have a way to monitor what activities are being performed by that identity and if they are anomalous?

Identity management. This is one of the more difficult areas of cloud to get right, especially when taking the manual approach. Each of the platforms has their own tooling for managing authorisation and there is little consistency in how they’re applied. One of the examples I often use to demonstrate the complexity of cloud identity management is from the AWS manual. It details a fairly complex process for assessing who has access to what. If you’re taking the manual approach to this, it’s unavoidable that you need to understand this flow for each provider you’re working with. Correct IAM configuration can mean the difference between well-secured storage and something that anyone on the internet can read and write. Most of the platforms offer tooling that can enforce a ceiling or boundary so at the very least you can minimise the effect of wide open, overly permissive roles.

Start as you mean to go on

There are links between each of these challenges and often working toward addressing one of the areas will lead you naturally to the technology involved in the other areas. The key is in doing what you can to make a start. There are many environments, cloud or traditional, where the project gets to a certain size, making it difficult or overwhelming to know where to start in making a positive difference. If you have the option of trying to integrate these practices earlier, do all you can to make sure security gets its fair share of the timeline. If the project or environment is already well established, start by addressing the visibility piece. Once you’ve taken stock of what your assets are, you can use that to create a plan for what really needs your focus.