Posts (page 13 of 43)

• OWASP AppSec Cali 2018 Presentation Jan 30, 2018

  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.

  

  In 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 Jan 14, 2018

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

  

  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) involves knowing how protocols and programs are constructed, plus the tools to analyze and 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 – your choice.

  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 that tended to equate 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-themed cover.

  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 only know how to repeat a simple trick. Hacking is better thought of as understanding how a trick is constructed or being able to create new ones of your own.

  Each chapter sets you up with some of that knowledge. And even if you don’t recognize an allusion to 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.

• Crucial Timing for Critical Vulns Jan 12, 2018

  Time, like love, is a universal subject in songs. Time is also a universal theme when discussing vulns; it’s a key component of risk. Equally universal is the heartbreak we feel when finding out about critical vulns or trying to figure out how to fix them.

  Identifying vulns is an important part of evaluating an app’s overall risk. Vuln discovery comes from many sources — scanners, crowds, pen tests, red teams, devs, or others. These are also affected by the budget available for vuln discovery.

  Fixing vulns is an important part of reducing an app’s overall risk. Whether you primarily find or fix vulns, it’s helpful to shift perspective between the two tasks. Both sides should be working against similar threat models, but the information they have will affect how each interprets, expands, or contracts those models. It’s mutually beneficial when teams can educate each other on how they perceive these models. This is especially important for resolving vulns efficiently and effectively.

  My previous post looked at average resolution times across vuln categories. It revealed a stark bias that the category of Redirects and Forwards took by far the greatest amount of days to resolve, with an implication that such vulns likely pose the least risk and therefore require the least investment of DevOps attention.

  In continuing the theme of resolution, here’s a graph that shows the relative number of days to resolve vulns of different risk levels. The days are measured against the average resolution time across all vulns. Fewer days represents a faster fix, greater days a longer one.

  

  It’s refreshing to see that the most critical vulns are fixed more quickly than average, and unsurprising to see that low-risk vulns take far longer than average. The top and bottom match what we’d expect from DevOps teams prioritizing their efforts based on risk.

  But the graph doesn’t form an idealized Z, where the number of days would be least (left-hand side) for the most critical vulns and progressively increase (towards right-hand side) for less critical ones. What’s going on in the middle?

  This messy middle provides a seed for many different discussions. As a metric, the number of days until a vuln is resolved is important, but it offers an incomplete story. Some vulns might be easy to find, but complex to fix. Some vulns might have one level risk when reported, but a lower one when reviewed by the DevOps team — not uncommon when the person who discovers the vuln doesn’t have the full context of the vuln’s impact. Others might be resolved by accepting the risk.

  (We might also use this to start a discussion on whether risk has been assigned in an effective manner. Calculating and managing risk is something for future posts.)

  As in that previous post, I haven’t noted any specific numbers related to the days. We’ll tackle SLAs and concrete timelines in a future post. The focus here is whether the criticality of a vuln influences the time it takes to resolve it. In the ideal world, they should be inversely related (more critical takes less time). But we live in the real world, where DevOps teams must make engineering trade-offs, address underlying problems, revisit assumptions, and review architectures.

  Fortunately, it looks like many organizations focus attention on critical vulns. The real world is messy — just listen to all those songs about time and love. Metrics don’t make things any cleaner, but they can give us different ways to evaluate just how messy it is.