Speakers

---

The Usual Suspects: A Look at Threat Actors Targeting the Cloud and their Battle for Superiority

• Video
• Speaker: James Condon (Lacework, Inc)
  James Condon is Director of Research at Lacework, where he researches various cloud security topics. James is a security veteran with over 10 years of experience in incident response, intelligence analysis, and threat detection. Prior to Lacework, James was Director of Threat Research and Analysis at ProtectWise (acquired by Verizon). Prior to ProtectWise, James was an analyst at Mandiant where he provided network traffic analysis and forensics for several incident response engagements. James got his start in the security industry as a Special Agent in the Air Force Office of Special Investigations.
• Abstract:

  Do you ever wonder who is behind the cryptojacking attacks targeting the cloud? If you examine a compromised server you will notice multiple attackers creating a chaotic mess of cron jobs, services, processes, and network connections. You will see evidence of different entities attempting to grab a foothold on the victim system. This talk takes a look at the actors and their tactics behind this activity.

  Cloud resources make a lucrative target for crypotjacking. To run a successful campaign an attacker must compromise servers and remain persistent long enough to turn a profit. To stay persistent the attacker must evade detection by the owners, typically by installing rootkits, adding multiple forms of persistence, and setting CPU limits to avoid alarms. Once this is complete mission accomplished right? Not quite.

  As it turns out cryptojacking is so popular that many actors are competing for the same resources. This results in attackers booting out anyone else that gets in their way. As seen in malicious scripts and binaries, attackers scramble to keep up with other attacker TTPs all while managing infrastructure in hopes that it doesn’t get blacklisted.

  This talk will discuss one of the first players to the game, the 8220 mining group, and how they target cloud-native technologies along with traditional applications. The very prolific group, Rocke, whose origins begin by forking an 8220 mining group github repo is examined along with their continually evolving tactics.. The talk also looks at Pacha, a group that adopts the tactics of their competitors while simultaneously disrupting their operations. Here you will learn about these groups and what they are likely to target. This talk is geared towards operators and incident responders who need to detect, prevent and remediate these attacks. It's also geared for those who are curious about what is happening behind the scenes and those who enjoy the quirks of attacker behavior.

Automating disk and memory evidence collection in AWS

• Video Slides
• Speakers: Ryan Tick , Vaishnav Murthy (Goldman Sachs)
  Ryan Tick and Vaishnav Murthy are cloud security architects for Goldman Sachs, responsible for automating the detection, analysis, and reporting of security incidents in Goldman's public cloud environment. They work with the firmwide Security Incident Response Team to design and conduct purple team exercises and respond to tier 3 security incidents in the cloud. Prior to working at Goldman, they were digital forensics and incident response (DFIR) consultants that led high profile cybercrime investigations for Fortune 100 clients across the globe. They both hold various AWS and GIAC certifications and are GIAC advisory board members.
• Abstract:

  During an incident, answers are needed quickly. Often this starts with evidence collection and log correlation. While companies generally have runbooks and standard operating procedures, this process tends to be manual, time consuming, and prone to human error. Companies have successfully automated on-prem evidence collection using both open-source and enterprise tools, but few have tackled this task in the cloud.

  At Goldman Sachs, we have automated an event-driven cloud response platform that uses AWS native services to successfully collect disk and memory from potentially compromised EC2 instances. All actions are logged via CloudTrail or custom host-based logs, ensuring that Chain-of-Custody and evidence handling best practices are followed. The disk collection process is leveraged across three AWS organizations and used by over 3000 AWS accounts, while the memory collection process is nearing the final stages of approval to be rolled out firm-wide.

  In this talk, we'll walk through how automated and manual findings from Security Hub are passed as inputs to Step Functions which orchestrate the collection of disk and memory. For disk, we'll deep-dive on how this process: 1) creates encrypted snapshots of impacted EBS volumes in the monitored account; 2) shares those snapshots back with the security account; and 3) spins up EC2 instances from a custom AMI that leverage open-source Linux tools such as dc3dd and incrond to stream dd images of those snapshots to S3. For memory, we'll discuss how this process leverages LiME or winpmem via AWS SSM to stream memory and the custom memory profile directly to S3. At the end of the collection process, Goldman Sachs’ Security Incident Response Team has access to a dd image of each volume attached to the compromised instance, as well as a full memory capture and custom memory profile.

