Improve data structure and lifecycle

Current workflow is something like:

1. src/tools/sync-issues.sh "updated:>=2022-04-25"
2. src/tools/generate-README.md.py
3. src/tools/retrieve-articles.sh

kehlarn> is your pinned tweet just a http://tria.ge for unix specific malware w some attack/stix attribution actually going to be modeled or just stay a limited mind map or?

timb_machine> Excluding the obvious challenges of time, the most recent changes have been to add more structure and automation such that I can restructure the data to support varying use cases and answer specific questions. Certainly don't envisage it remaining flat (but ever growing) list.

timb_machine> A simple example, I'd like to get to a point where it contains sufficient structured data to for example support automated auditd policy generation.

timb_machine> It's a great question though. Having all this data, what uses can it be put to? I feed bits into ATT&CK, but there must be more direct paths for consumption.

kehlarn> yea as i was trying to search through to find if you had recent threads i found myself exporting the entire issue base (no api for it. meh) and then reindexing into json. then i found the attack enterprise matrix and saw how you could merge them somewhat.

kehlarn> and it had me wondering if your project was the output from processing your own merge into gh template issues. adding linkage to yara and other rulesets like auditd seemed the obvious gluestep. could import this to ELK and map SIEM flows too.

kahlern> well the wheels i was poking around w were

• [IR] yara/loki
• [EDR] auditd/apparmor?
• [INT] http://tria.ge/virustotal
• [DB] att&ck/capec/stix

kahlern> so workflow in debate: gh > intel template > gh issue > gh action > git add/commit > gha build > db.json > readme

kahlern> reason for commit is to move from issues which arent cloneable and therefore tedious to action. whether we'd go repo direct or on a pr branch is up for debate

timb_machine> I guess if I get the JSON in the threats directory to be formatted as human readable, then it would be editable.

timb_machine> That workflow works for me in essence.

kahlern> well i was thinking if you tag an issue as 'accepted' or whatever that means this will get commited to the intel repo. that kicks a build that slurps the repo and produces the json and then to index

kahlern> and the accepted predicate tag prevents pr and issue bombers and other malformedness. we can lint the repo introduction too for paranoia on keywords/categories