Windows heeft bruikbare beveiligingsgereedschappen
De beveiliging van de machines zelf kan tegenwoordig goed centraal geregeld worden met ingebakken functionaliteit in Windows. Active directory, group policies en security templates zijn de sleutelwoorden. De kracht van dit trio wordt vaak onderschat. Als we dit trio optimaal inzetten in het kader van beveiliging, dan verschuift daardoor de rol van zware beheertools. Die bieden nog steeds functionaliteit die niet standaard in Windows zit, maar de essentiële rol die ze vroeger speelden in deze context is teruggedrongen tot een meer aanvullende rol. Om een veilige Windows-installatie te creëren moet men de machine ‘afharden’. Dit houdt in het verwijderen van ongewenste software-onderdelen, het uitschakelen of herconfigureren van onderdelen en applicaties, het eisen stellen aan user accounts, het beperken van toegang tot bestanden en het instellen van auditingfaciliteiten. Deze instellingen bepalen samen grotendeels het beveiligingsniveau van het systeem. Op veel plaatsen zijn handleidingen te vinden die onder meer vertellen welke services uitgeschakeld moeten worden en welke rechten aan bestanden en registry keys moeten worden toegekend. In een bedrijfsomgeving zijn er vaak tientallen, honderden of zelfs duizenden werkstations en/of laptops te beheren. Dat maakt het ondoenlijk om handmatig iedere pc te beveiligen, een vorm van automatisering is dan ook vereist. Een veel gebruikte manier om beveiligingsmaatregelen te implementeren is zo’n systeem eenmalig te configureren, er een image van te maken en daarmee vervolgens een aantal werkstations te klonen. Een andere manier is een beheertool in te zetten om een bepaalde configuratie naar een groot aantal machines te verspreiden. Het is echter niet voldoende dat een veilige configuratie eenmalig wordt ingericht: ook beveiliging vraagt onderhoud. Gezond verstand Gebruikers moeten hun werkzaamheden efficiënt kunnen verrichten. Dat is geen nieuws. Sommige beveiligingsmaatregelen hebben echter het neveneffect gebruikers in hun werk te belemmeren. Het vinden van de juiste balans tussen een goede veiligheid en werkbare systemen is de uitdaging waar iedere beheerorganisatie voor staat. Daarbij hoort de verantwoordelijkheid voor het beveiligingsniveau niet alleen bij de beheerders te liggen, maar ook bij het management en de gebruikers zelf. Complexiteit is de vijand van beveiliging. Hoe meer verschillende configuraties, hoe meer beheer en hoe groter de risico’s. Standaardisatie en uitgebreide, gedetailleerde en up-to-date documentatie is essentieel. Van belang is: • -duidelijkheid over welke instellingen voor wie gelden (en waarom); • -de mogelijkheid om het beveiligingsbeleid te auditen; • -inzicht te hebben/krijgen in (pogingen tot) niet toegestane handelingen; • -de mogelijkheid om instellingen snel en eenvoudig aan te passen. Beheer werkt het best wanneer gestandaardiseerd, gecentraliseerd en vergaand geautomatiseerd kan worden gewerkt. Daarnaast is een grote mate van pro-activiteit van belang om problemen te voorkomen. Een flinke dosis gezond verstand kan uiteraard eveneens geen kwaad. De uitdagingen die we hier hebben geschetst spelen zowel op management- als op praktisch uitvoerend niveau. Weinig bekend is dat de Windows-omgeving zelf een zeer bruikbare gereedschapskist biedt waarmee een aantal wensen en eisen relatief eenvoudig op te lossen zijn. Deze gereedschapskist biedt de volgende voordelen: • -Het (ICT-)management kan verifiëren dat het beveiligingsbeleid daadwerkelijk wordt uitgevoerd. • -Systeembeheerders kunnen snel en eenduidig systemen configureren volgens de laatste inzichten zonder van hun stoel te komen en zonder gebruikers te storen. • -Beheer van beveiligingsmaatregelen wordt eenvoudiger door centralisatie en generalisatie. • -Differentiatie in beveiliging kan eenvoudig geïmplementeerd worden, maatwerk voor speciale gevallen kost weinig extra. • -De actuele beveiligingsconfiguratie van werkstations en servers kan op elk moment exact in kaart worden gebracht. • -Voor dit onderdeel van het beheer hoeft geen duur gereedschap aangeschaft te worden. Dagelijkse praktijk Sleutelwoorden om tot een synthese van beveiliging en configuratiebeheer te komen zijn ‘active directory’, ‘group policies’ en ‘security templates’ (beveiligingssjablonen); strikt genomen zouden we hier van ‘profielen’ moeten spreken, maar om verwarring te voorkomen houd ik mij aan de Microsoft-terminologie. In een omgeving met Windows 2000/2003-servers zal als regel active directory worden ingezet om gebruikers te authenticeren en toegang te bieden tot diensten op het netwerk. Security templates worden gebruikt om individuele Windows-machines te configureren. Een security template bepaalt welke services op een machine draaien, welke rechten verschillende gebruikers op lokale bestanden hebben, en nog veel meer. Voor wie bekend is met de templates van Windows NT is dit geen nieuws, maar sinds Windows 2000 is er erg veel veranderd en verbeterd. Security templates kunnen via active directory automatisch toegepast worden op Windows-machines. Sterker nog, meerdere security templates kunnen gedefinieerd en naast elkaar gebruikt worden. Een voorbeeld. Er kan een ‘baseline’ security template zijn die voor iedereen geldt, daarnaast een template voor ‘standaardgebruikers’ die nog een aantal zaken afsluit, een template specifiek voor applicatie-ontwikkelaars die meer moeten kunnen, en een template specifiek voor systeembeheerders die (bijna) alles moeten kunnen, maar waarbij het auditen van handelingen veel belangrijker is. Security templates kunnen willekeurig gestapeld worden. Daardoor is het mogelijk om uit te gaan van een zeer hoge standaardbeveiliging en dan selectief enkele maatregelen uit te schakelen, of juist uit te gaan van een relatief lichte baseline waar bovenop aanvullende maatregelen worden gedefinieerd. Het is vervolgens mogelijk om per machine te bepalen wat het exacte beveiligingsniveau is als gevolg van de verschillende gestapelde templates. De ‘Security Event Log’ (het beveiligingslogboek) die op elke Windows-machine bestaat, kan gebruikt worden om in vast te leggen welke ‘events’ op het gebied van beveiliging mogelijk nadere inspectie vereisen, bijvoorbeeld een poging om een niet-geautoriseerd programma te starten. Middels security templates kan ingesteld worden welke events gelogd moeten worden. Dit heeft echter alleen zin als de logbestanden ook regelmatig (of beter: real-time) geanalyseerd worden op potentiële beveiligingsproblemen. Goed gereedschap Voor het opzetten van security templates bevat Windows standaard een add-in (module) voor de Microsoft Management Console genaamd ‘Security Configuration and Analysis’. Hiermee kunnen security templates ontwikkeld worden voor verschillende doelen en verschillende soorten systemen (bijvoorbeeld Windows 2003 Domain Controllers, Windows XP-werkstations, mailservers, webservers). Met behulp van het standaardbeheergereedschap voor active directory kunnen de security templates worden opgenomen en toegekend aan bepaalde machines. Een echte aanrader is de ‘Group Policy Management Console’ die niet standaard wordt meegeleverd, maar gratis gedownload kan worden van de Microsoft-website (zoek naar: ‘GPMC download’). Dit gereedschap integreert het beheer van security templates en administrative templates in active directory. Met administrative templates kunnen specifieke opties van standaard-Windows-toepassingen (zoals Internet Explorer, Windows firewall en Terminal Services), die deels met beveiliging te maken hebben, centraal worden ingesteld. Voor het aggregeren en analyseren van logbestanden biedt Windows zelf geen gereedschap. Daarvoor blijft vooralsnog aanvullende software noodzakelijk. Doe-het-zelvers kunnen gebruik maken van of inspiratie putten uit Microsofts scripts om logbestanden te beheren en te filteren (zoek op www.microsoft.com naar ‘TechNet Script Center’). Anderen zetten daarvoor een pakket als Mom in of implementeren een gecentraliseerde ‘syslog’-oplossing. Al met al begint het standaard-Windows-gereedschap op niveau te komen. Wat nog ontbreekt is een goede integratie van gereedschappen, de logische samenhang daartussen, en mogelijkheden om systeembeheerders meer pro-actief te laten werken. Voorkómen van (beveiligings)brandjes is immers beter dan blussen. De huidige commerciële beheertools bieden die functionaliteit slechts ten dele. Het lastige traject van beveiligingsbeleid tot en met een complete Group Policy valt buiten hun terrein. Er zijn vele Windows security templates vrij te krijgen, zoals van het NIST (Amerikaanse National Institute of Standards and Technology), of van Microsoft zelf, die ze ontwikkelt in samenwerking met NSA (de Amerikaanse National Security Agency). Deze templates zijn veelal in zoverre gedocumenteerd dat duidelijk is wat ze wel en niet toestaan. De filosofie en verklaring voor de specifieke instellingen wordt niet gegeven. Er ligt geen risicoanalyse aan ten grondslag. Wat voor de een ‘veilig’ of ‘veilig genoeg’ is, is dat voor een ander beslist niet. Daarom is het klakkeloos overnemen van een template van een gerenommeerde partij beslist geen garantie op goede beveiliging. Ook is het onzeker dat nog steeds wordt voldaan aan de functionele behoefte van de gebruikers van de organisatie na het implementeren van zo’n template. Uitgebreid testen blijft noodzakelijk. Zwakke punten Enkele zwakke punten zijn al genoemd, namelijk het verwerken van logbestanden en het ontbreken van verklaringen waarom bepaalde beveiligingsmaatregelen (bijvoorbeeld een service uitschakelen) in een bepaald template zijn genomen. Het eerste punt is op te lossen met een goede beheertool die wellicht ook de analyse van logbestanden voor zijn rekening kan nemen en zonodig alarm kan slaan. Het tweede punt, goede documentatie, is lastiger. Wie bereid is te zoeken kan op de website van Microsoft veel vinden, maar Microsoft zal niet snel schrijven dat bijvoorbeeld Universal Plug & Play beter uitgeschakeld kan worden omdat er al vele lekken in gevonden zijn. Deze informatie zal dus van derde partijen moeten komen en is met enige moeite ook te vinden. Er zijn echter meer zwakke punten waarvan we hopen dat Microsoft die snel oplost (zie kader). De problemen zijn deels consequenties van het Windows-beveiligingsmodel, deels beperkingen in de userinterface en deels tekenen van een systeem dat nog niet volwassen is. De bekende beheerpakketten kunnen deze problemen daarom niet oplossen. Het is echter zeker mogelijk om een applicatie of beheermodule te ontwikkelen die de ontbrekende integratie levert en ook meteen de genoemde zwakke punten wegwerkt. Kortom, de nieuwste versies van Windows bieden aanzienlijk betere voorzieningen dan eerdere versies om beveiliging in te regelen en centraal te beheren. Het gereedschap wordt steeds krachtiger, en de mogelijkheden om de beveiliging precies op maat te maken steeds beter. Een aantal zwakke punten is echter nog steeds evident aanwezig. Specialistische kennis op het gebied van beveiliging en bijbehorend gereedschap blijft dus noodzakelijk. Erik Frambach is senioradviseur bij M&I/Partners te Amersfoort (erik.frambach@mxi.nl).Zwakke punten beveiligingsmodel Het Microsoft beveiligingsmodel en de implementatie daarvan is niet volmaakt. In de praktijk vallen de volgende beperkingen en zwakheden op. Naast de standaarditems in security templates beveelt Microsoft aan een hele serie extra parameters op te nemen, met name als bescherming tegen denial-of-service attacks (zie www.microsoft.com/ technet/security/guidance/secmod57.mspx). De procedure om deze parameters toe te voegen is echter uitermate primitief. Het vereist een handmatige aanpassing aan de Windows-machine waarop de security template wordt beheerd. Security templates verschillen voor Windows XP, 2003 en 2000. Dat is logisch, maar wij vinden het niet logisch dat het ontwikkelen van security templates daardoor lastig wordt. Het zou ons inziens niets mogen uitmaken op welk type machine men een security template ontwikkelt. Helaas is dat wel degelijk het geval. Er is geen autonome applicatie die de beveiligingsparameters van een besturingssysteem kent en vervolgens kan bewerken tot een security template. Dit proces zou onafhankelijk moeten zijn van het besturingssysteem waarop de applicatie draait. Er is geen mogelijkheid om aan de instelling van een parameter een toelichtende notitie te koppelen, waarmee eenvoudig en automatisch complete documentatie gegenereerd zou kunnen worden. XML onder de motorkap zou hier wonderen kunnen doen. In een security template kunnen ‘environment variabelen’ worden gebruikt (bijvoorbeeld SystemRoot) waardoor een template meer generiek wordt. De userinterface biedt daar echter geen ondersteuning voor. Daarvoor moet men met een ‘plain text editor’ (bijvoorbeeld Notepad) de template handmatig bijwerken, met alle risico’s van dien. Security templates bieden geen ondersteuning voor reguliere expressies. Een voorbeeld. Het zou handig zijn als met één regel vastgelegd kan worden dat alle c:\windows\system32\*.msc bepaalde toegangsrechten krijgen. Zulke generalisaties zouden een security template veel eenvoudiger, overzichtelijker en toekomstvaster maken (denk aan service packs die nieuwe bestanden toevoegen). Microsoft levert weliswaar een commandline tool waarmee de syntaxis van een security template kan worden gecontroleerd (secedit.exe), maar dit programma schiet daarin ernstig te kort. De controle zou veel uitvoeriger moeten zijn. Een complete en exacte syntaxisbeschrijving van alle onderdelen van een security template is eveneens zeer wenselijk. Wij hebben die niet kunnen vinden. Informatie over security templates en uitgebreide voorbeelden:• -Microsoft: c:\winnt\security\templates (Windows 2000); c:\windows\security\templates (Windows XP/2003); http://www.microsoft.com.• Sans (http://www.sans.org).• NSA (http://www.nsa.gov).• NIST (http://www.nist.gov).• -Common Criteria (http://niap.nist.gov/cc-scheme/).