OT-Security maatregelen bepalen: Stap 2

Blog door Florian Buijs, Security Consultant

In deel 1 van deze serie hebben we gesproken over zichtbaarheid in het OT netwerk op een manier die geen impact op de productie omgeving heeft. Dat levert inzichten op, maar dat is meestal niet alleen goed nieuws. Vaak blijkt dat er ook ongewenst verkeer door het OT netwerk loopt. Denk daarbij aan iets wat eigenlijk goedaardig is, zoals een productiemedewerker die achter een HMI station heeft ontdekt dat het gewoon een Windows OS is met een internet browser. Dan kunt u toch best even in de rustige uren van een ploegendienst YouTube filmpjes kijken in FullHD kwaliteit. Er zullen ook daadwerkelijk ‘vreemde’ communicatie stromen zijn van devices die blijkbaar DNS queries uitsturen naar hardcoded DNS servers of SSH verbindingen opzetten naar het internet.

Dit brengt ons meteen bij stap 2: de mogelijkheid om verkeersstromen te gaan beperken tot dat wat nodig is (YouTube om 02:34 ’s nachts is misschien leuk tegen de verveling, maar nodig is het natuurlijk niet).

OTsecurityblogflorian-klein

Stap 1 gemist?

Lees hier de eerste blog in de serie OT-Security maatregelen bepalen: inzicht in verkeersstromen, assets en security events.

Lees hier stap 1

De manier om dit uit te voeren in de praktijk is netwerk segmentatie, iets wat in de IT wereld al heel normaal is. Meestal zijn daar de werkplekken, servers, telefoons, printers, wifi, etc. al lang van elkaar gescheiden. Dit voornamelijk op basis van VLAN’s. Een Security Device (zoals een Next Generation Firewall) bepaalt dan welke segmenten met elkaar mogen communiceren.

Dat klinkt als een goed idee voor de OT omgeving, maar ook daar zitten wel een aantal haken en ogen aan waar terdege rekening mee moet worden gehouden.

OT omgevingen:

  1. Gebruiken hele andere applicaties/protocollen:
    • Applicaties zoals Modbus, Siemens S7, CIP Ethernet IP, etc.
    • IT gerelateerde applicaties en protocollen zoals DNS, SSH, etc.
  2. Hebben apparatuur welke slecht/niet overweg kan met routing/subnets. Alles zit hierbij in een groot netwerk en daarom werkt het.
  3. Zijn op de laagste niveau’s (PURDUE/ISA-95) zeer tijdkritisch qua communicatie.

Het security element van netwerk segmentatie dient hier rekening mee te houden door:

  1. OT gerelateerde applicaties/protocollen te kunnen identificeren en daar security policies voor te kunnen bouwen. En daarnaast inspectie op te kunnen uitvoeren.
  2. Ook op OSI Laag 2 te kunnen segmenteren (dus op basis van MAC adressen) zodat IP adressen onveranderd kunnen blijven. Devices worden alleen verplaatst naar een ander VLAN, en verder blijven alle settings intact.
  3. Snel genoeg te zijn in de verwerking van de verkeersstromen.

Punt 3 is vooral belangrijk bij zogenaamde ‘realtime’ processen waarbij data van sensoren meteen moet worden verwerkt en een actie oplevert van een ander device. Bijvoorbeeld een lopende band die signaleert dat er iets mis gaat, moet meteen een stop actie opleveren. In gevallen waarbij de tijd tussen signalering en actie zeer kort dient te zijn, kan ervoor gekozen worden om deze devices toch in hetzelfde segment te houden.

Omdat in een OT omgeving productieverstoring uit den boze is, dient ook hier een specifieke volgorde aangehouden te worden:

  1. Alles doorlaten; alle applicaties en protocollen. Hierdoor zal via de logging duidelijk worden wat de exacte verkeersstromen zijn in combinatie met de mogelijkheden van de NGFW.
  2. Security rules maken die specifieke verkeersstromen doorlaten, zoals die in kaart zijn gebracht door de ‘alles doorlaten rules’.
  3. Ongewenst verkeer (zoals YouTube bijvoorbeeld) blokkeren.
  4. Inspectie aanzetten (zonder blokkade) op de toegestane verkeersstromen.
  5. Inspectie finetunen (met blokkade) voor specifieke vulnerabilities zoals die gezien zijn in de vorige stap ‘segmentatie’.

Bij het implementeren van deze netwerk segmentatie dient rekening te worden gehouden met langere doorlooptijden, omdat er verkeer nodig is dat geanalyseerd kan worden zodat de security rules en inspectie parameters vastgesteld kunnen worden. Dit alles om ervoor te zorgen dat de OT omgeving (cyber)veiliger wordt, zonder productieverstoring of persoonlijke ongelukken.

Benieuwd naar stap 3?

Deze zal Florian uitgebreid behandelen in zijn volgende blog. Wilt u niets missen? Meld u nu aan voor de nieuwsbrief en ontvang alle nieuwe content maandelijks in uw mailbox.

Aanmelden nieuwsbrief

Ook interessant voor u…

OTsecurity

Meer over OT security

SMR19_webinar

OT als risk driver? – Lees het in het Security Maturity Report

thumb-website-page-newsletter

Maandelijks interessante content ontvangen? Meld u aan voor de nieuwsbrief!