Skip to main content

Security

Considering that the data handled by GUARDARA is sensitive, a dedicated page documenting the security features and, in some instances, the lack of those and related risks helps customers to protect their deployment better.

Credentials​

Access to GUARDARA requires password-based authentication. GUARDARA stores passwords in a non-reversible form (salted hash) to protect credentials in case of unauthorised access to the database. The minimum password complexity requirement is that all passwords must be at least eight (8) characters long. GUARDARA allows customising the password length requirements from the Security section of the General tab of the Settings page.

Not having support for traditional (old-school) password complexity and password rotation rules was intentional, and we are not planning to implement such outdated, insecure practices. Instead, we recommend following industry best practices and choosing a strong passphrase. For further reading on this topic, click here.

To further protect accounts, users can enable two-factor authentication (2FA). Enforcing 2FA globally can be enabled from the Security section of the General tab of the Settings page.

Variable Collections​

It is not recommended to store sensitive information in Session Variables defined within Variable Collections as:

  • Session variables are not encrypted
  • At the moment, there is no concept of data ownership (see Data Ownership section)
  • There is no database-level encryption

In case testing with GUARDARA requires sensitive information such as credentials to be stored as Session Variables, it is recommended that:

  • The credentials are explicitly created for testing with GUARDARA
  • Such credentials do not provide access to production systems or to systems other than the test target
  • The account the test credentials belong to has no access to production data

Callbacks​

Callbacks allow running arbitrary Python code on the Engines during test runs as part of the Test Flow. Therefore, ensuring that only trusted personnel can create and modify callbacks is crucial.

Make sure to carefully review any Python code in Callbacks that came from untrusted sources.

Data Ownership​

Any data managed by GUARDARA, such as test assets and reports, are accessible to all users with the appropriate role. For example, a user with a role that allows reading reports can read any reports, even those produced by a test run of another user.

While data ownership-related improvements are on the roadmap, it is recommended to use the role-based access control to configure who can or cannot access certain types of information for now.

Data Encryption​

There is no database-level nor application-level encryption implemented. Any data managed by GUARDARA is stored as clear-text; this includes, for example, the SMTP server credentials. The above means:

  • If the hard drives of the machine running GUARDARA get stolen, the malicious actors could gain access to the data. In environments where this risk is applicable, it is highly recommended to utilize full disk encryption.
  • Due to the lack of application-level encryption, malicious actors with access to the database server will be able to access all data. Make sure GUARDARA is deployed on a security-hardened system, and access to the system is tightly controlled.

Extensions​

Extensions allow extending the capabilities of GUARDARA, and they are an integral part of the ecosystem. However, deploying malicious extensions can lead to unauthorized access to the systems running Engines. The impact of a successful attack is higher in case an Engine is running on the same host as the Manager because a compromise would provide an attacker access to the system that handles all data.

Because of the above, GUARDARA requires all extensions to be cryptographically signed. This signature is validated during deployment to ensure only extensions from trusted sources are deployed. To further mitigate the risk, it is recommended not to run Engines on the same host as the Manager.

Certificates​

GUARDARA’s certificate authority, the rootca microservice, issues the certificates used by the GUARDARA services. Certificates issued by this service are used both:

  • Service-to-service: Authentication between microservices is done by validating both the client and server certificate. If the certificate was issued by the rootca, the connection would be allowed.
  • User-to-service: By default, the Manager uses a server certificate issued by the rootca.

In case of unauthorized access to the rootca service, an attacker could obtain a certificate that allows communicating with any microservices. Also, if an attacker managed to steal the client certificate of a service, the certificate could potentially allow the attacker to connect to some microservices.

Even though the rootca is bound to listen on the loopback interface only (127.0.0.1), anyone with access to the machine running the microservice could obtain certificates as the rootca service requires no authentication.

As per the above, it is highly recommended to restrict access to the system running the rootca microservice.

Reporting Security Issues​

Please report security issues by sending an email to engineering@guardara.com.

Something's not right? Let us know!