Security and Privacy

Altarama Network Security

RefTracker takes security very seriously.  Our network manager is security qualified and is very happy to work with any customer who wishes to do their own penetration or other security testing.

Altarama’s network where hosted customer’s data is held is in a secure facility that has annual security compliance checks for all the appropriate security standards, such as SOC 1 Type II, SOC 2 Type II, PCI DSS, and HIPAA.  The equipment/network is for the exclusive use of Altarama, and no one other than Altarama staff has access to it.

For the ultimate in security, customers can install RefTracker in-house, so that it is protected by being on our own secure network.

Customers do not need access to the RefTracker server to be able to fully utilize their RefTracker systems.  FTPS is made available to any customer who needs to load data to this network other than through the application.

Only staff who need access to this network can access the network servers, and only staff who specifically need to be able to access the SQL server, have access to the SQL server/s.

All Altarama staff have signed a confidentiality agreement that specifically mentions that customer data belongs to the customer and must never be made available to any other party.

Of course RefTracker operators at the customer that owns that RefTracker system also have access to the data, but only in the ways that the RefTracker application provides.  Client data extraction in the application is limited to operators with Administrator privileges.  Access to the RefTracker operator functions is secured via a username and hashed password, and there are options to enforce password strength and changes.

Data is stored in an SQL database at the secure hosting facility.  It is backed up to a SAN drive external to the device running the SQL database, but on the same hardware network.  It is also backed up to an offside disaster recovery location.

Access to RefTracker can be limited by IP when required, and there is an optional SAML and OIDC SSO compliance module (click here for details of the SSO features).

RefTracker application level security

RefTracker is a totally web based application written in Visual Basic on the .Net platform, with some browser side JavaScript.  The code is written with security in mind and is checked by the VisualStudio development environment that we use.  Some of the security techniques used include the following:
– Burp suite is used to continually monitor for security improvement opportunities.
– All products that we use, like ASP are kept up to their latest release at the first opportunity to upgrade.
– ASP.NET request validation is used to prevent cross site scripting.
– On startup RefTracker checks its directory setup and will not operate if it detects it is not properly secured. If an issue is found, an email is sent to the Systems Administrator and to Altarama directly.
Sensitive fiels are protected by hidden directories, directory browsing is disallowed,, and debug is disabled.
– All user and imported email input is checked and validated to remove any executable script before it is written to the database.
– SQL injection is prevented by careful parsing and validation of all inputs to SQL queries.
– Control of a range of environmental variables ensure bad players cannot find information about the RefTracker operating environment that might help them identify possible attack vectors.
– The URL used to view attachments in the RefTracker, uses a temporary file structure based on temporary GUID’s for both file type and request number. Because they are temporary they do not reveal anything about the RefTracker file structure that would allow a bad player to access other files in RefTracker.
– The URL used to view embedded images in the RefTracker, uses a random string that points to an entry in a table that hides the real filename and data structure from bad players.
– All URL’s provided as input to RefTracker (by both staff and clients), are checked against the Google safe browsing API that checks for known URL’s that bring up malicious web sites.  Known bad site URL’s are not accepted as input to RefTracker and will be automatically removed and replaced by “* UNSAFE URL REMOVED*”.
– Functions that allow logged on Administrators to view and upload/download files for maintenance, use an obscured temporary path to the file, a security key, and limit access to only files that have already been displayed by the 917 or 918 screens that provide these functions. Further the file types that can be uploaded/downloaded are restricted as appropriate to the current directory, and all executable files are strictly forbidden.

