Admin

Ist ein Hacker oder eine Schadsoftware auf dem System, krallen sie sich oft als erstes privilegierte Accounts, damit sie ihren Angriff durchführen können. Denn ohne privilegierten Account kommen die Angreifer oft nicht sehr weit. Damit dieses meist genutzte Vorgehen funktioniert, müssen zwei Bedinungen gegeben sein:

1. Auf dem Client können Fremdsoftwares ausgeführt werden.
2. Auf dem Client wird mit privilegierten Accounts gearbeitet.

Wenn auf dem Client kein Application whitelisting aktiv ist, aber der Angreifer merkt, dass der User keine privilegierte Berechtigungen hat, die er übernehmen kann, stört er oft das System. Der Benutzer eröffnet darauf ein Ticket bei der IT Abteilung da sein System nicht ordnungsgemäss funktioniert. Ein IT-Supporter wird sich dem Problem annehmen. Um das Problem zu lokalisieren und zu beheben wird er sich oft mit seinem privilegierten Account auf dem System anmelden. Diese Situation wird der Angreifer ausnutzen wollen, um an dessen privilegierten Account heran zu kommen.

Wenn der Mitarbeiter dann doch mal ein Tool benötigt, Software für einen privaten Drucker oder eine neue Maus installieren muss oder notwendige Anpassungen am System selbst vornehmen soll, gibt es in diesem System sehr flexible Möglichkeiten solche Ausnahmen abzufangen.

Mit sehr gut anpassbaren Dialogen kann auf verschiedene Weise auf Ausnahmen reagiert werden. Von einer reinen Info bis zu komplexen Cheallenge/Response Verfahren/Workflows ist da alles drin.

Why would you ever let someone connect from the outside to your corporate network? Well, historically you had to do so, in order to provide partners or your own remote users access to applications and data. But why do that, when you should only allow access to the applications that the corresponding person is meant to see? Do you connect to the salesforce network when you want to use salesforce?

Nowadays, your users are more and more remote/mobile and applications are moved from your own datacenter to the cloud. The Internet becomes your corporate network. The question is how to implement network security in this scenario? How to achieve a zero trust model? Well, the good news is: A new cloud-based service called Zscaler Private Access (ZPA) enables you to provide access to your private and key corporate applications without ever connecting the user to the network. Users can access your applications in a transparent, secure and fast way – independently from location, device and network.

Gartner calls this Software Defined Perimeter (SDP) and Gartner reported in November 2017: “By 2021, 60% of enterprises will phase out network VPNs for digital business communications in favor of SDP”.

VPN brings connectivity for the users and enables them to access private applications securely. However, it does this by connecting the user to the network. Why would you ever want partners or your own users to share your corporate network when they just need to access a small set of applications? This way your network or some of its elements are exposed to the Internet and might become a target for attacks. And because the access to applications requires the user to be on the network, it can laterally scan other resources and exploit vulnerabilities.

VPN also forces a user to connect to a single location for access – the user over a VPN is locked into the location where the VPN tunnel is connected. This does not make sense anymore when you have applications spread all over your datacenters and in the cloud. Why would you force a remote user to connect to the corporate network only to have them go back out to Microsoft Azure or AWS? VPN has been created in the 90s when users and applications were all in-house and only a few partners and users required remote access.

Not to forget, there are always complaints when it comes to user experience. VPN solutions tend to be clumsy and slow.

The Zscaler Cloud brings two things together: The user (that runs a Zscaler agent on its device) and the application via a connector – a VM that runs in your own datacenter or in a cloud environment. The user is only connected to the application – never to the network. The Zscaler Cloud operates like a switchboard between a caller and a call receiver.

Authentication works via SAML (e.g. ADFS), the Zscaler Cloud provides the logic what users are allowed to see what applications and the user experience is promised to be very good: always-on, transparent, fast and secure. For security-aware customers, they can bring their own keys for double encryption of the tunnels.

As a nice side-effect and heavily marketed by Zscaler, your requirements regarding load balancing, DDoS protection or even internal firewalls for network segmentation are reduced to a minimum. There are many interesting use cases for ZPA starting with pure partner access and M&A acquisitions to cloud migration scenarios and VPN replacement. You may still need VPN for site-to-site connections. However, Zscaler has promised to cover this case in the very near-future as well…

For traditional client-VPN I strongly recommend Pulse Secure. The solution is very stable, very flexible and comes with an intuitive and seamless user experience. Pulse Secure is a highly matured product that meets requirements of customers of every size and industry.

So, what do the people at Pulse Secure think about the new approach from Zscaler? First, they argue that advantages that Zscaler claims for themselves can also be achieved by their own solution. Pulse Secure can restrict access to specific applications by making use of the Secure Application Manager, which provides per-app VPN capability. They confirm that hybrid and multi-clouds are standard mode of deployments now. Obviously, Pulse Secure cover these scenarios as well with a product called Cloud Secure.

Further, they argue that they are much stronger when it comes to device compliance and multiple controls on the end-user sessions. ZPA does not check for device compliance status and offers less flexibility when it comes to the level of secure access. By offering both strict access and moderate security enforcements, Pulse Secure has a strong and flexible offering to meet the requirements from customers across all industries. In their brand new agent version 1.5, Zscaler added a few more posture tests covering a set of criteria that a user’s device must meet in order to access applications with ZPA.

However, Pulse Secure admits that Zscaler provides a unique selling point when it comes to their user- and application-centric dashboard.

There is a leading retailer in Switzerland, who has decided for ZPA in 2018. Why have they? There were mainly two reasons for this. First, they were not happy with their current client-VPN (not Pulse Secure): many user complaints, too complicated, too slow. Second, they have been following a cloud first strategy for a few years and came to the conclusion that this new strategy is difficult to fulfill with traditional VPN.

Now, they are at their final steps of migration and the users’ feedback is very good so far. The main obstacles in the roll-out process were several issues with MacOS. Their final goal is to have ZPA rolled-out on all corporate devices – even for mobile phones and tablets. The customer is very happy with its choice. ZPA is invisible, always-on, cloud-ready and their first step towards zero trust.

Google hat ihre eigenen native Prevention und Detection & Response Lösungen vorgestellt. Sie bietet nebst Anomaly Detection auch automatisches Logging und ein sogenannte Security Health Analytics. Google’s Definition von Visibilität ist: “I can see what I need to see”. Dabei korrelieren sie sehr viele Datenquellen um zu einem einheitlichen Dashboard zu gelangen. Dabei wird so viel als möglich «Cloud-nativ» gelöst (z.B. werden Cloud-Functions für das triggern von Alerts eingesetzt) und sie automatisieren auch sehr viel. Ein interessanter Ansatz, der aber klar aufzeigt, dass in der Cloud sehr viel Komplexität vorhanden ist und noch nicht klar ist, welche Korrelationen dabei die wichtigen und richtigen sind. Time will tell…

Das Google Cloud Security Control Center wird weiterentwickelt und sie bieten jetzt auch VPC Service Logs an (zusammen mit weiteren 30 Security Neuigkeiten wie Event Threat Detection und Policy Intelligence).

Neuere Android Handys (min Android 7) können jetzt auch als Hardware Token für 2FA (Two Factor) benutzt werden.

Eine weitere Neuigkeit wurde als Beta-Version lanciert: Cloud Run. Dabei handelt es sich um eine Serverless Lösung für Container. Das heisst also, man muss sich über die Infrastruktur keine Gedanken mehr machen und kann einfache Container (stateless, http) schnell und günstig deployen. Dahinter läuft GKE und Knative (eine Kubernetes basierte Plattform für Serverless Workloads).

Das Ganze ist Kompatibel mit Stackdriver und hat Monitoring und Logging mit eingebaut. Für einfachere Applikationen ist das eine sehr kostengünstige Alternative und zusätzliche Funktionalitäten können über Partner bezogen werden (Puresec, Nodesource, Stackblitz, etc.)

Serverless ist ein grosses Thema bei Google und sie sehen Cloud Functions (also FaaS) als «Cloud Glue». Weil Serverless Funktionen Event-basiert funktionieren, sind sie sehr gut geeignet um Cloud-interne Abläufe zu steueren (Security, Cloud billing, Workflow, Stream processing, usw).

Ein reiner Serverless Ansatz für Devops könnte bei Google so aussehen:

Code mit Cloud Code -> Build mit Cloud Build -> Deploy mit Cloud Run -> Monitor mit Stackdriver