All Your Trust Are Belong to Us

• Video
• Speaker: Kesten Broughton
  Kesten Broughton holds a BSc in math and physics and is currently the Cloud Services Lead at Praetorian. Prior to working as a security engineer, he worked in devops wrangling cloud and container infrastructure.
• Abstract: Cloud providers often talk about the shared responsibility model between provider and customer. But there is another actor in the web of trust, the 3rd party vendor. These include cloud security, logging, and data analytics SaaS offerings. Customers trust those 3rd party providers to access their cloud infrastructure to deliver a service. While conducting research at Praetorian, the author discovered that 39.5% (with a sample of n=90) of AWS service providers which used cross-account role trust had a flaw in the way they provisioned trust into a customer's account. In other words, many companies who's sole purpose is to make your cloud more secure, provided a backdoor to your cloud deployment; many of the vulnerable vendors have over 2k customers and 1B in revenues.

What I Wished Someone Told Me Before Going Multi-Account

• Video

• Speaker: Brandon Sherman (Twilio)
  Brandon has been working with AWS infrastructure for over five years, which is long enough to still have nightmares about EC2 Classic. While awake, he is the manager of Cloud Security at Twilio, where the challenge of real-time cloud communications requires thinking about security in new and exciting ways. While asleep, he is LEGO Batman.

  Brandon's goal is to replace himself with a collection of equally poorly named micro-services and APIs; until Machine Learning has advanced enough to do that, but not so advanced as to become Skynet. While waiting for the future, you can find him teaching anyone who will listen that they can be a "security person" too.

• Abstract:

  There has been a long-standing debate around "multi-account" and if it's something worth pursuing as a strategy, a debate which is finally beginning to coalesce around the answer: "Yes"

  I have some news for you, and it's the first thing I wish I would have known — your organization already has multiple accounts. You just might not know about them.

  There are a variety of reasons this strategy is one to officially support and encourage. In this talk, I will cover each of them. More accounts can make your organization more secure, more resilient, grant better control over data and encryption keys which are subject to multiple and increasing compliance regimes, and more. All of these reasons are good ones from a security practitioners perspective, but none of the previous reasons are necessarily good enough to convince the rest of your organization. I wished someone had told me budgetary controls and growth planning were more convincing, if less exciting, arguments to push for a multi-account strategy.

  I have made a number of mistakes in this journey, some of which I will cover in this talk, including the reasons why you need to adopt a multi-account strategy, how to convince others to join you, the benefits you get from having multiple accounts both security and not, and the technical concerns that will need to be addressed along the way to keep everything functioning. All of these things and more I wished someone had told me before embarking on my current multi-account journey. Now, I'm ready to share my experience with others so you don't have to make the same mistakes.

Limiting Blast Radius by Automating IAM Policies using Policy Sentry

• Video Slides Code

• Speaker: Kinnaird McQuade (Salesforce)
  Kinnaird McQuade specializes in building, breaking, and automating security controls in cloud infrastructure. Kinnaird is the author of two IAM security tools — Cloudsplaining and Policy Sentry — and is passionate about making security easy via automation. He is currently a Lead Cloud Security Engineer at Salesforce.

• Abstract:

  Infrastructure engineers often find themselves in situations where they create over-permissive IAM policies to get their jobs done and because writing least-privilege IAM policies is unnecessarily complex. However, in the case of a breach, it is critical to limit the blast radius of compromised credentials by only giving IAM principals access to what they need.

  Policy Sentry - open-sourced in 2019 by Salesforce - writes least-privilege IAM policies with resource constraints in a matter of seconds, rather than tediously writing insecure IAM policies by hand. These policies are scoped down according to access levels and resource ARNs. In the case of a breach, this helps to limit the blast radius of compromised credentials by only giving IAM principals access to what they need.

  Before this tool, it could take hours to craft an IAM Policy with resource ARN constraints — but now it can take a matter of seconds. This way, developers only have to determine the access levels and resources that they need to access, and Policy Sentry abstracts the complexity of IAM policies away from their development processes.

  In this talk, you’ll learn how to use Policy Sentry. You will leave with practical knowledge about how to uplift and automate IAM security for your entire organization.

