My journey to security engineering
Full-time senior security engineer & part-time food connoisseur
What is security engineering?
Security engineering is about building dependable systems. At its core, it is very similar to reliability engineering. However, security engineering extends to securing systems that are considered susceptible to potential malicious actions — not just accidental or inadvertent events. Security engineering requires a lot of cross-disciplinary technical expertise and a strong, analytical understanding of economics.
Fundamentally, if I was to boil it down, security engineering is about recommending the right design and level of investment to protect systems. You have to figure out what needs protecting and how to do it.
I have worked in a variety of roles across the fields of cyber and information security for the last 5+ years. I have been exposed to various domains that make up the security industry including incident response and physical, application, and operational security.
I joined the League team almost 3 years ago as the first security engineering hire. This meant I got the chance to work on a lot of different initiatives with many talented Leaguers. I have had an enjoyable and formative — if not sometimes a little chaotic — ride as we scaled our product and engineering teams from 40 to 200 Leaguers. For the last couple of quarters, I have been focused on growing our identity capabilities at League.
How I got into security engineering
Coming out of school, I wasn’t really sure what I wanted to do with my shiny new electrical and computer engineering degree. Like a lot of people that don’t know what they want to do, I decided to take a job with a general consulting and engineering firm to get exposure to a variety of domains.
After I joined the company, I was assigned to a project that focused on modernizing how a local nuclear power operator treated and mitigated risk from potential cyber-attacks (think Stuxnet, etc.). This was my first exposure to the realm of security. I enjoyed the adversarial aspect of the work, which had me trying to figure out and prevent all the avenues an attacker could pursue to distribute a critical system. I am a board game lover and I think it fired similar neural paths. The other aspect that I enjoyed was diving into the details — which as an engineer gave me the warm and fuzzies — to develop a strong understanding of how the systems worked in order to validate a potential threat.
Knowing I enjoyed these aspects of the work and recognizing the huge need for security skills across pretty much every industry, I decided to pursue some additional night courses to build my knowledge through one of the local universities. I wanted to focus on the fundamentals instead of just pursuing specific certifications, as I figured it was better to have a strong foundation to build off versus a narrower, specific field of knowledge that might become less relevant as technology changed. I had also leveraged my current company’s training program to cover the majority of the cost of the courses.
After completing these courses — encryption systems, digital forensics, network security, offensive testing which were part of this certificate course — I was able to land a job on the newly formed security team at Geotab, a growing SaaS startup. I was by no means an expert, but they liked that I showed a strong desire to grow in the field, and I was a relatively cheap hire which made it worth the risk. For me, the job was perfect because it allowed me to develop my cloud, IT systems, and software development skills that I had identified as being relatively weak.
While working at Geotab, I pursued my Offensive Security Certified Professional (pentesting certification) and some development courses which allowed me to strengthen my security and software skills further — also bankrolled by my organization. After working at Geotab for a few years, I decided to look for a role that would let me focus more on my development skills, as the lack of knowledge in this area was preventing me from better interfacing with the more technical teams.
This is how I ended up at League! As you can see, my career path to becoming a security professional has not been linear. From chatting with a lot of other security practitioners, a non-traditional career path seems to be the norm in the security field. For example, I have met several security practitioners that went to school for music degrees before ending up in information security. There actually seems to be a pretty high correlation between security and musical talent for some reason. I, unfortunately, am not one of them — anyone who has been with me in a karaoke room can attest!
How does someone break into security engineering?
Based on my experience in the industry, I have found that it is pretty rare for someone to pursue a career in security directly. The industry suggests this will change as larger companies identify the need to hire and invest in training a solid pipeline for their organization. But personally, I have doubts this trend will change because becoming a security engineer isn’t often the first job in someone’s career. In my opinion, this has less to do with people not being familiar with security as a valid career path — something very rapidly changing — and more to do with the fact that security skills are often secondary skillsets.
I find currently there are three general paths or personas that the bulk of security professionals fall into:
- Transitioned from a traditional IT or system admin role
- Transitioned from a development or software engineering role
- Talented hobby enthusiast that transitioned into making it their day job
In order to excel in the security space, it really helps to already possess a solid technical background or foundation to build your security-specific knowledge upon. Logically, this makes sense as it is hard to find and patch a Docker image vulnerability or exploit a DOM-based XSS if you don’t know what a DOM or a Docker are! The persona that is an exception to this rule is the hobbyist. However, hobbyists generally tend to skew pretty heavily to the red side of the house (e.g. think a typical hacker/pentester who seeks to exploit public sites on the internet). I would argue these individuals have a capped growth potential till they have built up a stronger knowledge base from experience and exposure. Running tools and scripts can only get you so far.
Generally speaking, security skills aren’t a unique domain of knowledge but instead are better represented as a further specialization of existing knowledge bases in software development, information technology, and networking. High-performance organizations are now looking for specific security specializations of existing roles instead of looking for security generalists. Take a scroll through LinkedIn job postings and you will see how many security, infrastructure security, and product security roles are currently open. Few generic security postings are left up compared to even two to three years ago.
This shift in the industry is causing security-specific teams to become smaller and more focused on offensive capabilities, training and tooling to enable existing teams. Instead of large standalone teams, we see a model with more distributed and embedded security engineers working directly in cross-functional teams. The security engineers are still responsible for driving the organization’s approach to security in their domain, but the overall security risk is now no longer owned and managed by the central security team, but instead is managed by the cross-functional product team with guidance from the security team.
This is also leading to companies prioritizing domain knowledge over previous security experience when making hiring decisions. Organizations have realized it is far cheaper and more effective to teach security fundamentals to an experienced developer or DevOps practitioner looking to specialize than try to teach development skills to someone with a security operations background.
To summarize, I would encourage aspiring security professionals to look at holistically improving their technical skills instead of just concentrating on the specific security knowledge. I believe in the long term, it will be the combination of the technical domain knowledge plus security skills that allow for the greatest flexibility in career development and impact on your future organizations. I would also encourage existing developers and DevOps practitioners to think of security as a potential specialization that might help land a future senior or well-compensated position.
