Testing Insecurities: How Testing In The Cloud Can Lead To Severe Vulnerabilities Without The Right Precautions

By Joe Alfaro of Sauce Labs

Is your test environment secure? Do you know who has access to your test data, source code or design specifications? These are important questions for today’s business world, now dominated by software-centric organizations. The days of siloed, waterfall-driven application development have been transplanted by modern development processes, which are driven by complex yet efficient new architectures, such as micro-services and cloud computing.

There was a time, back in the days of stand-alone test systems and networks that were strictly local-area, when the questions above would have been easy to answer. A co-worker or two might have been looking over your shoulder, but that would have been about it.

These days, however, applications are exposed to the public web and such questions can have serious implications to software’s security and the company bottom line. Software and mid-market IT companies may still have physical locations, but much of the development and testing is done off-site, by employees, contractors and services that transfer data over the Internet, such as cloud-based testing.

Most companies are reasonably security-conscious when it comes to software development, but does that security consciousness extend to the ever-important testing process? For many companies, using an Internet-based testing service just makes good sense from both a practical and economic point of view. But when a QA department shifts its testing from in-house to online, do QA management and staff also shift their understanding of security from “stand-alone machines safe behind four walls” to “somewhere out there on the Internet”?

 

What’s At Stake

screen shot 2015 08 31 at 3 41 10 pm1 Testing Insecurities: How Testing In The Cloud Can Lead To Severe Vulnerabilities Without The Right Precautions

Consider what can be at stake if outside parties gain access to a company’s test data or test environment:

 

IP Theft

Unfortunately, not everybody in business sticks to the rules of fair play—and that includes the technology sector. Intellectual property is a valuable commodity, and for many technology providers, it is their main asset. This is particularly true for smaller companies and startups, which may not have had time to develop other assets, such as name-recognition or a reputation for high-quality products or services. IP is not hard to steal, since it generally consists of information that can be easily copied, compressed, encrypted and transported. Often enough, sufficiently detailed (or even general) knowledge of an idea is sufficient for it to be stolen. If you are testing a feature or technology that is worth stealing, and if there is a way for IP thieves to gain access to a test environment, there is a reasonably good chance that they will break in. When that happens, one may find themselves not only competing with knockoffs of their software-in-progress, but also fighting in court to regain control of that proprietary technology and data.

 

Competitors

Every company, if doing something worthwhile and making any money, has competition—and if the competitors are smart (which they almost certainly are), they are watching. They may play a cleaner game than IP thieves, but they want to know what you’re planning, what new technologies and services you’re in the process of implementing, how far along you are in developing them, and how well they’re working. Needless to say, if they know what mistakes you’re making, they can learn from them as quickly as you can. If your online test environment is not secure, it’s possible that your competitors have access to your test results, and may even be able to observe your tests while they are in progress. A test suite can give a sense of code, functionality, and potential issues and weak spots in your application. They’ll know what new features and technologies will be in your next release, and they’ll have a head start on adding competing versions to their own products. If they can learn enough from watching you, they may even beat you to the market.

 

Just Plain Privacy

Maybe you’re not testing anything that can be easily cloned by competitors or stolen. Maybe you’re working on things such as better implementations of known technology, and a new user interface that incorporates your brand-new, still-under-wraps company logo. There still may be some major security issues to keep in mind when it comes to online testing.

Consider this all-too-familiar scenario: Hackers break into a site, dig out some attention-getting information, and spread it all over the Internet. Very often, it turns out that what was mildly entertaining to the hackers is embarrassing or even damaging to the people and organizations affected by the leak. Do you want your upcoming feature list to become public knowledge while those features are still in the early development phase? Do you want your raw test data posted for anybody to see? Just one little break-in, into a non-secure test environment, could do all of that.

 

What Security Looks Like

screen shot 2015 08 31 at 3 41 10 pm1 Testing Insecurities: How Testing In The Cloud Can Lead To Severe Vulnerabilities Without The Right Precautions

So what does a secure test environment look like? There are characteristics that of a secure test environment:

 

Dedicated, One-Time Virtual Machines

Each test VM should be spun up, used only for a single test and then destroyed. VMs should not be recycled for multiple users, or even for multiple tests by the same user.

 

Secure Communication

Client communication with the test system should be by secure VPN or tunneling. Client test scripts and data should only be cached temporarily on the test-system side, and never stored. Only the current test VM should be allowed to communicate with the client.

 

No External Communication

All inbound channels of communication with the test VM other than client VPN/tunneling access should be disabled.

 

No On-Site Storage Of Test Data Or Artifacts

Test data and other artifacts should never be stored at the test site. They should only exist in RAM on the test server, and should be sent to the client via secure connection. If they are stored as part of the test service, such storage should be in a secure cloud-based location, it should be for a limited time, and it should only be at the client’s discretion.

 

If a test environment does not have these built in factors, developers cannot count on it to provide a secure testing environment. A genuinely secure software testing service, on the other hand, can guarantee that all test data will truly be for your eyes only.

 

Joe Alfaro is VP of Engineering at Sauce Labs. Joe has a proven track record of technical, organizational and business leadership and has held executive level positions at large companies such as Symantec, Borland, and Citrix. Joe cofounded and led startups that were funded and successfully acquired, and graduated from Stanford University.

The views, opinions and positions expressed within this guest post are those of the authors alone and do not represent those of CBS Small Business Pulse or the CBS Corporation. The accuracy, completeness and validity of any statements made within this article are verified solely by the authors.

 

Comments

Leave a Reply

Fill in your details below or click an icon to log in:

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Listen Live