Janus: A Multi-Party Authorization Framework for Accessing Critical Cloud Resources

• Video

• Speaker: Abhinav Srivastava (Frame.io)
  Abhinav Srivastava is a VP and the Head of Information Security at Frame.io, where he manages security, infrastructure, and IT departments. Before joining Frame.io, Abhinav spent 6 years in AT&T Shannon Labs as a Principal Researcher working on systems, cloud, IoT, and network security projects. He authored 30+ research papers in peer-reviewed conferences and journals and holds multiple patents. Abhinav earned a Ph.D. degree in Computer Science from Georgia Tech.

• Abstract:

  In the world of DevOps, developers are not only coding business logic but also performing operations on the cloud infrastructure. These operations often require admin privileges during resource provisioning, on-call duties, and troubleshooting scenarios. In a dynamic and fast-paced environment, where access is given readily, one would soon find itself with a list of growing administrators with unfettered access to critical resources containing customer data. In this dynamic environment, it is not sufficient to rely solely on the principle of least privileges for effective control and security. A good security program must provide the right balance between trust and verification. Multi-party authorization (MPA) is one way to achieve this balance. MPA is a process to protect access to sensitive areas of a business by a malicious insider by requiring that at least two authorized users approve an action before it is allowed to take place, making the process highly visible to the business and decreasing the chance of malicious collusion.

  In this talk, I will describe a system called Janus to create custom, versatile workflows to provision a multi-party authorization process in the AWS cloud environment. Janus uses AWS Lambda, Step Functions, DynamoDB, and SNS serverless technologies. With Slack as the primary communication medium, users can initiate, approve, or deny the request to a resource via Janus. Each request has to be approved by at least two authorized approvers. If a request receives 2 approvals from authorized users, a temporary IAM role is created on-the-fly for a limited duration with the appropriate permissions to access the requested resource in the target AWS account. At the end of the duration, the role is automatically deleted from the target account. The attendees will walk away with the learning on how to use serverless technologies to automate an MPA workflow and dynamically provision and de-provision temporary access to critical cloud resources.

Security Onion Approach Towards IAM Roles

• Video

• Speaker: Narayan Gowraj (Lyft)
  

  Narayan Gowraj is a Security Engineer at Lyft where he has been working on multiple application and cloud security projects. Narayan has been actively working on developing hands-on security techniques with product teams to have security baked into their SDLC process.

  Before joining Lyft, Narayan held Security Engineer roles at Adobe and RocketFuel. At RocketFuel, he was the first Security Engineer working with ELT to build a security program and creating the Bug Bounty program to scale appsec within the company. At Adobe, Narayan held a key role in helping secure premium creative cloud apps (like PS, Lightroom, etc), having built a CI/CD system for securing the mobile ecosystem at Adobe using in-house automated tools. Narayan also held a significant role in Adobe's M&A during the acquisitions of Allegorithmic.

• Abstract:

  IAM roles have become the facade for Identity and Access Management for both human and service assumed roles in AWS. On a day-to-day basis, hundreds of our service assume IAM roles to get access to AWS service and resources. On the other hand, humans assume roles to carry out tests, ETL processes and many more critical operations. This talk will explain a multi layered approach towards risk reduction with IAM roles. For efficient risk reduction, we need rich data set and finer details about our IAM roles. For this purpose, we will be leveraging multiple data sources: AWS Access Advisor API, cartography data and pMapper.

  The data fetched will be used for the following purposes: create/enable security alerts for IAM roles, remove unused roles, permission right sizing for IAM roles (least privilege access), and risk scoring to help in prioritization. To calculate risk score, we have used a risk assessment matrix which measures both "Impact" and "Likelihood" into account for determining the risk score. Impact is determined based on the level of access to data stored in the AWS account and likelihood is determined based on the artifacts that can assume this role. For example: Impact goes up if the role can be used to access S3 buckets with PII data, query access to DynamoDB tables etc. Likelihood goes up if the role can be assumed by other IAM principals (user/role/group) in the account. The data used to measure the impact and likelihood are fetched from Cartography and pMapper.

