6.9 – A felelősség, amely nem tűnhet el – Zuständigkeit, die nicht verschwinden darf

1. 2017. március 9-én az Apache Struts kritikus hibájáról szóló riasztás eljutott az Equifax biztonsági csapatához .

2. A csapat továbbította azt több mint 400 alkalmazottnak .

3. Az érintett szoftverekért felelősöket arra utasították, hogy 48 órán belül telepítsék a rendelkezésre álló javítást – ez a határidő pontosnak tűnt, annak ellenére, hogy a vállalat nem azonosította megbízhatóan minden olyan helyet, ahol a szoftver futott.

4. Az e-mail gyorsabban terjedhetett, mint amennyire a leltár helyesbítése lehetséges volt .

5. Négy hónappal később egy ACIS nevű fogyasztói vitakezelő alkalmazás még mindig sebezhető volt.

6. A Szövetségi Kereskedelmi Bizottság (FTC) szerint az Equifax csak akkor fedezte fel a rést, miután biztonsági munkatársai július végén gyanús forgalmat észleltek az alkalmazáson, amikor már nem az volt a kérdés, hogy a szoftver sebezhető-e, hanem hogy milyen messzire terjedt a behatolás .

7. Addigra a támadók már kihasználták a rést, hogy hozzáférjenek a személyes adatokhoz .

8. A nyilvánosság szeptember 7-én értesült az adatvédelmi incidensről.

9. A márciusi utasítás valódi volt, de annak kézbesítése soha nem bizonyította, hogy a szükséges munkát minden sebezhető rendszeren elvégezték volna, különösen ott, ahol a vállalat nem tudta biztosan összekapcsolni a sebezhető komponenst azzal a személlyel, aki jogosult volt annak javítására .

10. Ez a különbség az a keskeny rés, amelyen keresztül a felelősség eltűnhet .

11. A riasztás megnevezi a veszélyt; a javítás megváltoztatja a gépet.

12. Közöttük állnak azok az emberek, akiknek tudniuk kell, mely gépek vannak kitéve veszélynek, rendelkezniük kell a módosításhoz szükséges jogosultsággal, és igazolniuk kell, hogy a módosítás működött, még akkor is, ha az alkalmazás átlép a biztonsági személyzet és az üzemeltető csapatok közötti határokat .

13. Az Equifax irányelve határidőt szabott, de az FTC azt állította, hogy a vállalat nem ellenőrizte, hogy a sebezhető rendszerekért felelős alkalmazottak betartották-e azt, így nem maradt megbízható módszer arra, hogy megkülönböztessék a kijavított alkalmazásokat attól, amelynek tulajdonosa nem vette észre az üzenetet.

14. A címzettek száma miatt a figyelmeztetés széles körű volt, de nem feltétlenül teljes.

15. Az FTC azt is állította, hogy az ACIS érintett részéért felelős alkalmazott nem kapta meg azt a figyelmeztetést .

16. Egyik állítás sem jelenti azt, hogy minden címzett irányította az ACIS-t, vagy felismerte annak sebezhetőségét.

17. Ha üzenetet küldenek több száz embernek, az elhomályosíthatja a hiányzó tulajdonos kilétét, amikor minden címzett ésszerűen feltételezi, hogy egy másik csapat karbantartja a vonatkozó alkalmazást, és senkinek sem kell elszámolnia azokról a rendszerekről, amelyek nem válaszoltak .

18. A tulajdonos ebben az értelemben nem az a személy, akit a támadásért hibáztatnak .

19. Hanem az a személy vagy hivatal, akit/amelyet felhatalmaztak arra, hogy a következő döntést meghozza egy konkrét, fennálló kockázattal kapcsolatban .

20. A megkülönböztetés azért fontos, mert egy szervezet nem kezelheti biztonságosan egy el nem ismert feladatot befejezett javításként .

21. Az Equifax a riasztást követő egy héten belül megpróbálta átvizsgálni hálózatát a sebezhető szoftverek felkutatására .

22. A vizsgálat nem találta meg a sebezhető ACIS-komponenst .

23. Az FTC ezt a mulasztást a nem megfelelően konfigurált szkennernak és a szoftverek és rendszerek pontos leltárának hiányának tulajdonította – ez a kombináció úgy tűnhetett, mintha a sikertelen keresés a biztonság bizonyítéka lenne.

24. A vizsgálat csak arra a kérdésre ad választ, amelyre beállították.

25. Ha egy alkalmazás kívül esik a keresési körön, a „tiszta” eredmény kevés információt nyújt magáról az alkalmazásról, bármennyire is megnyugtatónak tűnhet a jelentés egy olyan vezető számára, aki csak a vizsgálat összefoglalójával rendelkezik, és nincs listája a kizárt elemekről.

26. Egy leltár a biztonsági csapat számára kiindulási listát adott volna az ellenőrizendő helyekről.

27. Emellett láthatóvá tette volna a kihagyásokat is: egy olyan alkalmazás, amelynek nincs megnevezett karbantartója vagy megerősített szoftververziója, nyitott tételként maradna, ahelyett, hogy csendben eltűnne a sorból, amikor a vizsgálat nem jelentenek egyezést.

28. Ez másfajta információ, mint egy Struts-ra vonatkozó riasztás.

29. A riasztás a szoftver egy ismert gyenge pontját írja le; a leltár pedig összekapcsolja ezt a gyenge pontot a szervezet saját gépeivel és embereivel.

30. E kapcsolat hiányában még egy technikailag pontos figyelmeztetés is kudarcot vallhat az átadás során .

31. A következő átadás a feladat kiosztásától a befejezés igazolásáig tart.

32. Előfordulhat, hogy egy rendszeroperátor jelentést tesz arról, hogy egy javítócsomagot telepítettek, míg egy külön ellenőrzés megállapítja, hogy a futó alkalmazás valóban a kijavított verziót használja-e, és hogy a sebezhető komponens egy figyelmen kívül hagyott példánya továbbra is használatban van-e .

