James Panetti is a freelance writer and owner of Panetti Tech Insights.  He is a 16-year tech industry veteran, having worked for Oracle, CA Technologies, and Broadcom over his career and is a tech junkie passionate about writing, coding, and cyber security.

Become a JMeter and Continuous Testing Pro

Start Learning

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)

6 Tips for Secure Cloud Testing

With the growing popularity of cloud platforms, safeguarding any proprietary code you upload (even simple scripts) is more important today than it ever has been. Modern cyber attacks now commonly target the software supply chain attack surface, such as attacks exploiting Jenkins servers or stealing private repository data from GitHub. Today’s blog will provide you with six tips for securing the continuous testing piece of your software supply chain when utilizing a cloud solution such as BlazeMeter.


1. Know the Privacy Policy


First and foremost, always familiarize yourself with your cloud vendor’s data privacy policies.  BlazeMeter is covered under Broadcom official privacy policy and BlazeMeter’s own Product Privacy Transparency Notice.   


Be aware that many cloud providers partner with other cloud providers, often behind the scenes, given that some of the service providers’ own systems likely run on a cloud platform as well.  So it is important to recognize all cloud providers involved and understand how each respective providers’ data privacy policies come into play.


For example, when you configure the load distribution for a performance test, you may select engines from Amazon Web Services (AWS), Google Cloud, or Microsoft Azure.  These engines only exist while your test is executing; they are destroyed afterward.  Meanwhile, any data you upload to BlazeMeter long-term is stored on BlazeMeter’s own Google Cloud storage.


Here’s where you can find our partner cloud providers’ own data privacy policies:


2. Password Hygiene


We recommend an extra level of diligence when protecting your account logins.  


BlazeMeter already requires complex passwords.  We encourage going beyond our minimum requirement in order to maximize security.  For example, passphrases (passwords that consist of multiple words) are generally harder to crack than passwords.


Each user within your organization should have their own account.  Never share user accounts under any circumstances. 


Never reuse a password that you have from another platform. Attackers commonly steal passwords from one website, then test using those same users’ passwords against other unrelated sites and services.  Such an attack compromised ESLint’s data on another platform in 2018


Lastly, change your passwords regularly.  It’s a good practice to ensure your password remains fresh and unique. 


All of these practices can be simplified by taking advantage of BlazeMeter’s ability to integrate with SAML SSO. SSO adds an extra level of protection by reducing the amount of logins each user has to keep track of.


3. The Principle of Least Privilege


The principle of least privilege is a common security principle that simply requires that a user or service is only granted access to the minimum amount of data required to achieve their objectives. 


It applies to services: Only upload the data needed to run your cloud performance test -- no more, no less.  That may mean scrubbing data of possibly sensitive information. It’s extra effort, but worth the protection.


It applies to people: Managing your organization's BlazeMeter user accounts in accordance with this principle.


In BlazeMeter, the first thing to understand when reviewing user access is that there is one organization account often consisting of multiple individual user accounts. As with any complex permissions structure, it can be easy to confuse one level of permissions with another, so take care to review all of our documentation on account permissions, which apply across all of BlazeMeter and mostly pertain to billing-related permissions, workspace permissions, which apply only to a single workspace, and team permissions, which apply to teams organized around API Monitoring Tests.  


4. Secure API Interaction


Each individual user has a responsibility to carefully safeguard their own API and secret keys.  We provide two keys in order to add another layer of protection, and BlazeMeter will only display your secret key to you once (at the time of creation).  


It’s up to each user to ensure secure use of these keys.  Never share your keys with anyone -- that includes other users within your organization.  


If you write any scripts or applications that interface with BlazeMeter using these keys, try to avoid hard-coding the keys directly into your source code.  Attackers often steal keys by attacking a source code repository, stealing the source code within, then using hard-coded keys or other credentials to spread the damage even further. 


5. Auditing


We recommend regularly auditing or otherwise proactively accounting for all activity on your account. If one of your users accidentally runs an excessive number of tests or tests that otherwise eat up your credits too quickly, you can easily find yourself exceeding your account limit, which can result in extra charges or prevent you from running more tests until your credits refresh. 


BlazeMeter’s Usage Report accounts for every test executed by every user for each billing period.  This is a great tool for on-the-spot auditing at any given moment. The Usage Report, of course, won’t report on activity until after it’s happened. You can configure workspace alerts, however, to alert you the moment a functional or performance test is executed.  You can likewise set up notifications for API Monitoring Tests.


These features can be key in catching unauthorized behavior. If, for instance, one of your user accounts has been compromised due to, say, someone sharing their login information, a workspace alert could alert you to an unexpected test run while the Usage Report will point you to the offending account’s recent history of activity. 


6. On-Premise Alternatives


Some data is so sensitive that you would rather it not be uploaded to a public cloud service of any kind. Many platforms today offer alternative on-premise solutions with this in mind.


BlazeMeter’s private locations -- on-premise engines -- allow you to execute functional and performance tests on your own hardware instead of via our AWS, Azure, or Google engines.  The test runs on your local machine, then metrics about the execution (not the test itself) are uploaded to BlazeMeter so it can generate a report.  You can even run these engines behind your own network proxy and use your own CA bundle


Similarly, you can execute API Monitoring Tests locally via the Radar Agent, which you can optionally set up for HTTPS and use your own certificates, and you can set up an on-premise agent for the purpose of securely executing your mock services.


For maximum security, you can take it a step further by setting up your own BlazeMeter private cloud -- meaning the entire platform is onsite.  To learn more, check out our guide on the difference between public cloud, private engines, and full private cloud solutions. 


Conclusion: Running Safer Software Tests


The modern age of the cloud has made many aspects of software development and testing easier than ever, but we can’t afford to take these luxuries for granted.  Extreme caution must always be exercised when processing any data through any online cloud service.  


Security begins with a sound privacy policy, is executed via smart password hygiene, practicing the principle of least privilege, and secure API usage, and is continuously monitored via periodic auditing.  Much, much more can be said on this topic, but beginning with these core principles is a great way to start off on secure footing.


Try out cloud testing yourself with a free BlazeMeter account. Here’s where you sign up.

arrowPlease enter a URL with http(s)

You might also find these useful:

Interested in writing for our Blog?Send us a pitch!