How should we define a bug bounty program?

Recently, a researcher discovered an RCE vulnerability on Instagram’s website.  The researcher used this RCE to gain access to the system, pivoted, and extracted data including password hashes, AWS keys and other non-customer data.  The researcher thought he was perfectly within his rights according to Facebook’s bug bounty program guidelines.  Facebook wasn’t too happy with this researcher’s tactics and there is now a war of words between Facebook’s CISO and the researcher.  The security community, as usual, has picked sides and I’m going to guess we are going to hear about this for a few weeks until the community gets bored and turns to something else.  This incident provides an opportunity to further define what a bug bounty program should look like.

Bug bounty programs have exploded in popularity in the last year.  Organizations are already being scanned and poked and prodded by good and bad guys alike so why not pay them for finding something interesting?  There’s a great cost-benefit for running one of these programs.  Pen tests can run anywhere from $5000 on the very low end to $20,000 and up.  After a traditional time-boxed pen test you might have a few XSS findings and some other less interesting findings.  Was that really worth $20,000?  Bug bounties, on the other hand, pay per bug.  Those few XSS findings that cost you $20,000 from a traditional pen test might cost you less than $1,000 through a bug bounty program.  The bean counters in the organizations love this!  But it’s been my experience that bug bounty programs produce some really clever exploits that don’t usually get found in a time-boxed pen test. 

How should a bug bounty program be defined?  That really depends on the risk appetite of the organization.  How hard does the organization want to get hit and how quickly can they respond?  With a bug bounty program you’re putting up a billboard saying come at me (not like the bad guys weren’t coming at you before).  But bug bounty programs in their infancy attract a lot of attention and this creates a lot of noise for your incident response team.  These programs should be nothing more than a vulnerability assessment and the program should be structured that way.  The line should be clearly defined that as soon as a bug is found it is reported and nothing more is done.  There is too much liability allowing an unknown researcher to rummage around your network dumping password hashes and cracking them.  Most pen test vendors provide some sort of liability clause in their contract.  Researchers don’t have that luxury and the penalties could be severe.  That’s why it’s best for the researcher to stop once when they’ve successfully exploited a vulnerability.  Snooping around the network and exfiltrating data doesn’t demonstrate a vulnerability.  The vulnerability in this case was the RCE.  

I’m a big fan of bug bounty programs.  I’ve seen the value they provide to an organization.  There will always be an incident or two like this one that makes executives cringe and rethink continuing the program.  I trust that there are a lot of very good, ethical researchers who will test applications with the organization’s best interest in mind knowing there could be a very good payday as a result.  Let’s not ruin this opportunity.  I would much rather pay out $250 for a XSS finding in a bug bounty program than $20,000 for a XSS finding from a pen test.

Why is there no Security 101?

The front page of Carnegie Mellon's School of Computer Science proudly boasts the university's Tartan Rescue Team finished third at the DARPA Robotics Challenge by submitting a robot called CHIMP that was built to help in disaster situations.  The University of Texas at Austin's Computer Science program page brags about one of their robots, UT Austin Villa, winning RoboCup 2015.  Georgia Tech's Computer Science page promotes a summer internship program called "Data Science for Social Good."  I am jealous of today's computer science students.  They are getting to explore so much more than I ever explored going through my computer science program.  I would like to ask the Carnegie Mellon students how they plan to secure their robot when it gets connected to the Internet of Things.  I'm sure that these students were taught about security implications as they were designing and building the robot, right?  Maybe the advisors for UT's Austin Villa team taught them about how to secure their robot, right?  Surely Georgia Tech's advisors advised the students in the summer internship program about data integrity and how to protect the data they were processing, right?  I graduated way back in 2004 with a computer science degree so I have been wondering how much computer science curriculum has changed since then.  Are schools teaching security as part of their core curriculum?  Let's take a look.

I decided to limit the scope of this blog to the top 10 computer science programs as identified by US News.  Here are the top 10 schools according to US News.

1.    Carnegie Mellon University
2.    Massachusetts Institute of Technology
3.    Stanford University
4.    University of California - Berkeley
5.    University of Illinois - Urbana-Champaign
6.    Cornell University
7.    University of Washington
8.    Princeton University
9.    Georgia Institute of Technology
10.    University of Texas - Austin

These schools are arguably the best in the world and are producing the brightest programmers who are doing amazing things.  They can build robots that respond during disasters but can they write secure code?  Based solely off the course catalogs, the answer is probably not.  Many of the schools offer a selection of security courses but none are required for a student to receive a degree.  A lot of schools offer graduate degrees with a focus on security so the opportunities are there.  But most students are just wanting to finish their undergrad program and get out and start making money.  Graduate school is an afterthought.  Carnegie Mellon, the top school, only offers one class on security to undergrads.  MIT doesn't offer any classes on security to it's undergrads.  Berkeley offersa few security courses but they are mostly high level.  What is needed is a course on secure coding which I haven not seen anywhere.

