Behind the scene of strengthening & securing the cloud env.

Hello 👋 fellow readers ~

In the previous Cloud Vulnerability Assessment (CVA) article, we shared our spiking experiences on how we can leverage Docker to build an image that can be used to perform CVA on your cloud hosting. As it was an introduction of the technical concept of CVA, many of the “working elements” were missing from it.

The “working elements” refers to the processes, workflows, and the spreading of awareness of the CVA cycle.

We as team Merlin (although we’re considered as magicians) also face challenges conducting the CVA spiking and incorporating it as part of DCube’s security assessment cycle.

Hence in today’s article, we’ll share our challenges, takeaways, and future enhancement(s) of our journey. Our objective is simple — we share our pain points so that you have an idea on what are the possible challenges that you may face when setting a CVA cycle in your own organisation.

Without further-ado, let’s dive right in~

Caveat: We’ll only be using the AWS environment in our discussion.

Challenges faced

Let’s face this fact: every spiking and new implementation comes with its own set of challenges which requires time and additional technical knowledge to resolve. We faced these challenges while spiking and implementing CVA:

P.S. we didn’t lie down and and cry when we faced all these challenges 😜

You may have noticed, the challenges mentioned above are all related to processes. To overcome these challenges, we have come up with the following approaches:

1. Conducting feasibility assessment of the existing market tools
2. Sourcing for external training and learning materials to understand how resources are being provisioned on the cloud environment.
3. Researching on the various security standards and benchmarks used for assessing the cloud environment.
4. Enhancing and integrating this new set of assessment into the existing workflow.
5. Educating the stakeholders on the benefits of conducting Cloud Vulnerability Assessment and how it can help to enhance the cloud security posture.

While conducting the feasibility assessment on the tools, we need to check against these requirements:

1. Is this tool easy to use?
2. Can this tool be set up on docker and cloud environments?
3. Can this tool be integrated with cloud-based CI/CD?
4. Does it have the flexibility to create test cases to cater for additional organisational policies?
5. How active is the tool owner/maintainer?

In total, we took ~2 months to get the right tool running — we spent 1 month spiking a particular tool but realised it doesn’t meet our criteria, thus we had to abandon the ship and proceed to spiking the next tool. Thankfully, the current tool we’re using (also took us ~1 month of spiking) does meet the above criteria. 🎉

Researching and understanding of cloud computing resources, various services, and benchmarks are the toughest challenges. As we’re mostly focusing on the security posture of web applications, we did have a hard time understanding the “technical” terms (eg. serverless, EKS, ECS, SNS, and many more). In some instances, understanding the infrastructure diagram is like appreciating an art piece.

Why an art piece?

It looks simple and straightforward but its underlying structure is powered by many different services and connections amongst one other! This took us months and different tutorial/crash courses from other engineers to build up our knowledge database 😛.

Also, all these challenges aren’t easy to overcome as some require the team members to spend additional time and effort to research and understand the standards and framework used in the chosen tool.

**Head banging moment:**

Cloud Vulnerability Assessment (CVA) is a new concept as compared to Network Vulnerability Assessment (NVA). The stakeholders assumed that the assessment is conducted by running certain tools directly on a list of public-facing IP addresses (which is not true!). It took us quite a far bit of time to explain the differences and ensure that CVA will help to improve the cloud security posture.

Takeaways

After 4 months of banging our heads, we managed to start our first AWS Cloud Vulnerability Assessment engagement! By just running the CVA tools on the cloud hosting environment, we achieved the following:

1. Field-tested the workflows and processes we’ve set up.
2. Executed the assessment on the cloud hosting environment.
3. Analysed the result (and filtering out false-positives).
4. Provided additional recommendations to improve the security posture.
5. Consolidated the findings into a report for ease of reading.
6. Presented the findings to our clients (product teams)

In summary, the CVA managed to identify the weaknesses that are currently found in the AWS environment. Some of the common weaknesses are:

1. Unused security groups.
2. Over Permissive IAM policies.
3. IAM policies created by Organisation Admin which the tenant may be unaware of.
4. Unrestricted NACL.
5. S3 bucket server logging not enabled.

Ultimately, we are pleased to see that CVA has managed to highlight the weaknesses and helps to improve the quality and security posture!

What’s next?

As of now, the CVA is still operating as a need basis. However as the threat landscape for cloud hosting is increasing, we have to find a way to constantly review the configurations on the cloud hosting environment with lesser manual efforts and processes.

GOOD NEWS!!!

We managed to find a way to implement the possibility of executing a more constant and automated review cycle for all configurations within the cloud hosting environment. We will share this approach in the 3rd article of the Cloud Vulnerability Assessment series.

So stay tuned~

🧙🏼‍♀Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.