De gemeente Amsterdam wil een zwaar beveiligd, draadloos netwerk aan de diensten en stadsdelen gaan aanbieden. De reden daarvoor is dat deze nu op eigen houtje draadloze netwerken installeren, zonder voldoende beveiligingsmaatregelen te nemen. Dat blijkt uit het 'Plan van aanpak technische infrastructuur en applicaties', dat tot doel heeft om het aantal verstoringen in de basis-ict-werkplek terug te dringen.
'De vraag vanuit de gemeente naar draadloze netwerken is al enige tijd gaande', valt te lezen in het Plan van aanpak technische infrastructuur en applicaties. 'Diensten en stadsdelen leggen zelf verbindingen aan met externe partijen en/of installeren draadloze netwerken zonder voldoende beveiligingsmaatregelen te nemen, waardoor ze de achterdeur openzetten.'
Daarom lijkt het nodig 'dat de Dienst ICT een draadloze oplossing gaat aanbieden om zo controle te kunnen houden op met name beveiliging'. Het plan is om een 'highly secured wireless netwerk' aan te bieden. Dat moet bestaan uit 'ongeveer vijfhonderd toegangspunten, wireless lan-controllers en managementserversoftware'.
Schaduwnetwerken
Ook het vaste netwerk van de gemeente blijkt nauwelijks beveiligd te zijn. 'Er bestaat geen intrusion detection op het netwerk, er is geen netwerk performance monitoring en er zijn vele ‘grijze circuit'-acties.'
'Gemeentelijke onderdelen hebben een eigen schaduwnetwerk aangelegd met decentrale netwerkkoppelingen. Hierdoor is geen centraal beheer op netwerkbeveiliging mogelijk.'
Nodeloos complexe structuur
In het algemeen geldt volgens het plan van aanpak dat 'de ict-beveiligingsstructuur enorm ingewikkeld is gemaakt en hierdoor grote impact heeft op het beheer en op projecten. Deze onnodig ingewikkelde structuur staat de migratie naar een centraal hostingplatform in de weg.'
Daarom wil de gemeente in het derde kwartaal van 2011 de beveiliging van de netwerkstructuur gaan vereenvoudigen. Daarbij gaat het niet alleen om het 'kernsysteem', maar ook om verbindingen met 'andere applicaties van bijvoorbeeld ketenpartijen'.
903 beveiligingszones
Daarnaast moet het 'firewallconcept' aangepakt worden. 'Firewalls zijn uiterst complex ingericht en niet te beheren. Het risico op fouten is uiterst groot. Sommige beveiligingsissues zijn niet goed geregeld met het risico op financiële en/of imagoschade door oneigenlijk gebruik.'
Het aantal beveiligingsdomeinen moet worden teruggebracht naar vier. Nu zijn er 43 beveiligingszones voor de acht belangrijkste gemeentelijke diensten. 'Dit komt overeen met 903 relaties tussen deze zones', aldus het document. 'Door het huidige beveiligingsbeleid is configuratie van netwerkcomponenten erg complex. Dit verhoogt de oplostijd bij problemen en het risico van fouten.'
'Aangezien in de datacenter-omgeving bovendien nog een scheiding is doorgevoerd tussen kantoorautomatsering (KA) en non-KA-applicaties zijn deze 43 beveiligingszones ook in beide omgevingen doorgevoerd. Dit heeft geleid tot een nagenoeg onbeheersbare situatie van firewallregels.'
Daarnaast moeten 'kritieke of technisch ongeschikte' firewalls en switches vervangen worden. 'Een aantal netwerkcomponenten voldoet niet aan de huidige architectuur of mist de mogelijkheid om hieraan te kunnen voldoen.'
Lijkt me dat ze in Amsterdam eens eerst de basis informatie voorziening op orde maken in plaats van nog meer ambitieuze projecten op te starten die toch gedoemd zijn te mislukken.
Voeg er nog maar aan toe dat er geen MAC-based beveiliging aan de kant van de netwerkpoorten op werkplekken is.
Wifi netwerken komt meer doordat de ICT afdeling helaas geen loket is voor alle leveranciers; via de facilitaire afdeling en projecten die om de ICT afdeling heen worden opgestart komt nogal eens wat het netwerk binnen.
Kwestie van beleid en samenwerking op het management niveau opstarten en dat naar beneden toe communiceren en uitdragen, in deze organisatie is het echter zo dat er hokjesgeest is ipv samenwerking
Afgelopen tijd ben ik artikelen tegengekomen in Computable die pleiten voor decentralisatie van ICT beheer, omdat de centrale ICT organisatie te traag, log, star, bureaucratisch etc. zou zijn.
Bovenstaand artikel laat zien dat deze aanpak ook zo zijn nadelen heeft.
De “visie” van sommige experts en de realiteit lijken helaas nog niet met elkaar in overeenstemming.
@PaVaKe: De ‘visie’ van sommige experts (niet ik) is nu juist de je je visie niet aan de praktijk kunt toetsen. Net zomin als je kunt toetsen hoevaak je gemiddeld een bepaald resultaat hebt met een bepaalde dobbelsteen als je met die dobbelsteen in de praktijk maar één keer mag/kunt gooien en het bovendien in de praktijk nog voor discussie vatbaar is welk resultaat het meest gewenst is).
Een visie kun je alleen maar toetsen in goed opgezette en herhaalbare experimenten. Het misverstand dat de praktijk daarover uitsluitsel kan geven, is van alle tijden, maar al door figuren als Pascal,Fermat en neven/broers/zonen de Bernouilli achterhaald en bevestigd in talloze experimenten op universiteiten in de vorige eeuw.
Het vreemde is, dat we ons dit met allerlei vergelijkbare zaken realiseren en er niet over peinsen er onszelf een ongefundeerde mening over aan te meten, maar hierbij ligt het kennelijk niet voor de hand (zelfs niet bij grote hoeveelheden gerenommeerde wetenschappers) dat je er wetenschappelijk onderzoek naar kunt doen en ook op grote schaal is gedaan.
@Rob Koelman
Wat jij in je reactie “visie” noemt, zou ik liever “hypotese” noemen. Een hypothese kun je of theoretisch onderbouwen, of toetsen aan goed opgezette en herhaalbare experimenten.
Bij de “visie” zoals ik het bedoel in mijn reactie is dat experts een bepaalde toekomst voor ogen hebben, gebaseerd op ervaringen uit het verleden en nieuwe inzichten. Wat ik, zeker in dit specifieke geval, constateer is dat de experts vooral lijken te kijken naar de nieuwe inzichten (behoefte aan decentralisatie) waarbij ervaringen uit het verleden (een beheersbare en gecontroleerde (beveiligde) omgeving)uit het oog verloren worden
Zijn dit bring your own netwerken of moet ik zeggen devices?
@PaVaKe: Maar een visie is toch altijd gebaseerd op getoetste hypothesen als het goed is? Dat is op zich ook al een visie en een hypothese, trouwens.
Waar het mij om gaat is dat experts bij het verwerven van nieuwe inzichten kijken naar ervaringen uit het verleden. Andere ervaringen uit het verleden zeggen nou juist dat dat niet kan. Er zitten teveel kanselementen in die zich in de praktijk noch à priori noch à posteriori laten quantificeren omdat ieder geval zijn eigen omstandigheden kent (althans, dat is wat veel slimmere mensen dan ik erover gezegd hebben).
En ja hoor… daar hebben we Amsterdam weer…
Of zou daar nu juist het probleem zitten? Is er wel “een Amsterdam”. Kijk naar alle gerelateerde artikelen en je zult zien dat er telkens sprake is van “diensten en stadsdelen” versus “centrale ICT”.
Zolang er decentraal te veel kan worden beslist door de budget houders (wie het geld heeft…) en er geen overall programma en architectuur voor een shared service center met een volwassen demand/supply keten is, zullen we nog veel van dit soort artikelen langs zien komen.
Wellicht hebben sommigen hier baat bij…
Ja Opmerkelijk, daar hebben mensen baat bij. Leveranciers die wegkomen met netwerken onbeveiligd afleveren, en niet zo professioneel zijn dat ze benadrukken dat het netwerk beveiligd moet zijn. En nu komt er zo’n megaproject van de centrale ICT afdeling waar uiteindelijk niemand tevreden mee zal zijn. In een organisatie waar centraal nou eenmaal niet werkt (je kunt lang wachten Peter tot managers iets uit gaan dragen) kun je bevoegdheid tot aanbesteding, leverancierkeuze etc. best decentraal neerleggen, maar moet je de kwaliteit borgen door kwaliteitscriteria in de vorm van protocollen (die door centraal en decentraal samen binnen een architectuur zijn ontwikkeld) dwingend op te leggen. In dit geval bijvoorbeeld: WPA2, Radius, PEAP et cetera.
De situatie m.b.t. het netwerk zoals hier is beschreven, is een typisch voorbeeld hoe de gemeente Amsterdam structureel geld over de balk gooit. Als je in 20011 een houtje-touwtje netwerk hebt, dat gebaseerd is op een begin jaren 90 concept, dan verlies je het overzicht, krijg je veel storingen, wordt de oplostijd langer, heb je vaak te weinig bandbreedte, zijn er onnodig beveiligingsrisico’s en kost het beheer veel te veel.
Om dit probleem snel op te lossen zou ik het netwerk als dienst op concernniveau uitbesteden. Je kan wel eerst vele componenten gaan vervangen of gaan herconfigureren, de organisatie aanpakken door onder andere alle incompetente managers (ca 80%) en projectleiders (ca 50%) te vervangen, medewerkers netwerkbeheer-cursussen laten volgen, et cetera, maar dat gaat te lang duren. Dat had de betrokken organisaties ook al lang zelf kunnen regelen, maar die wilden dat niet vanuit hun toko-denken. Ze praten interessant mee over architectuur, beveiligingsbeleid, samenwerking, maar ze willen er weinig mee doen.
Bij het uitbesteden dient men uiteraard wel uit de buurt blijven van al die grote detacheringbureaus die de genoemde incompetentie jarenlang hebben misbruikt met hun uurtje-factuurtje mentaliteit. Ook moet het uitbestedingproject vanuit gemeente geleid worden door mensen die in de praktijk hebben aangetoond dit te kunnen. Anders krijg je weer zo’n ambitieus Amsterdams project dat nooit afkomt en al gauw het drievoudige gaat kosten.
Computable, ga door met deze onthullingen. Jullie kunnen er een dossier Amsterdam van maken.