My name is Joe Basirico, I help people build secure software. Learn more »


Building a Collaborative & Social Application Security Program

10/9/2017 - Posted by joe

It's no secret that more and more companies are jumping on the Bug Bounty Program band wagon, and for good reason, there is a lot of value to be had there. However, rolling out a Bug Bounty Program (BBP) before you have done your own due diligence can often cause more problems than it solves.

Bugcrowd, one of the largest bug bounty program service providers touts that within the first two weeks a typical company with a new BBP will see 5 critical vulnerabilities, 70 unique vulnerabilities and 200 total vulnerabilities. Those are impressive but potentially overwhelming stats. If you reverse the math a bit, that means that organizations need to:

  1. Triage 200 issues
  2. Throw out 130 false positives
  3. Rank, Reproduce, and Assign 70 issues
  4. Rank and address 5 critical issues and determine which need to get fixed first

I am not advocating for that it's better not to know about these vulnerabilities, or against Bug Bounty Programs. It is critical that you know the threat landscape of your organization and software, and BPP's are a valuable component of a mature program, but they should be rolled out to an organization of reasonable security maturity.

Bug Bounty Programs support software assessment tools and external security assessments. Tools are a great place to start. They find a lot of common vulnerabilities faster than humans but generate a lot of false positives and miss compound, business logic, and other vulnerabilities. Once you've fine-tuned your tools and have removed the "low hanging fruit" from your results, getting an external software assessment is a good next step. This external security assessment is expert driven and can go deeper than any tool. They'll find issues that elude tools and give you context on how to effectively remediate and train your developers and testers to minimize the number of issues introduced into code in the future.

After automated and 3rd party penetration testing processes have been rolled out and optimized, has been conducted, a bug bounty program is a great piece to add.

There are more steps to a mature Application Security program including organizing your external and internal messaging, doing security training, creating an internal security and bug discovery program and feeding all of your information back into your Secure Development Lifecycle program. I'll be diving into each of these in a future webcast, please tune in then.

Security Researchers will frequently uncover vulnerabilities in software even when they aren't looking for them and even when there is no Bug Bounty Program enticing them with a reward. When a researcher finds an issue they'll frequently still submit the issue to you without expectation of a reward if the submission process is easy to do.

It's important to understand how to treat Security Researchers with respect. Ultimately, they want roughly four things:

Respect The Security Researcher is a professional giving you free testing. Their motivations may vary, but they're not malicious. If they were, they wouldn't be telling you about the issue they found.

Rewards Yes, they'd like to be compensated for their time through company SWAG, money, an interview or some other reward.

Results They are telling you about the issue because they want to see the security issues resolved. Set expectations with the researcher and follow up on a secure line of communication.

Recognition Security Research can be a reputation game. I can remember Ian Beer's name because he shows up in nearly every iOS and MacOS update I see. Rolling out a Bug Bounty Hall of Fame is a great way to encourage researchers.

External Messaging is the single most important thing you can start with, though. Making sure researchers know how to contact you, and your preferred terms of engagement can go a long way for your credibility when talking with a Security Researcher. Don't make them jump through hoops to give you free testing. At the end of the day, if you make this easy, they'll make it worth your while.

I'll be diving into much more detail on creating a collaborative & social application security program at SOURCE Conference Seattle today. If you are unable to make the event, feel free to download my presentation slides here.

Link to this article.

Lazy Days in the Cloud

8/1/2017 - Posted by joe

The cloud brings scalability, reliability and security features that allow companies of all sizes to run their online business efficiently. These powerful capabilities often bring a false sense of a "security is already done" mentality and organizations are prone to take a more relaxed approach to their security efforts. Additionally, while many of the cloud platform features are "built-in", that doesn't mean they are optimized for your organization out of the box - they still be analyzed in the context of a larger security strategy and re-evaluated frequently.

The recent compromise of almost 200 million registered U.S. voters was accidentally exposed online due to an improperly configured database setting that resided in the cloud. Much has been written about this breach, so I won't rehash that. Instead, I want to focus on issues that I've seen with cloud deployment:

  • You must protect your data, no matter where it resides, cloud included
  • The cloud won't automatically apply your appropriate risk tolerance level, you must set it appropriately
  • You must take steps to ensure each service, endpoint, etc. has been properly configured
  • You must treat the applications you run in the cloud as if they were running in a hostile environment, taking steps to protect yourself
  • In this particular case S3 buckets and other services must be appropriately protected