The client interface provides open access for the general public and is designed to be able to be used by all levels of user capabilities including assistive devices, on the widest range of hardware and even the oldest browsers.    It provides extensive inbuilt server side code to ensure that it cannot be exploited by hackers or spammers, such as:
– SQL queries used by the client interface are complex, and multi layered ensuring they are not vulnerable.
– Single-use un-guessable keys are used in the query strings so that a potential hacker can’t attempt to manipulate the client side pages.  If an invalid key is detected the user is presented with the Client interface Home page so that the altered URL is never submitted to RefTracker. 
– A Client interface Request form can only be used within 20 minutes of its display, preventing spammers from taking a copy of the form and using an analysed copy at a later time to submit responses that comply with any likely validation that we might be applying.  Human users who take more than 20 minutes to fill out the form will be shown a “Session has expired” message and the form will be redisplayed with a fresh key, and the data they have provided so far included, so they can easily resubmit.
– Client side pages are checked to ensure they are being posted from the current session (not a saved page being reused by a bot).
– Client side pages include a honey trap field that ensures that any pages being completed by bots will be rejected.
– RequestValidation is enabled for all client interface pages.  If a malicious user tries to insert script or any HTML like code into a RefTracker form, they will be shown a message indicating that HTML cannot be used and that their question has not been submitted.  If they try the same thing in any other client interface page, their input will not be processed and they will be shown the system’s client home page.
– A captcha can be included in RefTracker forms but the above measures mean that it is not necessary, making our forms easier to use.
– Suspected spammer activity is logged to the “warn” log files so it can be analysed to improve these protections should they be breached.
– When new users are created, they receive a Welcome email that validates their email address and ensures that they change the password that has been set for them by their Supervisor or Administrator.

Access to the staff interface is protected by hashed password with the option for password complexity and enforcement of replacement policies (parameters 9.32-36) .  RequestValidation is applied to the login page ensuring that anyone trying to submit script through that page will be re-presented with the login page without their submission being processed.

RefTracker security that customers should consider implementing

Altarama’s customers only have HTML access to their RefTracker systems. They cannot access the server on which the application runs.  So they only have access to the security aspects that RefTracker gives them access to.  They are:
– Parameter 0.95 prevents browsers from allowing RefTracker pages to be framed within another application that could house a malicious attack.
– Parameter 0.96 HSTS allows customer to choose to only interact with https sites from RefTracker. Desirable from a security perspective, but limiting in terms of what staff can refer to in their informational responses.
– Parameter 0.97 Cache Control header allows the browser caching to be prevented. Desirable from a security perspective, but will significantly impact response times.
-Parameter 9.80 and 9.81 allow Windows defender to be used to automatically check all attachments before they are loaded into RefTracker to ensure viruses are not loaded through this mechanism. See parameter 9.80 and 9.81 in this help page for more information about setting up this important security.
– 9.x parameters are used to secure RefTracker to RefTracker (R2R) and the RefTracker Widget so that these methods can only be used by RefTracker.
– Parameters 9.5x control whether the RefTracker API methods can be used. If a method is not in use, it should be set to Disabled (the default setting). Further, for each API method an APIkey can be set in the 9.x parameters that MUST be included in the call whenever that API method is used, to ensure that the method cannot be used by unauthorised users.
– If the API is in use the api.xml file controls what domains the API can be used from.  This file needs to be set to limit where the API can be used from.
Note that the RefTracker widget uses the API, and the api.xml file allows the domain/s from which the widget can be used to be individually set. 
– The RefTracker API is also used within RefTracker, and where that is the case, the method checks either for a staff login, or that the session is an established RefTracker session if the method is used by client pages. This means that any calls to these methods that are not from RefTracker will be ignored.
Where the API is used within ReftService, the system checks that the IP of the caller is the same as the IP of the RefTracker server.  This means any call to execute a RefTracker background process must come from the same server that RefTracker is running on.  Any call from outside the network running the RefTracker server, will be ignored. For any calls that breach these rules, the response is simply terminated – no information is returned to the caller, but the attempt is recorded in the warning log. Parameter 9.5 facilitates organisations where ReftService is not runnning on the same server.
– Parameter 2.8 specifies the maximum size of files that can be provided by clients through the client interface and via email importing in order to prevent spammers from maliciously loading very large files, and parameter 2.9 specifies the maximum number of files that clients can provide with any one request (in order to prevent spammers from flooding the system with a very large number of attachments).
– Only attachment types allowed by the mimemap.xml file can be uploaded to the system.  This file may be amended by the customer, or by asking Altarama.  It is already comprehensive in that it allows all the file types usually used by libraries, does not allow access to dangerous file type like .exe, and provides appropriate controls such as only allowing .zip files to be uploaded by staff.
– The “Delete attachments” background process allows attachments to be automatically deleted after a question has been closed for more than a specified period of time.
– Parameter 2.20 can be set to Yes to log all staff members who have seen that question.  This only needs to be set on where your organisation handles requests that are, in themselves, confidential information, such as parliamentary libraries.
– Parameter 2.29 and parameters 9.30 – 9.34 allow your organisation to control how the logon/off process works in your RefTracker instance.  Set all of these parameter to suit your need for password strength, expiry, etc.
– Parameters 9.35 – 9.36 provide controls on how many times a user can unsuccessfully try to log into your RefTracker system in a specified period and will lock them out for the specified period if they exceed that number.
– Parameters 5.12- 5.17 allow SAML and OIDC compatible Single Sign-On (SSO) to be applied to your staff and/or client access.  An optional module must be purchased to be able to use these parameters.
– Parameters 5.20-21 allow you to control whether the staff log on “remember me” cookie will be able to be used.