Ich stelle mich auch mal in unseren Speakers’ Corner und lasse all Eure Antworten und Kommentare auf mich einprasseln. Und starte hier mit dem Thema Authentisieren.

Vor allem müssen die User die Verfahren akzeptieren, nutzen und nicht als lästig empfinden. Aber ich will hier vor allem die technische Seite diskutieren und jeder ist eingeladen, auch seine Argumente mit einzubringen. Deshalb werde ich hier und da etwas übertreiben, provozieren und hoffen, dass es so viel Feedback gibt. Streiten im besten Sinne.

Meine Post-Reihe zum Thema Authentisieren wird wohl drei Teile lang werden. Smart Cards, OTP und ein anderes Verfahren – ein bisschen BIO muss ja heutzutage sein. Wenn dann gewünscht, tauchen wir tiefer in die Kryptografie ein. Mal sehen, wer dann bis zur Zahlentheorie durchhält. Ich verspreche, dass das multiplikative Inverse einer abelschen Gruppe sehr mächtig ist.

OK, aber zurück zum Thema – Smart Cards.

Unter Smart Cards verstehe ich hier richtige SC im Checkkarten-Format oder als USB-Tokens – also kein pfx auf einem Speicherstick.

Primär wird so eine Smart Card zur Authentisierung am Rechner oder VPN / Remote Access-Portalen verwendet. Insbesondere bei der Anmeldung an einem Windows-Rechner erhöht die zertifikatsbasierte Variante die Sicherheit des Kerberos-Protokolls. Auch Mimikatz hat es dann nicht mehr so leicht.

Email-Signatur: Wenn man die Aufgaben an den Benutzer überträgt, besteht die Aufgabe, die Verschlüsselung zu enforcen. Aber das ist vor allem abhängig von der Verfügbarkeit des Public Keys des Empfängers. Hier ist oft eine Gateway-Lösung, vor allem auch durch die richtlinienbasierten alternativen Verschlüsselungen, ein Vorteil. Aber auch hier gehören die Private Keys auf eine „Smart Card“ oder besser ein Hardware Security Module – HSM.

Einfach gesagt, ist es für mich die Kryptografie. Ob nun RSA (klassisch private and public mit Primzahlen) oder ECC (elliptic curve cryptography) ist mir persönlich egal, aber ja man sollte langsam zu ECC wechseln. Gerade in der mobilen Welt und auch WhatsApp nutzen ECC, das muss doch gut sein – oder? Den Part der Kryptologie, ob ECC so gut ist, überlassen wir der Kryptoanalyse.

Das Wichtige ist, dass die Smart Card am Mann oder der Frau bleibt (beim nächsten Mal kommen die Frauen zuerst, für die Gleichberechtigung, versprochen).

Also Token an das Schlüsselbund und die Karte mit einem Cardholder an die Leine legen. Besser ist noch die Kombination mit anderen Funktionen, Corporate Identity, Secure Printing, Payment oder Gebäudezutritt. Wenn das liebe Geld auf der Karte ist, lassen es nur noch wenige rumliegen.

Aber das Wertvolle für die IT-Sicherheit ist der Smart Card Chip. Kryptografische Operationen müssen auf dem Chip erfolgen, denn der private Schlüssel sollte einmalig sein und nur im Zugriff für eine Person.

Smart Cards sind sicherer als OTP-Hardware Token. Hier muss man den Chip «aufhobeln», um an die Informationen zu kommen. Das geht, machen aber wenige. Es ist ja kein HSM, bei dem wir extra Sensoren und entsprechendes Wipen für physische Angriffe vorsehen. Bei OTP-Verfahren kann man den Token Code oder sogar den Passcode telefonisch weitergeben. Token-Seeds können gestohlen werden, das haben wir ja schon erlebt. APT at RSA -2011 nachzulesen bei schneier.comschneier.com. Und heute macht man das (OTP) ja auf dem Smartphone, was die Sicherheit wiedermal zu Gunsten der Usability reduziert, auch wenn die Apps einiges für die Security tun. Software ist keine Hardware. Von SMS sprechen wir hier erst gar nicht. Deshalb ist für mich die Smart Card AuthN sicherer.

So, hier mal der oberflächliche Start zum Thema certificate based authentication und warum Smart Cards als Zertifikatsträger ein Muss sind.

