OT-Security maatregelen bepalen: Stap 3
De stappen uit deel 1 (inzicht) en deel 2 (segmentatie) hebben het OT netwerk veiliger gemaakt, maar hoe zit het met de zogenaamde ‘remote engineer’? Steeds meer apparatuur die wordt gebruikt in productie netwerken is dermate complex dat de interne medewerkers deze niet zomaar kunnen repareren in geval van storing. De fabrikanten hebben daar wel een oplossing voor, een engineer die het probleem oplost. Als die engineer in de buurt woont dan is fysiek langskomen niet zo’n probleem, maar de kans is groot dat dit niet het geval is. Veel specifieke apparatuur komt van ver weg (Zweden, Italie enz) en dus stelt de fabrikant voor om de engineer ‘op afstand’ te laten inloggen op de machine met storing.
Voor een plantmanager een perfecte oplossing, de response tijd wordt veel beter en geen reiskosten, een ‘win-win’ situatie.
Stap 1 gemist?
Lees hier de eerste blog in de serie OT-Security maatregelen bepalen: inzicht in verkeersstromen, assets en security events.
Helaas zitten hier wel wat security risico’s aan vast, het is immers geen eigen medewerker die toegang word verleend. De apparatuur van de engineer kan malware bevatten (vaak onbedoeld) en kan dus het hele OT netwerk besmetten. Of denk aan productie netwerken waar de ‘kroonjuwelen’ zoals een recept voor een bepaalde frisdrank zich in bepaalde machines bevind, daar moet die engineer dan niet bij kunnen komen.
Vanuit de engineer gezien is het ook lastig om met allerlei clientsoftware aan de slag te moeten om remote toegang te kunnen krijgen tot de defecte machine.
Om deze uitdagingen te adresseren zijn er twee soorten van oplossingen mogelijk, beide met zo min mogelijk impact op de engineer (nieuwe clientsoftware) en toch een maximale veiligheid.
De eerste oplossing is een combinatie van remote access oplossingen zoals we die kennen in de IT wereld (SSLVPN, Clientless VPN enz) waarbij geen client software geinstalleerd hoeft te worden. De authenticatie kan daarbij geregeld worden op basis van gebruikersnaam/wachtwoord, SSL certificaat en/of MFA. ‘Time-based’ toegang dient geregeld te worden op de authenticatieserver (bjvoorbeeld een account in AD dat tijdelijk enabled wordt). Nadat er een verbinding is gemaakt kan vervolgens een zogenaamde Jumphost worden overgenomen (RDP over HTML5). Op deze Jumphost (VDI of VM) die in een DMZ staat, kan vervolgens een verbinding worden gelegd met de te beheren machine. Voorwaarde is wel dat de benodigde software om met de machine te verbinden (die de engineer nodig heeft) op de Jumphost staat. Als dat niet het geval is, zou nog gekozen kunnen worden voor een SSLVPN maar dan met clientsoftware om een verbinding op te zetten naar de machine, deze variant is minder zeker en vereist client software aan de engineer zijde.
De tweede oplossing is specifiek gebouwd voor dit soort ‘restricted’ of beperkte remote access met maximale veiligheid en toch flexibiliteit. Hier word gebruik gemaakt van twee devices die samenwerken, een service-box (vlak bij de te beheren machine) en een rendevouz-box welke bereikbaar is vanaf het internet. Nadat de klant de verbinding naar de machine heeft opengezet voor de engineer (‘Time based access’) kan deze een verbinding opzetten naar de rendevouz-box (op basis van SSH, dus clientless) en zich authenticeert, kan vanaf daar de service-box van de desbetreffende machine worden gekozen. Op de service-box word alle communicatie vervolgens opgeslagen. Nadat de service vanuit de engineer is verleend wordt de toegang weer dichtgezet.
Hoewel de verleiding groot is om voor de eerste variant te kiezen (omdat veel of zelfs alle componenten reeds aanwezig zijn in de IT-omgeving), is de tweede variant qua beveiliging (en gebruiksgemak voor de engineer) de betere keuze. De klant bepaalt wanneer er toegang wordt verleent, toegang is alleen tot de desbetreffende machine en kan ook exact zien wat er allemaal uitgevoerd is.
Voorwaarde voor beide varianten is natuurlijk wel dat de vorige stap, segmentatie, heeft plaatsgevonden zodat er geen mogelijkheid is om ‘per ongeluk’ andere devices te benaderen via remote access.