Security response isn’t just about the “sexy” analysis of vulnerabilities, reverse-engineering of malware, and so on… it’s probably mostly about getting the basics right.
Every morning, I forward all of the PayPal phishing scams I receive to PhishTank, Netcraft, and Spoof@Paypal. Today, I took a closer look at the response I got to the last of these:
PayPal was carefully instructing me to visit their site using an unsecure HTTP url. While plenty of sites make this mistake, PayPal has a large security team and they should certainly know better… especially when the email is from their security team!
I dutifully dashed off a note to security@paypal, suggesting that they stop giving out bad security advice. Only to learn that they’ve decided not to follow an obvious best practice, instead auto-replying to say that they don’t accept email at that address and suggesting I follow some convoluted process on their website:
Gah. Okay, fine, I’ll just Google around to find out how to report a security vulnerability to PayPal. I find a very nice “Reporting Security Issues” page, which contains a LOT more text than I’d like to read, but hey, it’s a bug bounty program too so I guess they need lots of legalese. Okay, so I’ll just click the link to register:
Except that, oops… this link doesn’t go anywhere, automatically redirecting to PayPal’s homepage.
If you can’t manage your own security response process, you should seriously look into getting an account at HackerOne; researchers are far less likely to get fed up when the process is clear, simple, and well-managed.
-Eric Lawrence
text/plain 