Your first 90 days as a founding security engineer
authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Active Directory, and Auth0. Authentik Security is a public benefit company building on top of the open source project.
Being the first security hire is a lot of responsibility. It’s rare to find a security engineer among the first 10 employees at a startup, so when you join, it’s likely that you are joining a larger company. In this situation, you’re inheriting some established security practices (or lack thereof) and have more people to corral than in a small, tight-knit company. (This article even suggests onboarding the first, full-time security hire between 30-100 employees.) And the stakes are high—the SolarWinds story is an extreme, but cautionary tale that companies can be held accountable, even when they are victims of a hack.
It’s not all gloomy though! There is lots to enjoy about being a founding security engineer.
You get the chance to wear many hats: one day you’re investigating infrastructure alerts, another day you’re pen testing, or on another you might be urgently researching whether you’re vulnerable to a new breach. You might also get to pick your security stack! You’re constantly building your skills and learning new things.
The biggest challenge: How do you prove your value?
When you start any new job, you want to show how you’re contributing right away—especially if you’re the first and only member of your department. When I joined Authentik Security as the first security engineer, I was fortunate that my manager, our CTO and founder Jens, has a security mindset. Success can be hard to define, though, when you’re the only team member with extensive security experience, and you might not have continued direction or guidance from leadership. If you’re reporting to a CTO or CEO, chances are they will be relying on you to drive the bus, even if they have a security mindset and training; it’s why they hired you and they have other areas to build up. Particularly in small startups, where the focus is often on “whatever will help us land customers”, and not on internal security (a cost center).
So, where do you start?
Get the lay of the land
You can’t make a plan if you don’t know what you’re working with, and sometimes what you first learn about the company’s security posture and processes isn’t reflective of what’s actually happening. Again, I was lucky when joining the team, because security has always been treated as a priority here, but I know from past experience that’s not always the case. Be prepared that what was in the job description may not actually be what you end up doing, so be ready to dive in, assess the current state of security, and start defining what your plans are and how your strengths will be utilized.
Understanding the current lay of the land is fundamental to defining a successful plan going forward.
The next biggest risk category after employee risks (which we’ll get to in a moment), is configurations. That’s why you’ll want to first figure out the following topics
What is the security stack, and has it been implemented properly?
In security, it’s not uncommon to grab a tool to solve a problem, and then find that it actually works for maybe 25-50% of what it’s intended for. You want to make sure you’re getting full value, especially if you’re paying for it.
A misconfigured tool might say you’re not at risk, but this can be a false sense of security. You see this with vulnerability scanning: there are so many tools out there, but if they’re not configured correctly you won’t get all the findings.
Is monitoring of the environment set up consistently (if at all)?
We’ve discussed this topic on this blog before, but it’s just so much more important and effective to have eyes into your environment than chasing down vulnerabilities. Did someone open up a server to the public with SSH, or accidentally commit a password somewhere? Why is this AWS account monitored, but not that one? When I joined Authentik Security, Jens had already set up log ingestion from our authentik instance (yes, dog-fooding), so I built on that by setting up SIEM and threat intelligence capabilities.
Start with what you’re good at
Now that you have an idea of what you’re working with and have applied your basic knowledge and skills, it’s wise to start with an area of security that you feel confident in. Security is so broad; it’s likely that you won’t be well-versed in everything (from blue team, to red team, compliance, etc.). You will probably have to learn some of that stuff on the job, but don’t spend the first 60 of your 90 days trying to learn how to pen test something or configure a new ultra-complex tool.
It’s more effective to start with the things you do feel comfortable with and grow your knowledge in the other areas as you go (just make sure you validate your plan with your manager).
Phishing
As we mentioned before, you’re far more likely to fall victim to a breach than a targeted hack (that’s why you won’t find chasing vulnerabilities in this list of priorities). Some phishing awareness material may seem obvious, but phishing tactics evolve quickly and there are always going to be people on the team who can fall victim to phishing (see the recent Cisco Duo attack). You’ll want to set up training around phishing and possibly have ongoing campaigns, and make sure your email provider is configured to “Mark as phishing”.
Access
Access management only gets harder the longer you ignore it. At a lot of companies, you get admin access to everything by default, which just gets riskier as you scale the size of the company. Now, instead of one or two people at risk of leaking a password (or choosing a weak or obvious password) or getting breached, you have 5, 10, 20, 100 people you have to be concerned about. If you can start scoping that down, you limit the blast radius.
Going down the rabbit hole of access can be daunting. There will come a point where you have to limit any one person’s access to only the things they need to do their job (i.e. principle of least privilege). If you do that suddenly, it’s going to cause friction.
A better approach is to see what a team member needs access to in their day-to-day and give them those permissions, plus one level higher. The change won’t be as noticeable on their end, and you have limited the blast radius in the event of an attack.
Offboarding and onboarding
Without a formal offboarding process, it’s common for access to be forgotten when someone leaves a company. They might retain access long after they’ve left, leaving the door open for them to sell those credentials, or do other harm if they left on bad terms.
It makes your IT department’s lives a lot easier if, for example, you use an access management tool like authentik to grant permissions to people (as we do at Authentik Security!). Then, if they leave, it just takes the click of a button to revoke access.
Implementing SSO is high ROI for a founding security engineer: it automates onboarding and offboarding, improves workflows, and just makes things easier for teammates.
It’s not a panacea though; there are likely tools in your company’s stack that don’t support SSO, or maybe you don’t have the paid plan that includes it.
At Authentik Security, we of course use authentik; we have one group defined that is associated with a set of administrative-level permissions, but Notion (which we use for internal documentation and planning) doesn’t support that. SSO gets you into Notion, but once a team member logs in we have to manage authorization of different groups differently. But, at least if someone leaves or their access is compromised, we can disable them in authentik and now they can’t get into Notion at all.
Start a runbook
One of the toughest things about being a security-team-of-one is there’s a lot of weight on your shoulders, and if you’re out sick or on vacation, there’s no one obvious to fall back on. That’s why it’s worth getting into the habit of documenting as you go. As you triage, set things up, and respond to alerts, take notes (literally!); what is the process you’re following? What should someone do in your place?
If you build documentation into your process it’s much more likely to happen than setting aside time specifically, and now your teammates will have something to refer to if you’re not available.
Build your relationships
When you start a new role, you have a finite amount of social or political capital at your disposal. So, you need to be strategic about how you deploy it (see below). You can also build up your credit with your teammates by taking the time to connect with them and understand how your initiatives are going to impact their workflow. They will have more time for you if you make an effort to meet them halfway.
For example, if I have a new security tool I want to implement and I need a new server, instead of just asking our infrastructure engineer to do it for me, I know enough about Infrastructure as Code that I can go in and start the changes for him. He just has to make tweaks and corrections instead of starting from scratch. Making the effort to relieve some of that burden helps to build goodwill.
Don’t be afraid to dig into the code
It’s unusual for security engineers to have a true understanding of the code we’re charged with protecting. Not a lot of developers cross over into security, and if they do they usually end up pen testing on the red team side because they understand more about it.
Being able to hold your own at least somewhat helps to build trust and goodwill, and can make you a better security engineer. Say for example, a Veracode scan turns up a finding and the developer says, “This is fixed this way, let’s ignore this.” By having some coding background, I can say, “No, if I’m reading your code correctly, you’re not sanitizing that input before it falls in, and that’s why Veracode is complaining.”
Challenging developers can put people’s backs up, so you want to approach this collaboratively and prompt them with questions to lead to the right conclusion. Knowing enough to ask the right questions goes a long way.
Pick the hill you want to die on
It’s a tough line to walk between partnering with other teams and putting your foot down when something has to change. It never turns out well to just drop the hammer one day (like suddenly revoking most people’s admin access, or giving your devs 5,000 vulnerability results to address—at least pick a critical subset). You want to gradually bring up the security level in a way that’s not disruptive.
So, pick the hill you want to die on. A lot of security involves giving new work to others: “Hey, we need to fix this server. Hey, we need to fix this code. We need to fix this access.” You want to minimize your asks where possible so people don’t just avoid you! Make suggestions, go slowly, take small steps, and solicit feedback. People are going to feel far more inclined to work with you on compromises if you show a willingness to collaborate.
In security, it’s natural to feel like every measure is really important, but if you’re practicing defense in depth, and spreading your efforts across as much of your attack surface as possible, you don’t have to cover every base 100%. Focus your efforts on activities that have an impact without generating a ton of work for others.
Let us know your thoughts in the comments, via email to hello@goauthentik.io, on Discord or GitHub.