5.0.5 PROD – Remote Access Protection (RAP), Ransomware Encryption Protection X, Network Windows OS deployment. und Co-Branding-Steuerungen für den Agent

1. Remote Access Protection.
2. Ransomware Encryption Protection X 
3. Preboot Execution Environment (PXE)/ Network Windows OS deployment.
4. Heimdal-Agent-Co-Branding.
5. Anwendungssteuerung – Backend-Überarbeitung und Verbesserungen der Benutzeroberfläche.
6. PSA-Integrationen (Autotask & ConnectWise PSA): Verbesserung des Hostname-Abgleichs

Eine neue Version des Heimdal-Produktions-Dashboards (PROD), 5.0.5, ist jetzt verfügbar.

Ab Freitag, dem 17. Oktober 2025, steht der Heimdal-Produktionsagent im Dashboard im Bereich „Guide“ auf der Registerkarte „Download and Install“ zum Download bereit. Die Bereitstellung erfolgt im Laufe der kommenden Wochen schrittweise.
 

Heimdal-Dashboard

Preboot Execution Environment (PXE)/ Network Windows OS deployment

Nach der Einführung unseres iPXE-/Netzwerkbetriebssystem-Bereitstellungsmoduls in Version 3.9.0 (Herbst 2024) haben wir kontinuierlich daran gearbeitet, die von Microsoft auferlegten Einschränkungen bei der Bereitstellung von Betriebssystemen innerhalb des Netzwerks zu vereinfachen und zu umgehen.  

Mit der PROD-Version 5.0.5 können wir mit Überzeugung sagen, dass uns genau das gelungen ist und die Installation von Betriebssystemen auf der Hardware Ihrer IT-Umgebung mühelos und skalierbar geworden ist.

Wie die vorherige Version des Moduls zur Bereitstellung von Windows-Betriebssystemen im Heimdal-Netzwerk bietet auch die neue, überarbeitete Version eine Vielzahl vielseitiger Funktionen:

• Repositoryverwaltung: Verwalten Sie Ihr Repository für Betriebssystemabbilder über die Netzwerkeinstellungen.
• Abbildverwaltung: Laden Sie Betriebssystemabbilder hoch und verwalten Sie diese.
• PXE-Server-Hochstufung: Stufen Sie einen Hostnamen zum PXE-Server hoch.
• Vererbungsfunktion: Übernehmen Sie die Repository-Einstellungen des Resellers.

und umgeht dabei bekannte Einschränkungen, beispielsweise bei der Bereitstellung von Windows 11.

Einrichten eines Endpoints als Bereitstellungsserver:

1. Heimdal-Agent installieren: Laden Sie den Heimdal-Agent aus dem Dashboard herunter und installieren Sie ihn mit einem gültigen Lizenzschlüssel.

   2. Netzwerkbetriebssystem-Bereitstellungsfunktion aktivieren: Navigieren Sie zu Network Settings > Network OS Deployment und aktivieren Sie das Kontrollkästchen mit demselben Namen. 

Die Option „Inherit Reseller Repository“ kann nur von einem Reseller-Benutzerkonto für den aktuell impersonierten Corp.-Kunden aktiviert werden. Für den Corp.-Kunden ist diese Option ausgegraut. Wenn sie aktiviert ist, hat der Corp.-Kunde Zugriff auf alle vom Reseller hochgeladenen ISO-Dateien sowie auf die von ihm selbst hochgeladenen Dateien.

   3. Betriebssystemabbilder hochladen: Damit die Netzwerkbetriebssystem-Bereitstellungsfunktion ordnungsgemäß funktioniert, müssen gültige ISO-Dateien hochgeladen werden. Klicken Sie auf die Schaltfläche „Upload OS Image“. Daraufhin wird ein modales Fenster angezeigt, in dem Sie eine ISO-Datei auswählen und eine Beschreibung hinzufügen können.

Nachdem die Upload-Schaltfläche betätigt wurde, beginnt der Upload der Datei in die Cloud. Es ist wichtig, das Fenster geöffnet zu lassen, bis der Upload abgeschlossen ist. Andernfalls wird der Upload angehalten.

Hinweis: Wenn der Upload des bzw. der Abbild(er) länger als 2 Stunden dauert, wird der Benutzer aufgrund von Inaktivität abgemeldet.

   4. PXE-Server erstellen: Navigieren Sie zu Unified Endpoint Management > Device Info, Standard view. Wählen Sie einen Host aus, den Sie als PXE-Bereitstellungsserver bestimmen möchten, und wählen Sie in der Dropdown-Liste „Select what action to take“ die Option „Add OS Deployment Server“.

   5. PXE-Server konfigurieren: Beim Hinzufügen eines neuen Servers oder Bearbeiten eines vorhandenen Servers können mehrere Einstellungen vorgenommen bzw. geändert werden:

• Prüfintervall – Diese Einstellung legt ein bestimmtes Zeitintervall in Minuten fest. Auf Grundlage dieses Werts prüft das System regelmäßig die PXE-Version und lädt, sofern verfügbar, automatisch eine neue Version von Microsoft Entra ID herunter.
• Benutzerauthentifizierung erzwingen – Der Endbenutzer muss die voreingestellten (auf GP-Ebene festgelegten) Anmeldedaten verwenden, um auf das Betriebssystem-Repository des PXE-Servers zugreifen zu können.
• Downloadpfad – Legt den Standardspeicherort für den Download von ISO-Dateien fest. Stellen Sie sicher, dass auf dem ausgewählten Laufwerk genügend freier Speicherplatz für die festgelegte Anzahl herunterzuladender ISO-Dateien vorhanden ist.

• Verfügbare Betriebssystemabbilder – Durch Klicken auf die Schaltfläche „Add OS Image“ kann der Benutzer aus den aktuell verfügbaren ISO-Abbildern auswählen. Alle verfügbaren ISO-Abbilder werden in der entsprechenden Liste angezeigt.

Nach erfolgreichem Abschluss des Vorgangs „Sync GP“ werden auf dem Endpoint zwei Dienste aktiv: Heimdal OsDeployment und Heimdal OsDeployment Checker.

  6. Client-Endpoint-Verbindung zum Server: 

1. Korrekte Startreihenfolge festlegen: Legen Sie auf dem Client-Endpoint im BIOS die Startpriorität so fest, dass zuerst über das Netzwerk gestartet wird.
2. Verbindung herstellen: Stellen Sie sicher, dass der PXE-Server eingeschaltet und im Netzwerk sichtbar ist. Starten Sie den Client-Endpoint.
3. Authentifizierung: Geben Sie auf der Clientseite gegebenenfalls Benutzername und Passwort ein.
4. Windows-Preinstallation Environment (PE) laden: Das System lädt Windows PE.
5. Betriebssystemabbild auswählen: Wählen Sie das für die Installation vorgesehene Betriebssystemabbild aus.
6. Windows-Setup starten: Fahren Sie mit der regulären Windows-Installation fort.

Heimdal-Agent

Heimdal-Agent-Co-Branding

Die aktuellen Co-Branding-Funktionen (Dashboard und Berichte) wurden auch auf den Heimdal-Agent ausgeweitet. Dadurch können MSPs und Corp.-Kunden das festgelegte Logo in der Benutzeroberfläche des Agents anzeigen.

Für Reseller und Corp.-Kunden stehen zwei Upload-Optionen zur Verfügung (Guide -> Customer Settings -> Company Info):

• Großes Logo – verwendet in:
  • Heimdal-Dashboard (Anmeldeseite, Berichte, Warnungen).
  • Heimdal-Agent-Co-Branding-Szenario, wenn das Agent-Menü erweitert ist.