33. Ezek a lépések eltérhetnek egymástól, ha egy komponenst kihagytak, vagy egy változtatást visszavontak.

34. Az Equifax-ügy nem bizonyítja, hogy egy adott kiegészítő ellenőrzés biztosan megakadályozta volna a behatolást .

35. Azonban jól mutatja, miért tekintette az FTC a nyomon követés hiányát többnek, mint puszta adminisztratív hibának .

36. A sebezhető alkalmazás a határidő lejárta után is hosszú ideig elérhető maradt.

37. Kívülről nézve a támadóknak olyan lehetőségeik voltak, amelyeket a belső e-mailnek el kellett volna távolítania .

38. Ez nem jelenti azt, hogy a támadók döntése a sebezhetőség kihasználásáról egyenértékű lenne a vállalat azon kötelezettségével, hogy megvédje a birtokában lévő adatokat, mivel a két szereplő különböző döntéseket irányított, és különböző okokból hozta meg azokat.

39. A behatolás külső személyek által elkövetett szándékos cselekmény volt; a javítás, az észlelés és a terjedés megakadályozása a szervezeten belül egymástól elkülönülő feladatok voltak .

40. Ezen okok elkülönítése megakadályozza, hogy a megelőzésről szóló hasznos beszámoló cserélhető bűnösségről szóló történetté váljon .

41. Emellett megakadályozza azt is, hogy a javítatlan alkalmazás önmagában magyarázza az összes későbbi veszteséget .

42. A Kormányzati Számvevőszék szerint az Equifax vizsgálata négy problémás területet azonosított: a veszélynek kitett rendszerek felkutatását, a behatolás észlelését, az adatbázisok közötti hozzáférés korlátozását és az érzékeny adatok kezelését, és mindegyik probléma a veszteség megállításának vagy korlátozásának egy-egy különböző lehetőségét érintette .

43. Mindegyik a támadó útjának egy-egy különböző pontján volt fontos .

44. Az ACIS felkutatása és javítása a behatolással volt kapcsolatos.

45. A figyelemmel kísérés arra vonatkozott, hogy a behatolás után milyen gyorsan lehet felismerni a jogosulatlan tevékenységet, amikor a terjedés megakadályozása még befolyásolhatta, hogy mennyi információhoz jutottak hozzá, és hogy a vállalatnak lesz-e ideje elvágni a hálózatán keresztül vezető további utat .

46. A hozzáférés-ellenőrzés arra vonatkozott, hogy az ACIS-ben megszerzett támaszpont milyen egyéb adatbázisokhoz nyithat utat.

47. Az adatkezelés arra vonatkozott, hogy milyen értékes információk voltak jelen, és hogyan védték azokat, miután ezek a védelmi vonalak megsérültek .

48. Az FTC azt állította, hogy a támadók eljutottak a hálózat más részeibe, és a sima szövegben tárolt rendszergazdai hitelesítő adatokat használták fel további információk megszerzésére .

49. Ezek az állítólagos gyengeségek fokozták a kezdeti biztonsági rés lehetséges következményeit .

50. Ezek nem szolgáltak további magyarázatként arra, hogy miért nem sikerült a márciusi üzenetnek kijavítania a Struts-sebezhetőséget.

51. Egy kongresszusi bizottság munkatársai később kritizálták a biztonsági politika és annak az Equifax technológiai műveleteiben történő végrehajtása közötti tisztázatlan feladatkör-megosztást, amely hiányosság miatt egy központilag meghatározott szabálynak nem volt egyértelműen elszámoltatható útja a működő rendszerig.

52. Ugyanez a jelentés egy lejárt tanúsítványt hozott összefüggésbe az adatok eltávolításának korlátozott átláthatóságával .

53. Ez a megállapítás inkább az észlelésre vonatkozik, mint a Struts-on keresztül történt eredeti behatolásra.

54. A bizottság beszámolója egy visszatekintő intézményi értékelés, nem pedig bírósági ítélet a rendszeren dolgozó egyes alkalmazottak hibájáról, és nem szabad úgy értelmezni, mintha bizonyíték lenne arra, hogy minden érintett személy ugyanazokkal az információkkal vagy jogosultságokkal rendelkezett .

55. A márciusi riasztás idején az Equifax nem tudta, milyen útvonalat fog végül választani a támadó .

56. Az előre látható feladat szűkebb körű és gyakorlati jellegű volt: meg kellett állapítani, mely alkalmazások használták a sebezhető szoftvert, mindegyiket egy-egy operátorhoz kellett rendelni, és a határidő lejárta előtt ellenőrizni kellett a javítását, hogy azt a veszélynek való kitettség megszűnésének bizonyítékaként lehessen kezelni .

57. Ezek a lépések nem tették volna szükségessé a később elérhető adatbázisok pontos előrejelzését .

58. Megkövetelték volna, hogy a megválaszolatlan kérdéseket láthatóvá tegyék, amíg a rendszerhez hozzáféréssel rendelkező valaki megválaszolhatja őket.

59. Ennek a fegyelmezett eljárásnak megvan a maga költsége, mert a rendszer ellenőrzése időt igényel, és megszakíthatja az egyéb munkát .

60. De egy olyan határidő, amely lejár anélkül, hogy azonosították volna a felelős személyt, a bizonytalanság költségét azokra hárítja, akik soha nem látták a riasztást .

61. A fogyasztók számára ezt a bizonytalanságot a részvételük nélkül kényszerítették rájuk.

62. Nem vizsgálhatták meg az Equifax alkalmazásállományát, nem választhatták ki a biztonsági személyzetét, és nem tudták megmondani, hogy az ígért javítás valóban eljutott-e a vitáik kezelésére használt portálra, pedig az ő vállukra nehezedett a kiszivárgott személyes adatok terhe .

63. Az FTC 2019-es jelentése az érintett személyek számát körülbelül 147 millióra becsülte.

