Data Processing and Storage

Last Updated On

This article describes what kind of data BiG EVAL processes and how it stores it. This article can be used as a reference or complementary documentation for your data protection compliance.

What kind of data does BiG EVAL processes

The following are the main groups where data produced, processed and stored by BiG EVAL belongs to. The following chapter describe these groups in more detail.

Configuration Settings

The BiG EVAL application needs some configuration settings to run correctly. There are infrastructure onriented configuration settings and application oriented configuration settings.

Infrastructure Configuration Settings

Infrastructure configuration settings are used to tell the application at startup how the different application layers are connected and how they should behave. These settings are stored in the configuration-file appsettings.json right in the applications installation folder. The appsettings.json file includes the following configuration settings:

  • Connection-Information to the BiG EVAL repository database.
  • URL of the Web-Frontend of BiG EVAL.
  • Logging-Configuration.
  • Signing-Certificate settings (settings about which certificates should be used to sign protected data).

The appsettings.json file is protected by the filesystem of the Windows Server. That means it is your system administrators responsibility to protect the filesystem from unwanted access.

Application Configuration Settings

All other configuration settings that are not mentioned under “Infrastructure Configuration Settings”, are stored in the repository database.

These are:

  • Instance Settings
  • UI-Settings
  • Alerts

Data Sources

Test cases of BiG EVAL connect to different data stores where the “Data Under Test” is stored. The connection settings are defined in Data Source objects wich are stored in the repository database. These Data Source objects consist of

  • Name
  • Driver type
  • Connection String
  • Credentials
  • Depending on the data source type, there are more information.

Sensible information like usernames and passwords are encrypted and can only be decrypted on and by the BiG EVAL server itself because it uses the server-key available from the Windows infrastructure.

Test Case Definitions

The definition of a test case – or in other words: the implementation of a test case – is also stored in the repository database. A Test Case Definition consists of:

  • Metadata (Name, Description, Tags etc.)
  • Probes (Queries and different sesttings for shaping the query results)
  • Scripts
  • Test Suites
  • Parameter Lists
  • User Defined Methods
  • Snippets

There are usually no sensitive data stored in test case definitions. There could be sensitive data in the queries of probes depending on how the test case developer implements a test case. BiG EVAL stores queries in clear text in the repository database. So there is no encryption of sensitive data that may be part of a query.

Test Results

Test Results are the output of a test run. They get stored in the repository database and consist of:

  • Reference to the test case definition.
  • Test Run information (status, timestamps etc.)
  • Probe Values and Defects

The probe values is the actual information that was subject to test (Data Under Test) and that had errors within. BiG EVAL doesn’t store data under test, that has no errors. It also depends on the “Data Protection Switch” in each test case definition. There a test case developer is able to define what information about erroneous data should be stored:

  • Nothing at all
  • Id’s only
  • Full records

So, at the end it depends on the test concept a developer implements what will be stored in the repository database.

Data Under Test

The actual Data Under Test gets loaded from the source data stores to the memory of the BiG EVAL server. It get’s stored in-memory only. When a test case completed, the data gets dropped from the memory. What’s left, are the erroneous data records as explained in the previous section Test Results.

Parameters

Global Parameters are powerful way to dynamically adapt the behavior or setting of a test case to specific situations or environments. Storing server-names, and database-login-credentials in parameters is a common way to work with parameters. Except of global parameters, the values of parameters are only held in memory during a test run. Depending on the test-developers decision how to utilize parameters, the developers may assign confidential values within test-case-scripts or any other script. This is not a best practices as these values could be displayed to other users and are not stored in a safe way. We recommend using Encrypted Global Parameters to store confidential information.

The values of global parameters are stored in the repository database and can be viewed by users with read-access on this database as long as the parameter-values are not encrypted (see parameters documentation). Encrypted global parameters get encrypted with a AES256-algorithm using the machine-key of the BiG EVAL server.

User Logins, Preferences and Tokens

User Logins

BiG EVAL lets the administrator choose whether Active Directory user should be used to login into BiG EVAL, or whether the integrated user management of BiG EVAL should be used. In both casees, BiG EVAL stores information about the users in it’s repository database. This includes:

  • Username
  • First- and Lastname
  • Email-Address
  • Password (AES256-Encrypted and Hashed; and only with the internal user management enabled)
  • Groups and Roles
  • User Preferences (UI-settings)

When an administrator deletes a user in the user interface, it gets marked as deleted only to ensure that audit-history is maintained completely. That means the user data keeps present in the repository database.

Tokens

When using API-Clients with OAuth 2.0 authentication to control BiG EVAL from a 3rd party application, -process or -workflow, an API-Client-Configuration is needed. This includes:

  • Client Name
  • Client Secret (an ID generated by BiG EVAL)
  • Access Tokens (generated by BiG EVAL)
  • Claims and Role-Assignments

Technical Logs

There are log files where BiG EVAL stores technical events for tracing and error solving purposes. These log files are stored within the installation folder of BiG EVAL on the BiG EVAL server. Securing the file system is in the system administrators responsibility.

Which events and how much events get stored is primarily driven by the source code of BiG EVAL. But the configuration of the logging mechanisms can be overwritten in the appsettings.json logfile in the logging section.

Sensitive information like connection strings or similar do not get written to the logfile. They are masked by a couple of asterisks (*).

Web-Cache

BiG EVAL maintains an in-memory and in-process web-cache to boost the HTTP-performance. There is no physical persistence.

Cookies

BiG EVAL uses browser cookies to store authentication settings and user tokens. These tokens may contain group assignments and other claims of the user. BiG EVAL filters out all claims that do not belong to BiG EVAL before it sends the cookies to the client browser. So, there is no other information within these cookies. The cookies themselves are encrypted with a server-based key. So they cannot be encrypted on the client machine.

Repository Database

BiG EVAL uses a SQL Server database to store test case definitions, test results, user logins, preferences and tokens and application configurations. Depending on your system architecture, the SQL Server – and therefore the repository database – is installed on the same server as BiG EVAL or on a remote server.

Table of Contents