• Kleines Logo – verwendet im Heimdal-Agent-Co-Branding-Szenario, wenn das Agent-Menü reduziert ist.
  Wie im Heimdal-Dashboard und in den Berichten sorgt auch im Heimdal-Agent die Funktion „Reseller Logo Distribution“ (Reseller-Ebene) in Verbindung mit der Funktion „Opt out Reseller Logo“ auf Ebene des Corp.-Kunden für denselben Ablauf.

Heimdal-Berechtigungen & App. Control

Anwendungssteuerung – Backend-Überarbeitung und Verbesserungen der Benutzeroberfläche

Die Optimierung der Leistung und der Benutzererfahrung gehört zu unseren höchsten Prioritäten. In diesem Zusammenhang bringt unsere neue Produktversion ein vollständig überarbeitetes App.-Control-Modul mit, das das Produkt schneller, sicherer und stabiler macht und für eine bessere Benutzererfahrung sorgt.

Neben der vollständigen Umstrukturierung des Backends wurde auch der Produktbereich „App. Control“ im Dashboard geändert, wodurch Navigation und Datenvisualisierung effizienter und relevanter werden.

Die bisherigen Ansichten „Matching Allowed rules“, „Matching Blocked rules“, „Matching Allowed with auto elevation“ und „Full logging“ wurden eingestellt. Der Dashboard-Bereich „Application Control“ (Products -> Privileges & App Control) ist jetzt robuster und umfasst nur noch zwei Ansichten: „Standard“ und „Raw data“. Die Sortierung und Filterung der Daten bleibt unverändert und ermöglicht IT-Administratoren weiterhin, relevante Daten wie gewünscht zu visualisieren.

Die neue Ansicht „Raw Data“ zeigt ein Raster mit allen Prozessen (nicht gruppiert), die von App Control während der letzten 24 Stunden des ausgewählten Zeitraums abgefangen wurden, einschließlich folgender Angaben: Prozessname, Anzahl der Ausführungen, Herausgeber, Softwarename, Version, MD5, Status, Dateiberechtigungen verweigern, Erhöht und Zeitstempel.

Die Ansicht enthält ähnliche Filteroptionen wie die Standardansicht.

Wenn Sie historische Daten benötigen (bis zu maximal 30 Tage vor dem Datum „To“), können diese „on demand“ bereitgestellt werden. Wenden Sie sich dazu an unsere Supportabteilung.

Als letzte Erweiterung der Verbesserungen der Application-Control-Benutzeroberfläche wurde in den Produktansichten „Standard“ und „Raw data“ die Dropdown-Liste „Select GP“ hinzugefügt. Sie erleichtert die Datenvisualisierung bei großen Informationsmengen, da IT-Administratoren eine oder mehrere GPs auswählen und die Daten entsprechend filtern können.

Heimdal Endpoint Detection

Firewall: Remote Access Protection

Als natürliche Weiterentwicklung der in Version 4.9.0 eingeführten Verbesserungen zum Schutz vor Brute-Force-Angriffen der Firewall freuen wir uns, Ihnen das „Ende aller Sicherheitsverletzungen“ vorzustellen: Remote Access Protection (RAP). 
Angesichts der Ursache der meisten Sicherheitsverletzungen – einer einfachen, jedoch schwer zu bewältigenden Ursache, nämlich Sicherheitslücken durch die Verwaltung von RDP-Ports – ist Remote Access Protection (RAP) ein unverzichtbarer Bestandteil Ihres Sicherheits-Stacks.

RAP stellt eine neue Sicherheitsebene dar, mit der Sie den RDP-Zugriff überwachen und steuern können.
Diese Funktion überwacht, blockiert und verwaltet RDP-Verbindungsversuche zu durch Heimdal geschützten Endpoints. Sie trägt dazu bei, unbefugten Fernzugriff zu verhindern, und ermöglicht gleichzeitig eine detaillierte Steuerung über Allowlisting und Gruppenrichtlinieneinstellungen.

RAP ergänzt vorhandene Heimdal-Sicherheitsuntermodule wie Firewall und Brute Force Attack Protection und bildet damit eine vollständige Endpoint-Abwehrstrategie. Die Funktion ist eng mit unserem User-Security-Modul und M365 verbunden und unterstreicht damit die Vereinheitlichung als charakteristisches Merkmal unseres Produkt-Stacks.

