ICT-scan voor je infrastructuur: hoe pak je dat aan?

In het artikel APK voor je ICT-Infra ben ik al ingegaan op de noodzaak om af en toe een thermometer in je ICT-omgeving te houden. Ik heb beschreven dat er in elke ICT-omgeving momenten zijn geweest waarbij iets opgelost is met een ‘digital duct tape’. Daarnaast hebben de organisatie en de maatschappij niet stil gestaan. Dit alles leidt ertoe dat een doorsnee ICT-omgeving niet meer voldoet. Een ‘APK’ of ICT-scan kan hierin inzicht geven, maar hoe pak je dat aan? In dit artikel leg ik uit hoe en geef handvatten om zelf een ICT-scan uit te voeren.

Een ICT-scan bestaat uit 3 onderdelen:

1) Administratief, hoe is de administratie rondom de infrastructuur geregeld?
2) Functioneel, sluit de infrastructuur functioneel nog aan bij de behoefte van de organisatie?
3) Technisch, werken de ICT-componenten technisch nog goed?

Het is niet altijd mogelijk een harde scheidslijn te hanteren, maar voordat ik daarop inga is het goed om de 3 onderdelen duidelijk te beschrijven.

Administratief

Onder administratie vallen diverse zaken. High-level kun je kijken naar de diverse processen: hoe wordt een change uitgevoerd, wat gebeurt er bij een incident, welke stappen worden er gezet bij een nieuwe medewerker? Je inventariseert dan welke processen er zijn en houdt deze aan tegen bijvoorbeeld ITIL, MOF of ASL/BISL processen. Wordt er gebruik gemaakt van een van deze standaarden of een afgeleide daarvan? Of zie je juist dat er maar ‘iets’ gedaan wordt? Dit geeft inzicht in de volwassenheid van de organisatie en haar ICT-processen.

Ook als de processen beschreven zijn, zegt dit nog niet dat ze ook daadwerkelijk worden uitgevoerd. Je kunt dit eenvoudig controleren door te kijken naar bijvoorbeeld ‘ghost accounts’, gebruikersaccounts van medewerkers die niet meer in dienst zijn. Als de processen goed zijn ingericht en worden opgevolgd, kom je nauwelijks ghost accounts tegen. Zijn de processen er wel, maar vind je veel ghost accounts (meer dan 10% van het totaalaantal accounts), dan zou dit een  teken kunnen zijn dat het proces niet wordt opgevolgd.

Een andere indicator is in hoeverre de omgeving gestandaardiseerd is. Een omgeving waar ICT-objecten volgens een strak schema hun namen krijgen wijst op een goede administratie. Servers die allemaal op dezelfde manier worden geïnstalleerd wijzen op een gestandaardiseerde omgeving.

Het goed beheren van je ICT-omgeving met duidelijk omschreven processen zorgt ervoor dat het helder is wie wat mag, welke objecten er zijn en wie bij welke informatie mag. Een administratief gezonde ICT-omgeving zorgt voor inzicht. Dit inzicht wordt nog belangrijker bij bijvoorbeeld een ISO 270001 certificering, dan moet aangetoond kunnen worden wie welke bevoegdheden heeft.

Administratief gezond zegt niets over de technische of functionele staat van de omgeving. Wel geldt dat als de administratie niet goed geregeld is, dit zijn weerslag kan hebben op de technische staat van ICT-componenten. Goede administratie van een ICT-omgeving is niet alleen zaak van de ICT-afdeling, maar van een gehele organisatie.

Functioneel

Een ICT-infra wordt geïmplementeerd om de organisatie een aantal digitale functies te bieden, die gebruikers nodig hebben om hun werk optimaal uit te voeren. Deze functies worden bepaald op basis van de behoefte van de organisatie. Deze behoefte is echter geen constante factor, maar verandert naar aanleiding van maatschappelijke en bedrijfskundige ontwikkelingen. De ICT dient mee te groeien met deze veranderingen.

Nu is het bepalen van functioneel gezond niet zo makkelijk als technisch en administratief. Zo zijn bijvoorbeeld cloud en de bijbehorende functionaliteiten ‘hot’, tenminste als we de media moeten geloven, maar moet je het dan per se ook willen? Een bedrijf dat niet naar de cloud gaat is niet per definitie functioneel ongezond. Er kunnen hele goede redenen zijn om niet naar de cloud te gaan.

Wanneer is dan sprake van functioneel ongezond? Een bekend voorbeeld hiervan is de wens van gebruikers om remote toegang te hebben tot kantoor via een VPN-verbinding. Als de techniek dit niet toelaat, zullen gebruikers data, die ze toch nodig hebben, op een onbeveiligde USB-stick mee gaan nemen. In zo’n situatie spreken we van een functioneel ongezonde ICT-omgeving. In dit geval komt het “ongezond zijn” door een security risico voor de organisatie.

Functionele gezondheid bepaal je door vast te stellen wat de behoeften zijn van de organisatie. Dit kun je heel uitgebreid doen door een compleet gebruikersbehoeften onderzoek te houden, waarbij alle gebruikers geïnterviewd worden. Maar je kunt ook al een beeld vormen door te praten met een aantal kerngebruikers.

Functioneel gezond zegt niets over de technische staat van een ICT-component of de administratie van de ICT-omgeving. Wel zegt het iets over de gewenste beschikbaarheid en beveiligingsniveau. Zo is hoge beschikbaarheid een functionele behoefte van een organisatie, die ondersteund dient te worden door de ICT-infra. Een organisatie met hele oude soft- en hardware kan functioneel gezond zijn en een organisatie met het nieuwste van het nieuwste kan functioneel ongezond zijn.

