New intuitive web-based interface allows multi-user access London, UK – November 2016 – Acunetix, the pioneer in automated web application security software, has announced the release of version 11. New integrated vulnerability management features extend the enterprise’s ability to comprehensively manage, prioritise and control vulnerability threats – ordered by business criticality. Version 11 includes a […]

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:

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.