Sicherheit von Tag 1 bis Z : Modellbasiertes ganzheitliches Lifecycle-Management für IT-Produkte

Nahezu alle Prozesse in Unternehmen, Behörden und sonstigen Institutionen setzen das Vorhandensein einer funktionierenden und verfügbaren IT-Infrastruktur voraus – und dies erfordert die regelmäßige Beschaffung und Inbetriebnahme, den Betrieb und die Außerbetriebnahme von Teilen der IT-Infrastruktur. So simpel dieser immer wiederkehrende Zyklus erscheint, so häufig wird in der Praxis nur von einer Phase zur nächsten geplant. Diese Vorgehensweise führt jedoch regelmäßig zu Schwachstellen im Bereich der Informationssicherheit. Die verantwortlichen Personen haben dann schlicht nicht vorausgedacht – also nur reaktiv statt proaktiv gehandelt.

Um die Einhaltung der Informationssicherheits-Schutzziele durchgehend gewährleisten zu können, sollten bereits vor und müssen spätestens im Rahmen der Beschaffung alle Phasen des Lebenszyklus geplant werden. Als herausfordernd stellen sich in diesem Zusammenhang derzeit vor allem folgende Aspekte dar:

• Die Komplexität in IT-Infrastrukturen steigt stetig an [1,2] – durch den zunehmenden Grad der Vernetzung und den Einsatz neuer Technologie erhöhen sich die Integrationsdichte und -tiefe.
• Fehlendes Know-how in Zusammenhang mit dieser gesteigerten Komplexität sorgt für zusätzliche Schwierigkeiten beim Entwickeln vorausschauender Strategien zum Einsatz von IT-Produkten [1] – die fachliche Durchdringung des Technologiestacks und seiner Schnittstellen wird zunehmend schwieriger.
• Gestörte weltweite Lieferketten sorgen für Lieferengpässe und teilweise extrem lange Lieferzeiten bei der Beschaffung von IT-Produkten aller Art [3] – die langfristige Planbarkeit der Lebenszyklen von Hard- und Software wird hierdurch negativ beeinflusst.
• Maßnahmen zur Steigerung der IT-Sicherheit stellen einen Kostenfaktor während des gesamten Lebenszyklus von IT-Produkten dar [1] – trotz Methoden zur Schaffung einer Kosten-Nutzen-Transparenz in diesem Umfeld (z. B. „Return on Security Invest“, ROSI) versuchen Organisationen, gerade bei solchen Aspekten Kosten zu senken oder vollständig einzusparen.

Begrifflichkeiten

IT-Produkte

Zur IT-Infrastruktur in Organisationen gehören unterschiedliche Arten von IT-Produkten. Zur Schaffung eines einheitlichen Verständnisses werden diese für diesen Beitrag anhand ihrer Eigenschaften einer von vier Kategorien zugeordnet.

• IT-Systeme sind eine Kombination aus Hardware und in der Regel vollständigen Betriebssystemen. Dazu zählen unter anderem Server(-systeme), Desktop- und Notebook-Computer sowie mobile Endgeräte wie Smartphones und Tablets.
• IT-Komponenten sind Hardwaresysteme mit hardwarenahem Betriebssystem oder Firmware. Dazu zählen unter anderem Netzwerkhardware wie Router und Switches, Netzwerk- und IT-Sicherheitsappliances wie Firewalls und Intrusion-Detection/Prevention-Systeme (IDS/IPS), Peripheriegeräte wie Drucker und Smartboards sowie Embedded Systems, beispielsweise Zutrittskontrollsysteme und Überwachungskameras.
• IT-Applikationen sind Computerprogramme, die Anwendungsfunktionalität auf IT-Systemen oder IT-Komponenten zur Verfügung stellen. Dazu zählen unter anderem Softwaresuiten, Standard- sowie Individualsoftware.
• IT-Ressourcen sind abstrakte, immaterielle Produkte, über die IT-Dienste und IT-Applikationen bereitgestellt werden. Dazu zählen unter anderem Cloud-Ressourcen (SaaS, PaaS, IaaS), Webdienste und -ressourcen sowie Webhosting.

Der Autor fasst die genannten Kategorien unter dem Begriff „IT-Produkte“ zusammen. In der Praxis kommt es sowohl vor, dass nur einzelne Produkte, also etwa ausschließlich eine IT-Komponente, beschafft werden, als auch, dass mehrere Produkte aus unterschiedlichen Produktkategorien in Kombination zu beschaffen sind, beispielsweise ein IT-System zusammen mit einer IT-Applikation. Die Beschaffung erfolgt entweder im Rahmen von (mitunter größeren) Projekten, als Einzelbeschaffung oder auch als regelmäßig wiederkehrende Beschaffung standardisierter Produkte.

