Ah, 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 The Flaws in Hordes, the Security in Crowds, 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 here.

Asking a DevOps team what they’re most worried about in their app is a great way to seed a conversation about risk. In my recent presentations, I’ve taken to emphasizing the use of threat modeling exercises as an avenue towards security awareness. Threat models are ways of reasoning about different ways an app’s data or users might be compromised. They can also be great ways to build security awareness by encouraging creative thinking about an app’s security in a way that drives constructive conversation and minimizes judgement about lack of security knowledge.

A key element to such discussions is using the “Yes, and…” principle, in which you guide the conversation not by negating someone’s ideas, but expanding on them or offering an alternative viewpoint. In this exercise, you are the security expert filling in gaps in knowledge and nudging tangents away from unlikely scenarios, but letting the DevOps team drive the discussion amongst themselves.

Bikeshredding is when this exercise devolves into distraction. The term echoes “bikeshedding” — a situation where a software engineering discussion becomes overwhelmed by details irrelevant to the problem at hand. For example, if your problem relates to efficient structures for storing bicycles, it’s unlikely that the color of the structure contributes meaningfully to that efficiency. And that such ill-timed attention is counterproductive to the core task. It may also be as much about arguing over subjective choices as it may be about misusing data as an illusion about objective preferences.

In bikeshredding, a threat model becomes disjoined from reality. It may represent a scenario unduly influenced by ideology or one based on incomplete (or ignored) information.

A strong indicator of bikeshredding are models that begin with “Assuming...” or “All you need to do is...”. For example, “Assuming the Same Origin Policy is broken, then...“ it may not be necessary to continue this sentence if it involves a discussion of cross-site scripting or anti-CSRF tokens. Or perhaps the setup to an attack “just requires a DNS or BGP hijack” before the vuln under discussion could be exploited.

That doesn’t mean such scenarios aren’t impossible or that they should be dismissed. It does mean that threats are not unbounded agents that visit great woe unto apps or networks. Threat actors (those executing an attack) require resources and preparation. In some cases, those resources and prep may be nothing more than a browser bar and an unvalidated URL parameter. In other cases, those costs or sequence of events may be high and complex.

There is a place for stunt hacks, where an SDR Bluetooth spoofer affixed to a hedgehog launched (safely, with parachute) from a drone hacks an IoT fridge in order to obtain some tasty insects stored therein. Tinkering and creativity are fun. Always educational, it can sometimes inform practical appsec.

But there’s a reason that legacy systems and legacy software are notorious attack vectors. They’re easy and cost little for the attacker.

As you mature your organization’s stance and have more robust ways to respond to threats, you’ll also increase the time and resources required of an attacker. Over time, you’ll understand how successful attacks are executed. And, although you’ll continue to improve your app’s baseline security to prevent exploits, it’s highly likely that you’ll discover that an efficient detection and response becomes an equally important investment.

Use threat models to spread security knowledge throughout a DevOps team and engage them in prioritizing countermeasures and containment. Help them be informed about security topics and the chain of events necessary for various attacks to succeed. Avoid the bikeshredding and let them build the structure that handles user data with minimal risk.

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

The summer conference constellation rises over Las Vegas for about one week every year. The trio of Black Hat, BSidesLV, and DEF CON historically generates loud, often muddled, concerns about personal device security. Sometimes the concern is expressed through hyperbole in order to point out flawed threat models. Sometimes it's based on ignorance tainted with misapplied knowledge. Either way, perform the rituals and incantations that make you feel better. Enjoy the conferences, have fun, share knowledge, learn new skills.

Whatever precautions you take, ask why they're necessary for one special week of the year. If the current state of security for devices and web sites can't handle that week, I find that a failure of infosec and an indictment of appsec's effectiveness after three decades.

It's another way of asking why a device's current "default secure" is insufficient, or asking whether we need multi-page hardening guides vs. a default hardened configuration.

Keep in mind there are people with security concerns all 52 weeks of the year. People who are women. People in minority groups. People in abusive relationships. People without political representation, let alone power. Most often these are people who can't buy a "burner phone" for one week to support their daily needs. Their typical day isn't the ambiguous threat of a hostile network. It's the direct threat from hostile actors -- those with physical access to their devices, or knowledge of their passwords, or possibly just knowledge of their existence. In each case they may be dealing with a threat who desires access to their identity, data, and accounts.

There are a few steps anyone can take to improve their baseline security profile. However, these are just a starting point. They can change slightly depending on different security scenarios.

(1) Turn on automatic updates.

(2) Review authentication and authorization for all accounts.

• Use a password manager to assign a unique password to every account.
• Enable multi-factor authentication (MFA), aka two-factor authentication (2FA) or two-step verification (2SV), for all accounts that support it.
• Prioritize enabing MFA for all accounts used for OAuth or social logins (e.g. Apple, Facebook, Google, LinkedIn).
• Prefer WebAuthn authentication flows. It cryptographically binds credentials between the user device and server. This prevents replay attacks if the traffic is intercepted and reuse attacks if the server's credential store is compromised.
• Review third-party app access (usually OAuth grants) and remove any that feel unnecessary or that have more permissions than desired.

(3) Review MFA support (or activation factors as NIST 800-63B calls them)

• Prefer factors that rely on FIDO2 hardware tokens, biometrics, or authenticator apps.
• Only use factors based on SMS or email if no better option is available.
• For authenticator apps, enable backups or multi-device support in order to preserve access in case of a lost device.
• Record and save recovery codes associated with enabling MFA. Choose a storage mechanism sufficient for your needs, such as printed and placed somewhere safe or in a password-protected keychain.

Talk to someone who isn't in infosec. Find out what their concerns. Help them translate those concerns into ways of protecting their accounts and data.

Apple recently released Lockdown Mode in iOS 16, iPadOS 16, and macOS Ventura. It provides users with increased protection for their system by ensuring a secure default as well as disabling features that typically have security issues. It's effectively a one-click hardening guide and attack surface reduction. By disabling feeatures prone to abuse, it carries a useability cost. But ultimately it's an easy way for any user to have more security when they need it.

Not everyone has an iPhone and not everyone has threats limited to account takeover.

One resource with technical recommendations in non-technical jargon is Speak Up & Stay Safe(r).

The EFF has a wide collection of practices and tools in its Surveillance Self-Defense guide. Notably, it lists different security scenarios you might find yourself in and how to adapt practices to each of them.

The expectation for modern devices and modern web sites should be that they're safe to use, even on the hostile network of an infosec conference. If an industry can't create a safe environment for itself, why should it be relied on to create a safe environment for anyone else.

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 a Sisyphean 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 begin to model successful approaches within constrained budgets.