You’ve heard me say that planning is half the battle with Web security assessments. I’m finding that more and more people are on board with thinking things through in advance but there’s still one area that’s not getting the attention it deserves. It’s deciding on which environment to test: development, staging or production.
Everyone’s (and every application’s) situation is different but it’s rare for me to find a business where this issue has been thoroughly discussed. I’m guessing it’s related to those of us doing the testing not properly explaining the ramifications of testing production environments. I’ve found that the majority of developers, project managers, IT staff and others involved with Web application security testing aren’t fully aware of what can happen when production Web applications are tested including:
- Email floods
- Junk data inserted into databases
- News feeds filling with random input
- Log files filling up
- Accounts getting locked out
- Internet bandwidth consumption
- Scans that take longer to complete
- High server and database utilization
- Incident response teams and managed security providers having to deal with alerts
- Final cleanup needed after the fact
Much of this depends on how the application works but you can bet that at least one or two of these issues are going to arise in production during your Web testing. Are you prepared to take that on? Can the business absorb the impact if something goes awry? What are the alternatives?
There’s no good answer. It all depends on your business needs and current capabilities. Maybe you need to test an application now and cannot wait to build a development environment. Perhaps staging environment is the best alternative or perhaps you’re only allowed to test production. The best thing to do is to meet with the right people to discuss this and come up with a plan.
Regardless of your choice, it’s important to note any unique configurations and findings in your final report. For instance, production or staging servers may not be configured the same way as production. They may have missing patches or a Web server that hasn’t been hardened and thus different vulnerabilities. You may have a unique firewall, IPS or WAF setup or behavior in production that paints a different picture. Even when you go back and validate security flaws in development or staging you may get different results given the dynamic nature of those environments. Whatever you do, never assume that development and staging look just like production – and vice versa. Document your caveats.
Again, there’s no right or wrong solution. The important thing is that you’re testing something.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
