Security in Issuetrak

In any given application, there are multiple levels, methods, and implementations of security.  Issuetrak is no different.  From web traffic to connection strings to user credentials, there are different security mechanisms at work in different areas of the product.  This article exists to specify many of Issuetrak's security implementations.  Additionally, this page serves to provide more information than what is provided on our website.

Did you actually want to read about the Security page in Issuetrak?  Click here to read about that instead.

Issuetrak Cloud

Before we get into the security measures within the product and within the Issuetrak Cloud, it's a good idea to see the division of security responsibilities.

Below is a chart that shows what you are responsible for as the customer and administrator of your site, what Issuetrak is responsible for as the custodian of your data, and what Amazon Web Services (AWS) is responsible for as the infrastructure provider. 

Connection Strings

Connection strings are used by a web server to specify the basic connection and authentication information to use when connecting to another server.  Issuetrak is divided into four entities that handle different aspects of the product and intercommunicate.  Each of these entities use different connection strings.  

  • Classic ASP:  Optional DPAPI encryption is supported.  You can learn how to use DPAPI encryption in this article.  
    File is called Connection-Strings.asp and is located in the Connect folder within Issuetrak's web directory.  
  • MVC (Core) Application:  Encrypted by default. 
    File is called web.config and is located in the Core folder within Issuetrak's web directory.  
  • Services:  Encrypted by default. 
    File is called Issuetrak.Services.Global.xml and is located in C:\Program Files (x86)\Issuetrak\Common\Configuration\Services
  • API Application (Optional):  Encrypted by default. 
    File is called web.config and is located in the API folder within Issuetrak's web directory.

Web Traffic

This section explains how Issuetrak configures sites to behave within Internet Information Services (IIS).  

HTTP Module

We've added HttpModuleLoader via Issuetrak.Middleware.HttpModule.dll into the product.  This provides the framework for various security remediations. 

Request Filtering

These settings can be found in the Request Filtering section of each Issuetrak site in IIS.  Some of these will only be displayed by clicking Edit Feature Settings along the right-hand side.  

  • Request strings containing less-than (<) or greater-than (>) signs are denied by default.  Such request strings could allow malicious content to be injected into a page.  
  • GET and POST request verbs are allowed on the Core, Classic, and API sites, while the PUT verb is allowed only on API sites.  
  • Verbs not explicitly listed as allowed are disallowed.
  • The API site, if deployed, is configured to allow double escaping.  
  • Maximum allowed request content length for the Core site is capped at 52,428,800 bytes.
  • Maximum allowed request content length for the API site is 50,000,000 bytes.  
  • Maximum URL length in bytes is set to 2048 for all Issuetrak sites.
  • Maximum query string in bytes is set to 1024 for all Issuetrak sites.  

Additionally, here is a list of HTTP request headers that are filtered, along with their maximum request lengths:

URL Rewrite Rules

The Issuetrak deployment tools leverage the IIS URL Rewrite module to set inbound rewrite rules and outbound HTTP response headers.  These rules can be disabled as needed.  The information below explains what rules are deployed, what they are for, and when they might be deployed in a disabled state.  Inbound rules modify the way the server processes incoming requests.  Outbound rules modify the information the server would normally send in its outbound traffic.  In the case of Issuetrak, the Outbound rules are being used to deploy certain HTTP response headers.  

Inbound Rule:  Redirect HTTP to HTTPS

This rule captures traffic on the HTTP binding for the site and redirects it to the HTTPS binding with a 302 redirect if the following conditions are true:

  • Another HTTP to HTTPS rewrite is not already present.
  • An HTTPS binding exists for the site.
  • A valid certificate exists for the SSL binding.
  • The subject of the certificate matches the hostname of the SSL binding for the site.

Note: If any condition above is false, then the redirect is deployed in a disabled state, and the site will remain functional and accessible.  If the site is inaccessible after deploying Issuetrak 11.3, ensure that this rule is disabled. 


Outbound Rule:  Remove 'SameSite=None' Response Header 

This rule removes the 'None' attribute from the SameSite response header, as it is less secure than having the attribute of 'Lax' described below.


Outbound Rule:  Add  'SameSite=Lax' Response Header 

This rule provides a measure of protection against Cross-Site Request Forgery (CSRF).


Outbound Rule:  Set 'X-Frame-Options SAMEORIGIN' Response Header 

This rule indicates to the browser that the given page can only be displayed in a frame on the same origin as the page itself.


Outbound Rule:  Add 'HttpOnly' To Set-Cookie Response Header 

This rule prevents the browser from letting client-side scripts access the cookie, and therefore provides protection against Cross-Site Scripting (XSS) attacks.  


Outbound Rule:  Add 'Secure' To Set-Cookie Response Header

This rule tells the browser to only send the cookie over a secure connection.  This rule only works if the server has a valid SSL configuration, and is deployed in a disabled state if SSL isn't configured on the server.  If the site is inaccessible after deploying Issuetrak 11.3, ensure that this rule is disabled. 


Outbound Rule:  Set Server Response Header

The default server from a website contains potentially sensitive information about the server environment.  This change removes that information from the default server response.