64. Egy korábbi GAO-jelentés legalább 145,5 millió főt említett, ami tükrözte a 2018. augusztusi jelentéskészítéskor rendelkezésre álló információkat, valamint a hozzáférhető adatok azonosítására irányuló folyamatos erőfeszítéseket.

65. Ezek a számok a személyes adatokhoz való hozzáféréssel érintettek számának változó becsléseit tükrözik, nem pedig azok számát, akik később ugyanazt a kárt szenvedték el, vagy akár ugyanolyan típusú adatvédelmi kockázatnak voltak kitéve.

66. A számok közötti eltérés nem bizonyítja egy második adatvédelmi incidens bekövetkeztét .

67. Arra utal, hogy az incidens hatóköre bizonytalannak maradhat a közvetlen behatolás feltárását követően is .

68. Ez a bizonytalanság újabb felelősséget teremt: a számadatok felülvizsgálatát a bizonyítékok javulásával, valamint a továbbra is ismeretlen tényezők közlését, mivel azok, akik döntenek arról, hogyan védjék meg magukat, az adatokat tároló intézménytől függnek a megfelelő időben történő tájékoztatás tekintetében.

69. Mégis, egyetlen későbbi számlálás sem mondhatja meg az üzemeltetőnek, melyik alkalmazást kell javítania márciusban .

70. A leghasznosabb elszámoltathatóság akkor kezdődik, amikor egy figyelmeztetés még képes megváltoztatni a rendszert .

71. Valakinek nyilvántartásba kell vennie a kockázatot, valakinek, aki hozzáféréssel rendelkezik, el kell végeznie a javítást, és valakinek másnak képesnek kell lennie arra, hogy a jegy korára hivatkozás helyett a rendszerből származó bizonyítékok alapján megkérdőjelezze azt az állítást, miszerint a munka befejeződött.

72. Egy kis szervezetben ugyanaz a személy végezheti el a lépések többségét, de minden lépéshez külön válaszra van szükség, hogy a kockázati kitettségre vonatkozó döntés ne vesszen el egy általános felelősségvállaláson belül.

73. Az első válasz arra vonatkozik, hogy a megfelelő operátor megkapta-e a figyelmeztetést .

74. A második pedig arra, hogy a sebezhető komponenst megtalálták-e, frissítették-e és ellenőrizték-e a futó rendszerben .

75. Ha egy ellenőrzés sikertelen, akkor az alkalmazás leválasztására vagy az ideiglenes kockázatvállalás elfogadására vonatkozó felhatalmazásnak kifejezettnek kell lennie, mert ellenkező esetben a késedelem végleges döntésnek tűnhet .

76. Ezek a munkával, a bizonyítékokkal és a felhatalmazással kapcsolatos döntések, nem csupán nevek egy táblázatban.

77. Az eskalációs útvonal akkor fontos, ha az operátor nem tud a határidőn belül cselekedni .

78. Lehet, hogy egy javítás megzavarná a szolgáltatást, vagy az alkalmazás dokumentációja annyira hiányos, hogy senki sem tudja azonnal megmondani, melyik verziót használja, így ideiglenes biztonsági intézkedésre van szükség, amíg az operátor kivizsgálja az ügyet .

79. Ilyen esetben a hallgatásnak nyitott állapotban kell tartania a riasztást, miközben a döntéshozó mérlegeli az elszigetelést, a kiegészítő figyelemmel kísérést vagy más ideiglenes intézkedést, és rögzíti, milyen új bizonyítékok alapján maradhatna az alkalmazás üzemelésben .

80. Ez nem jelenti azt, hogy minden figyelmeztetés leállítást indokolna.

81. A beavatkozásoknak vannak költségei, és a tisztviselőnek össze kell hasonlítania ezeket a költségeket a fennálló veszélyekkel és bizonytalanságokkal.

82. De ha egy figyelmeztetést megoldatlanul hagyunk anélkül, hogy rögzítenénk, ki fogadta el a kockázatot, a döntés a munkafolyamat véletlenjévé válik .

83. A független ellenőrzés egy második szemlélői szintet hoz létre a munkafolyamaton belül.

84. Ennek a tényleges eredményt kell ellenőriznie, beleértve a kivételeket is, ahelyett, hogy egyszerűen csak ugyanazokat a biztosítékokat gyűjtené össze, amelyeket a cselekvésre kijelölt személyektől kapott, mert egy ismételt állítás az eredeti hibát átviheti egy második jelentésbe .

85. Az egy ellenőrzésen átjutó rendellenességnek nyomon követhetőnek kell lennie egy döntésig, még akkor is, ha a döntés a javítás elhalasztása egy megadott okból, hogy a késedelemnek legyen felelőse és újbóli megfontolásának dátuma.

86. Az ellenőr mégsem helyettesítheti a rendszerüzemeltető változtatásokra vonatkozó jogosultságát.

87. Ugyanígy a vezetői aláírás önmagában sem pótolja a hiányzó leltárt, és nem bizonyítja, hogy a javított alkalmazás biztonságosan fut.

88. Az adatvédelmi incidens után egy szövetségi bíróság 2019-ben megállapodáson alapuló végzést hozott az Equifax ellen indított FTC-ügyben.

89. A végzés előírta az Equifax számára, hogy kijelöljön képzett alkalmazottakat az információbiztonsági program felügyeletére, valamint legalább évente értékelje a belső és külső kockázatokat, így egy megnevezett felügyeleti funkciót kötelezve a változó fenyegetések és védelmi intézkedések rendszeres vizsgálatára .

90. Emellett előírta a biztonsági intézkedések tesztelését és nyomon követését is.

91. Kétéves értékelési időszakokra egy független szakértőnek kellett értékelnie a programot olyan vizsgálható bizonyítékok alapján, mint a mintavétel, az interjúk és a dokumentumok áttekintése, ahelyett, hogy kizárólag a szabályzatok meglétére vonatkozó általános nyilatkozatra támaszkodott volna.

92. Az igazgatóságnak vagy egy megfelelő irányító testületnek minden évben igazolnia kellett a megfelelést, és foglalkoznia kellett a még nem kijavított vagy nyilvánosságra nem hozott lényeges hiányosságokkal, így hivatalos kapcsolatot teremtve a technikai kivételek és az intézményt irányító tisztségviselők között.

93. Ezek a követelmények összekapcsolják a működési munkát az egyes alkalmazások szintjén túli felügyelettel .

94. A kockázatértékelés azonosíthatja, mire kell figyelni; egy felelős alkalmazott koordinálhatja a teendőket; egy független értékelő pedig ellenőrizheti, hogy a nyilvántartás alátámasztja-e a bejelentett eredményt .

95. Az igazgatótanács igazolása pedig megnehezíti, hogy a tartós kivételeket elrejtse a technikai ügyek sorában .

96. A végzés jogerejű megállapodás volt, nem pedig olyan bírósági ítélet, amely minden, a 2017-es adatvédelmi incidenssel kapcsolatos vitatott állítást rendezett .

97. Az Equifax a bíróság joghatóságához szükséges tények kivételével sem elismerte, sem tagadta a panaszban szereplő állításokat .

98. A végzés nem bizonyítja azt sem, hogy minden későbbi kockázatot kiküszöbölték .

99. Értéke ebben az esetben szerkezeti jellegű: meghatározza a személyeket, az ismétlődő teszteket, a bizonyítékokat, valamint azt az útvonalat, amelyen keresztül a megoldatlan problémák eljuthatnak azokhoz, akik jogosultak erőforrásokat allokálni, amikor az alkalmazáshoz legközelebb álló csapat egyedül nem tudja azokat megoldani .

100. Ez a szerkezet kudarcot vallhat, ha a kijelölt felügyelőnek nincs hozzáférése, személyzete vagy a szükséges hatásköre ahhoz, hogy egy kérdést nyomás alá helyezzen.

101. Akkor is kudarcot vallhat, ha a független értékelés olyan rituálévá válik, amelynek során csupán a „kifényezett” jelentéseket fogadják el, miközben a mintán kívül megmagyarázatlan hiányosságok maradnak fenn.

102. A több aláírás nem jár automatikusan nagyobb ellenőrzéssel.

103. A kérdés az, hogy egy eltérő észrevétel képes-e túlélni az átadásokat addig, amíg valaki cselekvéssel vagy kifejezett kockázati döntéssel válaszol rá, és hogy a következő felülvizsgáló megérti-e, miért tartották azt a választ megfelelőnek.

104. Egy rövidebb eset azt mutatja, hogy ilyen átadások nyomás alatt láthatóvá válhatnak.

105. Miután a SolarWinds Orion szoftver megsértése nyilvánosságra került, az Egyesült Államok Kiberbiztonsági és Infrastruktúra-biztonsági Ügynöksége (CISA) 2020. december 13-án kiadta a 21-01 számú sürgősségi irányelvet.

106. Ez arra utasította a szövetségi polgári végrehajtó hatóságokat, hogy válasszák le az érintett rendszereket, és határidőn belül jelentsék azok állapotát a CISA-nak.

107. Az utasítás megnevezte a felelős hatóságot, meghatározta a teendőket, és visszajelzést kért azoktól a szervezetektől, amelyeknek azokat végre kellett hajtaniuk .

108. Egy ügynökség nem teljesíthette az utasítást pusztán azzal, hogy továbbította a figyelmeztetést az irodáin belül.

109. A támadás azonban már megtörtént, és a szoftverek leválasztása nem törölhette a behatoló korábbi hozzáférését, sem nem javíthatta ki az összes kompromittált hálózatot.

110. Az Equifax és a SolarWinds esetei különböző rendszereket, fenyegetéseket és intézményeket érintettek, így az összehasonlítás nem állapít meg rangsort az általános biztonsági szintjükről.

111. Csak azt a szűkebb szempontot mutatja meg, hogy egy utasítás akkor válik jobban ellenőrizhetővé, ha a címzetteknek jelenteniük kell, mit tettek, és mi maradt védelem nélkül.

112. Maguk a jelentések is csupán állítások .

113. Akkor válnak hasznossá, ha egy másik fél összehasonlíthatja őket egy leltárral, ellenőrizheti a kivételeket, és ragaszkodhat egy új döntéshez, ha a bizonyítékok nem egyeznek – ami előfordulhat, ha egy alkalmazás hiányzik a listáról .

114. Még egy befejezett javítás sem szünteti meg a figyelemmel kísérés szükségességét, mert a támadó behatolhatott a javítás előtt, vagy talált egy másik útvonalat .

115. Ezzel szemben egy későbbi behatolás nem bizonyítja, hogy minden korábbi biztonsági döntés gondatlan volt .

116. A felelősséget azokon a döntési pontokon kell értékelni, ahol ismeretek és hatáskör állt rendelkezésre, nem pedig visszamenőlegesen a végső veszteség mértékéből kiindulva.

117. Március 9-én az Equifax-riasztás elindított egy láncreakciót, amelynek minden érintett rendszer esetében igazolt állapottal vagy a megoldatlan esetekről szóló, rögzített döntéssel kellett volna végződnie.

118. Az ACIS esetében a figyelmeztetés átkerült egy terjesztési listán, de a sebezhető alkalmazás továbbra sem került be a megerősített javítások körébe .

119. Ez a hiányosság túlélte a határidőt, egy széles körű levelezést és egy szkennelési kísérletet is.

120. A befejezetlen riasztás nem az a üzenet volt, amely még mindig a beérkező levelek között hevert; hanem a hiányzó válasz volt arról a gépről, amely továbbra is működött.

1. Am 9. März 2017 erreichte eine Warnung vor einer kritischen Sicherheitslücke in Apache Struts das Sicherheitsteam von Equifax.

2. Das Team leitete sie an mehr als 400 Mitarbeiter weiter .

