VEILIGHEIDSMAATREGELEN

IT-beveiliging is een zeer belangrijke hoeksteen die vaak wordt verwaarloosd en catastrofale gevolgen kan hebben. Ritter Technologie GmbH hecht veel belang aan een naadloos beveiligingsconcept dat meegroeit met de vereisten. We houden ons aan de aanbevelingen van MITRE / LIST en onze beveiligingsmaatregelen worden regelmatig door externe specialisten gecontroleerd op hiaten in de beveiliging. Automatische tests vormen niet alleen een belangrijke basis op softwareniveau, indien mogelijk wordt ook de hardware automatisch gecontroleerd op onregelmatigheden.

De certificatie-instelling van TÜV SÜD Management Service GmbH verklaart dat de onderneming Ritter Technologie GmbH, Essener Straße 2-24, 46047 Oberhausen (Duitsland) een managementsysteem voor informatiebeveiliging heeft geïmplementeerd en toepast in overeenstemming met de "Verklaring van Toepasselijkheid" voor het aangrenzende toepassingsgebied. Door middel van een audit, rapport nr. 707066405, is aangetoond dat aan de eisen van ISO/IEC 27001:2017 wordt voldaan. Dit certificaat is geldig van 01.01.2023 tot 31.12.2025.

Het toepassingsgebied van het beheersysteem voor informatiebeveiliging van Ritter Technologie GmbH strekt zich uit tot de locatie Oberhausen, Essener Straße 2-24, met toepassing van DIN EN ISO 27001:2013, voor het serviceprofiel "Innovatieve en veilige IT-oplossingen, advies, infrastructuur, datacenterbeheer, software & services".

SOFTWARE LEVENSCYCLUS

  • Beveiligingsconcepten: bijv. CRS, OWASP tegen SQLi, XSS, LFI, RFI, PHPci
  • Gebruik van BSI-normen 2020
  • Handmatige en automatische tests, bijv. Cypress / Postman
  • 27K-gecertificeerd datacenter en hardware-/softwareontwikkeling

VAN DE MITRE / NIST AANBEVELINGEN

  • Stabiliteit van het onderdeel in termen van functionaliteit
  • Voornamelijk gebruik van open source producten om je eigen broncode reviews uit te voeren (maak indien nodig een fork)
  • Gebruik alleen actieve projecten

Het grootste risico ontstaat als open source-projecten worden stopgezet. In dat geval moeten verdere ontwikkelingen intern worden uitgevoerd of moet worden overgestapt op alternatieve producten.

De producten worden ook getest en gecontroleerd op IT-beveiliging door externe specialisten.

KWETSBAARHEID SCANS

We hebben al een proces geïmplementeerd om alle code-repositories dagelijks te controleren op nieuwe CVE's. Dit proces maakt gebruik van Trivy, dat automatisch rapporten publiceert en aanmaakt in tickets voor de relevante afdelingen. De Trivy integratie voor Buildroot zal gebeuren via een parser voor de PKG statistieken gegenereerd door Buildroot.

TOEGANGSRECHTEN IEC 60870-104

Elk IEC60870-104 serverproces kan slechts verbinding maken met 1 client, redundante passieve verbinding uitgesloten. Als meerdere clientsystemen zoals Salvador en SCADA verbinding willen maken met de RTU, is het daarom noodzakelijk om 2 IEC6087-104 serverprocessen op de RTU te laten draaien. Dit kan worden gedaan via het mapping-bestand door 2 configuratieobjecten aan te maken. Elk IEC60870 serverproces heeft zijn eigen IOA objectruimte. Als je bewakings-/besturingsobjecten wilt voorzien voor beide 104-serverprocessen, is het noodzakelijk om 2 objecten aan te maken binnen de mapping. 1 object voor elke server.

Deze procedure maakt het mogelijk om precies aan te geven welke monitor- en besturingsobjecten beschikbaar moeten worden gemaakt voor elk serverproces. Hiervoor wordt een IP-filter geleverd.

TOEGANGSCONTROLE

TOEGANGSCONTROLE (SCADA)

Toegang op basis van IP-filter, beveiligd door Ipsec VPN

VALIDATIE VAN CONFIGURATIEBESTANDEN

Alle configuraties worden geleverd door Node-Red en worden automatisch gecontroleerd.

SLEUTEL- EN CERTIFICAATBEHEER

Tijdens de eerste ingebruikname en wanneer de vervaldatum is bereikt, haalt de RTU een certificaat op van de PKI-server via SCEP. Dit certificaat wordt gebruikt om de IPsec-verbinding tussen de RTU en het klantnetwerk tot stand te brengen. Optioneel wordt het ook gebruikt voor communicatie tussen de RTU en DEMAS. Vereiste: Zorg voor een geschikte root-CA voor DEMAS, aangezien de PKI van de klant de certificaten genereert.

OPTIONEEL OP AANVRAAG

Beveiliging - Vertrouwelijkheid en integriteit van netwerkcommunicatie: op RTU
Als de WAN-verbinding al is beveiligd via VPN, deactiveer dan optioneel verdere versleuteling en daarmee natuurlijk certificaten voor deep packet inspection.