Lebenszyklus

Der Lebenszyklus aller oben erwähnten IT-Produkte lässt sich in die im Folgenden beschriebenen vier Phasen „Beschaffung“, „Inbetriebnahme“, „Betrieb“ und „Außerbetriebnahme“ unterteilen.

• Planung und Beschaffung:
  Zu Beginn des Lebenszyklus steht die Anforderung des Fachbereichs. Diese kann einerseits durch den Bedarf an einer neuen Funktionalität im Sinne eines neuen oder veränderten Geschäftsprozesses begründet sein. Andererseits kann es sich auch bereits um eine technische Anforderung einer konkreten Produktart oder eines konkreten Produkts handeln. Basierend darauf ist eine Anforderungsanalyse durchzuführen, um alle funktionalen und nicht-funktionalen Anforderungen vollumfänglich zu erheben, zu kategorisieren und zu priorisieren. Anschließend erfolgt je nach Situation parallel oder nacheinander die Auswahl des oder der zu beschaffenden Produkte und bei komplexeren Vorhaben die Planung von Systemarchitekturen und der Integration der Produkte in die Bestandsinfrastruktur. Ebenso sind mögliche Hersteller und Lieferanten zu prüfen und auszuwählen sowie gegebenenfalls Verhandlungen mit diesen zu führen. Sind alle diese vorbereitenden Schritte abgeschlossen, folgt die tatsächliche Beschaffung im kaufmännischen Sinn in Form der Bestellung und Lieferung.
• Inbetriebnahme:
  Im Rahmen der Inbetriebnahme werden Soft- und Hardware installiert, konfiguriert und integriert. Die Durchführung obliegt je nach Umfang internen Mitarbeitern, externen Dienstleistern oder Mitarbeitern des Lieferanten oder Herstellers. Die einzelnen Komponenten und das Gesamtsystem sowie alle Schnittstellen sind zwingend zu testen! Diese Tests bilden die Grundlage für die Abnahme, deren Ziel die Prüfung der Konformität mit der in der Phase „Planung und Beschaffung“ definierten Spezifikationen sowie weiteren Vorgaben ist. Die Abnahme sollte in formalisierter Art und Weise stattfinden, um allen Kriterien ausreichend Beachtung zu schenken. Im Zug der Abnahme erfolgt der Übergang der Betriebsverantwortung auf den Verantwortlichen (siehe unten).
• Betrieb:
  Die normalerweise zeitlich am längsten andauernde Phase ist die des Betriebs. Im Anschluss an die im Rahmen der Inbetriebnahme erfolgte Abnahme befindet sich das IT-System, die IT-Komponente, die IT-Applikation oder die IT-Ressource im Regelbetrieb und stellt die geforderte Funktionalität bereit. Die Verfügbarkeit ist gemäß der in der Phase „Planung und Beschaffung“ definierten Anforderungen durch Wartungs- und Servicetätigkeiten und bei Bedarf durch Maßnahmen zur Störungsbeseitigung sicherzustellen. Im Idealfall legt man bereits während der ersten Phase fest, wie lange die Lebensdauer des IT-Produkts sein wird: Das erleichtert die vorausschauende Planung mehrerer aufeinander folgender Iterationen des Lebenszyklus.
• Außerbetriebnahme: Am Ende des Lebenszyklus endet der Regelbetrieb des IT-Produkts. Sofern eine dadurch bereitgestellte Funktionalität weiterhin zur Verfügung stehen muss, beginnt der Lebenszyklus parallel neu mit der Phase „Planung und Beschaffung“ und es erfolgt die Ablösung der bestehenden Funktionalität durch eine Neubeschaffung und Migration – andernfalls endet der Lebenszyklus. In jedem Fall ist sicherzustellen, dass die betroffenen IT-Produkte vollständig und ohne verbleibende Artefakte dekommissioniert werden.

Auswirkungen von Leasing

Eine interessante Randbetrachtung ist die Art des Erwerbs aus kaufmännischer Perspektive beziehungsweise aus Sicht der Finanzierung: Grundsätzlich gibt es die Varianten Kauf, Miete sowie Leasing (vgl. etwa [1]) – die Verfügbarkeit einzelner Varianten hängt im konkreten Einzelfall von der Produktart und vom jeweiligen Hersteller oder Lieferanten ab.

