Rich is the CEO of Securosis, a security research and analysis firm, and the CISO of DisruptOps, a cloud security automation platform based on his research. He has over 25 years of security experience and currently specializes in cloud security and DevSecOps, having starting working hands-on in cloud nearly 10 years ago. Prior to founding Securosis and DisruptOps, Rich was a Research Vice President at Gartner on the security team. He has spoken on every continent except Antarctica, where he'll speak for free if travel is covered.
Will Bengtson is the Director of Threat Detection and Response at HashiCorp focused on security engineering, operations, and tooling. Prior to HashiCorp, Bengtson has a background in security and has worked at many large tech companies, such as Netflix, solving security problems at scale. In his spare time, Bengtson enjoys research, bourbon, and traveling.
This demo-filled session will present a new incident response simulation framework for AWS. We start with how to design and roll out a training range across dozens of accounts using combinations of CloudFormation and Python apps, and then walk through building and deploying full attack simulations at scale. The session will also discuss how to adapt these tools to test blue teams in real environments.
Azure allows for privilege escalation via 3rd party service principals, if not carefully monitored. Depending on a user's assigned privileges on Azure Active Directory (AAD), a password or certificate can be assigned to O365 applications, allowing to perform AAD actions as that application, such as *Directory.Read.All* or *Groud.Read.Write.All*. This attack avenue is augmented by the fact that over 200 applications, with varying permissions assigned by default, are onboarded when integrating an O365 E3 or E5 license into a tenant. Microsoft does not view this as a security vulnerability or concern, leaving consumers to configure it in their Azure environment.
In terms of visualizing the attack and pivot opportunities related to service principals within a tenant, we've seen the advantages that attack graphing tools, such as Azure StormSpotter and BloodHound 4.0, bring security professionals. While StormSpotter or Azure Powershell could be used to extract information and identify service principals with permissive access, both methods may result in human mistakes when manually trying to interpret these interconnected relationships with a 3rd party service principal.
Our talk, therefore, will cover using new cypher queries we have built to be integrated with Azure StormSpotter. These queries can be used to graphically display 3rd party service principals integrated with Azure and their dependent relationships, as well as any other useful reporting information. These queries can be used in insolation or as building blocks to map more complex relationships. With this information, security professionals will be able to identify possible attacks avenues and also empower defenders to prioritize line of defense strategies. Where possible, we have implemented also a few exploitation-attempting scripts, that would report back on the effectiveness.
Charlie Cetin: Charlie Cetin is a Security Engineer at Yelp Inc. working in the Identity and Access Management team as tech lead. He received a Ph.D. in Computer Science from the University of South Florida focusing on access control and cryptographic protocols. His interests include access control, cryptographic protocol design and verification, and long-term security best practice solutions. He enjoys road trips, cooking, and swimming in his free time.
Quentin Long: Quentin Long is an infrastructure security engineer who's been helping secure Yelp since 2014. He's focused at various times on building our Yelp's logging and alerting pipeline, tooling for AWS credential and IAM management, and overhauling their data security policies at practices. He's previously presented at Blackhat Arsenal and various meetups about Elastalert, an open source alerting tool for Elasticsearch. Most recently, he's been involved in implementing new authorization layers for Linux and for Kubernetes access at Yelp.
Daniel Popescu: Daniel Popescu is the Group Tech Lead for the Security Organization at Yelp. Their focus is to define the security strategy for the company, and ensure that Yelp engineering is aware of security risks, leveraging security best practices, and making sure we’re all working to solve the right problems. They are extremely passionate about all facets of security, having attended security conferences for the past 17 years. Previously they worked at Microsoft on non-security products. Professionally, their interests include scrutinizing IAM policies and managing dozens of AWS accounts, automating manual tasks, building scalable distributed systems, and breaking things. In their spare time they enjoy yoga and flow arts.
Yelp recently migrated their container orchestration system from Mesos to Kubernetes. However, existing Kubernetes authorization mechanisms were insufficient to implement least-privilege access control rules. Yelp needed to authorize its users to hundreds of services owned by hundreds of different teams. By leveraging the Open Policy Agent (OPA), Yelp has implemented an authorization system that allows us to define fine-grained authorization rules. These can rely on service ownerships, resources’ or actions’ sensitivity levels.
This talk will cover Yelp’s journey to a fine-grained Kubernetes authorization using OPA and Active Directory. We’ll discuss the technical details of our design and implementation, and we will demonstrate how we integrated OPA with Kubernetes and Active Directory. The authorization policies and data structures we present are generic, and they provide the flexibility to express least-privilege access control semantics for thousands of engineers and hundreds of use cases. Our policy design is flexible enough to define authorization rules based on arbitrary metadata beyond what RBAC supports (i.e., any arbitrary resource metadata such as labels). Our policy design learnings will hopefully inspire the community to implement something similar in their organizations with minimal additional design overhead.
Finally, introducing authorization to a widely used system without affecting its users can be extremely difficult. Our migration strategy allowed us to achieve our goal of replacing the plane’s wings in flight with zero downtime and zero outages. We believe the community will appreciate our detailed strategy and the learned lessons.
Cloud providers, like AWS and GCP, make it easy for developers to quickly spin up infrastructure for their applications, which coincidentally makes it easy to misconfigure. Historically at Square, we’ve built our detections and guardrails for the cloud provider native APIs themselves. This was a great first step to provide us assurances that the underlying infrastructure is secure, but not without introducing some inherent friction for developers dealing with security issues days, weeks, or even months after the infra was created.
In this talk, I outline how we’ve worked to reduce this friction by introducing automated security scans into our standardized Terraform workflow to detect and prevent insecure changes before any infrastructure is actually spun up. Developers at Square now have real-time access to the proposed infrastructure changes they want to make, the security impact of these very changes, and instant remediation info for these findings. I’ll give an overview of our rollout strategy, approaches to enforcement, and other lessons learned along the way.
Joe Crawford is a Senior Manager in the Cybersecurity practice of Ernst & Young LLP. He is a holder of a master’s degree in Computer Science from North Dakota State University – Minot, and a bachelor’s degree in Computer Science from Northern Arizona University. Joe has an extensive cloud security engineering background, as well as several years of executive management in secure cloud adoption for highly regulated enterprises, as well as contributions to top cybersecurity companies. Joe has multiple certifications from AWS, and Google Cloud.
Alex Shulman-Peleg: As an industry leader in Cloud Security Alex enables organizations across industries to securely adopt Cloud through security automation and simplification. Previously, Alex was the Director of Cloud Security at Citibank, where she established and led Citi’s migration to secure Cloud and Containers. Prior to Citi, Alex developed secure Clouds and cloud security products at IBM Research, leading security innovation in multi-year EU Cloud consortium projects. She holds a Ph.D., M.Sc. and B.Sc. degrees in Computer Science with multiple awards, patents and over 30 publications with thousands of scientific citations.
Cloud and containers are the antithesis of traditional centralized management of assets and their state. This disrupts multiple organizational processes and deepens the disconnect between audit and engineering that are not speaking the same language.
In this talk we will give examples of new audit and cyber management processes that are driven by the Cloud philosophy. Such examples include deploying policy as code and replacing painful patching with frequent redeployment. We will present the impact of these changes to audit and risks management practices, describing examples of successful automation and simplification of these processes.
Specifically, we are driving the industry towards automated and more comprehensive implementation of the controls throughout all phases. Introducing three main changes: (1) Metrics for the control automation and coverage for the preventative, detective and responsive functionalities; (2) Zero-trust requirements covering all of the controls and reducing the blast radius and the residual risk in case of cyber incidents; (3) metrics across all phases of the controls – preventative, detective and responsive.
We believe that driving for zero trust across all domains and components throughout the entire lifecycle is essential to ensure the security of today’s Cloud architectures.
Do you know exactly what each user can do in your Google Cloud Platform (GCP) environment? Do you know if you have users who can assume other identities to escalate their privileges? Do you know the effective permissions the users would have if they assume other identities?
In this talk, we'll discuss the complexity of this problem with some examples, and demonstrate how a misconfigured member can escalate privileges via direct service account impersonation or by launching resources. This threat has existed for years in public cloud providers. While GCP and their recommended open-source tools address some IAM misconfiguration use cases, they do not provide full visibility into the potential for privilege escalation or lateral movement.
Finally, we’ll cover our open source tool, which provides a way to monitor the potential for privilege escalation in your environment. Once we obtain all the relevant information via API calls, it maps out the permissions granted to members, the structure of the GCP environment, and the service accounts. We'll show some results from running the tool, which was previously used to discover 'shadow admins' in production environments. We believe every enterprise should be aware of and monitoring this risk in their public cloud environments.
Steve has experienced a wide breadth of technologies throughout his career in the aero, telecoms and automotive industry improving quality, safety, velocity and efficiency.
Currently, he is a Developer Advocate with Bridgecrew (by Palo Alto) specialising in Cloud and Infrastructure Security Automation. Prior to this he was a Solution Architect for StackRox and Aqua Security specialising in container and kubernetes security and spent time with Synopsys establishing DevSecOps best practices for enterprise CI/CD pipelines.
He also plays Ultimate Frisbee.
Tracing misconfigurations and drift in runtime cloud deployments back to the owner and original commit of the associated IaC resource has been without a practical solution.
While major cloud providers have offered best practices for resource tagging they have left the problem of maximising those proposed benefits to us.
A new open source project from Bridgecrew called Yor solves this problem. It is a GitOps focused tag and trace solution which automates the tedium of manual resource tagging with consistent and strategic IaC resource tags. This automation strategy allows SREs and security teams to instantly trace misconfigured or insecure runtime cloud resources directly to a git commit and resource, radically reducing the escalating mean time to remediate and Jira ticket vortex that often results.
Yor tags can also be combined to enrich the already 500+ built it rules with open source IaC scanner Checkov, bringing new possibilities for context aware security policies to prevent misconfigured and insecure resource definitions prior to deployment.
This talk will combined the open source solutions Yor (IaC Tag and Trace) and Checkov (IaC Policy and Scanning) to show how to improve your security and crush your MTTR.
Today there continues to be an exponential growth in the use of Open Container Initiative (OCI) container images running in Kubernetes clusters in both on-prem and public clouds. As such verifying the trustworthiness of any 3rd party images used in these clusters is imperative. Many of these images form the foundation upon which application images are layered; they could be an OS base image or a middleware base image (e.g. a base OS image with Java layered on top, ready for application usage). Specifically we need to be confident that the images have not been tampered with and are fit for purpose.
In this talk I intend to describe how you can minimize the risk of consuming 3rd party images by using Open Source tools such as Openscap and Goss to validate the contents of images, and podman to provide a secure build environment. I will then describe how these components can be incorporated into a fully automated pipeline to deliver secure images ready for consumption.
Gaurav Kumar is a well-known cloud security expert and was the founder of cloud security company RedLock which was acquired by Palo Alto Networks. Today, RedLock is known as Prisma Cloud which is one of the most popular CSPM solutions. He led cutting-edge cloud security research activities at RedLock and published various research reports demonstrating novel attack techniques. Currently, he is CEO and founder of Dassana, an open-source cloud security company, and is on a mission to contextualize cloud security alerts.
One of the most frustrating aspects of responding to cloud security alerts is the time wasted collecting the relevant context. Consider an alert notifying that a storage bucket has been found publicly accessible. Should you drop everything and tend to it? The answer is always - “it depends”. And it always depends on the context. What if the bucket has an associated website with it with the word “static” or “marketing”? Suddenly, what felt like a critical alert is almost not an alert anymore.
Such contextualization or alert decoration becomes even more critical at scale. Unfortunately, there are no standardized solutions, and building and supporting internal tools becomes a headache and leads to tribal knowledge.
Dassana fixes that. Dassana is an open-source, serverless solution available in AWS Serverless Repo which normalizes, contextualizes, and prioritizes alerts using declarative workflows written in simple YAML files. The contextualization is done using Dassana Actions which are lightweight, language-agnostic, open-source serverless functions. Additionally, the alerts are normalized which means that you can simply swap out alert generating vendors and solve vendor stickiness problems.
In this talk, you will get a live demo of the tool and learn about opportunities to contribute to the world’s worst tool designed to contextualize alerts.
Chester is a Senior Cyber Security Engineer on the Threat Detection & Response team at Northwestern Mutual (NM). He works on the Response function of the team but spends part of his time building Cloud Detections and maturing the Cloud IR practice at NM among other things. He holds multiple GIAC/security certifications and most recently the AWS Certified Security Specialty. Chester is a huge sports fan and even coaches High School basketball which is his first love.
Repeatedly investigating AWS Guard Duty findings only to find out it was normal activity can be a key contributor to alert fatigue…at least it was for me. Researching methods to tune AWS GD offer very little insight into anything other than tune IPs and roles wholesale but may still leave you in a similar situation which can be truly frustrating.
Instead of ignoring the problem, I want to show you how you can operationalize AWS Guard Duty using a Risk Based approach to alert, a.k.a. RBA within your SIEM (Splunk in my case). In this presentation, I will take you through some of the struggles I had in this journey, pre-work needed for this approach, breakdown the logic including SPL (query) snippets so you will know how to go about significantly reducing the noise in your AWS Guard Duty environment.
Eliav Levy is a lead security researcher at Hunters, where he has been researching different attack surfaces - and mainly AWS. Prior to working at Hunters, he was in the Israeli Military Intelligence unit 8200 for five years.
Any organization with cloud resources must develop investigation capabilities for cloud-related security incidents. When investigating security incidents and threat hunting signals in the AWS control plane, questions like “what happened in this AWS session?” and “what exactly did the user do?” are critical for determining whether the suspected activity is benign, or if it seems malicious and requires deeper investigation.
Understanding which services the actor used in the session, which resources he interacted with and what he did with those resources can give crucial context for the analyst or forensic investigator. However, it turns out these questions are much harder to answer than one would think.
The author will offer an investigation methodology for control plane security incidents and demonstrate it on a GuardDuty alert, while diving deep into technical aspects of CloudTrail logging related to user sessions, identity-pivoting actions, web console activity and event-specific actions. During the demonstration, it will be shown how these technical details can be used to answer the questions mentioned above, and enable and speed up investigations.
The presentation will be accompanied by two findings by the author, discovered while conducting research at Hunters, which emphasize the complexity of CloudTrail logs on one hand, and show how intimate knowledge of the logs helps investigating and threat hunting in AWS on the other hand: a new defense evasion technique, and a previously undocumented behavior of AWS API keys being recycled between different identities.
The AWS Service Authorization Reference (or SAR) is supposed to be the main source of truth for IAM policy authoring, but what happens when even the cloud provider gets it wrong?
In this session I'll talk about problems within the SAR, my journey mapping every API method to its IAM equivalent (all 10,000+ of them), using that mapping in open source tools, and how you can contribute to help others in the future.
This talk is ideal for anyone who is enthusiastic about identity and access management, those who write or consume cloud security tooling, or even those that simply strive for least privilege in their environment.
Azure Administrators and security teams can use Azure Policies - similar to AWS Service Control Policies (SCPs) - to enforce hundreds of organizational standards and enforce security policies at scale, such as preventing unencrypted resources or over-permissive security group rules. However, deciding which of the 400+ built-in policies you want to enforce, and which stages you want to roll them out in can be a bit intimidating at the start.
I developed an open-source tool called Cloud Guardrails that helps maximize security coverage and eases the rollout process. Using Cloud Guardrails, you can cherry-pick and bulk-select the security policies that you want according to specific criteria in a YAML file, such as targets (subscriptions or management groups), enforcement levels (enforced or audit-only), or whether the policy requires the use of parameters. It generates Terraform that will allow you to deploy guardrails within minutes.
In this talk, we’ll cover how Azure Policies work and how Cloud Guardrails operationalizes the rollout. We’ll also cover deployment architecture, exceptions management, and other success strategies. Attendees will leave with an understanding of how to enforce hundreds of low-friction security guardrails within minutes without deep expertise.
Hari works as a Software Engineer in the Cloud Foundations team at Square and is based out of Los Angeles. He works on providing tooling, infrastructure, and libraries for Square engineering teams to power and manage their workflows in AWS (mostly) and GCP. https://developer.squareup.com/blog/adopting-aws-vpc-endpoints-at-square/ is an example of one of his past projects there. Prior to Square, he worked as a Software Engineer across the stack in different companies including like Twitter and Amazon (Twitch).
At Square, applications are spread across cloud providers and our datacenter. Apps talk to each other over an Envoy-based service mesh, and to AWS APIs using IAM credentials. In this world, developers had to choose one or other - the flexibility of building on top of cloud-native services like S3 and Lambda, or the convenience of interoperability with the rest of our service mesh.
In this talk, we’ll cover how we brought the two worlds together. Using Envoy’s built-in SigV4 signing library, we made it possible for apps to expose their AWS resources to remote callers over the service mesh securely. Developers can now deploy services that are just a collection of files on S3, or a group of Lambda functions. Callers of these services need no knowledge of IAM, or even be aware of the fact that they’re actually talking to a service in the cloud at all.
Jared is a Cloud Architect that specializes in enterprise cloud architecture and security; he is passionate about helping large organizations with architecting, building, securing and operationalizing cloud environments. In his spare time he blogs about security, cloud and devops.
In this talk, I will share several key lessons that I have learnt over the past 6 years as I have helped many organizations on their AWS cloud journey from the perspective of an enterprise defender. This will primarily focus on our initial experience and design thinking while building out security controls and sharing the wins and fails that we had along the way. During this talk I will briefly share our we approached various security threats, the controls we put in place and how this has evolved over time.
In the first part of the talk, I will talk about how we approached the initial building blocks for a cloud environment including network connectivity, network security, account management, account guardrails, IAM strategy, governance, and the regulatory challenges that we encountered. From a network perspective, this will include how we started with a transit VPC using CSRs and transitioning to a transit gateway spanning over 100 accounts. From an account perspective, this will include our initial approach to account separation, account automation, the challenges we had and how the landing zone and control tower have changed things. From an IAM perspective, this will include our IAM strategy and how we moved from a predict and control model to a decentralized trust model with compliance.
In the second part of this talk, I will share lessons that we learnt while building capabilities to enable application teams to run in the environment including encryption with KMS and CloudHSMs, creating AMIs through a pipeline, billing, shared services, DNS and active directory. This will include the operationalization challenges of onboarding teams, how we adopted infrastructure as code and how we used scaled learning to distribute common patterns and architectures to the application teams.
Lastly, I will share some of the frustrations with the AWS platform, what we are working on now and some things that we are excited about.
David is a cloud security architect at the prisma cloud speedboat at Palo Alto Networks. Before that, he was an independent consultant helping companies secure their Azure environments through private expert level trainings and assessments. He holds 13 professional certifications across Azure and AWS platforms, including the Azure Security Engineer, Azure DevOps and AWS Security Specialist certifications. He has also authored two cloud computing courses for the popular cybersecurity training platform - Cybrary.
David has over a decade of experience in Cybersecurity (consultancy, design, implementation) and over 6 years of experience as a trainer. He has worked with organizations of different sizes from startups to major enterprises to government organizations.
David has developed multiple vulnerable by design automation templates that can be used to practice cloud penetration testing techniques. He regularly speaks on cloud security at major industry events like Microsoft Future Decoded and the European Information Security Summit.
David is married to a lovely girl who makes the best banana cake in the world. They love travelling the world together and intend to do missions in Asia very soon!
As a Practice Director at NetSPI, Karl leads the Cloud Penetration Testing service line and oversees NetSPI’s Portland, OR office. Karl holds a BS in Computer Science from the University of Minnesota and has over a decade of consulting experience in the computer security industry. Karl spends most of his research time focusing on Azure security and contributing to the NetSPI blog. As part of this research, Karl created the MicroBurst toolkit (https://github.com/Netspi/Microburst) to house many of the PowerShell tools that he uses for testing Azure. Over the last year, Karl has co-authored the book “Penetration Testing Azure for Ethical Hackers” with David Okeyode. Over the years, Karl has held the Security+, CISSP, and GXPN certifications.
The Azure cloud platform is constantly evolving. Security researchers and attackers discover new methods to exploit services and workloads on a frequent basis. Combine this pace of change with the scale of the platform (currently supporting over 180 services) and you can see why securing Azure is a struggle for many organizations.
The first part of this session will focus on real-world attack tactics and techniques used to exploit Azure environments. We will cover how to exploit anonymous and authenticated access in Azure and demonstrate a sample discovery and exploit using MicroBurst – a pen test toolkit written by Karl Fosaeen. We will also share some practical techniques (controls, configurations, and best practices) that you can follow to limit the likelihood of a breach and to reduce the impact in the event of one.
In the second part of the talk, we will focus on the password extraction functionality included in MicroBurst. We will review many of the places that passwords can hide in Azure, and the ways to manually extract them. For convenience, we will also show how the Get-AzPasswords function can be used to automate the extraction of credentials from an Azure tenant.
VPC Service Controls is a tool available in Google Cloud to defend against data exfiltration. This is a very powerful and unique layer to add to your defense in depth arsenal. Nothing like this exists on AWS or Azure, but no one really understands how it works. I am here to change that.
Cloud katana is a cloud-native serverless application built on the top of Azure Functions that allows the orchestration and execution of attack simulations in the cloud and hybrid environments with the main goal to expedite research and assess security controls. Simulation steps are represented as blocks of code called functions and invoked via HTTP requests through a cloud-native serverless web API. The project is also designed to handle state and ensure reliability across numerous attack simulations by using an extension of Azure functions named durable functions. This feature allows the orchestration and execution of scenarios where actions could depend on the state and output of other simulation steps. In addition, Cloud Katana uses the Microsoft Identity Platform (also known as Azure Active Directory or Azure AD) as its identity provider to authenticate clients and restrict access to the application. Furthermore, when executing simulations in Azure, the tool uses a user-assigned managed identity, with the right permissions, to access other Azure AD-protected resources. In order to create interactive and repetitive templates to share the process with other security researchers, the project also uses the power of Jupyter Notebooks. Finally, we are experimenting with Azure App Service Hybrid Connections to run simulations against resources on-premises.
Debugging why an action received AccessDenied is a complex problem in AWS. When a principal tries to do something IAM does not allow, often all that is provided in the API response, CLI response and CloudTrail is an "Access Denied" message devoid of any context. The policy causing the issue could be an identity policy, a resource policy, a permission boundary, a session policy, tagging policies or an SCP and the reason for failure within that policy isn't always easy to find either: Is the problem in a missing resource for the permission? A missing dependent permission? One of the conditions? Perhaps a tag policy?
This not only causes confusion and frustration, but often leads to provisioning excessive permissions or forgoing necessary security controls just to end up with something that works. Not only are we left with over privileged policies, but ones that people are afraid to touch lest they break something.
The question of what is causing an "Access Denied" response can be a difficult one to answer manually as well as a tricky problem to automate. The language of Access Denied messages varies between services and between permissions, the request parameters logged in case of failure vary between requests, and relevant policies which could cause the denial of access are scattered in different places in the AWS environment and require different API calls to obtain. To find the policy causing denial, one must examine every single potentially relevant policy.
Access Undenied - open-sourced by Ermetic - uses information in the AccessDenied CloudTrail event – the text of the error message, the resources in the request, the request parameters – to gather all the policies which could be relevant to the permission, feed them into an assessment engine (like SimulateCustomPolicy) and output recommendations for rectifying the issue in a way that maintains least-privilege.
PodSecurityPolicy is a built-in admission controller that controls security-sensitive aspects of Pod's specification. PSP started the deprecation process in Kubernetes 1.21, while a new replacement proposal(3-tier policies) is progressing, we can use the opportunity to rethink and evaluate different implementation options that can achieve a more secure state.
The first change would be to evaluate the usage of "validation" webhook vs. "mutating" webhook. We'll look into the benefits and drawbacks of each of them and see how a hybrid model benefit from both worlds. Next, we'll look into the policy options comparing new declarative policy options available through open source tool like OPA/Gatekeeper and Kyverno policy engines. We'll compare and show example of these policies implementations which provides a more comprehensive capabilities sets (and libraries of predefined rules).
An additional change is the creation and modification of security policies using GitOps, how to create/update policies in a secure manner during services deployments.
You locked down your AWS account's IAM Policies, but are you certain there aren't any unexpected side effects? Are there any passable/assumable roles that could be abused to access those credentials you stashed in Secrets Manager? Principal Mapper (PMapper) is a tool for in-depth evaluation of AWS IAM Authorization Risks. This talk covers how to extend it to automate finding risks (continuous monitoring) and test for resource isolation.
Dre Mahaarachchi: A fresh grad from UC Berkeley, Dre recently joined Bright Machines as a software engineer on the platform service team. During the first two quarters in his new role he went from learning about access control to being a capable and empowered owner of its backend functionality. During the same timeframe, he was enticed to learn more about security. Though Dre is still very happily part of his original team he now also enjoys supporting Bright Machines product security efforts.
Jacques Thomas: Jacques has always been interested in distributed systems, security, and hardware tinkering. After 4.5 years doing the first two in the Snapchat security team, he now enjoys doing all three at Bright Machines, where he is a founding member of the Product Security team. Previously, he spent time at AWS after attending grad school at Purdue where he studied distributed systems and security.
In about 2 quarters, and with less than 2 full time engineers, we have built an authentication and authorization infrastructure, as well as a perimeter gateway, that we believe will not only support us for this cloud project, but will also be a solid foundation for future cloud projects. The beauty of it? We own almost none of it besides the business-specific configuration. That is we’ve used envoy proxy to normalize traffic and reduce the attack surface at the cloud edge: past that perimeter, only authenticated traffic is allowed. Yet, authentication is revalidated on each microservice, using envoy again, borrowing from the zero trust practice to always verify as well as provide defense in depth. The most business-specific part of the infrastructure is the granular access controls for our microservices. Yet, we’ve managed to boil it down to little more than a decision look up table vended as a sidecar. Everything can be extended and improved, but the system is built, functional, deployed, and easy to reason on. That’s key for our current stage of exponential growth as a company. A recently discovered bonus feature: we’re able to “upgrade” the header support of websockets at the edge, and rely on the standard “Authorization” header within our perimeter.
Saurabh Wadhwa is a Senior Solutions Engineer at Uptycs having more than 9 years of experience in the security industry. He has a passion for architecting security solutions. In his spare time, he likes to be outdoors playing cricket and also spend time with his family
The security community has embraced osquery as a way to gather and normalize telemetry from endpoints. Now, new extensions can bring that SQL-driven approach to cloud infrastructure and container environments.
This presentation will provide an introduction to the open-source osquery project and introduce cloudquery and kubequery, two new extensions to the osquery project that enable security, IT, and DevOps teams to easily ask questions of their cloud infrastructure, and their workload running within, to ultimately strengthen their cloud security posture. This session will also provide examples of detections and investigative workflows that join together telemetry from cloud-based hosts, container environments, and cloud infrastructure.
In this session, attendees will learn:
• The basics of osquery, cloudquery, and kubequery—powerful open-source tools that normalize security telemetry from the enterprise attack surface
• How these tools can help implement standards such as the CIS Benchmarks for AWS, Azure, and GCP
• Examples of how teams can use these tools to identify risk and detect threats in and across cloud and container environments
Riyaz is the Co-Founder/Chief Hacker/CTO at Kloudle Inc, a Cloud Native Security Monitoring SaaS company. At Kloudle, his offensive security skills are used to identify and mimic attackers attempting to break-in to various cloud configurations to enhance Kloudle's monitoring capabilities.
He is also an active security evangelist and researcher with over a decade of experience in the cyber security industry. His curiosity has led him to work in various aspects of Cloud Security, Kubernetes and Container Security, Web Application and Mobile Security, Network and System Penetration Testing, Wireless Network Security Assessment, Dynamic Malware Analysis, Threat Modelling, Windows Forensics, Security Code Review, Vulnerability Research, Exploit Development and Reverse Engineering.
He loves speaking at various conferences and community meetups and has been a speaker/trainer at numerous conferences including BlackHat, DefCon, OWASP AppSec and nullcon. He is also one of the chapter leaders of OWASP Bangalore and in the past has led community efforts at null (India's largest open security community) as well. When he is not writing/breaking code, you can find him dabbling in photography, stargazing, playing football, reading or fishing.
A lot of guidance is available on the Internet in decreasing order of availability/popularity for attacking AWS, Azure and GCP. Given the abysmal amount of content there is about attacking IBM Cloud services and offensive research that is available, I set about exploring the different services purely from an attacker mindset and creating a talk out of this.
This talk is about my foray into setting up different things within IBM Cloud, making sense of the confusing documentation and glossary and creating an attacker's guide for pentesting IBM Cloud as a result of the research.
In this talk we will examine at a bare minimum the following:
- Using OSINT to discover IBM Cloud resources exposed on the Internet
- Mis-configurations with Access (IAM) that allow privilege escalation
- Tokens, keys and SSO - what on the ibmcloud cli is useful
- A quick and dirty analysis of the IBM Cloud shell and a thing about kata containers
- A funny thing about ICMP through security groups
- Virtual Server for Classic and the `root` password obscurity
- A reverse shell within Functions / Serverless compute
- Cloud Object Storage and tooling to discover in the wild
The contents of this talk and any tools that have been / are created as part of research will be released as a Github repo on the day of the talk.
Garrett Wong is a Strategic Cloud Engineer with Google, specializing in Application Development, Infrastructure and Security. Garrett has worked with Google Cloud over the past three years, working with customers to enable secure migration to the cloud as well as partnering to transform legacy operations towards a devops focused mindset leveraging infrastructure as code best practices.
Wilson Liu is a Strategic Cloud Engineer with Google, focused on Infrastructure and Security. Wilson has worked at Google in various technical roles from systems administration to assisting large enterprises deploying Cloud Identity, Workspace, and Google Cloud.
Do you have the controls in place to withstand a security breach? How about the controls to detect a pattern of suspicious activity? We will demonstrate how compromised credentials on Google Cloud can be used to accomplish specific adversarial techniques from the MITRE ATT&CK® framework. The ATT&CK techniques will be showcased in GCP, how to mitigate with native controls, and how to investigate and respond to the breach