Design issue re marking references

[ghost]

Adding a back-end filter on object_marking_refs encountered a complex situation. Tagging @infosec-alchemist, @mpmmasterpeace, @mushinlogit, and @j987987 for input. Apologies for the novella.

First, going over the plan:

• discover-processor, admins and org leaders would be able to create marking definitions.

  • Those created by discover-processor and admins would automatically be "published."
  • Those created by org leaders would automatically be added to their org, although the org leader could elect to publish it.

• Marking definitions need to be added to organizations, for automatic assignment to their users.

  • Admins would be able to add published marking definitions to an org.
  • Org leaders would be able to add published marking definitions to their org.
  • Whenever a new, published marking definition is created, a notification should go out to org leaders so they can choose whether to apply them to their organization.

• Users would automatically receive all the marking definitions assigned to their orgs upon login.

  • Would be default behavior for all authentication strategies.
  • Custom authentication strategies (say, high side) could override this (say, by receiving the markings from the service they call).

• Queries would be filtered by examining each datum for object_marking_refs.

  • If no object_marking_refs, the datum is unrestricted, and therefore returned to the user.
  • If the user's markings include ALL of the object_marking_refs, the datum is authorized, and returned to the user; otherwise, the datum is filtered out.

Now that you have the background, I wrote the filter (last things first, right?) and tried it, and kept failing to return attack patterns. The reason was because all the mitre-attack APs have a copyright marking reference on them. So if I merge this filter into the code here at the end of the sprint, suddenly no one will be able to get any data that has a copyright thrown on it. I don't think that makes for a nice user experience.

So, what options are there?

Well, one is to add the first two capabilities first, so that we can throw things that are open into the org accesses ahead of time. In other words, our pre-configured organizations would also be assigned all the pre-configured marking definitions.

But another question is just what is STIX intending with marking definitions and references, when all they provided for were open statements (like the copyright) and TLP? They didn't design these markings very distinctly, which is why we're adding a non-standard CAPCO definition type. We could add a "restrictive" flag to a marking definition, and when those particular markings are added to an assessment / baseline / etc., we add them to a meta property. Then the filter would run against the meta property, rather than the object_marking_refs.

Keeping in mind, I don't want to add an aggregate query to all of our queries for reading the definition for each marking reference; the filter already adds enough complexity to increase queries by ~100ms. We should avoid making it any harder than the filter algorithm explained above...

So... thoughts?...

[ghost]

Other option discussed:

• Upon login,
  • default auth helper will retrieve all marking references that are TLP or statement types, and load them into the user's auths array;
  • derived auth helpers can also retrieve markings assigned to the user (whichever way they would do that, such as the list being returned by the auth service), and add them to the user's auths array.

[ghost]

Left to do on this issue (we can close and create a separate issue, if we want; I've left this open, because the task doesn't mean anything to anyone except on the high side):

• Check the system's cert against CASPORT to load marking references into the STIX store (this should be an automated process that executes periodically, say every 24 hours; would like there to be a REST endpoint that forces a recheck, too).

• Get CASPORT login to include loading the user's markings, comparing them against the STIX store, and adding the references to those markings to the user object.

• Get the CASPORT login to complete by passing the user object out to the passport library's success method.

• Re the first point, would like a REST endpoint for admins to check a user's DN against CASPORT (for privacy concerns, it can just return system email address and marking references).