Wer Smart Cards hacken will, schaue hier beim CCC vorbei: 35C3 –  In Soviet Russia Smart Card Hacks You – deutsche Übersetzung35C3 –  In Soviet Russia Smart Card Hacks You – deutsche Übersetzung. Das nächste Mal OTPs.

Wenn ein neuer Mitarbeiter seine Stelle antritt, durchläuft er häufig einen Einarbeitungsprozess. Er wird von seinen neuen Kollegen eingearbeitet, erhält oft on-the-fly Einführungen für die intern eingesetzte Software und muss die Firmenrichtlinien lesen und unterzeichnen. Jedoch wird kein Wort über die eingesetzten IT-Security- und Überwachungsmassnahmen der Firma verloren. In den Firmenrichtlinien steht nur, was der Mitarbeiter nicht darf. Mit der Zeit kommt beim Mitarbeiter ein Misstrauen auf, denn er weiss ja, dass die Firma Ihre IT-Infrastruktur schützen muss und dies auch tut. Aber er weiss nicht wie weit die interne IT geht um die Mitarbeiter zu überwachen.

Dann fragt sich der Mitarbeiter:

• Wird mein Browserverlauf geloggt und analysiert?
• Wird analysiert wie viele nicht-geschäftsrelevante Mails ich versende?
• Was wird sonst noch aufgezeichnet und evtl. ausgewertet?

Diese Ungewissheit schafft Misstrauen und wird das Mail- und Surfverhalten des Mitarbeiters, sowie sein Verhältnis zur Firma zwangsweise beeinflussen.

Softwareentwickler (oder Developer) wollen sich eigentlich nicht um die Infrastruktur kümmern, worauf ihre Applikationen laufen. Sie würden gerne Applikationen schreiben und die Server, das Netzwerk, die Security usw. jemand anderem überlassen.

Bei der Evolution von VM’s hin zu Containern (Docker, Kubernetes, etc.) ist ein Grossteil der Hardware-Eben schon abstrahiert. Der Developer kann bei so einer Umgebung die nötigen Definitionen in einem YAML File auflisten (das ist er sich gewohnt) und das Orchestrierungs-System übernimmt dann den Rest.

Und Serverless geht jetzt eben noch einen Schritt weiter. Der Developer kann einen Teil seines Codes (oft einen Algorithmus, eine Berechnung – deswegen auch «Function») in einem File ablegen, und dann definieren, unter welchen Umständen dieser Code ausgeführt wird.

In solchen Umgebungen ist das Event-getrieben. Konkret bedeutet das z.B. dass ein User auf einem Front-End seine Daten eingibt und diese dann abschickt. Das Abschicken der Daten ist ein Event und kann jetzt eine Funktion triggern. Die Funktion nimmt die Daten vom User und bearbeitet sie, berechnet z.B. den Preis basierend auf den Daten, die der User eingegeben hat.

Der Output dieser Funktion wird z.B. in eine Datenbank und zurück zum Front-End geschickt, damit der User den Preis bekommt. Sobald die Funktion die Berechnung abgeschlossen hat und sie weitergeschickt hat, wird der Code beendet (wenn es eine VM oder ein Container wären, dann würden diese nachher heruntergefahren oder geschlossen werden). Meistens führt die «Function» ihre Funktion in Millisekunden aus.

Kann man mit FaaS oder Serverless jetzt ganze Applikationen ersetzen? Dies wäre zwar wahrscheinlich möglich, ist aber nicht der Sinn der Sache. Wenn man jetzt nämlich 600 Funktionen untereinander verlinken will, dann kann man genauso gut eine Micro-Service Applikation schreiben.
Functions kommen z.B. dann zum Zuge, wenn man immer wieder etwas berechnen oder ausführen will, aber das nicht kontinuierlich macht. Oft werden Functions auch bei IoT Anwendungen eingesetzt, weil die Event-basierte Natur von IoT sehr gut mit Serverless zusammenpasst.

Man kann sich das gut an einem Beispiel vorstellen:

