Informatiebeveiliging Beleid en Basisregels Universiteit Utrecht
Versie beheer Versie Datum Korte beschrijving aanpassing 1.0 01-11-2005 Eerste versie vast te stellen door CvB op 15-11-2005 Copyright 2005, Universiteit Utrecht Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm of op welke andere wijze dan ook zonder voorafgaande schriftelijke toestemming van de afdeling ICT van de Universiteit Utrecht. Universiteit Utrecht 1
Inhoudsopgave VERSIE BEHEER... 1 INHOUDSOPGAVE... 2 1 DEEL I: BELEIDSKADER INFORMATIEBEVEILIGING... 4 1.1 INLEIDING... 4 1.2 WETTELIJKE BASIS... 4 1.3 DOELSTELLING INFORMATIEBEVEILIGING... 4 1.4 DOELGROEP... 5 1.5 KADERSTELLING... 5 1.6 LEESWIJZER... 5 2 DEEL II: BASISREGELS INFORMATIEBEVEILIGING... 7 2.1 ORGANISATIE EN VERANTWOORDELIJKHEDEN... 7 2.2 CLASSIFICATIE EN BEHEER VAN BEDRIJFSMIDDELEN... 9 2.3 BEVEILIGINGSEISEN TEN AANZIEN VAN PERSONEEL STUDENTEN EN BEZOEKERS... 11 2.3.1 Beveiligingseisen bij indiensttreding medewerkers... 11 2.3.2 Informatiebeveiliging in functiebeschrijvingen medewerkers... 11 2.3.3 Beveiligingseisen studenten en bezoekers... 11 2.3.4 Gebruiksregels ICT-faciliteiten... 11 2.3.5 Opleiding van gebruikers... 11 2.3.6 Reactie op beveiligingsincidenten... 11 2.4 FYSIEKE BEVEILIGING... 12 2.4.1 Publieke ruimten... 12 2.4.2 Niet-publieke ruimten... 12 2.4.3 Beveiligde ruimten... 12 2.4.4 Beveiliging van apparatuur... 12 2.4.5 Beveiliging mobiele middelen... 12 2.4.6 Netwerkvoorzieningen en bekabeling... 12 2.4.7 Afvoeren van informatiedragers... 12 2.4.8 Overige fysieke beveiligingsmaatregelen... 13 2.5 COMMUNICATIE- EN BEDIENINGSPROCESSEN... 14 2.5.1 Procedures en verantwoordelijkheden... 14 2.5.2 Integriteit van programmatuur en gegevens... 14 2.5.3 Beveiliging informatiedragers... 14 2.5.4 Uitwisseling van informatie... 14 2.6 TOEGANGSBEVEILIGING... 15 2.6.1 Toegangsbeleid... 15 2.6.2 Beheer van toegangsrechten... 15 2.6.3 Verantwoordelijkheden van gebruikers... 15 2.6.4 Toegangsbeveiliging voor netwerken, computers en applicaties... 15 2.7 ONTWIKKELING EN ONDERHOUD VAN SYSTEMEN... 16 2.8 CONTINUÏTEITSMANAGEMENT... 16 2.9 NALEVING... 17 2.9.1 Wettelijke voorschriften en contractuele eisen... 17 2.9.2 Beveiligingsbeleid... 17 2.9.3 Technische naleving... 17 2.9.4 Incidentafhandeling:... 17 2.10 SANCTIES BIJ INBREUKEN OP HET INFORMATIEBEVEILIGINGSBELEID... 18 2.10.1 Maatregelen studenten en medewerkers... 18 2.10.2 Ingehuurd personeel en bezoekers... 18 2.10.3 Aansprakelijkheid... 18 2.11 BEWUSTWORDING... 19 3 DEEL III: ACTIVITEITENPLAN... 20 Universiteit Utrecht 2
BIJLAGE I: GEBRUIKTE DEFINITIES... 21 BIJLAGE II: BEVEILIGINGSORGANISATIE EN MANAGEMENT MODEL... 24 BIJLAGE III - HET BASIS BEVEILIGINGSMODEL:... 25 BIJLAGE IV AANSLUITVOORWAARDEN SOLISNET... 28 BIJLAGE V GEBRUIKSREGELS ICT-FACILITEITEN... 36 Universiteit Utrecht 3
1 Deel I: Beleidskader informatiebeveiliging 1.1 Inleiding De bedrijfsprocessen van de universiteit zijn in grote mate afhankelijk van de kwaliteit van de informatievoorziening. Dit geldt voor nagenoeg alle bedrijfsprocessen op zowel universitair niveau als op decentraal niveau. Onder bedrijfsprocessen worden niet alleen de processen voor bestuur en beheer verstaan, maar uitdrukkelijk ook de primaire processen, zijnde onderwijs en onderzoek. De kwaliteit van de informatievoorziening wordt voornamelijk gedefinieerd in termen van beschikbaarheid, integriteit en vertrouwelijkheid. Om de gegevens en informatiesystemen waarover de universiteit beschikt op de hiervoor genoemde gebieden te kunnen beschermen is het noodzakelijk een universitair informatiebeveiligingsbeleid te hebben. 1.2 Wettelijke basis Behalve deze interne eisen zijn er bovendien wettelijke eisen gesteld aan de beveiliging van gegevens en informatiesystemen. Voorbeelden hiervan zijn te vinden in de Wet Bescherming Persoonsgegevens, in de Wet computercriminaliteit, maar ook in het Burgerlijk Wetboek, de Telecommunicatiewet, de Auteurswet, de wet op de Jaarrekening, de Archiefwet en het Wetboek van Strafvordering. Deze regelingen bevatten in het algemeen een resultaatsverplichting tot een passend niveau van informatiebeveiliging. 1.3 Doelstelling informatiebeveiliging Informatiebeveiligingsbeleid is de leidraad voor de aansturing en coördinatie van de verschillende beveiligingsprocessen binnen de universiteit. Het uiteindelijke doel is het inrichten van een evenwichtig stelsel van beveiligingsmaatregelen, gericht op risicobeheersing. De risicobronnen waar de informatie en informatievoorziening van de universiteit aan is blootgesteld komen onder andere voort uit: de door de organisatie gewenste functionaliteit de gebruikers van de informatiesystemen de kwetsbaarheid van de ICT-infrastructuur externe oorzaken (bijv. inbraak, ongeoorloofd gebruik, vernieling) externe oorzaken (natuurgeweld maar ook technische calamiteiten zoals bijv. lekkage) In het kader van informatiebeveiliging worden maatregelen getroffen om de risico s die de hiervoor genoemde risicobronnen met zich meebrengen te beperken c.q. de vervolgschade te beperken. Niet alleen het treffen van fysieke, procedurele, organisatorische en technische beveiligingsmaatregelen is noodzakelijk, ook de controle op naleving ervan is essentieel. Dit informatiebeveiligingsbeleid is leidend voor het opstellen en uitvoeren van beveiligingsmaatregelen en dient tevens als communicatiemiddel richting alle betrokkenen. Met dit informatiebeveiligingsbeleid beoogt de universiteit te voorkomen dat: in strijd met (inter)nationale wetgeving wordt gehandeld in strijd met de aansluitvoorwaarden van de Internetprovider voor de universiteit, zijnde SURFnet, wordt gehandeld zij in verlegenheid wordt gebracht doordat informatie, onder beheer van de universiteit, in onbevoegde handen komt haar positie in gevaar komt doordat kritische strategische informatie beschikbaar komt voor onbevoegden de informatievoorziening in gevaar komt door inbreuken op de integriteit, beschikbaarheid en vertrouwelijkheid van gegevens de gebruikers last ondervinden bij het gebruik van diensten en producten door onvolkomenheden in de informatievoorziening Het universitaire informatiebeveiligingsbeleid heeft ook tot doel de bewustwording ten aanzien van informatiebeveiliging te vergroten. Universiteit Utrecht 4
1.4 Doelgroep Het universitaire beveiligingsbeleid geldt voor alle onderdelen van de universiteit, voor zowel medewerkers (ook gastmedewerkers en inhuurkrachten), studenten (ook gast- en uitwisselingstudenten) en overige bezoekers. Indien bij samenwerking met derden sprake is van uitwisseling van informatie, waarvan de universiteit eigenaar of beheerder is, dient informatiebeveiliging een onderdeel van de samenwerkingsovereenkomst te zijn en is deze niet strijdig met het universitaire informatiebeveiligingsbeleid. Het beleid is locatie onafhankelijk. Indien een medewerker of student werkzaamheden verricht op een locatie die niet tot de universiteit behoort, maar waarbij men wel met informatie of informatievoorzieningen van de universiteit werkt, dient men dit beleid te respecteren. 1.5 Kaderstelling Binnen de universiteit vindt op sterk uiteenlopende en soms tegenstrijdige manier informatieuitwisseling en informatiebeheer plaats. Enerzijds zijn er de kritische bedrijfsprocessen waarbij een hoge mate van beschikbaarheid, integriteit en vertrouwelijkheid van de informatie vereist is en om die redenen in een zo gesloten mogelijke omgeving geplaatst dienen te worden. Anderzijds zijn er onderwijs- en onderzoekprocessen die, tot op zekere hoogte, juist gebaat zijn bij een zo groot mogelijke openheid met als doel informatie te verkrijgen of informatie beschikbaar te stellen. Tegen deze achtergrond is het informatiebeveiligingsbeleid opgesteld en geldt het als het basis beveiligingsbeleid van de universiteit Utrecht. Basis beveiligingsbeleid is in dit kader het minimum beveiligingsniveau. De meest kritische bedrijfsprocessen zoals de concernadministratie, de studentenadministratie en de patiëntenadministratie van diergeneeskunde vereisen aanvullend beleid. Bij het opstellen van het universitaire informatiebeveiligingsbeleid is de internationale standaard ISO/IEC 17799:2000, zijnde de code voor informatiebeveiliging, als leidraad gebruikt. In deze standaard worden alle facetten van informatiebeveiligingsbeleid die als good practice van belang zijn, benoemd en beschreven. 1.6 Leeswijzer In dit deel (deel één) is het beleidskader van het informatiebeveiligingsbeleid van de Universiteit Utrecht vastgelegd (Code voor Informatiebeveiliging hoofdstuk 3). Deel twee bevat de basisregels voor de universitaire informatiebeveiliging en is als volgt opgebouwd: Hoofdstuk 2.1: Organisatie en verantwoordelijkheden (Code voor Informatiebeveiliging hoofdstuk 4) Hoofdstuk 2.2: Classificatie en beheer van informatie en bedrijfsmiddelen (Code voor Informatiebeveiliging hoofdstuk 5) Hoofdstuk 2.3: Beveiligingseisen ten aanzien van personeel, studenten en bezoekers (Code voor Informatiebeveiliging hoofdstuk 6) Hoofdstuk 2.4: Fysieke beveiliging (Code voor Informatiebeveiliging hoofdstuk 7) Hoofdstuk 2.5: Beheer van communicatie- en bedieningsprocessen (Code voor Informatiebeveiliging hoofdstuk 8) Hoofdstuk 2.6: Logische toegangsbeveiliging (Code voor Informatiebeveiliging hoofdstuk 9) Hoofdstuk 2.7: Ontwikkeling en onderhoud van systemen (Code voor Informatiebeveiliging hoofdstuk 10) Hoofdstuk 2.8: Continuïteitsmanagement (Code voor Informatiebeveiliging hoofdstuk 11) Hoofdstuk 2.9: Naleving (Code voor Informatiebeveiliging hoofdstuk 12). Hoofdstuk 2.10: Sancties bij inbreuken op het informatiebeveiligingsbeleid Hoofdstuk 2.11: Bewustwording Deel drie is een activiteitenplan met daarin de activiteiten die uit deel één en twee volgen. Dit deel is tevens onderdeel van de beleidsrapportage. Universiteit Utrecht 5
Tenslotte bevatten de bijlagen respectievelijk: Bijlage I - een lijst met definities Bijlage II - de beveiligingsorganisatie en managementmodel Bijlage III- het basis beveiligingsmodel Bijlage IV - de aansluitvoorwaarden SOLISnet Bijlage V de gebruiksregels ICT-faciliteiten Universiteit Utrecht 6
2 Deel II: Basisregels informatiebeveiliging 2.1 Organisatie en verantwoordelijkheden Om de kwaliteit van de informatiebeveiliging te kunnen waarborgen is het van belang dat de verantwoordelijkheden op het gebied van informatiebeveiliging binnen de gehele organisatie goed verankerd zijn. Het College van Bestuur stelt het universitaire informatiebeveiligingsbeleid vast en is (eind-) verantwoordelijk. Het College van Bestuur heeft de bevoegdheden die nodig zijn voor het uitvoeren van het beleid gedelegeerd aan de directeur ICT. Het management van faculteiten en diensten is verantwoordelijk voor de naleving van het vastgestelde informatiebeveiligingsbeleid binnen de faculteit of dienst. De universiteit heeft een Chief Information Security Officer (CISO-UU) aangesteld. Deze onderhoudt het universitaire informatiebeveiligingsbeleid en adviseert zowel het universitair als het decentraal verantwoordelijke management over beveiligingsvraagstukken. De CISO-UU is verantwoordelijk voor het opstellen en uitdragen het universitaire beleid op het gebied van informatiebeveiliging en ziet toe op de uitvoering hiervan. De CISO-UU rapporteert aan de directeur ICT, maar kan zich in uitzonderlijke gevallen rechtstreeks tot het College van Bestuur wenden. Elke faculteit en dienst heeft een functionaris die binnen het universitaire onderdeel verantwoordelijk is voor de uitvoering van het informatie beveiligingsbeleid. Deze functionaris, Local Security Contact (LSC) genaamd, is door de decaan of directeur van het universitaire onderdeel benoemd. Het behoort tot de taak van de LSC om het universitaire beleid binnen de faculteit of dienst uit te voeren en te bewaken. De LSC rapporteert aan de decaan of directeur en levert op verzoek informatie aan de CISO-UU. De CISO-UU en de LSC s overleggen minimaal twee keer per jaar met als doel het universitaire informatiebeveiligingsbeleid te toetsen aan actuele inzichten. Binnen de organisatie van het informatiebeveiligingsbeleid is het ook van belang om één centraal punt te hebben waar alle incidenten op het gebied van informatiebeveiliging aangemeld en gecoördineerd worden. Binnen de universiteit is voor deze taak het Computer Emergency Response Team UU (CERT-UU) opgericht. Bij dit team, dat 7 dagen per week voor calamiteiten bereikbaar is, dienen beveiligingsincidenten aangemeld worden. CERT-UU coördineert de afhandeling van deze incidenten en bewaakt de voortgang. CERT-UU rapporteert maandelijks aan de CISO-UU. De rapportage is eveneens beschikbaar voor de LSC s. Het managementmodel van de hiervoor geschetste organisatie is opgenomen in bijlage II. Naast de hiervoor genoemde functionarissen hebben beheerders van informatie en ICT-middelen én eindgebruikers elk hun eigen verantwoordelijkheid op het gebied van informatiebeveiliging. Ter ondersteuning van de door hen uit te voeren taken zijn hun middelen en bevoegdheden toegekend. Aan het gebruik van deze middelen en bevoegdheden is de verantwoordelijkheid verbonden voor een deugdelijk beheer. Iedere beheerder en gebruiker is daarom verantwoordelijk voor alle aspecten van beveiliging binnen de eigen invloedsfeer. Voor beheerders liggen de verantwoordelijkheden vast in beheerprocedures. Deze procedures worden door de beheereenheid vastgesteld. De CISO-UU adviseert de universitaire beheereenheden bij het opstellen van beheerprocedures. Externe dienstverleners die voor of namens de universiteit universitaire informatie beheren zijn verplicht inzicht te geven in hun beheerprocedures. Dit wordt contractueel vastgelegd. Voor alle op het netwerk aangesloten systemen gelden de aansluitvoorwaarden SOLISnet. Deze aansluitvoorwaarden worden jaarlijks vastgesteld door de directeur ICT en zijn onderdeel van het informatiebeveiligingsbeleid. De aansluitvoorwaarden zijn opgenomen in bijlage IV Universiteit Utrecht 7
De verantwoordelijkheden voor eindgebruikers zijn in universitaire de gebruiksregels ICTfaciliteiten vastgelegd. Deze gebruiksregels maken deel uit van het universitaire informatiebeveiligingsbeleid De organisatie, bedrijfsprocessen, informatievoorziening en daarmee de informatiebeveiliging zijn voortdurend aan verandering onderhevig. Het universitaire informatiebeveiligingsbeleid wordt dan ook jaarlijks op inhoud, uitvoerbaarheid en implementatiestatus beoordeeld en, indien nodig, aangepast. De CISO-UU is verantwoordelijk voor dit proces. Dit proces van controle en beheer is een continu proces, echter jaarlijks wordt expliciet een revisie uitgevoerd. Hierover wordt gerapporteerd aan het College van Bestuur. Universiteit Utrecht 8
2.2 Classificatie en beheer van bedrijfsmiddelen Aan alle processen en middelen is een eigenaar toegewezen die verantwoordelijk is voor de implementatie en handhaving van de beveiligingsmaatregelen. Deze is verantwoordelijk voor classificatie en risicoanalyse van de processen en middelen. Binnen de universiteit wordt gebruik gemaakt van een uniform systeem voor classificatie van beveiligingsniveaus voor informatiesystemen. Voor deze classificatie wordt uitgegaan van de volgende criteria: - Beschikbaarheid en tijdigheid - integriteit en volledigheid - performance en capaciteit - vertrouwelijkheid Classificatielabel Kenmerken van systemen Kritisch Informatie of een (informatie)bedrijfsmiddel wordt kritisch genoemd indien het niet functioneren ervan in termen van beschikbaarheid, tijdigheid, integriteit, enz. de voortgang van het bedrijfsproces direct bedreigd of tot grote schade leidt. Voor deze categorie is aanvullend beveiligingsbeleid verplicht. Voorbeelden hiervan zijn: Osiris, het bibliotheeksysteem, het patiëntensysteem van diergeneeskunde, belangrijke delen van het netwerk, maar dit kan ook een onderzoeksysteem van een individuele onderzoeker zijn. Belangrijk Informatie of een (informatie)bedrijfsmiddel wordt belangrijk genoemd indien het onderdeel uitmaakt van het primaire bedrijfsproces, maar het niet functioneren hiervan niet direct leidt tot grote schade of bedreiging van de voortgang ervan. Voorbeelden hiervan zijn de UU-webserver of Metis Standaard Informatie of een (informatie)bedrijfsmiddel wordt standaard genoemd indien het geen onderdeel uitmaakt van het primaire bedrijfsproces en niet functioneren ervan niet leidt tot bedreiging van, of schade aan, het primaire bedrijfsproces Voorbeelden hiervan zijn bijv. de werkstations van de individuele werknemer Alle informatie binnen de universiteit wordt geclassificeerd naar één van de vier niveaus van vertrouwelijkheid, zoals hieronder vermeld. Classificatielabel Publiek Bedrijfsvertrouwelijk Vertrouwelijk Strikt vertrouwelijk Kenmerken van informatie Alle informatie die algemeen toegankelijk is. Beveiligingsmaatregelen beperken zich tot de integriteit en beschikbaarheid van de informatie. Dit betreft de informatie die toegankelijk mag of moet zijn voor alle medewerkers van de universiteit of alle medewerkers van een faculteit of dienst. Vertrouwelijkheid is gering. Beveiligingsmaatregelen beperken zich tot de integriteit van de informatie. Dit betreft informatie die alleen toegankelijk mag zijn voor een beperkte groep gebruikers. De informatie wordt ter beschikking gesteld op basis van need to know. Schending van deze classificatie kan serieuze schade toebrengen aan de universiteit of onderdelen daarvan. Dit betreft gevoelige informatie die alleen toegankelijk mag zijn voor de direct geadresseerde. Verder verspreiding kan grote schade toebrengen aan de universiteit, onderdelen van de universiteit of personen binnen de universiteit. Universiteit Utrecht 9
De eisen en maatregelen in vervolg op de classificatie van vertrouwelijkheid van informatie is in een apart document, Informatie classificatie genaamd, vastgelegd. De diverse beveiligingsniveaus voor informatiesystemen mét bijbehorende maatregelen zijn vastgelegd in het basis beveiligingsmodel. Dit model beschrijft een verplicht minimum beveiligingsniveau voor alle onderdelen van de universiteit én voor externe partijen die voor de universiteit diensten verrichten. Het basis beveiligingsmodel is beschreven in bijlage III. Universiteit Utrecht 10
2.3 Beveiligingseisen ten aanzien van personeel studenten en bezoekers Het doel van beveiligingseisen ten aanzien van personeel is het verminderen van menselijke fouten, diefstal, fraude of misbruik van voorzieningen. 2.3.1 Beveiligingseisen bij indiensttreding medewerkers Iedere medewerker krijgt bij indiensttreding schriftelijke informatie over het geldende basis informatiebeveiligingsbeleid. 2.3.2 Informatiebeveiliging in functiebeschrijvingen medewerkers Voor zover van toepassing worden de verantwoordelijkheden op het gebied van informatiebeveiliging in functieomschrijvingen vastgelegd. Voor kritische functies waarbij de functionaris toegang tot vertrouwelijke of privacy gevoelige informatie heeft, kan het ondertekenen van een geheimhoudingsverklaring verplicht worden gesteld. Bij deze functies staat informatiebeveiliging op de agenda voor functioneringsgesprekken. 2.3.3 Beveiligingseisen studenten en bezoekers Voor de beveiligingseisen ten aanzien van studenten en bezoekers zijn de hieronder genoemde paragrafen over gebruiksregels, opleidingen en reactie op beveiligingsincidenten van toepassing. 2.3.4 Gebruiksregels ICT-faciliteiten Het universitaire informatiebeveiligingsbeleid voorziet in gebruiksregels voor ICT-faciliteiten. Deze gelden voor medewerkers, studenten en bezoekers van de universiteit. Door gebruik te maken van de ICT-middelen van de universiteit heeft de gebruiker zich verplicht tot het naleven van de gebruiksregels. De gebruiksregels worden toegevoegd als bijlage V 2.3.5 Opleiding van gebruikers Informatiebeveiliging is onderdeel van opleidingen in het gebruik van ICT-middelen. Onder opleiding wordt ook verstaan het beschikbaar stellen van brochures die informatie bevatten over het universitaire informatiebeveiligingsbeleid. 2.3.6 Reactie op beveiligingsincidenten Er is een vaste procedure voor het melden van incidenten. Eenieder die beveiligingsrisico s in het kader van dit basis informatiebeveiligingsbeleid veronderstelt of constateert is verplicht dit te aan CERT-UU te melden. Dit geldt ook voor vermeende of geconstateerde onvolkomenheden in programmatuur. Universiteit Utrecht 11
2.4 Fysieke beveiliging Doel van fysieke ICT-beveiliging is het voorkomen van ongeautoriseerde toegang, teneinde schade in gebouwen en schade of verstoring van informatie te voorkomen. 2.4.1 Publieke ruimten Toegang tot ICT-voorzieningen in publieke ruimten is aan eenieder toegestaan. De fysieke beveiliging is gericht op het voorkomen van het ongeoorloofd verwijderen van apparatuur. 2.4.2 Niet-publieke ruimten Toegang tot niet-publieke ruimten en het gebruik van de in deze ruimten aanwezige ICT-middelen is alleen toegestaan aan daartoe geautoriseerde personen. ICT-middelen in niet-publieke ruimten, zoals kantoorruimten, worden fysiek beschermd tegen ongeoorloofd gebruik. Fysieke bescherming kan zijn het afsluiten van de ruimte bij afwezigheid of een fysieke toegangscontrole (bijv. via XS-pas). De fysieke beveiliging van niet-publieke ruimten is de verantwoordelijkheid van het voor deze ruimten verantwoordelijke management. 2.4.3 Beveiligde ruimten Kritische (ICT-)voorzieningen worden in beveiligde ruimten geplaatst. Deze ruimten zijn alleen toegankelijk voor daartoe gemachtigde personen. De fysieke beveiliging van beveiligde ruimten is gericht op: - voorkoming van ongeautoriseerde toegang - registratie van geautoriseerde toegang - brandwerende maatregelen - voorkoming van schade door water, blikseminslag of ander natuurgeweld - maatregelen bij stroomuitval Reservekopieën van informatie en informatiesystemen worden in voldoende mate, eventueel met reserve apparatuur en media, in beveiligde ruimtes en op veilige afstand van het origineel bewaard ter voorkoming van verlies of beschadiging bij calamiteiten. Ook de documentatie over deze informatie en informatiesystemen wordt op een veilige plaats, op veilige afstand van de het origineel, bewaard. 2.4.4 Beveiliging van apparatuur Kritische apparatuur is in beveiligde ruimten geplaatst (zie 5.3). Voor kritische apparatuur is een onderhoudscontract afgesloten. Er zijn maatregelen genomen om te voorkomen dat de eventueel op deze middelen aanwezige vertrouwelijke (bedrijfs)informatie door misbruik, diefstal of interceptie van dataverkeer ontvreemd of verminkt kan worden. 2.4.5 Beveiliging mobiele middelen Mobiele ICT-middelen (o.a. laptops, PDA s, memory keys, mobiele telefoons) zijn beveiligd tegen ongeautoriseerde toegang. Er zijn maatregelen genomen om te voorkomen dat de eventueel op deze middelen aanwezige vertrouwelijke (bedrijfs)informatie door misbruik, diefstal of interceptie van dataverkeer ontvreemd of verminkt kan worden. 2.4.6 Netwerkvoorzieningen en bekabeling De fysieke netwerkinfrastructuur bestaande uit actieve netwerkcomponenten en bekabeling, is een universitaire voorziening en is dusdanig beveiligd, dat deze niet zondermeer toegankelijk is voor ongeautoriseerde personen. 2.4.7 Afvoeren van informatiedragers Bij verwijdering of hergebruik van apparatuur met informatiedragers (o.a. harde schijven) wordt de daarop aanwezige informatie vernietigd of overschreven. Universiteit Utrecht 12
2.4.8 Overige fysieke beveiligingsmaatregelen Behalve de hiervoor genoemde maatregelen zijn het voorkomen van ongeoorloofd meelezen van beeldschermen en het ongeoorloofd lezen van vertrouwelijke of privacy gevoelige informatie op papier elementaire fysieke beveiligingsmaatregelen. In dit kader dienen de begrippen clean desk en clean screen gehanteerd te worden. Vertrouwelijke of privacy gevoelige documenten worden onder toezicht afgedrukt en onmiddellijk verwijderd (bij printers en faxen). Universiteit Utrecht 13
2.5 Communicatie- en bedieningsprocessen Het doel van communicatie- en bedieningsprocessen is het garanderen van een correcte en veilige bediening en beheer van ICT-voorzieningen. 2.5.1 Procedures en verantwoordelijkheden Voor alle informatie en elk informatiesysteem is vastgesteld wie functioneel eigenaar is. Voor het beheer van informatie en informatiesystemen zijn verantwoordelijkheden en procedures vastgelegd. De eigenaar van de informatie en informatiedragers stelt deze vast en is verantwoordelijk voor het onderhoud ervan. De CISO-UU stelt de kaders en kan eigenaren adviseren. Om vergissingen, nalatigheid of opzettelijk misbruik zoveel mogelijk te voorkomen, wordt de grootst mogelijke vorm van functiescheiding nagestreefd. Productie-, acceptatie- en ontwikkelomgeving zijn van elkaar gescheiden Voor het aanbrengen van wijzigingen in kritische ICT-voorzieningen is een formele wijzigingsprocedure vastgesteld. 2.5.2 Integriteit van programmatuur en gegevens Om de integriteit van programmatuur en gegevens te beschermen, zijn op alle systemen maatregelen genomen tegen kwaadaardige programmatuur, zoals virussen, wormen, Trojaanse paarden e.d. Het is verplicht om beveiligingsadviezen (patches) van leveranciers altijd onmiddellijk op te volgen, tenzij uitvoering van een dergelijk advies het goed functioneren van bedrijfskritische processen belemmert. Er wordt zoveel mogelijk gebruik gemaakt van actuele versies van programmatuur die door de leverancier ondersteund wordt. Indien dit niet mogelijk is kunnen beperkingen worden opgelegd ten aanzien van de koppeling van dergelijke systemen aan het universitaire netwerk. 2.5.3 Beveiliging informatiedragers Er zijn procedures voor het beheer van informatiedragers. Overtollige informatiedragers (bijv. overjarige pc s en servers) worden op een veilige manier afgevoerd 1. De daarop aanwezige informatie wordt op een adequate manier vooraf verwijderd. Er zijn duidelijke voorschriften en procedures voor de veilige behandeling en opslag van informatie (o.a. back-up strategie). In het bijzonder dient rekening gehouden te worden met wettelijke minimale en maximale bewaartermijnen en de bepalingen rond toegankelijkheid van opgeslagen informatie. 2.5.4 Uitwisseling van informatie Uitwisseling van vertrouwelijke of privacygevoelige bedrijfsinformatie en programmatuur tussen (onderdelen van) de universiteit en andere organisaties is alleen mogelijk op basis van wettelijke voorschriften of schriftelijke overeenkomsten tussen partijen en is in overeenstemming met het informatiebeveiligingsbeleid van de universiteit. Vertrouwelijke of privacygevoelige informatie wordt ook tijdens transport beveiligd tegen misbruik, manipulatie en inzage. 1 Ter voorkoming van zaken zoals die van Tonino Universiteit Utrecht 14
2.6 Toegangsbeveiliging Het doel van toegangsbeveiliging is het beschermen van ICT-diensten en (digitale) informatiebronnen tegen ongeoorloofde toegang, wijziging, vernietiging en openbaring. 2.6.1 Toegangsbeleid Studenten en medewerkers van de universiteit krijgen alleen op basis van functionele vereisten/behoeften toegang tot niet-publiek toegankelijke ICT-diensten en (digitale) informatiebronnen van de universiteit. Voor derden is expliciet toestemming van de eigenaar vereist voor toegang tot de niet publiek toegankelijke informatiesystemen en ICT-diensten. De eigenaar van de informatie of ICT-dienst is verantwoordelijk voor het toegangsbeleid en autorisatie van de toegangsrechten. Alle daartoe geautoriseerde gebruikers beschikken over een unieke gebruikersidentificatie. Omdat het gebruik van faciliteiten altijd tot een persoon herleidt moet kunnen worden is deze gebruikersidentificatie enkel voor persoonlijk gebruik. Het gebruik van ICT-diensten en informatiebronnen is vastgelegd (logging van het gebruik) om vast te kunnen stellen of is voldaan aan het toegangsbeleid. 2.6.2 Beheer van toegangsrechten Door de eigenaar van gegevens en informatiebronnen zijn voor het registreren, muteren en afvoeren van gebruikers en autorisaties van gebruikers formele procedures vastgesteld. De CISO-UU stelt de kaders en kan eigenaren adviseren. 2.6.3 Verantwoordelijkheden van gebruikers Gebruikers worden op hun verantwoordelijkheden gewezen in het bijzonder tot het gebruik van authenticatiemiddelen. Deze verantwoordelijkheden zijn in de gebruiksregels ICT-faciliteiten vastgelegd. 2.6.4 Toegangsbeveiliging voor netwerken, computers en applicaties Voor de toegang tot netwerken, computers en applicaties zijn de eisen vastgelegd. Toegang tot deze middelen of pogingen daartoe worden gelogd en gecontroleerd. Met in achtneming van de Wet Bescherming Persoonsgegevens worden de inloggegevens van deze voorzieningen opgeslagen. De mate van vertrouwelijkheid van de informatie bepaalt de zwaarte van de toegangsbeveiliging. Voor informatie die algemeen publiekelijk beschikbaar dient te zijn, is geen toegangsbeveiliging op persoonsniveau noodzakelijk. Voor toegang tot de overige informatie is gebruikersnaam / wachtwoord de minimale eis. In sommige gevallen is zwaardere authenticatie vereist. Welke vorm van authenticatie is voorgeschreven wordt op basis van de classificatie van ICT-diensten en informatiebronnen bepaald. Uit de classificatie volgt eveneens de geldigheidsduur van de gebruikersidentificatie. Universiteit Utrecht 15
2.7 Ontwikkeling en onderhoud van systemen Bij het ontwerp, selectie of de ontwikkeling van nieuwe informatiesystemen worden de benodigde beveiligingseisen op basis van een risicoanalyse vastgesteld. Projecten en ondersteunende activiteiten dienen op een veilige manier te worden uitgevoerd. Voorbeelden hiervan zijn het gebruik van testgegevens en het gebruik van een testsysteem naast de productieomgeving. Het aanbrengen van wijzigingen wordt volgens vaste procedures op een gecontroleerde en door de eigenaar van het betreffende informatiesysteem geaccordeerde manier uitgevoerd. 2.8 Continuïteitsmanagement Voor kritische ICT-diensten en informatiesystemen is een continuïteitsplan aanwezig. In het continuïteitsplan is opgenomen hoe, in geval van calamiteiten, de getroffen ICT-dienst of het getroffen informatiesysteem weer zo snel mogelijk operationeel gemaakt kan worden. Een continuïteitsplan kan variëren van een goede back-upvoorziening of het geografisch spreiden van de ICT-dienst tot een complete uitwijk. Continuïteitsplannen worden minimaal één keer per jaar op actualiteit geëvalueerd en regelmatig getest. Universiteit Utrecht 16
2.9 Naleving Het voorschrijven van maatregelen is alleen zinvol indien deze ook gecontroleerd en gehandhaafd kunnen worden. 2.9.1 Wettelijke voorschriften en contractuele eisen Het ontwerp, de bediening, het gebruik en beheer van ICT-diensten en informatiesystemen voldoet aan de wettelijke en contractuele vereisten. 2.9.2 Beveiligingsbeleid Het management zorgt ervoor dat alle maatregelen en normen die uit het informatiebeveiligingsbeleid voortvloeien worden nageleefd en uitgevoerd. Afhankelijk van het belang van het te beveiligen proces of middel definieert de CISO-UU controle maatregelen. Voor de vitale bedrijfsprocessen kan een uitgebreide EDP-audit worden uitgevoerd. 2.9.3 Technische naleving Het basis beveiligingsbeleid van de universiteit voorziet in een zogenaamde security scan. Met een dergelijke scan worden de beveiligingslekken in ICT-middelen geïnventariseerd. De security scan wordt regelmatig uitgevoerd op alle systemen die op SOLISnet zijn aangesloten. De scan controleert de aangesloten systemen op de meest voorkomende gebreken in de beveiliging. De uitkomsten van deze scans worden aan de LSC van het verantwoordelijke onderdeel overhandigd. Deze is ervoor verantwoordelijk dat de geconstateerde gebreken worden opgelost. Het niet verhelpen van geconstateerde gebreken kan afsluiting van SOLISnet tot gevolg hebben. Behalve dat hiermee het beveiligingsniveau van ICT-middelen inzichtelijk wordt gemaakt, verhoogt dit ook de bewustwording. Het universitaire netwerk wordt continue gemeten om te beoordelen of de capaciteit nog voldoende is. Bij vermeend misbruik kunnen deze metingen worden geïntensiveerd en kan, om de oorsprong te achterhalen, naar de inhoud van de getransporteerde datapakketten gekeken worden. Deze werkwijze is vastgelegd in de aansluitvoorwaarden voor SOLISnet 2.9.4 Incidentafhandeling: Bij de organisatie van de informatiebeveiliging in hoofdstuk 2.1 is vastgesteld dat CERT-UU het centrale punt is waar alle incidenten op het gebied van informatiebeveiliging aangemeld en gecoördineerd worden. In dit kader wordt onder incidenten verstaan: - beveiligingsincidenten waarbij medewerkers, studenten of ICT-middelen van de universiteit betrokken zijn (als slachtoffer of als veroorzaker) - diefstal of vernieling van ICT-middelen CERT-UU opereert in opdracht van de CISO-UU en is het meldpunt voor de hiervoor genoemde incidenten en heeft slechts een coördinerende en adviserende rol bij de oplossing ervan. Incidenten kunnen door zowel interne als externe gedupeerden aangemeld worden. De gedupeerde faculteit of dienst kan besluiten aangifte te doen van de hierboven genoemde incidenten, maar is hier zelf verantwoordelijk voor. Bij diefstal of vernieling wordt ook de bedrijfsbeveiliging (FBU-security) ingelicht. CERT-UU kan in voorkomende gevallen, in overleg met de CISO-UU of de directeur ICT, zonodig systemen of zelfs delen van het netwerk af laten sluiten van de rest van het universitaire netwerk of Internet. In die gevallen waarbij de CISO-UU of de directeur ICT niet bereikbaar zijn, en de ernst van een incident afsluiting noodzakelijk maken, is CERT-UU gerechtigd om zelfstandig systemen of delen van het netwerk af te sluiten. De verantwoordelijke systeembeheerder wordt, zo mogelijk vooraf, maar in ieder geval achteraf hiervan op de hoogte gesteld. CERT-UU rapporteert maandelijks aan de CISO-UU. Universiteit Utrecht 17
2.10 Sancties bij inbreuken op het informatiebeveiligingsbeleid Bij inbreuk op het inforrnatiebeveiligingsbeleid kunnen door of namens het College van Bestuur maatregelen worden getroffen. 2.10.1 Maatregelen studenten en medewerkers Aan studenten of medewerkers die zich niet houden aan de regels die voortvloeien uit dit informatiebeveiligingsbeleid en die vastgelegd zijn in de gebruiksregels ICT-faciliteiten, kunnen door of namens het College van Bestuur disciplinaire maatregelen worden opgelegd. 2.10.2 Ingehuurd personeel en bezoekers Ingehuurd personeel en bezoekers die zich niet houden aan de regels die voortvloeien uit het informatiebeveiligingsbeleid kan toegang tot universitaire middelen ontzegd worden. 2.10.3 Aansprakelijkheid Indien de universiteit wordt aangesproken op de overtreding van eigendomsrechten, auteursrechten of overtreding van andere wettelijke bepalingen, zijn de wettelijke en universitaire aansprakelijkheidsregelingen van toepassing. Indien de universiteit schade ondervindt door nalatigheid bij het gebruik of het opzettelijke misbruik van ICT-voorzieningen worden de wettelijke en universitaire aansprakelijkheidsregelingen op de veroorzaker toegepast. Universiteit Utrecht 18
2.11 Bewustwording Veel gebruikers en beheerders van informatie zijn zich niet bewust van de risico s die men in het kader van informatiebeveiliging loopt of zijn zich niet voldoende bewust van de verantwoordelijkheid die zij dragen ten opzichte van de informatie waar zij toegang toe hebben. Helaas is dit een vruchtbare voedingsbodem voor incidenten. Onderzoek geeft aan dat de meerderheid van beveiligingsincidenten zijn oorsprong vindt binnen de eigen organisatie. Daarom is bewustwording of liever bewustmaking een belangrijk instrument bij informatiebeveiliging en wordt als een apart proces gedefinieerd. De CISO-UU is verantwoordelijk voor het bewustwordingsproces en ontwikkelt jaarlijks een campagne hiervoor. Universiteit Utrecht 19
3 Deel III: Activiteitenplan Inventarisatie en checklist voor werkzaamheden voortvloeiend uit het informatiebeveiligingsbeleid en de bijbehorende basisregels Het activiteitenplan bevat elementen die een vertrouwelijk kenmerk hebben. Om die reden wordt deel III niet gepubliceerd. Voor vragen over het activiteitenplan kunt u zich per E-mail wenden tot de Corporate Information Security Officer. Zijn E-mail adres is ciso@uu.nl Universiteit Utrecht 20
Bijlage I: Gebruikte definities Attachment Authenticatie Autorisatie Autorisator Beheerder Beschikbaarheid Betrouwbaarheid Beveiligingsincident Beveiligingsniveau Calamiteitenplan CERT-UU CISO-UU Controleerbaarheid Detectieve maatregel Disclaimer Eigenaar Encryptie Bijlage. Letterlijk: toevoeging. Een attachment is een bestand dat wordt gekoppeld aan een mail-bericht. Dit attachment wordt meegezonden met het mail-bericht en kan worden gelezen door de computer die het bericht ontvangt, mits deze beschikt over de applicatie waarin het attachment is opgemaakt. De wijze waarop de voorgegeven identiteit van een gebruiker gecontroleerd wordt. Dit is gebaseerd op wat de gebruiker weet (bv. een wachtwoord, PIN-code of cryptografische sleutel), wat de gebruiker bezit (bv. een smart card) en/of wat een gebruiker is (bv. spraak, handschrift of vingerafdruk). De bevoegdheden van gebruikers of programma s om op een bepaalde wijze gebruik te maken van bepaalde ICT-voorzieningen (netwerk, databases, programmatuur etc). Mogelijke aanvullende criteria zijn: rol/functie, locatie, tijd, transactie, service beperkingen (bv. aantal gebruikers). Een functionaris, anders dan de beheerder, die door de eigenaar van een ICT-voorziening gemachtigd is om autorisaties formeel goed te keuren. De IT-functionaris/-afdeling die verantwoordelijk is voor het operationeel houden en doorgaans de ondersteuning van het gebruik van een IT-voorziening. Beschikbaarheid raakt de doelstelling van de ongestoorde doorgang van informatiebewerking. Van veel informatie verwerkende processen wordt verwacht dat ze plaatsonafhankelijk 7*24 uur voor bevoegde personen beschikbaar zijn (any time, any place). Bevat de aspecten vertrouwelijkheid, integriteit en beschikbaarheid. Iedere gebeurtenis die de betrouwbaarheid van de informatievoorziening verstoort. Aan de te beveiligen objecten moet een minimaal veiligheidsniveau worden toegekend. In dit plan worden de procedures vastgelegd ter voorkoming van verlies van gegevens bij een eventuele calamiteit (brand, diefstal, crash). Computer Emergency Respons Team Universiteit Utrecht. Team dat coördinerend optreedt bij het oplossen van beveiligingsincidenten Chief Information Security Officer, Security officer op UU-niveau. De mate waarin het mogelijk is kennis te verkrijgen over de opzet en werking van de huisregel, zodat kan worden vastgesteld in hoeverre de huisregel aan de gedefinieerde kwaliteitsaspecten voldoet. Maatregelen die tot doel hebben verstoringen te ontdekken, danwel bedreigingen te ontdekken die tot een verstoring kunnen leiden. Letterlijk: afwijzen van verantwoordelijkheid. Disclaimers verschijnen vaak onder aan mailberichten of webpagina's. Hierin wordt de lezer er b.v. op geattendeerd dat de berichtgeving vertrouwelijk is en dat aan de uitspraken geen rechten ontleend kunnen worden. De voor een ICT-voorziening hoogst verantwoordelijke manager. Versleuteling. Een proces waarbij informatie onherkenbaar wordt gemaakt om te voorkomen dat onbevoegden de gegevens bekijken Universiteit Utrecht 21
Firewall Gebruiker Gegevensclassificatie Hacking ICT-voorziening Identificatie Inbraak Incident Incidentenbeheer Informatiesysteem Integriteit Intranet LSC Lokale ondersteuner/ondersteuning Meldpunt Non repudiation Outsource Partners Risico analyse of gebruiken, in het bijzonder tijdens de verzending of wanneer de gegevens worden opgeslagen op een draagbaar (magnetisch, opties etc.) medium. Er is een sleutel nodig om de informatie te decoderen. Dit is het omzetten van gegevens naar een leesbare vorm. Bij bijvoorbeeld Internet. 'Brandscherm', een methode om computersystemen beter te beveiligen door toegang vanuit netwerkdelen te blokkeren, danwel middels een specifieke autorisatie toegang te verlenen. Een stuk software dat de grensovergang tussen Intra- en Internet controleert. Een gebruiker is een persoon die gebruik maakt van de UU-ICTvoorzieningen (toepassingen, gegevens, documenten, netwerk, apparatuur). De gegevens die de UU gebruikt kunnen onderverdeeld worden in verschillende categorieën. Dit is een andere term voor kraken. Dit betekent dat onbevoegden toegang proberen te krijgen tot de gegevens van het systeem, via de faciliteiten van een netwerk. Component van het UU-netwerk of de (elektronische) informatievoorziening bij de UU. Voorbeelden zijn: toepassingen (waaronder kantoorautomatisering), gegevens, documenten, externe koppelingen, Pc s, apparatuur (b.v. ticketprinter), (sub)netwerken en diensten. De wijze waarop een gebruiker zijn identiteit aantoont (bijv paspoort, collegekaart). Het zonder formele autorisatie verkrijgen van toegang tot het UUnetwerk of de daartoe behorende IT-voorzieningen. Iedere gebeurtenis die de betrouwbaarheid, vertrouwelijkheid of beschikbaarheid van de informatievoorziening in gevaar kan brengen, evenals (vermoedens van) zwakke punten in de beveiliging. Het proces incidentenbeheer richt zich op het administreren, volgen en beheersen van incidenten, nadat hiervan melding is gemaakt. Het geautomatiseerde onderdeel van een bedrijfsproces. raakt het thema van vertrouwen in de gegenereerde informatie ofwel juistheid en volledigheid van informatie Intranet is de term die gebruikt wordt als een bedrijfsnetwerk wordt opgezet met Internet-technologie. Het Internet blijft de term waarmee het publieke wereldwijde netwerk wordt bedoeld. Een Intranet betreft altijd een lokaal (of een aantal aan elkaar gekoppelde lokale netwerken), zonder dat er noodzakelijkerwijs sprake is van een open verbinding met het Internet. Local Security Contact. De functionaris die binnen een beheerseenheid verantwoordelijk is voor de informatiebeveiliging. De IT-functionaris/-afdeling die verantwoordelijk is voor de ondersteuning van de werkplekken bij de beheerseenheden en daarmee tevens eerste aanspreekpunt bij incidenten m.b.t. informatiebeveiliging. Een tijdens werktijden bereikbare persoon/organisatie voor de melding (en afhandeling) van beveiligingsincidenten (bij voorkeur de lokale ondersteuning/ict-servicedesk). Onweerlegbaarheid Externe organisaties waaraan verantwoordelijkheden voor informatieverwerking is uitbesteed. De diensten worden geregeld via zgn. SLA s. Bij de UU is Capgemini de grootste outsource partner Dit is een methode die informatie oplevert, waarmee het management in staat wordt gesteld te beslissen welke risico s een Universiteit Utrecht 22
Screensaver Servicedesk SLA Systeembeheerder Toegangscontrole UU ICT Infrastructuur UU netwerk Vertrouwelijkheid Virus WBP te grote potentiële schade vormen en met welke maatregelen deze risico s teruggedrongen kunnen worden. Programma dat inbranden van het beeldscherm voorkomt. Wanneer de PC wel aanstaat, maar niet gebruikt wordt zet de screensaver het scherm uit, danwel plaatst steeds wisselende plaatjes op het beeld. Tegenwoordig is dit programma voornamelijk van belang vanwege de additionele mogelijkheid om terugkeer naar de werkelijke schermgegevens af te schermen met een wachtwoord Centraal meldpunt voor incidenten met de computer apparatuur Service Level Agreement. De ICT-functionaris/-afdeling die verantwoordelijk is voor het operationele technische beheer van een informatiesysteem Het proces dat afhankelijk van een autorisatie toegang verleent tot een IT-voorziening. Het UU netwerk (SOLISnet alsmede alle daaraan gekoppelde (sub)netwerken en computersystemen) en daarop geïmplementeerde dienstverlening SOLISnet alsmede alle daaraan gekoppelde (sub)netwerken. De mate waarin de toegang tot gegevens of functionaliteit beperkt is tot degene die daartoe bevoegd zijn. Een programma dat een kopie maakt van zichzelf en zich zodoende verspreidt via opslagmedia (floppy, harde schijf, CD, etc.) of via een computernetwerk. Virussen richten vaak schade aan in de computersystemen waarin ze zijn binnengedrongen. Wet Bescherming Persoonsgegevens, voorheen WPR (Wet Persoons- registraties) genaamd. Universiteit Utrecht 23
Bijlage II: Beveiligingsorganisatie en Management model College van Bestuur CIO CISO CERT-UU Faculteiten en diensten vertegenwoordigd door de LSC Het management model is voor informatiebeveiliging is uitgewerkt tot onderstaand cyclisch model. Planning & Beleid Projecten Controle & Evaluatie Exploitatie & beheer Universiteit Utrecht 24
Bijlage III - Het basis beveiligingsmodel: Buitenwereld Het model: Publiek domein Universitair intern bedrijfsnetwerk core Voorbeelden voor invulling: WWW Remote toegang Staf Data Contract onderzoek Labopstelling fileservices Wirelesss ELO Inprikplekken SAP Osiris Universiteit Utrecht 25
Het basis beveiligingsmodel is van toepassing op alle universitaire ICT-middelen en processen. Binnen het model zijn vier subdomeinen gedefinieerd, te weten het publieke subdomein, het universitaire domein, het interne bedrijfsnetwerk en de core. Volgens de in hoofdstuk drie beschreven classificatie zijn de universitaire ICT-middelen en processen binnen de subdomeinen te classificeren als standaard voor het publieke domein, belangrijk voor het universitaire domein, strategisch voor het interne bedrijfsnetwerk en kritisch voor de core. Mits hiermee geen universitaire voorzieningen worden belemmerd is het binnen het model mogelijk om binnen een subdomein aparte zones te definiëren. Dit kan een zone voor een specifiek proces zijn (bijvoorbeeld SAP of voor een specifiek onderdeel, bijv. de faculteit Geowetenschappen). Onder voorwaarden is verkeer tussen zones mogelijk. Hiervoor worden aanvullende beveiligingseisen gesteld die vertrouwen tussen de zones waarborgen. 1. Op het grensvlak tussen buitenwereld en publiek subdomein Dit grensvlak is beschermd tegen de meest voorkomende bedreigingen van buitenaf. In bijlage V is beschreven welke beschermende maatregelen zijn getroffen. 2. Het Publiek-subdomein In het subdomein genaamd publiek worden services geplaatst die voor de buitenwereld beschikbaar dienen te zijn. De universitaire webserver is hier een voorbeeld van. Voor dit subdomein zijn beschikbaarheid en integriteit de voornaamste beveiligingscriteria. Authenticatie en autorisatie zijn niet noodzakelijk. Minimale eisen die gesteld worden zijn een virus scanner, installatie van beveiliging patches en een goede back-upvoorziening. Logging van het gebruik, met als doel misbruik te kunnen traceren, is vereist. 3. Het universitair domein In dit subdomein worden alle publiekswerkplekken, Interneteilanden, practicumzalen, wireless systemen en, onder voorwaarden, remote (thuis) werkplekken geplaatst. Vanuit dit subdomein is toegang mogelijk tot de subdomeinen Publiek en het subdomein Intern bedrijfsnetwerk onder de volgende condities: - elk gebruik is terug te voeren tot een verantwoordelijk individu (authenticatie) - toegang tot het subdomein publiek en het Internet (de buitenwereld) is vrij - toegang tot het subdomein Intern bedrijfsnetwerk geschiedt op basis van authenticatie en autorisatie Vanuit dit subdomein wordt geen rechtstreekse toegang tot de core verleend. Voor dit subdomein zijn integriteit en beschikbaarheid de voornaamste beveiligingscriteria. Minimale eisen die gesteld worden zijn een virus scanner, installatie van beveiligings patches en een goede back-upvoorziening. Logging van het gebruik, met als doel misbruik te kunnen traceren, is vereist. 4. Het interne bedrijfsnetwerk Binnen dit subdomein kunnen fileservers, Intranetservers en vaste werkstations van medewerkers worden opgenomen. Gebruik van de servers geschiedt op basis van authenticatie en autorisatie. De systemen binnen dit subdomein zijn voorzien van een virus scanner. Op deze systemen wordt bovendien een actief beleid op het gebied van beveiligingspatches uitgevoerd. Vanuit het Intern bedrijfsnetwerk subdomein is het mogelijk om zonder extra belemmeringen toegang te verkrijgen tot het subdomein publiek en het Internet (de buitenwereld). Toegang tot het subdomein core is mogelijk op basis van authenticatie en autorisatie. Beveiligingscriteria zijn integriteit, beschikbaarheid én vertrouwelijkheid. Installatie van een virus scanner en installatie van beveiligingspatches zijn vereist. Voor de opgeslagen informatie is een goede back-upvoorziening vereist met opslag op verschillende fysieke locaties. Logging van het gebruik, met als doel misbruik te kunnen traceren, is vereist. Universiteit Utrecht 26
5. De core In het core subdomein bevinden zich twee typen processen, te weten de kritische (bedrijfs)processen en de processen die op zichzelf niet of nauwelijks te beveiligen zijn (bijvoorbeeld aan het netwerk gekoppelde proefopstellingen). Voor dit subdomein gelden zware eisen ten aanzien van beschikbaarheid, vertrouwelijkheid en integriteit. Toegang tot deze processen is ofwel geheel niet mogelijk (geldt bijvoorbeeld voor proefopstellingen) of is alleen mogelijk op basis van authenticatie via één van de andere domeinen. Voor deze kritische bedrijfsprocessen zijn de beveiligingscriteria integriteit, beschikbaarheid én vertrouwelijkheid. Voor sommige processen in dit subdomein is gebruikersnaam/wachtwoord niet voldoende, maar is strenge authenticatie vereist. In een aantal gevallen dient het verkeer van en naar deze processen versleuteld te worden. Waar nodig stelt de CISO-UU aanvullende eisen op dit gebied. Installatie van een virus scanner en installatie van beveiligingspatches zijn vereist Logging van het gebruik, met als doel misbruik te kunnen traceren, is vereist. Voor de opgeslagen informatie is een goede back-upvoorziening vereist met opslag op verschillende fysieke locaties. Voor de moeilijk te beveiligen processen zijn integriteit en beschikbaarheid de voornaamste beveiligingscriteria. Universiteit Utrecht 27
Bijlage IV Aansluitvoorwaarden Solisnet 1. Inleiding SOLISnet is het datanetwerk van de Universiteit Utrecht en omvat het samenstel van kabels en actieve netwerkapparatuur in en tussen de gebouwen van de universiteit. SOLISnet is een universitaire voorziening uitsluitend voor studenten en medewerkers van de universiteit. Voor een goede werking van SOLISnet is het van belang een aantal standaarden, regels, voorwaarden, eisen, richtlijnen en normen in aansluitvoorwaarden vast te leggen. De directeur ICT is namens het College van Bestuur verantwoordelijk voor aanleg en beheer van SOLISnet én stelt de aansluitvoorwaarden vast. Het naleven van de aansluitvoorwaarden is van collectief belang en wordt daarom door de directie ICT niet alleen bewaakt maar ook gestimuleerd. Elke faculteit en dienst wordt geacht die maatregelen te nemen die nodig zijn om aan de aansluitvoorwaarden te voldoen. De directie ICT is uiteraard bereid om een toelichting op deze voorwaarden te geven. Bij het niet naleven van deze aansluitvoorwaarden wordt de verantwoordelijke beheerder en diens management hierop aangesproken. De directeur ICT is bevoegd om alle benodigde maatregelen te treffen om de functionaliteit, de integriteit en veiligheid van het net te garanderen. Indien een SOLISnetaansluiting hinder veroorzaakt kan de directeur ICT besluiten deze af te sluiten van het netwerk. Dit wordt, zo mogelijk, vooraf aan de lokale beheerder gemeld. Behalve deze aansluitvoorwaarden zijn voor de individuele eindgebruiker ook de gebruiksregels ICT-faciliteitengebruiksreglement ICT-faciliteite van toepassing. Door gebruik te maken van een SOLISnet aansluiting verklaart men zich automatisch akkoord met deze voorwaarden. Deze aansluitvoorwaarden worden gepubliceerd op de webpagina s van de directie ICT (www.ict.uu.nl)www.ict.uu.nl). 2. De SOLISnetaansluiting Onder een SOLISnetaansluiting wordt verstaan de fysieke walloutlet van SOLISnet (het netwerkstopcontact ). Op een SOLISnetaansluiting mag slechts één apparaat (computer, printer enz.) worden aangesloten. Een SOLISnetaansluiting kan pas gebruikt worden nadat hiervoor een abonnement is afgesloten. Een abonnement omvat: levering van een actieve aansluiting op SOLISnet levering van een aansluitkabel ter lengte van maximaal 4 meter Grotere lengtes, tot en met een lengte van 8 meter, zijn voor rekening van de aanvrager. Lengtes boven de 8 meter worden niet ondersteund verhelpen van netwerkstoringen beheer van de netwerkaansluiting t/m de walloutlet ( het netwerkstopcontact ) verhuizing van de aansluiting opheffen van de aansluiting transparant transport van data binnen SOLISnet, voor zover deze voldoet aan de toegelaten standaards en het universitaire beveiligingsbeleid transparant transport via SURFnet van en naar het Internet, voor zover deze voldoet aan de toegelaten standaards en het universitaire beveiligingsbeleid gebruik van de universitaire services, te weten Domain Name Service, Mail-relay, Mailfallback, Time service, DHCP service en Netnews service. Universiteit Utrecht 28
Nieuw abonnementen, wijzigingen en opheffingen op SOLISnet kunnen alleen door de geautoriseerde personen van de decentrale eenheden bij de SOLISnetbeheerder worden aangevraagd. Per faculteit of dienst kunnen, naast de directeur, maximaal 3 personen geautoriseerd worden. De hiervoor bedoelde mutaties worden alleen geaccepteerd indien zij zijn aangemeld via het daarvoor bestaande webformulier ( www.net.uu.nl ). Uitzondering op deze regel is de aanvraag van 6 of meer mutaties tegelijkertijd. In dit geval dient men contact op te nemen met de SOLISnetbeheerder. Het is verboden om zelf wijzigingen aan SOLISnetaansluiting uit te (laten) voeren. Uitbreidingen en wijzigingen kunnen alléén in overleg met, en na goedkeuring door de afdeling ICT, door de SOLISnetbeheerder worden uitgevoerd. Indien de SOLISnetbeheerder constateert dat zonder zijn medeweten mutaties zijn uitgevoerd, worden de herstelkosten altijd op de veroorzaker verhaald. Dit geldt ook voor uitbreidingen. 3. Abonnementen Voor het gebruik van een SOLISnetaansluiting is, per aangesloten systeem, een abonnementsgeld verschuldigd. De tarieven en voorwaarden worden jaarlijks door de directeur ICT vastgesteld en schriftelijk gecommuniceerd naar directeuren van faculteiten en diensten. Doorberekening geschiedt per kwartaal en per beheerseenheid (één factuur per faculteit of dienst) Reclames over facturen dienen binnen 1 maand na dagtekening van de factuur ingediend te worden bij de afdeling ICT van de universiteit. Reclames na deze periode kunnen niet leiden tot restitutie van abonnementsgeld. Niet betaalde aansluitingen worden na een periode van twee maanden afgesloten. 4. Aansluitvoorwaarden 4.1 Aangesloten systemen De op SOLISnet aangesloten systemen dienen: te beschikken over door de SOLISnetbeheerder goedgekeurde interfaces zich te houden aan de voorgeschreven adresseringsschema's zich te onthouden van het uitsturen van routeringsinformatie 4.2 hubs en switches Het gebruik van eigen hubs en switches is slechts toegestaan indien: - in de betreffende ruimte meer systemen geplaatst dienen te worden dan het aantal aanwezige SOLISnet aansluitpunten toelaat en de installatie van extra walloutlets onevenredig duur is - de SOLISnetbeheerder hiervoor toestemming heeft verleend De SOLISnetbeheerder dient SNMP-leesrechten te hebben op alle netwerkapparatuur, ook die apparatuur die niet door SOLISnetbeheer beheerd wordt. 4.3 wireless access points Gebruik van wireless apparatuur wordt onder de volgende voorwaarden toegestaan: - de SOLISnetbeheerder hiervoor toestemming heeft verleend - de wireless infrastructuur volgens de universitaire standaarden wordt ingericht De standaard voor authenticatie van gebruikers in een wireless omgeving is IEEE 802.1x. 4.4 Inbelservers en modems Uit beveiligingsoogpunt wordt geen toestemming verleend om eigen inbelservers en/of modems direct of indirect op SOLISnet aan te sluiten; overleg volgt nog over bestaande inbelservers en modems. Universiteit Utrecht 29
4.5 Routers Vanwege doorvoersnelheid, beheersbaarheid en mogelijke toekomstige uitbreidingen in functionaliteit wordt geen toestemming verleend om eigen routers in het netwerk te plaatsen; overleg volgt nog over bestaande routers waarvoor in het verleden toestemming is gegeven. 4.6 Firewalls en VPN-servers Vanwege beveiliging, doorvoersnelheid, beheersbaarheid en mogelijke toekomstige uitbreidingen in functionaliteit wordt geen toestemming verleend om eigen firewalls of vpn-servers in het netwerk te plaatsen; overleg volgt nog over bestaande firewalls en vpn-servers waarvoor in het verleden toestemming is gegeven. Bij storingen in het netwerk kan de directeur ICT besluiten delen hiervan af te sluiten, totdat de storingsbron is ontdekt. 5. Beveiliging Het netwerk is niet volledig transparant. Op de connectie met SURFnet/Internet en in de overige backbonerouters zijn enige filters geplaatst om elementaire vormen van misbruik te voorkomen; dit is conform het universitaire beveiligingsplan. Van de beheerders van de op SOLISnet aangesloten systemen wordt verwacht dat zij alle redelijke maatregelen treffen ter voorkoming van aanvallen en misbruik op de aangesloten systemen. Inbraken en pogingen daartoe in systemen die met SOLISnet verbonden zijn, dienen onverwijld gemeld te worden aan het Computer Emergency Response Team (CERT-UU), hetzij telefonisch (030-2535959), hetzij per E-mail (cert-uu@uu.nl). De beheerder van het getroffen systeem dient alle noodzakelijke medewerking aan de CERT-leden te verlenen bij het opsporen van de overtreder. Het is verplicht om het gebruik van de netwerkaansluiting te kunnen herleiden tot een specifieke gebruiker Dit is een eis van SURFnet. Door gebrek aan standaarden op dit gebied is anoniem gebruik tot op heden gedoogd. Inmiddels is er een standaard beschikbaar (802.1x) en is het gebruik hiervan bij nieuwe installaties en bij vervanging van bestaande installaties verplicht. Voor het overige gelden voor eindgebruikers én beheerders de vigerende gebruiksregels ICTfacilitieiten, die onderdeel zijn van het informatiebeveiligingsbeleid van de universiteit 6. Netwerkprotocollen Volgens laag 3 van het OSI-model wordt alleen het TCP/IP-protocol door het gehele netwerk gerouteerd. Lokaal, binnen gebouwen of binnen faculteiten/diensten zijn andere protocollen toegestaan zolang andere gebruikers hiervan geen hinder ondervinden. 6.1 TCP/IP Het (TCP-)IP-netwerk van de Universiteit Utrecht maakt gebruik van het B-klasse adres 131.211.0.0. Organisaties buiten de UU die wel aan SOLISnet zijn aangesloten dienen zelf bij SURFnet een IP-netwerkadres aan te vragen. Subnetting Het netwerk is onderverdeeld in subnetten van variabele grootte, variërend van 8 tot 1024 adressen. Van de beschikbare adressen in elk subnet is een aantal gereserveerd. Het eerste adres is het adres van de default router voor dat subnet. De overige gereserveerde adressen zijn voor gebruik door de SOLISnetbeheerder. Het aantal gereserveerde adressen hangt af van de grootte van het uitgegeven subnet. In de volgende tabel is het verband tussen subnetmask, aantal adressen en aantal gereserveerde adressen te zien: Subnet bits Subnet-mask Aantal hosts Effect. hosts Aantal gereserveerd 7 255.255.254.0 512 510 5 8 255.255.255.0 256 254 5 Universiteit Utrecht 30
9 255.255.255.128 128 126 4 10 255.255.255.192 64 62 4 11 255.255.255.224 32 30 4 12 255.255.255.240 16 14 4 13 255.255.255.248 8 6 4 14 255.255.255.252 4 2 2 De Solisnetbeheerder is verantwoordelijk voor de uitgifte van IP-adressen en subnetten. Het is ter beoordeling van de Solisnetbeheerder hoe subnetting wordt toegepast. Hiervoor zijn geen criteria vastgelegd. Voor elk subnet wordt een administratief beheerder (een persoon of afdeling) aangewezen die verantwoordelijk is voor de uitgifte en administratie van IP-adressen binnen dat subnet. Op het adres http://www.net.uu.nl /subnets.html is te zien welke subnets zijn uitgegeven en wie de beheerder daarvan is. Het is mogelijk dat een beheerder een toegewezen subnet zelf weer verder onderverdeelt in kleinere subnetten. In dat geval gelden voor de ontstane subnetten dezelfde regels voor o.a. gereserveerde adressen. Een dergelijke verdere onderverdeling moet altijd vooraf ter goedkeuring aan de SOLISnetbeheerder worden voorgelegd. De beheerder van een subnet dient een goede administratie van de IP-adressen te voeren. Een goede administratie bevat minimaal de gegevens die een IP-adres kunnen herleiden naar een systeem en de locatie van dat systeem. Bij het gebruik van DHCP dient door middel van logging aangetoond te kunnen worden wel IP-nummer aan een bepaald MAC-adres is toebedeeld. Zie voor meer informatie de paragraaf over DHCP. Desgevraagd dient aan de SOLISnetbeheerder opgegeven te worden aan wie of aan welke machine een bepaald adres is toegewezen. Een administratief beheerder dient eenieder die gebruik maakt van een SOLISnetaansluiting in het beheerde subnet, desgevraagd één of meerdere IP-adressen toe te wijzen. Dit kunnen zowel vaste als via DHCP dynamisch toegewezen adressen zijn. Routering Voor het routeren van IP-verkeer maken de routers gebruik van het routing protocol OSPF. De hierbij behorende indeling in zogenaamde area's is ook terug te vinden in het boven genoemde overzicht van subnets. Behalve de backbone-routers mag geen enkele router een statisch geconfigureerde 'default-route' adverteren. DHCP Voor de dynamische uitgifte van IP-adressen is binnen SOLISnet een DHCP-service beschikbaar. Faculteiten en diensten mogen gebruik maken van deze service. Het opzetten en beheren van DHCP-server(s) kan aan een faculteit of dienst gedelegeerd worden. Indien een faculteit of dienst zelf een DHCP-server inricht, is men verplicht zonodig ook DHCPservices te verlenen aan andere gebruikers binnen het subnet. Binnen een subnet kan slechts één DHCP-server actief zijn. Om gebruik en vooral misbruik te kunnen traceren dient op elke DHCP-server een uitgebreide logging van tijdstip, IP-adres en Mac-adres bijgehouden te worden. Deze gegevens dienen minimaal drie weken beschikbaar te blijven. De SOLISnetbeheerder of medewerkers van CERT-UU kunnen naar deze gegevens vragen. In geval van misbruik moeten deze binnen twee uur opgeleverd kunnen worden. Naamgeving Zie paragraaf 2.4 6.3 NetBIOS en Microsoft-netwerken NetBIOS ondersteuning op SOLISnet: Het NetBIOS-protocol kan onder andere over NetBEUI of TCP/IP worden getransporteerd. Bij het gebruik van NetBEUI, dat niet op de backbone wordt toegelaten, is de naamgeving vrij, waarbij alleen binnen het eigen subnet overeenstemming moet worden bereikt. NetBIOS-naamgeving wordt op geen enkele manier ondersteund op het SOLISnet. Universiteit Utrecht 31
Wie services aan Windows-clients ter beschikking wil stellen, wordt geadviseerd om als transportprotocol alleen TCP/IP en voor de naamgeving alléén de Domain Name Service te gebruiken. Bij gebruik van TCP/IP moeten domains en workgroups namen dragen die beginnen met het door het onderdeel gebruikte TCP/IP-subdomain. Omdat controle op gebruik van NetBEUI- (en IPX-)broadcasts binnen het lokale subnet nauwelijks mogelijk is wordt het beheer van namen voor machines en workgroups aan de lokale beheerders overgelaten. Er worden geen universitaire WINS- of andere NetBIOS-services worden ingericht. 7. Domain Name Service en naamgeving De universiteit heeft binnen de Internet-naamgeving (Domain Name System) de domeinnaam "uu.nl" toegewezen gekregen. Binnen deze domeinnaam bevinden zich een aantal diensten, systemen en mailadressen die voor de universiteit een centrale rol vervullen. Bovendien is binnen uu.nl een aantal sub-domeinen actief. Deze zijn grotendeels een afspiegeling van de organisatie van de universiteit. Deze sub-domeinen worden uitgegeven door de 'naming authority' van de Universiteit Utrecht. De rol van naming authority wordt uitgevoerd door de afdeling ICT. Het beheer van sub-domeinen kan, onder de in paragraaf 4.4.2 genoemde voorwaarden, aan een faculteit of dienst gedelegeerd worden. De beheerder van het sub-domein mag de namen van diensten en systemen binnen dat sub-domein in principe vrij kiezen. Ook kan het sub-domein verder worden onderverdeeld. De naming authority blijft echter verantwoordelijk voor de naamgeving binnen het uu.nl domein en kan bepaalde namen verbieden wanneer daar gegronde redenen voor bestaan. Voor het uu.nl domein zijn twee servers ingericht die, om continuïteit te kunnen garanderen, op twee geografisch gescheiden locaties staan opgesteld. Bovendien is een back-up faciliteit gerealiseerd bij SURFnet bv. De universitaire servers zijn: ns.uu.nl met IP-adres 131.211.4.5 en ns2.uu.nl met IP-adres 131.211.4.6 7.1 Beveiliging DNS Voor de zones waarvoor de universitaire servers als master fungeren worden zone-transfers alleen toegestaan naar officiële slave-servers. Dat zijn in principe alle servers die authoritive zijn voor de server (die in de NS-records van de zone vermeld staan). DNS-queries blijven gewoon mogelijk, zodat het normale proces van name-resolving niet verstoord zal worden. Voor de zones waarvoor de universitaire servers als slave fungeren worden zone-transfers alleen toegestaan aan de beide universitaire servers, en aan de master. Dit laatste om de beheerder van de master-zone in staat te stellen de inhoud van de slave-copieën te controleren. Ook hier blijven DNS-queries gewoon mogelijk. Domeinen en sub-domeinen worden binnen de techniek ook wel onder één noemer gebracht en zones genoemd. Om deze reden worden hierna in dit hoofdstuk alleen nog zones genoemd. 7.2 Verplichtingen en richtlijnen voor decentrale zonebeheerders: Zonebeheerders zijn verantwoordelijk voor het correct functioneren van hun servers(s) en voor de correcte configuratie van de zones op hun servers. Dit betekent dat van hen verwacht wordt dat zij: 1. over voldoende kennis op het gebied van DNS beschikken; 2. voor het oplossen van storingen op werkdagen tijdens kantooruren altijd bereikbaar zijn. We gaan uit van een max. reactietijd van 2 uur (voor het geval er dringende zoneoverstijgende problemen zijn) Om deze reden dienen naam en telefoonnummer van de decentrale zonebeheerder bij SOLIsnetbeheer (hostmaster@uu.nl) bekend te zijnhostmaster@uu.nl) bekend te zijn. Universiteit Utrecht 32
Over minder dringende zaken wordt per E-mail gecommuniceerd. Hiervoor wordt het Zone-mailadres dat in het SOA-RR staat gebruikt. De standaard voor dit adres is hostmaster@xyz.uu.nl, waarbij xyz de gedelegeerde zonenaam is. Deze mailbox dient minimaal eenmaal per 24 uur gelezen te worden. Voor (gedelegeerde) zones die als master beheerd worden moeten, zone-transfers toegestaan worden aan ns.uu.nl (131.211.4.5) en aan ns2.uu.nl (131.211.4.6), én aan alle overige slave servers. Uit beveiligingsoogpunt dienen overige zone-transfers geblokkeerd te worden. Om redenen van performance- en beschikbaarheid dienen ns.uu.nl en ns2.uu.nl als slave server geconfigureerd te worden en dient dit bij SOLISnet-beheer (hostmaster@uu.nl) aangemeld te wordenhostmaster@uu.nl ) aangemeld te. Zone-transfers van deze zones naar derden wordt vervolgens geblokkeerd. Wijzigingen in de eigen DNS-server-configuratie (zoals verandering van IP-adres) dienen altijd vooraf gemeld te worden aan de SOLISnetbeheer via een mailbericht aan hostmaster@uu.nl. Hiermee voorkomt men dat zone-delegaties worden verbroken(met als gevolg onbereikbaarheid van sub-domeinen). Van elk systeem en/of service dat op het netwerk aangesloten is/wordt, en dat gebruik maakt van publieke IP-adressen, moeten de actieve IP-namen en -adressen in de DNS opgenomen zijn. Bij alle IP-adressen, die aangewezen worden d.m.v. A-records, moet tenminste een PTR-record (reversed DNS-entry) gedefinieerd worden. Elk PTR-record moet weer terugverwijzen naar de IPnaam van het bijbehorende A-record. De administratief beheerder van een subnet is verantwoordelijk voor de invulling en beheer van de PTR-records die onder zijn/haar subnet vallen. Voor subnets met 256 of meer adressen (netmask <= 24) wordt de zone(s) x.211.131.inaddr.arpa toegewezen voor de invulling van de PTR-records (waarbij x het derde octet van de range(s) van IP-adressen). Voorbeeld: de range 131.211.64.0/22 (dat zijn de adressen 131.211.64.0 t/m 131.211.67.255) krijgen de zones 64.211.131.In-addr.ARPA, 65.211.131.In-addr.ARPA, 66.211.131.In-addr.ARPA en 67.211.131.In-addr.ARPA. Voor kleinere subnets wordt de methodiek zoals beschreven in RFC 2317 toegepast: de zone y- m.x.211.in-addr.arpa wordt toegewezen, waarbij x het derde octet van de IP-adres-range, y het vierde octet van het beginadres van de IP-range, m het aantal bits van het netmask. De parentzone (x.211.131.in-addr.arpa) bevat CNAME-records verwijzend naar de PTR- records in de subzones, en wordt beheerd op de centrale servers. Voorbeeld: de range 131.211.5.128/27 (dat zijn de adressen 131.211.5.128 t/m 131.211.5.159) krijgt de zone 128-27.5.211.131.In-addr.ARPA. Als alle subnets met hetzelfde derde octet onder een beheer vallen hoeft de methodiek volgens RFC-2317 niet toegepast te worden. Op gezette tijden worden door SOLISnetbeheer checks uitgevoerd (DNS-walks) op de DNSconfiguratie. Dit gebeurt vanaf één van de universitaire servers ns.uu.nl of ns2.uu.nl. Wellicht ten overvloede: De standaard RFC's (zie b.v. http://www.isi.edu/in-notes) dienen opgevolgd te worden. Bij A-records dienen altijd de PTR-records op correcte wijze geconfigureerd te worden binnen de toegewezen gedelegeerde zone(s) onder 211.131.In-addr.ARPA; let speciaal op de kleine subnetten (< 256 adressen) volgens de RFC-2317-methodiek. Bij falend DNS beheer kan de directeur ICT besluiten om de zonedelegatie van het falende onderdeel in te trekken. Hierover zal dan eerst met de leiding van de faculteit of dienst worden overlegd. 8. Mail, Mail relay en mail-fallback 8.1 Anti-virus en anti-spam Anti-virusbeleid op de universitaire infrastructuur: Universiteit Utrecht 33
Op de universitaire exchange/outlook infrastructuur is antivirus software van Sybari Antigen geïmplementeerd. De software is dusdanig geconfigureerd dat mailberichten die een virus bevatten weggegooid worden, ongeacht of het virus zich in het bericht zelf of in een bijlage bevindt. Afzender en geadresseerde ontvangen hier GEEN bericht van. Ook uitgaande mailberichten worden op dezelfde manier gecontroleerd op virussen. Deze acties worden wel in een logfile vastgelegd zodat achteraf getraceerd kan worden of een bepaald bericht doorgestuurd of vernietigd is. De virusscanner wordt dagelijks om 18.00 uur automatisch bijgewerkt en, indien nodig, extra via een handmatige update. Voor facultaire systemen (werkplekken en servers) is het gebruik van up-to-date antivirus software verplicht. De UU heeft via SURFdiensten een licenties voor Mcafee en Sybari. Anti-spam beleid: Op de universitaire mailrelay-servers is om de hoeveelheid spam te beperken het product MAPS geïmplementeerd. Deze software blokkeert een groot deel van de binnenkomende spam. Zie voor meer informatie over MAPS: http://mail-abuse.org/pressreleases/2002-01-23.html De eindgebruiker heeft geen invloed op het al dan niet doorlaten van mailberichten die volgens de MAPS-regels SPAM bevatten. Indien een gebruiker daarvoor een gegronde reden heeft kan hij/zij via de security officer (ciso@uu.nl) vragen of een bepaald domein, dat op de MAPS blacklist staat, in de MAPS whitelist opgenomen kan worden. Per geval wordt bekeken hoe schadelijk dit is. Indien een dergelijk domein overlast veroorzaakt wordt dit alsnog (opnieuw) op de blacklist geplaatst. Voor facultaire servers wordt anti-spam software sterk aanbevolen. Het is niet uitgesloten dat upto-date anti-spam software in de toekomst verplicht wordt. 8.2 Mail De door de Universiteit vastgestelde policy voor anti-virus, anti-relaying en anti-spam is van toepassing. Per maildomein zijn de volgende mailadressen verplicht: postmaster@xyz.uu.nl : e-mail problemen/aliassen/lijsten abuse@xyz.uu.nl : beveiliging gerelateerde zaken hostmaster@xyz.uu.nl : domain name service problemen/wijzigingsverzoeken Ten behoeve van het uitwisselen van beveiligingszaken is elke beheereenheid is verplicht om een mailadres genaamd lsc@xyz.uu.nl (local security contact) in te richten waarbij xyz het sub-domein van de betreffende beheereenheid is. De volgende adressen zijn gewenst: nic@xyz.uu.nl of netmaster@xyz.uu.nl : netwerkbeheer gerelateerde zaken admin@xyz.uu.nl : systeembeheer gerelateerde zaken helpdesk@xyz.uu.nl : algemene hardware/software problemen of verzoeken webmaster@xyz.uu.nl : webgerelateerde zaken 8.3 Mail-relay en mail-fallback De universitaire exchange/outlook infrastructuur maakt gebruik van de universitaire mailrelay infrastructuur Deze is opgebouwd uit twee identieke servers, die fysiek in twee verschillende gebouwen staan opgesteld. Hiermee is een redundante infrastructuur verkregen. Op deze servers wordt Postfix gebruikt als MTA (Mail Transfer Agent). Op deze servers worden begin 2004 zowel MAPS als een antivirus scanner geïmplementeerd. De servers fungeren als mailrelay voor een aantal sub-domeinen van uu.nl en zijn bovendien tenminste 72 uur fallback voor alle mail voor het uu.nl domein die niet op lokale mailservers afgeleverd kan worden. Faculteiten en diensten kunnen van de universitaire servers gebruik maken om ofwel hun mail op een gecontroleerde manier af te handelen (antivirus en anti-spam) ofwel voor mail fallback (mxfallback). Universiteit Utrecht 34
De beschikbare fallback bedraagt 1 Gigabyte. De maximale grootte van een mailbericht bedraagt 10 Megabyte 9. Tenslotte De directeur ICT heeft het SOLISnetbeheer opgedragen aan Capgemini Outsourcing bv (hierna te CG te noemen). CG heeft de volmacht om naleving van deze aansluitvoorwaarden te controleren en is gemachtigd om, indien in geval van calamiteiten hier noodzaak toe is, eigenhandig stappen te ondernemen die nodig zijn om SOLISnet ongestoord te laten werken. Universiteit Utrecht 35
Bijlage V Gebruiksregels ICT-faciliteiten Als vervolgactie van de ICT-beveiligingsnota worden in samenwerking met JZ gebruiksregels voor ICT-faciliteiten opgesteld. In de gebruiksregels wordt aangegeven wat studenten en medewerkers van de UU niet mogen doen met de hen ter beschikking gestelde apparatuur en de infrastructuur. Tevens wordt opgenomen dat het gebruik van elektronische communicatiemiddelen wordt vastgelegd en hoe het toezicht/controle is geregeld. Tot slot wordt vermeld dat misbruik tot een sanctie kan leiden en wie die sanctie mag opleggen. Universiteit Utrecht 36