No, I’ve Been Nervous Lots of Times!
It’s time to jump in and review each ladder to give folks some additional insight. Let’s start with:
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 the house’.
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 room. 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 security. Folks have to be able to work in them.
External Influence – Folks might disagree on this one, but I think it is critical that you get out there as a security professional. It helps grow the community and your brand (which will help you get your next gig!)
Vendor Engagement – At some point, you are going to buy something (or be a vendor. Yikes). You 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 security folks. Pay it forward.
Hiring – Let’s face it, you will have teammates leave at some point and hiring the best fit to 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 haven’t gone through 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 to take yourself and your team.
Communications – Got to talk to folks, and a lot of them will not be security people. Sorry.
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 blog 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 code.
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.
PS_Boston_Ladders.MD – Not much to talk about here.
PS_NICE_Mappings.MD – 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!)
Intrusion Detecting and Monitoring – This is what a SOC does. Pay attention to some of the later skills (starting at IDM.5), this are where things are headed, and you should be learning about these if you aren’t already.
Incident Response – Again, what a SOC does. I am a big fan of using the NIMS incident response process. Take a look if you haven’t done so.
Intelligence – As I mentioned above, this will eventually be its own ladder. I got hooked on the benefits when working as the CSO of a large hosting provider. Incorporating intelligence into my detection/response processes has saved my behind more times than I can count.
Forensics – It will be its ladder eventually, but is a critical skill to know (Also, the new ladder will likely expand on the E-Discovery aspects as well).
SOC_Boston_Ladders.MD – Not much here to talk about.
SOC_NICE_Mappings.MD – Not much here to talk about.
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 mentioned together and do your best. For orgs that are larger, you may want to split these out, or keep it as is – your choice.
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 scanning and fixing.
IS_Boston_Ladder.MD – You will see a lot of similarity to the SOC ladders. This is purposeful, so that teams that need to merge can be consistent with pay ranges, titles, etc.
IS_NICE_Mapping.MD – nothing too odd here.
Well, this brings part 2 to a close. Please look for our part 3 - Harry, I’ve Reached the Top,
next week. Again, we are going to end with a question – Can you guess what early 80’s movie this week’s blog post title refers to? Drop your answer in the blog stream!