Eine Sonde misst den Inhalt eines Dieseltanks und schickt über MQTT Daten zum AWS IoT Message Broker. Sobald ein neuer Wert hochgeladen wird, schickt der Message Broker diese Daten an AWS Lambda (wo unsere Funktion lebt). Durch diesen Event wird die Funktion aufgerufen. Sie ist so programmiert, dass sie neue Daten immer auf S3 ablegt, aber wenn ein Mindestwert erreicht ist, muss sie einen Alert auslösen (damit der Tank rechtzeitig wieder gefüllt werden kann).

Die Kosten sind dabei äusserst gering, bei einer Messung pro Minute, kann man mit 525’600 Messungen im Jahr rechnen, was zu etwas über einer Million Events pro Jahr führt, ca. $0,20.

So etwas ist nicht mit einer VM Instanz oder einem Container vergleichbar.

Erledigt der Cloud Provider denn nicht auch die Security bei Serverless? Genau gleich wie bei anderen Cloud-Services sind AWS, Azure und Co. für die Sicherheit der Infrastruktur zuständig, in diesem Fall also für die Sicherheit der FaaS Plattform (AWS Lambda oder Azure Functions). Für die Sicherheit der Applikationen und Daten ist der Benutzer weiterhin zuständig. Was kann denn schon passieren bei einer Funktion die nur alle 15 Minuten für weniger als 1 Sekunde aufgerufen wird? Unter Umständen eben einiges, jemand könnte sie unendlich lange laufen lassen und damit kosten verursachen. Oder die Funktion könnte so angepasst werden, dass sie nie einen Alert versendet, was zu einem leeren Tank führen könnte. Oder die Funktion versendet jede 2 Stunden einen Alert und ein Tanklastwagen wird unnötigerweise zu einem noch vollen Tank versendet.

Na gut, wie schütze ich mich dann vor Missbrauch solch einer Funktion? Auf der einen Seite sollte das Image der Funktion wie jedes andere Image vor dem Deployment gegen Vulnerabilities gescannt werden. Und die Images, die im Registry abgelegt sind sollten auch regelmässig gescannt werden, denn eine Vulnerability kann auch nach einem Deployment auftauchen.

Wenn man die Funktion während der Ausführung (runtime) überwachen möchte, dann kommt man nicht darum herum, sie mit einem weiteren Stück Code zu ergänzen. Dieser Security-Code kann als Firewall, als Proxy oder als ein Log-Melder wirken. Damit kann man einschränken mit wem die Funktion kommunizieren darf, worauf die Funktion Zugriff hat, wie lange sie ausgeführt werden sollte (wobei ein Alert ausgelöst werden kann, wenn die Länge der Ausführung einen Grenzwert überschreitet) und ob das Resultat innerhalb des erwarteten Rahmens liegt. Ein Baselining der Funktion über einen gewissen Zeitrahmen hinweg erlaubt auch eine gute Detection von Anomalien (dafür würde am effizientesten ein ML-Algorithmus eingesetzt).

Wer heutzutage aktuelle Netzwerkinfrastrukturen und Cloud-Anbindungen sicher betreiben will, wird immer mehr Firewall-Instanzen einsetzen wollen und müssen. Das Firewall Policy Management wird so schnell zu einer Sisyphus-Arbeit. Prozesse und Abläufe wollen eingehalten werden und die Deadline für den Change rückt immer näher.

Die Vorstellung, diesen ganzen Prozess zu automatisieren, ist bestechend. Der Applikationsverantwortliche pflegt neue Verkehrsbeziehungen in einer intuitiven Webgui ein, daraus werden automatisch Change Requests erstellt. Die Change Requests finden selbständig den Weg zum verantwortlichen Security Officer, welcher aufgrund einer automatischen Risikoprüfung schneller als bisher entscheiden kann, was mit dem Request geschehen soll. Im Optimalfall ergibt die automatische Prüfung ja gar, dass kein Security Officer den Segen geben muss und der Change implementiert werden darf.

Auf welchen Firewalls oder Security Devices die neuen Regeln erstellt werden müssen, wird aufgrund der Routing-Informationen im Netzwerk automatisch erkannt. Und folgerichtig erstellt das Tool die «Work orders» für die betroffenen Firewalls. Automatisch werden die Regeln danach noch auf die Firewalls installiert und die Applikation funktioniert.

Alle so generierten Changes sind einem Verantwortlichen zuzuordnen und ein anstehender Security Audit zaubert anstelle von Schweissperlen nur noch ein Lächeln ins Firewall-Admin-Gesicht.

