Hacker News Reader

Comment by tptacek | Hacker News Reader

The low-end of that range is the ballpark for the low-end of the range of security assessments; the $75,000 high-end is very high; a more realistic range would be $15,000-$30,000 for typical SAAS-type functionality.

This is simply what professional security assessment costs. There's a lot of competition and a diversity of firms, and this is the range the rates float in.

It doesn't make sense that small companies should be allowed to circumvent the requirement when what they're doing is just as sensitive as apps from large companies.

View on HN

Both are true simultaneously:

* professional security is needed, and this is what it costs

* the cost is more of a barrier to smaller companies (and hence provides an advantage to larger companies)

It seems like an inherent tension; I'm not sure how to get around it.

These costs definitely seem high. As a reference point - to get through the Salesforce AppExchange security review process, believe the cost is $2,700. It’s an extremely rigorous security testing as one might imagine with corporate CRM data.

Is that ran by SalesForce? If so, could they be subsidising it?

Yes AppExchange is run by Salesforce and they likely do subsidize the security review. They also take a percentage of revenues from direct AppExchange installs(believe 15-25%) after listing. SF wants third party devs building out functionality and the ecosystem. Google seems to be taking a different approach...

Seems like a business opportunity for somebody to create a compliant API that allows other people to write software that accesses gmail data in a limited fashion.

I'd say that this is nearly impossible.

We talk about two different data sets here: * The actual User data. * Data from third persons, including, but not limited to their e-mail address.

While a user can agree that their own data should be processed by a third party, the problem is that he cannot consent for other people.

And in my understanding (INAL), every part of the software where those third person information is transferred or processed needs to be part of that full assessment.

A limited API that does not give out any third persons data would have to somehow filter out all the information of all third partys.

Their TOS explicitly forbids doing that.

> It doesn't make sense that small companies should be allowed to circumvent the requirement when what they're doing is just as sensitive as apps from large companies.

If they really are small companies then (in most cases) what they're doing isn't as sensitive, because the value of the assets under protection is lower. It would be completely reasonable to say that companies with less than 5,000 users only need to be assessed for vulnerability to automated attacks and not targeted attacks.

If you're a company the size of Facebook and you're accidentally sending password reset tokens to your analytics partners then that's a disaster. But I don't know that it's worth shutting down hundreds of startups with a couple dozen users each over the sort of potential security weaknesses that, while not ideal, realistically aren't going to result in anyone having their private data exposed.

Smaller companies might have smaller blast radii, but that's cold comfort for the 4,999 people whose data would be lost in a breach. I don't think allowing small companies to externalize security risks is a good plan; neither, apparently, does Google.

I agree on principle that no company should be allowed to externalize security risks.

Where I disagree is that for a small company that doesn't use SQL, being forced to pay someone $10,000 to spend an extra week testing every single endpoint for SQL injections isn't going to mitigate any potential vulnerabilities, nor would being allowed to opt out of that requirement externalize any risk.

And if we're going going to say that companies shouldn't be allowed to externalize risk then that requires some baseline understanding of what risk actually is. And at the end of the day, it's impossible to separate risk from the value of the assets under protection, as Bruce Schneier has been saying for 20+ years.

Which is why an early part of the discussion, before the engagement starts, what the architecture of the application is and what technology it is built out of and where it is hosted.

In a competent code-assisted penetration test, nobody is going to charge $10k to test endpoints for SQLI when the application doesn't use SQL.

Reply on news.ycombinator.com