The first lesson learned is that you still need to understand the underpinnings of the cloud infrastructure to take full advantage of its benefits. Had Upguard configured their AWS S3 bucket to not allow download or access privileges, this breach could have been avoided. This may sound oversimplified and in actually, it sadly is - but the point remains that misconfigurations, both obvious and obscure, happen frequently with cloud operations; thus, regular expert scrutiny is necessary.

This is also a perfect example of why regular attack simulations and red teaming are necessary - had Upguard conducted these, they would have most likely found the dra-dw amazon subdomain, realized it was an attack vector, and secured it in a proper manner.

Originally written for the Security Innovation Blog

Link to this article.

Delegate Then Do

7/11/2017 - Posted by joe

Being a manager is difficult. It's sometimes difficult to know what tasks you should do yourself and what you should give to your team. I've adopted the Delegate then do methodology for myself.

Delegate everything you can to anybody on your team who can accomplish the task. Do this by default. Give your team the benefit of the doubt, and give them difficult tasks that they'll have to rise to the occasion for. Make sure they're supported and set up for success, but don't hold back a tasks for somebody on your team because you're not sure. You must push to grow.

Do, anything that is left over is your ask.

Do not select for "fun." If anything, opt to give fun tasks to your team, they'll appreciate the fun tasks and be more successful.

Consider using this framework

  • Do what you must: What can only be accomplished by you? Train and develop your team to reduce this pool of tasks.
  • Do what is necessary: What unblocks the most number of people? Grow your team and help them communicate so you are not a bottleneck.
  • Do what is left: What isn't being accomplished by your team, because it is difficult, boring, or confusing? If you've delegated something, but it's not getting done because it's too difficult, boring, or confusing consider taking it back and doing slogging through it yourself.
Link to this article.

So you want to be a better programmer

6/14/2017 - Posted by joe

Artem Sapegin
I get asked sometimes how some people on my team can become a better programmer. I think it's useful to think in terms of different evolutions of the programmer. In the beginning there's a scripter or coder and at the highest level you have an architect. There is much, much more to go into here, but this is a rough framework to plot your skills over time.

Use this to fill in your current skills and to identify key areas of improvement.


Progression from Scripting to Developing

