DevSecCon London 2018 Presentation

Here are slides for my presentation at DevSecCon London, “Building Effective DevSecOps
Teams Through Role-Playing Games.” It uses the aspect of social interaction in role-playing games as a model for working with DevOps teams to build secure apps and making sure the app’s threat models include social dimensions.DevSecCon2018

Automation is critical to building, testing, and scaling modern apps. Security benefits from being able to abstract cloud environments and infrastructure into APIs that we can code against. Such code helps make complex systems more easy to understand, which in turn helps create better security controls.

Yet we neither build apps alone nor build them to never be used by people. This is where RPGs come into play. Tabletop RPGs are collaborative story-telling exercises with as much conflict, drama, and shared success as there is in developing and securing apps. We have technical references and top 10 lists for app vulns. In appsec, we don’t have a similar level of documentation and advice around working with people and building threat models with people in mind. This is a step towards raising awareness of resources and work that already exists and would be a great addition to a DevOps approach to software.

(ISC)2 Security Congress 2018 Presentation

Here are slides for my presentation, “DevOps Is Automation, DevSecOps Is People.” It’s about exercising communication skills, establishing empathy, and considering threat models that consider people.

Communication skills are a part of inserting security into the DevOps process. Empathy is about understanding not only the engineering constraints that DevOps teams face, but also the population of users who will be using an application. We have references for technical flaws and weaknesses like the OWASP Top 10 and the related ASVS. We don’t have as many easy references for the people aspect of security.

Apps are built through collaboration and they’re built for people to use. Security should work as an enabler for DevOps teams to create more secure apps. Part of that security comes from acknowledging that the people who use apps aren’t a monolithic population with static threat models. Threat models should still reference the OWASP Top 10 and STRIDE. Those provide good ways to reason through technical issues in order to build technical controls. But those threat models also need to consider social dimensions of security, such as privacy, abuse, and whether the user experience influences good security behaviors or addresses threats facing those who use the app.

Part of the presentation shows how role-playing games are frameworks for groups to build shared stories, which is relevant to building secure apps. That sense of collaboration, which still involves conflict, is a great way to exercise the skills necessary to work with DevOps teams and has metaphors for understanding how different users face different threats. In an RPG, everyone gets to roll dice. In appsec, everyone should have security that addresses their needs. Collaborative approaches avoid the unproductive attempts to blame devs or users and instead focus on meaningful solutions.


Last week I attended the OURSA conference. I tweeted during the conference and wrote up some reasons why I enjoyed the content so much. Briefly, the format (~15 minute presentations followed by panel discussion) kept the themes well-focused. It was also impressive that the conference stayed so well on schedule. But these are more superficial  observations about the execution of the conference. The content and quality of presentations was what really kept my attention throughout the day.

Read some more at

Check out the recording of the event at


OWASP AppSec Cali 2018 Presentation

Here are slides for my presentation, “DevOps Is Automation, DevSecOps Is People.”

For me, automation is one of the most compelling aspects of DevOps. Without automation you won’t reach scale, you’ll struggle with maintenance and patch management, and you’ll only have a foggy notion of the risk your app has.

DnD ShelfIn addition to scaling, we want to make repetitive and complex tasks automatic for the people who do them. Exposing DevOps teams to the tasks of building and maintaining software shows that everybody hurts sometimes.

The cloud has enabled systems to be abstracted to code and APIs. This doesn’t mean that they’ll be more secure, but it does mean that the maturity you bring to code quality for you app can translate to the code quality for your systems and architecture. What we don’t have are APIs for people.

And software is ultimately made by and made for people. You might even say it’s made of people. (Some apps are more people than others…)

This presentation was a bit of a survey of topics, comments, and examples of how to improve not only how we work with people to add security to the DevOps pipeline, but additional things to consider as we build threat models for the apps being deployed. For example, it’s one thing to talk about weakness in “business logic” that may lead to privilege escalation or data theft. It’s another to consider how an app’s features can be used to abuse or harass other users.

In appsec we have lists, more lists, recommendations, secure coding guidelines, and more lists. But they’re meaningless without people to place them in context and take action. Communication and empathy are key to understanding how to improve the way we integrate security into processes successfully and build apps that serve people well.

In a way they’re like tabletop role-playing games. RPGs have lists and tables and appendices and dice and more tables and lists. They have threats and unexpected situations. But it’s the people that bring the game to life.

The Fourth Year of the Fourth Edition

Today is the fourth anniversary of the fourth edition of Anti-Hacker Tool Kit. Technology changes quickly, but many of the underlying principles of security remain the same. The following is an excerpt from the introductory material.

Welcome to the fourth edition of the Anti-Hacker Tool Kit. This is a book about the tools that hackers use to attack and defend systems. Knowing how to conduct advanced configuration for an operating system is a step toward being a hacker. Knowing how to infiltrate a system is a step along the same path. Knowing how to monitor an attacker’s activity and defend a system are more points on the path to hacking. In other words, hacking is more about knowledge and creativity than it is about having a collection of tools.

Computer technology solves some problems; it creates others. When it solves a problem, technology may seem wonderful. Yet it doesn’t have to be wondrous in the sense that you have no idea how it works. In fact, this book aims to reveal how easy it is to run the kinds of tools that hackers, security professionals, and hobbyists alike use.

A good magic trick amazes an audience. As the audience, we might guess at whether the magician is performing some sleight of hand or relying on a carefully crafted prop. The magician evokes delight through a combination of skill that appears effortless and misdirection that remains overlooked. A trick works not because the audience lacks knowledge of some secret, but because the magician has presented a sort of story, however brief, with a surprise at the end. Even when an audience knows the mechanics of a trick, a skilled magician may still delight them.

The tools in this book aren’t magical; and simply having them on your laptop won’t make you a hacker. But this book will demystify many aspects of information security. You’ll build a collection of tools by following through each chapter. More importantly, you’ll build the knowledge of how and why these tools work. And that’s the knowledge that lays the foundation for being creative with scripting, for combining attacks in clever ways, and for thinking of yourself as a hacker.

I chose magic as a metaphor for hacking because it resonates with creative thinking and combining mundane elements to achieve extraordinary effects. Hacking (in the sense of information security) requires knowing how protocols and programs are put together, and the tools to analyze or attack them. I don’t have a precise definition of a hacker because one isn’t necessary. Consider it a title to be claimed or conferred.

Another reason the definition is nebulous is that information security spans many topics. You might be an expert in one, or a dabbler in all. In this book you’ll find background information and tools for most of those topics. You can skip around to chapters that interest you.

The Anti- prefix of the title originated from the first edition’s bias towards forensics and equating Hacker with Attacker. It didn’t make sense to change the title for a book that’s made its way into a fourth edition (plus I wanted to keep the skull theme cover). Instead, consider the prefix as an antidote to the ego-driven, self-proclaimed hacker who thinks knowing how to run canned exploits out of Metasploit makes them an expert. They just know how to perform a trick. Hacking is better thought of as understanding how a trick is put together, or being able to create new tricks on your own.

Each chapter should set you up with some of that knowledge. And even if you don’t recognize a magical allusion to Hermione, Tenar, or Gaius Helen Mohiam, there should be plenty of technical content to keep you entertained along the way. I hope you enjoy the book. At some point there may even be a fifth edition.

DevSecCon London 2017

BugsAh, London — the city responsible for most of my music collection. Also, the city where I recently had the fortune to present at DevSecCon.

DevSecCon examines the challenges facing DevSecOps (and DevOps) practitioners. It emphasizes how to work with people to make tools and process part of the CI/CD pipeline. This resonates with me greatly because I strongly believe that effective security comes from participation and empathy.

DevSecOps brings security teams into the difficult tasks of writing, supporting, and maintaining code. It’s a welcome departure from delivering a “Go fix this” message. Sometimes developers need guidance on basic security principles and an introduction to the OWASP Top 10. Sometimes developers have that knowledge and are making tough engineering choices between conflicting recommendations. Security shouldn’t be the party that says, “No”. Their response should be, “Here’s a way to do that more securely.”

