Hey, everyone. So today, Asaff and I will be presenting on a symbiotic journey of CISO expertise and researcher Insight in cloud native environments.

So as the CSO of a cloud native company, we confronted the unique challenges posed by cloud native security infrastructure and methodologies.

Given our organization's focus on providing security solutions for cloud native environments.

And the expertise of our world class research team in this domain, we recognize the potential synergy, between the CSO team and research team.

So today, we'll give a quick overview on what cloud native technology is and how organizations are rapidly adopting this, what benefits it provides to organizations.

On the other hand, we'll discuss some of the additional attack surfaces and threat landscape that are introduced to organizations as a result of adopting these technologies, Asaf will go on to discuss some of the research that his team does in this domain, and then I'll wrap everything up. Talking about some use cases that us as a security team and myself as a seesaw can adopt based on the fruits of his research.

So in the not so distant past, developers operated within the realm of monolithic architecture where everything from servers to dependencies were centralized.

We managed our own infrastructure, wielded our unique interfaces, How is business logic and data under one roof? However, this approach came with its share of challenges, updates were time consuming, modifications were hassle, and the system was vulnerable. If something went wrong, everything went down. A single production team carried the weight and security fences were concentrated within the organization.

Let's fast forward to today, and the landscape is shifted to microservice architecture.

We've broken down applications into nimble processes or microservices, hosting them on diverse servers.

The payoff here is immense, Our applications are now more flexible, scalable, and resilient with the added benefit of failure isolation.

Yet, This transformation brings its own set of changes.

We now navigate through various distributed servers and environments many, of which extend beyond organizational boundaries.

Production teams have grown larger and more dispersed. This marks a significant paradigm shift. From a security standpoint, this evolution introduces new challenges, safeguarding our organization and workloads, now requires a different approach, one that aligns with the dynamic and distributed nature of our microservices architecture.

So take a look at the slide that we pulled from Open Excel. Wow. What a clutter.

As we delve into the realm of cloud native applications, not just the architecture that undergoes a transformation.

It's a holistic shift in the entire software development life cycle. We're talking about processes, tools, and the very fabric of how we work. In the past, we had a manageable set of tools to juggle and concerns to address.

Now, the landscape is vastly different. We've ushered in a multitude of tools many of which are open source, exposing us to vulnerabilities, and misconfigurations inherited from the broader community outside of organizational boundaries, Yes, we benefit from endless possibilities, continuous integration tools, source code management tools, but it's a double edged sword On one hand, this proliferation of tools accelerates everything, development to cloud speed, heightened automation, and a faster time to market. However, it also brings forth a challenge. Teams within the organization might have their preferences.

Some gravitate towards one tool while others lean towards another tool, you guys know what I'm talking about. It's a mixed bag, and proficiency across the spectrum has become imperative.

And this see if tools, errors, and mistakes become more likely.

The pace at which we operate can introduce security concerns. It's a balancing act. Capitalizing on business benefits while navigating the complexities and potential pitfalls introduced by this diverse toolset. From a security standpoint, it's crucial to consider these dynamics.

So we discussed some of the architectural and process changes involved when adopting cloud native. And as we navigate the expansive landscape of cloud native environments, defining security boundaries becomes pivotal in understanding and mitigating our newly introduced attack surface.

To make this complexity more manageable, we've broken down the cloud native attack surface into six distinct domains. And while we don't have time to discuss all issues, we'll highlight some of them.

So first, our IDs, our integrated development environments. So in the past, protecting IDs were relatively straightforward. They resided on individual computers and were shielded by endpoint solutions.

Today, with services such as Amazon SageMaker and the use of risky plugins for packages, safeguarding this domain has become more intricate.

Yes. While we deploy endpoint detection and response solutions or EDRs, it isn't always sufficient in addressing the evolving challenges.

Regarding SCMs or source code management systems. Consider the scenario of large organizations with many distributed teams each preferring their own SCM solution. Some hosted, some on prem, some might use their own accounts as well instead of authorized organizational accounts. This decentralization often introduces unprotected shadow IT with lax security practices. This can range from weak passwords to the absence of two factor authentication, creating security gaps, Regarding CICD, managing a CICD pipeline brings forth new challenges from securing secrets to preventing unauthorized access The cloud native landscape introduces issues not typically encountered in traditional organizational attack surfaces regarding registries and artifact repositories.

Here, many organizations underestimate the risk. Cloud native registries and artifact repositories are often intentionally exposed to allow external entities to download artifacts and container images.

This openness while facilitating cooperation also poses the risk of accidental exposure of sensitive information.

And regarding run time, this domain presents a myriad of challenges.

Understanding and mitigating the most updated threats, attacks, and root kits becomes imperative in a runtime environment where the landscape is constantly evolving.

Now considering this array of risks that we just discussed, we recognize the need for robust solutions to delve deeper into our approach and the solutions we've developed, I'll now pass the floor to Asaf, a leader in Aquas Security Research team. They'll share his insights into our research methodology, along with illustrative examples of our work in tackling these presenting challenges.

