Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It seems to me that trust is a more subtle metric than on and off. If nothing else, if you're trying to keep a secret it behooves you to tell as few people as possible, even if you trust them all.

There are lots and lots of security team pgp keys out there. Clearly not every vendor has a secure process, but certainly the people who make up the volume of the reported incidents do. Vendors who do have them might be worse off if people started using this scheme.

cisco: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA291...

google: https://services.google.com/corporate/publickey.txt

microsoft: http://www.microsoft.com/technet/security/bulletin/pgp.mspx



I am trying to imagine the response you'd get from, say, a message oriented middleware vendor without a dedicated security contact, upon sending them a message encrypted in such a way that only their SSL certificate could be used to decrypt it.

It's funny to think about it as "mass hysteria!"; the people who care about these reports are on the dev team and can safely be expected not to really understand what an SSL cert is, let alone have access to it or the patience to use OpenSSL's command line.

But more realistically what's going to happen is that the message will get chucked entirely.


That's fine, they can ignore it since ultimately it's not about them but about everyone else. People then evaluating similar products can go look and see how they compare on their security track record. Once that happens I imagine they'll figure it out.

Also, I'm probably imagining a few open source tools to make this easy to work with. The shell script is just a little test case to prove you can do one part of it. There'd need to be a few more things before everyone can actually play the game.


If you want to compare security track records, you have any of several huge vulnerability databases to consult; Secunia is the one that seems to have done the best job of SEO.

But there are two huge problems with this approach.

First, nobody cares. Nobody really evaluates products based on "security track records". If I did a "Month of Cisco Bugs", do you think any company in the world with more than 500 employees would switch to Juniper or Astaro? No, they would not.

Second, vulnerability track records don't directly measure product security, or even product security team responsiveness. They measure researcher interest and researcher effectiveness. Microsoft, Adobe, and Apple are deluged with reports, because researchers are incented to target them. It also tends to take (say) Microsoft longer to fix things than J-Random-Vendor; QA is harder, releases are more expensive, and more security issues are on the plate to begin with.


> First, nobody cares. Can this really be true? If so, why do you have a job?


Companies will select products with terrible security track records, then pay us to come in and beat up the vendor.


Those are three mega-corporations, and not small businesses though. Most places I've worked with outsource the software, web server administration, and SSL administration all to a single client, and don't necessarily pay for a security team to maintain GPG keys, but just for maintenance and ongoing development.

Allowing the web team to securely receive a vulnerability report using infrastructure they've already built opens up a secure reporting process to thousands of smaller businesses.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: