Corporate Cybersecurity E-Book

John Jackson

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch
• Veröffentlichungsjahr: 2021

Seitenzahl: 331

Beschreibung

CORPORATE CYBERSECURITY An insider's guide showing companies how to spot and remedy vulnerabilities in their security programs A bug bounty program is offered by organizations for people to receive recognition and compensation for reporting bugs, especially those pertaining to security exploits and vulnerabilities. Corporate Cybersecurity gives cyber and application security engineers (who may have little or no experience with a bounty program) a hands-on guide for creating or managing an effective bug bounty program. Written by a cyber security expert, the book is filled with the information, guidelines, and tools that engineers can adopt to sharpen their skills and become knowledgeable in researching, configuring, and managing bug bounty programs. This book addresses the technical aspect of tooling and managing a bug bounty program and discusses common issues that engineers may run into on a daily basis. The author includes information on the often-overlooked communication and follow-through approaches of effective management. Corporate Cybersecurity provides a much-needed resource on how companies identify and solve weaknesses in their security program. This important book: * Contains a much-needed guide aimed at cyber and application security engineers * Presents a unique defensive guide for understanding and resolving security vulnerabilities * Encourages research, configuring, and managing programs from the corporate perspective * Topics covered include bug bounty overview; program set-up; vulnerability reports and disclosure; development and application Security Collaboration; understanding safe harbor and SLA Written for professionals working in the application and cyber security arena, Corporate Cybersecurity offers a comprehensive resource for building and maintaining an effective bug bounty program.

Leseprobe

Corporate Cybersecurity

Identifying Risks and the Bug Bounty Program

John Jackson

This edition first published 2022

© 2022 John Wiley & Sons, Ltd.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.

The right of John Jackson to be identified as the author of this work has been asserted in accordance with law.

Registered Office(s)

John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA

John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK

Editorial Office

The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK

For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.

Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Some content that appears in standard print versions of this book may not be available in other formats.

Limit of Liability/Disclaimer of Warranty

While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

Library of Congress Cataloging-in-Publication Data

Names: Jackson, John (Cybersecurity professional), author. Title: Corporate cybersecurity : identifying risks and the bug bounty program / John Jackson. Description: Hoboken, NJ : John Wiley & Sons, 2021. | Includes bibliographical references and index. Identifiers: LCCN 2021020794 (print) | LCCN 2021020795 (ebook) | ISBN 9781119782520 (hardback) | ISBN 9781119782568 (ebook) | ISBN 9781119782537 (pdf) | ISBN 9781119782544 (epub) Subjects: LCSH: Business enterprises--Computer networks--Security measures. | Penetration testing (Computer security) | Cyberspace--Security measures. Classification: LCC HD30.38 .J34 2021 (print) | LCC HD30.38 (ebook) | DDC 658.4/78--dc23 LC record available at https://lccn.loc.gov/2021020794LC ebook record available at https://lccn.loc.gov/2021020795

Cover image: © WhataWin/Shutterstock

Cover design by Wiley

Set in 9.5/12pt STIX Two Text by Integra Software Services Pvt. Ltd, Pondicherry, India

Contents

Cover

Title page

Copyright

Foreword

Acknowledgements

Part 1 Bug Bounty Overview

1 The Evolution of Bug Bounty Programs

1.1 Making History

1.2 Conservative Blockers

1.3 Increased Threat Actor Activity

1.4 Security Researcher Scams

1.5 Applications Are a Small Consideration

1.6 Enormous Budgetary Requirements

1.7 Other Security Tooling as a Priority

1.8 Vulnerability Disclosure Programs vs Bug Bounty Programs

1.8.1 Vulnerability Disclosure Programs

1.8.2 Bug Bounty Programs

1.9 Program Managers

1.10 The Law

1.11 Redefining Security Research

1.12 Taking Action

1.12.1 Get to Know Security Researchers

1.12.2 Fair and Just Resolution

1.12.3 Managing Disclosure

1.12.4 Corrections

1.12.5 Specific Community Involvement

Part 2 Evaluating Programs

2 Assessing Current Vulnerability Management Processes

2.1 Who Runs a Bug Bounty Program?

2.2 Determining Security Posture

2.3 Management

2.3.1 Software Engineering Teams

2.3.2 Security Departments (Security Operations, Fraud Prevention, Governance/ Risk/Compliance, Edge Controls, Vulnerability Management, Endpoint Detection, and Response)

2.3.3 Infrastructure Teams

2.3.4 Legal Department

2.3.5 Communications Team

2.4 Important Questions

2.5 Software Engineering

2.5.1 Which Processes Are in Place for Secure Coding? Do the Software Engineers Understand the Importance of Mitigating the Risks Associated with Vulnerable Code?

