Adding MISP Suricata Rules, 'so-rule-update' error.

[sjnhawk]

I've exported some Suricata rules from MISP and added them to my local rules using the method outlined in the Security Onion documentation (https://docs.securityonion.net/en/2.3/local-rules.html), however when I run 'so-rule-update' after 'salt-call state.highstate', I receive the following error:

2023-04-24 02:46:10,563 - - Loading ./rulecat.conf.
2023-04-24 02:46:10,565 - - Forcing Suricata version to 6.0.
2023-04-24 02:46:10,565 - - Fetching https://rules.emergingthreats.net/open/suricata-6.0.0/emerging.rules.tar.gz.
100% - 3843560/3843560
2023-04-24 02:46:13,392 - - Done.
2023-04-24 02:46:13,508 - - Ignoring file rules/emerging-deleted.rules
2023-04-24 02:46:13,508 - - Loading local file /opt/so/rules/nids/local.rules
2023-04-24 02:46:19,437 - - failed to parse rule:
Traceback (most recent call last):
File "/usr/local/bin/idstools-rulecat", line 12, in
sys.exit(main())
File "/usr/local/lib/python3.9/site-packages/idstools/scripts/rulecat.py", line 861, in main
rules += idstools.rule.parse_fileobj(
File "/usr/local/lib/python3.9/site-packages/idstools/rule.py", line 361, in parse_fileobj
rule = parse(buf + line, group)
File "/usr/local/lib/python3.9/site-packages/idstools/rule.py", line 317, in parse
rule[name] = int(val)
ValueError: invalid literal for int() with base 10: 'XX'

Any thoughts? I did have one rule that didn't work and it explicitly identified that rule and I removed it. This looks like something happening with idstools, but not sure there.