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.

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.

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.

Infosec conferences are a great venue for sharing tools, techniques, and tactics across a range of security topics from breaking systems to building them. Not only are they a chance to learn from peers, but to meet new ones and establish connections with others who are tackling similar problems. One eternal topic is the “shift left” motto — building security into the SDLC as early as possible.

One way to shift left is to make sure developers aren’t left out of the conversation. Not every dev team has the budget to attend security conferences and quite often security conferences are attended by practitioners who aren’t building software as part of their daily work. I’ve attended many security conferences (and enjoy them!), but I’ve also wanted to find conferences that are oriented towards developers in order to bring an appsec message to them rather than expect them to discover security by chance.

This week I had the opportunity to present at the Star West developer conference. My presentation was about building metrics around the time and money invested in finding vulns within apps. It pulls data from real-world bounty programs and pen tests. It’s not hard to determine that finding vulns is important. But it can be hard to figure out when the time and money spent on finding them is well spent and when those investments could be directed to other security strategies.

A few points of the presentation were

• Always strive to maintain an inventory of your apps, their code, and their dependencies. This is easier said than done, but it’ll always be a foundational part of an appsec program.

• Find metrics that are meaningful to your program. For example, if you’re running a bounty program, when would it make more sense to attract more participants vs. engage the most prolific vuln reporters? If you’ve never conducted any security testing against an app, should you start with a pen test or a bug bounty? How might that choice affect your appsec budget?

• Organizations and apps vary widely. Resist trying to compare your own metrics to other programs whose context, assumptions, and environments don’t match yours. Instead, follow your own metrics over time in order to observe trends and whether they’re influenced by your security efforts.

Although the presentation begins with data related to finding vulns, it doesn’t forget that fixing vulns is what contributes to making apps more secure. Regardless of how you’re discovering vulns, your DevOps team should be fixing them. Which also means you should have some metrics around that process.

One of the ways I looked at this data was in the relative time it takes organizations to fix different categories of vulns. Rather than ask how long it takes to fix all vulns, I thought it’d be interesting to see how quickly different types of vulns are fixed relative to each other.

In the following chart I took the average time to fix all vulns, then compared different categories against that average. In this case, it wasn’t too surprising to see that Remote Code Execution stood out as requiring fewer days than average to fix — it’s typically a high impact vuln that puts an app at significant risk of compromise. On the other hand, Redirects & Forwards took a longer time to fix. One theory could be that the greater number of days is related to the relatively low risk of such vulns and don’t need immediate attention. Another theory could be that such vulns are more difficult to fix due to nuances in allowing certain types of redirects while disallowing others. Knowing that Redirects & Forwards dropped off the OWASP Top 10 list in the recent 2017 update lends additional support to the idea that these are lower risk vulns.

In any case, having metrics puts us on the path to data visualization. These steps enable us to start answering initial questions about the state of an app’s security. And then gives us a chance to ask follow-up questions about whether processes are working or whether we have blind spots in the data we’d like to have.

Appsec doesn’t happen in a vacuum. There’s a big difference between lamenting a perceived lack of security awareness among developers and engaging them on security issues that are relevant to their work. In addition to being relevant, the message should be constructive. Adding metrics to the discussion helps illuminate when efforts are successful, where they can be improved, and where more data is needed. Include the DevOps team as active participants in developing questions and metrics. Audience participation is a great way to build better appsec.

Data breaches happen. That doesn’t mean it’s acceptable for application owners to neglect security or be cynical about protecting data. It means that app owners need to be aware of how their organizations and the data they collect might be targeted. They need to review what controls and processes they have in place to make attacks more difficult or more easy to detect. And it means they should be ready to respond quickly and effectively in the event of a breach.

Be Practical

Data you don’t possess can’t be compromised. Of course, many apps are driven by data or need to collect data in order to provide value. But in many cases the utility of data degrades over time. There’s a point where the liability of holding onto data outweighs its value.

One way to approach data handling is reframing the metaphor you associate with it. For example, data can be toxic — accumulate as little as possible, be careful about collecting large doses. Perhaps it’s radioactive — it contaminates every system it touches and therefore those systems need to be protected. Or maybe you consider it digital oil — a valuable, finite resource that has significant negative consequences when it spills.

In any case, be aware of the nature of the data you collect, why it’s being collected, where it’s being stored, and when you can delete it. Again, these are easier said than done, but laying out a framework for the lifecycle of data (from collection to deletion) will help guide how you protect it.

Be Proactive

Encryption is necessary to protect data. It’s not sufficient (strong access control and authorization schemes are important as well), but it’s a baseline expectation for handling data.

Encrypt communications — HTTPS should be enabled and enforced by default with an HSTS header. The Let's Encrypt project has made it easier to deploy HTTPS sites as part of a DevOps process. It provides free certs, removing objections of initial cost, and its ACME protocol enables automation to maintain, renew, and revoke certs.

Encrypt storage — Data lands in surprising places, from the typical databases, and data stores to AWS S3 buckets that notoriously expose their content due to misconfigurations. Cloud services have made it easier to deploy to instances running encrypted filesystems and interacting with APIs that manage hardware-based key stores. Of course, apps need to work on decrypted data (unless you’ve moved into more sophisticated crypto), so don’t expect this to be the only solution you need.

Protect secrets — Encryption will need private keys and shared secrets. APIs will need access tokens. Make it unnecessary to place credentials in code. Monitor commits and repos for accidental inclusion of private keys, tokens, and passwords.

Rotate secrets — Have a process to revoke and replace compromised or exposed secrets. If you’re encrypting data, but it takes two weeks to rotate encryption keys, then that’s a dangerous level of exposure.

Conduct security testing — Run pen tests to evaluate the baseline and recheck at key milestones. Maintain a bug bounty program to manage vulnerability reports. Use red team exercises to check for gaps in your monitoring and detection capabilities.

Be Prepared

Being prepared means you don’t have to make every decision and take every action under pressure. During a breach investigation there’ll always be pressure and time constraints and legal questions, but being prepared with data and how to answer basic questions will free up time to tackle the challenges you didn’t anticipate.

Just following the few steps of finding out when data is being collected and where it resides will reveal who the stakeholders are that may need to be part of the conversation when a breach occurs. It also helps identify who should be responsible for encrypting communications and storage. The modern DevOps model builds security into processes and technology. Security teams become participants in the CI/CD process, not gatekeepers who only drop in for random inspections.

Discover what you don’t know, whether it’s a data store that’s been forgotten and ill-protected or access controls that lend more access than control. Use a pen test to review the security of your apps. Use a bounty program to enable a continuous feedback loop. Engage a red team to test the technology and processes you’ve put in place to detect and respond to breaches.

All of these exercises will help you in the unfortunate event that a breach occurs. They’ll also help focus on recovery and improvement instead of falling into blame and chaos.