Windows XP patch management

– Windows XP patch managementje pedig mindenkinek van. – Ezzel kijelentéssel válaszoltam egy kollégámnak, aki elmesélte, egyik ügyfele nagyot nevetett, amikor a 2014. áprilisi Windows XP támogatás vége szóba került. Az ügyfélnél még több ezer Windows XP üzemel, de hát mit számít, hogy áprilistól nem jönnek biztonsági frissítések és javítások, amikor eddig sem volt patch management és eddig sem raktak fel semmit?

A helyzet azonban az, hogy az ügyfél szakértője téved. Amióta a Windows XP létezik, azóta létezik hozzá patch management is. És mindenki használja. Az ellentmondás egyetlen szóval feloldható: mindenki számára rendelkezésre áll a reaktív szoftverfoltozás lehetősége. Azok számára is, akik nem építettek ki szoftverfoltozó technológiát, például WSUS-t. Azok számára is, akik eddig – eléggé el nem ítélhető módon – nem törődtek a frissítések terítésével.

Tegyük fel, hogy a jövő héten egy a Confickerhez hasonló számítógép-féreg kezd el terjedni. Mi történik ilyenkor?

• Akárcsak a Conficker esetén, a kártékony kód az operációs rendszerek sérülékenységét kihasználva elkezd terjedni.
• Vagy rögtön a terjedés pillanatától kezdve, vagy a vírus írója által meghatározott időben elkezdődik a károkozás. Ez a sérülékenység súlyától függően bármi lehet, beleértve adatok vagy a teljes rendszer törlését, jelszavak feltörését, fájlok “foglyul ejtését” stb.
• A szoftver gyártója elkészíti a sérülékenységet megszüntető szoftverfoltot – bár többnyire ez már a kártékony kód előtt elkészül és elérhető.
• Eközben az anti-malware gyártók is elkészítik a maguk szignatúra frissítését. Megindul a szignatúra frissítési mechanizmus.
• A gyártók figyelmeztető levelet küldenek az ügyfeleik számára, hogy jelentős fertőzés-veszély áll fenn, kérik a szükséges javítások terítésének haladéktalan megkezdését.
• A még nem fertőzött gépeknél az anti-malware rendszerek kezdenek védelmet biztosítani a féreg első variánsával szemben.
• A fertőzött gépekhez elkészül a vírus eltávolítási recept. Ez lehet egyszerű és nagyon összetett is. A “jól megírt” vírusok jól rejtőzködnek és védekeznek az eltávolítás ellen.
• A jelentős fertőzési hullámról beszámol a sajtó. Tipikusan először a szakmai fórumok, később a nem szakmai portálok, végül a nyomtatott sajtó is. A fertőzésről azok a szakértők is értesülnek, akiket egyébként a gyártók figyelmeztetése még nem ért el.
• Megkezdik a fertőzött gépek vírusmentesítését.
• Néhány szervezet megkezdi a sérülékenységhez kiadott szoftverfoltok terítését.
• Megjelenik a kártékony kód variánsa.
• Megfertőződnek olyan gépek, amelyek anti-malware szoftvere az első variáns ellen véd, de mások variánst még a heurisztikus módszerrel sem képes felfedezni.
• Bizonyos gépek újra megfertőződnek, mert nem kapták még meg a szoftverfoltokat.
• Az anti-malware gyártók kiadják az új szignatúrát – immár az új variáns ellen.
• Folyamatosan jelennek meg újabb és újabb variánsok és a nem foltozott gépek – a friss antimalware szoftverek ellenére – újra és újra fertőződnek.
• A szakértők megértik, hogyan szűntethető meg véglegesen a fertőzés. Megkezdődik a szoftverfolt vagy foltok tömeges telepítése. Ez történhet manuálisan vagy valamilyen automatizmus segítségével.
• A sérülékenységet hordozó gépek számra rohamosan csökken, megnehezítve ezzel a féreg terjedését.
• A sérülékenységet foltozó szoftverfrissítés annyira elterjed, hogy a fertőzött gépek száma minimálissá válik.

A fent említett szervezet is – legyen bármilyen elhanyagolt a szoftverfrissítések kezelése – követi a fenti sorrendet. A “modern” kártékony kódok többsége azért létezhet, mert sérülékenységek vannak az operációs rendszerekben vagy más szoftverekben. Azért születnek meg a kártékony kódok, mert ezek a sérülékenységek “gazdaságos módon” kihasználhatók. Ezt azért teszem idézőjelbe, mert itt a gazdaságosságról szervezett bűnözői csoportok döntenek. Tehát: kis erőfeszítéssel, gyorsan, jelentős haszonra lehet-e szert tenni, egy adott kártékony kóddal? Ha a válasz igen, a kódot elkészítik. A mi szempontunkból a lényeg: mindaddig, amíg az alapprobléma, tehát a sérülékenység fennáll, érdemes lesz újabb és újabb variánsokat elkészíteni, mert a fertőzés újra és újra kivitelezhető. Az anti-malware szoftverek sokat segíthetnek, de megakadályozni nem tudják a fertőzést. A végleges megoldás tehát a szoftverfolt terítése. A felkészületlen szervezetek ezt utólag, esetleg automatizmus nélkül végzik el, de akkor is elvégzik, mert ez nem csupán csökkenti, hanem megoldja, hogy az adott kártékony kód már ne fertőzhessen. Ezért mondtam, hogy mindenkinek van a Windows XP-re vonatkozóan patch managementje.