Other security things that you should consider are:
– RefTracker is accessed through a web browser and uses JavaScript in some places.  Operators need to be able to attach files and to download files received (as allowed for by the mimemap file).  You may wish to apply some controls in the browser.
– All staff operators should have antivirus software running on their computers.
– Spam filtering should be being applied to all email addresses from which email is imported into RefTracker.

Other Privacy considerations

– There are options for putting Privacy acceptance or terms of use information into your request forms so that your user’s agreement to your privacy policy or terms and conditions is recorded – see the Privacy and Request forms (GDPR) help page for more details.
– Parameter 6.10 allows you to control the period for which clients can see their previous requests.  You might revise this setting so that clients get the impression that data is only kept for the period you set here.
– Parameter 6.12 “Allow requester to delete contact details” should be set to anything other than “Presumed” by public libraries that need to comply with GDPR requirements.  If the client uses this function to set their “Retain client data” field to “Remove on close”, their PII (such as name, email address, IP address) will be deleted and no longer available for statistical analysis, or for relating that question to that client.  Client data that cannot be used to identify the individual is retained e.g. Postcode, State Country, Locale, browser used.
– A background process “Erase client data” can be set up to automatically erase client data from questions that have been closed for more than a specified period of time, or that have been marked to indicate the client wants their contact details removed after the question is closed via the “Retain client data” field.
– There is no automatic full question deletion process in RefTracker, so that the questions are always available for statistical analysis, however you can implement a manual schedule whereby closed questions not saved into the Knowledge base or FAQ, or the PII client contact information in closed questions, are deleted after a selected period of time. 

Altarama Data Security Statement re GDPR

Altarama has always regarded client contact information as highly confidential information.  All our customer contracts bind us to keeping our customer’s data, including client contact information, confidential.  For this reason our network manager is security certified.

Where is RefTracker customer data held

RefTracker collects only the data required for the client to be able to be delivered the information that they are asking for.  The data is freely given by the client so that they can receive the requested information.

The data is stored in RefTracker in relation to that question only.

RefTracker uses an SQL database and the client contact information is stored in the client table in the SQL database specific to that customer’s RefTracker system.

Customers usually only have live databases (no development or test copies of their data).  On the rare occasions when a copy of a live database is required for testing purposes, the client and staff email addresses are all overwritten before the copied system is used for the testing.  Any copy is only held as long as it is required for resolution of the issue, after which it is deleted.

Classification of the client data held

The data held in RefTracker about a client is low risk.  It can be as little as an email address, but usually also includes name, and according to how each Request type is set up in that RefTracker system, could also include things like phone number, address, Company name or Department, and the like.  Although it could include sensitive things like Ethic origin or Sexual orientation, no customers have yet found it appropriate to collect that sort of information in order to provide answers to information requests.  RefTracker does not hold any financial information about a client

Because some client contact information is essential to being able to respond to a request, we recommend that you include a Privacy statement in your RefTracker forms, and if dealing with European clients subject to the strictest of GDPR conditions (such as Italy) you may want to also include a mandatory custom client code table called something like “Agreement to Privacy conditions”, containing just one entry “Yes”.  If the user does not want to agree to that statement they will have the option of not submitting the form – because a response cannot be provided to them unless they give this permission.

Data control

The client who submitted the request has access to the data held about their question through the RefTracker client interface, in the ways provided by the RefTracker client interface.  To utilize the client interface features, clients must provide the correct question number and the email address used for that question, or use a link provided to them via an email. 

One of the features of the client interface is a function allowing the client to remove their client contact information.  Staff can also remove just the client contact information from a specific question, when asked to, or automatically have it removed from all questions after a customer specified period of time has expired from question closure.

Data breaches

Altarama has never had a data breach or any incidents where customer data has been lost or destroyed, and we believe that the measures that we have in place will continue to prevent it.