Laufzeiten von Sicherheitsprüfungen
Im Prüfverlauf steht der fachliche Prüfstatus im Vordergrund. Neue Prüfungen zeigen nach abgeschlossener Zeitmessung ihre Gesamtdauer. Die aufklappbaren Laufzeitdetails trennen tatsächlich ausgeführte Arbeitsschritte, einschließlich des Speicherns und Bestätigens der Ergebnisse.
Bei historischen Prüfungen sind Timingdetails nicht verfügbar. Konnte eine neue Laufzeitmessung nicht abgeschlossen werden, wird dies gesondert angezeigt. Fehlende Messwerte sind nicht null Sekunden und ändern weder das Prüfergebnis noch die Benachrichtigungen. Die Dauer nachgelagerter Benachrichtigungen gehört nicht zur Scanlaufzeit.
Aufgabe und Zugang
Die Plattformadministration unterstützt den technischen und übergreifenden Betrieb von OC//HSC. Plattformvorgänge erscheinen als eigener berechtigungsabhängiger Bereich im zentralen Postfach; die fachliche Bearbeitung bleibt von Vereins- und Veranstaltungsaufgaben getrennt.
Nur ausdrücklich berechtigte Plattformadministratoren sehen den Einstieg im Kontrollbereich. Die öffentliche Anleitung gewährt keinen Zugriff auf geschützte Funktionen.
Übergreifende Bereiche
Die geschützte Administration bündelt übergreifende Personen- und Zugangsvorgänge, Plattformhinweise, Rechtstexte, Zustellübersichten und betriebliche Statusinformationen.
Fachliche Aufgaben eines Vereins oder einer Veranstaltung werden weiterhin im jeweiligen Kontext bearbeitet und nicht pauschal in den Plattformbetrieb verschoben.
Anträge auf Vereinsanbindung
Ein Antrag aus dem Kontrollbereich erscheint als Plattformvorgang und als Rollenfreigabe. Der Vorgang nennt Benutzer, Personen-ID, Verband, Verein und gewünschte Rolle. Der Mitgliedsnachweis selbst befindet sich ausschließlich in der gesendeten E-Mail und wird nicht im Postfach oder Dokumentenbestand gespeichert.
Bei einer Freigabe werden die vorbereitete Mitgliedschaft und Rolle aktiviert. Bei einer Ablehnung werden beide inaktiv beziehungsweise abgelehnt und der Vorgang geschlossen. Eine optionale Antwort kann über den bestehenden Vorgang erfolgen.
- Vorgang und zugehörige Rollenfreigabe prüfen.
- Nachweis in der Plattform-E-Mail fachlich prüfen.
- Freigeben oder mit nachvollziehbarer Begründung ablehnen.
- Vorgang und Ergebnisstatus kontrollieren.
Interne Testorganisationen
Für kontrollierte technische Abnahmen können Plattformadministratoren unter Organisationen eine verborgene DVG-Testhierarchie vorbereiten. Der geführte Ablauf beschränkt die Auswahl auf den kanonischen DVG und bereits angelegte interne Testebenen.
Vor dem Anlegen zeigt OC//HSC Typ, Elternorganisation, technische Kennung und die deaktivierten Kommunikations- und Zahlungswege zur Kontrolle. Interne Testorganisationen erscheinen weder in regulären Organisationssuchen noch auf öffentlichen Seiten.
- Gewünschte Testebene und zulässige Elternorganisation auswählen.
- Name, Kurzname, technische Kennung, Referenz und Zweck angeben.
- Kontrollansicht prüfen.
- Interne Organisation anlegen und die Hierarchie in der Organisationsliste kontrollieren.
Cybersecurity und CRA-Nachweise
Der geschützte Bereich Cybersecurity & CRA zeigt Plattformadministratoren erfasste technische Komponenten, bekannte Schwachstellen, Prüfverläufe, geschützte SBOM-Dokumente und offene Sicherheitsmaßnahmen.
Schwachstellen werden kompakt je Komponenteninstanz, Version, Umgebung und Quelle zusammengefasst. Einzelne Advisory-IDs bleiben in den aufklappbaren Details vollständig such- und filterbar. Ein aktuelles Risiko benötigt einen belastbaren Bezug zur installierten Version oder Paketquelle; unsichere Zuordnungen erscheinen getrennt als Prüfung erforderlich.
Technische Betriebsnachweise und organisatorische Prüfungen werden getrennt angezeigt. Automatische Überwachung beschreibt den aktuellen Zustand eines Jobs oder Systems; die organisatorische Wiedervorlage ist eine davon unabhängige menschliche Prüfung. Bei Sicherungen, Wiederherstellung, Zertifikaten, Monitoring, Sicherheitsmeldungen, Malwareprüfung und Rollback bleiben nur aktuell belegte offene Punkte als Handlungsbedarf sichtbar. Eine unklare Debian-Versionszuordnung bleibt Prüfung erforderlich. Die Übersicht trifft keine automatische Aussage zur rechtlichen CRA-Konformität.
Historische Meldungen bleiben im Prüfverlauf auditierbar, gelten aber nicht automatisch als aktueller technischer Fehler. CRA-Readiness gleicht ihre frühere Ursache mit dem aktuellen Betriebsnachweis ab und zählt gleiche aktuelle Ursachen nur einmal.
Offene Punkte stehen getrennt unter „Technisch offen“ und „Organisatorisch offen“. Technische Hinweise nennen den konkreten Befund und vorhandene Anzahlen. Ein technischer Fehler öffnet keine bereits abgeschlossene organisatorische Entscheidung; diese lässt sich bei Bedarf bewusst über „Entscheidung bearbeiten“ öffnen.
Der Restore-Nachweis zeigt nur nach einer echten, vollständig bereinigten Wiederherstellungsprüfung den Status Nachgewiesen. Ein vorbereiteter Dienst oder Timer allein reicht nicht aus. Bei Fehlern bleiben Ursache, Cleanupstatus und ein späterer Recovery-Lauf nachvollziehbar, ohne Nutzdaten anzuzeigen.
Eine gesunde Kontrolle zeigt kompakt, dass die technische Überwachung aktiv, die organisatorische Entscheidung nachgewiesen und keine Maßnahme offen ist. Messwerte, technische Prüftermine, Nachweisquellen und interne Referenzen stehen unter „Technische Details“. Eine abgeschlossene Entscheidung bleibt geschlossen und kann über „Entscheidung bearbeiten“ erneut geöffnet werden. Erreicht die Wiedervorlage ihr Datum, erscheint die organisatorische Prüfung wieder als Handlungsbedarf.
Die Kennzahlen des Governance-Reifegrads öffnen direkt die passende Kontrollauswahl. Gesamtstatus, Handlungsbedarf, Kontrollbereich, Nachweisart und Suche lassen sich kombinieren; aktive Filter bleiben in der URL sichtbar und einzeln oder vollständig zurücksetzbar.
Bei einer nicht anwendbaren organisatorischen Bewertung ist der fachliche Grund sichtbar und wird auch in den Readiness-Berichten ausgegeben. Optionale leere Angaben wie Vertretung, Eskalationsrolle oder Notiz erzeugen für sich allein keine offene Maßnahme. Der aktuelle Readiness-Stand kann als PDF, JSON oder CSV heruntergeladen werden; alle Formate verwenden unabhängig von der sichtbaren Filterung den vollständigen aktuellen Zustand und sind keine rechtliche Konformitätsbescheinigung.
- Eine Kennzahl des Governance-Reifegrads für den direkten Drilldown auswählen oder die CRA-Kontrollen nach Gesamtstatus, Handlungsbedarf, Kontrollbereich, Nachweisart und Suchtext filtern.
- Aktive Filter und die angezeigte Trefferzahl prüfen.
- Bei einer betroffenen Kontrolle den konkreten offenen Punkt lesen.
- Messwerte, technische Prüftermine und Nachweisquellen nur bei Bedarf unter „Technische Details“ öffnen.
- Eine fällige organisatorische Entscheidung nach starker Bestätigung bearbeiten und speichern.
- Prüfen, dass die offene Maßnahme danach verschwindet und die nächste organisatorische Prüfung angezeigt wird.
- Bei Bedarf den vollständigen aktuellen Readiness-Bericht im passenden Format herunterladen.
Automatische Prozesse
Unter Automatische Sicherheitsprozesse bündelt OC//HSC vorhandene Laufzeit-, Zeitplan-, Audit- und Nachweissignale. Angezeigt werden nur Prozesse, für die ein tatsächliches Signal vorliegt.
Statusfarben beschreiben den zuletzt erkannten Betriebszustand. Ein geplanter Prozess ohne bisherigen Lauf erscheint als „Geplant, noch nicht ausgeführt“ und bleibt damit klar von einem Prozess ohne Zeitplan getrennt. Ein älterer Fehler bleibt in der Historie sichtbar, hält einen später erfolgreich wiederhergestellten Prozess aber nicht dauerhaft im Fehlerstatus.
- Zeitraum, Status oder Prozess filtern.
- Letzten und nächsten Lauf sowie Auslöser und Intervall prüfen.
- Details für Laufzeiten, Fehler, Recovery, Quellen und Artefakte öffnen.
- Bei gelbem oder rotem Status den zugehörigen Nachweis und die Betriebsprotokolle prüfen.
Backup
Die Prozessansicht zeigt erkannte Sicherungsmechanismen, ihren tatsächlichen Zeitplan und den letzten belegten Lauf. Ereignisgesteuerte Sicherungen, etwa vor einem Deployment, werden als solche bezeichnet und nicht als unbekannt dargestellt.
Serverseitige Sicherung und externe Kopie werden getrennt bewertet. Ein externer Nachweis gilt nur als aktuell, wenn der automatische Pull frisch ist, der neueste vollständige Satz vorliegt und die Prüfsummen von Datenbank, Uploads und Dokumenten übereinstimmen.
Die Ansicht prüft oder verändert keine Sicherungsinhalte. Sie macht lediglich vorhandene Betriebsnachweise sichtbar.
Restore
Ein Restore-Test gilt erst nach erfolgreicher Wiederherstellung, Prüfung und vollständiger Bereinigung als erfolgreich. Ein vorbereiteter Timer oder Dienst ist nur ein Zeitplansignal.
Fehler und spätere Wiederherstellungen bleiben in der Laufhistorie getrennt nachvollziehbar.
Rollback
Rollback-Nachweise zeigen, ob der vorgesehene Rückkehrpfad geprüft wurde und mit welchem Ergebnis. Die Ansicht löst keinen Rollback aus und verändert keine Releases.
Ein manueller oder ereignisgesteuerter Ablauf wird entsprechend gekennzeichnet.
Security Scan
Sicherheitsprüfungen erscheinen mit letztem Lauf, Ergebnis, Dauer und verfügbarem Zeitplan. Die Historie zeigt höchstens die letzten 50 Läufe und berechnet Durchschnittswerte aus höchstens 20 aktuellen Läufen. Auf Smartphones erscheinen die Läufe als lesbare Karten.
Der technische Laufstatus und die Abdeckung der vorgesehenen Quellen werden getrennt erklärt. Eine eingeschränkte Abdeckung nennt die verständliche Ursache; technische Codes bleiben aufklappbaren Details vorbehalten.
Eine manuelle vollständige Prüfung erhebt unmittelbar vor der Auswertung einen neuen Produktionsbestand und wird weiterhin nur über den geschützten bestehenden Ablauf gestartet. Scheitert diese Erhebung, entsteht kein neues SBOM aus älteren Bestandsdaten.
SBOM
Die SBOM-Erzeugung wird anhand tatsächlicher Scan- und Artefaktdaten erkannt. Erzeugte geschützte Artefakte bleiben ausschließlich im berechtigten Plattformbereich sichtbar.
Die Ablaufansicht ordnet die SBOM zwischen Inventarisierung und Schwachstellenbewertung ein, ohne eine zweite Bewertung zu erzeugen.
Operational Evidence
Operational Evidence fasst datensparsame Produktionssignale zu Backup, Wiederherstellung, Monitoring, Zertifikaten, Malwareprüfung und Benachrichtigungen zusammen. Quellen werden sichtbar, sensible Inhalte jedoch nicht offengelegt. Bei der Malwareprüfung werden Engine, Scannerdienst, Signaturaktualisierung, Signaturfrische, Socketschutz und Anwendungszugriff getrennt ausgewiesen.
Technische Nachweise bleiben klar von organisatorischen Bestätigungen und rechtlichen Bewertungen getrennt.
Datenlebenszyklus und Aufbewahrung
Die geschützte Lifecycle-Sicht ordnet Datenklassen nach Zweck, technischer Aufbewahrungslogik, Schutz und noch offener fachlicher oder juristischer Entscheidung. Bestandszahlen werden nur aggregiert angezeigt; Personen- und Zugangsdaten erscheinen dort nicht.
Der Abschnitt Retention & Audit zeigt für Mail- und Authentifizierungsprotokolle die versionierte Policy, den nächsten Bereinigungstermin, den letzten Lauf und den aktuellen Dry-Run-Bestand. Diagnose-, Zustell-, Sicherheits- und Rollennachweise besitzen getrennte Fristen.
Der bestehende Bereinigungsjob läuft täglich um 03:15 Uhr UTC. Die Ansicht stellt seine Zeitpunkte in Europe/Berlin dar und berücksichtigt damit Sommer- und Winterzeit.
Aktive Sitzungen und Sicherheitsmethoden bleiben unberührt. Die technischen Fristen sind interne Governance-Entscheidungen und keine pauschale gesetzliche Aufbewahrungsfrist.
- Datenklasse und Lifecycle-Status prüfen.
- Unter Retention & Audit Policy-Version, letzten Lauf und Überfälligkeit kontrollieren.
- Dry-Run-Bestand und zweckgebundene Frist vergleichen.
- Bei Bedarf den aktuellen aggregierten Bericht als PDF, JSON oder CSV herunterladen.
Datenintegrität
Die geschützte Datenintegritätsprüfung vergleicht zentrale fachliche Regeln und referentielle Zusammenhänge über Personen, Mitgliedschaften, Organisationen, Tiere, Veranstaltungen, Ergebnisse, Dokumente und weitere Plattformbereiche hinweg. Fachliche Einordnung und Sollzustand stehen in der Übersicht im Vordergrund; technische IDs bleiben aufklappbar verfügbar.
Auf Tablet und Smartphone werden Findings als strukturierte Abschnitte dargestellt. Ein technisch erfolgreicher Prüflauf kann Findings enthalten. Bewusst tolerierte historische Fallbacks werden als Hinweise von Fehlern und manuellen Prüffällen getrennt; die Ansicht verändert oder repariert keine Daten.
- Zusammenfassung und Zeitpunkt des aktuellen Prüflaufs kontrollieren.
- Bei Bedarf nach Domäne, Schweregrad oder Kategorie filtern.
- Sollzustand, kanonische Quelle und technische IDs eines Findings prüfen.
- Vor jeder fachlichen Korrektur Ursache, Schreibpfad und Aufbewahrungsregeln klären.
Benachrichtigungen
Die Benachrichtigungsübersicht zeigt je erkanntem Prozess Klasse, Eskalationsstufe, Empfänger, Mailregel, letzte Meldung und letzte Recovery.
Routineerfolge erzeugen keine E-Mail. Kritische oder handlungsbedürftige neue Ereignisse können sofort an die verantwortliche Person gesendet werden; normale relevante Änderungen und Recoveries werden höchstens einmal täglich zusammengefasst. Ohne zugewiesene Person fällt der Vorgang an die Plattformadministration.
Verantwortlichkeiten
Solange keine individuelle Person zugeordnet ist, liegt die Verantwortung standardmäßig bei der Plattformadministration. Das gilt für technische und organisatorische Aufgaben sowie für die Eskalation.
Eine bewusst ausgewählte Person hat Vorrang und wird nicht durch den Standard ersetzt. Eine Vertretung wird nur angezeigt, wenn sie ausdrücklich gepflegt wurde.
Wiedervorlage
Technisch automatisch überwachte Kontrollen benötigen keine manuelle Wiedervorlage. Organisatorische Regeln werden bei wesentlichen Änderungen erneut geprüft; kombinierte Kontrollen sind standardmäßig jährlich organisatorisch zu prüfen.
Ein konkretes Datum entsteht erst durch eine entsprechende Entscheidung. Der Prüfmodus selbst erzeugt keine künstliche Erledigungsfrist.
Erledigen bis
Eine Erledigungsfrist kann für offene, in Bearbeitung befindliche oder nicht umgesetzte Aufgaben gepflegt werden. Nach Abschluss oder bei Nichtanwendbarkeit wird keine Frist angezeigt.
Die Plattform setzt keine pauschalen Fristen. Überfällige Aufgaben erscheinen mit Zuständigkeit, Datum und Anzahl der überfälligen Tage im Reifegrad.
Eskalation
Ohne individuelle Festlegung ist die Plattformadministration die Eskalationsrolle. Dringlichkeit und Wiederholung richten sich nach der sichtbaren Benachrichtigungsklasse.
Die Diagnosevorschau zeigt die vorgesehenen Wege und Empfänger, ohne eine Nachricht zu versenden oder einen Vorgang zu verändern.
Der Bereich Plattform-Mail-Bereitschaft zeigt, ob SMTP, Absender, Antwortadresse, Zugangsdaten und Prüfstatus vorhanden sind. Webdomain und Maildomain dürfen voneinander abweichen; entscheidend sind gültige Mailadressen und die Unterstützung durch das verwendete SMTP-Konto. Zugangsdaten selbst werden nicht angezeigt.
Ohne erfolgreich versandte Testmail werden keine Sicherheits-E-Mails freigegeben. Dashboard, Postfach, Audit und Recovery funktionieren weiterhin; die Ansicht weist klar auf die deaktivierte Zustellung hin.
Recovery
Nach einem Fehler zeigt die Historie einen späteren erfolgreichen Lauf als Recovery. Der aktuelle Status folgt dem jüngsten belastbaren Signal, während der ursprüngliche Fehler für die Nachvollziehbarkeit erhalten bleibt.
Bleibt ein Recovery aus, müssen Plattformadministratoren den betroffenen Prozess und seine Nachweisquellen prüfen.
Recovery wird im Dashboard und Audit auch dann nachvollziehbar, wenn keine Plattform-Mail konfiguriert ist. Eine E-Mail-Zusammenfassung erfolgt nur über einen tatsächlich verfügbaren Mailweg.
Schwachstellen nach Verantwortung bearbeiten
Die Schwachstellenansicht zählt aktuelle Ursachen statt jede einzelne Advisory mehrfach. Sie zeigt, ob eine Ursache eine Anwendungsabhängigkeit, Plattform-Laufzeit, ein Distributionspaket oder gemeinsam betriebene Infrastruktur betrifft. Anwendungsabhängigkeiten werden zusätzlich als Laufzeit, Build, Entwicklung/Test oder optional eingeordnet.
Aktuell bezeichnet ausschließlich den heute installierten Zustand. Prüfung erforderlich kennzeichnet eine noch nicht belastbar entschiedene Zuordnung zur aktuellen Version und ist kein bestätigtes Risiko. Historie enthält frühere Versionen und Nachweise ohne aktuellen Handlungsbedarf.
Bei transitiven Paketen zeigen die Details die Abhängigkeitskette. Client-, Server-, Job- und Build-Exposition sowie der belegte Produktionsbundle-Status erklären die technische Reichweite, ohne den Schweregrad eines Befunds zu verändern.
Paketquelle, installierte Version, verfügbarer Kandidat und der zur Paketquelle passende Hersteller- oder Distributionsnachweis bestimmen den nächsten Schritt. Für ein offiziell betriebenes ClamAV-Paket zeigt die Komponentenansicht zusätzlich den Releasekanal, den aktuellen Patchstand und den Supportzeitraum aus dem offiziellen Nachweis. Ein offiziell als nicht betroffen oder bereits behoben ausgewiesener aktueller Stand bleibt als aktueller Nachweis sichtbar, erzeugt aber keine offene Ursache. Weist die offizielle Quelle ausdrücklich keinen Schweregrad aus, zeigt OC//HSC dies als „Keine“ und erfindet weder CVSS-Wert noch Update-Aktion.
Ein sofort verfügbares Plattform- oder Betriebssystemupdate wird von einem ausstehenden Distributionsfix, einer dokumentierten Schwachstelle ohne verfügbare Behebung und einer notwendigen Kompatibilitäts- oder Backportprüfung getrennt.
Die Filter Verantwortung, Nächste Aktion, Abhängigkeitsklasse und Abhängigkeitsart grenzen die Arbeitsliste ein. PDF, JSON und CSV verwenden dieselbe zentrale Einordnung und trennen aktuelle Version, aktuellen Prüfbedarf und historische Nachweise.
- Schwachstellen öffnen und die Zusammenfassung der aktuellen Ursachen prüfen.
- Nach Verantwortung oder nächster Aktion filtern.
- Die Paketquelle und den verfügbaren Kandidaten in den Details prüfen.
- Nur den ausgewiesenen unterstützten Aktualisierungsweg verwenden.
- Nach dem Folgescan prüfen, ob die Ursache historisch geworden ist.
Betriebsprotokolle und Störungsnachweise
Die geschützte Ansicht Betriebsprotokolle zeigt Plattformadministratoren, ob die technischen Protokollquellen der Plattform aktiv, zugriffsgeschützt, begrenzt aufbewahrt und ordnungsgemäß rotiert werden. Aufklappbare Details nennen den letzten Nachweis, Speicherverbrauch und Aufbewahrungsstatus, ohne vollständige Rohprotokolle offenzulegen.
Für eine technische Störung lässt sich ein begrenzter Zeitraum auswählen und chronologisch auswerten. Clientabbrüche, Dienstumschaltungen und Anwendungsfehler werden dabei getrennt eingeordnet. Die zeitliche Korrelation ist ein Betriebsnachweis und allein noch keine Aussage über die Ursache.
- Betriebsprotokolle in der Plattformadministration öffnen.
- Status und letzten Nachweis der benötigten Quelle prüfen.
- Zeitraum und bei Bedarf Quelle oder Bereitstellung filtern.
- Den Nachweis als PDF, JSON oder CSV herunterladen und die ausgewiesene Prüfsumme zum Vergleich festhalten.
Sicher und nachvollziehbar arbeiten
Administrationsaktionen folgen den sichtbaren Bestätigungs-, Prüf- und Protokollierungswegen der Plattform. Verwende keine administrativen Möglichkeiten als Ersatz für fehlende fachliche Zuständigkeit.
Interne technische Details, Sicherheitsverfahren und Betriebsdaten gehören nicht in öffentliche Anleitungen, Nachrichten oder Supportantworten.