No, I’ve Been Nervous Lots of Times!
Welcome to part 1 of our 3-part blog series around our recently open-sourced security career
If you missed it, here's the link to our Git repo:
General Knowledge Ladder
This purpose of this track is to outline the soft skills that are required for each level. It is
meant to be used in
conjunction with the skill ladder of choice so employees can drive the skills in the ‘other side of
There are 3 files in this ladder:
These are the skills for all employees, regardless if they are technical or management.
- Organizational Knowledge – Gone are the days of the tech
guys working in the back
Security folks need to know the
business they operate in and contribute to its success.
- Teamwork/Collaboration – Teams are the new norm, and I
mean teams beyond
be able to work in
- External Influence – Folks might disagree on this one,
but I think it is critical
out there as a security
professional. It helps grow the community and your brand (which will help you get your
- Vendor Engagement – At some point, you are going to buy
something (or be a
have to know how to
interact with these folks.
- Teaching – On my soapbox, I think this is the most
important thing we can do as
Pay it forward.
- Hiring – Let’s face it, you will have teammates leave at
some point and hiring
replaced them is going to
be critical for you and your team.
- Mergers & Acquisitions – Again, this is the world we live
in today. If you
this yet on one side or
the other (acquired or acquirer), you will at some point. Better to be prepared for it.
- Scope – As you move up, you are expected to take on
bigger things. Enough said.
- Strategy – Again as you move up, you are expected to have
a grand vision on where
yourself and your team.
- Communications – Got to talk to folks, and a lot of them
will not be security
These skills are for all employees responsible for leading/managing other employees.
- Managing Teams – Most of these are what you will learn as
you progress through
the management training programs.
- Managerial Finance – Why did we call this out? To be
honest, my teams operated
the best in an org when I had a full
grasp of the company’s financials and I had a great working relationship with my finance
business partner. It was
important enough to warrant a call-out. Find an accounting friend.
Pretty straight forward. Look to my description in the first ladders post for more information.
Product Security Ladder
This ladder is near and dear, as I’m now running my own product security company.
A couple of things to start with on this one. This ladder is meant for orgs with small
Product Security teams (which is
most of them). The skill list may look daunting, but these folks can get hired (I have hired
4 teams at this point) so
do not be discouraged by the list. Secondly, I personally don’t think there is an entry
level product security person.
All of the PS folks I have hired have come to the team with a background in QA, Eng, or
RelEng. This means you have to
do one of these jobs before this one. Trying to teach someone product security and
engineering at the same time is a
recipe for disaster and will lead to frustrated PS folks and stakeholders.
- SDL– Bread and butter. Got to know this one.
- Additional Product Security Practices – You might ask.
“Why are these here?”. Two answers: #1 you will run into these
during your work ,and #2 in small orgs you will likely own these. [Sideline story: I
once ran a PS team that shipped an
agent. Product Management found out they needed an export license to ship it because the
US government said that
cryptography was a dual-use munition (look it up). The conversation then went – Well the
PS team knows the most about
crypto because they do reviews of it as part of architectural assessments. So, voila! –
PS now owns export control, and
off to Washington, DC my team went to learn about it quickly so we could ship. You will
need to know these.
- Vulnerability Response – If you haven’t had a security
researcher report a vulnerability, you will at some point. Plus,
you may get some senior executive to want to run your whole program as one big bug
bounty (I ran away from a potential
gig that was advocating for this).
- Threat Modeling – I am a big fan as it goes a long way to
finding those fundamental flaws in your design.
- Security Features – You are the expert, and the teams
will look to you for guidance on these.
- Secure Coding – Again, a bit controversial, but I feel
every PS person needs to know how to code. If you are expected to
do critical feature code review (say on your crypto implementation), you actually need
to know how to read and interpret
- Security Testing – It is what most folks start with
(nothing like a tool to solve every problem) so you need to know
this inside and out.
- Security Training – You are going to needs friends
outside PS (and a force multiplier to do work) so knowing how to
train folks is a key skill.
Not much to talk about here.
Not much to talk about here.
Security Operations. This a big one. Again, it is a meant for smaller teams that can’t afford
specialists, so it
includes some skills that will likely get their own ladders in the future (namely threat
intelligence and forensics).
Also, I introduce the concept of converged SOC (GSOC). In at least two of my past orgs, we merged
the InfoSec and
physical security teams into one. As a result, the SOC responded to not just InfoSec events, but
physical events as well
(physical security will be covered in the next blog post). These physical skill IDs will be
represented with a “G”.
Disregard them if you are not running a GSOC (but I will say the merged GSOC was actually awesome
from a security
perspective. If you get the chance – do it!)
Infrastructure Security Ladder
This is an interesting one for several reasons. The role is generalist, meaning that it could be
split to more than a
few tracks (ex. Security Architect, Vuln Responder, etc.). Also, it tends to be the catch-all track
for orgs that don’t
or can’t have specialization due to resource constraints. I have had at least two teams where this
role included what is
listed, as well as all the SOC ladders and part of the Product Security ladder. It seems like a lot
of skills to have,
but you do your best with the resources you have. So, if you have a small team – merge the ladders I
and do your best. For orgs that are larger, you may want to split these out, or keep it as is – your
The above description says it all.
- Security Architecture – This is what would be seen as the ‘traditional’ security
architecture role in an org. To be
honest, I struggled with having an analyst role for this skill track. Fresh out school
won’t likely have the requisite
tech skills but in most of the cases I have experienced, this entry position has been a
transfer in from the systems/ops
team. (I have had great luck hiring desktop support people into this entry level role.
Give folks a chance!)
- Vulnerability Response – Again, could be its own track. It is all about the
You will see a lot of similarity to the SOC ladders. This is
so that teams that need
to merge can be consistent with pay ranges, titles, etc.
Nothing too odd here.
Well, let’s bring this to close. Please look for Career Ladders
Part 3 – Harry, I’ve Reached the Top, next week. Again, we end with a question – Can you
guess which early 80’s movie this week’s blog post title
Drop your answer in
the blog stream!
- Marc French