3 ms·

It's basically an additional QA or acceptance environment, capacity being a fraction of what is running live, that's no more costly and time consuming really th

by surge 11y ago

It's basically an additional QA or acceptance environment, capacity being a fraction of what is running live, that's no more costly and time consuming really then all the effort it takes to setup a bug bounty program, and you can get far more useful take aways from it if they can fully red team it. If someone finds an exploit that takes down the system or compromises account data, no real data or systems are at risk, no more so then they would be to actual malicious users. The rules of engagement would obviously limit you from testing the real properties and restrict you to said servers that are completely isolated from the working production environment. DDOS attacks would be things that hang the application, or database, not simply flooding it with bot requests. Then they could do code injection, etc.

tptacek 11y ago
I spent 10 years negotiating for complete staging environments for professional pentests, on engagements with a median price somewhere in the mid-5-figures, and we rarely got them. Whatever you may think about the simplicity of setting up staging environments on a message board, they are empirically not easy in the real world. There was no correlation between how savvy the target was and how likely they were to have staging environments for us. The modal organization that gave us a complete staging environment tended to be back-office IT for some huge company. Smart startups virtually never did. One reason for this is that the environment a pentester needs is different from the one a developer needs. Large portions of the production environment can be stubbed out for a developer, and they can still get testing work done by focusing on their own component. Virtually every part of the environment needs to work, the way it does in prod, for a tester to do their job. I'm still unclear on why code injection is such a big deal. The company isn't saying you can't test for vulnerabilities that lead to code injection. They're saying you can't actually inject code. There are two reasons you might, as a tester, want to do that: first, to "pivot" through the target to find more vulnerabilities, and second, to confirm a sev:hi flaw. Neither of those goals are important here, as long as the company is good about acknowledging prospective sev:hi flaws.
- NeutronBoy 11y ago
  Also, it adds ongoing costs to change management, as now you have to modify two environments for each change, test two environments, ensure data is refreshed into your non-prod environment (while ensuring you don't use production data in it), monitor two environments, pay licensing and support costs (hardware and software) for two environments, etc. Having a secondary 'test' environment isn't as easy as 'oh just clone the VMs'.

by surge 11y ago

tptacek 11y ago

I spent 10 years negotiating for complete staging environments for professional pentests, on engagements with a median price somewhere in the mid-5-figures, and we rarely got them. Whatever you may think about the simplicity of setting up staging environments on a message board, they are empirically not easy in the real world. There was no correlation between how savvy the target was and how likely they were to have staging environments for us. The modal organization that gave us a complete staging environment tended to be back-office IT for some huge company. Smart startups virtually never did. One reason for this is that the environment a pentester needs is different from the one a developer needs. Large portions of the production environment can be stubbed out for a developer, and they can still get testing work done by focusing on their own component. Virtually every part of the environment needs to work, the way it does in prod, for a tester to do their job. I'm still unclear on why code injection is such a big deal. The company isn't saying you can't test for vulnerabilities that lead to code injection. They're saying you can't actually inject code. There are two reasons you might, as a tester, want to do that: first, to "pivot" through the target to find more vulnerabilities, and second, to confirm a sev:hi flaw. Neither of those goals are important here, as long as the company is good about acknowledging prospective sev:hi flaws.

NeutronBoy 11y ago
Also, it adds ongoing costs to change management, as now you have to modify two environments for each change, test two environments, ensure data is refreshed into your non-prod environment (while ensuring you don't use production data in it), monitor two environments, pay licensing and support costs (hardware and software) for two environments, etc. Having a secondary 'test' environment isn't as easy as 'oh just clone the VMs'.