Das Untermodul Remote Access Protection (RAP) bietet vollständige Transparenz und Kontrolle über RDP-Verbindungsversuche zu Geräten, die durch den Heimdal-Agent geschützt sind.
Bei Aktivierung über die Gruppenrichtlinie (Endpoint Settings -> auf eine Windows-GP klicken -> Endpoint Detection -> Firewall & RAP -> Registerkarte RAP):

• wird der gesamte eingehende RDP-Datenverkehr überwacht.
• werden Verbindungen standardmäßig blockiert, sofern die Quell-IP-Adresse nicht auf der Allowlist steht oder zu einem privaten IP-Bereich gehört, der über die GP-Einstellung „Do not block private IPs“ zugelassen ist.

Jeder RDP-Versuch wird im Dashboard protokolliert. Administratoren können dadurch:

• Quelle und Ziel der Verbindung überprüfen.
• vertrauenswürdige IPs auf die Allowlist setzen.
• Ablaufdaten für Allowlist-Einträge festlegen.
• Verbindungsversuche bestätigen (als „Blocked“ markieren).

Die frühere Registerkarte „Firewall“ (Endpoint Settings -> Endpoint Detection) wurde in „Firewall & RAP“ umbenannt und umfasst nun drei separate Unterregisterkarten:

• Firewall – alle vorhandenen firewallbezogenen Einstellungen.
• RAP – Konfiguration des neuen Moduls „Remote Access Protection“.
• Brute Force Attack Protection – vorhandene BFA-Protection-Einstellungen, die nun in diese neue Struktur verschoben wurden.

Das neue Modul „Remote Access Protection“ (RAP) wurde als Bestandteil der Konfiguration „Firewall & RAP“ eingeführt. Es überwacht eingehenden Remote-Desktop-Protocol-(RDP-)Datenverkehr und verhindert standardmäßig unbefugten Zugriff, indem jede Verbindung blockiert wird, die nicht ausdrücklich auf die Allowlist gesetzt wurde.

Hinweis: Remote Access Protection kann nur aktiviert werden, wenn auch das Firewall-Modul aktiv ist.

Verfügbare Konfigurationsoptionen:

• Remote Access Protection – Dieser Umschalter aktiviert RAP.
• RAP-überwachte Ports – Gibt einen oder mehrere Ports an, die für eingehende RDP-Verbindungen überwacht werden:
  • Mehrere Werte werden durch ein Komma „,“ getrennt (z. B. 3389,3390).
  • Bei einer Bearbeitung in den Bereichen „Brute Force Attack Protection“ oder „RAP“ wird der Wert automatisch synchronisiert, um die Konsistenz zwischen beiden Modulen sicherzustellen.
  • Do not block private IPs – Erlaubt alle eingehenden RDP-Verbindungen von privaten IPs.
  • Allowlist:
    • Ermöglicht IT-Administratoren, IPv4-Adressen oder IPv4-Bereiche manuell anzugeben, die eine Verbindung über RDP herstellen dürfen.
    • Einträge können auch über die Importfunktion hinzugefügt werden, wodurch eine Massenverwaltung vertrauenswürdiger IPs oder Bereiche möglich ist.
    • IP-Bereiche können mit der Bindestrichnotation (-) hinzugefügt werden (z. B. 192.168.0.1-192.168.0.255).
    • Für jeden Allowlist-Eintrag kann optional ein Ablaufdatum festgelegt werden:
      • Wenn kein Ablaufdatum festgelegt wird, bleibt der Eintrag gültig, bis er manuell entfernt wird.
      • Wenn ein Ablaufdatum konfiguriert ist, bleibt der Eintrag bis zu seinem Ablauf gültig. Danach bleibt er zur Nachverfolgbarkeit im dedizierten Produktraster sichtbar.
      • Beim Festlegen oder Bearbeiten eines Ablaufdatums erzwingt das System, dass das ausgewählte Datum nach dem aktuellen Datum liegt. Dadurch können abgelaufene oder am selben Tag endende Einträge nicht konfiguriert werden.
      • Allowlist-Einträge können bei Bedarf bearbeitet oder gelöscht werden.