2.5.2 How Effective Are Current Communication Processes? Will Vulnerabilities Be Quickly Resolved If Brought to Their Attention?

2.5.3 Is the Breadth of Our Enterprise’s Web and Mobile Applications Immense? Which Processes Are Engineers Using for Development in the Software Development Lifecycle?

2.6 Security Departments

2.6.1 How Does Security Operations Manage Incidents? Will Employee Assistance Be Provided from the Security Operations Team If a Threat Actor Manages to Exploit an Application Vulnerability? Which Tools Do They Have in Place?

2.6.2 What Does the Fraud Prevention Team Do to Prevent Malicious Activities? How Many Occurrences Do They See of Issues such as Account Takeover, and Could They Potentially Create Application Vulnerabilities?

2.6.3 Are There Any Compliance Practices in Place and, If So, How Do They Affect the Vulnerability Management Process? What Does the Application Security Team Have to Do to Assist in Enterprise Compliance?

2.6.4 What Edge Tooling Is in Place to Prevent Attacks? Are Any of the Enterprise Applications at Risk of Being Exploited due to an IoT (Internet of Things) Device?

2.6.5 How Often Does Our Vulnerability Management Team Push for Updates? How Does the Vulnerability Management Team Ensure Servers in which Enterprise Applications Reside Are Secure?

2.7 Infrastructure Teams

2.7.1 What Are Infrastructure Teams Doing to Ensure Best Security Practices Are Enabled? How Long Will It Take the Infrastructure Team to Resolve a Serious Issue When a Server-side Web Application Is Exploited, or During a Subdomain Takeover Vulnerability?

2.7.2 Is There Effective Communication between Infrastructure, Vulnerability Management, Security Operations, and Endpoint Detection and Response?

2.8 Legal Department

2.8.1 How Well Refined is the Relationship between the Application Security Team and the Legal Department?

2.8.2 What Criteria Are/Will Be Set Out for the Escalation of Issues?

2.8.3 Does the Legal Department Understand the Necessity of Bug Bounty Program Management?

2.9 Communications Team

2.9.1 Has the Communications Team Dealt with Security Researchers Before? Is the Importance Understood?

2.9.2 Was the Communications Team Informed of Bug Bounty Program Expectations?

2.10 Engineers

2.11 Program Readiness

3 Evaluating Program Operations

3.1 One Size Does Not Fit All

3.2 Realistic Program Scenarios

3.3 Ad Hoc Program

3.4 Note

3.5 Applied Knowledge

3.5.1 Applied Knowledge #1

3.5.1.1 Private Programs

3.5.2 Applied Knowledge #2

3.5.2.1 Public Programs

3.5.3 Applied Knowledge #3

3.5.3.1 Hybrid Models

3.6 Crowdsourced Platforms

3.7 Platform Pricing and Services

3.8 Managed Services

3.9 Opting Out of Managed Services

3.10 On-demand Penetration Tests

Part 3 Program Setup

4 Defining Program Scope and Bounties

4.1 What Is a Bounty?

4.2 Understanding Scope

4.3 How to Create Scope

4.3.1 Models

4.4 Understanding Wildcards

4.4.1 Subdomain

4.4.2 Domain

4.4.3 Specific Domain Path or Specific Subdomain Path

4.5 Determining Asset Allocation

4.6 Asset Risk

4.7 Understanding Out of Scope

4.8 Vulnerability Types

4.8.1 Denial of Service (DOS) or Distributed Denial of Service (DDoS) Attacks

4.8.2 Social Engineering Attacks

4.8.3 Brute Force or Rate Limiting

4.8.4 Account and Email Enumeration

4.8.5 Self-XSS

4.8.6 Clickjacking

4.8.7 Miscellaneous

4.9 When Is an Asset Really Out of Scope?

4.10 The House Wins – Or Does It?

4.11 Fair Judgment on Bounties

4.12 Post-mortem

4.13 Awareness and Reputational Damage

4.14 Putting It All Together

4.15 Bug Bounty Payments

4.15.1 Determining Payments

4.15.2 Bonus Payments

4.15.3 Nonmonetary Rewards

5 Understanding Safe Harbor and Service Level Agreements

5.1 What Is “Safe Harbor”?

5.1.1 The Reality of Safe Harbor

5.1.2 Fear and Reluctance

5.1.3 Writing Safe Harbor Agreements

5.1.4 Example Safe Harbor Agreement

5.2 Retaliation against a Rogue Researcher (Cybercriminal or Threat/Bad Actor)

5.3 Service Level Agreements (SLAs)

5.3.1 Resolution Times