3. Die Verantwortlichen für die betroffene Software wurden angewiesen, den verfügbaren Patch innerhalb von 48 Stunden zu installieren – eine Frist, die präzise klang, obwohl das Unternehmen nicht zuverlässig alle Stellen identifiziert hatte, an denen die Software lief.

4. Die E-Mail konnte schneller verbreitet werden, als eine Bestandsaufnahme korrigiert werden konnte .

5. Vier Monate später war eine Anwendung für Verbraucherstreitigkeiten namens ACIS immer noch anfällig.

6. Nach Angaben der Federal Trade Commission entdeckte Equifax die Lücke erst, nachdem seine Sicherheitsmitarbeiter Ende Juli verdächtigen Datenverkehr bei dieser Anwendung bemerkt hatten – zu diesem Zeitpunkt ging es nicht mehr darum, ob die Software möglicherweise gefährdet war, sondern wie weit das Eindringen bereits fortgeschritten war.

7. Zu diesem Zeitpunkt hatten Angreifer die Lücke bereits ausgenutzt, um an personenbezogene Daten zu gelangen .

8. Die Öffentlichkeit erfuhr am 7. September von dem Datenleck .

9. Die Anweisung vom März war echt, doch ihre Übermittlung war kein Beweis dafür, dass die notwendigen Arbeiten an jedem gefährdeten System abgeschlossen worden waren – insbesondere dort, wo das Unternehmen eine anfällige Komponente nicht zuverlässig einer Person zuordnen konnte, die zur Reparatur befugt war.

10. Dieser Unterschied ist die schmale Lücke, durch die Verantwortung verschwinden kann .

11. Eine Warnmeldung benennt eine Gefahr; ein Patch verändert einen Rechner.

12. Dazwischen stehen Menschen, die wissen müssen, welche Systeme gefährdet sind, die Befugnis haben, diese zu ändern, und nachweisen müssen, dass die Änderung funktioniert hat – selbst wenn die Anwendung die Grenzen zwischen Sicherheitspersonal und Betriebsteams überschreitet.

13. Die Richtlinie von Equifax sah eine Frist vor, doch die FTC warf dem Unternehmen vor, nicht überprüft zu haben, ob die für anfällige Systeme verantwortlichen Mitarbeiter diese eingehalten hatten, sodass es keine zuverlässige Möglichkeit gab, eine reparierte Anwendung von einer solchen zu unterscheiden, deren Verantwortlicher die Meldung übersehen hatte.

14. Die Anzahl der Empfänger machte die Warnung zwar weitreichend, aber nicht unbedingt vollständig.

15. Die FTC behauptete zudem, dass der für den betroffenen Teil von ACIS zuständige Mitarbeiter diese Warnung nicht erhalten habe .

16. Keine dieser Behauptungen bedeutet, dass jeder Empfänger ACIS kontrollierte oder dessen Schwachstelle erkannte.

17. Das Versenden einer Nachricht an Hunderte von Personen kann einen fehlenden Verantwortlichen verschleiern, wenn jeder Empfänger vernünftigerweise davon ausgeht, dass ein anderes Team die betreffende Anwendung wartet, und niemand für die Systeme Rechenschaft ablegen muss, die nicht geantwortet haben .

18. Ein Verantwortlicher in diesem Sinne ist nicht jemand, dem die Schuld für einen Angriff zugewiesen wird .

19. Es ist die Person oder Stelle, die befugt ist, die nächste Entscheidung über ein bestimmtes offenes Risiko zu treffen .

20. Diese Unterscheidung ist wichtig, da eine Organisation eine nicht bestätigte Zuweisung nicht sicher als abgeschlossene Behebung behandeln kann.

21. Equifax versuchte innerhalb einer Woche nach der Warnung, sein Netzwerk auf anfällige Software zu scannen.

22. Der Scan fand die exponierte ACIS-Komponente nicht .

23. Die FTC führte dieses Versäumnis auf einen unzureichend konfigurierten Scanner und das Fehlen einer genauen Bestandsaufnahme von Software und Systemen zurück – eine Kombination, die eine fehlgeschlagene Suche wie einen Beweis für Sicherheit erscheinen lassen könnte.

24. Ein Scan beantwortet nur die Frage, für die er eingerichtet wurde.

25. Liegt eine Anwendung außerhalb des Suchbereichs, sagt ein einwandfreies Ergebnis wenig über die Anwendung selbst aus, so beruhigend der Bericht für einen Manager auch erscheinen mag, der nur über die Zusammenfassung des Scans verfügt und keine Liste der ausgeschlossenen Elemente hat.

26. Ein Bestandsverzeichnis hätte dem Sicherheitsteam eine Ausgangsliste mit zu überprüfenden Stellen geliefert.

27. Außerdem hätte sie Lücken sichtbar gemacht: Eine Anwendung ohne namentlich genannten Betreuer oder ohne bestätigte Softwareversion würde als offener Punkt verbleiben, anstatt stillschweigend aus der Warteschlange zu verschwinden, wenn ein Scan keine Übereinstimmung meldet.

28. Das ist eine andere Art von Information als eine Warnmeldung zu Struts.

29. Die Warnmeldung beschreibt eine bekannte Schwachstelle in der Software; die Bestandsaufnahme verbindet diese Schwachstelle mit den eigenen Rechnern und Mitarbeitern einer Organisation.

30. Ohne diesen Zusammenhang kann selbst eine technisch korrekte Warnung bei der Übergabe versagen .

31. Die nächste Übergabe erfolgt von der Zuweisung zum Nachweis der Erledigung .

32. Ein Systembetreiber könnte melden, dass ein Patch installiert wurde, während eine separate Überprüfung feststellt, ob die laufende Anwendung tatsächlich die reparierte Version verwendet und ob eine übersehene Kopie der anfälligen Komponente weiterhin im Einsatz ist .

33. Diese Schritte können voneinander abweichen, wenn eine Komponente übersehen wurde oder eine Änderung rückgängig gemacht wurde.

