Digitale beveiliging van industrial control systems

Industrial control systems besturen installaties en apparaten in de fysieke wereld. Vitale maatschappelijke functies zoals de energie- en drinkwatervoorziening, waterwerken en de verkeersinfrastructuur zijn afhankelijk van de goede werking ervan. En ook veel andere organisaties kunnen niet zonder goed functionerende industrial control systems. Denk bijvoorbeeld aan besturing van productieprocessen, toegangsbeveiliging en signaleringssystemen. Volgens het Nationaal Cyber Security Centrum ondernemen veel organisaties onvoldoende actie ter beveiliging van dergelijke systemen. Hoog tijd dus om ons als –
IT-auditors op dit terrein te oriënteren.

Een Australiër is veroordeeld tot twee jaar cel omdat hij ingebroken had op de computersystemen van de riolering in Maroochy Shire, Australië. Door de systemen te manipuleren heeft hij er voor gezorgd dat honderdduizenden liters vervuild rioolwater in de omgeving werd geloosd, waardoor grote stukken land en rivieren werden vervuild en talloze dieren overleden. De hack was een wraakactie en kon plaatsvinden omdat de man de computersystemen van zijn voormalig werkgever eenvoudig kon binnendringen: de wachtwoorden waren niet gewijzigd [TWEA12a].

In 2012 heeft de Tweede Kamer vragen gesteld aan de minister van Binnenlandse Zaken en de minister van Veiligheid en Justitie over het beveiligingsniveau en de beveiligingsrisico’s van die industrial control systems, ook wel SCADA-systemen of ICS genoemd, waarvoor de Nederlandse overheid verantwoordelijk is [TWEA12b]. Deze vragen bleken niet ongegrond: kort daarna toonde het actualiteitenprogramma EenVandaag aan dat het mogelijk was in te breken in de SCADA-systemen van een gemaal in de gemeente Veerle [EENV12].

In haar analyse van de cyberdreigingen voor Nederland voor 2012 liet GOVCERT.NL, nu Nationaal Cyber Security Centrum [NCSC], nog weten dat gerichte verstoring van industriële beheersystemen ‘niet waarschijnlijk’ was [GOVC11]. De redenering was dat het bouwen van een virus zoals Stuxnet, dat is gebruikt voor een aanval op Iraanse uraniumverrijkingsinstallaties, diepgaande kennis vereist van het systeem dat moet worden gekraakt.

Het NCSC is in de Cybersecuritybeelden Nederland van 2012 en 2013 teruggekomen op haar eerdere geruststellende uitspraak en is meer aandacht gaan besteden aan de beveiligingsproblematiek rondom ICS. Het NCSC geeft zelfs het volgende aan in het derde Cybersecuritybeeld Nederland [NCSC13]: ‘Hoewel grote incidenten zijn uitgebleven, is de dreiging onverminderd groot. De huidige beveiligingsstatus van ICS verslechtert steeds meer, maar dit gaat geleidelijk waardoor besef over het ernstiger worden van de situatie uitblijft en veel organisaties onvoldoende actie ondernemen.’

Het Maroochy Shire-incident laat zien dat geavanceerde software zoals Stuxnet geen vereiste is om een aanval op infrastructuur te laten slagen. Uit een recente ICS-CERT monitor [NCCI14] blijkt dat veel ICS toegankelijk zijn via internet. Een grote dreiging daarbij is dat ICS vaak niet of onvoldoende zijn beveiligd en eenvoudig vindbaar zijn via gespecialiseerde zoekmachines als SHODAN-HQ. Daar komt bij dat er steeds meer kennis en informatie over ICS vrij beschikbaar is. Hierdoor is het vereiste kennisniveau om aan het Internet gekoppelde ICS te vinden en te manipuleren sterk verlaagd.

De voorgaande berichten wekten onze interesse in de beveiliging van ICS. Omdat dit onderwerp niet aan de orde was gekomen in onze IT-audit opleiding hebben we besloten deze materie te gaan verkennen en ons referaat over dit onderwerp te schrijven. We hebben ons gericht op de beveiligingsproblematiek rondom ICS en de (mogelijke) rol van IT-auditing. In dit artikel, gebaseerd op ons referaat, willen we inzicht verschaffen in wat ICS zijn en wat de beveiligingsproblematiek rondom deze systemen inhoudt.

 Wat zijn ICS?