5.3.2 Triage Times

6 Program Configuration

6.1 Understanding Options

6.2 Bugcrowd

6.2.1 Creating the Program

6.2.2 Program Overview

6.2.2.1 The Program Dashboard

6.2.2.2 The Crowd Control Navbar

Summary

Submissions

Researchers

Rewards

Insights Dashboard

Reports

6.2.3 Advanced Program Configuration and Modification

6.2.3.1 Program Brief

6.2.3.2 Scope and Rewards

6.2.3.3 Integrations

6.2.3.4 Announcements

6.2.3.5 Manage Team

6.2.3.6 Submissions

6.2.4 Profile Settings

6.2.4.1 The Profile and Account

6.2.4.2 Security

6.2.4.3 Notification Settings

6.2.4.4 API Credentials

6.2.5 Enterprise “Profile” Settings

6.2.5.1 Management and Configuration

6.2.5.2 Organization Details

6.2.5.3 Team Members

6.2.5.4 Targets

6.2.5.5 Authentication

6.2.5.6 Domains

6.2.5.7 Accounting

6.3 HackerOne

6.3.1 Program Settings

6.3.1.1 General

6.3.1.2 Information

6.3.1.3 Product Edition

6.3.1.4 Authentication

6.3.1.5 Verified Domains

6.3.1.6 Credential Management

6.3.1.7 Group Management

6.3.1.8 User Management

6.3.1.9 Audit Log

6.3.2 Billing

6.3.2.1 Overview

6.3.2.2 Credit Card

6.3.2.3 Prepayment

6.3.3 Program

6.3.3.1 Policy

6.3.3.2 Scope

6.3.3.3 Submit Report Form

6.3.3.4 Response Targets

6.3.3.5 Metrics Display

6.3.3.6 Email Notifications

6.3.3.7 Inbox Views

6.3.3.8 Disclosure

6.3.3.9 Custom Fields

6.3.3.10 Invitations

6.3.3.11 Submission

6.3.3.12 Message Hackers

6.3.3.13 Email Forwarding

6.3.3.14 Embedded Submission Form

6.3.3.15 Bounties

6.3.3.16 Swag

6.3.3.17 Common Responses

6.3.3.18 Triggers

6.3.3.19 Integrations

6.3.3.20 API

6.3.3.21 Hackbot

6.3.3.22 Export Reports

6.3.3.23 Profile Settings

6.3.4 Inbox

6.3.4.1 Report Details

6.3.4.2 Timeline

6.4 Summary

Part 4 Vulnerability Reports and Disclosure

7 Triage and Bug Management

7.1 Understanding Triage

7.1.1 Validation

7.1.2 Lessons Learned

7.1.3 Vulnerability Mishaps

7.1.4 Managed Services

7.1.5 Self-service

7.2 Bug Management

7.2.1 Vulnerability Priority

7.2.2 Vulnerability Examples

7.2.2.1 Reflected XSS on a login portal

Report and Triage

Validation

7.2.2.2 Open redirect vulnerability

Report and Triage

Validation

7.2.2.3 Leaked internal Structured Query Language (SQL) server credentials

Report and Triage

Validation

7.3 Answers

7.3.1 Vulnerability Rating-test Summary

7.3.1.1 Reflected XSS in a login portal

7.3.1.2 Open redirect vulnerability

7.3.1.3 Leaked internal SQL server credentials

7.3.2 Complexity vs Rating

7.3.3 Projected Ratings

7.3.4 Ticketing and Internal SLA

7.3.4.1 Creating Tickets

8 Vulnerability Disclosure Information

8.1 Understanding Public Disclosure

8.1.1 Making the Decision

8.1.1.1 Private Programs

The Bottom Line

8.1.1.2 Public Programs

The Bottom Line

8.2 CVE Responsibility

8.2.1 What are CVEs?

8.2.2 Program Manager Responsibilities

8.2.3 Hardware CVEs

8.2.4 Software and Product CVEs

8.2.5 Third-party CVEs

8.3 Submission Options

8.3.1 In-house Submissions

8.3.2 Program Managed Submissions and Hands-off Submissions

8.3.2.1 Program Managed Submissions

8.3.2.2 Hands-off Submissions

Part 5 Internal and External Communication

9 Development and Application Security Collaboration

9.1 Key Role Differences

9.1.1 Application Security Engineer

9.1.2 Development

9.2 Facing a Ticking Clock

9.3 Meaningful Vulnerability Reporting

9.4 Communicating Expectations

9.5 Pushback, Escalations, and Exceptions

9.5.1 Internal steps

9.5.2 External steps

9.5.2 Escalations

9.5.3 Summary

