10 Things Your First Security Hire Shouldn’t Do

Apr 21, 24
10 Things Your First Security Hire Shouldn’t Do

First security hire is a weird job.

It means your boss is no longer a security expert. But unlike a Head of Security or CISO role, the person filling it can easily be mid-career. It also means you’re incepting a security program, probably from scratch.

If you find yourself in this role, there are many good guides - I’ve already compiled the best. Here’s my attempt to write a counterfactual. There are no absolutes, but I hope this is helpful if you’re managing a solo security engineer, or trying to navigate the role yourself.

There is a unifying theme: leverage. All your efforts as the first hire in the door should be Ratchets or Levers.

  1. Don’t run a public bug bounty

    A public bug bounty is snacking. You’ll get ambient noise, even if you spend the money on managed triage. Without care and feeding, it’s unlikely you’ll get significant meaningful findings - unless security is a mess in which case an unstructured firehose of problems is unlikely to be the most useful or scalable form of discovery.

    Instead:

    • Post a disclosure policy, so responsible researchers can get in touch if they stumble on something major. You can use Disclose.io to create your VDP, or use a managed platform.
    • Set up a private program once you’ve culled low-hanging fruit via in-house SAST, DAST, and Infrastructure Configuration scans. Start with a small pool of high-reputation researchers, and make sure to communicate well and set aside time to fix any issues found. Read Collin Greene.

  2. Don’t run internal red team assessments or pentests

    These are preening. Generally, if you’re the first hire it’s easy to shake the tree hard and come up with cool bugs. However, the return on investment is unclear, and it’s generally too narrow a pursuit. Additionally, it sets the wrong tone to spend too much of your time punching other teams in the face. It is guaranteed you will have obvious hardening work you can do to instead kill bug classes.

    Instead:

    • Encourage vulnerability reporting from anyone at the company, they’re close to the issues anyway
    • Within the first year, spend the 10-20k to get a professional penetration test to cover your bases, catch anything you missed, and baseline for future progress

  3. Don’t run bespoke trainings

    Most security training sucks. This is okay - you’ll get higher impact from your personal interactions anyway. Developing custom training for more than a couple hours is a time suck. Running it regularly doesn’t benefit from scale.

    Instead:

  4. Don’t set up hamster wheels of toil

    There are a lot of initatives that share a characteristic - they feel productive, because they generate a Big Dashboard of Problems. This includes:

    • Kitchen-sink SAST/DAST/Infrastructure Configuration scans
    • Kitchen-sink detections

    Instead: focus on high risk, high signal rules in your most critical platforms. Incrementally add rules and tune, to avoid getting overwhelmed with noise. Be very willing to disable rules that are low-signal

    • Manual compliance

    Instead: automate evidence collection, or just buy a platform - soc2.fyi

    • Vendor questionnaire purgatory: it’s easy to get caught up in custom processes, and fail to improve your own

    Instead: make sure to at least build up an answer database. Fill out a CSA STAR self-assessment or similar. Set up a public Trust or Security page. Consider outsourcing.

  5. Don’t gatekeep security from the folks who were already doing the work

    You shouldn’t join a company as the first security person where no one cared about security. Maybe it was the CTO, or a DevOps engineer, or someone in IT - but there is always someone are who has been doing security work. Fail to recognize that effort and fail to ride those tailwinds at your own peril.

    Instead:

    • Listen and learn about what’s already been done
    • Beware Chesterton’s fence
    • Start building Security Champions

  6. Don’t miss the mark on communicating upwards and outwards

    It’s easy to silo yourself as a solo security engineer. Especially if you’re reporting to someone very busy and very senior, who is hiring you to take security off their plate. Don’t forget that a huge part of the role is communication.

    Instead:

    • Ask for a lot
    • Broadcast often: interesting bugs, security wins, planned process changes

  7. Don’t fail to prepare for hiring

    You’ll eventually want a second (or even third!) security engineer. It’s easy to get so busy, fall behind, and then struggle to catch up on scaling people.

    Instead:

    • Make sure you build alignment early with leadership, and especially finance, about timing and gearing ratios.
    • Think about how you’ll hire folks with skills you lack, or more senior to yourself.
    • Think about how you’ll make space to staff junior members of the team.

  8. Don’t fight every fire

    When you’re growing quickly, there will always be fires—inventory shortfalls, servers crashing, customers whose calls aren’t answered. You won’t always know which fire to stamp out first. And if you try to put out every fire at once, you’ll only burn yourself out. That’s why entrepreneurs have to learn to let fires burn—and sometimes even very large fires.
    Reid Hoffman, Masters of Scale

    In addition to burnout, security needs to beware a reputation of catastrophizing or “crying wolf”.

    Instead:

    • Default to letting fires burn. Ask: why now? what will change if we wait a quarter, a year?
    • Prioritize based on risk
    • Do basic registration of issues, so you can check back if they get worse, make them visible upwards and outwards, and pick them up later

  9. Don’t ignore security domains

    As a solo security engineer, you likely have a “home” domain. Ideally, this is aligned to your companies core risks, often application or product security. But for most startups, rolling out webauthn is going to reduce more risk than any appsec initiative. Make sure you’re prioritizing broadly and accordingly.

    Instead:

    • Do a little CorpSec - probably SSO and webauthn
    • Do a little InfraSec - maybe set up a secure baseline for the cloud environment, or get staging split out from production
    • Do a little AppSec - set up high signal SAST, implement some secure defaults

  10. Don’t start big engineering projects

    This has the potential to chase ghosts, and is hard to get over the line. As a solo engineer, you’re going to lack the necessary luxury of focus. You’re going to miss lower-hanging fruit, and do a disservice on time-to-value. You’re increasing the risks of your lottery factor.

    Instead:

    • If there is a differentiated risk that is critical to address and can best be tackled with a big engineering project: get enough staffing or get enough partnership to do it right.