Er zijn een aantal min of meer overlappende aanduidingen voor computer-gebaseerde toezicht- en controlesystemen. Wij gebruiken de benaming industrial control systems (ICS; in het Nederlands vertaald als industriële beheersingssystemen), maar dergelijke systemen worden ook wel aangeduid als SCADA-systemen (Supervisory, Control and Data Acquisition), process control systemen, industriële informatie-en controlesystemen, proces IT, gedistribueerde controlsystemen, om de belangrijkste benamingen te noemen.

ICS worden gebruikt om industriële systemen en processen te beheren en aan te sturen. ICS zijn daarnaast vaak bronsystemen voor data die intern en extern wordt gebruikt. Deze data is dikwijls afkomstig uit het bedrijfsnetwerk, dat op zijn beurt gevoed wordt door het control network, al dan niet verrijkt met gegevens uit het publieke domein. ICS zijn essentieel voor de goede werking van vitale infrastructuren die vaak in een hoge mate met elkaar zijn verbonden en wederzijds van elkaar afhankelijk zijn. Tegenwoordig zijn vitale maatschappelijke functies afhankelijk van ICS. Voorbeelden zijn de distributie van elektriciteit en drinkwater, en functies zoals stadsverwarming en spoorverkeer.

Het belang van beveiligings-bewustzijn wordt onderschat door de organisatie.

Het spreekt voor zich dat het praktischer is om dergelijke systemen op afstand te beheren, dan dit op locatie via fysieke hendels en knoppen te doen. Sommige van dergelijke systemen kunnen alleen worden gebruikt om informatie af te lezen. Andere systemen kunnen ook voor daadwerkelijke beheertaken worden gebruikt, zoals het aanpassen van pompsnelheden of openzetten van kleppen. Figuur 1 geeft een voorbeeld van een interface dat de operator in staat stelt daadwerkelijk in real-time parameters van kleppen, pompen en andere componenten op afstand aan te passen. Een berucht voorbeeld uit de praktijk is dat van de frequentieregelaars voor de ultracentrifuges in Iraanse uraniumverrijkingsfabrieken, die werden ontregeld door het Stuxnet-virus.

Kenmerken van ICS

ICS vertoonden aanvankelijk weinig gelijkenis met reguliere IT-systemen voor kantooromgevingen [NIST12]. Het waren geïsoleerde systemen en netwerken met eigen protocollen die draaiden op gespecialiseerde hard- en software. Hierdoor waren ICS aanvankelijk enkel vatbaar voor lokale bedreigingen. Tegenwoordig worden voor ICS echter vaak standaard IT-oplossingen gekozen voor connectiviteit met andere systemen en voor externe toegang en is er steeds meer integratie van ICS in IT-netwerken. Deze integratie biedt nieuwe mogelijkheden, maar hierdoor zijn ICS minder geïsoleerd van de buitenwereld. Het dreigingsprofiel is dus vergroot en daarmee de kans op cybersecurity-aanvallen en incidenten, vaak zonder dat organisaties zich hiervan bewust zijn.

Hoewel sommige kenmerken van ICS en reguliere IT-systemen overeenkomen, zijn er ook kenmerken die meer of minder verschillen. Deze verschillen vloeien onder meer voort uit het feit dat logica uitgevoerd in ICS een direct effect kan hebben op de fysieke wereld. In tabel 1 staan de belangrijkste verschillen tussen reguliere IT-systemen en ICS.

Digitale bedreigingen

Doordat ICS-netwerken zijn geëvolueerd van losstaande eilanden tot netwerken die verbonden zijn hebben ze te maken met vergelijkbare soorten bedreigingen als de reguliere netwerken. Wij beschrijven hier de belangrijkste digitale bedreigingen voor ICS, waarbij we opmerken dat niet alle genoemde bedreigingen specifiek alleen voor ICS gelden; sommige gelden ook voor kantoor-IT-systemen. De bedreigingen ordenen we aan de hand van de volgende drie aspecten:

• tijd, een aspect dat betrekking heeft op onder meer de lange levenscyclus van ICS en de zeer hoge beschikbaarheidseisen;
• bewustzijn, in hoeverre zijn organisaties zich bewust van de mogelijke bedreigingen waaraan hun ICS blootstaan;
• netwerk, hierbij valt te denken aan alle bedreigingen die zich kunnen voordoen als gevolg van koppeling van het ICS netwerk met internet of met bedrijfsnetwerken.

