BED-4907: Edge type shortcuts

[brandonshearin]

Description

Describe your changes in detail

i added two new edges to our schema in cue, ALL_AD_ATTACKS and ALL_AZ_ATTACKS.

this change tweaks the logic of the cypher emitter when it is converting SQL AST->cypher string. when emitting for a relationship pattern in formatRelationshipPattern, if the provided AST node has the graph.Kind of "ALL_AD_ATTACKS" or "ALL_AZ_ATTACKS", then that graph.Kind is replaced with the full expansion of pathfinding edges defined in cue. the pre built queries now utilize these two edges.

for example, when a user provides the query:

match p = ()-[:ALL_AD_ATTACKS]->() return p

it gets translated to the following cypher:

match p = ()-[:Owns|GenericAll|GenericWrite|WriteOwner|WriteDacl|MemberOf|ForceChangePassword|AllExtendedRights|AddMember|HasSession|Contains|GPLink|AllowedToDelegate|TrustedBy|AllowedToAct|AdminTo|CanPSRemote|CanRDP|ExecuteDCOM|HasSIDHistory|AddSelf|DCSync|ReadLAPSPassword|ReadGMSAPassword|DumpSMSAPassword|SQLAdmin|AddAllowedToAct|WriteSPN|AddKeyCredentialLink|SyncLAPSPassword|WriteAccountRestrictions|WriteGPLink|GoldenCert|ADCSESC1|ADCSESC3|ADCSESC4|ADCSESC5|ADCSESC6a|ADCSESC6b|ADCSESC7|ADCSESC9a|ADCSESC9b|ADCSESC10a|ADCSESC10b|ADCSESC13|DCFor|SyncedToEntraUser]->() return p

Motivation and Context

This PR addresses: BED-4907

Why is this change required? What problem does it solve?
we want to have edge type shortcuts for common cypher statements that are currently very laborious to craft.

How Has This Been Tested?

Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc.
unit tests have been added to poke different ways that the emitter expands the new edge kinds

Screenshots (optional):

Types of changes

• Chore (a change that does not modify the application functionality)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Database Migrations

Checklist:

• I have met the contributing prerequisites
  • Assigned myself to this PR
  • Added the appropriate labels
  • Associated an issue: Issues and Pull Requests README #672
  • Read the Contributing guide: https://github.com/SpecterOps/BloodHound/wiki/Contributing
• I have ensured that related documentation is up-to-date
  • Open API docs
  • Code comments (GoDocs / JSDocs)
• I have followed proper test practices
  • Added/updated tests to cover my changes
  • All new and existing tests passed

[elikmiller]

I realize this PR is still a draft but I have a concern with the proposed solution here.

If, for example, a user ran the following cypher via the UI what is the expected result?

CREATE (a:User {name: 'Alice'})-[:ALL_AZ_ATTACKS]->(b:User {name: 'Bob'})

And what happens if they wanted to query this relationship later?

MATCH p=()-[:ALL_AZ_ATTACKS]->() RETURN p

[elikmiller]

Here is another scenario which I think is worth considering. What if a user wants to find all non-attack path relationships in the graph? A query like MATCH p=()-[r]->() WHERE NOT r:ALL_AD_ATTACKS RETURN p LIMIT 500 seems correct however running this query will happily return you many relationships which are indeed attack paths.

Here is an example using our test dataset.

My suggestion is to re-evaluate the current implementation (query transformation) and instead consider adding relationship properties to the graph to indicate whether or not an edge represents a valid attack path.

[elikmiller]

Please see my previous comments!