Building Cloud Security Automation at Scale

• Video

• Speaker: Rich Mogull (DisruptOps)
  

  Rich Mogull, Analyst & CEO

  Rich has twenty years experience in information security, physical security, and risk management. These days he specializes in cloud security and DevSecOps, having starting working hands-on in cloud nearly 10 years ago. He is also the principle course designer of the Cloud Security Alliance training class, primary author of the latest version of the CSA Security Guidance, and actively works on developing hands-on cloud security techniques. Prior to founding Securosis, Rich was a Research Vice President at Gartner on the security team. Prior to his seven years at Gartner, Rich worked as an independent consultant, web application developer, software development manager at the University of Colorado, and systems and network administrator.

  Rich is the Security Editor of TidBITS and a frequent contributor to industry publications. He is a frequent industry speaker at events including the RSA Security Conference, Black Hat, and DefCon, and has spoken on every continent except Antarctica (where he's happy to speak for free -- assuming travel is covered).

• Abstract:

  Cloud security starts with architecture and ends with automation, but automating at the scale of hundreds or thousands of accounts/subscriptions/projects is far more difficult than throwing together some Terraform templates and Lambda/FaaS functions. This (digital) whiteboard-driven talk will go deep on different techniques for scaling automation and the challenges and opportunities the present. Some specific topics covered include:

  • Determining the best execution environment based on the automation needs (e.g. instances/containers/functions).
  • Complexities of managing permissions across multiple environments.
  • Navigating organizational and cultural sills with technology design.
  • Managing state and jobs at scale.
  • Proper use of queues, pipelines, and notifications, including lessons learned and how to implement event-driven designs.
  • Gathering data, managing service limits, and collecting events.
  • Integrating both assessment and cloud detection and response.

  Rather than slides the session will use a live whiteboard consisting of pre-determined based images that we will draw on to keep the session more interactive.

  Note: this talk focus on how organizations can build and scale their own automation. Despite working for a vendor I will not be discussing the product. The DevSecOps days Austin presentation is online if you are concerned and want to review another version of the content.

GCP Primitive Roles, An indictment

• Video

• Speaker: Kat Traxler
  Kat Traxler is a Security Professional in the Twin Cities performing penetration testing, security architecture and research in the areas of Web Security, IAM, Payment Technologies and Cloud Native Technologies.

  Kat Traxler is obsessed with the attack surface at the confluence of Identity and Cloud Platform APIs and thinks you should be too.

• Abstract:

  Before Google Cloud released Cloud IAM there was only Primitive Roles. Prior to 2016, the course-grained Roles, Owner, Editor and Viewer were the only mechanisms available to grant access to GCP resources.

  Primitive Roles are the antithesis to least privilege but more specifically, they’re mere existence significantly impacts the security posture of a GCP Project. Four years after the release of Cloud IAM, despite the availability of fine-grained Roles, Primitive Roles are still pervasive in GCP. Is it possible to eradicate Primitive Roles from your GCP Organization and still use the Platform?

Automating Attack Simulation in the Cloud

• Video Slides

• Speaker: Nick Jones (F-Secure)
  Nick Jones is the cloud security lead and a senior security consultant at F-Secure Consulting (formerly MWR InfoSecurity), where he focuses on AWS security in mature, cloud-native organisations and large enterprises. He has a number of years experience delivering offensive security assessments and services to a broad client base. When he's not delivering more offensively-focused work, he's typically found working with clients to help them develop their security operations and attack detection capabilities.

• Abstract:

  Between the MITRE ATT&CK framework and open source platforms such as Atomic Red Team and CALDERA, many security teams monitoring on-premise estates have deploye automated attack simulations to help benchmark their detection capabilities. This approach has allowed many teams to demonstrate capability development over time, justify further investment to management, and ensure that there are no regressions in capability as their detection stack evolves over time.

  There has been comparatively little done in this space for the cloud, however, with even MITRE ATT&CK for cloud being comparatively new and less developed compared to its on premise counterpart. This talk will present Leonidas, a cloud native toolchain that allows security analysts and red teamers to easily define, simulate and detect new attack vectors and techniques in AWS. It will also offer advice and guidance on developing similar capabilities in house, and how best to integrate the results of automated attack simulation into security operations improvement programmes.

It’s Time to Rethink the Shared Security Responsibility Model

• Video Slides

• Speaker: Matthew Fuller
  Matthew Fuller is an accomplished founder and entrepreneur in the cloud security space. He began his career developing, deploying, and supporting cloud-native applications for startups and enterprises, during which he saw the difficulties in developing truly secure workloads in complex cloud environments. This led him to found CloudSploit, an open source and commercial cloud security configuration monitoring service, which was acquired in 2019. Matthew currently crawls the internet awaiting the next S3 bucket breach.

• Abstract:

  For over a decade, the big cloud providers have advocated a “shared responsibility” model for security of and in the cloud. Today, this model is fatally flawed and weakened, having absorbed the blows of nearly non-stop high-profile cloud security breaches. In this talk, we will explore how the balance of security ownership has been tipped too far in the users’ direction and how your organization can fight back.

  This talk will serve as a detailed, fact-supported critique of the shared responsibility model for security in the cloud. While this model made sense in the earlier days of cloud computing, the rapidly-expanding suite of cloud services, along with their infinite combinations of settings, now places an extraordinary burden on security teams.

  I will argue that this burden has shifted the balance of security ownership too far in an unfavorable direction for cloud developers and organizations by analyzing the additional financial costs, human capital, and training required to stay secure in modern cloud environments.

  With this groundwork established, we will then explore ways to fight back, through both technical controls and business decisions. I will include detailed cost tradeoffs when enabling or disabling certain security features, a comparison of features across clouds (including which are included free of charge).

Centralizing Identity across AWS, Azure and GCP

• Video

• Speaker: Paul Schwarzenberger (Celidor)
  

  Cloud security architect, engineer, and DevSecOps specialist, using an agile approach to lead the implementation and migration of critical systems to public cloud. Enterprise experience as security specialist in AWS, Azure and GCP, with certifications across all three platforms.

  Speaker on Cloud Security and DevSecOps at conferences including Security BSides London, DevSecCon, and Enterprise Cloud Computing London

  Trainer on cloud security for A Cloud Guru, the leading on-line cloud training provider.

• Abstract:

  We begin by looking at the approaches to Identity and Organizations adopted by AWS, Azure and GCP. Azure and GCP both use an inherently centralized model for identity:

  • Azure AD tenant and multiple Azure subscriptions (dev, test, prod …)
  • GSuite or Cloud Identity, GCP organization, multiple GCP projects (dev, test, prod …)

  By default, AWS user identities are not centralized across multiple AWS accounts – it’s possible to create separate IAM users in each AWS account. However, this is definitely not recommended from a security perspective as it’s then all too easy for user credentials to remain active after someone has left the organization.

  There are two principal design patterns for centralizing identity across multiple AWS accounts:

  • A landing AWS account, where the user assumes roles into other accounts
  • AWS Single Sign-On (SSO) integrated with AWS Organizations

  Whichever cloud provider is used, it’s important to federate identity back to a single source of truth – commonly on-premise Active Directory for larger enterprises.

  We’ll look at an organization which had IAM users created within several different AWS accounts, and no federation of identity.

  As this organization was an Office 365 customer, Azure AD was already in place as the identity source for Office 365, synchronized with on-premise Active Directory.

  I’ll talk about my experience leading the implementation of AWS Single Sign-On (SSO) across the AWS Organization, synchronized to Azure AD, using on-premise Active Directory identities.

  You’ll see a live demonstration of user synchronization and single sign-on using AWS Organizations, AWS SSO, Azure AD and Active Directory, and hear about some of the practical issues encountered in adoption across multiple AWS accounts within the enterprise.

Kubernetes from an Attacker's Perspective

• Video

• Speaker: Abhisek Datta (Appsecco)
  

  An accomplished security professional with over a decade of experience in information security solution engineering, services, vulnerability research, reverse engineering and security tools development.

  Experienced in security solution development using cloud native and Kubernetes native technologies. Developed and released `KubeSecO`, an open source solution for OSINT and AppSec workflow automation using Docker containers running in a Kubernetes cluster.

  A participant of NULL – India’s largest open security community as a core team member responsible for technology development.

  As a security researcher, he is credited with multiple vulnerability discovery across enterprise products with CVEs to his name such as CVE-2015-0085, CVE-2015-1650, CVE-2015-1682, CVE-2015-2376, CVE-2015-2555, CVE-2014-4117, CVE-2014-6113.

  Open source code: https://github.com/abhisek

• Abstract:

  Kubernetes is everywhere, a container orchestration platform that is actively supported by all major cloud providers and adopted by companies across size and scale. However, the distributed nature of the system at its core has new and interesting security implications that cannot be tested using conventional tools and techniques.

  This talk is aimed for anyone interested in exploring the depths of Kubernetes security from an attacker's perspective including DevSecOps Teams looking to defend against attacker tools and techniques.

  The session will provide a high-level overview of Kubernetes architecture from an attacker's perspective i.e. what can be attacked. Subsequently look at, through demos, modern attacker tools and techniques using various real-world scenarios for attacking applications and components in a Kubernetes cluster.

Winning in the Dark: Defending Serverless Infrastructure

• Video

• Speaker: Eric Johnson (Puma Security)
  

  Eric is co-founder and Principal Security Engineer at Puma Security focusing on cloud security, static code analysis, and DevSecOps automation. His experience includes performing cloud security reviews, infrastructure as code automation, application security automation, web and mobile application penetration testing, secure development lifecycle consulting, and secure code review assessments.

  Eric is also a Senior Instructor with the SANS Institute where he authors information security courses on cloud security, DevSecOps automation, secure coding, and defending mobile apps. He delivers security training for SANS around the world, and presents security research at conferences including SANS, BlackHat, OWASP, BSides, RSA, DevOpsDays, and ISSA.

• Abstract:

  This technical session examines real world scenarios security professionals will encounter defending Cloud workloads running on Serverless Infrastructure. Attendees will see a series of hands-on attack techniques for extracting credentials from serverless functions, and how to leverage those credentials for data exfiltration.

  The session starts with insecure secrets management in Serverless. Live demonstrations will show how a vulnerability in a function can allow attackers to exfiltrate secrets from a configuration file inside the function’s execution environment.

  Attendees will then see how to extract credentials from a function’s execution environment, and use those credentials from a remote machine to gain unauthorized access to data.

  Next, the session explores the ephemeral execution environment that is supposed to live for a few hundred milliseconds and then disappear. In practice, does that hold true?

  Concluding the session, we discuss some defensive techniques for locking down serverless environments, controlling egress traffic, restricting credential access, and querying audit logs.

  Attendees will leave with an understanding of the common attacks and practical security controls for defending their Serverless Infrastructure.

Creating the AWS Account Controller — "Your rules don't apply to me"

• Video Code

• Speaker: Ian Mckay (Kablamo)
  

  Ian breaks basically everything; an AWS Partner Ambassador, Ian thrives on destruction. When he's not busy making helpful (but often awful) open-source tools, he's squatting S3 buckets, popping data lakes, and breaking every rule in the AWS Terms of Service. He also has a day job as the Cloud Lead at Kablamo, a cloud consultancy from Australia.

• Abstract:

  At re:Invent in 2018, AWS teased a solution that was used by the Amazon retail teams for managing the lifecycle of short-lived AWS accounts for development and testing purposes. That solution was never released and the manual process for deleting an AWS account is still a disaster. In this talk I present a solution that combines Amazon Connect, AWS Single Sign-On and some magic with headless browser automation to allow users to self-administer their own sandbox accounts.