What does your job title mean?

View original thread
Todd's photo

Mine is Technical Lead - Software Security

I am the lead engineer of a product/application security team.

What this translates into is:

  • Helping craft goals for the team and checking in to make sure that we are making progress towards those goals

  • Making sure each team member is challenged, stimulated, and that their skillsets are being used to benefit the team/company

  • I am often the "spokesperson" for the team in meetings with upper management and other teams/departments. I've worked with people ranging from PR to marketing to sales to engineering to legal to IT on problems affecting application/product security. This is definitely something that I learned when I got into security engineering - communication skills are even more important than other types of engineering. A good example of how this may play out is say a customer service manager uses some third party software to interact with users, and that software has a security vulnerability but is hosted on our domain... It could impact our users even though it's not our software, so I have to work with this sales manager to get contacts at the third party company and work with their security team or engineers to see that the issue is fixed!

  • Managing our bug bounty program - imagine a GitHub Issues section where all of the submissions are security vulnerabilities from hackers/researchers. My team takes these, checks to see if they are true (validation), writes an exploit to prove the vulnerability exists, and then works with the engineering team to remediate the vulnerability in a patch.

  • Working with Product and Engineering teams to advance the security posture of the software and hardware products. Meaning, for example, if this year we are using TLS 1.0, next year we want to upgrade to TLS 1.2, etc... Being an advocate and pushing these types of things along. Developers are often focused on just getting the product working properly, whereas we're focused on getting it properly secured.

==========================================================

The above uses probably about 50% of my work time... THe other 50% of my work time is spent on technical tasks. I also spend a lot of my free time on technical tasks at home so I would still say that the majority of my overall time is spent on technical stuff, which I love too! So let's get to those:

  • I work with code most days of the week lots of different code. In one given day, I may be writing a C program, modifying someone else's python script to add some features, writing an exploit for a vulnerability in JavaScript for our web code, reverse engineering or writing some assembly language code, reverse engineering some C# code, and sometimes even more! In a single day some days!
  • I work on tasks such as reviewing application architecture to find security weak points (threat modeling), consulting with engineering managers and leads about weak areas of their application and seeing what types of attacks I can pull off, writing code obfuscation algorithms, suggesting specific ciphers for encryption, attacking applications from a "bad guy" perspective (we call this black box testing), reviewing source code (white box testing), and more.
  • Our team also provides training to software developers so for example, we may teach a 1 hour training course on how to prevent cross-site scripting, how to secure API keys and tokens, how a type conversion vulnerability can be used to exploit a system, and etc...
  • Our team has to work with 7 different platforms/domains: macOS, Windows, Linux, firmware, Android, web/cloud, and iOS. This is one of the most exciting, challenging, and fun parts of the job. Most of the development teams are focused on one main platform such as the iOS team or Android team. We have to be skilled in all platforms.

As you can see, the job involves a lot of different hats and it can be hectic at times, but very rewarding and fun as well. Members of this team trade having to deal with security emergencies and switch subjects frequently for having more research time when things are slower. This is a bit different from typical software development which is focused on getting a specific feature released or a specific product out.