• Greylist-Erkennungsblockierung nach 7–30 Tagen automatisch bestätigen – Einträge mit dem Status „Default blocked, not actioned“ werden automatisch in „Blocked“ geändert, nachdem die konfigurierte Anzahl von Tagen seit dem aufgezeichneten Zeitstempel verstrichen ist, sofern sie nicht zuvor manuell bestätigt wurden.
   
• M365-Integration:
  • Dieser Konfigurationsbereich ist in der Gruppenrichtlinie immer sichtbar, bleibt jedoch deaktiviert, sofern TAC UI & M365 User Security nicht lizenziert ist.
    • Bei Lizenzierung und Aktivierung erhalten Administratoren Zugriff auf risikobasierte Informationen, die für das Allowlisting genutzt werden können, einschließlich:
      • der Möglichkeit, über einen Schieberegler einen Schwellenwert für den Allowlist-Risikoscore festzulegen.
      • eines zusätzlichen Bestätigungsdialogs, der angezeigt wird, bevor die Aktion abgeschlossen wird, wenn der Risikoscore eines Endbenutzers den zuvor genannten Schwellenwert überschreitet.

Hinweis: Die GP-Funktion „Enable M365 User Security Integration“ wirkt sich nicht auf zuvor gemeldete Daten aus. Sie beeinflusst lediglich, wie Daten für zukünftige RDP-Verbindungsversuche ab dem Zeitpunkt der Aktivierung der Einstellung ausgewertet und gemeldet werden.

Die Produktansicht im Heimdal-Dashboard (Products → Endpoint Detection → Firewall → Remote Access Protection)

und die Ansicht mit den Clientdetails (nach dem Klicken auf einen Hostnamen im Raster der Ansicht „Remote Access Protection“)

zeigen alle erkannten RDP-Verbindungsversuche mit ihrem jeweiligen Status:

• Default blocked, not actioned – Erkannte und blockierte RDP-Verbindungen, die vom Dashboard-Benutzer nicht bestätigt wurden.
• Blocked – Erkannte und blockierte RDP-Verbindungen, die vom Dashboard-Benutzer bestätigt wurden.
• Allowlisted – Erkannte und blockierte RDP-Verbindungen, die später vom Dashboard-Benutzer auf die Allowlist gesetzt wurden.

Die anderen in den beiden zuvor genannten Ansichten verfügbaren Spalten sind:

• Hostname – Name des Zielcomputers.
• Last Known Username – zuletzt am Computer angemeldeter Benutzer.
• IP – Quell-IP-Adresse, von der die RDP-Verbindung versucht wird.
• Expected User – Wird durch Überprüfung von Login Anomaly Detection (LAD) anhand der Quell-IP-Adresse und Identifizierung des zuletzt von dieser IP-Adresse verbundenen Benutzers abgerufen.
  • Wenn eine Übereinstimmung gefunden wird, wird der erwartete Benutzername angezeigt.
  • Wenn keine Übereinstimmung gefunden wird oder Login Anomaly Detection (LAD) nicht lizenziert oder konfiguriert ist, wird im Feld „N/A“ angezeigt.
• MFA Enabled – Zeigt ein Statussymbol „Enabled“ oder „Disabled“ an, basierend auf der aktuellen MFA-Konfiguration des Benutzers, der in der Spalte „Expected User“ identifiziert wurde.
  • Nur verfügbar, wenn die Einstellungen für M365 User Security und Login Anomaly Detection (LAD) aktiv sind.
  • Wenn M365 User Security nicht lizenziert oder aktiviert ist, wird im Feld „N/A“ angezeigt.
