Die Geschichte – und die Herausforderungen – von Firewalls der nächsten Generation
About sixteen years ago, in 2007, Palo Alto Networks introduced their first product, forever altering network security. The term “Next-Generation Firewall,” or NGFW, had yet to be coined. That would happen when Gartner introduced the term in 2009. At the time, Palo Alto’s products fell under the earlier term “Unified Thread Management,” or UTM. While Palo Alto did not invent the UTM or the NGFW, they have since become the defining product in that space, against whom all competitors are measured. For the purposes of this post, we’re just going to use the NGFW moniker for simplicity.
While what we now call “the cloud” certainly did exist in 2007, data centers were still largely being built in the traditional manner: a hard crunchy shell of security around a soft gooey center of data and compute. Only the very boldest of organizations were moving assets into AWS (Amazon Web Services) and other new cloud services. The data center still had a defined and known boundary. The lines were clear between the assets inside the data center and those on the outside.
NGFWs: Perfekt zum Schutz des Rechenzentrumsumfangs
Die NGFW mit ihrer Vielzahl leistungsstarker Sicherheitsfunktionen passte wunderbar zu diesem Modell. NGFWs wurden schnell zu den Gatekeepern von Rechenzentren und kontrollierten sorgfältig, was in einem bestimmten Netzwerk einging (und in weitaus geringerem Maße, was wieder herauskam). Leistungsstarke benutzerdefinierte CPUs analysierten und verschoben Pakete schnell auf ihrem Weg, und die für die Sicherheit verantwortlichen Personen schliefen nachts ein wenig besser, da sie wussten, dass ihre Ressourcen durch eine Reihe neuer Tools geschützt waren.
NGFW vendors such as Palo Alto Networks, Check Point, and Fortinet now set themselves a new goal: dominance inside of the data center, monitoring and controlling traffic between applications, as network segmentation came into vogue as the “hot new thing.”
Here, though, they faced a far greater challenge. NGFWs were an obvious choice to protect the data center perimeter. The prohibitive cost of hardware, licensing, and support was justified by the clear benefits, and the price was kept in check by the fact that Internet connections into data centers were relatively slow compared to connectivity on the inside, and price goes up with bandwidth. On the inside, however, nowhere near such a clear-cut cost/benefit ratio was to be found. A significant percentage of NGFW features, take DDoS mitigation or traffic shaping as examples, had no value on the inside. But you paid for them, regardless.
Als ob die horrenden Kosten für den 10G-Durchsatz nicht schon abschreckend genug für den internen Gebrauch wären, wurden alle Kosten um der Redundanz willen verdoppelt. Es war extrem schwierig, das Fünffache der Ausgaben einer herkömmlichen Firewall für eine Reihe von Funktionen zu rechtfertigen, die übertrieben und oft nicht relevant für die anstehende Aufgabe waren.
That said, industry and government regulations require certain controls on the inside, at least for certain classes of applications. HIPPA and PCI come to mind as stand-out examples. So, customers settled on hybrid solutions, with NGFW devices protecting the boundary and a few critical, specific applications, with traditional stateful, non-NGFWs taking up the slack of internal protection. This unhappy marriage of old and new worked for a while. All the way up until the mainstream acceptance of the public cloud.
Management der NGFW-Komplexität in der Cloud
Die Public Cloud hat die Sicherheitswelt auf den Kopf gestellt. Aber nicht für jeden und nicht immer auf offensichtliche Weise.
Denken Sie daran, dass NGFWs bei jedem Paket, das ihr Gehäuse durchläuft, eine erstaunliche Menge an Verarbeitung durchführen. Die Intel-Architektur, so allgegenwärtig sie auch ist, ist eine schlechte Wahl für die epischen Mengen an Low-Level-Arbeit, die innerhalb einer NGFW erledigt werden muss. Palo Alto entschied sich für Cavium Network Processors, um all die Paketinspektion und -manipulation auf niedriger Ebene durchzuführen. Fortinet hat seine eigenen internen Kundenprozessoren entwickelt, um die Arbeit zu erledigen.
Der heutige NGFW ist, gemessen an den Standards von vor nur einem Jahrzehnt, ein Supercomputer der Klasse einer Regierungsbehörde, der sicherlich einen Teil der Kosten ausmacht. Die NGFW-Anbieter reagierten schnell auf den Wechsel in die Cloud mit virtuellen Versionen ihrer Produkte, aber die Leistung war aufgrund der Einschränkungen der Intel-Architektur auf der ganzen Linie miserabel.
Dies führte zu großen Veränderungen in der Art und Weise, wie die Sicherheit an der Grenze von Cloud-Netzwerken gehandhabt wurde. Oft wurden Dutzende von virtuellen Firewalls mit Lastausgleich ausgestattet. Die Netzwerkarchitektur wurde so umgestaltet, dass sie über weitaus mehr Internet-Peering-Punkte verfügen als zu Zeiten, wodurch die Leistungsanforderungen pro Firewall gesenkt wurden. Und Firewall-Anbieter begannen, ihre VM-Implementierungen (Virtual Machine) in Sechser- und Zehnerpacks zu verkaufen, weil ein oder zwei Firewalls diese Aufgabe nicht mehr erfüllen konnten.
If that sounds complex to build and manage, pity the more typical company who moved only a portion of their assets to the cloud. As both IaaS (Infrastructure-as-a-Service) and PaaS (Platform-as-a-Service) proliferated, network boundaries started becoming increasingly indistinct. Whereas the IT-related definition for “cloud” had been derived from the idea of a large number of computers (analogous to water vapor) seen together as one from a distance, it started becoming more appropriate to use a different definition: “Something that obscures or blemishes.”
Als Rechenzentren begannen, eine zufällige Auswahl von Anwendungen und Teilen von Anwendungen in der Cloud zu hosten, während andere Anwendungen (und Teile von Anwendungen) vor Ort verblieben, wurde es unglaublich schwierig, sie zu schützen und Sicherheitsrichtlinien durchzusetzen. Dies liegt vor allem daran, dass es fast unmöglich wurde, Grenzen zu definieren, auf die normalerweise Sicherheit angewendet wird. Und selbst in den Fällen, in denen die Grenzen klar waren, wurde die schiere Menge an Sicherheitshardware, -software und -konfiguration überwältigend.
In der Folge machte die Sicherheit einen großen Schritt zurück.
Blick in die Zukunft: NGFW-Funktionen in einer Mikrosegmentierungsumgebung
Thus began the area of what was known in the early days as microsegmentation, and what is now more often called Zero Trust Segmentation (ZTS).
Das Konzept der Mikrosegmentierung ist einfach: Durchsetzung von Richtlinien (d. h. Firewalls) auf jedem Server, die sowohl den eingehenden als auch den ausgehenden Datenverkehr zu jedem anderen Server kontrollieren. Im Grunde genommen ist die Mikrosegmentierung einfach eine Erweiterung der Idee der Netzwerksegmentierung, die auf die Spitze getrieben wird (eine Firewall pro Server). Die Mikrosegmentierung gab Sicherheitsteams ein leistungsstarkes neues Werkzeug an die Hand, um die "unscharfen Grenzen" um und in unseren Rechenzentren zu bewältigen, indem sie die Sicherheit auf Server-für-Server-Basis (oder zumindest von Anwendung zu Anwendung) angingen.
In der Vergangenheit hat sich die Mikrosegmentierung mit Ports und Protokollen befasst, ohne in das für NGFW-Funktionen erforderliche Gebiet der Deep Inspection einzutauchen.
Im Büro des CTO ist es meine Aufgabe, "Was wäre, wenn?" zu spielen und zu versuchen, auf mögliche zukünftige Probleme und deren mögliche Lösungen zu blicken. Die aktuelle Forschung bei Illumio befasst sich daher unter anderem mit den Möglichkeiten, NGFW-Funktionen in einer Mikrosegmentierungsumgebung zu implementieren.
Lesen Sie nächste Woche meinen Blog, um mehr über die Forschung von Illumio und diese potenziellen zukünftigen Entwicklungen im Bereich der Mikrosegmentierung zu erfahren.
.png)
.webp)
.webp)
