Read Time: 6 minutes

Vulnerable U Community,

Welcome to this week's edition of Vulnerable U, where we delve into the world of cybersecurity and explore the power of vulnerability.

This week, we'll learn how to harness the strength of strategic quitting. Plus, we'll share an inspiring story of how a self-reported security incident led to a game-changing revelation about developer experience.

Topic of the Week:

“A quitter never wins and a winner never quits."

We've all heard some version of this saying. Growing up, many of us were encouraged to stick with things longer than we wanted, be it sports, piano lessons, or friendships. Our families had our best interests at heart, pushing us not to give up easily.

I’m a big fan of Stephen Dubner and Steven Levitt, authors of Freakonomics and Think Like a Freak. In their more recent work on podcasts[1][2] and in their research, they suggest quitting isn't always a bad thing and shouldn't be viewed so negatively. I’d like to pull from this and apply it to our tech lives.

Picture this: You're a senior tech team member responsible for managing large data projects, but you're struggling with limited resources and inadequate tools. After months of research and evaluation, you finally identify the perfect vendor, persuade your company's leadership to sign off on the substantial investment, and eagerly await the benefits.

With high hopes, your team works relentlessly for months to implement the new tool, navigating the complexities of integrating it into your existing systems. However, after all the hard work, you find the tool falling short of your expectations. The promised efficiency gains are nowhere to be found, and your team is struggling to adapt to the new system. Worse yet, the vendor's support is subpar, leaving you to troubleshoot problems on your own or spend precious professional service dollars seeking help.

Now you're faced with a difficult decision: continue investing time and resources into a seemingly failing solution, or cut your losses and explore alternatives.

What do you do?

The dilemma outlined above brings forth a lot of points that Dubner and Levitt hit on in their research, namely Sunk Cost Fallacy.

Once you’ve spent a certain amount of time, money, or blood, sweat, and tears on a given project, it becomes so hard to walk away from it. But that’s the wrong way to think about it. The right way to think about it is, What’s the opportunity cost of continuing to work on this project?

Some things to consider:

1. The project is no longer aligned with your goals: As your organization evolves, its goals and priorities may change. If a technology project is no longer contributing to your strategic objectives, it's worth considering whether it's time to abandon it and invest your resources elsewhere.

2. The costs outweigh the benefits: If the resources required to complete a technology project have exceeded the anticipated benefits, or if it's clear that they will, it's time to reevaluate. Be honest with yourself about the true costs of the project, including time, money, and opportunity costs.

3. The technology landscape has changed: Innovations and breakthroughs can quickly make a project obsolete. If new technologies or platforms have emerged that would better serve your needs, it might be time to pivot and adapt to the changing landscape. Think of all the data center engineering teams in the middle of a build out when AWS started to blow up.

4. Team morale is suffering: If a project is causing significant stress and frustration among team members, it could be a sign that it's time to reevaluate. A toxic environment can lead to burnout and turnover, which can ultimately harm your organization's overall success.

No matter what, it takes a person being vulnerable after putting all that time and money on the line to know when to quit and back out of a project. The power here is that the vulnerable leader may take a few dings to the armor but if executed properly, quitting will be for the greater good.

When have you quit something very difficult but ultimately for the best?

Elective Reading

Here are some things I’m reading right now and some cliff notes or thoughts:

This one was so good - I wrote a whole blog post about it: mattjay.com

“The reality is that today cloud security is often separate from cloud,” Anne Neuberger, the deputy national security adviser for cyber and emerging technology, said last week during a roll-out event for the new cyber strategy. “We need to get to a place where cloud providers have security baked in with that.”

File under: “Real life consequences to bad cybersecurity processes and transparency”

How much will AI Large Language Models like the GPTs start to augment modern security orgs? Can it cut thousands of combined hours spent on policy writing and reporting monthly OKR progress down to minutes?

Krebs, solid as always, discusses the latest US Cybersecurity Strategy I linked in last week’s newsletter.

When your phishing kits have better feature development and customer support than your enterprise software. Great writeup from Microsoft looking into a modern phishing kit causing pain for orgs across the net.

Good writeup about a malware operation targeting Facebook Business Ads Platform

The Power of Vulnerability:

Recently, one of our team members bravely self-reported a security incident. The individual had inadvertently leaked production credentials to a third-party, potentially exposing sensitive company data. While this could have easily turned into a blame game, I chose to see it as an opportunity for growth.

Instead of pointing fingers, I sat down with the developer to understand what led to the incident. It quickly became apparent that the root cause wasn't a lack of security awareness, but rather, a poor developer experience that made it difficult to work securely. Our developers were struggling to access the resources they needed without resorting to using production credentials on their local machines.

Recognizing this, we used the incident as a catalyst to improve our development environment. Our security and development experience teams are now collaborating to create a more streamlined and secure process, ensuring that developers can access the resources they need to code without resorting to less secure shortcuts.

What other appsec issues are just developer experience issues in disguise?

One of my key take aways here and challenges to you: instead of blaming individuals for security lapses, examine the underlying systems and processes that may contribute to these incidents.

I’d like to thank the team member who had the courage to come forward and share their experience. Their vulnerability allowed us to learn, grow, and build a more resilient security posture. Remember, we're all in this together.

Community Spotlight:

Please write to me and share stories or anecdotes for this section. It goes very well with the theme of being vulnerable together to share stories. I’d especially love to hear about your failures. What is a time you failed? What did you learn? How did it change your life?

Extra Credit:

Help Us Grow! If you know someone who might be interested in joining the Vulnerable U community, please share this newsletter with them! As of now, spread will just be by word of mouth.

Parting Thoughts:

As always, let me know how I can help. If there's a topic you'd like to see covered in a future edition of the newsletter, or if you have any questions or concerns, please don't hesitate to reach out. I’m always happy to hear from our readers and help in any way I can.

Stay safe, Matt Johansen
@mattjay