Unabhängig von anderen Vor- und Nachteilen können sich unter Umständen aus Sicht der IT-Sicherheit Synergieeffekte ergeben, wenn Hardware geleast oder gemietet statt gekauft wird: Hierdurch resultieren nämlich automatisch feste Laufzeiten und die Kalkulierbarkeit und Planbarkeit eines regelmäßigen Austauschs steigert sich.

Leasing trägt dann etwa dazu bei, dass Hardwarebeschaffungen nicht hinausgezögert werden und so keine „Altsysteme“ mit nicht mehr vom Hersteller unterstützten Betriebssystemen oder Applikationen im Bestand der Infrastruktur bestehen. Im Zuge der Kostenplanung sind allerdings entsprechende Preissteigerungen und eine Aufstockung der vorhandenen Hardware im künftigen Zyklus zu berücksichtigen.

Lebenszyklus-Modell

Um einen ganzheitlichen Blick auf alle Phasen des Lebenszyklus zu erhalten, schlägt der Autor das in Abbildung 1 dargestellte Modell vor. Seine Kernelemente sind die drei Bereiche „Beteiligte“, „Verantwortung“ und „Operative Sicherheit“. Diese liegen – gestützt durch ein Betriebskonzept – dem Lebenszyklus mit all seinen einzelnen Phasen zugrunde und umfassen technische und organisatorische Maßgaben zur IT- und Informationssicherheit in aggregierter Form.

Beteiligte

Die IT-Sicherheit wird in der Praxis regelmäßig bereits dadurch unterminiert, dass in der Phase „Planung und Beschaffung“ nicht von Anfang an alle zu beteiligenden Personenkreise informiert und gehört werden. Dazu können zählen:

• der anfordernde Fachbereich
• die (interne) IT-Abteilung
• das zentrale oder IT-interne Projektmanagement
• der zentrale Einkauf oder falls vorhanden das IT-Sourcing
• Datenschutzbeauftragte
• Informationssicherheitsbeauftragte
• IT-Sicherheitsbeauftragte

Sofern die genannten Personengruppen nicht von Beginn an ausreichend beteiligt sind, ist es wahrscheinlich, dass deren spezifische funktionale und nicht-funktionale Anforderungen an das IT-Produkt teilweise oder in Gänze nicht erfüllt werden – was wiederum das Niveau der IT-Sicherheit senken kann. Abhilfe schaffen klare Beschaffungsprozesse (auf Basis von Beschaffungs-Richtlinien und sonstigen Regelwerken), die für einen angemessenen Informationsfluss sorgen [1]. Ebenso positiv wirkt sich die Anwendung bewährter Projektmanagementmethoden aus, die eine ausreichende Steuerung und Kontrolle der Abläufe bewirken.

Verantwortung

Besonders wichtig ist die rechtzeitige Festlegung der Verantwortung/Verantwortlichkeit für ein IT-Produkt. Hierbei hilft meist – und besonders in Unternehmen mit agiler Arbeitsweise – die Besetzung von Rollen wie „Product-Owner“, „Tech-Owner“ und so weiter. Hierfür sollten Rollenbeschreibungen mit klar abgegrenzten Tätigkeiten und Verantwortungsbereichen vorliegen. Je nach Art und Anzahl der IT-Produkte lässt sich die Verantwortung nur insgesamt vergeben oder aber teilen: Handelt es sich um einzelne IT-Komponenten, IT-Applikationen oder IT-Ressourcen ist eine Trennung der Verantwortung entweder nur schwierig oder nicht sinnvoll möglich.

Bei IT-Systemen mit darauf installierten IT-Applikationen lässt sich die Verantwortung an verschiedenen Stellen im Technologiestack trennen (vertikale Verantwortungsteilung, vgl. Abb. 2). Wichtig ist hierbei, dass es auf einer Ebene nicht mehrere Verantwortliche gibt, sondern die Verantwortung nur einem Rolleninhaber obliegt. In größeren Organisationen sind oft dedizierte Teams für die Applikationsadministration zuständig oder das entsprechende Know-how ist im anwendenden (Nicht-IT-) Fachbereich vorhanden (in Abb. 2 hellblau hinterlegt). Alternativ hierzu ist ein Rückgriff auf externe Dienstleister möglich. Sofern es sich um technische „Inseln“ handelt, wird Variante 1 aus Abbildung 2 infrage kommen – bei zentral bereitgestellten Diensten (wie E-Mail, Dateidiensten usw.) ist in der Regel Variante 4 gängig.