In der Praxis ist ein Firewall-Policy-Management-Projekt ein “Digitalisierungsprojekt”. Manuelle Prozesse werden miteinander verlinkt und automatisiert. Durch die Automatisierung und Integration muss das Tool mit einer Vielzahl an Herstellern und Produkten kompatibel sein. Ein hoher Automatisierungsgrad kann nur erreicht werden, wenn alle Layer-3-Netzwerkkomponenten und alle Security Devices integriert werden können.

Dies verursacht Abhängigkeiten und Kompatibilitätsprobleme für Netzwerk- und Security-Komponenten und erfordert weitere Kompatibilitätstests, bevor solche Komponenten aktualisiert oder ausgetauscht werden können.

Firewall Change Requests werden in Ihrem Ticketing-System eröffnet und dies soll so beibehalten werden. Somit muss das Autmatisierungstool sich in das Ticketing-System integrieren, im einfachsten Fall mittels E-Mail-Kommunikation, im besten Fall per APIs.

Um einen Change berechnen zu können, müssen IP-Adressen, Hostnamen, Ports und allenfalls Applikationen oder Userdefinitionen auch im Automatisierungstool bekannt sein. Unterschiedliche Quellen wie Firewall-Management-Syteme, DNS-Listen oder IPAM-Quellen können verwendet werden.

Für die Traffic-Flow-Berechnung wird die Netzwerk-Topologie abgebildet. Klassische Netzwerkrouter und auch SDN oder Cloud-Plattformen müssen eingebunden werden. Und schlussendlich muss die Firewall Policy analysiert und verstanden werden um die richtigen Aktionen oder Work Orders zu generieren.

Alle diese involvierten Komponenten müssen mit dem Automatisierungstool kompatibel sein, eine Herkules-Aufgabe für den Hersteller. Ein kleiner Change in den APIs, SNMP-OIDs oder CLI-Kommandos und der Hersteller muss dies nachpflegen. Lock-In-Situationen können entstehen, wenn Upgrades und Migrationen (noch) nicht gemacht werden können, weil das Automatisierungstool die neue Version / Komponente noch nicht unterstützt.

Wir alle haben es schon gehört: «Das ist das erste Mal, dass dieses Problem auftritt, bei anderen Kunden funktioniert das». Dies gibt es leider auch bei Policy-Automatisierungen. Keine Umgebung ist identisch zu der nächsten oder der vorherigen. Jede Integration ist einzigartig und birgt andere potentielle Stolpersteine.

Aus meiner Sicht müssen Automatisierungsprojekte Schritt für Schritt angegangen werden, mit einem klaren Zielbild vor Augen. Ein phasenweises Vorgehen mit Vorteilen und einem klaren Nutzen nach dem Abschluss jeder Phase.

Ein PoC weitab und fern von der Realität meines Netzwerks bringt mir noch nicht die Sicherheit, dass das Tool auch tatsächlich für mich funktioniert. Eine Testinstallation in einem produktiven (Teil-)Netzwerk bringt erste Einsichten und sollte im Idealfall direkt als Testumgebung bestehen bleiben. Mit den Learnings dieser Testinstallation werden die weiteren Schritte geplant und der Automatisierungsgrad erhöht.

Ein Firewall-Policy-Automatisierungstool einzuführen und zu betreiben ist keine «fire and forget»-Übung, sondern bedingt einen initialen Aufwand und kontinuierliche Pflege.

Links:

Bei der AVANTEC setzen wir auf die Produkte-Suite von AlgoSec, «Business-driven security management»: https://www.avantec.ch/loesungen/algosec/

Auf der Herstellerseite von AlgoSec finden sich viele Tutorials, Video-Learnings etc., um sich ein Bild von der Lösung zu verschaffen: https://www.algosec.com/resources/

Ihr werdet nicht glauben, was ich an der CPX erlebt habe. Da war dieser Typ von RnD und was dann passiert ist, war spektakulär.

Sorry fürs „Clickbaiting“. Es gibt da so eine Challenge, mit wer hat die meisten „Klicks“. Aber genug aus dem AVANTEC-Nähkästchen