9.6 Continuous Accountability

9.6.1 Tracking

9.6.2 Missed Deadlines

10 Hacker and Program Interaction Essentials

10.1 Understanding the Hacker

10.1.1 Money, Ethics, or Both?

10.1.2 Case Study Analysis

10.2 Invalidating False Positives

10.2.1 Intake Process and Breaking the News

10.2.2 Dealing with a Toxic Hacker

10.3 Managed Program Considerations

10.4 In-house Programs

10.5 Blackmail or Possible Threat Actor

10.6 Public Threats or Disclosure

10.7 Program Warning Messages

10.8 Threat Actor or Security Researcher?

10.9 Messaging Researchers

10.9.1 Security Researcher Interviews

10.9.2 Bug Bounty Program Manager Interviews

10.10 Summary

Part 6 Assessments and Expansions

11 Internal Assessments

11.1 Introduction to Internal Assessments

11.2 Proactive Vs Reactive Testing

11.3 Passive Assessments

11.3.1 Shodan

11.3.1.1 Using Shodan

11.3.2 Amass/crt.sh

11.3.2.1 Amass

11.3.2.2 crt.sh

11.4 Active Assessments

11.4.1 nmapAutomator.sh

11.4.2 Sn1per

11.4.3 Owasp Zap

11.4.4 Dalfox

11.4.5 Dirsearch

11.5 Passive/Active Summary

11.6 Additional Considerations: Professional Testing and Third-Party Risk

12 Expanding Scope

12.1 Communicating with the Team

12.2 Costs of Expansion

12.3 When to Expand Scope

12.4 Alternatives to Scope Expansion

12.5 Managing Expansion

13 Public Release

13.1 Understanding the Public Program

13.2 The “Right” Time

13.3 Recommended Release

13.3.1 Requirements

13.4 Rolling Backwards

13.5 Summary

Index

End User License Agreement

List of Illustrations

Chapter 6

Figure 6.1 Bugcrowd “Start now” button.

Figure 6.2 Bugcrowd: selection “Bug Bounty Program”.

Figure 6.3 Selecting the program name on Bugcrowd.

Figure 6.4 Adding targets to test on Bugcrowd.

Figure 6.5 Adding a target to Bugcrowd.

Figure 6.6 Adding reward ranges by severity on Bugcrowd.

Figure 6.7 Identify goals and concerns on Bugcrowd.

Figure 6.8 Select researcher activities, environments,...

Figure 6.9 Upload your company’s logo and create a...

Figure 6.10 Vulnerability tasking tabs.

Figure 6.11 Bugcrowd documentation.

Figure 6.12 Program dropdown menu.

Figure 6.13 Crowd control navbar.

Figure 6.14 Vulnerability submissions panel.

Figure 6.15 Program participants tab.

Figure 6.16 Program invitations tab.

Figure 6.17 Program rewards dashboard.

Figure 6.18 Insights dashboard: technical severity chart.

Figure 6.19 Insights dashboard: target breakdown.

Figure 6.20 Insights dashboard: performance.

Figure 6.21 Program brief settings.

Figure 6.22 Scope details.0

Figure 6.23 Profile dropdown menu.

Figure 6.24 Targets tab.

Figure 6.25 Program dropdown menu.

Figure 6.26 Add group” button.

Figure 6.27 Description of an asset group.

Figure 6.28 Target groups.

Figure 6.29 Target group rewards.

Figure 6.30 Target group listings.

Figure 6.31 Integrating various tools to help with report management.

Figure 6.32 Announcements option.

Figure 6.33 New announcement option.

Figure 6.34 Manage team option.

Figure 6.35 Invite a team member option.

Figure 6.36 Data fields option.

Figure 6.37 CVSS v3 option.

Figure 6.38 Remediation advice option.

Figure 6.39 Retesting option.

Figure 6.40 Markdown embedded attachments option.

Figure 6.41 Profile and enterprise sidebar.

Figure 6.42 Profile option.

Figure 6.43 Security option.

Figure 6.44 Events option.

Figure 6.45 Two-factor authentication option.

Figure 6.46 Notifications settings option.

Figure 6.47 API credentials option.

Figure 6.48 Single sign-on option.

Figure 6.49 Unverified domains option.

Figure 6.50 Activity summary.

Figure 6.51 Submit deposit request option.

Figure 6.52 Transfer funds option.

Figure 6.53 Program balances option.

Figure 6.54 Program settings option.

Figure 6.55 Miscellaneous program options.

Figure 6.56 Security page function.

Figure 6.57 HackerOne product editions.

Figure 6.58 Single sign-on with SAML.

Figure 6.59 Domain verification example.

