1 | © 2019 Palo Alto Networks. All Rights Reserved. Ariel Zelivansky Security Research Manager, Palo Alto Networks Security Disclosure Policies in the Cloud Native Landscape

No content

In the beginning • Two security researchers found a critical security issue with software used to process personal details and financial activity • Used by many casinos globally • They attempted to follow responsible disclosure • Contacted the company through emails • They were ignored • Other attempts, including leaving info on their FTP server, were ignored • They tweeted about the issue to attract public attention

The FBI Cyber Division got involved • The FBI played the role of a “mediator” • The company had to listen to the FBI • The company finally agrees to fix the issue, as well as pay the researchers for their work • That was the last time they heard from the company • The issue was not resolved

How not to handle a disclosure • After a while, the researchers visited a conference the company participated in • After introducing himself, one of the researchers was violently attacked by a company executive, ripping off his attendee badge in the process • The last report mentions that legal processes are now taking place • What went wrong?

What went wrong • No disclosure policy • No security contact details • No acknowledgement of the issue • No response • Lying regarding payout • Assault • Not fixing the issue

Types of disclosures • There is a long time debate in the security community regarding disclosures • Vulnerability disclosure policies commonly divided into three 7 | © 2019 Palo Alto Networks. All Rights Reserved. 1 2 3 Non Disclosure Full Disclosure Responsible Disclosure

Responsible Disclosure • Also known as Coordinated / Private Disclosure • There is no standard definition on the process, but it’s generally agreed that the researcher should • Discreetly reach the software vendor with the details of the issue • Allow the vendor to acknowledge the flaw, develop a fix, test it, and publish a patch within a reasonable timeline • Publish the issue details to the public • Some vendors heavily disencourage this • Most vendors agree to issuing some identifier for a security issue (e.g. CVE) • If the vendor does not respond to contact or fails to acknowledge the issue • The researcher has no choice but to publish the details to inform users (as in full disclosure) 8 | © 2019 Palo Alto Networks. All Rights Reserved.

Responsible Disclosure • Since we are all [white hat | ethical | well-meaning] hackers • Responsible disclosure is the way to go • Not unanimously supported • Many researchers have stories of negative experiences with vendors • E.g. legal threats, radio silence, downplay or dismissal of the issues • Then why not skip to public disclosure? • Unpatched one-days = golden mine for black hats • Real damage to companies or individuals 9 | © 2019 Palo Alto Networks. All Rights Reserved.

Motives • Let’s try to think of common motives for the parties involved in a disclosure 10 | © 2019 Palo Alto Networks. All Rights Reserved. • Improve security of product • Avoid one day exploits and attacks • Avoid bad publicity • Personal interest (e.g. self or company using the product) • Reputation / fame / resume • Money (works best with bug bounties) • Good citizenship Vendor Reporter

Why do disclosures go wrong? • Misunderstanding • Why is this hacker threatening us? Who is he working for? Call the police! • No internal policy • Who processes the report, who writes the fix, who verifies, who backport, who issues the notification • E.g. security report lands in non-engineering team and gets lost (or mishandled) • Misconception • Fear of admitting mistake (both at engineer level and company level) 11 | © 2019 Palo Alto Networks. All Rights Reserved.

Why do disclosures go wrong? • Miscommunication • Knowledge gap • Report is not clear enough 12 | © 2019 Palo Alto Networks. All Rights Reserved.

What can vendors do? ● Prepare an internal process for handling third-party security reports ○ AKA Vulnerability Management Program ○ Designate person or team (incident response team/CSIRT/PSIRT) to own all handling of reports and delegate to engineers ○ Define process for delivering a fix, backporting supported versions and notifying users of the vulnerability ■ Having a list of known vulnerabilities is a great practice ■ Use CVE IDs ■ Mailing list for security announcements ■ Common mistake: releasing the fix in the publicly tracked repository before announcement 13 | © 2019 Palo Alto Networks. All Rights Reserved.

What can vendors do? ● Define communication process with the reporter ○ Acknowledge first ○ Keep the reporter updated as much as possible ○ Coordinate fix time and announcement 14 | © 2019 Palo Alto Networks. All Rights Reserved.

What can vendors do? ● Publish disclosure guidelines for researchers to follow ○ For open source projects, publish SECURITY.MD ○ What is a right way for researchers to contact you privately? ■ Publicly tracked issues are not an option! ■ Github has a new feature to allow private security issues ○ What can the reporter expect when contacting you? ○ Embargo policy ■ Define deadlines ○ Follow CVD (CERT Guide to Coordinated Vulnerability Disclosure) for reference 15 | © 2019 Palo Alto Networks. All Rights Reserved.

What can vendors do? • Incentive researchers to responsibly disclosure issues with monetary and non-monetary rewards • E.g. cash, swag, hall-of-fame acknowledgement 16 | © 2019 Palo Alto Networks. All Rights Reserved.

Current state of cloud native projects • Managing disclosures becomes a multitude harder for open source projects with many contributors • No standard • Policies/guidelines range between highly detailed to non-existent • In fact, too many CNCF projects have no security point of contact • On the positive side, many of the major CNCF projects have a clear policy and security teams 17 | © 2019 Palo Alto Networks. All Rights Reserved.

Current state of cloud native projects • 18 | © 2019 Palo Alto Networks. All Rights Reserved.

Current state of cloud native projects 19 | © 2019 Palo Alto Networks. All Rights Reserved.

Disclosure experiences with CNCF projects ● Mixed results from both ends ● Example of a simple disclosure that went positively ○ Researcher Aviv Sasson found a DoS issue with NATS server ○ Shared advisory through security email ○ NATS project manager responds immediately ○ A fix is developed and a new version is released in two weeks ○ NATS team ships us complimentary T-Shirts and a thank you note

Tips for reporting security issues 21 | © 2019 Palo Alto Networks. All Rights Reserved. You’ve found a zero-day vulnerability! What's next? • Create a PoC • This can highly help engineers understand the impact / prevent downplay • Be respectful and understanding • Get a CVE • MITRE is the head organization responsible for assigning CVE IDs. They have a list of vendors that are given permission to assign CVEs for their own software (called CNAs) • If the vendor is not a CNA, consider reserving a CVE through MITRE • Contact privately • Sharing issue on a public tracker is equivalent to FD • Define deadlines • But be considerate

Summary Define your disclosure process Making life easier for researchers is valuable for your security Understand the difficulties of the vendor But be determinant when needed We can define a standard Make life easier for all parties Reporter Vendor Cloud Native

Ariel Zelivansky azelivansky@paloaltonetworks.com Thank you