After "what's the best new way I can find people who can write code fast and who will have a talent for finding security vulnerabilities", this is the issue that occupies all my cycles.
Like most firms working in security, our bread is buttered by large companies, who are bidding very high numbers for (in our case) appsec testing.
But by number, a conspicuously large fraction of our customers are mid-late stage startups, and taken as a whole, we talk to more startups than any other kind of business.
Startups are particularly exposed to the security market problem. They have very little infrastructure and they are spending most of their cycles just trying to stay in business and find traction. At the same time, they've managed to outsource all of the technical requirements of their businesses except the part which bears the highest security risk, which is their custom code.
What can we do about this? I talk to YC companies all the time, and it's frustrating. I am always good for a phone call and we'll even poke at startup apps pro-bono (we love working with startups) but that help has to get in line behind our paying clients, all of whom can be counted on to appear from behind a dark corner at any moment and swallow 2-3 weeks of our time whole.
I am seriously all ears for ideas on how security people like iSEC and Matasano can help early-stage startups without invoicing half+ of those startups last funding round.
I have always assumed this is about the editing of choices - there is a vast world of OSS choices. And I cannot keep up.
I would happily buy Matasano-branded cloud servers that talked the AWS/OpenStack API (ie were actually run there) but were imaged off one baseline that was Thomas-Approved.
I dont trust other people's Chef or Puppet recipies to install nginx for me. I would trust yours.
That means I would start writing my application on your branded stack. If that means I get to only use vi on OpenBSD then - hey there is real badge value in it still:-)
And if actually I can only deploy my code to your secure server via a CI process, all the better.
Having a secure baseline setup is obviously important. However the point that tptacek seems to be making is that most of the security risk of startups comes from the custom code that they write.
You can have the most hardened openBSD setup in the world but if you write a web app that runs shell commands based on user input and you don't validate well enough you might be in for a bad time.
Is that really the cause of most security penetrations?
Would love to hear from security researchers on this.
My guess is a known vulnerability in a third party server is far far more likely to get you compromised (think Wordpress)
Than unsantised SQL because one can scan and attack Wordpress automatically but need to manually craft an attack against my specific app
Anyway. It's not really how to make startups less vulnerable, it's how to sell tptaceks expertise at a greater scale. If there is overlap good
It's not really that hard to run Wordpress securely enough to deal with the sorts of automated attacks that target Wordpress sites.
As I understand it, the danger in custom code is not just that it will be architected insecurely, but that simple oversight can create a vulnerability that won't be found until it is too late. If only one site is running your code, then that site will go down if a vulnerability is found.
One advantage of running Wordpress is that Automattic is leveraging a network of millions of honeypots (the other bozos running Wordpress) to find new vulnerabilities fast. You have keep on top of the patches though.
They are both major causes of intrusions, but if I was running a SaaS shop, I'd be more worried about vulnerabilities in my own code than I would about vulnerabilities in my operating system. Modulo: don't run Wordpress.
With my developer hat on, it's not so much my code as it is the poor choices frameworks and similar "everyone does it this way" tilutorials make.
It's too easy to follow the tutorial and have a default of stuffing everything into a cookie, overly complex orm s and oh you know the rest - and that's before I have written my facebookforfish code
I am not sure where that problem fits in - but it feels like the same issue as we urging the OS or securing my postfix. The layer beneath my code is one I want to be secure and be simple. Help with that and I will use your layer choices.
Probably true, but you don't need to hire Matasano to tell you to patch your Wordpress. If you follow reasonable security practices then the low end automated scanning attacks tend to go away.
Security of custom code is really another vector altogether and an expensive one that suddenly becomes important when your stuff gets popular enough to warrant bespoke attacks.
I guess the problem startups may have is that they have lots of users (therefor lots of incentive to attack) before they necessarily have the spare change to pay for professional audits of their custom code.
There was a guy in the Pinboard Prosperity Cloud who was working on best-in-class secure VMs. I haven't seen a follow-up but it's only been several weeks.
Actually having thought about this, it's commoditising your junior staff.
I saw a video of you explaining how to break cookies that have stored password-equivalents in encrypted apps (with iirr fixed block cipher dictionary attack(?)). The throw away comment was although it looked like magic when shown to clients it was simple and appsec researchers had to write their own as a rite of passage.
So raise the bar on every appsec company out there by making
An app / site / whatever that is really simple to do that attack on ones own site.
We all should do nmap to check we have locked out ports down - you want it to be known We should run Thomas-map to check our cookies, etc
The specifics are less important than I should be able to read your notes and discover the same vulnerabilities your juniors could on my own app - be aide having found them I probably don't know how to fix them but am damn sure who I will ask.
Obviously you've spent more time considering this, but on the off chance it's helpful:
1. Take payment in some other form. Get creative.
2. Link the infosec to the startup's revenue. In other words, make it something we can sell. Applicable within specific domains. For example, I'd buy a modern CRM solution I had infosec confidence in, but until then we're sticking with our self hosted install of RT.
3. Expand security code review to be a more generalized form of code review that also yields improvements in time to market, overall code quality and project risk. Sell as such.
Various research concludes that expert code review early in a project dramatically helps overall productivity. It's easier to test, review, and fix the bugs and awkward sections of code now than maintain it and troubleshoot customers across the following months or years.
Whenever I'm doing an internal review even if I'm specifically scanning for vulnerabilities, I can't help but notice any number of garden variety bugs, things needing to be refactored, obvious ways to fill gaps in test coverage, better variable and function names, helpful comments I could add, etc.
Maybe this isn't a good use of a high end security researcher's time and could be better left to someone more general, but you could staff some code quality minded generalists. It's quicker to audit clean code so maybe it pays off.
There's a flip side to the problem - not only can startups not pay, but they might not even know that they should be talking to someone like Matasano. Many tech startups severely underestimate the security implications of what they're doing, especially those dealing with very private business data or very personal consumer data.
With respect to fees, there's a whole swath of lawyers, accountants, and other service providers who work with companies from YC and other incubators. They don't work pro bono - they operate on some combination of fee deferral and / or equity. I realize this still doesn't have as much impact as the checks the big guys write, but it seems like it would close the gap.
If you have questions I can help with, it can't hurt to mail them; the worst that can happen is I'm too busy to respond quickly. I don't have a YC filter or anything.
Like most firms working in security, our bread is buttered by large companies, who are bidding very high numbers for (in our case) appsec testing.
But by number, a conspicuously large fraction of our customers are mid-late stage startups, and taken as a whole, we talk to more startups than any other kind of business.
Startups are particularly exposed to the security market problem. They have very little infrastructure and they are spending most of their cycles just trying to stay in business and find traction. At the same time, they've managed to outsource all of the technical requirements of their businesses except the part which bears the highest security risk, which is their custom code.
What can we do about this? I talk to YC companies all the time, and it's frustrating. I am always good for a phone call and we'll even poke at startup apps pro-bono (we love working with startups) but that help has to get in line behind our paying clients, all of whom can be counted on to appear from behind a dark corner at any moment and swallow 2-3 weeks of our time whole.
I am seriously all ears for ideas on how security people like iSEC and Matasano can help early-stage startups without invoicing half+ of those startups last funding round.