Author: Mike Shema

(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.

OURSA Recap

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 https://blog.cobalt.io/oursa-their-presentations-and-your-follow-up-2ba6240f4559.

Check out the recording of the event at https://youtu.be/pcUDzHb4Gdo.

 

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.

Cybercroissant Podcast Episode

While I was at DevSecCon earlier this year I had a chance to record a podcast episode with Cybercroissant. You can find it on their site.

During the conversation I brought up a parallel between magic tricks and hacking. That idea is perhaps better described in the introduction to my last book, which I’ve excerpted below.

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 domains. 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. 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 over a decade later. (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.

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.

Now One Week All Year

The annual summer conference constellation of the week of Black Hat, BSides, and DEF CON usually brings out a certain vocal concern about personal device security. Some of the concern is grounded in wry humor, using mirth to illustrate a point. Some of it floats on ignorance tainted with misapplied knowledge. That’s fine. Perform the rituals and incantations that make you feel better. Enjoy the conferences, have fun, share some knowledge, learn some skills.

But after you select a level of extra precaution. Ask why such a choice is necessary for one week of the year. It’s a question without a single answer. As a leading question, it’s intended to elicit reasons based on a coherent threat model that addresses the week’s anticipated behaviors and environments. As an antagonistic question, it’s intended to explore why “default secure” is insufficient or why, after more than two decades of one-week-a-year concern, system and device security is so poor that none of it can be trusted outside your home network.

As you ponder an answer, take a moment to help someone else improve their baseline security profile.

  • For a mobile device, set a passcode longer than four characters.
  • For a mobile device, enable Touch ID or similar biometric feature.
  • Turn on automatic updates.
  • Enable multi-factor authentication (MFA, 2FA, Security Key, App Authenticator, or whatever synonym it supports) for their email, social media, and financial accounts.
  • Record and save recovery codes associated with enabling MFA. Help them choose an effective storage, such as printed and placed somewhere safe or in a password-protected keychain.

As a follow-up to enabling MFA, help them update and make unique each of their passwords.

  • Install a password manager.
  • Starting with their most-used sites, go through the password change process and allow the password manager to assign a new, unique password. If they wish to have a memorable password, ensure that it’s only used for that account.
  • Review any OAuth or Social Logins used for the account, e.g. if they use Facebook, Twitter, LinkedIn, or similar to authenticate to the site or to allow access to their social account.

Now consider that there are people whose security precautions require attention 52 weeks of the year. People who have expressed an opinion. People who are women. People in abusive relationships. People without political representation, let alone power. These are different situations that need different approaches to securing devices and data.

These are people who can’t buy a “burner phone” for one week, then return to normal. Their normal isn’t the vague threat of a hostile network. It’s the direct threat from hostile actors — those with physical access to their devices, or maybe just knowledge of their passwords, or possibly just knowledge of their existence. But in each case an actor or actors who desire to obtain access to their identity, data, and accounts.

After helping someone with the basic security hygiene of setting strong passwords and turning on automatic updates, gather resources for how to deal with different threat models and different levels of concern. Help them translate those concerns into ways of protecting accounts and data.

One resource to start with could be https://onlinesafety.feministfrequency.com/.

There’s a trope in infosec that this week has “the most hostile network” ever. A network may indeed be hostile, but a hostile playground network is far different from the threats against a network people use on a daily basis.

It can be fun as well as a great educational experience to attack a playground network. On the other hand, networks that no one can use or be expected to use aren’t reflective of security engineering. If you think a network can never be secured or a device never be safe, then you’ve possibly skipped over the exercise of threat modeling and making choices based on risk.

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.