Hierna beschrijven we per aspect de bijbehorende bedreigingen. De fysieke bedreigingen en maatregelen worden buiten beschouwing gelaten, omdat ze voor ICS veel omvangrijker zijn dan voor reguliere IT-systemen en de kennis hiervan buiten de expertise van de gemiddelde IT-auditor valt.

Tijd

De levenscyclus van ICS is vaak erg lang, dit kan variëren van 15 tot wel 30 jaar of langer. Door deze lange levenscyclus draaien ICS vaak op verouderde firmware of besturingssystemen. Dit beveiligingsprobleem wordt verergerd door de achterhaalde aanname van organisaties dat ICS geïsoleerd zijn en door gebrek aan goede patch managementprocedures [DEPA08], [DEPA09].

Gezien de hoge prestatie- en beschikbaarheidseisen voor ICS vormt patch management een grote uitdaging. Beheerders van ICS zullen zeer voorzichtig zijn bij het patchen van hun systemen, omdat dit een aanzienlijke hoeveelheid testen inhoudt, terwijl op hetzelfde moment de beschikbaarheid en veiligheid van het systeem gevaar lopen. Het testproces wordt vaak bemoeilijkt doordat er geen testomgeving is om de invloed van patches adequaat te testen. In de praktijk is het vaak slechts eenmaal per jaar mogelijk om een ICS te patchen op een ver vooraf bepaald moment. Sommige moderne apparaten kunnen op afstand en automatisch worden geüpdatet. Maar in veel gevallen moet legacy hardware van ICS via een fysieke aansluiting geüpdatet worden of soms helemaal worden vervangen. De uitdagingen rondom patch management leiden ertoe dat veel ICS niet zijn voorzien van de laatste updates en patches, waardoor deze ICS vaak voor langere tijd kwetsbaar zijn voor aanvallen.

Verder is er een gebrek aan specifieke beveiligingstechnologie voor ICS terwijl voor standaard IT-omgevingen veel beveiligingsproducten en ondersteuning door diverse leveranciers beschikbaar zijn [DEPA09], [PETE08]. Standaard beveiligingsproducten kunnen wel worden aangepast voor gebruik in ICS omgevingen, maar dit is vaak kostbaar, complex en eist veel commitment van leveranciers, die beperkte kennis van ICS-netwerken hebben. Ook ontberen de legacy-systemen, die soms al tientallen jaren operationeel zijn, vaak de benodigde beveiligingsfunctionaliteiten waardoor het lastig is ze goed te beveiligen. Daarnaast kan beveiligingsfunctionaliteit op gespannen voet staan met het real-time karakter en de zeer hoge beschikbaarheidseisen van ICS. Beveiligingsfunctionaliteit gebruikt resources, waardoor mogelijk vertraging optreedt in de verwerking van informatie. Hierdoor kan de veiligheid in het geding komen.

Bewustzijn

Beveiliging wordt ‘van oudsher’ gezien als issue voor de zakelijke IT-omgeving en niet voor de ICS-omgeving, omdat deze geen koppeling had met internet. In ICS-omgevingen zijn ICS-medewerkers vaak onbekend met IT-beveiliging en zijn IT-beveiligingsmedewerkers vaak onbekend met ICS. Dit komt omdat er geen (financiële) middelen voor zijn of het belang van beveiligingsbewustzijn wordt onderschat door de organisatie. Dit, terwijl personeel de belangrijkste resource is en tegelijkertijd potentieel ook de grootste bedreiging voor beveiliging [CPNI11]. Daar komt bij dat organisaties ervan uitgaan dat bestaande beveiligingstools en -technieken niet werken in ICS-omgevingen, wat er toe leidt dat ICS vaak niet adequaat zijn beveiligd [CPNI11], [DEPA09].

Het gebrek aan bewustzijn leidt er ook toe dat organisaties vaak geen specifieke beveiligingsprocedures voor ICS hebben. Door de integratie en groeiende complexiteit van ICS- netwerken is het aantal personeelsleden dat toegang heeft tot ICS-netwerken toegenomen. Daarnaast hebben externe leveranciers steeds vaker remote toegang tot de ICS-netwerkomgeving. Zelfs met procedures voor remote beheer ontbreekt vaak de mogelijkheid voor logging of andere auditmaatregelen.

