Owners, due dates and campaigns

A finding says something is wrong. Remediation is who answers for it, by when, what happens when that date passes, and how the people involved are told.

All of it is managed-mode only, and all of it is receiver state.

What is in the review queue

Governance > Review queue holds four kinds of finding, in the same three columns (open, acknowledged, accepted):

The findings are derived from the log store over the reporting window, as ever. What is stored is only the human side: the response (acknowledged, or accepted with a reason), the owner and due date, and the Jira issue.

Owners and due dates

Open a finding and give it an owner and a due date, with an optional note. The owner is an owner or admin account: the people who make decisions answer for findings. Viewers and team viewers can read who owns a finding and cannot change it.

• Two days before the due date, the owner is emailed a reminder.

• Once the date passes with no accepted response, every owner and admin is told, by email and the webhook.

Each is sent once. A notice counts as sent only when it reached somebody - an address the mail server took, or a webhook that is set - so a deployment with neither sends nothing, and the finding says no notice has gone, until one is set up. Changing the owner or the date starts the notices again. Accepting the finding, or the finding no longer being observed, stops them.

The receiver checks every REMEDIATION_CHECK_MINUTES (default 15).

New matches and broken conditions

The portal tells the receiver what every rule and every approval's conditions match, every POLICY_CHECK_MINUTES (default 15). What is new since the last check is told to owners and admins once: a rule that says to tell them, and every newly broken approval. It also names the owned findings that are no longer observed, which is what stops their reminders.

This runs with the portal's own credential, RECEIVER_PORTAL_TOKEN. Without it the check does not run, and the portal says so at start. An empty window sends nothing: a log store that did not answer would otherwise read as every finding resolving at once.

Campaigns

A campaign is one message to the people behind personal-account findings. Governance > Campaigns.

1. Draft it. Choose the tools (none means every tool), whether acknowledged findings count too, and write the subject and message. {name}, {tools} and {accounts} are filled in for each person. Accepted findings are never included. A finding with no person attached is counted and left out: there is nobody to write to.

2. Check the addresses. Each person is shown with the address the message would go to, and where it came from:

• the identity map, first, because somebody put it there;

• the person's sign-in name, where it is an address at one of your
  corporate domains - which is how Entra names people;

• a Budget member whose address or name matches, where exactly one does.

Anyone left has no address. Type theirs in, and it is saved into the identity map, so the next map download carries it; or leave them out of the campaign.
3. Send it. Sending is held until everyone in the campaign has an address and mail is set up. Each person gets their own message, once. A sent campaign is a record: it cannot be edited, sent again or deleted.

Afterwards the campaign shows, for each person, whether the message was delivered, and whether the personal-account use it was about has been seen since it went. That is within the reporting window, and a device that stopped reporting looks the same as a person who stopped, so check detection sources before closing a finding on it.

Mail from a security tool telling people what to do is easy to imitate. Keep links out of the message and say who to ask instead.

The identity map's email column

The identity map takes an optional third column:

key,identity,email
C02XXXX,jo.bloggs,jo.bloggs@example.com
jo.bloggs,Jo Bloggs

A two-column map loads exactly as before, and uploading one keeps the addresses already saved. An address saved for somebody with no row gets a row of their own name.

Jira

Settings > Integrations connects one Jira site: the site address (https), the account email and an API token (or, for Jira Data Center, a personal access token and no email), the project key and the issue type. Saving tries the connection and says what happened; a connection that fails is still saved, with the reason.

With it connected:

• a finding's record has Raise a Jira issue;

• the review queue can raise one issue for every open finding without one, each on its own, reporting any Jira refused;

• a campaign's page can raise one for the campaign.

An issue is raised once per finding, labelled nyxus, with a link back to the finding. Its status is read back on the remediation timer and shown on the finding and on its card in the queue. Nothing is raised on its own, and a finding's response is never changed by its issue's status.

The token is kept by the receiver, like a Budget vendor API key: recoverable, because the receiver has to present it to Jira, and returned by no route. See SECURITY.md.

Settings

Mail is the same outbound mail the invites use (Settings > Display & alerting > Email); the webhook is webhook_url.