Data Storage and File Security

Data Storage and File Security

< Guide Menu

Overview

Quasar Server stores encrypted data, keys, and management information in database files on the local filesystem. In Quasar v3, a connection to an SQL Server database was required for storage of sensitive, non-sensitive, and job control and management data. In Quasar v4, this has been changed to use local files on the application server’s NTFS filesystem to store the above data separately.

Quasar’s sensitive data is stored as compressed encrypted blocks, packed into container files. This has enabled significant enhancements to performance, cost, and security in Quasar v4.

Default File Locations

The local file location defaults to c:\programdata\quasar, but can be controlled by changing the location in quasarserver.cfg and quasarui.cfg.

Quasar expects that the local filesystem uses NTFS as it uses NTFS permissions to enforce security.

As the UI and server components make use of the same files, it is important that they are located on the same machine.

Quasar does not support using network drives for storage of the data files.

Data Folder Usage

Folder SecurityUse
data\defaultNot currently used
data\lowContains miscellaneous files and the management database used for job control and agent tracking. No cardholder data is ever stored here. Also contains temp files and logs.
data\highContains encrypted data files, local encryption keys, and the user actions audit log database

Data Folder Security

Folder SecurityPermissions
defaultInherits rtfs permissions from its parent. No changes are made.
lowAs default and assigns everyone the pseudo-user. Allows permissions to be modified but does not grant Full Control. This is to ensure that admins can read the logs, and that the applications can manage their temp space effectively.
highThe owner is the account quasar is running under. Inherited permissions are stripped / removed. The account has full control for the folder, subfolders, and files. No other permissions are permitted.

Further Information on High Security

The data files and data encryption keys are stored in separate areas under a high security data folder. NTFS permissions are set by the server to:

  • Strip / Remove all permissions normally inherited from parent folders.
  • Set ownership to the account / user the server is running as.
  • Lock down permissions so that user and only that user has read / write access to the high security folder.

Quasar checks the folder security every time the server starts. If there are any problems, the server will log an error to the Windows event log and refuse to start. On startup, Quasar checks:

  • Read / Write to the required Quasar folders
  • Security permissions set on the required Quasar folders
  • Access to the management database
  • Access to any data store files

Server Application Startup

Security checks are performed on application startup. Failures will cause startup to abort and the service to not run.
All security checks are logged to an entry in the Windows Event Log.
The log entries detail folder locations, the service’s running user, and the results of permission checks, to aid troubleshooting.

Read/Write Access to the various folders is checked
Security permissions are set on the various folders as above.
Access to the management database is checked
Access to any datastore files is checked.

—— Example normal startup log ———-
INFO - Config file D:\tmp\server\quasarserver.cfg not found, using defaults
INFO - app path D:\tmp\server
INFO - Running user (u'bb', u'FLEET', 1)
INFO - root folder access OK C:\ProgramData\quasar
INFO - temp folder access OK C:\ProgramData\quasar\temp
INFO - data folder access OK C:\ProgramData\quasar\data
INFO - log folder access OK C:\ProgramData\quasar\logs
INFO - high security folder access OK C:\ProgramData\quasar\data\high
INFO - low security folder access OK C:\ProgramData\quasar\data\low
INFO - default security folder access OK C:\ProgramData\quasar\data\default
INFO - set low security folder C:\ProgramData\quasar\temp
INFO - set low security folder C:\ProgramData\quasar\logs
INFO - set low security folder C:\ProgramData\quasar\data\low
INFO - set high security folder C:\ProgramData\quasar\data\high
INFO - temp folder access OK C:\ProgramData\quasar\temp\svr

—— Example Fail log ———-

Error setting up folders : (5, 'GetFileSecurity', 'Access is denied.')
Log:
INFO - Config file D:\tmp\server\quasarserver.cfg not found, using defaults
INFO - app path D:\tmp\server
INFO - Running user (u'SYSTEM', u'NT AUTHORITY', 1)
INFO - root folder access OK C:\ProgramData\quasar
INFO - temp folder access OK C:\ProgramData\quasar\temp
INFO - data folder access OK C:\ProgramData\quasar\data
INFO - log folder access OK C:\ProgramData\quasar\logs
ERR - high security folder access failed C:\ProgramData\quasar\data\high
WARN - could not access folder owner info
ERR - (5, 'GetFileSecurity', 'Access is denied.')

Detailed error information:
Traceback (most recent call last):
File "quasarserver.pyc", line 74, in init
File "foldersconfigs.pyc", line 173, in InitDirs
File "foldersconfigs.pyc", line 88, in EnsureDir
File "foldersconfigs.pyc", line 234, in GetPathOwner
error: (5, 'GetFileSecurity', 'Access is denied.')

Common Startup Failure Modes

As the high security folder permissions are configured on application startup (and ownership taken if necessary) the first run will determine the folder owner.
If subsequent runs are under a different account, access to the high security folder will fail, causing start up to fail

It is important to ensure that:

  • The server and UI components are run under the same user account at all times
  • Initial testing of the components (e.g. in a command prompt) has the command prompt running as the appropriate user.

To resolve:
If need be, an administrator with sufficient privileges can take ownership of the folder, then assign open acccess permissions.
(This admin take ownership functionality is a feature of windows and cannot be worked around.)
When the app is run, it will lock the folder down again to it’s own user with it’s own permissions.

Threat Model & Security Tradeoffs

Quasar V3 used a connection to an SQL Server database to store sensitive, non-sensitive, and jobcontrol/management data.
Quasar V4 uses local files on the application server host’s NTFS filesystems to store sensitive, non-sensitive and management data separately.

The data is stored as compressed encrypted blocks packed into container files. This has enabled significant enhancements to performance, cost, and security in V4.

==Performance==
Quasar data no longer loads down an SQL Server database, freeing database resources that can be used elsewhere (typically when quasar v3 has been sharing the use of an existing sql server cluster).

==Cost==
When quasar v3 has been using it’s own sql server instance exclusively, the decommissioning of that instance typically saves the customer NZ$2-4,000/year in licensing fees to Microsoft.

==Security==
Security-wise in V4 all data is now encrypted and the encryption and keys are managed by the quasar server itself. This is an improvement over V3 where security and encryption was the responsibility of customers and required to be managed by the SQL DBAs.

Symmetric encryption is performed by the server using an industry-standard module – ‘libsodium/NaCl’ using the ‘secret box’ high level API. Thus any risk of ‘home brew cryptography’ is avoided.

The threat model & mitigation here is:
1) If an attacker can gain access to the high-security area, the attacker must already have enough access to be able to do far worse things to the windows host itself. In short there are ‘bigger things to worry about’ at that point than quasar.
2) Any tampering of the folder security can be easily audited and logged/alerted if the customer has a SIEM infrastructure in place.

The data-encryption keys are in turn encrypted with a passphrase then scrubbed from local storage, when the files need to be sent for analysis.

Next Risk Management and Mitigation
Table of Contents