És mi történik, ha a kártékony kód mondjuk, 2014. augusztusában jelenik meg? A 2014 áprilisa után a felfedezett sérülékenységeket már nem fogja javítani a Microsoft. A fenti felsorolásból a Windows XP-re vonatkozóan a pirossal kiemeltek nem történnek meg, az alapproblémára nem készül javítás. Tekintettel a Windows XP magas penetrációjára, a “gazdaságosság” magas lesz, ezért egy ilyen kártékony kód megszületésének valószínűsége közel 100%. A variánsok elkészítésével pedig folyamatosan magas szinten lehet majd tartani a fertőzött gépek számát. Az az aggodalmam, hogy a támogatás meglétének jelentőségét, és annak lezárultát nagyon sokan csak túl későn fogják megérteni.

Még egyszer: Windows XP patch managementje mindenkinek van. Még.

IE9 RC

Nem biztos, hogy ez az IE9 RC-vel jött, mindenesetre most tapasztaltam először

Nem rossz, nem rossz.

Hyper-V Server 2008 R2 – biztonság, frissítések – 7 hónap mérlegen

A február végi Technetre készülök, és egy érdekes – nem mellesleg alapvető – kérdésre kell választ adnom, de legalábbis a válaszhoz támpontot nyújtanom. A kérdés pedig így hangzik: architektúrális szempontból érdemes-e általános célokra készült operációs rendszerből felépíteni a virtualizációs környezetet? Leegyszerűsítve a sokszálú vitát, ez a két egymásnak feszülő érv:

• Nem érdemes, mert a célszoftverrel szemben sem sebességgel, sem pedig a karbantartási munkák alacsony szintjével nem lehet versenyre kelni. A célszoftverek kisebb kódbázisával együtt kevesebb karbantartás, kevesebb leállás, kevesebb biztonsági probléma társul.
• Érdemes, mert a hypervisor a virtualizációs bázisnak csupán egyik eleme. Az alacsony birtoklási költséget – persze a jó minőségű kód mellett – olyan tényezők határozzák meg, mint a menedzselhetőség, az integráció más rendszerekkel, és a rendszerfelügyeleti folyamatok hatékonysága.

Itt és most, azt hiszem, nem fogunk igazságot tenni, viszont azt megtehetjük, hogy az elmúlt hét hónap tapasztalatait összegyűjtjük, legalábbis a Hyper-V Server 2008 R2 vonatkozásában. (Azért éppen hét hónap, mert 2009. július 14.-én zárult a kód, július 22-én pedig bejelentették az RTM változatot.) Amint azt korábban is írtam, a Hyper-V Server 2008 R2 egy figyelemre méltó hypervisor, számos vonzó képességgel, tulajdonsággal. Nézzük, miként alakul a “nagy lemezterületet” foglaló rendszer a frissítések szempontjából. Egy éppen csak telepített Hyper-V Server 2008 R2-re 9 frissítés töltődik le automatikusan:

Az alap adatok:

• Az összes frissítés száma: 9 db. A frissítésekből egy (KB976098) kumulatív, vagyis volt már előzménye is. Az egy augusztusi kiadás, a világban előforduló óraátállítási változások átvezetése.
• Biztonsági frissítések száma: 5 db. Az öt frissítés a teljes kódbázishoz kiadott frissítések száma.
• Sérülékenységek száma: 10 db. Egy-egy frissítés mögött több sérülékenység is lehet, vagyis a kódban előforduló tényleges biztonsági rés. Jelen esetben frissítésenként átlagosan kétrésről beszélhetünk.
• Hyper-V kódot érintő biztonsági frissítések/sérülékenységek száma: 1 db. Kizárólag a Hyper-V kódra vonatkozó frissítések száma.
• Kritikus biztonsági frissítések száma: 1 db
• Fontos biztonsági frissítések száma: 4 db
• Újraindítástt igénylő frissítések: 8 db. Ha a frissítéseket egyesével telepítik, akkor ennyi újraindításra volt szükség. Ez azonban ritka. A gyakoribb verzió, amikor havi karbantartási ciklusokat alkalmaznak.
• Karbantartást igénylő hónapok száma: 3 db. Ha a frissítéseket havi rendszerességgel várja össze és teríti egy informaikai csapat, akkor három frissítési ciklusuk lehetett: október, november és február.

Néhány számított érték:

