Оглавление
John Jackson. Corporate Cybersecurity
Corporate Cybersecurity. Identifying Risks and the Bug Bounty Program
Contents
List of Illustrations
Guide
Pages
Foreword
Acknowledgments
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
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
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
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.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
Evaluating Logic and Impact
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
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
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
WILEY END USER LICENSE AGREEMENT