• Strong Password enabled – Zeigt ein Statussymbol „Enabled“ oder „Disabled“ an, basierend auf der aktuellen Konfiguration für starke Passwörter des Benutzers, der in der Spalte „Expected User“ identifiziert wurde.
  • Nur verfügbar, wenn die Einstellungen für M365 User Security und Login Anomaly Detection (LAD) aktiv sind.
  • Wenn M365 User Security nicht lizenziert oder aktiviert ist, wird im Feld „N/A“ angezeigt.
• State – Gibt den Status jeder aufgezeichneten RDP-Verbindung an:
  • Default blocked, not actioned (Standardstatus) – Die Verbindung wurde automatisch vom RAP-Modul blockiert und noch nicht von einem Administrator überprüft.
  • Blocked – Manuell von einem Administrator bestätigt oder automatisch nach 7–30 Tagen aktualisiert, wenn die Gruppenrichtlinienoption zur automatischen Bestätigung der Greylist aktiviert ist.
  • Allowlisted – Die Verbindung wurde auf Grundlage des entsprechenden Allowlist-Eintrags der Gruppenrichtlinie zugelassen, sofern der Eintrag nicht abgelaufen ist.
• Risk Score – Zeigt den Risikoscore des Benutzers an, der in der Spalte „Expected User“ identifiziert wurde:
  • Wenn M365 User Security nicht lizenziert oder aktiviert ist, wird der Wert 0 angezeigt.
• Timestamp – Zeitpunkt, zu dem der Verbindungsversuch stattgefunden hat.

Für Aktionen zu RAP-Einträgen können nach Auswahl eines oder mehrerer Einträge in den Ansichten „RAP product“ bzw. „Client specifics“ abhängig vom Status die folgenden Aktionen über die Dropdown-Liste „Select what action to take“ ausgeführt werden:

• Für Einträge mit dem Status „Default blocked, not actioned“:
  • Acknowledge – Ändert den Status in „Blocked“.
  • Add to Allowlist:
    • Beim Hinzufügen einer IP-Adresse zur Allowlist ermöglicht das modale Fenster die Auswahl einer einzelnen oder mehrerer GPs.
    • Ein Ablaufdatum kann konfiguriert werden.
    • Wenn die M365-Validierung aktiviert ist und der Risikoscore den Schwellenwert überschreitet, wird ein zusätzlicher Bestätigungsdialog angezeigt.

• Für Einträge mit dem Status „Blocked“:
  • Add to Allowlist:
    • Beim Hinzufügen einer IP-Adresse zur Allowlist ermöglicht das modale Fenster die Auswahl einer einzelnen oder mehrerer GPs.
    • Ein Ablaufdatum kann konfiguriert werden.
    • Wenn die M365-Validierung aktiviert ist und der Risikoscore den Schwellenwert überschreitet, wird ein zusätzlicher Bestätigungsdialog angezeigt.

• Für Einträge mit dem Status „Allowlisted“:
  • Remove from Allowlist:
    • Nur verfügbar, wenn der Allowlist-Eintrag exakt mit der aufgeführten IP-Adresse übereinstimmt.
    • Beim Entfernen einer IP-Adresse aus der Allowlist ermöglicht das modale Fenster die Auswahl einer einzelnen oder mehrerer GPs.
    • Das Entfernen von IPs, die Bestandteil eines definierten IP-Bereichs in der Allowlist der Gruppenrichtlinie sind, wird nicht unterstützt.

Wie bereits erwähnt, kann die Allowlist-Aktion bei der Auswahl einer einzelnen GP ausgeführt werden. In diesem Fall wird das folgende Validierungsfenster angezeigt:

oder bei der Auswahl mehrerer GPs; dieses Szenario wird im folgenden modalen Fenster dargestellt:

Ransomware Encryption Protection X: verbesserter Schutz und bessere Leistung