De IT-auditor kan niet om deze ICS heen.

Sommige ICS hebben zeer oude programmacode die op maat gemaakt was of niet meer wordt ondersteund door een leverancier. De programmacode kan om meerdere redenen onveilig zijn, bijvoorbeeld doordat deze is ontwikkeld door personeel met beperkte kennis van veilige programmeerstandaarden. Maatwerk is vaak niet op kwetsbaarheden getest, is gebrekkig gedocumenteerd of bevat geen uitleg in de programmacode. Veelvoorkomende programmeerfouten zoals buffer overflows, het ontbreken van invoervalidatie en het gebrek aan authenticatie of encryptie maken maatwerk kwetsbaar [DEPA09].

Netwerk

Zoals video 1 laat zien, zijn netwerken steeds vaker onderling verbonden en worden er gezamenlijke protocollen en besturingssystemen gebruikt binnen zowel het bedrijfsnetwerk als het ICS-netwerk. In ICS-omgevingen wordt de communicatie tussen systemen vaak nauwelijks beveiligd en wordt ook weinig rekening gehouden met bedreigingen die vanaf gekoppelde netwerken kunnen komen. Dit leidt tot een groot scala aan netwerkgerelateerde bedreigingen voor ICS, zoals achterdeuren in de netwerkperimeter, SQL-injecties en man-in-the-middle aanvallen.

Een ICS kan meerdere koppelvlakken hebben met andere netwerken zoals internet en interne bedrijfsnetwerken. Deze koppelvlakken bieden geautoriseerde medewerkers toegang tot de ICS-netwerken, maar kwetsbare of onjuist geconfigureerde koppelvlakken kunnen kwaadwillenden toegang tot het ICS-netwerk geven. Koppelingen tussen netwerken zijn een interessant doelwit voor hackers omdat toegang hiertoe hen in staat stelt de vertrouwensrelatie die tussen de netwerken bestaat te misbruiken [DEPA09]. Daarnaast bieden de bij ICS-netwerken vaak nog aanwezige inbelvoorzieningen directe toegang tot een of meerdere ICS-componenten. Het toegangspad voor een aanvaller om via de inbelvoorziening toegang te krijgen tot het ICS is korter en vaak minder goed beveiligd dan via internet [DAVI08].

Door de adoptie van veel gebruikte netwerktechnologieën (bijvoorbeeld TCP/IP) in ICS wordt tevens het hele scala van bijbehorende beveiligingsproblemen in huis gehaald. De convergentie van ICS-netwerken met bedrijfsnetwerken biedt hiermee een nieuwe omgeving voor aanvallers om kwetsbaarheden in veel gebruikte standaarden te misbruiken. In het bijzonder zijn analyse en manipulatie van het netwerkverkeer via een man-in-the-middle aanval de grote bedreigingen voor ICS. Hiermee kan een aanvaller ongeautoriseerd bepaalde activiteiten in een ICS starten en stoppen en zelfs alarmering onderdrukken of voorkomen.

SQL-injectie in een database met waardevolle gegevens kan verstrekkende gevolgen hebben, vooral in een ICS-omgeving, waar nauwkeurigheid van de gegevens en integriteit cruciaal zijn voor zakelijke en operationele besluitvorming. Wanneer databases van ICS zijn aangesloten op zakelijke of financiële databases of computers met toepassingen die toegang tot dergelijke gegevens hebben, kunnen aanvallers gebruikmaken van het communicatiekanaal tussen beide netwerken. Zodoende worden beveiligingsmechanismen omzeild die het ICS-netwerk moeten beschermen [DEPA09].

Beveiligingsmaatregelen

We beschrijven de belangrijkste beveiligingsmaatregelen rondom ICS, waarbij we opmerken dat deze niet uniek zijn voor het ICS-domein. Wel zit er verschil tussen de toepassing van de maatregelen binnen ICS en reguliere IT.

Organisatorische beveiligingsmaatregelen ICS

