• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Resources
  • About
  • Schedule a Call

May 3, 2016 by James Jardine Leave a Comment

Security in Testing Environments

When it comes to creating applications, there is a need for multiple environments to support the development process. It typically starts on the developers own computer, then on to an integration environment, a QA testing environment, possibly a UAT (User Acceptance Testing) environment, and then finally production. Depending on your organization, you may have some, none, or all of these different environments.

When it comes to security, the focus is typically on the production environment. This is where the instances that all of the users use are on a daily basis. This has all the “real” data. It is where real credit card numbers or social security numbers may reside. There is a lot of effort put on securing the production environment.

What about the test environments?

If your testing environments are externally exposed, the security of those environments are just as important. Anything exposed externally is a target and needs to be considered. Just recently there was an article about a test database being exposed that resulted in leaked data. This is an opportunity for us to look at our own systems to understand what we are doing with our test environments.

Some things to think about within your test environments:

  • What do we actually have exposed externally – Keep an inventory of the software, services and devices that are exposed. This includes any databases, web servers, ports, etc.
  • Ensure the endpoints are properly locked down – Make sure that your systems are not left wide-open. Don’t leave default passwords in place, make sure they are changed to be unique. If you are running some form of database server, make sure it is not exposed and that it has authentication enabled on it.
  • Check the validity of data – What type of data do you use in your test environment? Are you using a straight copy of production (shame on you)? What type of data scrubbing are you performing? Are you performing data scrubbing? What types of sensitive information may be stored in the environment.
  • Who has access to the environment – Is the environment limited to specific IP addresses or clients? Is it open to anyone that has a valid username and password? Who should it be open to?
  • Where are the servers – Consider where these servers are located. Are they in the same environment as the production servers? What about the corporate network?

These lower-level environments produce risk and should be tracked accordingly. Don’t discount them just because they are “test”.

Filed Under: General Tagged With: authentication, database, default password, developer, production, security, test environment, testing

Reader Interactions

Leave a Reply

You must be logged in to post a comment.

Primary Sidebar

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
Email: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved