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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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:
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.
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.
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?
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.
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.
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.
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).
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.
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:
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:
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.
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
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.
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.
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.
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.
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.