Before I dive into this week’s sermon, just a quick note that our posting will be a bit off through the end of the year. As happens from time to time, our collective workloads and travel are hitting insanity levels, which impedes our ability to push out more consistent updates. But, you know, gotta feed the kids and dogs.
Today’s news means we are going from accepting entries from only a handful of individuals capable of inventing new mitigation bypass techniques on their own, to potentially thousands of individuals or organizations who find attacks in the wild. Now, both finders and discoverers can turn in new techniques for $100,000.
While you’re thinking about little kids in scary costumes, I’m here thinking about adults who write scary code. As I go through the results of a couple different companies’ code scans I am trying to contrast good vs. bad secure development programs. But I figure I should ask the community at large: What facet of your secure software development program has been most effective? Can you pinpoint one?
Almost everyone you know is blissfully unaware of the digital footprints we all leave, and how that information can be used against us. The problem is that you understand, and if you spent much time thinking about it you’d probably lose your mind. So as a coping mechanism you choose not to think of how you could be attacked or how your finances could be wrecked, if targeted by the wrong person.
As I wrote a few weeks ago, everyone has their strengths. I know that managing the details is not one of mine. In fact I can’t stand it, which is very clear as we prepare for our oldest daughter’s Bat Mitzvah this weekend. It’s a right of passage signaling the beginning of adulthood. I actually view it as the beginning of the transformation to adulthood, which is a good way to look at it because many folks never complete that transition – at least judging from the way they behave.
This is part 3 in a series.Click here for part 1, or submit edits directly via GitHub.
Even mature organizations occasionally struggle to keep security aligned with infrastructure. But low-friction processes that don’t overly burden other areas of the enterprise reduce both errors and deliberate circumvention.
This is part 2 in a series.Click here for part 1, or submit edits directly via GitHub.
As mentioned in the previous section, this process is designed primarily for more complex networks, and takes into account real-life organizational and technological complexities.
This is the first post in a new paper I’m writing.The entire paper is also posted on GitHub for direct feedback and suggestions. As an experiment, I prefer feedback on GitHub, but will also take it here, as usual.
Dave Elfering had a good post, making clear the difference between managing and leading.
I thought my job as a security leader was to produce detailed policies that might as well have been detailed pseudo code executed by robots.
Every year Mike, Adrian, and I get together for a couple days to review our goals and financials, and to make plans for the next year. This year we scheduled it in Denver, and by an amazing coincidence Jimmy Buffett was in town playing.