Een van de architectuurprincipes voor het beschermen van kritische systemen is te zorgen voor een beveiliging die uit meerdere lagen bestaat, het zogenaamde defense-in-depth principe. Dit houdt in dat maatregelen worden getroffen op meerdere niveaus in de organisatie en infrastructuur. Deze maatregelen dragen gezamenlijk bij aan de beveiliging van een ICS en kunnen op verschillende lagen worden gerealiseerd, zoals de operationele laag, netwerklaag en host-laag. In figuur 2 is weergegeven hoe de verschillende lagen tegen, bijvoorbeeld, een buffer overflow kwetsbaarheid beschermen.

Patch management

Gedurende de levensloop van ICS hebben vooral de stabiliteit en beschikbaarheid de meeste aandacht van de beheerafdeling en de systeemeigenaar. In de afgelopen jaren hebben veel leveranciers van ICS patches voor hun producten uitgebracht om beveiliging toe te voegen of te verbeteren. Ongeplande downtime van een ICS kan ernstige operationele gevolgen hebben. Daarom zijn strenge eisen nodig voor het testen en valideren van patches voordat deze in productie genomen kunnen worden. Patchen van ICS is vaak lastig vanwege:

• hoge uptime van ICS (24×7 met 99,999% beschikbaarheid, wat ongeveer 5 minuten downtime per jaar betekent);
• complexe samenhang tussen veel componenten op verschillende locaties.

Iedere patch moet zo goed mogelijk worden getest voordat deze in de productieomgeving mag worden uitgerold. Als er geen testomgeving is, kan gebruikt worden gemaakt van de redundantie door eerst de patch uit te rollen op componenten die stand-by staan. Nadat de juiste configuratie daarvan is ingesteld vinden tests plaats en na acceptatie wordt de stand-by-component in de productieomgeving omgezet. Op de niet geüpdate component die nu als stand-by dient, kan worden teruggevallen in noodsituaties.

Nauwe samenwerking met de leverancier van het ICS is van belang bij het hardenen en upgraden van software- en hardware componenten. Hardening van ICS is complex en kan zonder samenwerking met de leverancier onder meer leiden tot verstoring en instabiliteit [MSB10, p. 13].

Beveiligingsbeleid en beveiligingsbewustzijn

Een generiek beveiligingsbeleid voor bedrijfsnetwerken kan ook worden toegepast op ICS met aanvullende ICS-specifieke beveiligingseisen. Voorbeeld hiervan is de verzameling cyber security requirements for electric systems van NERC (Northern American Electronic Reliability Council). Het beveiligingsbeleid is afgeleid van de bedrijfsdoelstellingen en is gebaseerd op risicoanalyses. Voor het opstellen van beveiligingsbeleid voor SCADA-systemen hebben Kilman en Stamp [KILM05] een framework ontwikkeld dat onder meer de volgende beveiligingsonderwerpen bevat: overkoepelende beveiligingsrisico’s, informatiebeveiliging, platformen, communicatie personeel, configuratie-management, auditing, applicaties, fysieke beveiliging en handmatige handelingen.

ICS-beheerders hebben veelal weinig training in en ervaring met de beveiligingsaspecten. Dit komt vaak doordat er geen (financiële) middelen voor zijn of het belang van beveiligingsbewustzijn wordt onderschat. Opleiding is een belangrijk onderdeel van een overkoepelend bedrijfsbreed beveiligingsbeleid dat nodig is voor de bescherming van belangrijke informatie en informatiebronnen [DEPA09], [KUIP06].

Beveiligingsopleiding en een specifiek beveiligingsbewustzijnprogramma voor het ICS-domein is van belang voor de beveiliging van ICS. Beveiligingsbewustzijn voor ICS draagt bij aan een continue en meetbare beveiligingsstatus [TEN08]. Het opleidingsprogramma voor beveiligingsbewustzijn dient periodiek te worden gegeven en afgestemd te zijn op de rol van de medewerkers, bijvoorbeeld bestuur, operationeel of technisch. Formele opleidingen zijn preventief van karakter en kunnen kosten in de toekomst voorkomen en medewerkers bewust maken van risico’s als social engineering [NIST03].

Incident response

Om te kunnen reageren op beveiligingsincidenten dient er een incident response capability ontwikkeld te zijn. Het moet duidelijk zijn hoe een beveiligingsincident wordt gesignaleerd, hoe erop wordt gereageerd, hoe de gevolgen worden gemitigeerd en hoe de dienstverlening wordt hervat. Een incident response procedure instrueert medewerkers welke stappen of procedures ze moeten volgen als het ICS netwerk of een component daarvan wordt gecompromitteerd. Iedere medewerker moet opgeleid zijn en toegang hebben gekregen tot de procedures. Daar moet niet mee worden gewacht tot er een incident optreedt.

