Veikt ceturkšņa uzņēmuma drošības auditu

Kad izmantot

The quarterly scheduled audit. Not for rotating a single password after a scare — use tech.password-rotation. Not for a suspected phishing e-mail — use tech.phishing-report, which may escalate into an out-of-cycle audit. Not for a lost laptop — use tech.lost-device, which is an incident, not a review.

Pirms sāc

• The employee/contractor list is current — reconcile it with people.offboard-employee records first; an audit against a stale list finds nothing.
• The owner has confirmed which paid services count as in scope this quarter.
• The agent has read access to the domain, DNS and mail modules; it never needs to see password values, only their state.

Ko izpilde pieprasa2

Ceļš8 soļi

1. S1

   Build the inventoryaģents

   List from the modules: every mailbox, every domain with its DNS records, every device registered to a person, every paid service or login the company holds.

   Izdarīts, kad the inventory is written down with a count per category.

2. S2

   Check access against peopleaģents

   For every login, mailbox and device, name the person who holds it. Anything held by a leaver, a shared "info@" with no owner, or an unknown person goes on the findings list.

   Izdarīts, kad every access item maps to a current person, or is listed as a finding.

3. S3

   Check passwords and MFAaģents

   For each service: does it enforce MFA, and when was each password last changed? Flag services with no MFA and passwords older than the company's rotation rule. Record states only — never copy password values into the report.

   Izdarīts, kad each service shows MFA yes/no and last-change date, or is flagged "unknown".

4. S4

   Check the external surfaceaģents

   Run bc dns per domain: SPF, DKIM, DMARC present and sane (tech.dmarc-review handles deep changes; here only flag what is missing). Check HTTPS certificates against tech.ssl-expiry-check results. Run bc mail search for forwarding rules to outside addresses — a hidden forward is a classic breach sign.

   Izdarīts, kad each domain has a pass/fail line for SPF, DKIM, DMARC, certificate and forwarding rules.

5. S5

   Check backups and recoveryaģents

   Read the latest tech.backup-restore-drill record. If none exists in this quarter, that is itself a finding — a backup nobody has restored is a hope, not a backup.

   Izdarīts, kad the report states the date of the last successful restore test.

6. S6

   Review findingsīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Present findings ranked: leaver access first, then no-MFA, then external records, then everything else. The owner marks each finding: fix now, file as task, or accept as risk with a reason.

   Izdarīts, kad every finding has one of the three marks and the owner's name next to the decision.

7. S7

   Execute approved fixesaģentsvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S7 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Apply the "fix now" items: remove leaver access, disable dead mailboxes (tech.remove-mailbox covers deletions), turn on MFA where the owner approved it. For "task" items, run bc tasks add with the finding, the owner and a date.

   Izdarīts, kad each "fix now" item is verifiably done and each "task" item exists as a task.

   ⛔ Removing access or a mailbox is treated as irreversible — only what the owner marked in S6, nothing else.

8. S8

   Write the report and schedule the next runaģents

   One page: date, inventory counts, findings with their marks, fixes applied, accepted risks with reasons. Link the report from the audit calendar entry; set the next quarterly date.

   Izdarīts, kad the report is filed and the next date is in the calendar.

Pārbaudes — kā zinām, ka izdevās

• Re-read the report against the systems: the leaver marked "removed" no longer appears in any access list.
• Every finding has a mark and, for tasks, an owner and a date — no orphan findings.
• The previous quarter's findings are each either closed or carried forward with a reason.
• The next audit date exists in the calendar.

Ja noiet greizi

Ko atstāj katrs solis

1. S1the inventory is written down with a count per category.
2. S2every access item maps to a current person, or is listed as a finding.
3. S3each service shows MFA yes/no and last-change date, or is flagged "unknown".
4. S4each domain has a pass/fail line for SPF, DKIM, DMARC, certificate and forwarding rules.
5. S5the report states the date of the last successful restore test.
6. S6every finding has one of the three marks and the owner's name next to the decision.
7. S7each "fix now" item is verifiably done and each "task" item exists as a task.
8. S8the report is filed and the next date is in the calendar.

Ko saglabāt

The dated report · inventory counts · the owner's decisions in S6 (who, when) · before/after state for each fix · task ids for open findings · the accepted risks with reasons.

Kā šī procedūra uzlabojas

After every 4 runs (one year) ask: what share of findings were closed within the quarter, and did any finding repeat three times? Did any accepted risk later cause an incident? Is S1 inventory-building drifting from reality — if a check in S2 found something the inventory missed, the inventory method needs a new check, and the change note says which step changed.