Presentation delivered by Krystian Szybis on OWASP Poland Day 2018.

1. Responsible Disclosure in a bank
Krystian Szybis
W a r s a w , 1 0 . 1 0 . 2 0 1 8
OWASP
Poland Day 2018

2. Agenda
• How program was developed, choices made
• Policies
• What we’ve found
• Drivers for improvement
I won’t speak about vulnerabilities or get into specific cases
Views expressed herein are mine and may not reflect those of my
employer or other employees.

3. Responsible Disclosure
„In computer security or elsewhere, responsible disclosure is a
vulnerability disclosure model in which a vulnerability or issue is
disclosed only after a period of time that allows for the
vulnerability or issue to be patched or mended.”
Wikipedia, Responsible Disclosure
As a company we’re allowing others to pentest our IT estate in
line with set policy.

4. Complementary service
Programs allowing vulnerabilities from external researchers are
complementary „defense in depth”:
• Vulnerability Scanning
• Penetration Testing (project, ongoing assurance)
• Threat Hunting
• Red Teaming
• Security Assessment

5. Preparation
We thought everyone had a program like that so we’ve decided to
review the landscape:
• Take list of 50 biggest banks
• Review their programs
• And come back with nothing...

6. Or maybe
Of TOP 50 biggest banks:
• 5 have some type of bounty/disclousure program (2 US, 3
Dutch)
• 2 of which don’t give anything
• 3 do give out rewards
We’ve not counted: private bug bounty programs, ones wrongly
translated from non-English pages.

7. Approach
Similar to establishing any other IT process:
• getting buy-in from business/technology owners as well as
Communications and Legal
• Defining approach
• Later building up capability/process (from adhoc to
defined/managed)
• dedicated vs virtual teams (1st , 2nd line)
• establishing contacts and escalation paths
• establishing reporting
• creating and establishing policy

8. C h o i c e s
• Type of program (vs bug bounty)
• Own program rather than 3rd party managed
• Coverage (across IP range and URL domains)
• Rewards (wall of fame, letters of appreciation to everyone or
top)
• Scope: URL’s, IP’s address ranges, type of attacks

9. What we've found
• Steady flow of findings per month, peak at EOY
• Pentesters motivated by recognition
• Became focal point of communication with Security for
Researches and other bank security teams
• Brings Security closer to the Business (and Communications
and Legal ;-)

10. About the vulnerabilities
• Over 100 vulnerabilities in a year
• Some great (really!), some good, some informative, miniscule
number of false positives
• Most submissions contained required information
• No customer service impact

11. Everyday challenges
• Locating and persuading owners of applications/technology
(including owners of technical debt)
• Findings already reported
• Mitigation time
• That good but out of scope finding
• Social media exposure
• Enough information to reproduce a findings

12. Lessons for us
• Benchmark policy periodically
• Updating process as we find better ways
• Updating policy based on data
• Use form for data submission,
• When push comes to shove we will take correct action
immediately
• Does not solve funding issues owners have, but helps prioritise
vulnerability migitation
• Will result in review of other work/process to check if/why
vulnerability was missed

13. Net result for organisation
• Less vulnerabilities on the perimeter
• Established contact to good pentesters in community
• Tried and tested process for dealing with vulnerabilities
• Great input to thematic reviews
• End result -> complimentary service

14. What we ask testers for
• Staying within the policy
• Good information, PoC (optional) and impact
• Patience (a lot of it)
• Good findings
• Report to us only
• Be mindful there could be a reason others are not doing it

15. Appendix - Out of scope

16. Any questions?
Krystian Szybis
krystianantoni@gmail.com
<yeah right >