Pushing Left, Like a Boss - Part 10: Special AppSec Activities and Situations

Special Situations

Not all application security programs are the same, and not all security needs are equal. As many of you know, I am leaving Microsoft this week, and I'm going to talk about them a bit in this article because they are probably the best example on the planet of special security requirements and situations.

Think about this: Not only does Microsoft make the most popular consumer operating system on the planet (Windows), they also make the second most popular cloud (Azure), the most popular programming IDE (Visual Studio Code), one of the most popular programming languages/frameworks (.Net), the most popular office suite (Microsoft Office), and so, so much more. It wasn't until I worked there that I realized just how many things depend on Microsoft. It's staggering. I tried to threat model the idea of Microsoft going out of business (I'm a blast at team meetings) and I think the world would not be able to recover, because their systems are used to support so many other systems on this planet that are critical. We would literally shut down.

What this means is that Microsoft has very special security needs. Their operating system, cloud and other products that we depend on must be secure. They must go far beyond the average company in their efforts to ensure this, and they do. I have seen this first-hand; I was lucky enough to work with the amazing human beings that create and maintain these systems for two years. I was repeatedly floored by just how incredible the people were who I was so privileged to work with.

But the average company is not Microsoft. Which means they don't need to take the same precautions. As a second example, let's take "Alice's Flowers".

Alice has a website for her floral shop that delivers flowers in her small town. It shows basic info, such where they are located, their phone number, and when they are open. It also has a link to her Shopify shop for online orders (meaning she does not need to secure that, Shopify does; Alice is smart to have outsourced the hard part). The rest of Alice's website, in the big scheme of things, is not very important. If her site goes down for a day or two, it would be inconvenient but it would not the end of the world.

Most companies fall somewhere between Microsoft and "Alice's Flowers" in regards to their risk. It has been my experience that many places, when I look at where they spend their security dollars, seem to be very confused as to where they sit on this scale. This is not my attempt to make fun or insult any company, I think it's a sign of our times that not all companies are receiving good (and unbiased) advice.

The AppSec activities listed below do not apply to all IT shops. I invite you, reader, to try to imagine where your workplace would be on this scale. Please remember your place on the scale as you read the rest of these examples, to help you decide if any of this activities may apply to your place of work.

Special AppSec Activities

Responsible Disclosure

Responsible Disclosure (also known as Coordinated Disclosure), is a process where someone finds a security problem in a product or site, reports it to a company, and the company 1) does not sue them 2) thanks them 3) sometimes offers a token of appreciation but generally does not offer money and/or 4) sometimes the reporter is publicly acknowledged by the company or their bug is reported formally as a CVE.

Last week I used a government website, I saw a bug, I figured out who to talk to (the Canadian Goverment doesn't have a disclosure process, of any kind), and I emailed it to them. They said thanks, I offered ideas on how to fix it, and they were great. This is one version of responsible disclosure. See how I was responsible?

Some places have a formal program, whereby security researchers (or normal users like me), can report issues to them in a secure manner (me sending details over twitter then email to the government employee was not very 'secure'). If the product they found the issue in is something well-known or used often, they may file a CVE (Common Vulnerability Exposure) so that other's are aware that version of that product is known to be insecure. But also for credit; having your name on a CVE is pretty cool.

Industry standard for fixing such things is 90 days, but not every company complies, and not every person who reports such an issue is so patient. When you hear that someone "dropped O Day", what they mean is they released the info about a vulnerability onto the internet, and there is no known patch for it (also known as a 'zero day'). This is often done in order to pressure a company to fix the issue. Because if one person found it, that means others might have found it (and they may be exploiting it in the wild, causing people problems, and that's no good).

Note: "dropping O day" is NOT a part of responsible disclosure.

Bug Bounties

Microsoft (lead by Katie Moussouris) basically invented Bug Bounties, out of a need to find every vulnerability. Since then several large tech companies have started their own programs including Shopify, Google, Netflix.

The invention of bug bounties spawned an entirely new industry; dedicated security researchers or "bug hunters", as well as large companies that sell these people's services on a pay-per-find basis.

The thing about working as part of a bounty program is you only get paid if you find something, if no one else has found it before, if your finding is in scope, and if your report actually makes sense. Submitting things that aren't in scope is a great way to get yourself banned (such as taking over accounts of employees at the company you are supposed to be finding bugs for, don't do that). What this means is that many, many bug hunters make little-to-no money, and a small few do quite well. I've heard people call this "a gig economy", which means no job security, benefits or anything to fall back on.

The economics for the researchers aside, this is an advanced AppSec activity. I've been asked many times "Should we do a bounty?" to which I have responded "How is your disclosure program going? Oh, you don't have one, okay. Ummm, how is your AppSec program going? Oh, you don't really have a formal program you just hire a pentester from time-to-time, okay. Hmmmm, do you have any security-savvy developers that could fix the bugs the bounty finds? No, okay, ummmmm. So you already know that you should DEFINITELY NOT DO A BOUNTY, right? Okay, yeah, thanks."

I realize that doing a bounty program is "hot" right now, and that the companies that sell bounty programs are happy to tell you that it's good value for your money to start no matter where you are at in your AppSec program. NO. That's just not true. I usually sugar-coat things in my blog, but for this I can't. If you don't already have an AppSec program and you do a bounty you are setting your money on fire. If you want to hear from an expert on the topic though, you should watch Katie Moussouris explain it much more gracefully than I, here: Bug Bounty Botox Versus Natural Beauty.

Capture TheFlag

Capture the Flag contests, also known as CTFs, are not a bunch of security people running around in a field with flags; it's a contest made up of security puzzles. Sometimes it is vulnerable systems you need to exploit, sometimes it's intentional puzzles for you to solve. When you 'solve' one of the challenges you get a 'flag', which means points. The person or team at the end with the most points wins.

Why do security professionals sit around playing games and solving puzzles? Because this is a great way to learn. And it's SO FUN! Also: if you find a vulnerability and it's something you have done before in your code you will never, ever make that mistake again. Trust me on that one.
Inviting your devs to a CTF can be a great team building exercise and it can teach them many of the lessons you wish they knew!

On this note, WoSEC is hosting an international women-only beginner CFT on November 2nd. I invite all lady-folk, women and NB peeps to consider attending. It should be a ton of fun! Special thanks to Chlo Messdaghi for organizing it!

Snowflakes

There are many more special situations that demand interesting and exciting AppSec activities, such as chaos engineering, red teaming, and so much more. I could go on and on, and I will; that's why this is a blog and not a book.;-D

Thank you

Thank you for reading my first blog series; this is the end. When I started my blog I honestly wasn't sure anyone would read it, but I wanted to share all of the things I had learned so I went for it. Thank you for coming on this journey with me, I hope you follow me on many more.

If you aren't sure where to start or want to go back in time, check out the Table of Contents for this series at the top of each article.