Als beveiligingsspecialist krijg ik vaak vragen van bedrijven omtrent softwaremanagement. Het is een haast ondoenlijke taak om goed softwaremanagement in te voeren en te handhaven. Meerdere pc’s met meerdere besturingssystemen vragen meerdere oplossingen om software goed te voorzien van de juiste updates. En men moet er dan ook nog rekening mee houden dat alles het blijft doen.
Veel software heeft afhankelijkheden naar andere software, en de kleinste patch kan een operationele omgeving al stop zetten, of leiden tot gevaarlijke situaties. Ik zal in een voorbeeld uitleggen wat dit betekent.
Bedrijf WWH ( Wij Werken Hard) heeft een omgeving met Windows XP en een terminal server omgeving voor het faciliteren van de buitendienstmedewerkers. De laatste nieuwe pc’s zijn echter allemaal voorzien van Microsoft Vista. Als voornaamste software gebruikt WWH Office 2003, Microsoft CRM, diverse tekenpakketten en Coda Financials. Verder gebruikt WWH SPSS 15 voor het bijhouden van statistieken.
In huis ontwikkelde VB programma’s worden gebruikt om machines aan te sturen, voor hun patchmanagement wordt WSUS toegepast.
Op patch-Tuesday, de dag voor alle planmatige updates van Microsoft, komt er een belangrijke update binnen voor Office 2003, en deze moet snel uitgerold worden omdat het om een ernstig beveiligingsrisico gaat. De patch word door WSUS verspreid.
Echter na het uitrollen van de patch werkt een in huis ontwikkelde applicatie niet meer samen met het CRM, en valt een machine stil in een productieproces. Vervolgens blijkt er ook in een fout in Coda Financials te zitten waardoor de administratie stil valt.
Probleem in dit scenario is dat het testen van zelfs de meest kritische patch zeer doordacht moet gebeuren. Alle software moet getest worden op werking en functionaliteit. Maar bij een kritische patch gebeurt dit niet. Het juist testen kost minimaal 2 weken doorlooptijd, en tijdens deze testen is de infrastructuur wellicht in gevaar. Vervolgens blijkt ook dat WSUS niet altijd in staat is om alle pc’s te voorzien van de juiste software. Indien op een enkele of meerdere pc’s specifieke software is geïnstalleerd door een beheerder of een gebruiker kan dit de update van de patch al verstoren. Ook in deze situatie is het netwerk in gevaar. Indien het een patch betreft die een beveiligingslek moet dichten, dan loopt men het risico dat men het netwerk en de pc’s onterecht veilig acht . De betreffende pc kan dan gebruikt worden om van buitenaf het netwerk te infiltreren met alle gevolgen van dien.
Als oplossing voor bovenstaande scenario’s is een juist en waterdicht softwaremanagement van groot belang. Echter was al geconcludeerd dat dit haast onmogelijk is. Maar er schijnt licht aan de horizon. Anderhalf jaar geleden kwam Altiris op de markt met SVS, Software Virtualization Solution. Met behulp van SVS is het heel gemakkelijk om software te packagen en als een virtuele laag op een pc te zetten. Alle virtuele lagen kunnen samenwerken, en het patchen is niet meer dan het upgraden van een laag en deze opnieuw te distribueren. Dit geeft echter ook weer een nieuwe uitdaging. Voor ieder besturingssysteem moet een virtuele laag worden onderhouden. SVS is ook niet te gebruiken in een echte multi-user omgeving zoals een terminal server of een Citrix omgeving. Dit kan worden opgelost door toepassing van DVS en DVS4SBC.
DVS en DVS4SBC zijn add-on producten voor Altiris SVS. Het grootste voordeel hiervan is dat een pakket op iedere omgeving identiek is. Of deze nou via XP, Vista of Citrix beschikbaar wordt gesteld. De applicatielagen voor DVS en DVS4BC zijn ongeacht het besturingssysteem op de andere systemen te gebruiken. Het patchen vindt plaats op een centrale referentie machine. Vervolgens wordt de aangepaste laag naar de repository gekopieerd, en word er een uitrolscript gestart. Dit kan gebeuren door middel van SMS, Tivoli, Altiris Deployment Solution, of zelfs via de Active Directory. In het opstartscript wordt de oude laag gedeactiveerd, en de nieuwe versie word geactiveerd. Er kan in dit geval dus nooit meer een oude versie draaien.
Mocht er nu iets fout gaan, dan kan vrij gemakkelijk over het netwerk via een script de nieuwe versie gedeactiveerd worden, en de oude versie geactiveerd worden. De gebruikers verliezen geen tijd meer doordat de systemen onbruikbaar zijn. Systeembeheerders hebben vervolgens de tijd om een goede analyse te maken van het probleem en dit op te lossen, zonder dat gebruikers hierop hoeven te wachten. Na het verhelpen van het probleem kan het pakket weer geactiveerd worden. En dat kost slechts enkele seconden.
Door tijdens het packagen gebruik te maken van een centrale repository en een Visual Source safe blijft alle documentatie, software, patches en packages bij elkaar. Dit ondersteunt ook meteen de standaardisatie op applicatieversies.
Beheerders blijven in control over een beheerbare en beheerSbare infrastructuur .
