RTS Staff

Visible to RTS staff only.

dTracker 4.1 Release.

We are pleased to announce the first release of our new Java-based dTracker system.

dTracker version 4.1 has been five years in development, from initial concept & design, through prototyping & testing, to final deployment release. Some of its benefits are:

  • Provides remote access over the Internet and can be “cloud” based.
  • Very high security, built from the ground up (meets PCI-DSS requirements).
  • Removes the requirement for MS Access and can be run on Apple machines.
  • Allows other corporate systems to be enhanced to communicate with dTracker.
  • Allows web-based systems to retrieve and update data, based on security profiles.
  • Provides a new base with which to support many more enhancements (eg. mobile apps).

It is able to co-exist with the current Access version (3.4) so that existing systems can be enhanced or upgraded in stages and office processes do not have to be redeveloped during deployment.

 

This release (4.1) is best suited to organisations who want to integrate dTracker with public or private (Intranet) websites, rather than those who may want it for remote user access. This is because although it provides a full-function program interface for operation by other systems, it has only a limited-function user interface for operation by staff. The next release (4.2, Dec 2012) will provide a full-function user interface.

New dTracker versions are free to organisations who have a current support subscription. If you do not have a current support subscription and want to deploy the new version then please contact us for renewal details.

For further information about dTracker 4.1 and its deployment please see the associated forum postings. If you have any questions or would like to discuss dTracker or this release with us, please use the contact form.

Right Track Services Inc.
30 Jan 2012

dTracker Security.

The attached document provides an overview of how dTracker version 4 provides managed access to information from anywhere at any time. (If you cannot see the attachment then please login with your user account or contact us below.)

It describes how data is protected whilst in storage and in transit, and how it is made available to designated people & corporate systems while remaining inaccessible to others. It also contains "best practice" information on how to secure dTracker's environment for maximum benefit.

This document is intended for people who have a management or oversight role, or who want assurance that providing on-line access to dTracker will not involve unacceptable risks to an organisation. It tries to avoid being too technical, but does require some familiarity with computer system concepts.

If you have any questions or would like to discuss this with us, please use the contact form or the email address mentioned in the document.

dTracker and PCI DSS.

Background

"PCI DSS" stands for Payment Card Industry - Data Security Standard. It is a policy & assessment framework which financial institutions have developed to protect electronic credit & debit card data during processing and storage.

Compliance with the PCI DSS is now mandatory in some countries for all organisations which process or store card data. This includes any mission or aid agency which might receive credit/debit card donations & payments. The industry has stated that this will be progressively extended to most, if not all, remaining countries.

However even if PCI DSS compliance is not manatory for an organisation, it represents "best practice" electronic handling of private or sensitive data. It should be a goal of all Christian organisations to apply the principles to all of their IT systems and operations.

Requirements

The implications of PCI DSS (v1.1) for dTracker are primarily in the following areas of the standard:

  • Requirement 3: Protect stored cardholder data.
  • Requirement 4: Encrypt data transmission across public networks.
  • Requirement 6: Develop and maintain secure systems and applications.
  • Requirement 7: Restrict access to cardholder data by business need-to-know.
  • Requirement 8: Assign a unique ID to each person with computer access.
  • Requirement 10: Track and monitor all access to network resources and cardholder data.

The other requirements in the standard are related more to an organisation's IT infrastructure - machines, networks, and usage policies. These are outside the scope of this document and need to be addressed by the appropriate IT support staff & management.

Compliance

All of the relevant requirements are fully covered in dTracker version 4. Specifically, a correctly installed & configured system complies with items 2.1, 2.3, 3.1-3.5, 4.1, 6.1-6.5, 7.2, 8.1-8.4 & 10.1-10.5 of the standard.

Four of the above requirements are fully covered in dTracker version 3:

  • Item 3 is covered by the fact that the database file (dTrackerData.mdb) uses MS-Access' in-built encryption. (It cannot be opened without signing in.)
  • Item 4 is not relevant because dTracker version 3 does support access from outside of the local (private) network.
  • Item 6 is covered if you apply Microsoft Office updates (part of the Windows update functions). Access to the data is controlled by MS-Access, not by dTracker.
  • Item 8 is covered if you use login passwords and do not share usernames - each person should sign into dTracker under their own name (and only their own name).

The remaining two requirements are not fully covered in version 3:

  • Item 7 is possibly covered because you must sign-in to dTracker to see the card data. If everyone who uses dTracker has [even occasionally!] a need to view it then you are fully compliant. If not, then the other users can see the data even though they do not need to.
  • Item 10 is not covered at all. Whist dTracker version 3 logs all changes to card data, it does not log access to it.

Mitigation

To be compliant while still using dTracker version 3 (from 3.3) you have the following options:

  1. Erase or truncate the Card Numbers on all past receipts and activate the function to do this for any new receipt once it has been processed. This will limit any compliance issues to the Regular Contributions - which may be sufficient, or may mean that you must also adopt the following option. However this will also require you to re-enter the card number for every new receipt.
  2. Process credit & debit cards externally in your accounting or banking systems. dTracker can be configured to permit receipts with no card number, however this may require double-handling of the payment.
  3. Item 7 can be resolved by moving all non-financial users to a later version if it has the necessary functionality. The new version can be configured to prevent them from accessing card data.

Conclusion

dTracker version 4.0 and later are fully compliant with the relevant PCI DSS requirements.

dTracker version 3.3 and later are only partially PCI DSS compliant. However there are ways of mitigating the problem issues until version 4 can be implemented.

dTracker versions 3.2 and earlier are only partially PCI DSS compliant. The only way to resolve this is to remove all card numbers from the system and process card payments externally.

Syndicate content