Make Change Happen

“Look at email, go to meetings, discuss designs, have my head explode because people are retarded, look at vuln reports on production servers, head explodes because people haven't patched shit in 2 fuckin years, send emails, write power point presentations telling management how bad their people suck, talk to some lawyers, respond to an incident then go the fuck home to do it all over again the next day.”

That’s from a reddit thread on what security engineers do in a typical day. This person sounds frustrated.

Odds are that reddit user was never drawn to meetings or the thrill of documentation. I’ll bet that person was a bit mischievous in their youth and liked solving puzzles. That mischievous nature and problem solving satisfaction probably led to a unique skill set: They could find ways to misuse technology for nefarious intent . Maybe they wore a black hat for a time, doesn’t matter, know they’re wearing a white hat.

Now they’re spending less of their time utilizing what they learned about memory allocation, injection payloads, phishing, and malware. Now they’re spending most their time in meetings and writing emails trying to persuade others. Now they’re trying to solve a new puzzle. A puzzle requiring a different skill-set, and it’s not technical.

These are my principles for making change happen and the books I’ve learned from. I hope they can help you or anyone suffering from head exploding agony.

Don’t be a jerk

“At the end of the day people won’t remember what you said or did, they will remember how you made them feel.” -Maya Angelou

It’s easy to get lost in a technical problem and forget you’re part of a team. Technical problems tend to attract deep thinkers. These are people who spend much of their day in “focus time” and too much focus time can lead towards social skills atrophy. Dale Carnegie’s “How to win friends & influence people” is one of my favorite books, though, I’ve never liked the title. The title sounds superficial and political. Regardless of the title, it’s a great book for those of us who have developed great problem solving skills and need to improve our social skills. Those of us who need to work on not being a jerk.

Don’t put the cart before the horse.

It’s easy to forget the order of things when you’re dealing with risk every day. Add on a healthy dose of media hype when something goes wrong and it’s nearly impossible to see the forest for the trees.

Sometimes we lack perspective. Perspective to understand how our organization is funded. Generating funding comes first and reducing infosec risks comes second. Ok, sure, maybe you work in an awesome organization with great a mission and purpose - that’s part of the reason you wanted to work there. Missions and purpose don’t back paychecks and I doubt any of us want to work for free.

Ben Horowitz’s “The Hard Thing about Hard Things” is a great book on the chaos and stress of building and running a business. It’s a great book that can help with perspective. It can help us InfoSec folks blinded by vulnerability reports and stupid decisions, it can help us see the forest, and it can help us understand why servers patching isn’t always the priority.

You have to sell it

Fear, uncertainty, and despair (FUD) are crutches. Don’t be the boy that cried wolf and don’t make a mountain out of an ant hill; Both are great ways to erode ethos. Ethos, Pathos and Logos are Aristotle’s “Modes of Persuasion”. Like it or not you’re going to have to persuade others in your organization to do things and there’s no better tool than rhetoric.

There’s no better book on rhetoric than Thank You for Arguing by Jay Heinrichs

Eat elephants

All too often we have to deal with technical debt: The result of creating a bigger problem, an elephant, by taking a shortcut to solve a problem in need of immediate resolution. A village can devour an elephant but you’ll probably never get a village full of resources to confront your elephant. You’ll need to eat an elephant one bite at a time.

Ok, so none of us are really eating elephants, are we? We are dealing with constraints. The theory of constraints is a management philosophy introduced by Eliyahu M. Goldratt in his book “The Goal”. The Phoenix Project (Gene Kim, Kevin Behr, and George Spafford) is based on The Goal but applied towards software engineering - it’s much more relatable. Either book can help us understand “units of work”, what blocks completion of units of work, and how to deal with blockers.

We can manage our units of work once we understand what they are and there’s no better tool for managing our workloads than: SCRUM The Art of Doing Twice the Work in Half the Time by Jeff Sutherland.

Keep calm and carry on

Sometimes it feels like we’re living in a world where our mistakes have the potential to trend on twitter. None of us want to miss a vulnerability on a single server that suggests to the world we’ve been sleeping at the wheel.

It’s naive to think you can solve everything. Failure is painful, inevitable, and one of life’s most valuable teaching moments. The power of failure can be seen in professional sports. Amatures are both inefficient in their actions and deterred by failure. Professionals were not deterred by failure, learned from the experience, and apply what they’ve learned towards the most efficient use of resources required to compete.

I’d like to think everyone would enjoy reading the “Art of Living” by Epictetus and the teachings of Epicurus. While the teachings of both are invaluable, they were written long ago, and may not be relatable. Ray Dalio’s Principles is probably the better choice for anyone who wants to understand why embracing failure is fundamental for making change happen.