In allen anderen Fällen (Variante 2 und Variante 3) verteilt sich die Verantwortung auf unterschiedlichen Ebenen im Technologiestack.

Sofern mehrere verschiedene IT-Produkte in Kombination beschafft und betrieben werden sollen, ist eine Trennung der Verantwortung zwischen diesen ebenfalls praktikabel (horizontale Verantwortungsteilung) – und auch Mischformen sind in diesem Zusammenhang möglich (siehe Abb. 3).

Die klare Definition und Trennung von Verantwortlichkeiten soll dafür sorgen, dass vor allem die Vorgaben aus dem Bereich „Operative Sicherheit“ tatsächlich umgesetzt werden. Wenn sich beispielsweise niemand für die Installation von Updates auf einem IT-System verantwortlich fühlt, können Sicherheitslücken entstehen, die sich negativ auf die IT- und Informationssicherheit auswirken.

Bei allen genannten Varianten empfiehlt es sich, die für die Phase „Betrieb“ relevanten Leistungen in Service-Level-Agreements (SLAs) abzufassen – unabhängig davon, ob externe Parteien an der Betriebsverantwortung beteiligt sind oder nicht. Zu den abzubildenden Leistungen gehören unter anderem die Beseitigung von Störungen, die Installation von Patches und Updates, die Durchführung von Konfigurationsanpassungen et cetera. Durch eine solche Verschriftlichung entstehen auch bei ausschließlich internen Zuständigkeiten klare Strukturen und verbindliche Vorgaben. Falls eine interne Verrechnung stattfindet, stellt sie außerdem eine wichtige Grundlage für „Make-or-Buy“-Entscheidungen dar.

Operative Sicherheit

Aufgrund technisch unterschiedlicher Eigenschaften lässt sich keine für alle IT-Produkte allgemeingültige Liste von Anforderungen an die Betriebssicherheit erstellen. Die nachfolgend genannten Punkte dienen jedoch als Übersicht, was man grundsätzlich bedenken sollte. Die Reihenfolge der Aufzählung stellt hierbei keine Wertung dar – in Klammern sind jeweils die dadurch hauptsächlich gestützten Informationssicherheitsziele genannt. Die Beachtung dieser Punkte ersetzt natürlich nicht die Implementierung umfangreicher Standards und Normen wie BSI-Grundschutz oder die ISO-27000-Reihe.

• Ausfallsicherheit (Verfügbarkeit): Je nach individueller Anforderung hinsichtlich der Verfügbarkeit des oder der IT-Produkte(s) ist zu prüfen, ob ein möglichst ausfallsicherer Betrieb notwendig ist und wie man ihn erreichen kann. Allem voran sollte man eine redundante Auslegung kritischer Teile des Produkts in Betracht ziehen.
• IAM – Identity- and Access-Management (Vertraulichkeit, Integrität): Im Zuge des IAM ist ein Berechtigungskonzept zu erstellen. Weiterhin sind Regeln für die Vergabe von Benutzerkonten und Passwörtern festzulegen. Sofern vorhanden ist dabei auf eine zentrale Kennwortrichtlinie zurückzugreifen. Falls technisch möglich, sind alle Authentifizierungsverfahren mit einem zweiten Faktor abzusichern – das gilt besonders für administrative Benutzerkonten und für Accounts, die zur Anmeldung an öffentlich verfügbaren IT-Ressourcen genutzt werden.
• Netzwerksicherheit (Vertraulichkeit, Verfügbarkeit): In der Praxis sind netzwerktechnische „Inseln“ selten. Es ist also in den meisten Fällen davon auszugehen, dass die zu beschaffenden IT-Produkte mit anderen IT-Produkten innerhalb der Bestandsinfrastruktur und in öffentlichen Netzen kommunizieren müssen. Aufgrund dieser Kommunikationsbeziehungen ist festzulegen, in welchem logischen Netzwerkbereich das IT-Produkt eingebunden wird, wie die Kommunikation mit anderen IT-Produkten erfolgt und welche Voraussetzungen hierfür zu erfüllen sind. Die Kommunikation mit IT-Produkten in anderen
  logischen Netzwerkbereichen hat grundsätzlich über eine Firewall zu erfolgen. Sofern Webdienste nach extern zur Verfügung gestellt werden sollen, sind die Unterbringung in einer demilitarisierten Zone (DMZ) und der Einsatz einer Web-Application-Firewall (WAF) zwingend erforderlich. Muss wiederum auf andere externe Webdienste zugegriffen werden, hat dies über einen Webproxy zu erfolgen.