Schools are under a lot of pressure to graduate their students in four years due to mounting pressure from the government and other higher education critics who are wary of rising tuition costs.  Requiring an extra class or two that focuses on security will add a semester or two to a degree which could be costly.  The security community is amazing in that there are so many conferences and training opportunities at little to no cost.  Heck, conferences even serve beer.  Can you imagine how many college students would show up to a security conference if they knew there was free beer?  As a nice side effect we would be teaching these kids security or at least making them security-aware with no additional tuition fees.

Computer science programs are accredited by ABET and must adhere to ABET's criteria.  What does ABET say about security?  Nothing.  Without this guidance from ABET I don't believe schools will add security to the mandatory courses students must take.  ABET leans on an organization called CSAB to develop the required curriculum that computer science programs must meet to be accredited by ABET.  CSAB is made up of IEEE-CS and ACM.  Ok, no more acronyms.  I believe working with IEEE and ACM to promote security is the only way to get security to be added to the curriculum.  I envision OWASP would be best positioned to get involved in this process from a security perspective.

There are some brillaint minds developing amazing applications across all industries.  I would argue quality developers are writing secure code without knowing it.  Secure code is really nothing but good, functional code.  Security vulnerabilities are just bugs from another mother.  One of these kids is going to build a medical device that is one day going to save my life.  I want that little snot rag to at least be thinking about security when he's building that device.  When and where will tomorrow's developers learn how to write secure code?  It's 2015.  We are on Web 2.0 with 3.0 probably right around the corner.  Where is the Security 1.0 revolution?

Don't Roll Your Own Crypto

Security professionals are fond of telling developers "Don't roll your own crypto" and for good reason.  Implementing crypto is tough!  If you don't believe me then I dare you to look at the OpenSSL code.  Go ahead, I'll wait.  Are you scared yet?  This isn't going to be one of those "Security is hard" posts, I swear.  But implementing security is hard!  It's not just crypto.  Implementing session management can sneak up and bite developers.  There are a lot of intricacies that developers just don't think about.  Developers don't have the mindset of an attacker.  They are busy implementing business requirements so their company can make money off an application.  Developers might have the best of intentions when they are trying to code securely but some times it just isn't enough.  Looking for a script tag passed in from a web application isn't sufficient to defend against sophisticated XSS attacks.

The OWASP Top Ten is a must read for anyone with even a passive interest in security.  Injection vulnerabilities such as SQL injection are the biggest menace according to OWASP.  Application security professionals such as myself bemoan the fact that SQL injection is still a major issue in 2015.  We try to pound it into developers heads to use query parameterization to protect against SQL inject.  That's all a developer has to do to protect their code from SQL injection.  Simple, right?  Not really.  Developers don't have time, or maybe the interest, to keep up with secure coding techniques.  Security professionals, on the other hand, are expected to stay up to date on secure coding techniques.  It is incumbent on us to take our knowledge and work side by side with the developers.  In a perfect world application security professionals would pair program with the developers but this isn't a perfect world and we have a lot of other things to keep us busy.

"Give them some training and they'll know how to code securely."  Excuse me while I try to stop laughing.  Yes, training will help developers to code securely.  Unfortunately most developers don't get more than a couple hours of annual training.  They can't possibly learn how to defend against the OWASP Top Ten in that little bit of time, not to mention there are so many more vulnerabilities lingering outside the top ten that are just as dangerous.  Furthermore, as new developers come into the organization they will have to be trained so there's a constant need for training.

Ok, I'm beginning to sound negative about application security.  I'll try to be more positive.  Let the developers do what they do best and do what they were hired to do.  And that's to build killer apps.  Separate the business logic from the security components.  Instead of instructing the developers to write their own session management code suggest they use one of the many proven and actively maintained session management frameworks available.  Just as developers have their own niche so do application security pros.  Authentication and authorization functions are extremely complex and that's why there are a number of products available that easily integrate with a home-grown application.  Application security pros in organizations should have the capability to get their hands dirty and write a little code to satisfy some security requirements.  Organizations need to take advantage of this unique knowledge.  Organizations don't necessarily need to buy security products if they have the right personnel to build it.  But the security requirements need to be weighed against the skillset in the company.  If the skillset in the company doesn't exist then it's better to acquire a COTS product.

The security industry is overflowing with security products.  There's SAST, DAST, IAST, WAF and the latest trend is RASP.  They all have a role in the secure SDLC.  RASP stands for Real Time Application Security Protection and can protect against various attacks such as XSS, CSRF, SQLi, etc.  RASP is the most interesting because it becomes a part of your application if integrated properly.  There seems to be a lot of opinions on RASP.  Some argue if developers were coding securely that RASP wouldn't be needed.  That is true.  Unfortunately there are lots of variables that contribute to the lack of secure coding.  Some view RASP as a band-aid and to help secure legacy apps that are still in production but management isn't willig to allocate the proper resources to maintain it.  I argue if an app is in production then an organization has a duty to allocate the proper resources to maintain it but that's another topic for another time.  I don't necessarily view RASP as a band-aid.  I view RASP as any other 3rd party library or framework that developers use to help build their apps.  RASP allows the developers to focus on what they know and leave the details of security to other people who have the time to spend studying sophisticated attack vectors and adapting these technologies to protect against the attack vectors.