• A biztonsági frissítések aránya az összes frissítéshez képest: 55%
• A kritkus biztonsági frissítések aránya az összes biztonsági frissítéshez képest: 20%
• A Secure Development Lifecycle folyamat bevezetése előtt keletkezett sérülékenységek aránya az összes sérülékenységhez képest: 90%. Figyelem! Itt nem a biztonsági frissítéseket, hanem a bennük lévő sérülékenységeket számoltam. Maga a mutató egy kis magyarázatot igényel. 2002-ben a Microsoft – személyesen Bill Gates – elindította a Trusthworthy Computing kezdeményezést, amely alapvető változást hozott a Microsoft fejlesztési metodológiájában. Teljes egészében 2004-től lett kötelező a Microsft minden fejlesztő részlegében, A változás első csírái a Windows XP SP2-vel és a Windows Serve r2003 SP1-el érkeztek meg, az első, ilyen elvek szerint fejlesztett operációs rendszer a Windows Vista volt. (Nem véletlen, hogy az SDL csapat annyi kimutatást készít a biztonsági frissítésekről. Valójában a munkájuk eredményét teszik közzé.) Az erőfeszítések sokrétűek voltak, de a Windows még ma is tartalmaz olyan kódot, amelyet még bőven az SDL bevezetése előtt gyártottak, és még sokkal előbb terveztek. A fenti szám azt mutatja, hogy:
  1. Az SDL-nek köszönhetően a biztonsági hibák száma drasztikusan csökkent az új kódban.
  2. Továbbra is vannak régi kódelemek, amelyek tartalmaznak biztonsági réseket.
  3. A régi kód kikopásával együt egy sokkal jobb egyesnsúlyi állapotba kerülünk majd.
  Ez a folyamat egyébként már ma is megfigyelhető. A Vista, bár  már az SDL érában tervezték, sokkal több kódot tartalmaz a megelőző Windows verziókból, mint a Windows 7, ennek “megfelelően” több is benne a sérülékenység.
• Újraindítások száma azonnali telepítést feltételezve (az egy napon megjelent frissítéseket egy lépésben telepítve): 5 db
• Újraindítások száma, havi karbantartási ciklust feltételezve: 3 db

A legjobb gyakorlat… ha ez érdekel valakit

A fenti számok akkor érvényesek, ha a hypervisorainkat úgy kezeljük, mint a közönséges gépeket, és ha a telepített konfigurációnk semmiben sem tér el a más fizikai szerverekétől. Ha azonban a biztonsági frissítések leírását alaposan elolvassuk – tudom fehér holló, de mégis – vagy esetleg követjük a gyártó javaslatát, hogyan érdemes Hyper-V gazdagépeket konfigurálni, akkor egy igen meglepő helyezet is adódhat.

Először nézzük a négy nem biztonsági hotfix leírásait. Idemásolom őket, pirossal kiemelve a fontos részeket:

A leírásokból kiviláglik, hogy ezek a frissítések Windows 7, vagy RDS környezetben hasznosak (az időátállítással kapcsolatos frissítést leszámítva.). A Windows kiszolgálók a “Server Core” telepítéssel elindultak egy egyszerűbb, modulárisabb úton – de láthatólag nem értek még a végére. A platform szempontjából lehet, hogy ezek a frissítések szükségesek, de a Hyper-V Serveren biztosan nincs különösebb hasznuk. Bőven ráér ezeknek a frissítéseknek a telepítése egy Service Pack keretében.

Ezek alapján marad 5 biztonsági frissítés. Négy közülük akkor használható csak ki, ha a szülőpartíciót távolról el lehet érni. Ha viszont valaki – követve a legjobb gyakorlatot – szegmentálja a hálózatát VLAN-okkal vagy IPSec segítségével, és csak meghatározott kiszolgálókról vagy munkaállomásokról engedélyezi a rendszerfelügyelettel kapcsolat forgalmat, akkor ezzel a lehető legkisebbre csökkentette az egyébkét létező veszélyt (lást a Security Bulletin-ok “Workaround” szekciói.)

Ezek alapján maradt egyetlen biztonsági frissítés, a KB977894-es. Ez egy Hyper-V biztonsági rés, DoS támadás indítható a következő feltételek esetén:

• A támadónak be kell jelentkeznie egy virtuális gépbe. (Vagyis: a támadás nem lehet anonim, nem lehet távolról kezdeményezni, és az adott virtuális gépen a felhasználónak “Log on locally” jogal kell rendelkeznie.)
• A bejelentkezés után le kell futtatnia egy megfelelően megkonstruált programot.

Mindebből kiviláglik, hogy VDI vagy virtualizált terminál kiszolgáló hyper-v feletti futtatása esetén használható ki a hiba. Ha nincsenek ilyen gépeink, a sérülékenység nem érint minket.

Szóval a meglepő helyzet az, hogy “csuklóból” kezelve a szükséges frissítések száma 9. Átgondolt rendszerfelépítés és jól működő frissítési folyamat megléte esetén pedig ez a szám 0 és 9 között változhat.

