How to Set up a Secure Test Environment with an Offsite Team
One of the key aspects of corporate security is control. It is hardly possible to protect important data while not being able to control the information system that hosts this data. And controlling the processes in a distributed multichannel network with a geographically distributed team is always harder than when you have a network located in your own secured space. Unfortunately, this is often not possible with an offsite or offshore team. Physical security methods will not work here, so your control over a distributed network must be implemented on the logical level, with some additional tuning for the team’s internal processes.
The variety of practices and tools to set up a secure test environment consists of the following main groups:
- Infrastructure: namely the networking solutions used to unite remote QAs into a secure and collaborative team.
- Policies: a set of rules and recommendations for all team members to operate safely.
- Processes: including the practical implementation of the policies. Your approach to the situation defines how the infrastructure will actually be used and how the policies will be implemented.
A case when two or more groups of QA engineers are working on the same project in different offices is relatively simple. This generally falls within the scope of your sysadmin/DevOps’ daily routines. The office networks are connected together via secure gateways and virtual channel protocols with standardized settings.
However, in today’s world, it is increasingly more common to have some, if not most, teammates connecting independently from their remote locations (aka home offices) to the company’s or project network. From a technical point of view, such a structure brings some benefits while adding new challenges at the same time.
First of all, you’ll have virtually no control over the individual remote devices. A company may provide a remote QA with a laptop or a phone, however it will still be difficult to monitor use of the device. So, the main security measures are to be implemented on the company’s side. a mandatory VPN channel such as Cisco AnyConnect is to be used to connect the remote QA work device with the internal network, and further access to the test environment will be controlled with usual internal security procedures.
Team communication is usually conducted via popular channels (Skype, Slack etc.), which are device-independent. It is preferable that all teammates including remote ones use special corporate accounts and participate in calls and discussions from their work devices whenever possible. Again, the last requirement is difficult to enforce for remote workers.
The same practices apply to shared data storage and email accounts. Most projects today use Google Drive and Google Mail for both purposes, as this platform is both secure and convenient. Often the client’s own cloud is mandatory, which therefore takes some part of responsibility to control it from the outsourcing company to the client. In addition, we’ve got a secure internal cloud as an option. It allows sharing documents and media files to both authenticated and anonymous viewers, and, unlike Google, does not limit its users by the upload amount.
Last but not least: Regardless of how distributed the QA team is, it is crucial to maintain control over test servers. Team members may access them or even launch CI jobs there to get a non-scheduled update or run autotests. Yet in any problematic situation, a final decision must be up to the project manager, the tech lead or the product owner from the customer’s side, depending on the project configuration.
Once infrastructure has been set in place, teams can move forward with creating policies that will dictate how this infrastructure will be used. The team must set internal standards, follow best practices and have strict corporate rules to prevent some of the typical mistakes that introduce security risks into a distributed QA environment.
The first set of policies should cover access restrictions and policies for using shared documents and data.
A lot of the fundamental aspects of these policies are covered when establishing infrastructure, for instance, by using Google Drive for document sharing and establishing a team hierarchy for determining who gets access to which documents. On a policy level, this is extended to ensuring only corporate accounts can access the data. This will also prevent the use of multiple accounts by the same contributor, which often leads to chaos.
The same access rights and restrictions policies can be used for documentation. Having an internal hierarchy can help teams decide that important documentation can only be available for the client and the project manager, for example.
Finally, in an ideal case, an offshore or offsite team is provided with dedicated work devices by a customer or by an outsourcing company. However, most often remote QAs have to use their personal ones. Depending on the project specifics and its network configuration, some approaches still can be used to keep control in this situation. Particularly, the QAs might be required to avoid connecting these devices to unsafe networks, such as undefended public WiFis, and to take responsibility for their work credentials and sensitive project information so that it does not get exposed to any third party.
The final, and arguably the most important, part of establishing a secure QA environment is a focus on the QA processes. It’s not just what you do to be secure, but how you do it as well. The process aspect of security is where corporate culture comes into play.
No matter how perfect your policies are, you have to make sure teams are actually following them. The best way to ensure it is through motivation, avoiding micromanagement whenever possible. A well-engaged teammate should be interested in the project’s success. Add a clear and complete system of responsibilities, and you are likely to have most of your security risks avoided and any disasters quickly solved.
If the team is new or a clear culture hasn’t been established yet, you can choose to monitor and log some key processes. Even if you do have a good culture, some logging should be conducted in the project network in case of a security incident, such as unauthorized access, some clues could be used to understand the problem. And it is crucial to support versioning for all important documents — with Google Docs you have it by default — so you could always roll back if something important was deleted for some reason.
The balance between trust and micromanagement is going to determine your team’s flexibility. A remote team should maintain a proper balance between security policing and efficient collaboration. The key to success is understanding real risks and taking adequate prevention measures — that is, being flexible!
Challenges and Risks
The biggest risk in any security measure is how closely it’s followed. It is often tempting to ignore formalities to save some time, especially if the deadline is close. Nearly every team has been in such a situation at least once. Of course, it may have worked for you previously. But the price of failure can be too high when there is even a small risk of important data loss or leaks of sensitive information.
On the flip side, building an overcomplicated infrastructure because of inefficient security policies can really slow down a team and hinder individual performance. Time losses or miscommunication caused by poor understanding of roles and responsibilities inside the team can lead to failure to deliver results in time. That is why flexibility and team engagement matter.
Without flexibility, the QA team might be too rigid to fit the client’s policies. The client’s wishes and policies should be followed, even if that means relying heavily on micromanagement.
However, a client’s security policy is the bare minimum of what a distributed QA team should go for. If the team members find that the client’s policies are lax, going a bit further than what’s been requested can help out in the long run.
Our remote QA teams intend to keep important data in test environments safe so they always bring up any problematic situation or loophole they find, and make sure that the customer is informed about the risk. It is our team’s responsibility to avoid breaching any important security rule while maintaining high output and efficient QA processes.
Tips/Best Practices for Continuous Improvement
It’s nearly impossible to form a new QA team and immediately create an environment that is 100% safe. Each team must conduct their work responsibly and learn as they go along, closing gaps if mistakes are made and following best practices.
Each project brings some unique experience and even if it is a data security disaster, you can use it to improve your infrastructure, your policies or your approach to remote team building. At QArea, we are keen to analyze every problematic case in our history. Moreover, we monitor current trends in security strategies and take into account any such cases from other companies whenever such information is publicly available.
Teams should maintain clear requirements and internal guidelines. It’s better to spend some extra time establishing infrastructure, policies and processes before work begins because making changes on the fly can stall the entire development process.
Finally, the key to security is clear communication, first by making things clear to clients. It is better to invest some time in detailed discussion and clarification of all requirements and specific cases than to discover serious hidden problems near the end of a project.
Then, within the whole QA team. For example, our team is committed to active knowledge-sharing between professionals who have varying experience from their past projects, as well as any QA-related events they have ever attended. Particularly, there is a long tradition of meetups every Thursday in our R&D office where security risks and solutions get mentioned quite often.