Implementing security is hard and it's not for the faint of heart.  Security is an art.  It takes a special, and some would say slightly deranged, mind to be good at security.  The security community is big and still growing.  There are a number of professionals who have dedicated their lives to making applications as secure as they can possibly be.  Create an environment where security professionals can work side by side with developers to implement proper security.  If this means bringing in 3rd party libraries or frameworks to achieve this goal then so be it.  Hackers are looking for any advantage they can get.  A security function that isn't implemented properly could create just the hole the hackers are hunting.

The Art of Compliance

When I think of compliance I think of my mom yelling at me to clean my room or I can't play Xbox.  I stomp my feet, procrastinate a little, huff and puff and finally attempt to clean my room.  Clothes get thrown in the hamper, dishes get taken to the kitchen and odds and ends get shoved in the closet or under the bed creating the illusion that my room is clean.  My mom checks my room and declares it good enough and I run downstair and play my Xbox.  Of course by next week my room will be a mess again and I'll be fighting this same battle with my mom.  This sounds an awful like security compliance.  Organizations do just enough to secure their environments for the auditors to come in and give them a stamp of approval and then security is relaxed until the next audit.

In my previous job I worked on a number of Department of Defense projects.  The acronyms in the military are endless but the ones security professionals are most aware of are STIGs and DIACAP.  These acronyms probably makes anyone who has ever worked with them shudder.  In addition to these acronyms security professionals also have to navigate DoD directives, regulations and any other special requirements levied upon them from USCYBERCOM and the specific military branch they are working with.  The endless requirements tend to overlap and it's not always clear which requirements take priority.  What is clear is DoD thinks a one size fits all approach to security is the way to go.  Non-government organizations know this pain very well when trying to comply with PCI-DSS, HIPAA, HITECH, NERC, FISMA and the list goes on and on and on.  Organizations have to align all of these various external requirements with their business goals and objectives.  Instead of being proactive about security, organizations are forced to be reactive based on new laws, regulations and standards.

One size fits all requirements just don't work and lead to ugly and, ironically, insecure implementations.  Take for example an industrial control system with real time or near real time requirements.  The functions performed by these systems are critical and can not be delayed by non-essential processes.  Now add a requirement from some governing body that says HIPS must be installed on the system.  HIPS will slow the system down enough that critical functions can not operate per their operational requirements.  On a non-real time system such as a website the operational requirement are much looser and having HIPS running is no big deal.  This does not ruin the user experience.  The organization running this industrial control system is in a bad situation.  They have to somehow figure out how to install HIPS and stay within their operational requirements.  Here's what will most likely happen.  The organization will install HIPS but disable it until it's time to be audited.  When the auditor shows up then HIPS is enabled and the organization passes the audit.  But this brings up two issues: 1) The organization is only compliant with the requirement when an auditor is present.  The rest of the time the organization is out of compliance. 2) The organization was forced to install a product that could put potentially put lives in jeopardy if enabled during normal operating hours. 

The last example of an organization being forced to install HIPS into a real time system is why one size fits all requirements don't work.  Organizations need to have the flexibility to design the proper security controls into their system rather than being forced to implement requirements that could potentially break the system.  There are waiver processes but those take a lot of time and cost money.  And there is no guarantee that the governing body will grant the waiver. 

Compliance is a reactionary process and is only a snapshot of the organization's security posture at the time they are audited.  If an organization is having to comply with a requirement then chances are they have already lost the battle.  Not to mention two months down the road the organization may have gotten lax about their security and they are no longer compliant.  But they have a certificate saying they are compliant so they are good for another year.  Security too often is reactionary but it should be proactive.  Organizations need to see the bigger picture and take control of their own destiny rather than waiting to see what someone else in the industry does or what some governing body tells them to do.  This causes the organization to quickly react and implement a security control that was not thoroughly thought out and can have broader negative implications down the road.  But the organization is currently compliant and the governing body is happy, at least for now.

How do we fix this problem?  We need compliancy requirements that focus less on controls and more about process.  Organizations should be measured based on how they assess their infrastrucure.  If an organization is meeting the bare minimum standards and not worrying about a standard being deprecated then they are going to lose when they are forced to upgrade to a new standard.  For example, SHA-1 for use in digital signatures has been deprecated by NIST.  This was not something that was done overnight and there was ample time for organizations to upgrade.  But why didn't the organizations upgrade?  SHA-2 has been available for some time so why not use the latest and greatest?  There are lots of excuses that I won't get into here.  But an organization should be judged based on planning for the future.  Not upgrading to SHA-2 until the last minute should give an organization a red mark.  Let's judge an organization based on how they are planning for the future rather than being in compliance with some bare minimum standards that aren't effective.  Mom is going to bug you again next week to clean your room so why not just keep it clean to begin with and save yourself the hassle?