I’ve written before about the paradox of hiring managers not being able to find entry-level cybersecurity candidates, while many people with decent training or even degrees in the field cannot get hired.
As it turns out, it’s not really that hard to explain.
The Military takes you from zero to hero.
In extremely large and long-term-focused organizations—like the Military—this gap is understood, so they spend time building extensive, standardized programs that can take anyone off the street and turn them into professionals over time.
Most startups are just happy to be alive, and aren’t anywhere close to thinking about how to systematically grow security talent.
Some large companies do actually grow talent, but not enough.
In most companies—and especially startups—they don’t have programs that spin people up from nothing because they simply don’t have the time. They’re dealing with their own pressing problems, like trying to convince partners that they aren’t a complete dumpster fire (which they often are).
The result is that they need to hire people that already know how to do things.
The security engineer skills that managers need right now
This is a perfect example of when a hack is needed.
So here’s the secret that nobody’s talking about. It’s absolutely possible to hack your way into an entry-level position in security.
The trick is being able to convince the hiring manager—and their team—that you can do the tasks that they need most. Luckily, many of those tasks are somewhat standardized, and this article will take you through them.
If you’re on any security team at a junior to mid-level, these are exactly the types of things you’re likely to spend your first few years working on.
So many of these are a combination of soft and hard skills.
- Product Selection:
- Scenario: Your manager tells you that the CISO read about endpoint protection on the wall of an airport, so now we need to do that immediately, and it’s your job to find the best one.
- Learn About The Space: Figure out who the main players are in the space, so you can understand what the capabilities are.
- Determine Your Requirements: Untangle exactly what we need from an endpoint solution.
- Create a Scorecard: Create a system for rating all selected products based on your criteria, with as little bias as possible.
- Meet With Vendors: Get with vendors and learn about their products to see who you can eliminate quickly and who will be in your testing group.
- Eliminate All But Your Top N Products: Using what you learn combined with your criteria, get your candidates down to 2-5 vendors.
- Product Testing: Do the best testing you can on these products, in a fair way that represents how your company will use them.
- Write Your Analysis: Create an artifact describing the selection and testing process, and which product was selected.
- Present Your Findings: Depending on the company and the size of the project, you might have to present your artifact/analysis to various managers to move the project forward and get support.
More junior members of the team often do only one of these tasks.
This is really a full-stack kind of job because you have to make big decisions, organize your thoughts, come up with fair criteria, make sure you don’t miss things in your testing, and then make a compelling argument in your analysis and recommendation.
This is a great place for bug bounty folks to slide into a team’s DMs.
- Ad-hoc Security Assessment:
- Scenario: Your team has just learned that some website—which we just found out about—is about to go live tomorrow morning at 9AM. And it has not had a security review. Your manager calls you and tells you to take a look real quick to see if we need to spend political capital to have the site launch delayed.
- Perform a Quick Web Security Assessment: Fire up Burp and/or any other commercial tools you might have and start manually testing the site for vulnerabilities. While you run some automated scanners using a set of test credentials, you also run through your manual testing methodology to look for P1 – P3 vulnerabilities.
- Write Your Analysis: You found out that the site allows enumeration of usernames and passwords, and once logged in there’s an IDOR vulnerability that allows one customer to pivot to see other customers’ data. So you have to write this up in a 1-3 page report, with screenshots. And you have to do it in a clear-headed, matter-of-fact way that doesn’t aim to embarrass the team that built it.
- Present Your Findings: After midnight there’s a call with the product team who built the app, and your manager asks you to explain why these things are bad, and why we can’t just launch the site and fix these later.
There are many types of security assessment, but the most common are tiny little risk assessments where you ask very simple questions like: Where’s the data, how does it travel, how is it stored, who has access to it, how is logging handled, is the system connected all the way through to incident response, etc.
You’ll basically be doing these assessments constantly, often multiple times per week—with each taking just a few minutes. Before long you’ll barely even know you’re doing it.
This one is one of the hardest to prepare for, since it’s strongly based on experience.
- Preparing for and Handling an Audit:
- Scenario: It’s Friday afternoon, and you just got told that Sarah, who normally handles all technical audit work, is out of the office next week unexpectedly for a death in the family. The auditors are onsite Monday morning at 8AM, and you need to 1) make sure all of our technical controls are in place, 2) be completely honest with them, and 3) they better not find anything—we’re depending on you.
- Learn the Audit Standard: Very quickly spin up on what a SOC2 audit is.
- Find Out Our Current State: Now that you know what they’ll be looking for (that took a bunch of Friday night and Saturday morning), now you have to figure out where they’ll be looking at our stuff, and what state it’s in.
- Answer Questions About Our Controls: Be able to respond sensibly about how we are (or aren’t) meeting a particular standard that’s being asked about. The amount of wiggle room here is remarkably (and sadly) very large, and the more technical and smart you are the better shape you’ll be in. Honesty is rewarded by good auditors, and they often give time to make quick fixes before the audit is completed.
- Create a List of Follow-ups: Take a list of findings from the auditor and go do all the relationship-straining leg-work to go get those things fixed throughout the entire company.
- Follow-up with the Auditor: Come back to the auditor and show them (days or weeks later) that all the outstanding items have been addressed.
Dealing with auditors is a great example of the breadth of skills required to be a security engineer. When you’re handling an auditor you need to be extremely versed in many types of security, the controls that are involved, the reasons they’re asking their questions, and what exactly can be done to come to an arrangement regarding remediation.
Tech skills can really help here, but the best teacher is experience on this one as well.
- Integrating a New Security Product:
- Scenario: Your company just implemented a new NextGen CloudChainAI Firewall (Barracuda’s latest product), and your manager tells you to get it integrated with your (tee hee hee) centralized logging solution.
- Talk to Your Logging People: Just kidding, that person is you also. But pretend it isn’t. Find out how they take in logs, over what protocol, how that delivery will be monitored, how to get an alert if logging stops, etc.
- Determine What Events Should Be Alerts: Knowing what you know about the device, and the types of functions it performs, determine what types of issues we care about knowing immediately, that that must be monitored 24/7.
- Find out How the Appliance Does Logging: Get credentials and go into the new device’s administrative interface, figure out where logging happens, and send the logs there. Configure or arrange those integrations with the appropriate folks in Incident Response.
The steps required to do this integration could be as simple as pointing logs, all the way to integrating with SOAR systems, talking to multiple teams for their touchpoints, etc.
This is where previous developers can prove their worth as junior team members.
- Create a New Tool:
- Scenario: Your group just got access to a new domain blacklist, and it has a pretty well-documented API. But now that makes 5 total blacklists your team is subscribed to. Your team lead asks you to create a single internal API that queries all of them, with extremely fast performance.
- Create a New API: Create a new API using whatever language is used internally to aggregate all the existing APIs, search against them, and provide a YES/NO answer in less than 200 ms.
- Create Documentation and Examples: Create documentation that includes how to call your new service in Go and in Python.
Note: Programming isn’t strictly required for all security positions, but for situations like we see above, it’s highly beneficial and preferred by managers.
I prefer the term meta-skills, because they are ever-present and make other skills better.
I’ve mentioned them multiple times already in the technical sections above, but being able to communicate is invaluable. There are many technical people who can implement or break their butts off, but they’re not desired on teams because they can’t interact with others.
You want to have both.
Here are the main soft skills you want to make sure you have.
- Excellent Writing: I believe strong writing is the Uber-skill because clear writing requires clear thinking. The focus should be on being concise, and doing so with as little bias as possible.
- Fast Learning: The best thing you can possibly say to a manager who asks you to do something you don’t know how to do yet is, “I can’t do that yet, but I should be able to within a day or two.” Those are true skills. Nobody can do everything. The question is how quickly you can jump into something new and become proficient.
- Mentorship: In addition to being a great communicator and being quick to learn new skills, you’re also likely to be considered a better member of the team if you’re someone who lifts others and shares your knowledge. Don’t be the person who tries to make others depend on you so you’ll be more needed. It works in the short-term, but people eventually see it as selfishness and insecurity. Help others, and the Karma will return to you.
This summary has solidified for me why the skills gap exists. These tasks are not easy—even for someone who’s been in the field for 1-3 years. And that’s precisely why hiring managers keep passing up on lots of applicants.
You’re either able to do these kinds of tasks on your first Monday, or the team is likely to see you as a detractor rather than an asset. Because now they not only don’t have someone who can do the work, but you’re taking cycles away from someone else on the team to spin you up.
The key is to try to get as good at these things as possible before your interview.
- Know the various product spaces, and the main players in those spaces. And be able to talk about how you might run a comparison between them.
- Know how to quickly assess any type of system, whether it’s some financial system you’ve not yet seen the tech for, or a new security product that someone is deploying, or a website that’s about to go live. Know how to come up with a smart assessment methodology very quickly, and how to present findings in a concise and compelling way.
- Know how to handle auditors—from being able to talk the tech with them, talk about the controls, and negotiate and follow through on negotiated remediations.
- Get your programming skills to the point that you can hack together a quick client in Go or Python for accessing APIs, pulling data from a website, interacting with products, processing lots of text, and producing basic output. Few things (other than writing) will help you more in your career.
- Sharpen your writing. Crisp and clear.
- Be adaptable. Be the one who can take almost any task and learn it and execute.
- Be the one with positive energy that is willing to help others.
The one thing to focus on
This is why bounty people and programmers with active Githubs have an advantage.
Your primary focus needs to be convincing the hiring manager that you can be useful on day one. That’s it.
And learning to be good at the skills above, along with the ability to convey those through your LinkedIn, your projects, and your interview, is what’s going to make you stand out.
TL;DR: If you can convince the hiring manager that you can take projects within a week of starting, you’ve got a really high chance of getting an offer.
- There are other entry-level security positions, such as SOC analysts, that many companies definitely need. But those positions tend to be at larger organizations that have the infrastructure to take junior people and grow them, whereas this article is focused on what you can do to become a versatile member of a general security team in a smaller company where people are asked to do lots of things.
- Michael Coates made the excellent point that a key reason for the skills gap is that not enough companies are doing what the Military is doing in growing talent. But in the startup world that’s completely understandable. Most startups are lucky to even have security people at all in a world where the entire company is still an experiment.
- Top image from Crowdstrike.