JIRA Priority based on vulnerability severity

[Wilks1]

Hi Stephen,

I've seen your post relating to this on another thread.

I've added the following to the config.yaml file -

tenable:
  severity_prioritization:
    critical: 1
    high: 2
    medium: 3
    low: 4

However, the JIRA tasks are still being imported with an unassigned priority in JIRA.

Am I missing something?

Thanks

[SteveMcGrath]

Are you on the latest version? You really need to be on 1.1.17 or better.

[Wilks1]

Yep, setup the integration for the first time at the start of this week.

[SteveMcGrath]

whats the whole config look like?

[Wilks1]

tenable:
  # Tenable.io or API Access Key
  access_key: (redacted)

  # Tenable.io or API Secret Key
  secret_key:  (redacted)

jira:
  # The API Token to use to authenticate to the Jira application
  api_token:  (redacted)

  # The User that will be authenticaing to the Jira application
  api_username:  (redacted)

  # The address pointing to the Jira application.
  address:  (redacted)

project:
  # The lead account id for the primary user for the project.
  leadAccountId:  (redacted)

# The following log definitions are optional.  Only specify these if you want
# to change the default logging behavior of only outputting warnings and errors
# to the screen.
log:
  # What is the logging level desired?  Available levels are:
  #   debug, info, warn, error
  # The default level if unspecified is "warn"
  level: warn

  # If you would like the log output to goto a file instead of standard output,
  # then specify the filename here:
  filename:  (redacted)

# The following section is optional.  You should only specify this section if
# you would like the bridge to run as a service with it's own timer.
service:
  # How many hours should we wait between jobs?  Note setting this to a
  # non-zero number will result in imports past the initial import will use
  # time of the last completed import as the basis for last observed.
  interval: 24

screen:
  jira_ids:
    - 15134
    - 15135

severity_prioritization:
  critical: 1
  high: 2
  medium: 3
  low: 4