34. Der Fall Equifax beweist nicht, dass eine bestimmte zusätzliche Überprüfung den Angriff mit Sicherheit verhindert hätte .

35. Er zeigt jedoch, warum die FTC das Fehlen von Folgemaßnahmen als mehr als nur einen administrativen Mangel betrachtete .

36. Die anfällige Anwendung blieb noch lange nach Ablauf der Frist erreichbar.

37. Von außen hatten Angreifer Möglichkeiten, die durch die interne E-Mail eigentlich beseitigt werden sollten .

38. Dies bedeutet jedoch nicht, dass die Entscheidung der Angreifer, die Schwachstelle auszunutzen, mit der Verpflichtung des Unternehmens zum Schutz der von ihm verwahrten Daten gleichzusetzen ist, da die beiden Akteure unterschiedliche Entscheidungen kontrollierten und unterschiedliche Gründe für deren Treffen hatten.

39. Der Einbruch war eine vorsätzliche Handlung durch Außenstehende; das Schließen von Sicherheitslücken, die Erkennung und die Eindämmung waren getrennte Aufgaben innerhalb der Organisation .

40. Die klare Unterscheidung dieser Ursachen verhindert, dass eine aussagekräftige Darstellung der Präventionsmaßnahmen zu einer Geschichte austauschbarer Schuldzuweisungen wird .

41. Sie verhindert auch, dass die nicht gepatchte Anwendung allein für jeden späteren Schaden verantwortlich gemacht wird.

42. Nach Angaben des Government Accountability Office identifizierte die Untersuchung von Equifax vier Problembereiche: das Aufspüren exponierter Systeme, die Erkennung des Eindringens, die Beschränkung des Zugriffs zwischen Datenbanken und die Verwaltung sensibler Daten, wobei jedes Problem eine andere Möglichkeit beeinflusste, den Schaden zu stoppen oder zu begrenzen.

43. Jeder dieser Punkte war an einer anderen Stelle im Angriffsverlauf des Angreifers von Bedeutung.

44. Das Aufspüren und Patchen von ACIS betraf den Zugang .

45. Die Überwachung betraf die Frage, wie schnell unbefugte Aktivitäten nach dem Eindringen erkannt werden könnten – zu einem Zeitpunkt, an dem eine Eindämmung noch Einfluss darauf haben könnte, auf wie viele Informationen zugegriffen wurde, und ob das Unternehmen Zeit hätte, einen fortgesetzten Weg durch sein Netzwerk abzuschneiden .

46. Die Zugriffskontrollen betrafen die Frage, welche anderen Datenbanken durch einen Zugang zu ACIS erschlossen werden könnten.

47. Beim Datenmanagement ging es darum, welche wertvollen Informationen vorhanden waren und wie diese geschützt wurden, sobald diese Schutzgrenzen versagten .

48. Die FTC behauptete, dass Angreifer andere Teile des Netzwerks erreichten und im Klartext gespeicherte Administrator-Zugangsdaten nutzten, um weitere Informationen zu erlangen .

49. Diese angeblichen Schwachstellen vergrößerten die möglichen Folgen des ursprünglichen Sicherheitsverstoßes .

50. Sie waren keine zusätzlichen Erklärungen dafür, warum die Mitteilung vom März die Struts-Sicherheitslücke nicht schließen konnte .

51. Mitarbeiter eines Kongressausschusses kritisierten später unklare Zuständigkeiten zwischen der Sicherheitspolitik und deren Umsetzung im technischen Betrieb von Equifax – eine Lücke, die dazu führen könnte, dass eine zentral festgelegte Regel keinen klar nachvollziehbaren Weg zu einer funktionierenden Lösung findet.

52. Derselbe Bericht brachte ein abgelaufenes Zertifikat mit einer beeinträchtigten Transparenz bei der Datenlöschung in Verbindung .

53. Diese Feststellung betrifft eher die Erkennung als die ursprüngliche Sicherheitslücke durch Struts .

54. Der Bericht des Ausschusses ist eine rückblickende institutionelle Bewertung, kein Gerichtsurteil über das Verschulden jedes einzelnen Mitarbeiters, der an dem System gearbeitet hat, und er sollte nicht als Beweis dafür verstanden werden, dass jede beteiligte Person über dieselben Informationen oder Befugnisse verfügte .

55. Zum Zeitpunkt der Warnung im März wusste Equifax nicht, welchen Weg ein Angreifer letztendlich einschlagen würde.

56. Die vorhersehbare Aufgabe war enger gefasst und praxisorientiert: festzustellen, welche Anwendungen die anfällige Software nutzten, jede davon einem Betreiber zuzuweisen und die Behebung des Problems vor Ablauf der Frist zu überprüfen, damit dies als Nachweis dafür gewertet werden konnte, dass die Gefährdung beendet war.

57. Diese Schritte hätten keine Vorhersage der genauen Datenbanken erfordert, auf die später zugegriffen wurde .

58. Sie hätten erfordert, unbeantwortete Fragen sichtbar zu halten, bis jemand mit Zugriff auf das System sie beantworten konnte.

59. Diese Vorgehensweise ist mit Kosten verbunden, da die Überprüfung eines Systems Zeit in Anspruch nimmt und andere Arbeiten unterbrechen kann.

60. Aber eine Frist, die abläuft, ohne dass ein Verantwortlicher identifiziert wurde, bürdet die Kosten der Ungewissheit denjenigen auf, die die Warnmeldung nie gesehen haben .

61. Den Verbrauchern wurde diese Unsicherheit ohne ihre Mitwirkung auferlegt.

62. Sie konnten weder das Anwendungsinventar von Equifax einsehen, noch das Sicherheitspersonal auswählen, noch feststellen, ob eine versprochene Korrektur tatsächlich das Portal erreicht hatte, über das ihre Streitfälle bearbeitet wurden – obwohl sie die Last der offengelegten personenbezogenen Daten zu tragen hatten.