Move from "scripting" to "programming" to "developing"


  • Coders understand how to solve immediate problems in a sometimes brute force way. Question -> Google -> StackOverflow -> Copy -> Paste is a standard method of development and problem solving.
  • Lack algorithms or data structures understanding well enough to know when there may be an efficient solution to the problem
  • Develop primarily in a text editor
  • Write code -> compile -> fix compiler errors -> run -> fix runtime errors -> repeat
  • Struggles to estimate coding projects larger than one month


  • Understands their IDE can use it for debugging
  • Understands basic Algorithms and Data Structures
  • Breaks problems into reusable parts
  • Is comfortable with their programming language and the common libraries and frameworks
  • Googling is still common, compiler errors are less frequent, runtime errors are less frequent
  • Can break problems down to estimate more effectively


  • Fluent with their IDE and all features
  • Understand all features and components of the software (from DB, to unit tests, to OS, etc.)
  • Knows multiple languages and when to do different things in different areas (for example when it's best to let the database handle something vs. code)
  • Understands Advanced algorithms and data structures
  • Deeply understands language constructs, libraries and frameworks they're using. Understands The Law of Leaky Abstractions.
  • Understands performance tradeoffs
  • Can reliably create time estimates, and track progress toward them


  • Knows when to use different systems for best performance/security/logic
  • Sophisticated knowledge of data structures and algorithms including space and time complexity analysis

Books to read:

Link to this article.

Project Success

6/9/2017 - Posted by joe

This diagram is an approximation of how I think about iterating toward a goal to increase my likelihood for success. There are a few concepts that I've packed into this diagram, so I'll try to explain here. I've also recorded myself drawing this diagram roughly in order of operations on youtube. here.

Step 1: Set a Clear Goal

Defining a clear goal and understanding what "Success" looks like is the most important first step. A make the analogy that a goal might be to Summit a mountain. Every action is a step. Steps can take you in any direction. If you're not careful about which direction you're walking, you may not be making it closer to your goal, and in fact you may be moving farther away! Do not waste time with actions that don't take you closer to your goal.

I'm a fan of SMART Goals (https://www.projectsmart.co.uk/smart-goals.php), but having goals that are at least Specific, Measurable, and Realistic is super helpful. Being able to track your progress so you know when you're going in the right direction is important and will help keep you inspired to complete the goal.

Step 2: Try a lot of ideas!

You may feel like you want to dive right into solving your problem or that you know the best way to do so. Instead try a few different things, ask around and challenge your assumptions, do research and see what sticks and resonates for you.

Step 3: Iterate and start working

Split your work into small attainable chunks. After each chunk test if you're closer to your goal or further away. Make sure each piece of work you start work on is the most important thing you can do and that it moves you closer to your goal. Don't work on "fun" things just because they're fun. Work on important, foundational things that you will make the largest difference first.

Do not attempt action without Iteration

Get feedback, and check against the goal as frequently as possible. If you focus on action and don't look up to check against your goal you can find yourself very far away from your goal and have wasted a large amount of time going in the wrong direction

Do not overestimate Sunk Costs!

We sometimes think back on the work we've done and overestimate the value of it. In a bad scenario we will overestimate the value of the work we've already accomplished, and underestimate the work ahead of us. If something's not working, shelve it and try something new. Ask yourself the question "How would I accomplish this goal if I knew everything I know now?"

Consider going back to Step 2 then to Step 3 with your new idea!

Step 4: Iterate frequently and check against your goal

This is the same as Step 3, but with a new starting point

Good Enough

Once you've made good progress toward your goal start asking if you've achieved "Good enough" Perfect is rarely achievable. You'll naturally make the most progress toward your goal early in the project. Trying for "Perfect" is a great target, but time and other pressures may make it clear that your time and energy could be better spent elsewhere.

Celebrate Success

It is incredibly important to reflect and celebrate your success. We often get too caught up in what could have been done better or we quickly move to the next project. It's good to know what can be improved for next time, but if that's all you focus on you can become burnt out and cynical. Focus on what was great and how proud you are of your accomplishment.

Link to this article.

Don't Short Circuit a Lesson

6/3/2017 - Posted by joe

Don't short circuit a lesson because you think you know what the take away is going to be. Too often we try to map other's experiences or recommendations to our own and we miss out on new opportunities to grow or learn.

Next time you hear somebody describing something they just learned don't interrupt with by saying "oh, I know where you're going" or "I know something similar" instead do two things:

First, delight in the other person's excitement about the topic. Be empathetic to their story, their journey, and their discovery. Ask probing questions, be genuinely excited to hear what they're saying.

Second, understand you can learn from everybody. Not in some cheesy "everybody has a story to tell" sort of say, but a very real, concrete way. They learned this topic in a different way from you, they have come from a different place, walked a different path, and colored their discovery through their experience. Because of this they will be able to teach you something about any new topic.

Link to this article.

Scale Your Solution to the Problem

5/30/2017 - Posted by joe

It's important to Scale your solution to the problem at hand vs. trying to scale the problem to your solution.

By analogy a master photographer knows when to pull out her iPhone and take a quick snap, edit it in-app and upload it to Instagram and when it's appropriate to break out the $5k camera body and $5k lens, and wait for the perfect opportunity and use Photoshop to edit the photo to perfection. The amateur photographer doesn't know anything about photoshop and lacks the skill to wield the $10k camera even if they had one so their options are technically limited, they'll miss out on the ability to create truly beautiful photographs. The new professional photographer who just invested in their $10k camera and just went to their first photoshop conference will want to reach for those tools every time. They'll miss out on the joy and speed of quickly snapping a photo and sharing it with friends.

It's only after you've become comfortable with all the tools at your reach, and have let go of any perceived value that you can really focus on finding the best solution.

Link to this article.

Digital Currencies

5/24/2017 - Posted by joe

I recently got interested in Digital Currencies, such as Bitcoin and others and decided to start learning about what they were, why they're interesting, and how to invest.

There's a lot to understand about cryptocurrencies or digital currencies (DCs), and I'm just getting started learning about it. But if you want to learn more a good place to start is https://www.cryptocoinsnews.com which is just a place to learn about what's going on in the cryptocurrency world.

If you've never traded before there is a lot of good DCs specific trading information in this series: https://hacked.com/trading-101/

You should research DCs based on adoption, business, and technology then make a call based on whether you think they'll be successful in the future. Different DCs are trying to do different things. For example Bitcoin (BTC) was the first crypto currency and is the defacto standard to the point where most transactions start with BTC. So to get started buying bitcoin is a good start (and frankly a fine investment strategy. BTC has gone up 11% in just 24 hours, so if you put in $100 yesterday, you'd have $111 now, which is an insane return. Once you own BTC you can buy other coins, anything other that BTC is called an "altcoin." Take care though, historically DCs have lost significant value nearly over night BTC $1200 -> $200 and ETH from $30 -> $8.

Certainly do your own research, and none of these returns are guaranteed. Also, never invest more than you're willing to lose. There's a very real possibility that a coin could go to zero value and you could lose everything, of course that could happen in the stock market too.


  • https://www.cryptocompare.com - A good place to read up on DCs. Use their portfolio to track all of your DC in one place
  • https://www.coinbase.com - A good exchange for BTC, ETH, LTC
  • https://gatehub.net - A good exchange for Ripple, but difficult to use. Buy BTC from another exchange, and send it here through ShapeShift
  • https://shapeshift.io - Allows you to convert any asset to another with no account (just a fee)
  • https://www.gdax.com - The exchange behind coinbase, which gives you more information if you're into nerding out about the details and are a real trader.

DCs - each DC has a name and a symbol Bitcoin's symbol is BTC, but Ripple is XRP. There are also different version of coins with the same name but different symbols, so be careful to invest in the coin you think you're investing in.

Digital Currencies

Here are some popular coins:

  • Bitcoin (BTC): The first DC and the current standard. Good returns right now, that will likely continue into the next 6-12 months. I imagine BTC will stay around for a long time, and will stabilize to reduce volatility significantly. That said, there is a ton of internet drama surrounding BTC at the moment (including a potential Hard Fork, see below under warnings)
  • Etherium (ETH): This is the coin I'm most excited about. They took what BTC did and built on it a programming language which allows developers to build anything in the world on top of it. Without getting into the details, this allows ETH to be built into a lot of other areas, making it a financial framework for other systems.
  • Ripple (XRP): Currently the financial system uses a system called SWIFT, which was built on mailing and cashing physical checks. SWIFT is really slow, it's why transferring money from one account to another can take days. XRP wants to replace SWIFT. Right now XRP is the riskiest DC I invest in, but if they're successful in replacing SWIFT it could be really, really huge.
  • Litecoin (LTC): Litecoin is an interesting DC that could augment or replace Bitcoin in the very long term. I think it's interesting enough to watch.

There are a ton more DCs out there (seriously over 800 different DCs), but I recommend you stick to the top 20 to research (https://coinmarketcap.com/all/views/all/). Some other coins that might be interesting to research are: DASH, XMR, XLM, ZEC, and STRAT for different reasons.


Wallets are where you hold your DCs. You can have an online or offline wallet. Online wallets have been known to get hacked, so only using a wallet tied to an exchange while trading is a good idea. Once you've made your purchases online, then move your DC to an offline wallet for long term storage. You can generate a paper wallet, which includes all of the information you need to use your DC again, or you can buy an electronic hardware wallet. I recommend the Ledger Nano S, which includes some really great security features to keep things safe.

One of the benefits of Digital Currencies is that there is no central authority, but this also means that if you lose your wallet or mess up the generation and cannot recover your own money, it is not possible to recover it.


You buy DCs through an exchange, not all exchanges allow you to buy any type of DC. I use two: coinbase.com and gatehub.net. Coinbase is nice and is pretty easy to connect your bank account to. You can also buy DCs with a credit card. It's fine to do that, but there are added expenses if you use a credit card.

Depending on where you're located http://poloniex.com is a good exchange that supports many DCs. They're not available in Washington.

You can convert almost any DC to any other DC using shapeshift.io without an account. This is really nice if you're buying anything uncommon like XRP.


You do need to report any gains to the IRS, so keep good books on your purchases and sales. You must follow all currency trading laws for your state as well, so read up on those. All of this is very early, and seems to be run by a bunch of kids, so don't expect your exchange to track your tax implication for you.


You may hear about mining, which is how many of these coins are created. So if you don't have any money, but you do have a bunch of computer power you can "mine" for coins instead of buying them. Most calculators show that it's not worth the power you put into it.


There's a possibility that any of these coins could be "hard forked" which means that one coin could be turned into two incompatible coins. If your money is in an online wallet (like in an exchange) it's possible that the wallet could only support one of the currencies. If that happens you'll lose the other currency. You won't lose any current value, but you'll lose potential value of the unsupported currency. You can mitigate that by moving your currency into an offline or paper wallet. If you control your DCs you can know it's not lost.

Currently BTC is talking about a "hard fork" http://www.investopedia.com/terms/h/hard-fork.asp

Also, seriously, don't invest money you can't live without. Don't cash out your 401k, don't put up your rent money. Greed changes people, don't get too excited.

Link to this article.


7/27/2016 - Posted by joe

Sorry biweekly, you've just been ejected from my vocabulary. I hate to be esoteric in my language and use a word like fortnightly, but when your definition from Merriam Webster has two directly conflicting definitions I simply cannot use that word. Fortnightly it is!

From Grammar Girl:

Semi- always means "half." You can remember the meaning by remembering that semisweet chocolate is only half sweet, and semiannual sales happen twice a year.

Bi- can mean both "two" and "twice." Bifocals have two lenses and the bicentennial happens after two hundred years, but a biannual event happens twice a year.

A listener named Eric pointed out that these terms are relatively set in the mortgage industry. A bimonthly payment is paid two times a month, but a biweekly payment is made every two weeks-not two times a week as you might presume if you were trying to adhere to just one meaning for the prefix bi-. The Merriam-Webster website explains that the "ambiguity has been in existence for nearly a century and a half." How frustrating!

Reading that makes me feel like I'm crazy. As a coworker noted:

"biannual is twice per year, but can also be a synonym for biennial which is every other year" This is terrible.

Are we insane??

Link to this article.

Why You Should Have Trust Issues with Pokemon Go, and Every Other App on Your Phone

7/13/2016 - Posted by joe

Viral Game Highlights Calls Attention to Timeless Security Debate

I want to run into traffic, fall into a pond, catch Pokémon while my wife is in labor, and find a dead body; let's check out this Pokémon Go thing!

Pop quiz: Is this a valid login screen for Google Account services? This is the first screen I see when I click login with my Google Account from Pokémon Go. It's concerning because it offers no clear indication this is a valid page, no way for me to verify that I'm sending my credentials to Google, no SSL/TLS lock, and no security controls -- just a white page that looks pretty legit.

Adam Reeve wrote a good post about this already. He's not quite right about the access Pokémon Go requests, but the message that we should question the privileges we grant Pokemon Go, and every other application, is a good one to take to heart.

Pokémon Go requests Full Account Access when you sign in using your Google account on an iOS device (note: it looks like they've issued a  fix for the issue, but this would have been a good opportunity for them to catch this early with a 3rd Party Security Assessment). It's hard to discover what "can see and modify nearly all information in your Google Account" means from that page, but we can all agree it's more than we want Pokémon Go to have direct access to. As a security person, this is really scary.

It's not just Pokémon Go, though. It's every application you install on your device and use another account to log in to. The promise of only having to remember a single password is great, but it does put all of our proverbial eggs in one basket. In this case it's a matter of making sure this app just requests the fewest permissions it needs to operate. But in others you may log in using your Facebook, Microsoft, Twitter, or any of the 62 other providers that are easily available. If you sign into one of these services you must first verify that you are signing into an OAuth provider -- this protects your account credentials from being sent to the app developers; and second, you must check the requesting permissions of the application.

To make it even more complex, you should also verify that the permissions the app requests on your device itself don't overreach. It's not OK for my calculator app to know my location, or to be able to access my photos or camera.

My team's motto is "We have trust issues." We have shirts, mugs, and pint glasses with this on it, so I'll admit I'm paranoid, but I'm also not ready to hand over everything that I use Google to manage to a random app dev.

This calls into question a timeless debate in the industry about the balance between security and privacy and features and fun. It's fun to play Pokémon Go, it's fun to integrate everything with everything. Hell, connecting first and worrying about the consequences later is a fundamental driving force of how the internet was created. That doesn't mean that leaping before we look hasn't gotten us into a lot of trouble though.

I'm the VP of Services at Security Innovation, and part of my job is helping to make security decisions for our company. I help decide if we're going to allow a third party app or service to connect to our Google accounts.

Most of the time the answer to that question is no.

We live and work in a trust-based industry. One data breach or even the hint that we don't keep our customer's data perfectly secure and we'd deserve to be out of business.

We take this responsibility incredibly seriously.

Sometimes saying no because of security reasons means we can't have fun things. We use a self-hosted feature restricted version of Slack for collaboration. No third party integrations and no mobile apps. What it does have is a small attack surface and easy to review code, and it lives on an internal, encrypted, locked down server within our complete control.

We have to think not only about the trust between us and the third party, but the trust we have with their developers, contractors, and security assessments, audits and personnel. We need to know beyond a doubt they will always act in our best interest.

There are few companies I would trust with our customer's data; in fact the number of companies that I trust with unencrypted customer data is zero.

The biggest lesson we can all take away from this conversation is to think before we act. Think about the tradeoffs between features and fun and security and privacy. Is it reasonable that your flashlight app requests access to your photos? Is it right that the Flappy Bird knockoff needs your location information? Is it good that Pokémon Go needs full Google account access?

Link to this article.

⇐ Previous 1 2 3 4 5 Next ⇒