Outbound Rule:  Set Content-Security-Policy Response Header for HTTP

This header determines which sources of content are whitelisted for the browser to load over HTTP.  This provides some protection from Cross Site Scripting attacks.  


Outbound Rule:  Set Content-Security-Policy Response Header for HTTPS

Same as above, but applies to HTTPS sources.  


Outbound Rule:  Set Strict-Transport-Security Response Header

This header directs the browser to never load the site via HTTP, and to communicate over HTTPS instead.  This rule is only valid when the server has a valid SSL configuration, and is deployed in a disabled​ state if SSL isn't configured on the server at the time of deployment.  When this rule is active, it provides some protection against Man-in-the-Middle attacks.  If the site is inaccessible after deploying Issuetrak 11.3, ensure that this rule is disabled. 

HTTP Response Headers

HTTP Response headers are simple name-value pairs containing content processing instructions that are communicated between a web server and browser.  In this context, we are referring to response headers sent from IIS to the web browser for the purpose of improving security from the default IIS configuration.  

Server response headers are scrubbed of text containing "Issuetrak".

Issuetrak creates a Feature-Policy header to deny all browser features not needed by the site.  This includes:

  • Accelerometer
  • Ambient light sensor
  • Autoplay
  • Camera
  • Encrypted media
  • Fullscreen
  • Geolocation
  • Gyroscope
  • Magnetometer
  • Microphone
  • Midi
  • Payment
  • Picture-in-picture
  • USB
  • VR

Additional response headers are also implemented:

  • Referrer-Policy origin header is deployed with the value of "same-origin". 
    When navigating from an Issuetrak site to another site, information about the referring page is often included when communicating with the web server for the second site.  This header controls how much information is provided to the second site.  
  • An X-Content-Type-Options header is deployed with the value of "nosniff". 
    This header forces the browser to interpret and render only the information types specified in the site's Content-Type header.  
  • An X-Permitted-Cross-Domain-Policies header is deployed with the value "none". 
    This header prevents client software such as Adobe Flash and Acrobat from loading your site content from another domain.  
  • An X-XSS-Protection header is deployed with the value "1; mode=block". 
    Modern web browsers contain optional cross-site scripting protection.  This header tells the browser to enable cross-site scripting protection when navigating an Issuetrak site.  

Sub-Resource Integrity
Issuetrak implements Sub-Resource Integrity, which allows browsers to validate the resources they load from a site against a known value to ensure their authenticity. 
Path-Relative Stylesheet Import (PRSSI)

Every stylesheet reference in the product uses absolute URLs instead of relative URLs to prevent a Path-relative stylesheet import (PRSSI) vulnerability.

Secure Cookie Prefix

Sites that communicate over SSL add the "__Secure-" prefix to cookies sent to the browser. This instructs the browser to treat the cookies in a more secure manner.  See this page for information on cookie prefixes.

Same-Site Cookies

We implement Same-Site Cookies, which will provide some protection against Cross-Site Request Forgery (CSRF) attacks and Cross-Site Script Inclusion (XSSI).

Inter-Server Communication

Incoming Email

The Incoming Email feature is capable of using secured SSL/TLS or insecure communication with POP, IMAP, and Exchange servers.  Issuetrak communicates with the incoming email server using the exact communication settings specified in Incoming Email.  Security here is determined by the settings that were entered by the Administrator when Incoming Email was configured.  Issuetrak recommends using TLS when possible.

Outgoing Email

The Outgoing Email feature is capable of using secured SSL/TLS or insecure communication via SMTP.  Issuetrak communicates with the outgoing email server using the exact communication settings specified in Email Settings.  Security here is determined by the settings that were entered by the Administrator when Outgoing Email was configured. Issuetrak recommends using TLS when possible.

Active Directory

Active Directory integration is capable of using secured SSL/TLS or insecure communication with Microsoft AD servers.  Issuetrak recommends using TLS when possible. 

Web-to-SQL Communication

The Web server communicates with the SQL server using the strongest encryption that both servers have enabled.  Issuetrak requires that the Microsoft OLE DB Driver 18 for SQL Server to be installed on the Web server.  The Microsoft OLE DB Driver 18 for SQL Server supports TLS 1.2 communication, but does not force it.  Details for configuring the Web and SQL servers to force encrypted communication can be found from Microsoft here.  

Safeguarding User Credentials

User Passwords

Application user account passwords are secured with the NIST-recommended PBKDF-2 function, with an iteration count that exceeds current recommended standards, and that continues to increase automatically as time progresses.  For each new password stored, a new, cryptographically random 64-byte salt is generated and supplied to the function along with the plaintext password.  The hash used in the function is SHA-512.

Password hashes are retained only as long as the site administrator has configured, and plaintext passwords are never sent to the database.

Password Resets

As a security safeguard, Issuetrak requires an Administrator to validate their own password prior to performing a password reset for another user account.  

If Password Self Service is enabled, and a user has appropriate permissions, they can choose 'Forgot / Reset your password?' from the login screen, and the user is emailed a dynamically-generated link that expires after a configurable time period.  When clicked, the link will take the user to a page in the product that allows the user to set their password.  The email is valid for a period that is globally configurable from 1 to 168 hours.