Hogy a 9 frissítés, három frissítési hónap, 1 kritikus biztonsági rés, összesen 10 sérülékenység stb. stb. sok-e vagy sem, és hogy ehhez képes a konkurrens termékekben mindezen számok hogyan is állnak, azt nem vizsgáltam. Ha valaki megteszi, örömmel veszem.

Soron kívüli biztonsági frissítés

A most megjelenő, soron kívüli Internet Explorer biztonsági frissítéssel kapcsolatban megnéztem, hogyan alakult az elmúlt évek során a soron kívüli frissítések száma. A táblázat forrása a Microsoft Security Intelligence Report 7. Úgy tűnik, hogy az ilyen helyzet nem túl gyakori: az elmúlt öt évben összesen ötször fordult elő.

A HUP-on többször is előjött témaként a Microsoft szoftvereiben található sérülékenységek számossága, súlyossága, no meg főleg az a tévhit, hogy a Microsoft nem reagál rá időben. Ezért aztán összegyűjtöttem, hogy milyen tanulmányok születtek az utóbbi években a “Days of Risk” témakörében. A “Days of Risk” azt az időt jelent, amikor már nyilvánosságra kerül egy sérülékenység, de még nem készült el a hibát javító szoftvercsomag,

Évekkel ezelőtt készült a Forrester tanulmánya “Forrester Research: Is Linux More Secure than Windows” címmel. Ez ma is letölthető, de meglehetősen borsos ára van. A belőle készült összefoglalót a EWeek tette közzé a “Linux vs Windows Which is More Secure”. Ezt a tanulmányt nem a Microsoft készítette, nem is sponzorálta, a Forrester neve pedig fémjelzi a leírtak komolyságát.

Jeff Jones – Microsoft Strategy Director a Microsoft Security Technology szervezetében – meglehetősen sokat foglalkozott a “Days of Risk” témakörével:

• Basic Guide to Days of Risk
• Putting Days of Risk to Practical use
• Days-of-risk in 2006 : Linux, Mac OS X, Solaris and Windows
• H1 2008 Desktop OS Vendor Report Vulnerabilities and Days of Risk
• Download: Internet Explorer and Firefox Vulnerability Analysis (2007-es adatokkal)

Ezeknek a tanulmányok az adatforrásai bárki által elérhető adatbázisok (cve.mitre.com, Secunia, nvd.nist.gov). Jeff az adatok gyűjtésével és elemzésével kapcsolatos nehézségekről is ír egyik blogjában Scrubbing the Source Data – Part 1 – NVD (National Vulnerability Database) címmel, nagyon tanulságos. Különösen az első bekezdés érdekes, idézem: “When I publish my analyses, I actively encourage folks to challenge my results, challenge my methodology, perform their own analysis and generally just keep me honest.  Sadly, while many may be willing to cast doubts on the results, few follow up with any analysis on their own.”

Végezetül  érdemes még két fontos tanulmányt felsorolni. Ezek ugyan nem tartalmaznak DoR információkat, de egyéb vonatkozásban rengeteg érdekes és meglepő adattal szolgálhatnak:

• Download Windows Vista One Year Vulnerability report
• Microsoft Security Intelligence Report 7

Sajnálom, hogy a Windows 7-ről még nincs olyan jelentés, mint a Vistáról készült 90 napos, 180 napos és egyéves korában. Remélem hamarosan elkészítik.

Windows 7 – négy hónap

Július 22.-én jelentette be a Microsoft, hogy elkészült a Windows 7. Azóta több mint négy hónap telt el. Furdalt a kíváncsiság, hogy azóta mennyi frissítést kellett telepíteni, hát megnéztem. Persze nincs emögött semmi tudományosság, de mégis, jelzésnek jó lehet. Tíz-tizenöt csomagra számítottam, de kellemes meglepetés ért. Mindössze hét frissítés került a rendszerre, ha viszont a megoszlásukat nézzük, akkor még kellemesebb a kép. Részletezve:

• KB975467 – MS09-059: Vulnerability in the Local Security Authority Subsystem Service could allow denial of service
• KB974571 – MS09-056: Vulnerabilities in CryptoAPI could allow spoofing
• KB974455 – MS09-054: Cumulative security update for Internet Explorer
• KB973525 – MS09-055: Cumulative Security Update of ActiveX Kill Bits
• KB958830 – Description of Remote Server Administration Tools for Windows 7
• KB958559 – Description of Windows Virtual PC
• KB973874 – A Compatibility View list update is available for Windows Internet Explorer 8: August 25, 2009

A hét frissítésből összesen négy biztonsági jellegű, egy a kompatibilitást javítja, kettő pedig funkcionálisan bővíti a Windows 7-et. Mindez már csak azért is érdekes, mert a biztonsági csapat háza táján nem csökken a munkakedv, októberben az eddig megjelent csomagok közül a legnagyobbat adták ki.

