The Security Engineer Handbook

You're on the losing team, the team that makes the company waste money. On the other side is the winning team, the one that makes the company money. Don't trump yourself, this is how it works unless your company is printing dough, or your company is rooted in security (perhaps the founder was a security engineer previously). No matter what, your existence will always be hard to argue for.

All of what you'll be doing will, directly or indirectly, create work for others. It will slow down roadmaps, add friction to people's daily lives, and require reprioritization for teams. Put yourself in their shoes. They already have a lot to figure out (like everyone really) and now some nincompoop is trying to tell them how to do their job and how they need to clean their room before they can go play in the park. It sucks really.

I'm going to contradict previous examples here, but if you're just starting you should not try to cover as much ground as possible. Instead, you should focus on one or two projects at most, and try to prove yourself there. Meanwhile, the company will have to suffer as you'll be ignoring a lot of glaring issues. But there's no way around that, you don't start on a complex project and try to give it a hug, instead you stab it in the heart.

You get it now, you need to lurk, you need to court the king, you need to appreciate the beauty of the gardens they helped shape. It'll take time, and energy, but it's all worth it. After many talks, they will agree that some of the stuff is not great, and you'll offer your help. It's a win-win at this point. Without this, you're on private property, and you're risking getting shot.

you need credits. See them as coins, literally, that you can gain slowly by playing the right cards, and that you can lose in one hand. Without credibility, collaboration is impossible, and so is the job of a security engineer. So play the game, accumulate these points as soon as possible, and don’t lose track of the end goal. If you find your ass sitting in-between two chairs, it might be time to ask yourself: do I want to double down on these? Is it worth losing that many credits?

If you're joining a large company with an established security team, you will get a chance to play the part of some specific type of security engineer. On the other hand, younger organizations tend to have smaller security teams that care less about specialization. If you're in the latter situation, you're bound to ride a very confusing roller coaster. In the weather of your emotion it'll be cloudy, sunny, rainy, and snowing. So wear some flip flops but carry a big coat. You'll have zero clue what the expectations for your role are, and you'll end up wearing many hats. You're going to love it.

In this chapter, I propose the following security engineer's feedback loop: threat model, prioritize, find a way in, and execute. Let me explain in this order: always start by looking at your system holistically. By creating (or re-visiting) a threat model, you make sure that you are not missing anything. Then, prioritize. Find the low hanging fruits from the attacker's point of view. Where are the holes, where are the single points of failure? Once you decided on what you want to work on, find a way in. If you have management support, this could be easy: this could be prioritized from the top, resources could be allocated to make sure the work is done, and you would just have to make sure that everything goes well. If you don't, it gets trickier, and this is where you must create relationships (if you don't have these already) and find ways to convince people. This is honestly the hardest part of your job, albeit the less technical. Finally, once you got all of that figured out, execute. Drive your plan to completion. Once you accomplish the task, go back to your threat model.