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

Averaging A Group's Salary

I recently wanted to find the average starting salary for some recent college graduates that had also worked at Surface Systems and Instruments. As most people know it is rude to ask what someone's salary is and can cause awkward situations. So I came up with the following algorithm to get a group of people's average salary without disclosing any information to anyone else, except for the average of course.

Person 1 comes up with a random number k. k should be much larger than person 1's salary. Person 1 should compute S1 + k, where S1 is person ones salary. Person 1 then tells person 2 and only person 2, S1 + k.

Person 2 takes S1 + k and adds S2 to it. Then gives person 3 S1 + k + S2.

Person 3 takes S1 + K + S2 and adds S3. Then gives it to person the next person.

On this goes till n people, where n is everyone we want the average salary of,  has added their salary to the running sum. The last person gives S1 + k + S2 + ... + Sn to person 1.

Person 1 subtracts k from S1 + k + S2 + ... + Sn and is left with S1 + S2 + ... + Sn. To compute the average, Person 1 simply takes (S1 + S2 + ... + Sn)/n and can then share it with everyone.

In order to make this secure, n must be grader than 2 and no person can give their sum to anyone else besides the next person in the line. Unfortunately, this does suffer from an attack. If person a and person a+2 want to know person a+1's salary, by subtracting the sum person a gave person a+1  from sum person a+1 gave person a+2.

So this is a fun method. My goal was to make it simple and practical to use. If you can find any other attacks please let me know.

Usable Security

There has been a big push over the last few years to develop what has been coined as "usable security". Things like drawing patterns on Android devices instead of typing in a 4 digit pin or identifying particular things in an image instead of typing a password have been developed. The biggest problem with these usable security mechanisms is that they often take longer to use than the alternatives.

Imagine if you had to take your mouse and click at 10 particular spots in an image every time you wanted to unlock your screen at work. Doing this would take several more seconds at every sign on and would add up quickly. Often for systems that are used often keying in a password is still the fastest method.

Well Microsoft has developed a new solution. Instead of having password requirements that are visible to the user, like minimum length, they want to let users use anything as a password. Even simple passwords like "love" would be accepted. However there is a catch, only a small number of users will be allowed to use a particular password.

Complex password requirements were introduced to combat spraying and braying attacks. A spray and bray attack is when an attacker tries to use one particular password on a large number of accounts. This way bypassing lock out procedures. This solution by Microsoft will fix this by only allowing a small number of accounts to be compromised and thus reduce the benefits of the spray and pray attack while keeping passwords simple and easy to remember.

Examining Security Of Open Source and Closed Source

I recently just completed a research paper, with two of my colleagues: Clint Caywood and Matt Strayhall, on the security of Open Source Software. The paper went very in depth and I feel helped fill a void of the lack of credible information in this hotly debated topic. Here is the abstract:

In this paper, we examine the security of open source software versus that of closed source software. Facets examined include a brief history of the growing need for security in software, a comparison of the different philosophies driving the development of security in open and closed source software, arguments for obscurity in closed source versus the “many eyeballs” theory in open source, and the pros and cons involved with both development processes. We also look at the two approaches in practice, focusing on competing software like Linux and Windows, OpenOffice.org and Microsoft Office, and Apache and Windows IIS Server. Finally, we examine the impacts on society from software security, as well as who is responsible for maintaining secure software.

You can find more, including download links, if you visit my Research section of this website.

A Lapse in Policy

We have all be on the phone talking to someone that we may not know all to well, when at the end of the conversation they say "sounds good, go ahead and shoot me an email about this.". If you are like me you think, "why did we just talked about it". However that email actually is used for quite a few things: The most obvious one is that it will be used as a reminder, people often use there inbox as a to-do list. The next thing that email will be used for is a record of your request, most companies have very strict policies on change management where all changes must have a request associated with it. The final thing that email will be used for is authentication, with the raise of knowledge about social engineering over the phone email as authentication has come into play.

The lapse in policy comes from the last two things the email serves. It comes from the assumption that only the person who controls the email account can send an email from that email address.  Unfortunately email, like most Internet protocols was invented before security was taken into account. Its actually considered quite trivial to send an email appearing to come form any name and email address that you please.

Fortunately there is a simple fix to this problem: Simply reply to all request emails with a confirmation request. So if person A requests person B to preform some task on the companies file server. Before preforming the task, person B should send a confirmation email to A asking for A to confirm the task.  Then the request and the confirmation should be stored for record keeping and we can be sure to the point of the security of the email account that the request was authentic.

Insights in Risk Assessments

Bruce Schneier has a great insight on risk. In a recent post to his blog he wrote:

People have a natural intuition about risk, and in many ways it's very good. It fails at times due to a variety of cognitive biases, but for normal risks that people regularly encounter, it works surprisingly well: often better than we give it credit for.

This struck me as I listened to yet another conference presenter complaining about security awareness training. He was talking about the difficulty of getting employees at his company to actually follow his security policies: encrypting data on memory sticks, not sharing passwords, not logging in from untrusted wireless networks. "We have to make people understand the risks," he said.

It seems to me that his co-workers understand the risks better than he does. They know what the real risks are at work, and that they all revolve around not getting the job done. Those risks are real and tangible, and employees feel them all the time. The risks of not following security procedures are much less real. Maybe the employee will get caught, but probably not. And even if he does get caught, the penalties aren't serious.

Bruce hits risk assessments right on the head in this post. The risk inherent in what is considered risky Internet  behaviour is not as bad as many make it out to be. People often surf the web in untrustworthy wireless networks and store data on none encrypted memory sticks and nothing bad ever seems to happen because of it. At least on the personal level. We may read news articles once a week that describe how some sensitive data was lost on a stolen laptop or some other similar story. The thing to take from them is that they are in the news, if it happened to everyone it wouldn't be news worthy. Bruce goes on to say:

"Fire someone who breaks security procedure, quickly and publicly," I suggested to the presenter. "That'll increase security awareness faster than any of your posters or lectures or newsletters." If the risks are real, people will get it.

This is exactly correct. People need a real risk to be aware of the riskiness of their behaviour. However the network administrators need to take into account the actual risk, likelihood, and cost of each policy. You can't stop business in the name of security.