Can security testing only happen in the production environment?

Security test expert Kevin Beaver talks about the advantages and disadvantages of security testing in production environments. If production environments are off-limits, he makes recommendations for testing in staging or disaster recovery environments.

What is the best practice for testing security vulnerabilities in Web applications? Testing of our production environment is not currently feasible using automated tools due to the generation of thousands of records into the production data base. Everything seems to indicate the production environment is the best and only place you can test web application vulnerabilities with any certainty. Is this the case?

Your concern is a valid one. You don't necessarily want automated scanning tools generating thousands of requests...

that submit junk data into your database(s). They can certainly do that in a hurry and the ramifications can be widespread.

Which applications you actually test is completely up to you and, of course, any contracts, policies, or standards that may contain specific testing requirements. I typically test applications in production but have also tested applications running in staging and DR environments. You don't necessarily have to have the latest code to test as long as it's reasonably current (i.e. within a couple of weeks). Again, know your requirements.

If production is off limits, then the simplest solution is probably to test staging where you can easily blow away the database – or not care how you muck it up. You may also consider setting up an environment that mirrors production at a DR facility or on a backup set of servers on your own network. I've seen people create a virtual environment that allowed for simple code updates and configuration changes and, when the time's right, they just scrapped the environment and started over.

Getting back to testing applications in production, doing so can be beneficial because you know it's running the latest code and represents the real world environment you're presenting to everyone. What you may be able to do is, on the back end, limit or redirect the specific application requests that are made during your application security testing so they don't actually insert data into the database. As long as input is not hindered and the application can make database calls you should still be able to get a good representation of actual vulnerabilities. Of course doing so depends on your unique environment, which user you're connected as, application logic and so on but if you can figure out a way to do it this may be the best overall solution.

Dig Deeper on Topics Archive