Posts (page 11 of 43)
-
Some Appsec Haikus Dec 15, 2022
Writing show intros provides a brief and enjoyable creative outlet. I have yet to present a haiku, although I have dipped into limericks – of which I have several more drafts in the queue. In one October episode I reimagined a stanza from The Raven.
And now I have a few experiments with haikus.
That popular web app security listTen plagues on software OWASP documents them all Bug bounties prosperPrioritizationA vuln disclosure CVSS rating high Maybe I’ll fix itHype or critical...A vuln disclosure CVSS version 3 UncalculatedReading someone else's codeCode review begins Visions of apocalypse A plus one appearsGit. When things go right.Merge request is sent Git undertakes a commit A branch perseveresGit. A three-letter command for producing four-letter words.Git rebase push pull Force reset now detached head The branch defeats usCryptocurrencieslol lmao seriously so much lol and a little fraudWeb3Inspiring problems Decentralized solutions Ends in vaporware -
DevSecCon London 2018 Presentation Oct 19, 2018
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.
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 Oct 13, 2018
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.