Asaf, Thank you, Moshe. The tech surface is extensive. And at this juncture, we categorize it into knowing and unknown threats. The known ones relate to indication of compromise, IOCs, and IP reputation.

Many companies concentrate their security strategies in this area. And we do the same. However, the more intriguing aspects of our work lie in the realm of unknown cloud threats to address these.

One must pose certain questions and then device matters to answer them. We frequently contemplate whether a threat is genuine is the distinction between traditional cyber attacks and those that occur in the cloud. Who is specifically targeting cloud native environments?

What are their objectives?

How do they accomplish their goals? What tools do they utilize?

To respond these questions, we decipher this enigma. We engage in vulnerability research. In addition, we also make look into misconfiguration threats in the cloud. Lastly, we maintain extensive array of honey pots. These honey pots enable us to observe the attack landscape and understand the behaviors of attackers in the in the wild.

One walk in the area of vulnerability research has included focus on developer's behaviors.

We inquired whether developers download visual studio code, fierce code extensions, and the unanimous response was affirmative when asked about their methods for scanning these extensions the startling response was that seldom any measures were taken. We play for the best one cynically said to us. Consequently, we demonstrated how someone could easily create a malicious Vias code extension that mimics a popular one effectively disguising it and luring developers into executing potentially how for remote code on their endpoints.

We concluded we conducted a similar experiment with Azure DevOps tools as illustrated in the pictures to divide.

You can see that anyone can create a package.

They can give it the same name as a highly popular one. They can replicate the description and metadata making it look like the original one. They can even link it to the original project's git repository.

This situation highlights the risks associated with the shift left approach.

This reveals significant security gaps and underscores the necessity to address them.

We have also conducted research in the area of misconfigurations we found hundreds of organizations exposed and reported them well findings.

Through discussions with these companies, we identified some common deficiencies.

Thus, we are in a position to assert many of these gaps were linked and caused by similar factors such as shadow IT, use of personal accounts, and under estimation of the potential risks present in staging or test environments.

Ultimately, these issues often resulted in the exposure of secrets to sensitive areas in the software development life cycle in the cloud.

For instance, in a recent study, we published two weeks ago, we explained how an engineer inadvertently uploaded a Kubernetes secret to a public repository using his personal account.

The compromised key allowed for both download and upload access to an artifact management system. One that contained over ninety five million artifacts.

This incident could have led to a significant supply chain attack. Our research shine a bright light on these areas of the software development life cycle in the cloud that are more prone to faults which could ultimately lead to catastrophic results.

Utilizing our extensive network of honey pots which span over numerous cloud infrastructure and related applications, we can monitor the behavior of attackers.

In one notable case, our research team was the first to detect head cop, a highly sophisticated detector targeting ready servers.

The threat actor uses the service framework to execute malware as a memory resident, a file's malware.

Relaying only on Redis commands and infrastructure.

This unique method of attack is stealthily affected over twelve hundred victims and managed to evade detection.

Our honeypots allow us to monitor one time. To identify new threats and malicious behavior.

These are just three examples to showcase our research capabilities.

We have a much larger collection of case studies. Nonetheless, it would be far more insightful to inform Moshe about how he and his team is applying or applying our findings to bolster the security posture of our organization.

Thanks, Asaf. That's some amazing stuff. Good work. And as we conclude today's journey, let's focus on some relevant areas that can be derived from our research, insights that resonate with the security challenges and opportunities in our evolving landscape.

Firstly, the shift left paradigm that has become a cornerstone elevating developer engagement and allowing us to remediate risks at the source. It's a powerful concept, but the question arises Do we have the right tools to measure this model accurately?

Are we truly understanding the collaboration in its entirety?

Our research has further illuminated data drawn from real world cases of misconfigurations and attacks that are seen exploited in the wild.

These cases not only identify actual threats and vulnerabilities, but also serve as invaluable lessons, helping us educate our internal teams and stakeholders and refine our policies and work processes.

Then there's devsec ops and evolving profession where roles and responsibilities are still crystallizing.

Our learning curve is steep, fueled by insights from real world cases in the wild. The research team's identification of gaps in other organizations provides us with a unique vantage point. We learn from their experiences, refining our defenses and addressing blind spots and sensors, detections, processes, and focus areas. And finally, in the realm of security operations, while we harness typical external sources, to bolster our detection capabilities, we've definitely recognized a trend. The majority of lists prioritize risks to user computers and emails and focus less on risks to servers.

Our internal honeypots process millions of files, IPs, and URLs daily, enabling us to unveil threats that might not appear on conventional lists, affording us better protection at the perimeter. In essence, Our research not only identifies challenges, but also serves as a compass, guiding us towards solutions.

As we move forward, this collaboration between the CSO Office and our research team remains the driving force and fortifying our organization against the ever evolving landscape of cloud native security?

What about your organizations?

Thank you very much.

It's been a pleasure.