Ez jó. Azt hiszem, nagyon jó.

Ökölszabály vagy ökör szabály?

Biztos vagyok benne, hogy nincs kishazánkban olyan rendszergazda, aki ne tudná: ha a felhasználók a saját gépeiken “felhasználók”, akkor az csupa-csupa előnnyel jár a rendszer birtoklását illetően.  A teljesség igénye nélkül:

• A felhasználó-felhasználók nem telepíthetnek (telepítgethetnek) illetéktelen, az IT által nem ellenőrzött szoftvereket.
• Nem kapcsolhatják ki a védelmi rendszereket (antivírus, tűzfal, automatikus frissítések) – és ezt trójai vagy egyéb kártévő kódok sem tehetik meg helyettük.
• Nem írhatnak olyan helyekre, mint a “Program Files”, meg “Windows” környtárak, meghosszabbítva ezáltal az operációs rendszer stabilitását. Ez hasznos tiltás, hiszen tudvalévő, hogy egy felhasználó-felhasználó ott potyogtat el állományokat, ahol csak tud.
• Egy felhasználó nem futtathatja a regedit-et, vagy ha igen, kritikus pontokat nem írhat felül.
• Egy felhasználó-felhasználó nem tudja megakadályozni a csoportházirendek lefutását – ezáltal a rendszerfelügyelet gördülékenysége megmarad.

Végeredményben a felhasználó-felhasználó nagyságrendekkel kisebb mértékben veszélyezteti saját rendszerét, a számítógépe védett VELE SZEMBEN is, ez pedig végeredményben kevesebb hibát, kevesebb incidenst, alacsonyabb üzemeltetési költségeket és kisebb TCO-t jelent. Tiszta nyereség, mindenki látja ezt, a felhasználó pedig – aki igazából nem ért az informatikához – belátja, hogy ezek a szabályok végeredményben érte és nem ellene vannak.

A felhasználókat valódi felhasználókká tenni Windows környezetben azért nem olyan könnyű. Ha a Windowsra fejlesztők nem lennének oly megátalkodott lusták és követnék Microsoft ajánlásait, már régen kivesztek volna a rendszergazda jogosultságot igénylő alkalmazások. De sajnos korunk fejlesztője életművének nem elhanyagolható része igényli a rendszergazda jogosultságot. Mégis, rendes IT szervezet küzd az ilyen ártány szoftverek ellen: alternatívákat vásárol inkább, vagy megveszi és bevezeti a legújabb verziót, amelyet már rendesen megírtak stb. stb. A szakma pedig mindig, MINDIG elismerően nyilatkozik, ha valahol a kollégák belevágják a fejszéjüket a kemény fába: legyen a felhasználó csak felhasználó. Végül, ha sikerül a projekt, és mindenki, aki nem része az üzemeltetésnek, csak felhasználói jogokkkal rendelkezik, a közösség elismerően bólogat: igen, ez egy biztonságosabb rendszer.

Teljesen őszintén: én sem vagyok kivétel. Korábbi munkahelyemen, a MAL-ban, ahol én voltam a felelős a szerverek és munkaállomások működéséért, mindenki felhasználó volt a gépén: a tulajdonosok, a vezérigazgató, a IT igazgató és az összes felhasználó, beleértve rendszergazdákat, de még a tulajdonosok gyerekeit is.(*) Sőt! Még ebben a webnaplóban is beszámoltam a “Zéró Domain Admin” projektről, amelynek az volt a lényege, hogy szerepkör-megosztással szétosszuk a “Domain Admin” jogosultságokat és kiürítsük a csoportot. Nálunk még a rendszergazdák is felhasználók voltak, legalábbis azon igyekeztem, hogy a nem rendszerüzemeltetési feladatokhoz a saját, korlátozott, felhasználói fiókjukat vegyék igénybe.

Mindabból, amit leírtam, egyenesen következik, hogy igencsak meglepődtem, amikor a Microsofthoz kerültem, és azt találtam, hogy itt mindenki helyi rendszergazda a gépén. Éppenséggel nem bántam: egy kicsit aggódtam, mi lesz, ha én is csak felhasználó leszek a gépemen. Én tudom, hogy mikor, mit és miért kell feltenni a gépemre. Rendszergazda jogosultság mellett sem szedek össze vírusokat, és ha netán összebarmolnám a gépemet (nem szoktam), magam meg tudom javítani. Feltéve, hogy van jogom rá. Lett jogom, és ezt ma sem bánom.

De hogy is van ez? A felhasználóimnak korlátozom a jogait, de ha magamról van szó, akkor már nem is tetszik annyira ez a módszer? És még tovább: hogy van az, hogy a Microsoft, amelynél több, mint százezer ember dolgozik, amely a világ egyik leginkább támadásoknak kitett IT rendszerével rendelkezik, és amely cég úton útfélen azt hirdeti (karöltve a Gartnerrel), hogy a “lezárt, jól menedzselt gép az üdvözítő”; szóval ez a cég mégis megengedi, hogy a munkatársai tetszés szerint garázdálkodhassanak a gépeiken?