Issue Auditing

If enabled, Issue Auditing allows users to view a change log of the history of subsequently-entered issues by clicking Issue Change Log along the lefthand menu while in an issue. 

Admin Auditing

If enabled, Admin Auditing makes it possible to view changes made to many settings of Issuetrak within the Administrative settings. 

Admin audits can be viewed by those with Administrative privileges by going to the gear icon in the upper right corner of Issuetrak and then choosing Admin Auditing along the lefthand menu.  The resulting Admin Audit Search page can be used to find specific types of audits, subject to whatever search criteria is entered.  

Asset Auditing

If properly licensed and enabled, Asset Auditing makes it possible for users to download and execute the ScanPC/TrakPC application on their machine.  ScanPC will scan and POST audits about the PC to the Issuetrak site.  


Logging Facilities

When Issuetrak generates log files on the Web server, it uses an application called NLog.  NLog is responsible for monitoring various Issuetrak-specific processes on the Web server for events and writing those events to logs.  NLog does not run continuously on a Web server, and is instead called by each process that relies on it for logging.  Details on the various logging locations will follow below.  

Deployment Tools

Every time a site is upgraded or deployed, the Issuetrak Deployment Tools will write an extensive log concerning the deployment to the Issuetrak distribution folder, located within Logs.  

Be aware that the logs may contain sensitive information concerning your site and environment.  As a best practice, Issuetrak recommends that the logs be removed once you have successfully deployed or upgraded your site.  

Active Directory

If logging is explicitly enabled, logs stored for Active Directory can be found within:  IssuetrakWebFolder\Core\App_Data\Logs

AD Federation Services

AD FS exposes logging to the UI when clicking the Test Connection button on the AD FS Identity Provider page. 


The API stores its logs in the Issuetrak site's web folder via the following path:  IssuetrakWebFolder\api\App_Data\Logs

Outgoing Email

There are two logs maintained for Outgoing Email: The Product log and the Service log. 

The Product log is kept for informational purposes and logs the content of every email sent from Issuetrak.  You can navigate to it by finding and clicking on the gear icon in the top right, choosing Email Settings along the lefthand menu, then clicking View Email Log within the lefthand menu. 

The Service log is generated by the Outgoing Email Service, and contains information related to the processing and sending of the emails to the SMTP server, which is useful for troubleshooting purposes.  You can find the Service log within the file structure of the Web server in:  C:\Program Files (x86)\Issuetrak\Logs

Incoming Email

There are two logs maintained for Incoming Email:  The Product log and the Service log.

The Product log is kept for informational purposes and logs the content of every email processed by Issuetrak.  You can navigate to it by finding Administration along the navigation bar in the top left, choosing Incoming Email, then clicking View Log along the lefthand menu.  

The Service log is generated by the Incoming Email Scheduled Task, and contains information related to the Web server's communication with the Incoming Email server(s), as well as receiving and processing the emails into issues.  Each log file will be up to 20MB.  Once a file reaches 20MB, a new log file is created.  Up to 10 log files will be kept.  The Service log is stored in each Issuetrak site's Web folder within:  pathto:\WebFolder\Services\IEM\Logs\

Scheduled Active Directory Imports

If Active Directory is enabled, and a scheduled task is utilized for automated import of AD users, there are two log files stored on the Web server located as follows:

  • IssuetrakWebFolder\IssueTrak_Logs\AD_Import.log (containing the results of an AD import)
  • C:\Program Files (x86)\Issuetrak\Logs\{SiteName}\AD_Import.log (containing task-specific event logging)

Scheduled Reports

If Scheduled Reports are used, a log of the Scheduled Report activity and any problems the scheduled task may have run into will appear in a log stored in three different locations: 

  • Within the Issuetrak user interface, for users that have permission to access Reports:  Reports --> Report Writer --> Scheduled Reports --> View Log.  This log displays the particulars of:  what report was run, who it was sent to, and when it was sent.
  • The Web server's IssuetrakWebFolder\Reports\RptSch_Process.log (containing the results of the scheduled reports)
  • The Web server's C:\Program Files (x86)\Issuetrak\Logs\{SiteName}\RptSch_Process.log (containing task-specific event logging)


While this isn't necessarily an exhaustive list, the information provided here is what we consider to be the most important and noteworthy security features and implementations that we have in the product.  Issuetrak conducts periodic application vulnerability scanning and auditing to improve the product.  Some security features are optional and are left to the discretion of the management for each instance of Issuetrak.  

If you are a security researcher and have discovered a security vulnerability, we appreciate your help in disclosing it to us in a responsible manner.  We ask that you keep your findings confidential and do not share or publicize any unresolved vulnerabilities with/to third parties. 

If you submit a vulnerability report, the Issuetrak security team and associated development teams will use reasonable efforts to:

  • Respond in a timely manner, acknowledging receipt of your vulnerability report
  • Investigate the reported issue and provide feedback
  • Seek your guidance in identifying or replicating the report issue
  • Let you know when the vulnerability you've identified has been fixed

Please contact us at with any relevant information so we can investigate security issues immediately.