Jackson, John (Cybersecurity professional),
Corporate cybersecurity : identifying risks and the bug bounty program / John Jackson. - 1 online resource : color illustrations
Includes bibliographical references and index.
Foreword xiii -- Acknowledgments xv -- Part 1 Bug Bounty Overview 1 -- 1 The Evolution of Bug Bounty Programs 3 -- 1.1 Making History 3 -- 1.2 Conservative Blockers 4 -- 1.3 Increased Threat Actor Activity 4 -- 1.4 Security Researcher Scams 5 -- 1.5 Applications Are a Small Consideration 5 -- 1.6 Enormous Budgetary Requirements 5 -- 1.7 Other Security Tooling as a Priority 6 -- 1.8 Vulnerability Disclosure Programs vs Bug Bounty Programs 6 -- 1.8.1 Vulnerability Disclosure Programs 6 -- 1.8.2 Bug Bounty Programs 7 -- 1.9 Program Managers 7 -- 1.10 The Law 7 -- 1.11 Redefining Security Research 8 -- 1.12 Taking Action 8 -- 1.12.1 Get to Know Security Researchers 9 -- 1.12.2 Fair and Just Resolution 9 -- 1.12.3 Managing Disclosure 9 -- 1.12.4 Corrections 9 -- 1.12.5 Specific Community Involvement 9 -- Part 2 Evaluating Programs 11 -- 2 Assessing Current Vulnerability Management Processes 13 -- 2.1 Who Runs a Bug Bounty Program? 13 -- 2.2 Determining Security Posture 13 -- 2.3 Management 14 -- 2.3.1 Software Engineering Teams 14 -- 2.3.2 Security Departments (Security Operations, Fraud Prevention, Governance/Risk/Compliance, Edge Controls, Vulnerability Management, Endpoint Detection, and Response) 14 -- 2.3.3 Infrastructure Teams 14 -- 2.3.4 Legal Department 14 -- 2.3.5 Communications Team 14 -- 2.4 Important Questions 15 -- 2.5 Software Engineering 15 -- 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? 15 -- 2.5.2 How Effective Are Current Communication Processes? Will Vulnerabilities Be Quickly Resolved If Brought to Their Attention? 15 -- 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? 16 -- 2.6 Security Departments 16 -- 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? 16 -- 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? 16 -- 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? 17 -- 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? 17 -- 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? 17 -- 2.7 Infrastructure Teams 17 -- 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? 17 -- 2.7.2 Is There Effective Communication between Infrastructure, Vulnerability Management, Security Operations, and Endpoint Detection and Response? 18 -- 2.8 Legal Department 18 -- 2.8.1 How Well Refined is the Relationship between the Application Security Team and the Legal Department? 18 -- 2.8.2 What Criteria Are/Will Be Set Out for the Escalation of Issues? 18 -- 2.8.3 Does the Legal Department Understand the Necessity of Bug Bounty Program Management? 18 -- 2.9 Communications Team 18 -- 2.9.1 Has the Communications Team Dealt with Security Researchers Before? is the Importance Understood? 18 -- 2.9.2 Was the Communications Team Informed of Bug Bounty Program Expectations? 19 -- 2.10 Engineers 19 -- 2.11 Program Readiness 19 -- 3 Evaluating Program Operations 21 -- 3.1 One Size Does Not Fit All 21 -- 3.2 Realistic Program Scenarios 21 -- 3.3 Ad Hoc Program 22 -- 3.4 Note 24 -- 3.5 Applied Knowledge 24 -- 3.5.1 Applied Knowledge #1 24 -- 3.5.1.1 Private Programs 25 -- 3.5.2 Applied Knowledge #2 25 -- 3.5.2.1 Public Programs 25 -- 3.5.3 Applied Knowledge #3 26 -- 3.5.3.1 Hybrid Models 26 -- 3.6 Crowdsourced Platforms 27 -- 3.7 Platform Pricing and Services 28 -- 3.8 Managed Services 28 -- 3.9 Opting Out of Managed Services 29 -- 3.10 On-demand Penetration Tests 29 -- Part 3 Program Setup 31 -- 4 Defining Program Scope and Bounties 33 -- 4.1 What is a Bounty? 33 -- 4.2 Understanding Scope 33 -- 4.3 How to Create Scope 34 -- 4.3.1 Models 34 -- 4.4 Understanding Wildcards 34 -- 4.4.1 Subdomain 35 -- 4.4.2 Domain 35 -- 4.4.3 Specific Domain Path or Specific Subdomain Path 35 -- 4.5 Determining Asset Allocation 36 -- 4.6 Asset Risk 37 -- 4.7 Understanding Out of Scope 37 -- 4.8 Vulnerability Types 38 -- 4.8.1 Denial of Service (DOS) or Distributed Denial of Service (DDoS) Attacks 38 -- 4.8.2 Social Engineering Attacks 38 -- 4.8.3 Brute Force or Rate Limiting 38 -- 4.8.4 Account and Email Enumeration 38 -- 4.8.5 Self-XSS 39 -- 4.8.6 Clickjacking 39 -- 4.8.7 Miscellaneous 39 -- 4.9 When is an Asset Really Out of Scope? 39 -- 4.10 The House Wins - Or Does It? 40 -- 4.11 Fair Judgment on Bounties 42 -- 4.12 Post-mortem 43 -- 4.13 Awareness and Reputational Damage 43 -- 4.14 Putting It All Together 44 -- 4.15 Bug Bounty Payments 44 -- 4.15.1 Determining Payments 45 -- 4.15.2 Bonus Payments 46 -- 4.15.3 Nonmonetary Rewards 46 -- 5 Understanding Safe Harbor and Service Level Agreements 49 -- 5.1 What is "Safe Harbor"? 49 -- 5.1.1 The Reality of Safe Harbor 49 -- 5.1.2 Fear and Reluctance 49 -- 5.1.3 Writing Safe Harbor Agreements 50 -- 5.1.4 Example Safe Harbor Agreement 50 -- 5.2 Retaliation against a Rogue Researcher (Cybercriminal or Threat/Bad Actor) 51 -- 5.3 Service Level Agreements (SLAs) 52 -- 5.3.1 Resolution Times 53 -- 5.3.2 Triage Times 53 -- 6 Program Configuration 55 -- 6.1 Understanding Options 55 -- 6.2 Bugcrowd 55 -- 6.2.1 Creating the Program 55 -- 6.2.2 Program Overview 61 -- 6.2.2.1 The Program Dashboard 61 -- 6.2.2.2 The Crowd Control Navbar 63 -- Summary 63 -- Submissions 63 -- Researchers 64 -- Rewards 65 -- Insights Dashboard 65 -- Reports 66 -- 6.2.3 Advanced Program Configuration and Modification 66 -- 6.2.3.1 Program Brief 66 -- 6.2.3.2 Scope and Rewards 67 -- 6.2.3.3 Integrations 72 -- 6.2.3.4 Announcements 73 -- 6.2.3.5 Manage Team 74 -- 6.2.3.6 Submissions 75 -- 6.2.4 Profile Settings 76 -- 6.2.4.1 The Profile and Account 78 -- 6.2.4.2 Security 78 -- 6.2.4.3 Notification Settings 79 -- 6.2.4.4 API Credentials 80 -- 6.2.5 Enterprise "Profile" Settings 81 -- 6.2.5.1 Management and Configuration 81 -- 6.2.5.2 Organization Details 81 -- 6.2.5.3 Team Members 81 -- 6.2.5.4 Targets 81 -- 6.2.5.5 Authentication 81 -- 6.2.5.6 Domains 82 -- 6.2.5.7 Accounting 83 -- 6.3 HackerOne 84 -- 6.3.1 Program Settings 85 -- 6.3.1.1 General 85 -- 6.3.1.2 Information 86 -- 6.3.1.3 Product Edition 86 -- 6.3.1.4 Authentication 87 -- 6.3.1.5 Verified Domains 88 -- 6.3.1.6 Credential Management 89 -- 6.3.1.7 Group Management 89 -- 6.3.1.8 User Management 90 -- 6.3.1.9 Audit Log 91 -- 6.3.2 Billing 92 -- 6.3.2.1 Overview 92 -- 6.3.2.2 Credit Card 92 -- 6.3.2.3 Prepayment 92 -- 6.3.3 Program 93 -- 6.3.3.1 Policy 93 -- 6.3.3.2 Scope 93 -- 6.3.3.3 Submit Report Form 95 -- 6.3.3.4 Response Targets 96 -- 6.3.3.5 Metrics Display 97 -- 6.3.3.6 Email Notifications 97 -- 6.3.3.7 Inbox Views 98 -- 6.3.3.8 Disclosure 98 -- 6.3.3.9 Custom Fields 98 -- 6.3.3.10 Invitations 99 -- 6.3.3.11 Submission 100 -- 6.3.3.12 Message Hackers 101 -- 6.3.3.13 Email Forwarding 102 -- 6.3.3.14 Embedded Submission Form 102 -- 6.3.3.15 Bounties 103 -- 6.3.3.16 Swag 103 -- 6.3.3.17 Common Responses 104 -- 6.3.3.18 Triggers 106 -- 6.3.3.19 Integrations 107 -- 6.3.3.20 API 107 -- 6.3.3.21 Hackbot 107 -- 6.3.3.22 Export Reports 108 -- 6.3.3.23 Profile Settings 108 -- 6.3.4 Inbox 108 -- 6.3.4.1 Report Details 109 -- 6.3.4.2 Timeline 109 -- 6.4 Summary 110 -- Part 4 Vulnerability Reports and Disclosure 111 -- 7 Triage and Bug Management 113 -- 7.1 Understanding Triage 113 -- 7.1.1 Validation 113 -- 7.1.2 Lessons Learned 115 -- 7.1.3 Vulnerability Mishaps 115 -- 7.1.4 Managed Services 115 -- 7.1.5 Self-service 116 -- 7.2 Bug Management 116 -- 7.2.1 Vulnerability Priority 116 -- 7.2.2 Vulnerability Examples 117 -- 7.2.2.1 Reflected XSS on a login portal 117 -- Report and Triage 117 -- Validation 117 -- 7.2.2.2 Open redirect vulnerability 117 -- Report and Triage 117 -- Validation 118 -- 7.2.2.3 Leaked internal Structured Query Language (SQL) server credentials 118 -- Report and Triage 118 -- Validation 118 -- 7.3 Answers 118 -- 7.3.1 Vulnerability Rating-test Summary 119 -- 7.3.1.1 Reflected XSS in a login portal 118 -- 7.3.1.2 Open redirect vulnerability 118 -- 7.3.1.3 Leaked internal SQL server credentials 118 -- 7.3.2 Complexity vs Rating 119 -- 7.3.3 Projected Ratings 120 -- 7.3.4 Ticketing and Internal SLA 120 -- 7.3.4.1 Creating Tickets 120 -- 8 Vulnerability Disclosure Information 123 -- 8.1 Understanding Public Disclosure 123 -- 8.1.1 Making the Decision 123 -- 8.1.1.1 Private Programs 123 -- The Bottom Line 124 -- 8.1.1.2 Public Programs 125 -- The Bottom Line 126 -- 8.2 CVE Responsibility 126 -- 8.2.1 What are CVEs? 126 -- 8.2.2 Program Manager Responsibilities 126 -- 8.2.3 Hardware CVEs 126 -- 8.2.4 Software and Product CVEs 128 -- 8.2.5 Third-party CVEs 128 -- 8.3 Submission Options 130 -- 8.3.1 In-house Submissions 130 -- 8.3.2 Program Managed Submissions and Hands-off Submissions 130 -- 8.3.2.1 Program Managed Submissions 130 -- 8.3.2.2 Hands-off Submissions 131 -- Part 5 Internal and External Communication 1 ...
"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 nor given the opportunity to shine. Throughout history, hacking has been a word that scares the public and creates waves of fear inside of 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 US Dollars to pick a physical lock. (https://www.itspmagazine.com/itsp-chronicles/history-and-interesting-facts-about-bug-bounties-an-appsec-usa-2017-panel-recap)."--
9781119782544 1119782546 9781119782568 1119782562 9781119782537 1119782538
10.1002/9781119782568 doi
9635028 IEEE
2021020795
Business enterprises--Computer networks--Security measures.
Penetration testing (Computer security)
Cyberspace--Security measures.
Cyberspace--Security measures.
Business enterprises--Computer networks--Security measures.
Penetration testing (Computer security)
Electronic books.
HD30.38 / .J34 2022
658.4/78
Corporate cybersecurity : identifying risks and the bug bounty program / John Jackson. - 1 online resource : color illustrations
Includes bibliographical references and index.
Foreword xiii -- Acknowledgments xv -- Part 1 Bug Bounty Overview 1 -- 1 The Evolution of Bug Bounty Programs 3 -- 1.1 Making History 3 -- 1.2 Conservative Blockers 4 -- 1.3 Increased Threat Actor Activity 4 -- 1.4 Security Researcher Scams 5 -- 1.5 Applications Are a Small Consideration 5 -- 1.6 Enormous Budgetary Requirements 5 -- 1.7 Other Security Tooling as a Priority 6 -- 1.8 Vulnerability Disclosure Programs vs Bug Bounty Programs 6 -- 1.8.1 Vulnerability Disclosure Programs 6 -- 1.8.2 Bug Bounty Programs 7 -- 1.9 Program Managers 7 -- 1.10 The Law 7 -- 1.11 Redefining Security Research 8 -- 1.12 Taking Action 8 -- 1.12.1 Get to Know Security Researchers 9 -- 1.12.2 Fair and Just Resolution 9 -- 1.12.3 Managing Disclosure 9 -- 1.12.4 Corrections 9 -- 1.12.5 Specific Community Involvement 9 -- Part 2 Evaluating Programs 11 -- 2 Assessing Current Vulnerability Management Processes 13 -- 2.1 Who Runs a Bug Bounty Program? 13 -- 2.2 Determining Security Posture 13 -- 2.3 Management 14 -- 2.3.1 Software Engineering Teams 14 -- 2.3.2 Security Departments (Security Operations, Fraud Prevention, Governance/Risk/Compliance, Edge Controls, Vulnerability Management, Endpoint Detection, and Response) 14 -- 2.3.3 Infrastructure Teams 14 -- 2.3.4 Legal Department 14 -- 2.3.5 Communications Team 14 -- 2.4 Important Questions 15 -- 2.5 Software Engineering 15 -- 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? 15 -- 2.5.2 How Effective Are Current Communication Processes? Will Vulnerabilities Be Quickly Resolved If Brought to Their Attention? 15 -- 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? 16 -- 2.6 Security Departments 16 -- 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? 16 -- 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? 16 -- 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? 17 -- 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? 17 -- 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? 17 -- 2.7 Infrastructure Teams 17 -- 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? 17 -- 2.7.2 Is There Effective Communication between Infrastructure, Vulnerability Management, Security Operations, and Endpoint Detection and Response? 18 -- 2.8 Legal Department 18 -- 2.8.1 How Well Refined is the Relationship between the Application Security Team and the Legal Department? 18 -- 2.8.2 What Criteria Are/Will Be Set Out for the Escalation of Issues? 18 -- 2.8.3 Does the Legal Department Understand the Necessity of Bug Bounty Program Management? 18 -- 2.9 Communications Team 18 -- 2.9.1 Has the Communications Team Dealt with Security Researchers Before? is the Importance Understood? 18 -- 2.9.2 Was the Communications Team Informed of Bug Bounty Program Expectations? 19 -- 2.10 Engineers 19 -- 2.11 Program Readiness 19 -- 3 Evaluating Program Operations 21 -- 3.1 One Size Does Not Fit All 21 -- 3.2 Realistic Program Scenarios 21 -- 3.3 Ad Hoc Program 22 -- 3.4 Note 24 -- 3.5 Applied Knowledge 24 -- 3.5.1 Applied Knowledge #1 24 -- 3.5.1.1 Private Programs 25 -- 3.5.2 Applied Knowledge #2 25 -- 3.5.2.1 Public Programs 25 -- 3.5.3 Applied Knowledge #3 26 -- 3.5.3.1 Hybrid Models 26 -- 3.6 Crowdsourced Platforms 27 -- 3.7 Platform Pricing and Services 28 -- 3.8 Managed Services 28 -- 3.9 Opting Out of Managed Services 29 -- 3.10 On-demand Penetration Tests 29 -- Part 3 Program Setup 31 -- 4 Defining Program Scope and Bounties 33 -- 4.1 What is a Bounty? 33 -- 4.2 Understanding Scope 33 -- 4.3 How to Create Scope 34 -- 4.3.1 Models 34 -- 4.4 Understanding Wildcards 34 -- 4.4.1 Subdomain 35 -- 4.4.2 Domain 35 -- 4.4.3 Specific Domain Path or Specific Subdomain Path 35 -- 4.5 Determining Asset Allocation 36 -- 4.6 Asset Risk 37 -- 4.7 Understanding Out of Scope 37 -- 4.8 Vulnerability Types 38 -- 4.8.1 Denial of Service (DOS) or Distributed Denial of Service (DDoS) Attacks 38 -- 4.8.2 Social Engineering Attacks 38 -- 4.8.3 Brute Force or Rate Limiting 38 -- 4.8.4 Account and Email Enumeration 38 -- 4.8.5 Self-XSS 39 -- 4.8.6 Clickjacking 39 -- 4.8.7 Miscellaneous 39 -- 4.9 When is an Asset Really Out of Scope? 39 -- 4.10 The House Wins - Or Does It? 40 -- 4.11 Fair Judgment on Bounties 42 -- 4.12 Post-mortem 43 -- 4.13 Awareness and Reputational Damage 43 -- 4.14 Putting It All Together 44 -- 4.15 Bug Bounty Payments 44 -- 4.15.1 Determining Payments 45 -- 4.15.2 Bonus Payments 46 -- 4.15.3 Nonmonetary Rewards 46 -- 5 Understanding Safe Harbor and Service Level Agreements 49 -- 5.1 What is "Safe Harbor"? 49 -- 5.1.1 The Reality of Safe Harbor 49 -- 5.1.2 Fear and Reluctance 49 -- 5.1.3 Writing Safe Harbor Agreements 50 -- 5.1.4 Example Safe Harbor Agreement 50 -- 5.2 Retaliation against a Rogue Researcher (Cybercriminal or Threat/Bad Actor) 51 -- 5.3 Service Level Agreements (SLAs) 52 -- 5.3.1 Resolution Times 53 -- 5.3.2 Triage Times 53 -- 6 Program Configuration 55 -- 6.1 Understanding Options 55 -- 6.2 Bugcrowd 55 -- 6.2.1 Creating the Program 55 -- 6.2.2 Program Overview 61 -- 6.2.2.1 The Program Dashboard 61 -- 6.2.2.2 The Crowd Control Navbar 63 -- Summary 63 -- Submissions 63 -- Researchers 64 -- Rewards 65 -- Insights Dashboard 65 -- Reports 66 -- 6.2.3 Advanced Program Configuration and Modification 66 -- 6.2.3.1 Program Brief 66 -- 6.2.3.2 Scope and Rewards 67 -- 6.2.3.3 Integrations 72 -- 6.2.3.4 Announcements 73 -- 6.2.3.5 Manage Team 74 -- 6.2.3.6 Submissions 75 -- 6.2.4 Profile Settings 76 -- 6.2.4.1 The Profile and Account 78 -- 6.2.4.2 Security 78 -- 6.2.4.3 Notification Settings 79 -- 6.2.4.4 API Credentials 80 -- 6.2.5 Enterprise "Profile" Settings 81 -- 6.2.5.1 Management and Configuration 81 -- 6.2.5.2 Organization Details 81 -- 6.2.5.3 Team Members 81 -- 6.2.5.4 Targets 81 -- 6.2.5.5 Authentication 81 -- 6.2.5.6 Domains 82 -- 6.2.5.7 Accounting 83 -- 6.3 HackerOne 84 -- 6.3.1 Program Settings 85 -- 6.3.1.1 General 85 -- 6.3.1.2 Information 86 -- 6.3.1.3 Product Edition 86 -- 6.3.1.4 Authentication 87 -- 6.3.1.5 Verified Domains 88 -- 6.3.1.6 Credential Management 89 -- 6.3.1.7 Group Management 89 -- 6.3.1.8 User Management 90 -- 6.3.1.9 Audit Log 91 -- 6.3.2 Billing 92 -- 6.3.2.1 Overview 92 -- 6.3.2.2 Credit Card 92 -- 6.3.2.3 Prepayment 92 -- 6.3.3 Program 93 -- 6.3.3.1 Policy 93 -- 6.3.3.2 Scope 93 -- 6.3.3.3 Submit Report Form 95 -- 6.3.3.4 Response Targets 96 -- 6.3.3.5 Metrics Display 97 -- 6.3.3.6 Email Notifications 97 -- 6.3.3.7 Inbox Views 98 -- 6.3.3.8 Disclosure 98 -- 6.3.3.9 Custom Fields 98 -- 6.3.3.10 Invitations 99 -- 6.3.3.11 Submission 100 -- 6.3.3.12 Message Hackers 101 -- 6.3.3.13 Email Forwarding 102 -- 6.3.3.14 Embedded Submission Form 102 -- 6.3.3.15 Bounties 103 -- 6.3.3.16 Swag 103 -- 6.3.3.17 Common Responses 104 -- 6.3.3.18 Triggers 106 -- 6.3.3.19 Integrations 107 -- 6.3.3.20 API 107 -- 6.3.3.21 Hackbot 107 -- 6.3.3.22 Export Reports 108 -- 6.3.3.23 Profile Settings 108 -- 6.3.4 Inbox 108 -- 6.3.4.1 Report Details 109 -- 6.3.4.2 Timeline 109 -- 6.4 Summary 110 -- Part 4 Vulnerability Reports and Disclosure 111 -- 7 Triage and Bug Management 113 -- 7.1 Understanding Triage 113 -- 7.1.1 Validation 113 -- 7.1.2 Lessons Learned 115 -- 7.1.3 Vulnerability Mishaps 115 -- 7.1.4 Managed Services 115 -- 7.1.5 Self-service 116 -- 7.2 Bug Management 116 -- 7.2.1 Vulnerability Priority 116 -- 7.2.2 Vulnerability Examples 117 -- 7.2.2.1 Reflected XSS on a login portal 117 -- Report and Triage 117 -- Validation 117 -- 7.2.2.2 Open redirect vulnerability 117 -- Report and Triage 117 -- Validation 118 -- 7.2.2.3 Leaked internal Structured Query Language (SQL) server credentials 118 -- Report and Triage 118 -- Validation 118 -- 7.3 Answers 118 -- 7.3.1 Vulnerability Rating-test Summary 119 -- 7.3.1.1 Reflected XSS in a login portal 118 -- 7.3.1.2 Open redirect vulnerability 118 -- 7.3.1.3 Leaked internal SQL server credentials 118 -- 7.3.2 Complexity vs Rating 119 -- 7.3.3 Projected Ratings 120 -- 7.3.4 Ticketing and Internal SLA 120 -- 7.3.4.1 Creating Tickets 120 -- 8 Vulnerability Disclosure Information 123 -- 8.1 Understanding Public Disclosure 123 -- 8.1.1 Making the Decision 123 -- 8.1.1.1 Private Programs 123 -- The Bottom Line 124 -- 8.1.1.2 Public Programs 125 -- The Bottom Line 126 -- 8.2 CVE Responsibility 126 -- 8.2.1 What are CVEs? 126 -- 8.2.2 Program Manager Responsibilities 126 -- 8.2.3 Hardware CVEs 126 -- 8.2.4 Software and Product CVEs 128 -- 8.2.5 Third-party CVEs 128 -- 8.3 Submission Options 130 -- 8.3.1 In-house Submissions 130 -- 8.3.2 Program Managed Submissions and Hands-off Submissions 130 -- 8.3.2.1 Program Managed Submissions 130 -- 8.3.2.2 Hands-off Submissions 131 -- Part 5 Internal and External Communication 1 ...
"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 nor given the opportunity to shine. Throughout history, hacking has been a word that scares the public and creates waves of fear inside of 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 US Dollars to pick a physical lock. (https://www.itspmagazine.com/itsp-chronicles/history-and-interesting-facts-about-bug-bounties-an-appsec-usa-2017-panel-recap)."--
9781119782544 1119782546 9781119782568 1119782562 9781119782537 1119782538
10.1002/9781119782568 doi
9635028 IEEE
2021020795
Business enterprises--Computer networks--Security measures.
Penetration testing (Computer security)
Cyberspace--Security measures.
Cyberspace--Security measures.
Business enterprises--Computer networks--Security measures.
Penetration testing (Computer security)
Electronic books.
HD30.38 / .J34 2022
658.4/78