heygrc
SOC 2 CC7.2 im Code

Bemerken, bevor es jemand anderes tut.

CC7.2 ist das SOC-2-Kriterium zur Überwachung: Erkennen von Anomalien und Sicherheitsvorfällen, um darauf reagieren zu können. Es baut auf der Protokollierung auf: Ein Protokoll zeichnet auf, dass etwas passiert ist, die Überwachung bemerkt es und schlägt Alarm. Eine Kontrolle, die nicht sichtbar in Aktion tritt, ist eine Kontrolle, auf die man nicht reagieren kann. Deshalb gibt es für die Erkennung ein eigenes Kriterium.

How it shows up in a diff

The shapes the same control failure takes.

CC7.2 wird geschwächt, wenn eine Änderung leise verkleinert, was das System bemerken kann. Die wiederkehrenden Muster:

  • Eine Warnregel wird gelöscht

    Eine Regel, die bei einer Sicherheitsbedingung ausgelöst wurde (z. B. ein Anstieg fehlgeschlagener Logins oder eine unerwartete Berechtigungserteilung), wird entfernt, weil sie zu viele Fehlalarme auslöste, und damit auch die Erkennungsfähigkeit.

  • Ein Schwellenwert wird gelockert

    Der Schwellenwert einer Warnung wird so weit angehoben, dass die Anomalie, die sie eigentlich erkennen sollte, nicht mehr ausgelöst wird. Die Regel bleibt zwar bestehen, ist aber effektiv blind.

  • Eine Metrik wird nicht mehr erfasst

    Die Instrumentierung, die ein Dashboard oder eine Warnung speiste, wird entfernt, sodass das überwachte Objekt unsichtbar wird, obwohl die Warnung weiterhin existiert.

  • Überwachung folgt nicht der neuen Oberfläche

    Ein neuer Dienst, Endpunkt oder Pfad wird ohne Überwachung bereitgestellt, sodass ein ganzer Bereich des Systems standardmäßig unbeobachtet bleibt.

  • Eine Erkennung wird deaktiviert

    Anomalie-Erkennung oder ein Sicherheitsmonitor wird abgeschaltet (z. B. über ein Feature-Flag oder einen auskommentierten Check), um Lärm zu reduzieren, und nie wieder aktiviert.

Worked example

Eine Warnung bei Spitzen fehlgeschlagener Logins, entfernt.

Eine Warnung, die bei einem Anstieg fehlgeschlagener Logins ausgelöst wird, hat während Lasttests die Entwickler benachrichtigt. Daher wird sie in einer Änderung aus der Überwachungskonfiguration gelöscht. Der Lärm hört auf - und damit auch die einzige automatisierte Methode, mit der das Team einen Brute-Force-Angriff in der Produktion bemerken würde.

monitoring/alerts.yaml+0 -4
groups:-  - alert: FailedLoginSpike-    expr: rate(auth_failures_total[5m]) > 20-    for: 2m-    labels: { severity: security }
heygrcSOC 2 CC7.2

Dies entfernt die Erkennung für einen Anstieg fehlgeschlagener Logins, das Signal, das man bei einem Brute-Force-Angriff auf ein Konto erhalten möchte. CC7.2 erwartet, dass das System Anomalien wie diese überwacht und erkennt. Wenn die Warnung zu laut ist, sollte der Schwellenwert angepasst oder die Benachrichtigung umgeleitet werden, aber die Erkennung sollte nicht gelöscht werden.

What an auditor does with this

Überwachung wird als Fähigkeit, nicht als Versprechen geprüft.

Ein Prüfer sucht nach Beweisen, dass Anomalien tatsächlich erkannt und darauf reagiert wird: die vorhandenen Warnungen, dass sie ausgelöst werden und dass jemand handelt, wenn dies geschieht. Eine Änderung, die eine Sicherheitswarnung löscht oder eine Metrik leise blind macht, ist die Lücke hinter der Aussage, dass man überwacht. Sie zeigt sich im Diff der Überwachungskonfiguration, dem günstigsten Ort, um sie zu erkennen.

What this is, and is not

Eine Überprüfung, nicht Ihr Überwachungs-Stack.

heygrc markiert Änderungen, die CC7.2 betreffen, und verweist auf das Kriterium, sodass die Korrektur im Pull Request erfolgt. Es führt nicht Ihre Warnsysteme oder Ihr Incident Response aus. Es erkennt den Moment, in dem eine Erkennung entfernt oder blind gemacht wird, direkt im Diff.