lxb

This is the peak of technical self-improvement to me. Someone just spending a bunch of time on something for the sake of knowledge itself and demonstrating it can be done, regardless of the present utility of it. Dedication and follow-through are very rare these days

Using greek letters and such as variables in #golang gets a bad rep. But really, what choice do I have if all the other meaningful one-letter variable names are already taken?

I wonder if this increases the value of patch diffing results. Because P0 will not disclose what the bugs are for a long time which automatically makes patch diffing more attractive https://twitter.com/i0n1c/status/1214621661099646989 …

I dunno. I think they're writing to what they see as the baseline constraints. As my thread suggests, they're not used to dealing with a world where subjective value judgements can have such an outsized but hard-to-measure impact.

This! Is what I keep repeating at almost every live session (it’s all in the recordings, btw). Passive consumption of knowledge such as exploit write-ups has near-zero value for learning vulnerability researchhttps://twitter.com/halvarflake/status/1206641034370912258 …

I seem to get a lot of hecklers lately who insist I'm in a position of influence, so it's my duty to parrot industry orthodoxy. It doesn't work like that. I'm sure you can find the whitebread security takes you're looking for somewhere else

true, most defensive enterprise teams have no realistic view of the offensive landscape and capabilities

You know what else has collateral damage? Telling people week after week that they are noble and selfless for inflicting damage on their teams and burning them out. For prioritizing what FEELS virtuous over what the science shows leads to better results (and quieter weekends).

If you aren’t actively working to make progress, then you are blocking it no matter how positive your sentiments are. Today is the best day to start making things better for others.

Or maybe they're running their old windshield wipers that are worn out and aren't doing the job for the amount of snow that's falling, so they're just in denial that something better exists ;) I love this analogy of driving without being able to see where you're going even more.

A lot of what I hear from resistant folks sounds like "we're too busy trying to focus on driving w/ snow and ice all over our car, so we can't possibly run the windshield wipers, or heaven forbid, pull over for a second to just scrape off the ice and snow covering our windshield"

2/ Taking risks is a necessary part of becoming successful. Doing the average thing will yield an average outcome; guarantees mean there is no risk. It's impossible to be right all of the time, so life is really all about managing our risks.

1/ One of the biggest investments you can make in yourself is to make it easy for you to take risks. Most people underestimate the reward that can come from taking risks, and so fail to be bold and take a chance when they could stand to gain significantly.

My philosophy these days is: Learn esoteric stuff voraciously, apply it sparingly ;)

Hackers never became good by meeting the minimum requirements.

You added a lot of complexity, and all you got in return was you made attackers do an afternoon of work to write a new shellcode. I think the answer is you made things worse

not impressed by this newest vim vuln https://github.com/niklasb/vimrc/blame/master/vimrc#L77 … joke's on you nano users, my editor is safe and does not suck at the same time

The most controversial point is that if your security team is created from people who prefer toil to writing code, you'll never be able to scale with software. The reason there is a cybersecurity skills shortage is because we've been selecting for skills rooted against scaling.

The problem with toil is that it's addictive. You feel like you are making progress because you are busy fighting fires. But it doesn't scale and when you take a few steps back, you can see that you aren't keeping up. You have to measure and cap toil time to be able to engineer.

Until we treat securing the org as a problem that we build and maintain custom in-house software to manage, we'll fail to keep up. That means treating security experts as product owners for cross-functional agile software engineering teams that own security management systems.