`

[SteveMcGrath]

The first section should look like this:

tenable:
  access_key: A
  secret_key: B
  severity_prioritization:
    critical: 1
    high: 2
    medium: 3
    low: 4

[Wilks1]

That has worked for about 25 entries of 350...

Something is going wrong, I'll investigate further tomorrow.

Do you need DEBUG logs?

[SteveMcGrath]

Did the integration only process those entries?

[Wilks1]

It doesn't seem so from looking at debug logs.

It is processing within the integration a number of VULN IDs that are not being edited within JIRA.

When the integration was last ran it updated the description of 12 vulnerabilities. Running the integration again gets the same exact updates to the descriptions of the same vulnerabilities.

Example of debug log where there is an entry in the integration but nothing propogated to JIRA.

Example -

2021-01-22 10:41:42,794 tenable_jira.jira.Jira INFO UPDATED VULN-272 [10.25.52.227/443/TCP] [143221] ESXi 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2020-0026)
2021-01-22 10:41:42,795 tenable_jira.jira.Jira DEBUG Request:{"method": "PUT", "url": "https://(redacted)/rest/api/3/issue/41987", "params": {"notifyUsers": "true", "overrideScreenSecurity": "false", "overrideEditableFlag": "false"}, "body": {"fields": {"project": {"key": "VULN"}, "issuetype": {"id": "10004"}, "customfield_10934": "Tenable.io", "customfield_10936": "7.2", "customfield_10937": "5.3", "customfield_10938": "7.8", "customfield_10939": "6.8", "customfield_10940": "2020-11-19T00:00:00Z", "customfield_10941": "143221", "customfield_10942": "Misc.", "customfield_10943": "ESXi 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2020-0026)", "customfield_10944": "High", "customfield_10945": ["35b6235d-65db-4e06-87ff-6194e7fe3195"], "customfield_10946": ["(Redacted)"], "customfield_10947": "90:B1:1C:AC:34:03", "customfield_10948": ["10.25.52.227"], "customfield_10950": ["10.25.52.227"], "customfield_10953": "00000000-0000-0000-0000-000000000000", "customfield_10954": "2020-12-01T03:03:15.553+0000", "customfield_10955": "2021-01-19T02:46:41.254+0000", "customfield_10957": "OPEN", "customfield_10958": "443", "customfield_10959": "TCP", "customfield_10962": "9.2", "summary": "[10.25.52.227/443/TCP] [143221] ESXi 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2020-0026)", "description": {"version": 1, "type": "doc", "content": [{"type": "heading", "attrs": {"level": 1}, "content": [{"type": "text", "text": "Description"}]}, {"type": "paragraph", "content": [{"type": "text", "text": "According to its self-reported version number, the remote VMware ESXi host is version 6.5, 6.7 or 7.0 and is affected\nby multiple vulnerabilities. \n\n  - A use-after-free error exists in the XHCI USB controller. An unauthenticated, local attacker with local\n    administrative privileges on a virtual machine can exploit this, to execute code as the virtual machine's\n    VMX process running on the host. (CVE-2020-4004)\n\n  - A privilege escalation vulnerability exists in ESXi due to how certain system calls are managed. An\n    authenticated, local attacker with privileges within the VPM process can exploit this, when chained with\n    CVE-2020-4004, to obtain escalated privileges. (CVE-2020-4005)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber."}]}, {"type": "heading", "attrs": {"level": 1}, "content": [{"type": "text", "text": "Solution"}]}, {"type": "paragraph", "content": [{"type": "text", "text": "Apply the appropriate patch as referenced in the vendor advisory."}]}, {"type": "heading", "attrs": {"level": 1}, "content": [{"type": "text", "text": "Output"}]}, {"type": "paragraph", "content": [{"type": "text", "text": "\n  ESXi version    : 6.7\n  Installed build : 14320388\n  Fixed build     : 17167734\n"}]}]}, "parent": {"key": "VULN-271"}}}}
2021-01-22 10:41:43,067 urllib3.connectionpool DEBUG https://(redacted)443 "PUT /rest/api/3/issue/41987?notifyUsers=true&overrideScreenSecurity=false&overrideEditableFlag=false HTTP/1.1" 204 0
2021-01-22 10:41:43,072 tenable_jira.jira.Jira DEBUG Request:{"method": "POST", "url": "https://(redacted)/rest/api/3/search", "params": {}, "body": {"jql": "project = \"VULN\" and issuetype = \"Task\" and status not in (Closed, Done, Resolved) and \"Tenable Plugin ID\" ~ \"134862\""}}
2021-01-22 10:41:43,468 urllib3.connectionpool DEBUG https://(redacted):443 "POST /rest/api/3/search HTTP/1.1" 200 None
2021-01-22 10:41:43,471 tenable_jira.jira.Jira INFO UPDATED VULN-85 [134862] Apache Tomcat AJP Connector Request Injection (Ghostcat)
2021-01-22 10:41:43,472 tenable_jira.jira.Jira DEBUG Request:{"method": "PUT", "url": "https://(redacted)/rest/api/3/issue/41800", "params": {"notifyUsers": "true", "overrideScreenSecurity": "false", "overrideEditableFlag": "false"}, "body": {"fields": {"project": {"key": "VULN"}, "issuetype": {"id": "10003"}, "customfield_10935": ["CVE-2020-1745", "CVE-2020-1938"], "customfield_10936": "7.5", "customfield_10937": "5.9", "customfield_10938": "9.8", "customfield_10939": "8.8", "customfield_10940": "2020-03-01T00:00:00Z", "customfield_10941": "134862", "customfield_10942": "Web Servers", "customfield_10943": "Apache Tomcat AJP Connector Request Injection (Ghostcat)", "priority": {"id": "2"}, "customfield_10944": "High", "customfield_10962": "9.6", "summary": "[134862] Apache Tomcat AJP Connector Request Injection (Ghostcat)", "description": {"version": 1, "type": "doc", "content": [{"type": "heading", "attrs": {"level": 1}, "content": [{"type": "text", "text": "Description"}]}, {"type": "paragraph", "content": [{"type": "text", "text": "A file read/inclusion vulnerability was found in AJP connector. A\n remote, unauthenticated attacker could exploit this vulnerability to \nread web application files from a vulnerable server. In instances where\nthe vulnerable server allows file uploads, an attacker could upload \nmalicious JavaServer Pages (JSP) code within a variety of file types \nand gain remote code execution (RCE)."}]}, {"type": "heading", "attrs": {"level": 1}, "content": [{"type": "text", "text": "Solution"}]}, {"type": "paragraph", "content": [{"type": "text", "text": "Update the AJP configuration to require authorization and/or upgrade the Tomcat server to 7.0.100, 8.5.51, 9.0.31 or later."}]}]}}}}
2021-01-22 10:41:43,731 urllib3.connectionpool DEBUG https://(redacted):443 "PUT /rest/api/3/issue/41800?notifyUsers=true&overrideScreenSecurity=false&overrideEditableFlag=false HTTP/1.1" 204 0
2021-01-22 10:41:43,733 tenable_jira.jira.Jira DEBUG Request:{"method": "POST", "url": "https://(redacted)/rest/api/3/search", "params": {}, "body": {"jql": "project = \"VULN\" and issuetype = \"Sub-task\" and status not in (Closed, Done, Resolved) and \"Tenable Platform\" ~ \"Tenable.io\" and \"Tenable Plugin ID\" ~ \"134862\" and \"Tenable Asset UUID\" = 735e65ee-5947-457c-b21e-9f1a58760913 and \"Device IPv4 Addresses\" = 10.25.77.89 and \"Device IPv6 Addresses\" is EMPTY and \"Vulnerability Port\" ~ \"8009\" and \"Vulnerability Protocol\" ~ \"TCP\""}}
2021-01-22 10:41:44,180 urllib3.connectionpool DEBUG https://(redacted):443 "POST /rest/api/3/search HTTP/1.1" 200 None

[SteveMcGrath]

Jira appears to be returning a 204 response code, which tells me that Jira thinks that there is nothing to update:

https://httpstatuses.com/204

[Wilks1]

Ahhh, I think its only changing priority on the "Tasks" and "subtasks" are being left as unknown priority.

Is there something that I can change to make subtasks use the priority of their top level task?

Thanks

[SteveMcGrath]

1.1.19 uploaded with the fix.

[Wilks1]

Hi Steve,

I've pulled the new updates down and ran the integration again.

No change to the unknown priority vulnerabilities. Thought I would mark all the unassigned as "Done" to force the integration to create new issues.

The integration is now creation new issues but still with the unassigned priority.

Thanks

[SteveMcGrath]

please send a debug.

[Wilks1]

Noticed that the version in the debug log was showing as 1.1.18 still. I have done another fetch/reset etc and the status is definitely 1.1.19. Its just showing different in debug.

[SteveMcGrath]

1. to build a debug, please use the --troubleshoot flag.
2. after looking through that log, it looks to only be passing the priority param to issuetype 10003 and not 10004.
3. The fact that the version is still 1.1.18 is concerning. You may need to re-install the package with a pip install -Ue . if you want to package to be installed in an "editable" way.

[Wilks1]

Did a fresh install and now working correctly on 1.1.19.

Thanks for your support Steve and the prompt fix.

All the best