63. Der Bericht der FTC aus dem Jahr 2019 bezifferte die Zahl der betroffenen Personen auf rund 147 Millionen.

64. Ein früherer GAO-Bericht ging von mindestens 145,5 Millionen aus, was die zum Zeitpunkt der Berichterstattung im August 2018 verfügbaren Informationen und die fortlaufenden Bemühungen widerspiegelte, festzustellen, auf welche Datensätze zugegriffen worden war.

65. Diese Zahlen beschreiben sich weiterentwickelnde Schätzungen darüber, auf wessen personenbezogene Daten zugegriffen wurde, und nicht die Anzahl der Personen, die denselben späteren Schaden erlitten oder gar derselben Art von Risiko ausgesetzt waren.

66. Der Unterschied zwischen diesen Zahlen ist kein Hinweis auf einen zweiten Datenverstoß .

67. Er ist vielmehr ein Hinweis darauf, dass der Umfang eines Datenverstoßes auch nach der Aufdeckung des unmittelbaren Eindringens ungewiss bleiben kann .

68. Diese Ungewissheit bringt eine weitere Verantwortung mit sich: die Zahlen anzupassen, sobald sich die Erkenntnisse verbessern, und zu kommunizieren, was noch unbekannt ist, da Menschen, die entscheiden, wie sie sich schützen sollen, auf zeitnahe Informationen seitens der Institution angewiesen sind, die die Daten verwaltet.

69. Doch keine spätere Zählung kann einem Betreiber sagen, welche Anwendung im März gepatcht werden muss .

70. Die nützlichste Rechenschaftspflicht beginnt, solange eine Warnung noch eine Änderung am System bewirken kann .

71. Jemand muss das Risiko erfassen, jemand mit Zugriffsrechten muss die Reparatur durchführen, und jemand anderes muss in der Lage sein, die Behauptung, die Arbeit sei abgeschlossen, anhand von Nachweisen aus dem System und nicht anhand des Alters des Tickets anzufechten.

72. In einer kleinen Organisation kann dieselbe Person mehr als einen Schritt ausführen, doch jeder Schritt erfordert dennoch eine eigenständige Antwort, damit eine Entscheidung über das Risiko nicht in einer allgemeinen Verantwortungserklärung untergeht.

73. Die erste Antwort betrifft die Frage, ob der richtige Betreiber die Warnung erhalten hat .

74. Die zweite ist, ob die anfällige Komponente im laufenden System lokalisiert, aktualisiert und überprüft wurde .

75. Wenn eine Überprüfung fehlschlägt, muss die Befugnis, die Anwendung abzuschalten oder ein vorübergehendes Risiko in Kauf zu nehmen, ausdrücklich gegeben sein, da eine Verzögerung andernfalls als feststehende Entscheidung getarnt werden kann .

76. Dies sind Entscheidungen über Arbeit, Nachweise und Befugnisse, nicht bloß Namen in einer Tabelle.

77. Ein Eskalationsweg ist wichtig, wenn der Betreiber nicht innerhalb der Frist handeln kann.

78. Möglicherweise würde ein Patch einen Dienst stören, oder die Anwendung ist so schlecht dokumentiert, dass niemand sofort sagen kann, welche Version sie verwendet, was eine vorübergehende Sicherheitsmaßnahme erforderlich macht, während der Betreiber Nachforschungen anstellt .

79. In einem solchen Fall sollte durch Schweigen die Warnung offen bleiben, während ein Entscheidungsträger Isolierung, zusätzliche Überwachung oder eine andere vorübergehende Maßnahme in Betracht zieht und festhält, welche neuen Erkenntnisse es ermöglichen würden, die Anwendung weiter in Betrieb zu lassen.

80. Das bedeutet nicht, dass jede Warnung eine Abschaltung rechtfertigt.

81. Eingriffe sind mit Kosten verbunden, und ein Verantwortlicher muss diese Kosten mit der Gefahr und der bestehenden Unsicherheit abwägen.

82. Eine Warnung jedoch ungelöst zu lassen, ohne zu dokumentieren, wer das Risiko akzeptiert hat, macht eine Entscheidung zu einem Zufall des Arbeitsablaufs .

83. Eine unabhängige Überprüfung schafft eine zweite Sichtlinie quer durch diesen Arbeitsablauf .

84. Sie sollte das tatsächliche Ergebnis, einschließlich Ausnahmen, überprüfen, anstatt lediglich dieselben Zusicherungen zu sammeln, die von den mit der Maßnahme beauftragten Personen stammen, da eine wiederholte Behauptung den ursprünglichen Fehler in einen zweiten Bericht übertragen kann.

85. Eine Anomalie, die eine Überprüfung übersteht, muss auf eine Entscheidung zurückverfolgbar bleiben, selbst wenn die Entscheidung darin besteht, eine Behebung aus einem angegebenen Grund aufzuschieben, damit diese Verzögerung einen Verantwortlichen und einen Termin für die erneute Überprüfung hat.

86. Der Prüfer kann dennoch nicht die Befugnis des Systembetreibers ersetzen, Änderungen vorzunehmen.

87. Ebenso wenig liefert eine Unterschrift der Geschäftsleitung allein das fehlende Inventar oder stellt sicher, dass eine gepatchte Anwendung sicher läuft.

88. Nach dem Datenleck erließ ein Bundesgericht 2019 einen vereinbarten Beschluss zur Beilegung des Verfahrens der FTC gegen Equifax .

89. Der Beschluss verpflichtete Equifax, qualifizierte Mitarbeiter zu benennen, die ein Informationssicherheitsprogramm beaufsichtigen und mindestens einmal jährlich interne und externe Risiken bewerten sollten, wodurch eine namentlich benannte Aufsichtsfunktion an eine wiederkehrende Überprüfung sich ändernder Bedrohungen und Abwehrmaßnahmen gebunden wurde .

90. Außerdem wurden Tests und Überwachungen der Sicherheitsvorkehrungen vorgeschrieben.