In unserem REP-Endpoint-Untermodul ist jetzt eine neue Ransomware-Encryption-Protection-X-Engine verfügbar. Der Kernel-Minifiltertreiber von Ransomware Encryption Protection X kann unter Endpoint Settings -> auf eine Windows-GP klicken -> Endpoint Detection -> Ransomware Encryption Protection, Abschnitt „Ransomware Encryption Protection X“ der GP aktiviert bzw. deaktiviert werden (standardmäßig für neu erstellte Gruppenrichtlinien aktiviert).

Hinweis: Die REP-X-Einstellungen funktionieren genauso wie REP v1 (allgemeine Einstellungen und Ausschlüsse).
REP X wird in den Windows-Diensten als separater Dienst („HeimdalREPService“) angezeigt.
Alle 2 Minuten wird eine Integritätsprüfung durchgeführt, um zu überprüfen, ob der REP-Dienst noch ausgeführt wird, und ihn gegebenenfalls neu zu starten.

Die verbesserte Erkennung und Geschwindigkeit der REP-X-Engine resultiert aus der Vielseitigkeit und Leistungsfähigkeit des neuen Kernel-Minifiltertreibers. Dieser kann mehr als 800 Ransomware-Kategorien erkennen und stoppen, da er vier Unter-Engines umfasst:

Encryption Engine:

• Ermöglicht die Überwachung der Dateiverschlüsselung in Echtzeit, um unbefugte Verschlüsselungsversuche zu erkennen.
• Ist standardmäßig aktiviert, wenn eine neue GP erstellt wird.

Rename Engine:

• Erkennt verdächtige Aktivitäten beim Umbenennen von Dateien, die bei Verschlüsselungsangriffen durch Ransomware häufig verwendet werden.
• Ist standardmäßig aktiviert, wenn eine neue GP erstellt wird.

Volume Shadow Copy Engine:

• Überwacht und schützt Volumeschattenkopien vor dem Löschen, um Wiederherstellungspunkte zu erhalten.
• Ist standardmäßig aktiviert, wenn eine neue GP erstellt wird.

Canary Engine:

• Aktiviert die Erstellung und Überwachung von Täuschungsdateien, um unbefugten Zugriff zu erkennen.
• Ist standardmäßig aktiviert, wenn eine neue GP erstellt wird.
• Es stehen vier zusätzliche Einstellungen für die Canary Engine zur Verfügung:
  • Canary visibility – Steuert die Sichtbarkeit von Canary-Dateien: ausgeblendet, sichtbar oder als Systemdatei ausgeblendet.
  • Canary folders – Gibt den Speicherort an, an dem Canary-Dateien abgelegt werden. Diese Ordner sollten vertrauliche oder besonders gefährdete Verzeichnisse umfassen.
  • Canary file types – Wählt die für Canary-Fallen verwendeten Dateitypen aus. „All“ umfasst gängige Dokument- und Medienformate. Beim Erstellen von Canary-Dateien werden die Formate zufällig ausgewählt.
  • Canary suffix – Fügt allen Canary-Dateien ein eindeutiges Suffix zur einfachen Identifizierung und Filterung hinzu.
    Hinweis: Ein Benutzer kann eine Canary-Datei nicht löschen. Wenn versucht wird, eine solche Datei zu löschen, wird im Heimdal-Agent eine Popup-Meldung angezeigt.

Unabhängig davon, welche Unter-Engine den Erkennungs- und Blockierungsvorgang auslöst, erhält der Endbenutzer die folgende Popup-Meldung vom Heimdal-Agent.

Heimdal Email Protection

Email Security – verbesserte Bedrohungskategorisierung im Quarantänebericht: Botnet-Unterstützung

Diese neue Verbesserung erhöht die Transparenz und Bedrohungskategorisierung im Quarantänebericht von Email Security durch die Unterstützung des Bedrohungstyps „Botnet“.

