AppSec US 2018 (Please, make sure you register to attend)

"When “getting pwned” doesn’t even fully describe what happened"

When building your systems and infrastructure in the cloud, you should always consider the attack vectors you open yourself up to and to continually strive to proactively close them. It’s common knowledge that when bringing up cloud computing resources you should do things like preventing SSH logins as the root user, disable password authentication for all users, as well as do things like limit which IP addresses can talk to the different services on your virtual machines. In more recent years, as our usage of SaaS and IaaS has grown, the importance of securing employee credentials has become even more crucial. So in addition to securing the infrastructure, you require that all employees who need access to the control panel use multi-factor authentication (using TOTP, making sure it’s not SMS-based).

By segmenting access, configuring an intrusion detection system, keeping the systems and packages up to date, and by implementing multiple factors of authentication for your cloud control panel you’re confident in the setup. You’re fairly certain that an alarm would go off if an attacker was able to gain access, and even then their access would be limited to an unprivileged user on only the infrastructure they have access to. But what happens if an employee’s credentials aren’t phished, and instead your infrastructure provider is compromised? Are your systems protected from that vector, and will your heuristics catch it? What can you do to protect yourself from this vector, and can you even reasonably do that?

In this talk, we’ll tell a story from the not too distant past around a successful targeted attack against a company using infrastructure providers as the vector. Details surrounding the methods used by the attacker will be shared, and the explicit steps they took to attempt to cover their tracks. We’ll also look at the other things they did after the attack vector was closed, while attempting to regain access to the systems. Finally, we’ll look at what things you can do to help mitigate the risks you incur if your infrastructure provider is compromised.

The adoption of agile development practices and DevOps has enabled companies to iterate more quickly, allowing them to be more responsive to customer needs and deliver features in a fraction of the time. While this rapid release cycle has a number of benefits for the engineering team, it can tax already time- and person-limited security teams, who are usually outnumbered by engineers 100:1 or more.  To keep up with growing engineering teams and the rapid pace of development, security teams have begun investing heavily in tools, processes, and policies that more efficiently and effectively amplify their efforts.
 Join us for a candid panel discussion of how several companies have worked to scale their AppSec program, including senior security team members from Netflix, Datadog, DocuSign, and Signal Sciences. We’ll discuss a number of relevant topics, including:
* What are some initial, high ROI minimal security engineering efforts that are valuable to pursue first?
* Which security tools, processes, or libraries have been the biggest wins at your company?
* What are three things you’d do in any organization you join?
* What are three spectacular failures you’ve had?
Attendees will leave with specific, practical and actionable lessons they can apply immediately to their organizations. We’ll leave extra time for questions at the end to ensure we answer the audience’s most pressing needs.

An overview of performing enhancing software in League of Legends and what Riot does to combat it.