3

How to boot up a bug bounty program in a DevOps world

In the release-driven world of DevOps, where automation is king, there is still a need for manual assessments and ethical hacking to assess your attack surface. You may have spent time automating your static and dynamic analysis capabilities, maybe even focusing on differential assessments, where only changed code is assessed. 

A bug bounty program might be right for your organization to add another layer of diligence beyond the de facto annual penetration test, and to continuously assess your external web and mobile application portfolio with manual independent assessors. 

If you have been following recent trends in software security, bug bounty or responsible disclosure programs have been all the rage in identifying real production security vulnerabilities in live applications. Information security professional and writer Daniel Miessler states in his blog:

“If you want to continue finding more vulnerabilities, and the systems you’re testing are not overly sensitive (source code reviews, private networks, crown jewels, etc.), then you should start thinking about doing a bug bounty.”

[ Special Coverage: All in on All Day DevOps ]

It can be argued that starting with a bug bounty may allow for quick-traction vulnerability management. But I recommend starting with the proverbial low-hanging fruit by performing the basic application security blocking and tackling with secure code training, static analysis, dynamic analysis, on-going (targeted) penetration testing, and general vulnerability management. 

Adam Bacchus, Chief Bounty Officer at HackerOne, says:

“One of the biggest causes of misunderstandings between hackers and security teams is a lack of communication.”

A bug bounty provides an invaluable means of collaborating with the large, verbose security researcher community. I recommend having a well-rounded security professional managing the relationships who can also re-test issues and discuss vulnerabilities intelligently.  While the security researchers are an extension of your team, you have to keep in mind that they are not employed by the organization, nor do they need the detail behind a business decision to accept a risk.

Receiving communications from a researcher requires finesse to handle the relationship, so I can't stress enough that minute business details or technical aspects should not be argued.  As an example, why your team chose the cryptographic hash algorithm SHA-1 instead of the more modern SHA-256, even if it is a vendor or product limitation.  It is critical to recognize the submission and show appropriate appreciation for the effort, but always default back to a properly defined program policy with details about disclosure of remediation activities or follow-up communications once issues are submitted. Be consistent, and be fair. 

As an information security professional who has had the opportunity to build software security programs in four different organizations, I have discovered some uncommon lessons over the years. Here are three quick tips.

World Quality Report 2017-18: The state of QA and testing

1. Vulnerability management

Ensure your security vulnerability management process can handle production-related security issues. If you are comfortable with pre-prod assessment practices but have not dealt with critical issues that could lead to a potential incident, perform some simple tabletop exercises on how the issue would be managed, communicated, and remediated. 

2. It's dangerous to go it alone

While booting up an internal program may seem straightforward, I highly recommend starting with a provider or partner with experience handling the security research community. Having an established communication platform, community, and support will help augment your team's ability to handle what will likely result in many false positives.

Another reason for starting this way is to avoid conflicts over a design pattern your business has decided upon--one that a security researcher would not understand independently without having sat in all those design reviews and threat modeling meetings you had.

3. Have a budget

Working in publicly traded organizations requires effective budgeting and finance management. Therefore, to reward security researchers you need a mechanism to provide incentives and to genuinely say ‘thank you’ to someone who is attempting to help your organization. I have yet to meet a finance team that wants to handle your team submit expense reports for purchasing digital currency. 

Forecasting and managing a budget require intelligence, and a phase-based approach to testing and learning. Don't just open up all of your Internet-facing properties at once. Refer back to suggestion No. 2 when partnering with a vendor with the effective experience.

Bug bounties are bountiful

If you have ever had to field a question from your CEO, CIO, CTO, or CISO about a potential vulnerability sent through some social media or email channel, you could have benefited from a bug bounty program. Unless you have a process or platform of communication, you will have limited means for harnessing the power of legitimate security researchers while also separating out the signal to noise ratio—and there will be noise. 

While most security researchers have positive intent, there are scenarios where researchers could reach out to say that they have performed due diligence to "check the box" before publicly disclosing the issue. A social media message is appreciated more than a public presentation, but a proven, trusted bug bounty model is the ideal. 

For more about my real-world experiences and the practical aspects of launching a bug bounty program, join me during All Day DevOps 2017, where I will share more on the topic. Admission is free, and you can also view my presentation after the event concludes.

World Quality Report 2017-18: The state of QA and testing
 

 

Topics: Security