Figure 6.60 Credential management tab.

Figure 6.61 Group management options.

Figure 6.62 Group management options.

Figure 6.63 Adding users option.

Figure 6.64 Audit log option.

Figure 6.65 Overview of bounties and fees.

Figure 6.66 Adding assets.

Figure 6.67 The CIA triad.

Figure 6.68 Submit report form option.

Figure 6.69 Customizing the report form.

Figure 6.70 Response targets option.

Figure 6.71 Metrics display option.

Figure 6.72 Setting email notifications.

Figure 6.73 Inbox views option.

Figure 6.74 Disclosure option.

Figure 6.75 Invitations option.

Figure 6.76 Public launch option.

Figure 6.77 Submission requirements option.

Figure 6.78 Messaging hackers option.

Figure 6.79 Email forwarding function.

Figure 6.80 Embedded submission configuration.

Figure 6.81 Bounties option.

Figure 6.82 Common reponses option.

Figure 6.83 Add common response option.

Figure 6.84 Edit common response option.

Figure 6.85 Default common responses option.

Figure 6.86 Create triggers option.

Figure 6.87 Hackbot settings option.

Figure 6.88 Export reports option.

Figure 6.89 Reporting inbox vulnerabilities.

Figure 6.90 Example report.

Figure 6.91 Timeline option.

Chapter 11

Figure 11.1 Shodan Browser Search.

Figure 11.2 Shodan Search Bar.

Figure 11.3 Generating Results.

Figure 11.4 Shodan Asset Analysis.

Figure 11.5 Shodan Services Analysis.

Figure 11.6 Google Search Results.

Figure 11.7 Amass Scanning for Subdomains.

Figure 11.8 Subdomains in Nano.

Figure 11.9 Subdomain Enumeration with crt.sh.

Figure 11.10 nmapAutomator Scanning Information.

Figure 11.11 nmapAutomator Performing Full Scan of Asset.

Figure 11.12 nmapAutomator Results.

Figure 11.13 Sn1per Running Metasploit Modules.

Figure 11.14 Sn1per Running Nmap Scripts.

Figure 11.15 Setting up an Automated Scan in OWASP ZAP.

Figure 11.16 OWASP ZAP Scan Results.

Figure 11.17 OWASP ZAP Potential Vulnerability Result.

Figure 11.18 XSS Attack Performed.

Figure 11.19 Dalfox Available Command.

Figure 11.20 Dalfox Identifying an XSS Instance.

Figure 11.21 XSS Attack.

Figure 11.22 Dirsearch Finding Folders.

Guide

Cover

Title page

Copyright

Table of Contents

Foreword

Acknowledgments

Begin Reading

Index

End User License Agreement

Pages

i

ii

iii

iv

v

vi

vii

viii

ix

x

xi

xii

xiii

xiv

xv

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

Foreword

It’s safe to say that information security and the industry surrounding it has exploded into a massive, constantly growing sector around the world. Like many other professions within technology, the main attribute which has secured many organizations success (or failure) in maintaining their relevance has been their ability to adapt. In the case of security, we are constantly adapting to methods used by malicious actors with the hopes of becoming as secure as possible – with the goal of identifying (and remediating) vulnerabilities prior to an attack.

As security professionals we understand that it isn’t a matter of if an event happens, but when. Although nothing can be completely secure, it’s our job to work towards obtaining a level of maturity within our security programs that are proactive against potential threats. Although zero days will always exist, it’s our job to stay up to date and as protected as possible, which can be very costly, especially for many organizations that don’t fully understand security and (in many situations) are hesitant to move forward with a proper budget for what is needed to enable adequate professionally accepted levels of protection.

Information security, or cybersecurity, is still in its infancy. This may be a shocking statement to someone who doesn’t work within the industry; it is, however, accurate. Only recently have many universities begun offering degrees in the field of cybersecurity. Many pieces of software that would be considered a “must have” for a company’s defense in depth weren’t in existence just a couple of short years ago.

Many professionals in the industry have moved to their positions as security specialists after previously working in general information technology. I have worked with many organizations, in both the private and the public sectors, and at this point in time, from what I’ve witnessed, a very small fraction of security professionals have been formally educated in security, and rely heavily on certifications to prove their understanding of the field. This is a blessing for those who need to obtain credentials quickly without the slow drag of the many years of college, but also is a curse for those with certifications but little real world experience. An overwhelming number of professionals are learning on the job, which can be daunting given the fact that many organizations are looking to increase their maturity as quickly as possible.

There are many gears turning in a proper security program. There’s an overall lack of understanding of security by those outside of the security team, so one of the most prominent procedures by security professionals is to understand how to assign tasks to thelimited resources they have while properly managing a security program that grows in maturity on a constant basis. All in a world where new vulnerabilities can be found daily.

