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 - securityleadership.ninja - originally posted on 2021-02-14.

Comments

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: http://half-bakedbaker.blogspot.ie/2009/11/cannoli-and-broken-computer.html 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

MongoDB Authori(s|z)ation

Introduction Having answered numerous questions on the new and old authori(s|z)ation within MongoDB, I thought I'd write a short blog post explaining how things work as there seems to be some confusion. What's New Prior to version 2.4 , there was a very basic sense of "Role Based Access Controls" (RBAC) within MongoDB as there were only two roles - read readWrite which is quite limited. For example, if the user has "readWrite", that user is essentially "root" and the user can add/remove users as well as inserting data into the database, i.e. there is no role segregation. Version 2.4 added in the following 3 core roles - userAdmin dbAdmin clusterAdmin with a notable extension such that there are now 4 roles that apply across all databases - readAnyDatabase readWriteAnyDatabase userAdminAnyDatabase dbAdminAnyDatabase This increased RBAC is a significant improvement from a security perspective in MongoDB. It is imp

Separate MongoDB Syslog by Facility

In my last post , I showed how you can set up MongoDB v2.2 to syslog its logs off to a remote syslog server. As my `tcpdump` snippets show, the syslog messages hit the syslog server tagged as "user.info", which means that they're assigned to the "user" facility with a severity level of "info". I've received a few questions regarding the possiblity of splitting out syslog messages by facility, however, as everything is currently sent to a "user.info" bucket, so-to-speak, this is not possibility. There is a current feature request for this capability and work will be done on this but if this is important for you, I'd strongly encourage you to vote for this feature. In the meantime, however, (whilst not ideal) you can still do some host filtering with rsyslog as outlined here .