How to become a Security Engineer

I am regularly asked how to get into the security space. I love being asked this because it means these people want to get better at security which in term means we will make more secure products! This post is a summation of what I tell those interested folks and some of my other thoughts around thriving in the cybersecurity space. 

I believe that being a Security Engineer is an immersive life choice. By that I mean that the way you get great at Security Engineering is to surround yourself with cybersecurity. From the news articles you read, the feeds your scroll through, the water cooler conversations you have at work, your personal hobbies, to making secure a key aspect of each project you drive at work. As you do this, you will discover that you start to spot potential for abuse in many aspects of your life, from getting your covid-19 vaccines (Did the nurse really leave me alone with a the stack of blank vaccination cards?) to projects you simply hear about at work (They are putting too much trust in the client and likely not validating state mutations sufficiently server side). 

A key thing that everyone should know: Becoming a great security engineer does not require special college degrees or any formal security training, in fact one of the best security engineers I know never attended college. Security engineering is like any other skill you get good at it by practicing it. 

So for this post, I’m going to focus on ways you can to start practice and how to start to immerse yourselves into the cybersecurity world.

Blog/newsletters

Many security issues apply in different situations or reoccur in different contexts. So reading about issues or incidents occurring in other industries will help you spot risk in yours. Additionally, I like to keep track of situations that are no too dissimilar to a problem I am dealing with. It is very difficult to estimate the likelihood of a security incident occurring, so having some real world examples and an understanding of the frequency of the occurrence is a key component of how I make likelihood estimates.

• Krebs on Security - Does not cover all the news but instead provides in depth analysis on particular topics of interest. 
• Google’s Project Zero - Tends to provide easy to follow technical explanations for the amazing vulnerabilities that the Project Zero team finds
• Schneier on Security - Will have interesting happenings with a bit of Bruce’s own analysis put into the mix. I tend to really enjoy the way Bruce looks at the world, so I like to soak in Bruce’s analysis whenever I can.
• Daniel Miessler - Has a paid for weekly analysis newsletter. The newsletter includes a good selection of interesting security news. I filtering of all the news is definitely worth the cost to help get a more curated feed of the news that highlights the signal and reduces the noise. 
• Troy Hunt - A generally awesome person. Runs “Have I been pwned” and tends to have interesting takes on many security reality topics. 

Podcasts

• Darknet Diaries - A really well produced podcast with awesome stories. The podcast does a great job of not just telling the story and over indexing on the technical details but instead talks about the motivations of attackers and challenges attackers faced. Which is a prospective I feel like is overlooked.
• Risky Biz - A good summary of each weeks security news with a bit of analysis and linking events together. 

Books

I don’t tend to like books for an up to date analysis on any particular topic but instead like books for a wider bit of analysis. Such as psychology of humans, in depth stories, etc. Things that can be a bit more timeless. Books tend to be out of date with the latest in a science by their nature. So always keep that in mind when reading these books. 

• Applied Cryptography by Bruce Schneier - This was one of the first security focused books I read. So it has a special place in my heart. The crypto is mostly out of date at this point but Bruce didn’t present anything as absolutes so you can still read it to get a deeper understanding of the basics of using cryptography in systems.
• Building Secure and Reliable systems - I contributed to this book. It is a good read to understand how Security and Reliability work hand in hand. Lots of good practical examples.
• American Kingpin: The Epic Hunt for the Criminal Mastermind Behind the Silk Road - A good story on how the creator of the Silk Road was caught
• Social Engineering: The Science of Human Hacking - A great combination of stories, examples, and provides a deeper understanding to the techniques used in social engineering.

Courses 

Coursera in general has a lot good classes. Some that have served my team well:

• Cryptography - The class will give you a really good understanding of cryptography. As always, remember Never Crypto Alone!
• Secure Coding Practices - Talk about how your code can be written more safely and learn to spot risky patterns in code

Bring Security Discussions into your workplace

I have found that many people in the technology space love talking about security. It is a topic area that dominates the news and has a certain amount of excitement that doesn’t quite exist in many other places in software development. You can leverage this naturally occurring interest and use it to up level your own abilities and everyone around you. I’ve successfully done this by:

• Creating a mailing list or a chat that is dedicated to security topics. This should include both topics inside of your company and news topics.
• Start a weekly or bi-weekly "Security Hangout" meeting. Invite anyone who is interested in discussing security topics. I've found this meeting works best as a discussion around a particular topic rather than a standing "training" session. Try to encourage questions and open ended topics where everyone can share their thoughts. 

My story of how I got into Security

My personal journey for security started in high school. I wanted to create a distributed storage system across systems I didn’t trust. This lead me to read Bruce Schneier’s Applied Cryptography book. This book opened my eyes to the amazingly complex and deep puzzles that need to be untangled to make real world systems secure. In particular, there is a section on how to use cryptography to make a voting system secure. The considerations of trade offs between anonymity, integrity of votes being counted, and confidentiality of votes casted was extremely fascinating to me. This lead me to go to college with the intention of becoming a cryptographer. 

I had dreams of creating new unbreakable ciphers. Sadly after taking classes and doing further research I discovered that in a well designed system cryptography is typically not the weak link. In fact, it seemed to me that if people simply did the right thing security was sort of a “solved” problem. This turned me off of security and by the time I left college I still was interested in the topic but it wasn’t where I thought I would spend most of my career on.