Technisch

De ICT-infra bestaat voornamelijk uit technische componenten, zoals servers, routers, firewalls, enz. Voor de technische gezondheid kijk je naar de logfiles. Staan er veel warnings of errors in en wat voor meldingen zijn het? Hoe is een server ingericht, zijn hierbij de richtlijnen van een leverancier gevolgd of niet? Hoe vaak zijn er issues met een component? Zijn componenten volgens een standaard ingericht of is elk onderdeel anders. Een standaardinrichting heeft raakvlakken met de administratieve gezondheid van een ICT-omgeving. Je kunt dus een standaard op papier hebben, die niet in de praktijk wordt opgevolgd.

Kijk ook naar de update status. Zijn de laatste updates aanwezig? Vooral de security updates zijn van groot belang. In het verlengde hiervan ligt support en/of end-of-life (EOL). Op het moment dat een product EOL is, zal een leverancier geen update meer aanleveren. Dit betekent dat belangrijke zero days exploits niet gedicht worden en het ICT-component risico loopt.

Een ICT-component kan functioneel gezond zijn, maar technisch te oud.

Scope van een ICT-scan

In een ICT-scan zijn veel aspecten te bekijken, het is dus ook van belang dat je van tevoren een duidelijke scope opstelt. De scope wordt gedefinieerd door de antwoorden op de volgende vragen:

1) Wat is je doelstelling? Welke vraag wil je gaan beantwoorden?
2) Welk onderdelen ga je meenemen? Administratief, functioneel of technisch?
3) Welke ICT-componenten neem je mee? Alles, alleen de Windows servers of kijk je alleen naar het netwerk?

De eerste vraag is het belangrijkste, wat wil je bereiken? Ter illustratie wat voorbeelden:

Je gaat het beheer overnemen van een andere partij. Dan wil je weten waar je straks verantwoordelijk voor bent. Je kijkt dan vooral hoe de omgeving erbij staat, welke interfaces er zijn, en of je de verantwoording kunt/wilt nemen. Hierbij zal de technische staat het belangrijkste zijn, maar je zult ook zeker kijken naar zaken als administratief en functioneel.

Je wilt graag weten wat de algemene status is van je ICT-omgeving. Voldoet deze nog aan de huidige standaarden en werkt alles nog naar behoren? In dat geval zal je in de eerste plaats kijken naar de technische en administratieve status.

Je wilt het ICT-budget vaststellen voor de aankomende 2 jaar. Je zult dan in de eerste plaats kijken naar de functionele status, voldoet deze nog aan de wensen van de organisatie? Bij de technische status kijk je vooral of deze goed genoeg is voor de eventuele changes die nodig zijn. Op basis daarvan kun je dan kijken waar je naar toe wilt en een roadmap gaan opstellen.

Risicoanalyse

Bij de eerste twee voorbeelden zal een risicoanalyse helpen om een beeld te geven van zowel de status van de complete ICT-omgeving als de individuele ICT-componenten.  Het uitvoeren van een risicoanalyse kun je zo complex of eenvoudig maken als je maar wilt. Het idee achter de risicoanalyse is dat je per onderdeel het risico op uitval bepaalt.

Voordat je begint, definieer je een minimale en maximale waarde die je toekent aan een risico. De waarde wordt dan bepaald door de kans op uitval plus de impact daarvan op de organisatie. Risico 0 bestaat niet, er is altijd een risico, het zogenaamd restrisico, wat je zult moeten accepteren. Je kunt wel bepalen tot welke waarde de risico’s acceptabel zijn en vanaf welke waarde actie ondernomen moet worden. Hoe groter het risico, hoe belangrijker het is dat er iets aan gedaan wordt. Daarbij kunnen de volgende zaken meegenomen worden:

  • Is het systeem enkel of dubbel uitgevoerd? Een enkelvoudig systeem heeft meer kansen om volledig te falen dan een dubbel uitgevoerd systeem.
  • Hoe belangrijk is het systeem voor de organisatie? Belangrijke systemen zullen een hogere impact hebben op de kernprocessen van een organisatie.
  • De technisch en administratieve status van het systeem. Hoe beter deze is, hoe kleiner de kans dat er iets gebeurt met het systeem.
  • De locatie van het systeem, kan het systeem direct vanaf het internet bereikt worden? Dit beïnvloedt de kans dat het systeem gehackt wordt.
  • Kennis en kunde van de beheerders. Beheerders die kundig zijn zullen een systeem beter beheren.
  • Zijn de patches en wachtwoorden up-to-date?

Security

In dit artikel heb ik security als apart onderwerp buiten beschouwing gelaten. Dat is ook logisch, aangezien security altijd een integraal onderdeel is van de ICT-scan. Risico’s en de security status van een product hangen nauw met elkaar samen. Je kunt ervoor kiezen om een ICT-scan uit te voeren voor alleen de security risico’s. Hierbij kijk je vooral welke risico’s een systeem loopt op basis van het security profiel.

Samenvatting

Een ICT-scan geeft inzicht in jouw ICT-infrastructuur, wat loopt goed en wat minder goed. Ook kun je een ICT-scan gebruiken om je budget voor een aankomende periode te bepalen. Het uitvoeren van een ICT-scan vereist wel dat je helder heb wat je ermee wilt bereiken en hoe je gaat meten. Dit helpt om later te bepalen wat de vervolgactiviteiten zijn.

Martijn Bellaard heeft 3 jaar als lead architect bij TriOpSys gewerkt. Begin 2017 heeft hij zijn grote droom gevolgd en is hij docent aan de Hogeschool van Utrecht geworden. Dit artikel is gepubliceerd op 29-01-2015.

Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this page