Bevallom, nem tettem volna fel ezeket a kérdéseket magamnak (és a webnaplónak), ha a minap nem beszélgetek hosszan egy partnerünk tapasztalt rendszermérnökével a Microsoft Optimimális Desktop ajánlatáról. A beszélgetés során kiderült, hogy náluk is éppen “racionalizálják” a hozzáférési jogosultságokat, és tulajdonosi támogatás mellett (“eszi, nem eszi, nem kap mást”) megindult az átállás, amelynek eredményeképp ők – a teljes rendszerintegrációs csapat, beleértve a konzulenseket meg mindenkit – “felhasználókká” válnak. Így aztán már most gondolkodnak azon, hogy milyen módszerrel jutnak majd olyan eszközhöz, amivel dolgozni is lehet…

Ahhh. Leesett a tantusz.

Az “Optimális desktop ajánlat” első lépése (többről, másról most nem is lesz szó), hogy mérd fel a felhasználóid igényeit és sorold őket ez alapján kategóriákba. Mindjárt fel is dobunk 5 általunk kitaláltat, ötletek ezek, sokak számára azonnal használatba vehetők. A történet azonban attól szép, hogy itt nincs semmi kőbe vésve. Vannak fejlesztőid és külön kategóriába sorolnád őket? Legyen úgy! A kereskedők különös állatfajta nálatok? Semmi gond, legyenek ők is egy kategória. Stb. Stb. A lényeg az, ahogy kezded: “Mérd fel a munkájukat, igényeiket.”

Szóval miért is helyi rendszergazdák a Microsoft dolgozók? Azért, mert ez legitim igényük. Nem úgy igény ez, mint ahogy az igazgató kisfia sír admin jogért, hogy játékot tehessen fel.  Hanem a felelős cselekvésé: az MS alkalmazottak informatikai értelemben képzett és felelős felhasználók. Tudnak bánni rájuk bízott jogokkal. A rendszer agilisebb, vagyis gyorsabban reagáló, ha az emberek megtehetik azt, amihez egyébként értenek. Ha senki sem lenne rendszergazda, egy ilyen szervezetben ez olyan mértékű incidens EMELKEDÉST jelentene, amelyet semmilyen támogató csapat nem tudna lekezelni. Mindenki minden esetben a helpdeskhez fordulna a telepítésekért, átkonfigurálásért, beállításokért stb. stb.

Tudják ezt az MSIT-nál is. Ezért aztán több dolgot is (jól) csinálnak:

• A kezdőket és a bíbelődni nem akarókat Standard lemezképpel támogatják. Tedd fel, minden benne van, ami az alap munkához kell (Office, antivírus, VPN csatlakozási lehetőség, RMS kliens, Bitlocker, management kliensek stb. stb.)
• A telepítéseket – akinek szüksége van rá – precíz leírásokkal támogatják.
• A saját utjukon járóktól a MÉLYSÉGI VÉDELEM módszerével kényszerítik ki azt, amit a józan ész megkíván:
• Biztonsági ellenőrzés, egészség-ellenőrzés VPN-es bejelentkezéskor (tűzfal, antivírus, hotfixek megléte stb.)
• SCCM és SCOM ügynökökkel távoli felügyelet, patch management stb. – interneten keresztül is.
• IPSEC és Domain izoláció (nem domain tag gépek nem tudnak domain tagokkal kommunikálni)
• Titkosítás mindenütt: kliens forgalomban, állományokon, leveleken, wireless hálózaton stb. stb. stb.
• Alkalmazás szintű publikálás – csak a szükséges forgalom, ellenőrizve, titkosítva (Outlook anywhere; TS WebAccess stb.)
• Totális védelem a szerver oldalon (jogosultság-ellenőrzés, szerepkör-szétválasztás, auditálás stb. stb.)

Szummázat (az enyém):

A “felhasználó legyen felhasználó” szabály egy ökölszabály. Többnyire helyes. Az informatikailag képzetlen, félművelt vagy felelőtlen (magán segíteni nem tudó) felhasználók támogatása olcsóbb, ha a “hibázás lehetőségét” csökkentjük. Okos dolog, ha a gyufát és a gyógyszert olyan helyen tároljuk a lakásban, ahol kisgyermek nem éri el.

Ugyanakkor a “felhasználó legyen felhasználó” szabály CSAK egy ökölszabály. A tényleges igények, munkamódszerek felmérése után vezethető be. Ha olyan helyen is alkalmazzuk, ahol nem kellene, kárt okozunk: jobb esetben csak megemelkedett támogatási költségeket, rosszabb esetben egy kevésbé hatékony szervezetet eredményezhet az intézkedés bevezetése. Az előbbi példával: ha a családban mozgássérült felnőtt is van, gyógyszereinek elzárása akár életveszélyt is okozhat.