91. Für zweijährige Bewertungszeiträume musste ein unabhängiger Sachverständiger das Programm anhand von überprüfbaren Nachweisen bewerten, darunter Stichproben, Befragungen und die Prüfung von Unterlagen, anstatt sich lediglich auf eine allgemeine Erklärung zu stützen, dass Richtlinien existierten.

92. Der Vorstand oder ein geeignetes Leitungsgremium musste jedes Jahr die Einhaltung der Vorschriften bestätigen und wesentliche Mängel beheben, die nicht korrigiert oder offengelegt worden waren, wodurch eine formelle Verbindung zwischen technischen Ausnahmen und den für die Leitung der Institution verantwortlichen Personen hergestellt wurde .

93. Diese Anforderungen verknüpfen die operative Arbeit mit der Aufsicht über die Ebene einer einzelnen Anwendung hinaus .

94. Eine Risikobewertung kann aufzeigen, was Aufmerksamkeit erfordert; ein verantwortlicher Mitarbeiter kann Maßnahmen koordinieren; ein unabhängiger Gutachter kann prüfen, ob die Unterlagen das behauptete Ergebnis stützen .

95. Durch die Bestätigung durch den Vorstand wird es dann schwieriger, anhaltende Ausnahmen in einer technischen Warteschlange unterzutauchen .

96. Die Anordnung war eine rechtskräftige Vereinbarung, kein Gerichtsurteil, das alle strittigen Vorwürfe bezüglich des Datenlecks von 2017 klärte .

97. Equifax hat die Vorwürfe der Klage weder zugegeben noch bestritten, abgesehen von den für die Zuständigkeit des Gerichts erforderlichen Tatsachen .

98. Ein Beschluss beweist auch nicht, dass jedes spätere Risiko beseitigt wurde.

99. Sein Wert liegt hier in der Struktur: Er legt Personen, wiederkehrende Tests, Nachweise und einen Weg fest, über den ungelöste Probleme diejenigen erreichen können, die befugt sind, Ressourcen zuzuweisen, wenn das Team, das einer Anwendung am nächsten steht, diese nicht allein lösen kann.

100. Diese Struktur kann versagen, wenn dem benannten Aufseher der Zugang, das Personal oder die Befugnis fehlt, ein Problem voranzutreiben.

101. Sie kann auch versagen, wenn die unabhängige Bewertung zu einem Ritual der Abnahme aufpolierter Berichte wird, während ungeklärte Lücken außerhalb der Stichprobe verbleiben.

102. Mehr Unterschriften führen nicht automatisch zu mehr Kontrolle.

103. Die Frage ist, ob eine abweichende Bemerkung die Übergaben überstehen kann, bis jemand darauf mit einer Maßnahme oder einer expliziten Risikobewertung antwortet, und ob der nächste Prüfer nachvollziehen kann, warum diese Antwort als angemessen erachtet wurde.

104. Ein kürzerer Fall zeigt, dass solche Übergaben unter Druck sichtbar gemacht werden können.

105. Nachdem die Kompromittierung der SolarWinds-Orion-Software öffentlich geworden war, erließ die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) am 13. Dezember 2020 die Notfallanweisung 21-01 .

106. Sie wies die zivilen Bundesbehörden der Exekutive an, betroffene Systeme vom Netz zu trennen und ihren Status fristgerecht an die CISA zu melden.

107. Die Anweisung benannte eine zuständige Stelle, legte Maßnahmen fest und verlangte Rückmeldung von den Organisationen, die diese umsetzen mussten.

108. Eine Behörde konnte die Anweisung nicht erfüllen, indem sie die Warnung lediglich innerhalb ihrer Dienststellen weiterleitete.

109. Der Angriff hatte jedoch bereits stattgefunden, und das Trennen der Software konnte weder den früheren Zugriff eines Angreifers ungeschehen machen noch jedes kompromittierte Netzwerk wiederherstellen.

110. Equifax und SolarWinds betrafen unterschiedliche Systeme, Bedrohungen und Institutionen, sodass der Vergleich keine Rangfolge hinsichtlich ihrer allgemeinen Sicherheit begründet.

111. Er verdeutlicht vielmehr den enger gefassten Punkt, dass eine Anweisung an Verantwortlichkeit gewinnt, wenn ihre Empfänger berichten müssen, was sie unternommen haben und was weiterhin gefährdet ist.

112. Berichte selbst sind nach wie vor Behauptungen.

113. Sie werden dann nützlich, wenn eine andere Partei sie mit einem Bestandsverzeichnis vergleichen, Ausnahmen prüfen und auf einer neuen Entscheidung bestehen kann, wenn die Beweislage nicht übereinstimmt – was der Fall sein kann, wenn eine Anwendung in der Liste fehlt.

114. Selbst ein installierter Patch macht die Überwachung nicht überflüssig, da ein Angreifer möglicherweise bereits vor der Reparatur eingedrungen ist oder einen anderen Weg gefunden hat.

115. Umgekehrt beweist ein späterer Einbruch nicht, dass jede frühere Sicherheitsentscheidung nachlässig war.

116. Die Verantwortung muss an den Entscheidungspunkten bewertet werden, an denen Wissen und Handlungsbefugnis vorhanden waren, und darf nicht rückwirkend anhand des letztendlichen Ausmaßes des Schadens zugewiesen werden.

117. Am 9. März löste die Equifax-Warnung eine Kette aus, die mit einem verifizierten Status für jedes betroffene System oder einer dokumentierten Entscheidung über ein ungelöstes System hätte enden sollen.

118. Bei ACIS wurde die Warnung über eine Verteilerliste weitergeleitet, doch die anfällige Anwendung blieb von einer bestätigten Behebung ausgeschlossen.

119. Diese Lücke überstand eine Frist, eine breit angelegte E-Mail-Versendung und einen Scanversuch.

120. Die unvollendete Warnung war nicht die Nachricht, die noch im Posteingang lag; es war die fehlende Antwort bezüglich eines Rechners, der weiterhin lief.