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:
- Content-type: 100 bytes
- Translate: 0 bytes
- If (all headers starting with If): 0 bytes
- Lock-Token: 0 bytes
- Transfer-Encoding: 0 bytes
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. |
| Set Content-Security-Policy Response Header With Embedded HTML to HTTP | Disabled by default. If enabled, allows the "Embedded HTML" setting on the Features screen to load third-party scripts via HTTP. |
| Set Content-Security-Policy Response Header With Embedded HTML to HTTPS | Disabled by default. If enabled, allows the "Embedded HTML" setting on the Features screen to load third-party scripts via HTTPS. |
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-srcset 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 (if enabled) 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 / TrakMac /TrakAsset applications 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 gear icon in the top right to open the Settings lightbox > 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 Reporting from the left menu > Scheduled Reports > Scheduled Report Logs in the right quick 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.
