Skip to main content

Start-Up Security

After many years in Security @ Riot Games and eventually putting the "s' out there, I recently decided to jump out of my comfort circle for a new challenge and joined a start-up (yes, I left a comfortable, stable job in a pandemic, lunacy lol).

Now that I've been here almost 6 months, I wanted to share some findings because security at a start-up is significantly different. 

When you join a start-up, there's going to be so much that you can do and it will be incredibly easy to "boil the ocean", and try to fix everything. At best, this guarantees failure for the Security team, at worst, alienation from the engineering and product teams. There are some obvious quick wins that a Security team can make without slowing down iteration and innovation speed, while also reducing risk:

  • Auth 
    • Partner with Engineering/IT/CTO such that there's alignment on Security owning all things "auth(n|z)". 
      • As part of this ownership, you need to be prepared to respond quickly because any time someone doesn't have the access they need, you're now on the hook.
    • This will involve an initial audit of what tools are there.
    • Basic training on each tool. 
    • Audit who has access.
    • Alignment on who should have access and then removal of those who don't need it (be aware that this will be sensitive as many of the folk have been here when they knew everything about the company or they are the founders).
    • Implement SSO and MFA on "all the things".
    • Review on-boarding/off-boarding and ensure that it's a seamless process where HR owns the process and IT executes the technical changes.
    • What secrets do you have? How are they managed?
  • Scan
    • Set-up scanning of your external IP space with a lightweight Security IR process so that the vulnerabilities can be remediated, mitigated, or the risk accepted (remember explain the risks in business-impacting terms).
      • At this stage of the company, you're really only concerned about anything that's critical, damaging to the product or affecting either customer or company data.
    • If possible, tie this Security IR process into the company's Operations IR process, which:
      • Will show that Security is part of the org, and not that team in the corner
      • Gives visibility to the rest of the org on why Security do certain things
      • Will simplify things for engineers as they only have one IR process to understand.
  • Embed
    • If you still have time/cycles/resources, embed Security engineers into key company projects that are delivering value to the product. 
      • Ensure there is well-defined deadline based on a "Definition of Done", otherwise you risk the engineer being there forever and becoming a network/software/systems engineer as opposed to a "security" engineer.
      • Embedding for projects will enable knowledge transfer both ways:
        • knowledge of security best practices for the non-security folks.
          • e.g. why "ownership/attribution" is so important to do from the start (tagging in AWS is one example of something that will save you later).
        • improved understanding of the product and company priorities for the security peeps.
  • Data
    • Understand where you have your data (both company and customer) and what data you have
      • How is it stored?
      • How is it transferred?
      • What Data Privacy regulations do you need to follow or abide by?
      • Map the data (i.e. where is it)
      • Create and implement a lifecycle policy (if you don't have the data, you can't lose it as Haroon often says)
  • Roadmap
    • If you've done all that, then come up with a roadmap that aligns with what's actually important to the business, not what you think is important. So go talk with the business and product :)

If you feel there's something I have missed or there's something more important to focus on, please leave a comment.

Related Resources

If you want something more detailed, also by someone more knowledge, check out Ryan McGeehan's excellent set of resources for Starting up Security.

Note:  Moved from my other site - - originally posted on 2021-02-14.


Popular posts from this blog

Being a Support Engineer @ 10gen - Part 1

There's a mis-conception around the role of a "Support Engineer".  As a clue, it's not what Urban Dictionary   says   - A person whose job is to answer calls from customers of a small- to large-sized company...... They are teathered to a their desk all day via phone headset........ phone jockeys usually hate their jobs.......they are are paid well enough..........until they completely burn out, and hate everyone.   and doesn't always involve this - Image Source: As you can see  here , there's lots of open roles in  10gen  and more specifically with 10gen, in  Dublin . I thought I'd write this quick blog to explain what Support Engineers actually do and why I joined 10gen as a "Support Engineer". I could be wrong but didn't Google come up with term " Site Reliability Engineer " to do away with the stigma associated with being a

LinkedIn Emails

Receiving mails via LinkedIn is an interesting experience. For example, how many folk actually personalise "contact requests" - from what I see, less than 1%. I typically try to because I think it shows some thought has gone into the request and it's friendly, but then "manners" on the Internet is a very different thing to the real world, right ;-) Anyway, to the point of the blog post. In early November (2012), whilst I was preparing my Security Onion presentation for IrissCon  (why did I bother when my MBP died on-stage), I received a very interesting and personal email via LinkedIn. The email came from a "Senior International Belief Instigator" (let's call him the SIBI - to save me typing) at Riot Games and the email was literally awesome, it hit many of the key points that you'd hope for in a recruiter email but it also had a wonderful tone. In my ignorance, I knew of League of Legends but not Riot (yes, I am embarrassed by that). I r

Doing The GSE

So, as many folks know, I went to Orlando towards the end of March to attempt the GSE lab. Both before and afterwards, I received several questions about the GSE :) Therefore, instead of destroying my fingers and typing multiple individual respones, I figured I'd write a short blog on my experiences with the lab section, whilst my thoughts on the written section can be found here . Apologies, this post started off short. Firstly, let me say, that once I overcome the initial nerves (I was bricking it on the first morning), I had a great time. @Chris_Mohan and @asho_relaxo both told me that I'd have fun but I didn't believe them (in fairness, they're not trustworthy characters). Most folk enjoy the first day the most, but I loved the second morning, it was a blast, especially when you come back to that problem that you couldn't figure out and then you nail it :)