A biztonságnak lehet ez segítője, de rossz esetben csak pótcselekvés: a valódi veszélyekkel szemben a valódi védelmi intézkedéseket kell hozni. Mélységi védelemre van szükség. És még valami. Részlet a “10 Immutable Laws of Security” írásból: Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

Te, olvasó, aki értesz az informatikai eszközökhöz, sőt, esetleg biztonsági szakértő vagy, mit szólsz a partnerünk biztonsági csapatának ötletéhez? Megosztod a gondolataidat, hogy a IT biztonsági csapat a legjobb döntést hozhassa?

———————–

(*) Kivéve egyet: egy egyetemet végzett, a számítógéphez profi módon értő srácról volt szó. Először persze ő is csak felhasználó volt. De mivel annyiféle dolgot csinált, és mindig tudta, hogy mit, és okos volt és felelősségteljes, végül engedtem, és kapott helyi rendszergazda jogot. Attól kezdve tizedannyit hívott. A * után részből tudható, hogy miért.

Az OCS Director és a biztonság

Ha IT biztonságról van szó, hamar előtör belőlem az irónia. Akik ismernek tudják, hogy a nagy butaságra zsigerből villámgyorsan óriási ökörséget improvizálok, hogy a beszélgetőpartnerem észre vegye magát. No, de ügyfélnél azért mégsem tehet ilyet az ember, marad egy enyhe mosoly. Ma délelőtt egy OCS implementáció lehetséges biztonsági kérdéseit tárgyaltuk. Elhangzott, hogy:

1. "OCS Direktorra csak akkor van szükség, ha kívülről is hozzá szeretnék férni a rendszerhez"

miközben tudjuk (ökölszabályként minden informatikus ismeri), hogy:

2. "A támadások többségét a belső, vállalati hálózatból indítják."

És íme az irónia: A támadások többségét a belső vállalati hálózatról indítják EZÉRT OCS Directorra csak akkor van szükség, ha kívülről is hozzá szeretnénk férni a rendszerhez.

Ugye milyen fura? Ugye, rögtön szúrja a szemedet a szálka? No, indexeltessük le a keresőkkel a helyes megoldást is:

"Ha a biztonság fontos a számodra, akkor OCS bevezetésnél a dedikált Direktor szerepkör elengedhetetlen, függetlenül attól, honnan kapcsolódnak a kliensek"

UAC – talán mégis hasznos

Ha egy rendszergazdának a korábbi Windows XP világban sikerült elérnie, hogy a felhasználók valóban csak felhasználók a gépeiken, akkor elsőre, és aztán sokadszorra is idegenkedik a Vista "User Access Control" funkciójától. Hiszen minek az egy olyan felhasználónak, akinek sohasem lesz rendszergazda joga? Akkor most adjunk neki? Honnan tudja majd a felhasználó, hogy egy legitim kérésről, és nem egy kártékony kódról van szó? A felhasználó DEFINÍCIÓ SZERINT ezt nem tudhatja. Bevallom rendszeradminisztrátorként mindig legyintettem erre a funkcióra. Ahol helyi admin a felhasználó, ott nem sokat ér, ahol meg nem az, ott meg használhatatlan. 

Nos, mint annyiszor, most is tévedtem. Kezdjük ott, hogy az UAC mindenütt látható a felületen méghozzá azért, mert minden adminisztrátori jogoultságot igénylő művelet mellett ott virít egy kis pajzsocska, legyen az bárhol. Az első képen látható például, hogy a vizuális effektusok állításához és a Windows által adott teljesítményindex újraszámolásához rendszergazdai jogosultságok szükségesek. Persze lehetne most azon vitatkozni, hogy miért, meg miért ilyen sok esetben szükséges, de a mondanivalóm szempontjából ez lényegtelen. Sokkal lényegesebb, hogy olyan egyszerű esetekben is, mint például egy mappa megnyitása, ha az csak a rendszergazdáknak engedélyezett, akkor feltűnik a kis ikonka. Ez már izgalmasabbá teszi a történetet, mert ilyenkor nem a párbeszédpanel bal szélén jelenik meg a pajzs (ekkor csak információ volna), hanem egy "Continue" feliratú gombon. Vagyis, vigyázz, ha folytatod, meg kell adnod a rendszergazdai hitelesítő adataidat. De figyelem! Nem hajt el a fenébe!!! Lehet folytatni a műveletet! És ez már minőségi különbség a Windows XP-hez képest. A Continue gombra ugyanis rákattinthat egy felhasználó is, legfeljebb egy rendszergazdának kell folytatnia a műveletet – például egy távsegítség (Remote Assistance) keretében.