Die Kategorie „Botnet“ wird jetzt automatisch unter der Auswahl „Spam“ im Quarantänebericht berücksichtigt. Dadurch werden als Botnet eingestufte E-Mails korrekt angezeigt und über die vorhandenen Quarantänemechanismen verarbeitet, ohne dass eine manuelle Konfiguration erforderlich ist. Diese Aktualisierung verbessert die Bedrohungsabdeckung und gewährleistet eine konsistente Verarbeitung aller mit Malware verbundenen Elemente, einschließlich Botnet-Datenverkehr.

Unter Network Settings -> Edit/ Add domain -> Quarantine Settings, im Abschnitt „Advanced Threat Protection“, wurde neben der Kategorie „Spam“ eine Infoblase hinzugefügt, die darauf hinweist, dass diese Kategorie speziell Spam und Botnets behandelt.

Wenn diese Kategorie für die Aufnahme in den Quarantänebericht aktiviert wird („Include in Report“), werden Bedrohungen dieses Kategorietyps im Erkennungsfall ausdrücklich gesondert ausgewiesen.

Weitere Verbesserungen und Fehlerbehebungen:

1. Administratives Kontrollkästchen (in den Lizenzierungsoptionen) für NFR-Vereinbarungen

Zur Verbesserung der administrativen Kontrolle und der Genauigkeit der Berichterstattung (Kunden mit NFR-Lizenz werden nicht in die Heimdal-Administrationsberichte „Device and Monthly Billing Info“ aufgenommen) wurde auf Ebene der Corp.-Kunden eine neue Option „NFR“ (Not for Resale) eingeführt. Sie kann nur von Dashboard-Benutzern mit Reseller-Rollen geändert (aktiviert/deaktiviert) werden.
Diese Option wird als Kontrollkästchen dargestellt und ist auf den Seiten „Create Customer“ bzw. „Update Customer“ im Admin-Bereich des Heimdal-Dashboards zu finden.

      Hinweis: Reseller-Benutzer können die NFR-Option nur für einen Corp.-Kunden aktivieren.

Für eine übersichtlichere Navigation wurde auf der Seite Admin -> Customers/ Partners im oberen Bereich ein neuer Filter für NFR-Kunden hinzugefügt (wenn aktiviert, werden nur die NFR-Corp.-Kunden angezeigt und visuell durch ein eigenes Symbol hervorgehoben).

2. Hinzufügen einer Dropdown-Liste „Items per page“ im Bereich „Accounts“

Diese kleine, aber leistungsstarke Verbesserung der Benutzererfahrung besteht aus einer neuen Anpassungsoption im Bereich „Accounts“ des Heimdal-Dashboards (nach dem Klicken auf ein Konto bzw. eine E-Mail). Die Dropdown-Liste ermöglicht die Auswahl der standardmäßig pro Seite angezeigten Ergebnisanzahl (10/50/100) auf den Produktseiten des Heimdal-Dashboards.

●  Forensische Verbesserung – Dateiattribute von „Upload to storage“ und .csv-Export beibehalten

Diese Funktion ermöglicht es Benutzern, strukturierte Metadaten für jede Datei anzuzeigen und zu exportieren, die eine Erkennung ausgelöst und in den Speicher hochgeladen wurde (Unified Endpoint Management -> Standard- und Hardwareansichten -> auf Hostname klicken -> Logs -> Registerkarte Files). Die Metadaten werden gruppiert und in einem modalen Fenster mit vier strukturierten Registerkarten angezeigt:

• General.
• Details.
• Digital Signatures.
• Security.

Dem modalen Fenster wurde eine zusätzliche Schaltfläche „Download CSV“ hinzugefügt, über die Dashboard-Benutzer den gesamten Inhalt aller Registerkarten in eine einzelne CSV-Datei exportieren können.

3. PSA-Integrationen (Autotask & ConnectWise PSA): Verbesserung des Hostname-Abgleichs

Diese Verbesserung betrifft das Hinzufügen eines Hostname-Parameters zum Ablauf der Support-Ticketerstellung in den Heimdal-Integrationen für AutoTask und ConnectWise PSA, um den Abgleich zu vereinfachen.

ConnectWise PSA
 

Autotask