--- title: "Die 5 Säulen der IT-Resilienz: Praxis-Framework" date: 2026-05-12T09:05:00+02:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//de/blog/die-5-säulen-der-it-resilienz-praxis-framework" section: "Entries: Articles" --- ### Säu­le 1: Prä­ven­ti­on [\#](#s%C3%A4ule-1-pr%C3%A4vention "Säule 1: Prävention") **Ziel:** Angriffs­flä­che redu­zie­ren und Ein­drin­gun­gen erschweren. **Kern­tech­no­lo­gien:** - **Patch-Manage­ment:** Auto­ma­ti­sier­te Updates für OS, Midd­le­wa­re, Soft­ware. Kri­ti­sche Patches inner­halb von Tagen, nicht Wochen. - **End­point Detec­tion & Respon­se (EDR):** Agent auf allen Work­sta­tions, Ser­vern und End­points. Echt­zeit-Bedro­hungs-Erken­nung, Beha­vi­or Analytics. - **Net­work Seg­men­tie­rung (Zero Trust):** Kein impli­zi­tes Ver­trau­en basie­rend auf Netz­werk-Nähe. Jeder Zugriff wird authen­ti­fi­ziert und auto­ri­siert. Micro-Seg­men­tie­rung iso­liert kri­ti­sche Assets. - **Mul­ti-Fak­tor-Authen­ti­fi­zie­rung (MFA):** Auf allen Zugriffs­punk­ten, ins­be­son­de­re für Admin-Accounts und VPN. - **Vul­nerabi­li­ty Manage­ment:** Regel­mä­ßi­ge Scans, Prio­ri­sie­rung nach Seve­ri­ty und Explo­ita­bi­li­ty, reme­dia­ti­on tracking. **Rei­fe­grad-Mes­sung:** Wie lan­ge, bis Sie über einen bekann­ten CVE infor­miert sind und ihn gepatcht haben? Best Prac­ti­ce: Kri­ti­sche Patches < 3 Tage. **ROI:** Prä­ven­ti­on redu­ziert Angriffs-Wahr­schein­lich­keit signi­fi­kant — aber nicht auf 0%. ### Säu­le 2: Detek­ti­on [\#](#s%C3%A4ule-2-detektion "Säule 2: Detektion") **Ziel:** Ein­drin­gun­gen früh­zei­tig erken­nen, um Scha­dens­aus­maß zu limitieren. **Kern­tech­no­lo­gien:** - **SIEM (Secu­ri­ty Infor­ma­ti­on & Event Manage­ment):** Zen­tra­li­sier­te Log-Erfas­sung und ‑Ana­ly­se. Kor­re­la­ti­on von Events über meh­re­re Sys­te­me hin­weg. Anomalie-Erkennung. - **Net­work Detec­tion & Respon­se (NDR):** Über­wa­chung des Netz­werk-Traf­fics auf ver­däch­ti­ge Mus­ter. Erken­nung von Com­mand-and-Con­trol Kommunikation. - **Thre­at Intel­li­gence:** Inter­ne (beha­vi­oral basiert) und exter­ne Feeds (IOCs, CVE, Thre­at Reports). - **Beha­vi­oral Ana­ly­tics:** Base­lining nor­ma­ler Nut­zer- und Sys­tem-Akti­vi­tät. Erken­nung von Abweichungen. - **Log­ging-Stan­dard:** Alle kri­ti­schen Sys­te­me sen­den Logs — Fire­wall, Pro­xy, DNS, AD, End­points. Reten­ti­on min­des­tens 1 – 3 Jahre. **Rei­fe­grad-Mes­sung:** Wie lan­ge zwi­schen Angriff und Erken­nung? Best Prac­ti­ce: < 1 – 2 Stun­den für signi­fi­kan­te Aktivität. **ROI:** Redu­ziert ​“Dwell Time” (wie lan­ge ein Angrei­fer unbe­merkt arbei­tet). Jeder Tag Dwell-Time bedeu­tet mehr Datenexfiltration. ### Säu­le 3: Reak­ti­on [\#](#s%C3%A4ule-3-reaktion "Säule 3: Reaktion") **Ziel:** Auf erkann­te Angrif­fe schnell und struk­tu­riert reagieren. **Kern­tech­no­lo­gien & Prozesse:** - **Inci­dent Respon­se Plan (IRP):** Schrift­lich doku­men­tiert, min­des­tens annu­al reviewd. Kla­re Defi­ni­ti­on von ​“Inci­dent”, Eska­la­ti­ons­stu­fen (SEV 1 – 4), Rollen. - **Inci­dent Com­man­der Struk­tur:** Desi­gnier­te Per­son, die die IR-Koor­di­na­ti­on lei­tet. Kei­ne Dis­kus­sio­nen — kla­re Befehlskette. - **Rol­len & Ver­ant­wort­lich­kei­ten:** IT-Inci­dent-Respon­se-Team, Secu­ri­ty-Team, Foren­sik, Legal, Com­mu­ni­ca­ti­ons, Management-Escalation. - **Kom­mu­ni­ka­ti­ons­plan:** Wer infor­miert den CIO? Wann wird der Vor­stand benach­rich­tigt? Wann müs­sen Kun­den infor­miert wer­den? Wann muss das BSI benach­rich­tigt wer­den (NIS2: 72 Stunden)? - **Foren­sik-Kapa­zi­tät:** Ent­we­der intern oder durch einen retai­nie­ren Dienst­leis­ter. Fähig­keit zu sam­meln, zu bewah­ren und zu ana­ly­sie­ren von Evidenz. - **Iso­la­ti­on & Con­tain­ment:** Ver­fah­ren, um infi­zier­te Sys­te­me schnell vom Netz­werk zu tren­nen, ohne Bewei­se zu zerstören. **Rei­fe­grad-Mes­sung:** Kön­nen Sie einen Inci­dent inner­halb von 1 Stun­de erken­nen und con­tai­nen? Kön­nen Sie eine Kom­mu­ni­ka­ti­on an Vor­stand und BSI inner­halb von 2 Stun­den versenden? **ROI:** Redu­ziert Scha­dens­aus­maß wäh­rend eines akti­ven Angriffs. Die Dif­fe­renz zwi­schen ​“schnel­le Reak­ti­on” und ​“lang­sa­me Reak­ti­on” kann Mil­lio­nen EUR Unter­schied bedeuten. ### Säu­le 4: Wie­der­her­stel­lung [\#](#s%C3%A4ule-4-wiederherstellung "Säule 4: Wiederherstellung") **Ziel:** Sys­te­me aus einem bekann­ter­ma­ßen siche­ren Zustand wiederherstellen. **Kern­tech­no­lo­gien & Prozesse:** - **Mehr­stu­fi­ge Back­up-Archi­tek­tur:** - Tier 1 (Online): Hoch­fre­quen­te täg­li­che Back­ups für schnel­le RTO. - Tier 2 (Air-Gap): Iso­lier­te, nicht-netz­werk-ver­bun­de­ne Back­ups. Die­se Ebe­ne ist resilienz-kritisch. - Tier 3 (WORM-Archiv): Lang­fris­ti­ge Auf­be­wah­rung auf Hard­ware-WORM (Silent Cubes). - Tier 4 (Geo-Red­un­danz): Exter­ne oder geo­gra­fisch ver­teil­te Kopien. 23. **Iso­lier­te Reco­very-Umge­bung (IRE):** Netz­werk-iso­lier­te Infra­struk­tur zum Tes­ten und Durch­füh­ren von Reco­very. Kei­ne Ver­bin­dung zu Pro­duc­tion-AD, kei­nen Inter­net­zu­gang wäh­rend Initi­al Recovery. 24. **Reco­very-Run­books:** Sys­tem-für-Sys­tem Wie­der­her­stel­lungs­an­lei­tung. Abhän­gig­keits­dia­gramm (wel­ches Sys­tem zuerst?). Geschätz­ter RTO pro Sys­tem. Veri­fi­zier­te Anweisungen. 25. **RTO/RPO Defi­ni­ti­on:** Reco­very Time Objec­ti­ve (wie lan­ge darf der Aus­fall sein?) und Reco­very Point Objec­ti­ve (wie viel Daten­ver­lust ist akzep­ta­bel?). Die­se müs­sen aus Busi­ness Impact Ana­ly­sis abge­lei­tet werden. 26. **Reco­very-Tests:** Regel­mä­ßig (min­des­tens quar­tals­wei­se) Reco­very durch­füh­ren und veri­fi­zie­ren. Nicht nur Back­ups tes­ten — voll­stän­di­ge Reco­very testen. **Rei­fe­grad-Mes­sung:** Kön­nen Sie alle kri­ti­schen Sys­te­me inner­halb Ihrer RTO-Zie­le aus Back­ups wie­der­her­stel­len? Haben Sie das in den letz­ten 3 Mona­ten getestet? **ROI:** Wie­der­her­stel­lung ist die letz­te Ver­tei­di­gungs­li­nie. Wenn Säu­len 1 – 3 ver­sa­gen (und sie wer­den ver­sa­gen), ist Wie­der­her­stel­lung Ihre Ver­si­che­rung gegen exis­ten­zi­el­le Risiken. ### Säu­le 5: Anpas­sung [\#](#s%C3%A4ule-5-anpassung "Säule 5: Anpassung") **Ziel:** Kon­ti­nu­ier­li­ches Ler­nen und Verbesserung. **Kern­tech­no­lo­gien & Prozesse:** - **Post-Inci­dent Review (PIR):** Nach jedem Inci­dent (oder regel­mä­ßig, wenn Sie glück­lich sind, kei­nen zu haben): Was ist pas­siert? War­um hat es pas­siert? Wie hät­ten wir es schnel­ler erkannt? Wie ver­bes­ser wir? - **Les­sons Lear­ned Ses­si­ons:** Regel­mä­ßi­ge Mee­tings mit IT, Secu­ri­ty, Manage­ment, Legal. Aus­tausch von Erkenntnissen. - **Table­top Exer­ci­s­es:** Simu­lier­te Sze­na­ri­en durch­spie­len. ​“Was wür­de pas­sie­ren, wenn …?” ohne ech­te Sys­te­me zu beeinflussen. - **Red Team­ing / Pene­tra­ti­on Test­ing:** Exter­ne Sicher­heits-Pro­fis ver­su­chen, Ihre Sys­te­me zu durch­bre­chen. Fin­det Lücken, die inter­ne Tests verpassen. - **Archi­tek­tur-Ver­bes­se­run­gen:** Basie­rend auf Erkennt­nis­sen Sys­te­me umbau­en. Z.B. wenn Ran­som­wa­re ein Sys­tem erreicht hat, das nicht sein soll­te — Seg­men­tie­rung verbessern. - **Trai­ning & Awa­re­ness:** Employee Secu­ri­ty Trai­ning. Jedes Quar­tal Phis­hing-Simu­la­ti­ons. Schu­lung auf neu­en Bedrohungen. **Rei­fe­grad-Mes­sung:** Haben Sie doku­men­tier­te Ver­bes­se­run­gen basie­rend auf Inci­dents oder Tests? Wie vie­le Fin­dings aus Pene­tra­ti­on Tests wer­den inner­halb von 3 Mona­ten remedied? **ROI:** Schließt den Feed­back-Loop. Ohne Anpas­sung wer­den Sie die glei­chen Feh­ler wiederholen. ### Die Inte­gra­ti­on aller 5 Säu­len [\#](#die-integration-aller-5-s%C3%A4ulen "Die Integration aller 5 Säulen") Eine robus­te Resi­li­enz-Stra­te­gie orches­triert alle fünf Säu­len. Ein Beispiel: 1. **Prä­ven­ti­on** redu­ziert Angriffs-Wahr­schein­lich­keit von 100% auf, sagen wir, 5% pro Jahr. 2. Wenn trotz­dem ein Angriff kommt, **Detek­ti­on** iden­ti­fi­ziert ihn nach 2 Stun­den (statt nach 2 Wochen). 3. **Reak­ti­on** iso­liert infi­zier­te Sys­te­me und kon­ta­kiert Vor­stand inner­halb von 1 Stunde. 4. **Wie­der­her­stel­lung** stellt alle Sys­te­me inner­halb von 4 – 8 Stun­den aus iso­lier­ten Air-Gap-Back­ups wie­der her. 5. **Anpas­sung** iden­ti­fi­ziert, dass ein bestimm­ter Admin-Account kom­pro­mit­tiert wur­de — und ver­bes­sert das Pass­word Management. Das Resul­tat: Ein Angriff, der ohne die­se fünf Säu­len 5 Mio. EUR Scha­den hät­te, kos­tet viel­leicht 100.000 EUR (Foren­sik, IT-Mehr­auf­wand, kur­zer Aus­fall) und führt zu dau­er­haf­ten Verbesserungen. ### Häu­fi­ge Fra­gen [\#](#h%C3%A4ufige-fragen "Häufige Fragen") **Kön­nen wir eine Säu­le auslassen?** Theo­re­tisch ja — aber mit erheb­li­chen Risi­ken. Eine feh­len­de Wie­der­her­stel­lungs-Fähig­keit (Säu­le 4) ist ein Durch­bruch für Ran­som­wa­re. Eine feh­len­de Detek­ti­on (Säu­le 2) bedeu­tet lan­ge Dwell Times und mas­si­ve Datenexfiltration. **Wel­che Säu­le ist am wichtigsten?** Säu­le 4 (Wie­der­her­stel­lung) ist der Base­line. Sie MÜS­SEN wis­sen, dass Sie sich wie­der­hertstel­len kön­nen. Dann, in die­ser Rei­hen­fol­ge: 2 (Detek­ti­on), 1 (Prä­ven­ti­on), 3 (Reak­ti­on), 5 (Anpas­sung). **Wie viel kos­tet das?** Das hängt stark von Grö­ße und Kom­ple­xi­tät ab. Ein mit­tel­stän­di­sches Unter­neh­men mit 500 Usern und 50 kri­ti­schen Sys­te­men soll­te mit 500.000−1 Mio. EUR initi­al rech­nen, dann 200 – 300k EUR p.a. für Betrieb. --- ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/disaster-recovery) ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/disaster-recovery) ### WORM WORM (Write Once, Read Many) bezeichnet ein Speicherprinzip, bei dem Daten einmal geschrieben und danach technisch nicht mehr verändert oder gelöscht werden können — bei Hardware-WORM ist diese Unveränderlichkeit eine physikalische Eigenschaft des Speicher-Controllers, unabhängig von Software, Betriebssystem oder Benutzerprivilegien. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/worm) ### WORM WORM (Write Once, Read Many) bezeichnet ein Speicherprinzip, bei dem Daten einmal geschrieben und danach technisch nicht mehr verändert oder gelöscht werden können — bei Hardware-WORM ist diese Unveränderlichkeit eine physikalische Eigenschaft des Speicher-Controllers, unabhängig von Software, Betriebssystem oder Benutzerprivilegien. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/worm) ### WORM WORM (Write Once, Read Many) bezeichnet ein Speicherprinzip, bei dem Daten einmal geschrieben und danach technisch nicht mehr verändert oder gelöscht werden können — bei Hardware-WORM ist diese Unveränderlichkeit eine physikalische Eigenschaft des Speicher-Controllers, unabhängig von Software, Betriebssystem oder Benutzerprivilegien. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/worm)