Beveiligingsonderzoeken

Door het uitvoeren van periodieke beveiligingsonderzoeken en -audits ontstaat een betrouwbaar beeld van de feitelijke beveiliging. Binnen ICS heeft een groot deel van de gebruikte componenten weinig beveiligingsfunctionaliteiten. Door triviale programmeerfouten kan de werking van deze componenten al bij een scan of aanval worden verstoord. Het gebruik van geautomatiseerde beveiligingstesten wordt afgeraden, omdat ICS zeer gespecialiseerde omgevingen zijn die specifieke kennis vereisen van de onderzoeker. Voor het uitvoeren van een beveiligingsonderzoek moet zoveel mogelijk de productieomgeving worden ontzien en gebruikgemaakt van eventuele test- of acceptatieomgevingen. Van iedere mogelijke verstoring die door het beveiligingsonderzoek zou kunnen optreden, moet van te voren worden bekeken hoe deze het best te voorkomen is en hoe een verstoring verholpen kan worden mocht deze onverhoopt toch optreden [MSB10].

Technische beveiligingsmaatregelen ICS

Netwerkbeveiliging

Bij de netwerkarchitectuur is het goed om verschillende zones te definiëren. De zone met daarin het ICS dient gescheiden te zijn van de andere netwerkzones in het bedrijfsnetwerk. Minimaal zijn er vier netwerkzones te onderscheiden voor ICS, namelijk: een zone met externe netwerkconnectiviteit, een zone met het bedrijfsnetwerk (bijvoorbeeld ERP-systemen), een ICS- beheerzone en ICS-operationele zones. Netwerkbeheerders dienen te zorgen dat de netwerkdiagrammen met daarop de verbindingen tussen netwerkzones, DMZs en subnets up-to-date zijn en blijven.

Oudere ICS zijn vaak ontwikkeld in de tijd dat control netwerken fysiek van bedrijfsnetwerken waren gescheiden en logische toegangsbeveiliging voor ICS onbekend was. Tegenwoordig zorgen firewalls en routers voor segmentering tussen de netwerkzones. Al het netwerkverkeer tussen netwerkzones dient zonder uitzondering via firewalls te verlopen. Firewalls kunnen netwerkverkeer filteren (packet filter firewalls) op basis van vooraf gedefinieerde regels die bepalen welke netwerkprotocollen tussen verschillende netwerken zijn toegestaan. Zo kan worden gezorgd dat specifieke netwerkcomponenten alleen met elkaar kunnen communiceren via een vooraf gedefinieerde combinatie van protocol en netwerkpoort. Een firewall voorkomt dat het ICS direct vanaf willekeurige componenten in andere netwerkzones benaderbaar is.

Verschillende typen firewalls kunnen meerlaagsbeveiliging creëren voor ICS. Proxy Gateway Firewalls (PGF) kunnen worden ingezet om de netwerkcomponent die zij beschermen te verbergen. Voorwaarde is dat de PGF specifieke kennis heeft van de achterliggende componenten of applicatie(s). De PGF is minder snel dan een firewall die uitsluitend op netwerkniveau filtert, maar is zeer geschikt om ICS-netwerkzones te beschermen [KUIP06]. PLC-/veldniveau-firewalls zijn op hardware gebaseerd en worden direct op veldniveau aangesloten. Het effect van deze firewalls kan aanzienlijk zijn bij het beschermen van apparaten die geen ingebouwde beveiligingsmogelijkheden hebben [DEPA09].

Er zijn verschillende manieren om het netwerk te monitoren op ongebruikelijke en ongeautoriseerde netwerkactiviteit. Intrusion Detection Systems (IDS) zijn een verzameling van technieken (tools) en processen die netwerkbeheerders in staat stellen inzicht te krijgen hoe het netwerk wordt gebruikt. IDS is een passieve beveiligingsmaatregel die het netwerkverkeer en netwerkactiviteit beoordeelt zonder het te beperken. Dit gebeurt op basis van vooraf gedefinieerde of specifieke maatwerkregels (signature based), op basis van gedrag (heuristic based) en op basis van bekende signaturen van bekende kwaadaardige software. Voor control netwerken is de beschikbaarheid van adequate signaturen tegen kwaadaardig netwerkverkeer minder vanzelfsprekend. Wel worden steeds meer signaturen specifiek ontwikkeld voor ICS en zorgen leveranciers dat er oplossingen komen voor hun specifieke producten. IDS hebben steeds vaker de mogelijkheid om van het netwerkverkeer te ‘leren’ en zodoende afwijkingen te signaleren [DEPA09].