It’s no secret that software security and web application security are fast-growing segments within the field of cybersecurity. Every organization has a web presence. Every organization uses software. Individuals also use software and web applications in their daily lives, assets which hold personally identifiable information, and whose contents can greatly range in sensitivity.

Although identifying vulnerabilities through continuous testing is a powerful activity, many organizations don’t have the resources or budget to consider it as an option. In search for a remedy to this situation, I have seen many explore the option of creating or joining a bug bounty program, albeit reasons for considering such a program are not limited to such issues. This can clearly be seen in large organizations’ involvement with their own bug bounty programs. It’s quickly becoming a standard for many large companies to have a bug bounty program, either in house or through a third party.

Bug bounty programs may be new, but they have caught on quickly with proactive organizations seeking to be more secure. It was only in 2013 (less than a decade as of this writing) that Katie Moussouris created Microsoft’s first bug bounty program. In March 2016, Moussouris would also be involved with the creation of the Department of Defense’s “Hack the Pentagon” pilot program, which would serve as the United States Federal Government’s first bug bounty program. Bug bounty programs have gained in popularity due to their benefits greatly outweighing their negatives, many of which are explained clearly within this book, which at the time of writing is geared to be the first wide-release publication on how to create and manage a bug bounty program.

This book is a critical asset for security professionals who seek to understand how to build and operate a bug bounty program. Security professionals can use this book as a guide for the creation of their own bug bounty program. Professionals across all domains of security can use this book to quickly absorb the years of information acquired by real world experience to understand the subject and provide more value to their team.

Robert (@rej_ex) Willis

Acknowledgments

There are far too many influential people in my career to mention in this section. I’m thankful for all of the information security individuals who have let me learn alongside them, given me opportunities, and have put my skills to the test. I’ve learned many lessons along the way.

A special thank-you to my friend Christian Bobadilla is in order. Christian is one of the most talented application security experts I know, and his humility keeps him out of the information security limelight. Through me, your excellent advice and mentoring lives. If it weren’t for you, I wouldn’t know even a quarter of what I do about bug bounty programs. Thank you for being a positive role model in my life. It’s exceedingly difficult to find people who are not only intellectually sharp and humble but also incredible leaders. This book is dedicated to the faith that you have put in my abilities.

One final dedication: to my father, who encouraged me to try my best at all times. Rest in peace.

Part 1 Bug Bounty Overview

1 The Evolution of Bug Bounty Programs

1.1 Making History

