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.
    • The file is called Connection-Strings.asp and is located in the Connect folder within Issuetrak's web directory.
  • MVC (Core) Application: Encrypted by default.
    • The file is called web.config and is located in the Core folder within Issuetrak's web directory.
  • Services: Encrypted by default.
    • The 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.
    • The 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.

URL Rewrite Rule Details:

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.

Outbound Rules
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.
Add SameSite=Lax Response Header This rule provides a measure of protection against Cross-Site Request Forgery (CSRF).
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.
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.
Add Secure To Set-Cookie Response Header This rule tells the browser to only send the cookie over a secure connection.
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.
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.
Set Content-Security-Policy Response Header for HTTPS Same as above, but applies to HTTPS sources.
Set Strict-Transport-Security Response Header This header directs the browser to never load the site via HTTP, and to communicate over HTTPS instead. When this rule is active, it provides some protection against Man-in-the-Middle attacks.
Set Cache-Control Response Header If enabled, tells the browser not to cache page data.
Set Content-Security-Policy Response Header With Chat to HTTP Disabled by default. If enabled, allows the Chat add-on to work with a site running HTTP binding.
Set Content-Security-Policy Response Header With Chat to HTTPS Disabled by default. If enabled, allows the Chat add-on to work with a site running HTTPS binding.

Note: The Redirect HTTP to HTTPS, Add Secure To Set-Cookie Response Header, and Set Strict-Transport-Security Response Header rules will be deployed in a disabled state if any of the below conditions is false.

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

If you are not using an HTTPS binding and the site is inaccessible after deploying Issuetrak 11.3+, ensure that these rules are 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 Permissions-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:

  • A 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.
  • An Expect-CT header is deployed, with the default IDU/IDM JSON configuration options set to:
    • ShouldEnforceExpectCt: false
    • ExpectCtReportUri: ""
    • ExpectCtMaxAge: 0
  • The Content-Security-Policy header is deployed with the value object-src set to none.

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 / LDAP

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 is installed on the Web server, OR that MS OLE DB Driver 19 for SQL Server is installed, so long as your environment is already configured to use it.. 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 them, 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.


Profile Change Notifications

This feature will send an email notification to the affected user (if it has a valid email address) when changes are made to their user account. To enable this feature, go to the Settings lightbox > select Outgoing Email beneath Email and check the box for Enable Notifications under the Profile Change Notifications section.


Multi-factor Authentication

Issuetrak natively supports multi-factor authentication (MFA) for users that use Issuetrak authentication.

There are two supported methods of MFA. You may select only one method to use per user account:

  • Time-based One-Time Passcode (TOTP) - An app such as Google Authenticator or Authy generates a 6-digit passcode that the user must enter in addition to their issuetrak credentials.
     
  • Email-based one-time passcode - Upon entering their credentials, they will be emailed a one-time passcode that must additionally be entered to access Issuetrak. This requires that the user has a valid email address and that Issuetrak has Outgoing Email configured and functional.

Additionally, you may decide to require all of your users to use MFA.


Auditing

 
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 in the right context 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 Settings Lightbox.

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 beneath Tools. 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

 
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.


API

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


API v2

API v2 stores its logs in the Issuetrak site's web folder via the following path: {IssuetrakWebFolder}\api\v2\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 Outgoing Email beneath Email > then selecting View Log within the right context 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 clicking on the Settings lightbox(gear icon) in the top right > choosing Incoming Email beneath Email, then clicking View Log in the right context 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: {IssuetrakWebFolder}\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: Click on Reports in the left menu > Scheduled Report Logs in the right context menu. 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)


 

Conclusion

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 reported issue
  • Let you know when the vulnerability you've identified has been fixed

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