Error creating Jira issue for T1001

[ScooterSec]

I tried running this in a free trial version and everything went smoothly. When trying to run in on my company's instance I got the following error. Is there something custom with my company's instance that I need to look for in order to figure out what may be causing this? I am running the latest version from the master branch and have tried with multiple API keys.

[*] Creating Jira issues for ATT&CK's techniques... [!] Error creating Jira issue for T1001 {"errorMessages":[],"errors":{"customfield_10110":"Field 'customfield_10110' cannot be set. It is not on the appropriate screen, or unknown.","customfield_10111":"Field 'customfield_10111' cannot be set. It is not on the appropriate screen, or unknown.","customfield_10112":"Field 'customfield_10112' cannot be set. It is not on the appropriate screen, or unknown.","customfield_10113":"Field 'customfield_10113' cannot be set. It is not on the appropriate screen, or unknown.","customfield_10114":"Field 'customfield_10114' cannot be set. It is not on the appropriate screen, or unknown."}}

[mvelazc0]

Hello @ScooterSec !

A couple of questions

• Is your company instance also a Jira cloud instance ? Or is it Jira on premise ?
• Are you an administrator on your company's Jira instance ?

This may be a permissions issue, we have only tested attack2jira in a greenfield environment where our users are administrators. However, it seems that the project was created and the errors only showed up when trying to create the tickets correct ?

[ScooterSec]

It is a Jira Software Cloud instance. I am and administrator on this instance, and yes the errors only show up when trying to create the tickets.

[ScooterSec]

Get request for my permissions returns the following results

https://####.atlassian.net/rest/api/3/mypermissions?permissions=BROWSE_PROJECTS%2CEDIT_ISSUES

{"permissions":{"BROWSE_PROJECTS":{"id":"10","key":"BROWSE_PROJECTS","name":"Browse Projects","type":"PROJECT","description":"Ability to browse projects and the issues within them.","havePermission":true},"EDIT_ISSUES":{"id":"12","key":"EDIT_ISSUES","name":"Edit Issues","type":"PROJECT","description":"Ability to edit issues.","havePermission":true}}}

[ScooterSec]

Do I need System_Admin permissions. I have ADMINISTER and ADMINISTER_PROJECTS?

{ "permissions" : { "ADMINISTER" : { "description" : "Create and administer projects, issue types, fields, workflows, and schemes for all projects. Users with this permission can perform most administration tasks, except: managing users, importing data, and editing system email settings.", "havePermission" : true, "id" : "0", "key" : "ADMINISTER", "name" : "Administer Jira", "type" : "GLOBAL" }, "ADMINISTER_PROJECTS" : { "description" : "Ability to administer a project in Jira.", "havePermission" : true, "id" : "23", "key" : "ADMINISTER_PROJECTS", "name" : "Administer Projects", "type" : "PROJECT" }, "SYSTEM_ADMIN" : { "description" : "Ability to perform all administration functions. There must be at least one group with this permission.", "havePermission" : false, "id" : "44", "key" : "SYSTEM_ADMIN", "name" : "Jira System Administrators", "type" : "GLOBAL" } } }

[mvelazc0]

Thanks @ScooterSec . Are you open to doing a zoom session one of these days ? I'd like to understand where it failed, it seems the project was created, the custom fields, etc. Do you happen to have to initial output ?

[mvelazc0]

About the permissions: I honestly dont have an answer for that. Its a great question and I do want to research the answer.

[ScooterSec]

here is the entire output. I would be up to hopping on a zoom call as well.

Jira API Token for ####: [] Authenticating to https://####.atlassian.net... [!] Success! [] Creating the Att&ck project... [!] Success! [!] Found custom fields [] Adding custom fields to ATTACK's default screen tab ... [!] Done!. [] Hiding unnecessary fields from ATTACK's issue layout... [!] Done. [] Obtaining ATT&CK's techniques... [!] Done! [] Creating Jira issues for ATT&CK's techniques... [!] Error creating Jira issue for T1001 {"errorMessages":[],"errors":{"customfield_10110":"Field 'customfield_10110' cannot be set. It is not on the appropriate screen, or unknown.","customfield_10111":"Field 'customfield_10111' cannot be set. It is not on the appropriate screen, or unknown.","customfield_10112":"Field 'customfield_10112' cannot be set. It is not on the appropriate screen, or unknown.","customfield_10113":"Field 'customfield_10113' cannot be set. It is not on the appropriate screen, or unknown.","customfield_10114":"Field 'customfield_10114' cannot be set. It is not on the appropriate screen, or unknown."}}

[jonod8698]

To add to the above. I have tried master & release 1.3 in our production and test tenant which were created more than 6 months ago. Received the exact same error.

However, I just spun up a new trial tenant - works perfectly without issues.

That leads me to believe the issue is related to pre-existing workflows/screens as duplicate ones are created if the script is run more than once e.g. due to a failure on the first attempt.

[thuettenmueller]

I'm facing the same problem. Manually inspecting the created project reveals that the custom fields have NOT been added to the screen and subsequently it fails to create any issues. Is there a way to run the script but only create the issues? the few custom fields can easily be added by hand after the project is created but the script aborts if the project already exists.

[slw07g]

Probably need to check the status code that is returned here

[PtrSt2]

I stumbled upon the same problem recently and can provide the explanation and solution that worked for me.

It looks like the Attack API currently (Jan 2023) may provide inconsistent data in a way described below. The data sources obtained via the get_data_sources() function are different than the ones that are returned by get_techniques(). get_data_sources() currently produces 40 unique results whereas the number of unique data sources "attached" to the results returned by get_techniques() exceeds 100.

It later leads to errors like this one in creating Jira issues. What exactly happens is a completely different set of values of data sources is obtained from get_techniques() and it is then attempted to be mapped on the datasources custom field in Jira (or more precisely, mapped on the field's options to be selected) that had already been preconfigured by the script to use that other value set from get_data_sources().

I fixed it in the fork below: https://github.com/PtrSt2/attack2jira_2023/tree/fixed-issues

Hope it helps at least some of you.

[mvelazc0]

hey @PtrSt2 !! It would be great to incorporate your fix to the main project. Is that something you are interesting in doing ? I would mention you on the project. If not, I'll merge the changes myself but wanted to ask first.

Thanks!

[PtrSt2]

Hi @mvelazc0 ! Thank you for your reply. I will be very happy to contribute to the main project. I have just updated my code and will raise a pull request soon.

Let me use this opportunity to share that I am a big fan of your project and the idea and will gladly help in the future too!

Thanks!

[mvelazc0]

Appreciate the kind words. Yeah, I think its time to pick up development ! I'll ping you.

[mvelazc0]

@PtrSt2 tested your changes and merged them. Thanks !

I'll reach out to continue chatting about attack2jira.