learn to make it in a security team, develop a risk-oriented mindset, and discover
secrets of the industry
The Security Engineer Handbook
A short, edgy, funny, bold, mini-guide
to being a security engineer.
written by Mark Wisde and Tom Park, FAANG
security engineers and security consultants.
last update: 2021/03/31
Infiltrate the world of security engineers
Level up your game as a security engineer
Learn the principles of the job
Succeed in your role.
Table of content:
1. The losing team
2. Threat modeling everything
3. Mind your dependencies
4. Identifying work
5. Risk management
6. Staying up to date
7. How to get a good start on any project
8. Forcing people to do things
9. How bugs happen
10. Dealing with white hats and black hats
11. Immersing yourself
12. Security reviews
13. What's in a security team?
14. The expectations of a security engineer
15. Making it as a security engineer
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
ground as possible. Instead, you should focus on one or two projects at most, and try to prove yourself
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
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
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
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
If you find your ass sitting in-between two chairs, it might be time to ask yourself: do I want to double
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
part of some specific type of security engineer. On the other hand, younger organizations tend to have
security teams that care less about specialization. If you're in the latter situation, you're bound to ride
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,
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,
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
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.