Q
Problem solve Get help with specific problems with your technologies, process and projects.

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.

This was last published in October 2010

Dig Deeper on Software Security Test Best Practices

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Security testing can happen in any environment in which tests can be executed. Lower environment are representative of or comparable to production, but they are rarely identical. That means you may not be able to perform every test you want/need to in a lower environment, but you can perform some security testing there, such as checking for SQL injection, buffer overflow, or any number of vulnerabilities.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close