| I'm probably oversummarizing, but this seems to boil down to burnout caused by (from the post): > But why don’t they just patch? It’s not that complicated after all. And you kinda see this later on when the author talks about what they worked on post-transition out of infosec as a mainline career: > I finally joined Michelin in December 2016 where I started working in the CERT team where my main mission was to automate scanning and reconnaissance phases [emphasis added] on internet-facing assets and this was my real first experience on the other side of the story - defending infrastructure and where I finally experienced change management (and the complexity behind it), impact evaluation and so on. It seems like the author burned out not because of the work but because wherever he ended up, there was no strategic initiative to streamline and automate patching to a point where it's largely invisible. It's also a hard problem given the risks of patching bringing reliant services down and the need to automate a slew of testing to validate that said patches won't torpedo production and mission critical systems. The bit above is important not just because it solves a problem but because (I'm convinced that) people like knowing they actually built something and enacted lasting change. And security may be one of the least likely engineering disciplines where you'll experience building a tangible product as an IC. At least in software security it's a bit easier with build and deployment pipelines offering an opportunity to block when patches are outstanding, but I can see where the burnout would arise when a strategic effort to invisibly ensure patching isn't in place or well funded. No one gets to build anything, and likewise, nothing gets solved because nothing was built. --- So if I could add another takeaway: • if your job involves running around and putting out fires, consider recommending up the chain and across the aisle all the ways to prevent the fires. And if those recommendations don't catch fire (so to speak), may be worth exploring alternative means to address the burnout risk long term with the current role. |
> It seems like the author burned out not because of the work but because wherever he ended up
Don't get me wrong and maybe I was not clear enough (my bad). The infosec part I mostly contributed to was within some consulting companies where I was hopping from one assignment to another one, having different clients every week. I saw some clients with some really strong security posture, I mean it. The "burn out" I experienced was clearly not related to that but pretty much from hacking, writing report, sleep & repeat.