My first job out of college was as a software engineer on the vendor integration team for Google Payments (GPay). About a year into this role, there was a new group being started Payments Security. Given my interest in security from college and the opportunity to be part of something new at a big place like Google I jumped at the chance. This was around 2013.

From there the Payments Security team (PaySec) grew along side the Google Payments organization. The team was initially primarily responsible for protecting all of the credit card, bank account, social security numbers, and any other sensitive data users entrusted to Google for money movement purposes. Google Payments was used for almost all money movement at Google from Adwords, Adsense, Drive, Cloud, Play, and the Google Pay product. So there was a lot of this sensitive data that needed to be kept safe. 

The scale of the amount of sensitive data that Google Payments needed to protect was enormous, just like everything at Google. I ended up leading the PaySec team from 2014 - 2020. During my time, we invented numerous technologies and techniques to keep this sensitive data safe. Many of those techniques are now common place in the industry: for example we had something we called edge tokenization where we could limit the number of places needing to ever have sensitive data in memory, this is now a common feature of well designed card payment systems such as Strips Vaulting. 

Ultimately the team grew from protecting just the sensitive data to many of the aspects that you would associate with a security team such as: Security design reviews, internal red team exercises, vulnerability remediation, and incident response plus creation of key security critical infrastructure and libraries. 

At the end of 2020, I left my role at Google on PaySec and joined Veritone. I am currently leading an effort to create a security focused product which is looking to use cognitive systems to improve authentication. I am also creating an Application Security team dedicated to AiWARE to ensure AiWARE remains a highly trusted place to do processing.

My teams are hiring! If anyone is interested in knowing more and joining me at Veritone to democratize access to AI powered security solutions please reach out! - chardman@veritone.com 

Public job postings:

• Security Engineer job listing — All positions are full time remote
• Software Engineers — Looking for Senior and Principal level engineers

How to Measure Exposure of Access to a System

 

Objective

Describe a metric that captures the level of exposure due to access to a system. The intended use is to measure how close an access management process is to achieving principle of least privilege. 

Definitions

• Access - An actor's ability to read or modify data in or through a system.

• Access Management - A process to ensure appropriate actors have access to systems. 

• System - A catchall term for things like: a database, tool, or APIs.  

• User Data - A catchall term for data an end user is storing in the system.

• Personally Identifiable Information (PII) - a subset of user data that is considered directly identifying the end user. Such as a name, address, phone number, email, etc. 

• Sensitive Personally Identifiable Information (SPII) - The subset of PII that is considered sensitive, typically defined by the regulatory environment in which the data is being processed. Typically examples in the United States include Credit Cards, Social Security Numbers, etc.

• Principle of least privilege - Actors have ability to access only data needed to achieve their business objective.

• End user - Refers to the person that is trusting their user data to the system. Many times this is referred to as the customer. 

Background

As systems gain user data, there is a generic need to ensure appropriate access is being granted. This is achieved through creation of an access management process. Appropriate access typically depends on the sensitivity of the data being stored in the system. For example SPII typically has more restrictive access than PII. 

A difficulty in building an Access Management program is deciding how to define success. As with many processes, metrics around efficiency as fairly common such as:

• Average time to provision an actor access to the system -- less is better

• Headcount required to manage the process -- less is better

• Number of moments someone needs access but doesn’t have it -- less is better

These are great metrics from the perspective of ensuring least impact on business proposes. However, none of them have an explicit goal ensuring the access management process achieves the principle of least privilege. In fact, focusing only on these metrics will lead to preemptively granting many actors access to the system. As that is the easiest way to drive all of those metrics to their ideal state.

Access Exposure Metric

I propose that we measure the access exposure as a proxy for how close we are to achieving principle of least privilege. I define access exposure as:

(Number of actors) X (Average Number of end users they have access to)

Number of actors - The count of actors with ability to access end users user data.

Average number of end users they have access to - The average count of end users the actors have access to. Note the exact granularity of the subset of the end users’ data they have access to can be set as needed when measuring a systems Access Exposure.

As an example: Assume we are trying to measure the access exposure to a database with 100 million rows, each row contains the end users name, mailing address, and shopping history.  To ensure only appropriate access, we have an access management process that verifies business need before granting access. Once verified actors are added to a group with read access. This group has 100 actors in it. So we would say this system has an access exposure of 10 billion (100 x 100 Million). 

Now that we have this ability to measure the access exposure we can see where our resources will be best spent -- Lets say that it is decided that access to the database needs to be restricted as much as possible. Typically the access management process would focus on spending more cycles vetting the 100 actors with access. Potentially putting more through training, having management chains confirm the business need etc. Assume these measures are able to reduce the number of actors down to 50. That would be a 50% reduction in the access metric now at 5 billion.

Eventually though, we will see diminishing returns on reducing access focused on the number of actors. Some number of actors simply need to access this data. However, note the metric has two terms and access management so far has focused on just one of those terms, the number of actors. Shifting the focus to the other terms through creating a dynamic access mechanism. Such as: if the actors are a group of support agents that only need access to the one customer that they are supporting. Imagine a chat support system that grants the connected agent access to the customer’s data only once connected. In such a dynamic access model we would have an access exposure of ~50 (50 actors x 1 average end user each actor has access to). This represents a >99.999% reduction in access exposure.