Ettől a pillanattól kezdve valamilyen módon meg kell adni a szükséges jogosultságot, és ezt alapesetben kétféleképp végezhetjük el. Ha eredetileg sem voltunk rendszergazdák, akkor az alábbi két kép közül a bal oldali jelenik meg. Be kell ütnünk egy adminjogú felhasználónevet és jelszót. Ha eredetileg megvolt a korlátlan jogunk, csak az UAC vette el ideiglenesen, akkor a jobb oldali párbeszédpanel segítségével szabadulhatunk a kötöttségektől átmenetileg. (Ez utóbbi esetet nem tartom sokra, vagy másképp: életveszélyesnek tartom!)

Ha esetleg kényelmi szolgáltatásokkal felszerelt gép előtt ülünk (mint például az én HP Compaq nc 8430-as, ujjlenyomatolvasós masinám), akkor a kényelemről nem kell lemondanunk. A bal oldali kép kiegészül egy, vagyis esetemben kettő opcióval: smartkártyával vagy ujjlenyomattal is produkálható a rendszergazdai jog. Én ez utóbbit használom, mondhatom kellemes élmény.

A "teljes biztonságot" meg úgy értem el, hogy a jobb kezem ujjai "csak felhasználók", a balkezemé pedig a rendszergazdák :-). Gond nélkül működik. (Az itt látható képet egyébként fényképezőgéppel kellett előállítanom, mert a jogosultság bekérésekor semii sem működik, így például az AltGr-PrintScreen billentyűkombináció és a vágólap sem.)

Még egy pillanatra térjünk vissza az Internet Explorerhez. Korábban (értsd: rendszerüzemeltető koromban) úgy szereztem egy Remote Assistance munkamenetben admin jogot, hogy elindítottam egy Internet Explorer-t a RunAs funkcióval, majd a helyi meghajtókat böngészve "ruhát váltattam vele" és Windows Intézővé változtattam. Ettől kezdve a Vezérlőpult minden ikonja admi módban indult, és így bármilyen konfigurációt, amit másképp nem lehetett elvégezni, megtehettem, illetve a teljes fájlrendszerhez hozzáférhettem. Nos, erre a Vista világában már nincs szükség. Az admin jelszó bárhol megadható, még az ActiveX kontrollok telepítésekor is.

Száz szónak is egy a vége: az UAC hasznos lehet még azokban a jól menedzselt hálózatokban is, ahol a felhasználó felhasználó. Ott az "igazi" rendszergazdákat segíti.

58

58 szoftver hotfixet és egyéb firssítést bocsátott ki a Microsoft augusztus 8.-án. Még ha nem számolom a különböző platformokat (x64, Itanium), akkor is 30 körüli a csomagok száma. A csomagok 12 biztonsági réshez kapcsolódnak, amelyből 9 kritikus, 3 fontos besorolású – vagyis a telepítésüket a lehető leghamarabb el kell végezni. A Microsoft szerint alapvető, hogy a csomagokat teszteljük a kiadás előtt. Na de kérem: ki és mikor? Egy csomag tesztelése, ha az normális, leírt, dokumentált teszt, akkor a legeslegjobb esetben sem kevesebb, mint 4-5 óra, tehát naponta max. 2-vel lehet végezni, és akkor ezt a munkát már nem biztos, hogy egy ember végzi. Mérnöki szempontból tisszességes megoldás két szakember kb. 15 munkanapja. Három munkahét. A kérdés: mekkora IT szakembergárda esetén engedhető meg ilyen dedikált feladat? Továbbá: mekkora IT rendszer esetén éri meg (engedheti meg magának) a szervezet, hogy ezzel foglalkozzon? Íme egy példa, amely akkumulálja az IT szervezetek növekedését – vagy beolvadását más, nagyobb IT szervezetekbe. Lásd IT outsource.

Persze az élet hozza a megoldást: a tesztelés elmarad, a lyukakat befoltozzuk, a biztonság fontosabb, mint a change management, és bízunk abban, hogy a Microsoft jól tesztelt, helyettünk is. Nota bene: eddig alig hallottam még olyan hírt, ami arról szólt volna, hogy a Microsoft egyik hibajavító hotfixe egy újabbat generált volna, netalán kiesést okozott volna.

De az örödög nem alszik. A tesztelésen megspórolt pénz is idő csak látszólagosan megspórolt: "üzemeltetési kockázat" címszó alatt növeli a (rejtett) költségeinket.

 

Ps.: Jut eszembe: ez nem platformfüggő. Bármely szoftverre igaz.

Az év biztonsági rése

Remélem nem lesz túl zsurnaliszta szagú ez a bejegyzés, de eléggé elképedtem ezen az Exchange javítócsomagon:

Microsoft Security Bulletin MS06-019 Vulnerability in Microsoft Exchange Could Allow Remote Code Execution (916803)

 

Ilyen durva Exchange hibát még nem láttam. Csak néhány aprósági a leírásból:

 

"There are no known mitigating factors."
What might an attacker use the vulnerability to do? An attacker who successfully exploited this vulnerability could take complete control of the affected system.
Could the vulnerability be exploited over the Internet? Yes. An attacker could try to exploit this vulnerability over the Internet.

Rakhatom fel este mindegyik szerveremre.