• Hardening (Vertraulichkeit, Integrität): Je nach Exponiertheit des IT-Produkts ist zu prüfen, ob spezifische Maßnahmen zur systemseitigen Härtung und zur sicheren Grundkonfiguration zu treffen sind. Dies betrifft vor allem die Einstellungen von Betriebssystemen und IT-Applikationen. Gerade beim Betrieb von Webservern sollte man gängige Standards umsetzen (siehe etwa [4]).
• Applikationssicherheit (Vertraulichkeit, Integrität): Innerhalb von IT-Applikationen sollte sichergestellt sein, dass die konzeptionellen Vorgaben aus dem Identity- and Access-Management umgesetzt werden. Ebenso muss man auf IT-Systemen und IT-Komponenten dafür sorgen, dass nur die zwingend notwendigen, explizit freigegebenen Applikationen mit den jeweils notwendigen, minimalen Rechten ausgeführt werden können (Application-Whitelisting).
• Patch- und Updatemanagement (Vertraulichkeit, Integrität): Auf IT-Systemen und IT-Komponenten dürfen nur vom Hersteller unterstützte Betriebssysteme, Firmware und IT-Applikationen installiert sein. Weiterhin ist dafür zu sorgen, dass Patches für die Fehler- und Schwachstellenbehebung und Updates für Funktionserweiterungen und Produktverbesserungen regelmäßig installiert werden. Das bedingt sowohl organisatorische Festlegungen hinsichtlich der Häufigkeit und des Automatisierungsgrads der Durchführung als auch technische Aspekte wie die Anbindung an zentrale Update-Server.
• Endpoint-Protection (Vertraulichkeit, Integrität): Auf allen IT-Systemen und IT-Komponenten mit vollwertigem Betriebssystem sollte eine Virenschutz- oder Endpoint-Protection-Lösung installiert werden, die mindestens einmal täglich aktuelle Malwaredefinitionen und sonstige Bedrohungsinformationen erhält. Die Kontrolle des Ausrollens dieser Updates und des aktuellen Status von Agents auf den Systemen sowie zu gefundenen Bedrohungen hat über eine zentrale Instanz zu erfolgen.
• Backup (Verfügbarkeit): Es ist festzulegen, in welchem Zyklus welche Art von Backups erzeugt wird (inkrementelle, vollständige oder „transactional“ Backups) und wie die technische Anbindung hierfür aussieht. Idealerweise erfolgt die Steuerung der Backup-Mechanismen und die Speicherung der Backup-Dateien über/auf einem zentralen Backup-System. Zudem sind regelmäßige Wiederherstellungstests zu planen.
• Monitoring (Vertraulichkeit, Integrität, Verfügbarkeit): Abhängig von der geforderten Verfügbarkeit sollte man prüfen, welche Parameter, Werte und Status in der Phase „Betrieb“ zu überwachen sind und auf welche Weise das erfolgt. Dazu gehören zum Beispiel die generelle Verfügbarkeit von Systemen und Diensten, das Vorhandensein und die Qualität der Netzwerkkonnektivität, die Ressourcenauslastung physischer oder virtueller Hardware, das Erzeugen und Verwenden von Benutzerkonten und Diensten und so weiter. Ebenso sind zugehörige Schwellenwerte und mögliche automatisierte Alarmierungen zu definieren.
• Change-Management (Integrität, Verfügbarkeit): Jegliche Änderungen an einem IT-Produkt sind im Vorfeld der Durchführung zu planen, zu testen und zu dokumentieren – das betrifft vor allem Tätigkeiten, die in der Phase „Betrieb“ erfolgen. Die in diesen Fällen anzuwendende standardisierte Verfahrensweise ist festzulegen; es empfiehlt sich eine Abwicklung über zentrale Change-Management-Prozesse.