TOEGANGSCONTROLE VOOR TECHNICI (DEMAS)

  • De structuur van onze technische beveiliging is generiek. Alle Auth-providers kunnen worden aangesloten via Keycloak en NGINX.
  • We hebben gekozen voor mTLS (TLS-clientcertificaat uitgegeven via lokale PKI (SCEP)).
  • Naast DEMAS kan elk ander systeem optioneel worden beveiligd met dit generieke concept.

TOEGANGSCONTROLE VOOR INGENIEURS (RTU)

De RTU wordt centraal beheerd door DEMAS. Directe toegang tot de RTU via SSH is daarom mogelijk, maar niet noodzakelijk. Met de RTU is het mogelijk om gebruikers, wachtwoorden en groepstoewijzingen te definiëren in de systeemconfiguratie.

Een centrale aanmeldservice beheert de aanmeldingen voor de modules DEMAS en Node Red. Deze configuratie wordt normaal gesproken door DEMAS geleverd, maar kan lokaal worden gewijzigd. In dit geval wordt de wijziging herkend en wordt UUID 0 teruggemeld aan DEMAS. Hierdoor kan DEMAS op de wijziging reageren.

De bestanden en fatale herstelscripts kunnen alleen worden gewijzigd of uitgevoerd door gebruikers met rootrechten.

De gebruiker moet daarom ofwel in de root groep zitten of in de sudo groep. In het tweede geval moet de gebruiker alle acties starten met sudo.

  • We gebruiken Strongswan IPsec om het WAN-communicatiepad van de RTU naar het klantnetwerk te beveiligen. De configuratie van de IPsec parameters kan worden gedefinieerd in de systeemconfiguratie.
  • Het gebruikte certificaat wordt opgehaald van de PKI-server tijdens de eerste toegang en het proces via SCEP.
  • Authenticatie tussen 104 server en client is nog niet geïmplementeerd omdat dit geen onderdeel is van de protocolspecificatie.
  • Om de communicatie te beveiligen, gebruiken we IPsec voor vertrouwelijkheid en integriteit.

RTU BEVEILIGINGSFUNCTIES

  • FIT (Afgevlakte Beeldboom)
    • Gehasht: SHA-256
    • Versleuteld : AES-256-CBC
    • Ondertekend X.509-certificaat (4096-bits RSA-sleutel)
  • Cert-controle en image-decodering bij opstarten
  • Bootloader is beveiligd via HABv4-handtekening (closed source door NXP)
  • CPU biedt een veilige opstartfunctie voor HABv4
  • CPU laadt alleen bootloader met correcte HABv4-handtekening
    • Dual boot voor firmware fall back
    • Cert geprogrammeerd in OTP (One Time Programmable) zekeringen

FIRMWAREBEVEILIGING

De RTU-firmware gebruikt het FIT-formaat. Dit ene bestand bevat de kernel, de device tree en het root bestandssysteem. De RTU gebruikt een RAM bestandssysteem om schade aan het root FS te voorkomen. De bootloader U-Boot controleert bij elke start de geldigheid van het FIT firmware image, pakt de gegevens uit in het RAM en voert de Linux kernel uit. Alle veranderingen in de root FS gaan verloren na een herstart.
Het rtu-mgr proces stelt de instellingen voor alle services in volgens de systeemconfiguratie die door DEMAS wordt geleverd.

Het FIT-image wordt dienovereenkomstig ondertekend. De publieke sleutel bevindt zich in de bootloader omdat deze de image moet verifiëren. De private sleutel staat alleen op de RITTEC firmware build server en verlaat deze niet. We gebruiken het maximale sleutelformaat dat wordt ondersteund door U-Boot, RSA 4096 bit met SHA256.

De gegevens in de FIT-afbeelding zijn versleuteld en de bijbehorende sleutel is alleen verborgen in U-Boot. Dit is niet relevant voor de beveiliging, maar alleen een maatregel tegen reverse engineering.

Daarnaast is elke FIT-afbeelding voorzien van een HABv4-handtekening. Dit is een eigen
procedure van NXP die in de CPU is geïmplementeerd. Hiervoor wordt een privésleutel en een publieke sleutel gegenereerd met een NXP-hulpprogramma. De privésleutel verlaat nooit de buildserver.
De publieke sleutel wordt in de CPU gebrand door OneTimeProgrammable Fuses.

Nadat de CPU permanent is vergrendeld via een andere OTP-fuse, kan hij alleen nog correct HABv4-ondertekende bootloaders uitvoeren. De U-Boot bootloader die we gebruiken is daarom HABv4-gesigneerd, net als de FIT image van de firmware. Na het laden van het FIT-image controleert de bootloader eerst de HABv4-handtekening met behulp van de CPU, dan de FIT-handtekening, ontcijfert de gegevens in het RAM en start de kernel.

Een firmware-update wordt uitgevoerd door de volledige inactieve FIT-image te overschrijven. De eerder inactieve image wordt geactiveerd en opnieuw opgestart. Alle hierboven beschreven processen volgen nu. Als de image niet start, schakelt de watchdog terug naar de oude image.