Understanding the evolution of bug bounty programs first requires familiarity with the hacking landscape, or as many in the information security field know it, penetration testing. Security researchers haven’t always been respected or given the opportunity to shine. Throughout history, hacking has been a word that scares the public and creates waves of fear inside a company when rumors of a “hack” spread. The first bounty paid for breaking into something (in recorded history) was in 1851. Charles Alfred Hobbs was paid roughly the equivalent of $20,000 to pick a physical lock. (https://www.itspmagazine.com/itsp-chronicles/history-and-interesting-facts-about-bug-bounties-an-appsec-usa-2017-panel-recap).

The first actual bounty program was run by Netscape and it began in 1995. The primary scope was application testing for Netscape Navigator 2.0., their primary product. Slowly, other enterprises started to adapt their own bug bounty programs and offer awards. Bug bounty crowdsourcing platforms introduced the new wave, compiling enterprise programs into a neat catalogue in which security researchers could hop into various programs and begin to participate. Bugcrowd was known as the first crowdsourcing platform in bug bounty history and has been a key player in enterprise bug bounty program management. The pioneers – Casey Ellis, Chris Raethke, and Sergei Belokamen – believed in connecting latent potential to unmet demand with the overall goal of making security easier for everyone. In addition, Ellis firmly believed in assisting security researchers in keeping their records clean. Casey Ellis has also expressed a desire to help educate the youth toward the idea of ethical hacking, rather than a life of crime, and part of the inspiration for creating such a company has to do with the ideal of destigmatizing security research.

In all actuality, reviewing the state and history of bug bounty programs gives the reader a valuable positive perspective, but enterprises are slow to adapt. Even since 1995, there are still fewer than 400 bug bounty programs and 1600 vulnerability disclosure programs that exist in the world. The surprisingly small number of programs that exist in the world represent the resistance and conservatism of the field of legal hacking, otherwise known as security research.

1.2 Conservative Blockers

When information security specialists learn about bug bounty programs, many of them are excited to get involved. Application security is a growing field, and modern day web, mobile, and hardware assets need to be protected. With such an essential requirement to protect applications, enterprises still resist the absolute necessity of making vulnerability reporting management a prioritized incentive. As with everything, there’s not a “one-size-fits-all” answer for why an enterprise would ignore application security; however, many factors play a role in the resistance that is widespread, even today. For example, here are some of the reasons a company may decide to ignore the idea of a bug bounty program:

Increased threat actor activity.

Security researchers scamming.

Applications being a small consideration.

Enormous budgetary requirements.

Other security tooling as a priority.

There are obviously several other reasons an enterprise may believe a bug bounty program will cause unnecessary risk or negative effects. Debunking the above five defined points will give people a better understanding of why being afraid is natural, but it can be detrimental to the overall health of a good application security program.

1.3 Increased Threat Actor Activity

An enterprise may be fearful that establishing a bug bounty program will cause an increase of malicious threat actors attempting to hack into or successfully exploiting applications. The logic can be portrayed as such, “If an enterprise bug bounty program is established, then security researchers will be allowed to hack, and it will be impossible to tell who is malicious.” The problem with this statement’s assumption that threat actors are hiding among security researchers is one of a common philosophical logical fallacy: the Slippery Slope.

The Slippery Slope logical fallacy is best defined as, “A course of action that seems to lead inevitably from one action or result in another with unintended consequences.” In layman’s terms, the translation of the Slippery Slope in the security research scenario is, “If the enterprise allows security researchers to conduct research, we will be maliciously exploited.” It’s best to imagine the scenario of increased threat actor activity with the other perspective in mind. Without a bug bounty program, flaws may never be identified – vulnerabilities that could compromise an organization’s sensitive information or intellectual property.

Enterprises considering operating bug bounty programs should learn effective logging and prevention through logging mechanisms and web application firewalls, which are discussed later in this book.

1.4 Security Researcher Scams

Any type of business that relies on services rendered by another party should always be weary of scamming. Understanding the vulnerability types, criticality, and assessing payment amounts will always be the best course of action for a company running a bug bounty program. Still, the idea of scamming isn’t a new one. Potential program managers have to learn best practices and understand the basics of vulnerability management. Nonetheless, protections for programs are in place. Managed services offered through bug bounty crowdsourcing platforms such as Bugcrowd and HackerOne will become useful tools. The triage team will assist in validating the legitimacy of a vulnerability which can assist in preventing scamming. Program managers shouldn’t solely rely on the validation, but scamming happens far more infrequently than enterprises that are on the fence imagine.

1.5 Applications Are a Small Consideration

Enterprises that avoid bug bounty programs because of the idea of applications being a small attack surface are asking for trouble. When employees tasked with the security of a company evaluate vulnerability potential, the obvious go-to is to secure the network and related assets. However, web and mobile applications in particular have become exceedingly complex. With multiple development languages and servers, the attack surface is far greater than one might imagine. Consider the following example:

Server → Hosts one part of the web application → One assigned IP address

Web application → Connected to multiple servers → Multiple IP addresses

The deployment of an enterprise’s assets will always be the determinant factor in the attack service; however, modern applications are becoming more interconnected than they ever were in the past. It’s easy to think about a “server” as an asset with a wide attack surface, and in many cases, that is true, and the attack vectors will always vary. Regardless, enterprises should not consider the value of a bug bounty program as something minute and ineffective. In addition, flawed application logic may result in the exploitation of the network and enterprises may not consider that. For example, SQL (Structured Query Language) injection can result in a full server-database dump or remote code execution on the network. Server side request forgery can result in the exposure of sensitive information leading to unauthorized server access or pivoting to other parts of the network. Application security is a large undertaking and neglecting it can result in the full compromise of an enterprise.

1.6 Enormous Budgetary Requirements

Bug bounty programs scale. The size and operation of the bug bounty program is up to the enterprise to decide. In addition, if the company isn’t giant, it’s unrealistic to assume that the enterprise would have to pay a large sum of money to get a program up and running. With bug bounty crowdsourcing becoming the norm, companies like Bugcrowd and HackerOne are willing to have scoping calls with leadership to identify a fair pricing model for program management. The price of program management is well worth the cost of identifying vulnerabilities that can result in the loss of hundreds of thousands, if not millions, of dollars in assets or compliance violations such as GDPR (General Data Protection Regulation) or the California Privacy Act. Application security, like any other subbranch of security, is an investment – and security doesn’t typically see hefty returns on investment. Information security doesn’t make a company money: it protects the company from losing money, allowing the acquisition of money.

1.7 Other Security Tooling as a Priority

Out of all of the other potential worries for setting up a program, security tooling is a legitimate concern. Balancing a budget requires coordination with all levels of leadership and an overall evaluation of security posture. For example, establishing a bug bounty program isn’t likely a good idea if the enterprise does not have a web application firewall, or a decent endpoint protection and response solution. Coordination with the security team will have to occur, but if all other bases are covered, there’s no reason a basic bug bounty program cannot be established.

1.8 Vulnerability Disclosure Programs vs. Bug Bounty Programs

Even for the most technical of individuals, understanding the difference between a vulnerability disclosure program (VDP) and a bug bounty program (BBP) can be mind boggling. Even still, engineers who run bug bounty programs may make the mistake over calling a bug bounty program a vulnerability disclosure program, or vice versa. Understanding the difference between the two is essential to communicating expectations clearly and educating the general public on the day-to-day processes involved.

1.8.1 Vulnerability Disclosure Programs

Vulnerability disclosure programs are the method used when an enterprise wants to facilitate the disclosure of vulnerabilities but not offer any sort of paid incentive. Vulnerability disclosure programs can be considered a goodwill type of vulnerability management process. The two types of vulnerability disclosure programs are managed and unmanaged. An unmanaged program would be a vulnerability disclosure program that is offered in-house, with an associated good faith based effort. In contrast, a managed vulnerability disclosure program could be one where program managers are assisted by a triage team from a bug bounty crowdsourcing platform such as Bugcrowd or HackerOne. As an incentive to researchers, they are offered points in return for reports, which is an essential part of leveling-up and getting invited to private programs, which typically have less competition for security researchers and a better chance of vulnerability finding.

Private vulnerability disclosure programs are also allowed through crowdsourcing platforms, reducing the costs associated with paying bounties as points will be rewarded.

1.8.2 Bug Bounty Programs

Bug bounty programs are typically more mature vulnerability disclosure programs, offering rewards in place of points. When program managers want to convert their vulnerability disclosure programs to bug bounty programs, the process is typically as simple as initiating a financial incentive for security research. Bug bounty programs carry more weight and attract more professional hackers. For example, some of the best security researchers may never participate in vulnerability disclosure programs because the time they spend evaluating bug bounty programs could easily be time converted to a cash flow. An enterprise’s end state should always be aspiring to reach paid-program participation. Security research consumes a lot of time and an enterprise should want to pay its researchers for the time spent. If confused, think of it like this: how many people are willing to do a full-time job for free versus paid? Hobbyists will always exist, but the participation of some of the greatest security researchers can only be obtained with monetary incentives.

1.9 Program Managers

Throughout the book, the phrase “program manager” will come up frequently. A program manager isn’t to be thought of as a traditional manager who coordinates employee activity. Rather, program managers are any employee who deals with the configuration or management of an enterprise bug bounty program. For example, the title of the employee doesn’t matter: an application security engineer or a chief information security officer could be a program manager. The only consideration is that the employee must have oversight of the program and the ability to make changes. After all, even an employee who is remediating bugs is managing the day-to-day workflow of the program.

1.10 The Law

Historically, the law hasn’t always been kind to security researchers. Even today, hacking is still considered dangerous or controversial to nontechnical people. A substantial part of society does not view hacking as an art, but as a criminal behavior in all circumstances. When most people view hacking as an overwhelmingly criminal activity, it is unsurprising that legitimate researchers often find themselves working in a hostile environment, and one that threatens to punish them. Many documented instances of security researchers being threatened with legal action exist. A quick search on the Internet of the phrase “security researcher threatened” will bring up quite a bit of news.

Redefining the expectations of security research starts with educating the community – and bug bounty programs play a gigantic role in helping society understand that hacking can be ethical. Vulnerability disclosure programs are a great start, but the end state is a transition to a bug bounty program that allows hackers to receive fair compensation for their efforts. Nonetheless, security research without utilizing a bug bounty program can be highly dangerous and can risk the livelihood of the individual conducting the research. A bug bounty program and the safe harbor clauses it contains can help to guarantee researcher safety. Vulnerability research has changed the landscape of what category hackers fall into, and has allowed quite a bit of flexibility and protection from punishment from the law.

1.11 Redefining Security Research

During the course of this book, the reader will see what skills are necessary to create, manage, and refine bug bounty programs. The one important aspect to remember when reading this book is that establishing or managing a bug bounty program is only one small part of a much bigger picture. History is being made, in real time, and the expansion of ethical hacking into the enterprise space is a necessary component of ensuring the safety of company assets and user data. Understanding how important programs can be is a way of information security that should be shared in a positive light. The best way to bring attention to the ethical nature of thousands of security researchers while they hack and make a difference is to operate with an open mind and attempt to give honest disclosure, while awarding processes a fair evaluation on every occasion.