Seit ein bisschen mehr als einem Jahr wird bereits über die Falcon-Karten gesprochen. Bereits an der letzten CPX wurde die Karte an einem Innovation Track Table vorgestellt. Wer das nicht kennt: Das sind meistens Leute von RnD an einem Tisch, die zeigen, woran sie gerade arbeiten. Interessierte können sich da dransetzen und sich das Produkt/Feature zeigen lassen. Das Coole daran ist, man kann in einem entspannten Rahmen den Leuten von RnD Löcher in den Bauch fragen. Auch dieses Jahr war wieder der gleiche Entwickler an einem dieser Tische, aber diesmal ohne Karte zum Anfassen. Bei der Frage, warum sie dieses Jahr nicht zum Anfassen dabei ist, musste er etwas beschämt gestehen, dass er es diesmal nicht geschafft hat, sie durch den Zoll zu bringen. Haha… Wer den Flughafen in Tel Aviv kennt, der glaubt’s ihm.

Spannend ist ja, wozu die Karten da sind. Die Falcon-Karten sollen den auf Intel basierenden Firewalls einen mächtigen Boost für SSL Inspection und Threat Prevention geben. Und ehrlich gesagt, haben die das bitter nötig. Die Konkurrenz entwickelt seit Langem zu dem Zweck relativ billige ASIC’s, welche mit rasender Performance punkten. Manager, welche sich strikt nach „TCO per protected Mbps“ orientieren, sehen Check Point schnell als relativ teuren Hersteller. Das Image haftet an und kommt auch nicht von ungefähr. Man könnte nun den Agony Meter und das GUI als „de facto Management Gold Standard“ (Quelle: GARTNER) herausstreichen. Es gibt sicher genügend Argumente, die für Check Point sprechen. Aber lassen wir die rosa Brille mal weg.

Gemäss dem Typ von RnD soll eine Falcon Karte 80% mehr Performance für SSL und TP bringen. Das Coole daran: Der Traffic muss nicht mal durch die Karte durch. Das heisst, egal durch welches Interface der Traffic durchfliesst, er wird zur Verarbeitung zur Karte ausgelagert. Und noch besser – man soll mit fünf Kartenslots auch fünf Falcon-Karten einbauen können, welche ihren Performance Boost kumulieren können. Zukunftsmusik ist schon was Tolles. Ich bin sicher, da geht noch das eine oder andere Prozent für das „Clustern“ der Karten flöten. Unter welchen Umständen diese Werte erreicht werden, ist noch nicht bekannt. Aber auch so tönt’s meiner Meinung nach vielversprechend.

Damit diese Magie mit den Falcon Karten funktioniert, musste Check Point kräftig an SecureXL rumschrauben.

In R80.20 wurde die Erzeugung von Templates und Connections zum fw_worker verschoben. Der fw_worker aktualisiert die SecureXL Connection Table nur wenn nötig. Das vereinfacht die Template-Erzeugung und verringert die benötigte Kommunikation zwischen SecureXL und dem fw_worker und verringert die Syncs zwischen den beiden. NAT Templates sind nun per default eingeschaltet und „complexe flows“, wie „partial connection logic“ und „delayed notifications“ sind nicht mehr nötig, wie vor R80.20. Das hat auch positiven Einfluss auf ClusterXL, da die Syncs nur noch auf fw_worker basieren.

Das führt zu weiteren tollen Nebeneffekten, welche mit R80.20 bereits heute verfügbar sind. Allein durch diese „Magie“ soll R80.20 gegenüber R80.10 um 20% Performance-Gewinn bringen. Notabene ohne Falcon-Karten.

Ausserdem stellt sich beim Policy Push SecureXL nicht mehr ab und SecureXL muss auch für das Check Point-eigene Monitoring Tool „fw monitor“ nicht mehr ausgeschaltet werden. Wer kennt nicht den Moment in dem man troubleshooten möchte, SecureXL auschaltet, schnell zu „top“ wechselt und ganz stark hofft, dass einem die Kiste nicht um die Ohren fliegt?

Bleibt zu hoffen, dass Check Point diese Karten zu fairen Preisen verkauft. Oder noch besser, sie überall einfach einbaut. So ab den 6000ern, von mir aus im Bundle mit HPP. Die Marketing-Füchse werden sich sicher was einfallen lassen, da mach ich mir keine Sorgen. Wir werden sehen, wenn es heisst: „the falcon has landed“.