Changes to support PCI DSS

PCI DSS 3.3 -- Mask PAN.
Eloquence 8.1 will be addressing this by either completely or partially masking columns. Minisoft will work with Marxmeier Software to support this Eloquence feature.

PCI DSS 3.6 – Key Management.
The changes we are making will remove hardcoded keys and passphrases. These will be controlled by the customer and changeable without needing support from Minisoft.

PCI DSS 4.1 – Encrypt data.
Encrypt all data transmission between client and server. Using SSLv3 or TLSv1 with support for OpenSSL and SPPI.

This is currently undergoing testing and optimization using both OpenSSL and Microsoft SPPI.

PCI DSS 6.3 – Software Application Development.
Please schedule a time when we can discuss the aspects of this section.

PCI DSS 6.5 – Web Applications.
Many of our customers use the drivers to access data via the web. Please let us know if there are any items relevant to this section that are not covered by other requirements.

PCI DSS 7 – Restrict access.
Access controls and logging will be changed as needed to permit this requirement to be met. To meet these requirements we will need to handle one or more of the following, host uid/pwd, Eloquence uid/pwd, or some other authentication system. We currently have an optional access filter (Catalog Editor) that will be made the default method of controlling access to data.

PCI DSS 8 – Computer Access.
Currently database access is handled through Data Sources or connection strings stored either on computers or in applications. Our current plan is to move this data to the host system and only access it after the client PC has been authenticated (see 8.3). The data would be stored in an encrypted data store. The database access information will be defined at the granularity of individual columns.

PCI DSS 8.3 – Two-factor authentication.
Incorporate a transient service to prompt user for authentication at the start of a remote connection through a RADIUS or other authentication server. The information used for authentication would only exist in the current workstation (Windows) session. The information may also be eliminated after a period of inactivity. If requested, we can limit the scope to a single instance of a user application calling the ODBC driver.

PCI DSS 8.5.1 – Control of user IDs.
The database access information will be managed by administrators so that the scope of access meets each users current business needs. The access can be revoked by removing a user ID from the list of authorized users.

PCI DSS 10 – Monitor.
We can (if needed) log access information such as IP address, calling application, client username, SQL statements.
Changes to logging and debugging modes will be made to prevent the logging of data fields that can currently happen.

Question list

• Should the database access (Section 8) information also include details such as hours of access and IP address?
• Is use of Schema Editor files required?

TODO list

• Drop default implicit access for explicit control of access and logging to all columns.
• Access logging for: User - Service - Web
• Use a custom PAM that will securely log access. Base service name on value from environment file associated with each Minisoft server port.
• Do not use root for inetd.
• Do not store host or database (eloquence) uid/pwd in DSN. Store the values needed in an encrypted file on the server with access controls.
• Modify DB configuration dialogs in driver, schema editor, catalog editor, and config3kodbc.