Frissítések és a pokol felé vezető út

Jelenleg a tökéletes vihar a frissítésektől. A látszólag végtelen operációs rendszer (OS) frissítések mellett az alkalmazások és a hardver frissítései is vannak. Mindannyian megszokták, hogy a Microsoft Windows rendszeren havonta kiadják a javításokat, és arra a pontra kerülnek, hogy minden hónapban várjuk el a javítás keddjét. De most van még több.

A biztonsági kutatók felfedezték az Intel Management Engine problémáit, amely a saját kis operációs rendszerében él az Intel processzorain belül. Ezután a kutatók komoly problémákat fedeztek fel a processzoroknak a program végrehajtásának tervezésével kapcsolatban, ami a Spectre and Meltdown feliratú biztonsági résekhez vezetett. Az Meltdown befolyásolja a processzorok gyorsítótárazásának biztonsági határait, miközben a Specter spekulatív végrehajtással foglalkozik, és az összes processzort érinti, nem csak az Inteltől. (A teljes leírásért olvassa el Tom Brant „Hogyan kell az eszközöket megvédeni az olvadástól” című részt.)

Tehát a Windows és a Linux szokásos frissítésein, valamint a MacOS ritkább frissítésén túl most látjuk az őket támogató processzorok frissítéseit is. 2017 őszén az Intel frissítéseket adott a Management Engine-nek a PC-gyártók számára, amelyek firmware-javításokat adtak ki. Ezután javítások érkeztek a firmware-hez és a processzorok mikrokódjához, hogy rögzítsék az Meltdown-ot az Intel processzorokon, és bizonyos mértékben a Specter szinte minden processzoron.

A Spectre és az Meltdown javítások szintén megjelennek az operációs rendszer szoftverében, ezért január 3-án jelent meg egy fontos Windows Update, a szokásos Patch kedd sorozatból. És természetesen még mindig volt a rendes Patch kedd.

Frissítés vagy Nem frissítés

Hirtelen sok frissítés repül körül. Csak olyan gyorsan alkalmazza őket, ahogy megjelennek? A válasz: valószínűleg nem. Az Intel már foglalkozik néhány olyan régebbi processzorral, amely a javítások felvétele után elindította az újraindítást. Jelenleg olyan jelentések vannak, hogy egyes ipari ellenőrző rendszerek hibásan működnek a javítások miatt.

Nyilvánvaló, hogy kétszer is gondolkodnia kell a javítások egyszerű alkalmazásáról, amikor azok megjelennek. De akkor is aggódnia kell a következményekért, ha nem. Hogyan döntsön?

A frissítés elutasításának következményei ismertek. Végül, egy nem páratlan biztonsági rés megnyitja a rendszereket a sok kihasználás egyikének, és ez adatvesztést és az azt követő összes rossz dolgot okoz. Vannak azonban következmények, amelyek a javítás megválasztásakor is felmerülnek. Az Intel javításaival kapcsolatos kérdések mellett, vannak olyan idők is, amikor az operációs rendszer frissítései problémákat okozhatnak. Figyelembe kell vennie ezeket.

Például előfordulhat, hogy a helyileg írt vagy egyes egyéni alkalmazások nem működnek megfelelően, miután a javítást a Windowsra telepítették. Manapság ez nagyon ritka, de fennáll a lehetőség. Ha van ilyen alkalmazás, akkor tesztelnie kell a frissítést, mielőtt alkalmazná az összes rendszerre.

A problémák valószínűbb akkor, ha a frissítés jelentős, például amikor sok számítógépes rendszert frissítettek a Windows 7-ről a Windows 10-re. Ezután annak ellenére, hogy a kereskedelmi szoftvereknek kezelniük kell az átmenetet, továbbra is fontos, hogy teszteljék a módosítás bekapcsolásával. néhány számítógép, mielőtt végigmegy.

Normál körülmények között, amikor irodai alkalmazásokat futtató irodai számítógépekkel foglalkozik, alig van indok, hogy ne hagyjuk, hogy a frissítés megtörténjen, amint az azt használó személy munkaterhelése megengedi. Kevés kockázatot jelent a frissítés, és a felhasználók kockázata annak, hogy valamit csinálnak, amit nem kellene, nagyon magas.

Különleges megfontolások a szervereknél

A kiszolgálókként használt számítógépek eltérő probléma. Ott a felhasználók kockázata valamivel alacsonyabb, de a problémákkal való frissítésből származó kockázatok magasabbak. Ezenkívül a leállások költségei is vannak, ha a szerver nélkülözhetetlen az üzleti életéhez. Ebben az esetben a frissítés alkalmazásának folyamatát gondosan meg kell fontolni.

A kiszolgálók frissítésének talán a legjobb módja az egyenként, a tartalékkal kezdve. Frissít egy tartalék kiszolgálót, és teszteli ezt. Ha biztos benne, hogy megfelelően működik, cserélje ki a szervert a frissítettre. Várjon egy darabig a régira, csak arra az esetre, ha a frissítés nem játszik jól a hálózat többi részével, majd frissítse. Attól függően, hogy hány szerveren van, ezt megteheti egyszerre, vagy automatizálhatja a javításkezelő szoftver segítségével.

A legfontosabb, hogy nem egyszerűen elhárítja a frissítéseket örökre. A 2017-ben és korábban sikerült adatsértések sokasága azért lehetséges, mert a hackerek kihasználták azokat a kihasználatlan biztonsági réseket, amelyek frissítéseket és javításokat álltak rendelkezésre hónapokig vagy évekig, de amelyeket soha nem alkalmaztak. A hírszerző közösség által kifejlesztett és a szivárgás óta rendelkezésre álló hasznosítási lehetőségek még nagyobb kockázatot jelentenek a javítás elkerülése érdekében.

Ha felosztja a döntéshozást, könnyebbé válik. Először azonnal javítsa meg azokat a rendszereket, amelyekben a javítás kockázata alacsony, és a javítás elkerülésének kockázata a legmagasabb, ideértve az irodai gépeket és a nyilvános számítógépeket. Ezután alkalmazzon javításokat és frissítéseket olyan rendszerekre, ahol engedheti meg magának rövid ideig állásidőt, például olyan kiszolgálók, amelyek offline üzemmódra válthatnak egy éjszakán keresztül.

Végül fontolja meg a javítás és cseréje megközelítést a többi rendszernél, ahol több ideje van tesztelésre, és az állásidő minimálisra csökken. Adjon ismét időt a kicserélt rendszereknek, hogy megbizonyosodjanak arról, hogy jól működnek a hálózaton.

De bármit is csinál, ne hagyja ki a kritikus javításokat. Ütemezze őket, hogy megfeleljenek az Ön igényeinek, de ne csak tegye őket félre. Nem akarod, hogy támadás miatt a következő cég legyen az első oldalak.