Bij het implementeren van IDS in control netwerken is het van belang te zorgen dat de gebruikte signaturen de specifieke dreigingen voor het netwerk ook daadwerkelijk kunnen herkennen. Het is belangrijk dat na de implementatie de tools regelmatig worden geüpdatet en de juiste werking wordt gevalideerd. Gezien de passieve aard van IDS wordt de effectiviteit van de maatregel bepaald door de frequentie en effectiviteit waarmee log files worden geanalyseerd. Als een aanvaller het netwerk weet binnen te dringen voordat de logbestanden worden geanalyseerd, is het niet meer mogelijk de aanval af te slaan.

Een Security Incident en Event Management (SIEM) oplossing kan helpen bij het stroomlijnen van de monitoring van de gebruikte beveiligingsoplossingen (firewalls, IDS, en dergelijke). SIEM-technologie biedt real-time inzicht in (beveiligings)waarschuwingen van netwerkcomponenten en applicaties. Daarnaast kunnen geautomatiseerd verbanden tussen incidenten worden gelegd in verschillende logbestanden en biedt het visualisatiemogelijkheden. Effectieve visualisatie van data kan eraan bijdragen dat analyses sneller kunnen plaatsvinden, reactiemogelijkheden toenemen en training van personeel eenvoudiger wordt [DEPA09]. Dit vereenvoudigt de communicatie over beveiliging op alle niveaus in een organisatie. SIEM is een passieve maatregel en de effectiviteit ervan hangt af van actieve monitoring door medewerkers [CPNI10].

… en verder?

De hierboven benoemde beveiligingsmaatregelen zijn niet nieuw of uitsluitend bedoeld voor ICS, maar in het toepassen ervan zijn er wel degelijk verschillen. Dit geldt natuurlijk voor vele andere (beveiligings)maatregelen die de IT auditor uit de praktijk kent maar die binnen het ICS-domein kunnen verschillen, bijvoorbeeld: een continu proces van risicoanalyses voor ICS, het identificeren en beheren van risico’s in de gehele ICS-keten (zoals afhankelijkheid van leveranciers), inventarisatie van projectrisico’s voor ICS, compliance met specifieke ICS wet- en regelgeving, support van het hoogste management voor ICS-beveiliging, aandacht voor redundantie en fouttolerantie, inkoop van ICS, noodplannen, configuratiemanagement, beveiliging van externe mediadragers en identificatie- en authenticatieproces. Voor nadere uitleg hierover verwijzen wij naar ons referaat. [JANS13]

Conclusie

Een behoorlijk aantal IT-auditors zal op enig moment audits uitvoeren bij organisaties die een of meerdere ICS hebben, die hoogstwaarschijnlijk ook nog zijn gekoppeld met het bedrijfsnetwerk. De IT-auditor kan niet om deze ICS heen en moet op zijn minst een weloverwogen afweging kunnen maken om (de beveiliging van) ICS binnen de scope van een audit al dan niet mee te nemen. Wij hopen met dit artikel de IT-auditor voldoende inzicht te hebben gegeven in wat ICS zijn en wat de beveiligingsproblematiek rondom ICS inhoudt, om bij de scoping van een onderzoek rekening te kunnen houden met deze systemen.

We willen afsluiten met een aanbeveling voor de IT-auditopleidingen. Het lijkt ons waardevol om ICS en de specifieke beveiligingsproblematiek daaromheen op zijn minst aan de orde te laten komen in die opleidingen. ICS vervullen vitale maatschappelijke functies en wijken zo sterk af van de systemen waar 99% van de IT-auditors mee bezig is, dat de toegevoegde waarde van aandacht voor dit onderwerp groot is. De differentiërende kenmerken van ICS, de grootste bedreigingen en de belangrijkste (beveiligings)maatregelen zijn aspecten die zeker in de opleiding aan de orde zouden moeten komen.