The “Go fix this” attitude has underserved appsec. We live in an age of 130,000+ Unicode characters and extensive emoji. Yet developers must still (for the most part) handle apostrophes and angle brackets as special exceptions lest their code suffer from HTML injection, cross-site scripting, or a range of other injection-based flaws.

All this is to say, check out my presentation, which explores this from the perspective of vuln discovery — and that too much investment in vuln discovery at the time when an app reaches production misses the chance to build stronger foundations.

Slides from all the presentations are available at this link.

DevOps Is Automation, DevSecOps Is People

A lot of appsec boils down to DevOps ideals like feedback loops, automation, and flexibility to respond to situations quickly. DevOps has the principles to support security, it should have to knowledge and tools to apply it.

Real-world appsec deals with constraints like time, budget, and resources. Navigating these trade-offs requires building skills in collaboration and informed decision-making. On the technology side, we have containers, top 10 lists, and tools. Whether we’re focused on more efficient meetings or trying to driving change across an organization, we need equal attention on techniques that make the social aspects of security successful.

We build automation with apps. We build relationships with people. This presentation explores methods for establishing incentives, encouraging participation, providing constructive feedback, and reaching goals as a team. It shows different ways to use metrics and communication to drive positive behaviors. These are important skills not only for managing teams, but for influencing appsec among peers and growing a career.

Security is an integral part of DevOps. And, yes, it’s made of people.

Here’s a new abstract to seed content for the blog and for conference talks. I’ve alluded to people before, where they are the target of consumption. Now I’d like to look at people as both the audience to benefit from appsec as well as the collaborators for improving it.

Stay tuned for more!

ISC2 Security Congress, 4416 – GBU Slides

RattlesnakeMy presentation on the good, the bad, and the ugly about crowdsourced security continues to evolve. The title, of course, references Sergio Leone’s epic western. But the presentation isn’t a lazy metaphor based on a few words of the movie. The movie is far richer than that, showing conflicting motivations and shifting alliances.

The presentation is about building alliances, especially when you’re working with crowds of uncertain trust or motivations that don’t fully align with yours. It shows how to define metrics and use them to guide decisions.

Ultimately, it’s about reducing risk. Just chasing bugs isn’t a security strategy. Nor is waiting for an enumeration of vulns in production a security exercise. Reducing risk requires making the effort to understand what what you’re trying to protect, measuring how that risk changes over time, and choosing where to invest to be most effective at lowering that risk. A lot of this boils down to DevOps ideals like feedback loops, automation, and flexibility to respond to situations quickly. DevOps has the principles to support security, it should have to knowledge and tools to apply it.

RVAsec 2017: Managing Crowdsourced Security Testing

This June at RVAsec 2017 I continued the discussion of metrics that reflect the effort spent on vuln discovery via crowdsourced models. It analyzes data from real-world bounty programs and pen tests in order to measure how time and money might both be invested wisely in finding vulns. Here are the slides for my presentation.

We shouldn’t chase an eternal BugOps strategy where an app’s security relies solely on fixing vulns found in production. We should be using vuln discovery as a feedback mechanism for improving DevOps processes and striving to automate ways to detect or prevent the flaws that manual analysis reveals.

And when we must turn to manual analysis, we should understand the metrics that help determine when it’s efficient, effective, and contributing to better appsec. This way we can being to model successful approaches within constrained budgets.


OWASP AppSec EU 2017 Presentation

FireHere are the slides for my presentation at OWASP AppSec EU this year: The Flaws in Hordes, the Security in Crowds. It’s an exploration of data from bug bounty programs and pen tests that offers ways to evaluate when a vuln discovery strategy is efficient or cost-effective.

OWASP records the sessions. I’ll post an update once video is available. In the meantime, you check out some background articles on my other blog and keep an eye out here for more content that expands on the concepts in the presentation.