I'm usually the first person here to jump to 37s' defense. I know some of their people, they're hometown heroes, and I use and like their products.
This is hard to defend, guys.
It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them.
If you're selling accounts on a web app, you need:
* A security page
* With a PGP key
* And an email contact
* of someone who will write back
* who knows what a security vulnerability is
* and who will write back quickly.
That's it. Do that, and you're not a punch line. If someone dumps zero-day about you onto Twitter, you're already two steps ahead in the PR war, because you had a reasonable process, and the researcher ignored it.
Bonus points --- things that are trivial to do, but that nobody's even asking you to do:
* You can assign special issue numbers to vulnerabilities, to make the researcher feel like an XSS disclosure isn't the same thing as a bug in your online help.
* You can thank researchers privately, and let them know that you'd really like them to keep disclosing thing to you --- you could even give them (wait for it) a phone number.
* You can do what every vendor with a real security team does, and keep a public web page thanking people who have discreetly disclosed vulnerabilities to you.
You're exactly right, Tom. We dropped the ball on having the security@37signals.com account setup before this issue so reports went to our normal support team. A specific email address with an associated GPG key has since been added to our security page and there is a person who is tasked to respond. This was added on August 23rd when the problems with the process around the previous XSS problem were discovered.
I never used to have travel insurance but after my first intercontinental flight my suite-case broke and I learned the importance of having one.
In a perfect world your support team would be able to distinguish between someone rambling about bytes and an actual security issue. That's hard without a lot of technical knowledge.
I believe that's why the Rails security team responded rather quickly and 37 Signals support team didn't. I'm sure they will do better in the future.
The problem isn't that 37S tech support doesn't know how UTF-8 works. The problem was that security reports were routed to tech support in the first place. Again, the solution to this problem is a single web page with just a couple pieces of information on it.
It would be easy to defend if being an airline passenger is even vaguely analogous to being an application service provider who charges money and promises you your data is secure -
This is hard to defend, guys.
It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them.
If you're selling accounts on a web app, you need:
* A security page * With a PGP key * And an email contact * of someone who will write back * who knows what a security vulnerability is * and who will write back quickly.
That's it. Do that, and you're not a punch line. If someone dumps zero-day about you onto Twitter, you're already two steps ahead in the PR war, because you had a reasonable process, and the researcher ignored it.
Bonus points --- things that are trivial to do, but that nobody's even asking you to do:
* You can assign special issue numbers to vulnerabilities, to make the researcher feel like an XSS disclosure isn't the same thing as a bug in your online help.
* You can thank researchers privately, and let them know that you'd really like them to keep disclosing thing to you --- you could even give them (wait for it) a phone number.
* You can do what every vendor with a real security team does, and keep a public web page thanking people who have discreetly disclosed vulnerabilities to you.