• Physische Sicherheit (Vertraulichkeit, Integrität): Abhängig von der Exponiertheit des oder der IT-Produkte gegenüber unberechtigten Dritten ist zu prüfen, ob und durch welche Maßnahmen die physische Integrität gewährleistet werden kann. Während beispielsweise IT-Systeme durch den Einbau in einem Rechenzentrum (RZ) bereits ein gewisses Niveau hinsichtlich des Zugriffsschutzes erfahren, sollte man bei öffentlich oder halböffentlich zugänglichen IT-Systemen und IT-Komponenten (z. B. Kassensysteme, Besucherterminals) zusätzliche Maßnahmen treffen. Dazu gehören unter anderem die Abschaltung oder Blockierung von nicht benötigten USB- und Netzwerk-Schnittstellen, die Verschlüsselung von Datenträgern und so weiter.
• Offensive Security (Vertraulichkeit, Integrität, Verfügbarkeit): Sowohl zum Ende der Inbetriebnahme (einmalig), als auch während des Betriebs (regelmäßig) sollten Methoden aus dem Bereich „Offensive Security“ angewandt werden, um Schwachstellen, Fehlkonfigurationen und so weiter entdecken zu können. Dazu zählt unter anderem die Durchführung von Penetration-Tests, Schwachstellenanalysen oder Angriffssimulationen. Automatisierte Tools können hierbei für reproduzierbare Ergebnisse sorgen.

Betriebskonzept

Die in der Beschaffungs-Phase festgelegten Vorgehensweisen für alle anderen Phasen sollten in einem Betriebskonzept dokumentiert und zwischen allen Beteiligten abgestimmt werden. Bevor dies erledigt ist, sollte kein Übergang zur „Inbetriebnahme“ erfolgen, um sicherzustellen, dass tatsächlich alle notwendigen Angelegenheiten geregelt wurden. Das Betriebskonzept sollte folgende Punkte enthalten:

• Dokumentation des IT-Produkts – beziehungsweise bei komplexeren zusammenhängenden Strukturen:
  eine komplette Produkt- und Architekturübersicht inklusive der Beschreibung aller Schnittstellen und Kommunikationsbeziehungen
• Nennung und Beschreibung der in den einzelnen Phasen des Lebenszyklus durchzuführenden Tätigkeiten sowie etwaige Meilensteine und mögliche Abnahmekriterien zur Erreichung der nächsten Phase
• Nennung und Beschreibung möglicher Restriktionen (z. B. klare Abgrenzung zwischen einem evtl. Proof-of-Concept und der späteren Produktivumgebung)
• Definition der Verantwortlichkeiten (s. o.)
• Beschreibung der Abläufe für Wartung, Service und Störungsbeseitigung mit zugehörigen SLAs und Meldewegen
• Beschreibung der konkret getroffenen oder noch zu treffenden Sicherheitsmaßnahmen aus dem Bereich „Operative Sicherheit“
• Festlegungen zu Datensicherheit und Datenschutz, darunter auch ein Löschkonzept für den Umgang mit Daten und Datenträgern in der Phase „Außerbetriebnahme“
• Falls die Erfüllung von Gesetzen, Normen und Standards erforderlich ist: Verweis auf die entsprechenden Normen oder deren relevante Bestandteile

Fazit

Das vorgestellte Modell kann dabei helfen, die IT- und Informations-Sicherheit in den gesamten Lebenszyklus von IT-Produkten zu integrieren und in diesem Zusammenhang eine Betrachtung des Gesamtprozesses zu erleichtern. Gerade Aspekte der operativen Sicherheit während des Regelbetriebs lassen sich so rechtzeitig im Vorfeld adressieren. Die Schaffung klarer Verantwortlichkeiten trägt zusätzlich zu einem angemessenen Niveau der IT- und Informations-Sicherheit bei. ■

Benedikt Schmieder ist hauptberuflich IT-Security-Analyst und bietet nebenberuflich Unternehmen Unterstützung als selbstständiger IT-Berater an.

Literatur

[1] Ernst Piller, Beschaffung unter Berücksichtigung der IT-Sicherheit, Wichtigkeit, Herausforderungen und Maßnahmen, Springer Vieweg, 2017, ISBN 978-3-658-18598-5 (Softcover) bzw. 978-3-658-18599-2 (eBook)
[2] Eberhard von Faber, Wolfgang Behnsen, Joint Security Management: organisationsübergreifend handeln, Springer Vieweg Edition <kes>, 2018, ISBN 978-3-658-20833-2 (Hardcover und eBook) bzw. 978-3-658-20834-9 (eBook)
[3] Peter Marwan, Lieferschwierigkeiten bei IT-Infrastruktur, ChannelPartner, Dezember 2022, www.channelpartner.de/a/lieferschwierigkeiten-bei-it-infrastruktur,3615900
[4] Chandan Kumar, Apache Web Server Hardening and Security Guide, Geekflare, September 2022, https://geekflare.com/apache-web-server-hardening-security/