Door Joost Schellevis

Redacteur

Scada-beveiliging: een structureel probleem

30-01-2012 • 08:00

97

Multipage-opmaak

Inleiding

Een 49-jarige Australiër is veroordeeld tot twee jaar celstraf omdat hij had ingebroken op de computersystemen van de riolering in Maroochy Shire, een deelregio in het oosten van Australië. Door met de systemen te knoeien zorgde hij ervoor dat 800.000 liter vervuild rioolwater in de omgeving van Maroochy Shire werd geloosd, waardoor parken en rivieren werden vervuild en talloze dieren het leven lieten.

De hack van de Australiër was een wraakactie: zijn sollicitatie bij de lokale overheid was afgewezen en hij was met ruzie vertrokken bij het bedrijf dat de computersystemen had geïnstalleerd.

Dit is geen vergezocht verhaal - het is waargebeurd. En niet vorig jaar, of het jaar daarvoor, maar al in 2000. Erg hightech was de aanval niet: de ex-werknemer kon de systemen van zijn voormalig werkgever eenvoudig binnendringen omdat de wachtwoorden niet waren gewijzigd.

In een analyse van de 'cyberdreigingen' voor Nederland schrijft de Nederlandse overheid dat 'gerichte verstoring' van industriële beheersystemen 'niet waarschijnlijk' is. De overheid verwijst daarbij naar het Stuxnet-virus, dat werd gebruikt voor een aanval op Iraanse uraniumverrijkingsinstallaties. Het Maroochy Shire-incident bewijst echter dat dergelijke geavanceerde software geen vereiste is om een aanval op infrastructuur te laten slagen.

Maroochy shire

Wat is een scada-systeem?

De toepassingen waarmee industriële systemen worden beheerd, worden scada-systemen genoemd. Scada staat voor supervisory control and data acquisition en is een verzamelnaam voor beheersystemen voor bijvoorbeeld rioleringen, energie-opwekking, fabricage en oliepijplijnen. Afhankelijk van de exacte definitie vallen er ook beheersysteemen voor treinen, verkeerslichten, telefonienetwerken, vliegtuigmotoren en pretparkattracties onder. Soms worden scada-systemen ook wel 'ics' genoemd: industrial control systems.

Het spreekt voor zich dat het handiger is om dergelijke systemen op afstand te beheren, dan door fysiek hendels en knoppen te bedienen. Diverse bedrijven, waaronder Siemens, Schneider Electric en General Electric, hebben daarom scada-toepassingen ontwikkeld.

Sommige scada-systemen kunnen alleen worden gebruikt om informatie af te lezen. Onderstaand screenshot is volgens Internet Security Systems, een onderdeel van IBM, een 'typisch voorbeeld' van een dergelijke interface.

Scada-systeem

Andere systemen kunnen ook voor daadwerkelijke beheertaken worden gebruikt. Een inmiddels berucht voorbeeld is dat van de frequentieregelaars in Iraanse uraniumverrijkingsfabrieken, die werden ontregeld door het Stuxnet-virus. Dat virus is volgens de geruchten ontwikkeld door de Verenigde Staten en Israël en zou specifiek bedoeld zijn om de Iraanse plannen voor kerncentrales te ondermijnen.

Het Stuxnet-virus was in sommige opzichten geavanceerd. Zo maakte het gebruik van maar liefst vier zero day-exploits; het misbruikte dus gaten in de beveiliging die tot op dat moment nog niet bekend waren. Eén zo'n zero-day-lek is op de zwarte markt al een fortuin waard.

Het bouwen van een virus als Stuxnet of het vergelijkbare - en waarschijnlijk van dezelfde bron afkomstige - Duqu-virus is niet voor iedereen weggelegd; het vereist diepgaande kennis van het systeem dat moet worden gekraakt. Iran claimt zelfs dat Siemens, de fabrikant van de getroffen frequentieregelaars, bij de aanval betrokken was.

De vraag is dan of de vaardigheden die nodig waren om Stuxnet en Duqu te ontwikkelen, een voorwaarde zijn om industriële beheersystemen te kunnen binnendringen - en het antwoord is vermoedelijk 'nee'.

Direct aan het internet

De systemen in de Iraanse kerncentrales konden via usb-sticks worden besmet. "Usb-sticks zijn de allergrootste bedreiging", zegt expertpanellid webinn, die ervaring heeft met de beveiliging van scada-systemen. "De opkomst van scada-systemen met Windows brengt grote uitdagingen met zich mee."

Het zou natuurlijk nog makkelijker zijn om systemen op afstand te kunnen misbruiken. Het lijkt een slecht idee om een cruciaal onderdeel van een dergelijk systeem aan het internet te hangen, maar slecht idee of niet - het gebeurt.

"Over het algemeen zijn deze systemen afgeschermd of zelfs helemaal niet met het internet verbonden", zegt tweaker Nvidiot, die eveneens ervaring met de beveiliging van scada-systemen heeft. "Er is echter druk van de beheerders en het management om ze wel op het internet aan te sluiten."

Door een systeem op het internet aan te sluiten, kunnen beheerders bijvoorbeeld een waterpomp bedienen zonder er naartoe te rijden. "Dat dat behoorlijke risico's met zich meebrengt, lijkt men zich niet altijd te realiseren", constateert Nvidiot.

Essent

Soms weten bedrijven ook niet dat systemen rechtstreeks aan internet hangen. Essent had bijvoorbeeld een gatewaysysteem, dat werd gebruikt voor het monitoren van warmtekrachtinstallaties, rechtstreeks aan het internet hangen, zo ontdekte beveiligingsonderzoeker @ntisec van Tweakers.net deze week. Op het systeem kon worden ingelogd met gebruikersnaam en wachtwoord 'admin'.

Hoewel de potentiële problemen in dit geval meevielen - het grootste gevaar was een denial of service waardoor automatische monitoring niet meer mogelijk was - had dit niet mogen gebeuren, gaf Essents plaatsvervangend security officer Marcel de Kock toe. Het voorval maakt in elk geval duidelijk hoe moeilijk het is om zulke omvangrijke systemen in hun geheel onder controle te houden. Na melding loste Essent de problemen overigens nog dezelfde avond op.

Fabrikanten van scada-systemen raden het doorgaans af om een scada-systeem rechtstreeks op het internet aan te sluiten. Dat dat advies in de praktijk nog wel eens wordt genegeerd, blijkt uit verschillende onderzoeken, zoals de afstudeerscriptie van de Brit Éireann Leverett. In zes maanden tijd ontdekte hij 10.358 internethosts die zichzelf als scada-systeem presenteerden. Overigens omvat dat cijfer mogelijk wel false positives en systemen met meerdere ip-adressen.

Scada-systemen aan het internet

Leverett ontdekte 370 scada-systemen in Nederland en 39 systemen in België. Van de ontdekte hosts die via port 80 te bereiken waren, gaf slechts 17 procent de http-statuscode dat authenticatie vereist was; in 53 procent van de gevallen kon de pagina van het scada-systeem worden opgevraagd. Bij 30 procent van de scada-systemen werd naar een andere locatie verwezen.

Het kan uiteraard wel zijn dat de bewuste systemen niet direct om http-authenticatie vroegen, maar doorverwezen naar een andere pagina of een anderssoortig loginformulier gebruikte. Feit is wel dat een systeem op dat moment benaderbaar is en dus in potentie misbruikt kan worden.

In een geval ontdekte Leverett zelfs een systeem dat aan het internet was gekoppeld, geen authenticatie vereiste en volledige toegang tot het beheerpaneel gaf. Het ging om de beheerinterface van een remote terminal unit, die volgens de fabrikant bijvoorbeeld voor het beheer van waterpompen kon worden gebruikt.

Het was zelfs mogelijk om ip whitelisting aan te zetten, zodat alleen van bepaalde ip-adressen verbindingen konden worden opgezet. Door daar zijn eigen ip-adres in te vullen, had Leverett de beheerders van het systeem kunnen buitensluiten. "Ik hoop maar dat dit systeem niet cruciaal voor de veiligheid is", schreef hij.

MOXA

Alle software bevat bugs

Dat een systeem aan het internet hangt, wil niet per definitie zeggen dat het kwetsbaar is. In de praktijk bestaat er echter geen software zonder beveiligingsproblemen. Zelfs als beveiligingsproblemen snel worden gepatcht, bestaat er nog het gevaar van de eerder al genoemde zero day-aanvallen.

Maar zelfs het maken en uitrollen van patches gebeurt niet altijd goed genoeg. "Het gaat vaak om oudere systemen die niet gepatched worden. Beheerders zijn daar huiverig voor", zegt Nvidiot. Ze willen het proces waarvoor het systeem wordt gebruikt niet in gevaar brengen.

Station

Een ander probleem is dat leveranciers vaak alleen oude versies van een besturingssysteem ondersteunen, waardoor gebruikers niet zomaar naar een nieuw OS kunnen upgraden. "Dat is prima als het netwerk niet aan het internet hangt", aldus Nvidiot. Zodra dat wel gebeurt, zijn de ongepatchte systemen een beveiligingsprobleem. Ook virusscanners kunnen vaak niet worden gebruikt, zegt webinn. "De leverancier moet dat willen en kunnen ondersteunen", zegt hij. En vaak is dat dus niet zo.

Metasploit

Een aantal beveiligingsonderzoekers stoorde zich zodanig aan de slechte beveiliging van veel scada-systemen dat ze een aantal kwetsbaarheden hebben toegevoegd aan Metasploit, een framework waarmee beveiligingsproblemen kunnen worden aangetoond. Het gaat om programmable logic controllers waarin backdoors zaten, waarvan de webinterface kon worden misbruikt of waarmee fuzzing mogelijk was.

Exploits voor één bepaalde General Electric-plc zijn nu toegvoegd aan het framework; exploits voor systemen van onder andere Schneider Electric, General Electric en Koyo volgen mogelijk later.

plc vulns

Geen theoretisch probleem

Dat beveiligingsproblemen in scada-systemen geen theoretisch probleem zijn, blijkt ook uit een onderzoek van Red Tiger Security, dat anderhalf jaar geleden op Black Hat werd gepresenteerd. Bij een analyse van circa 120 industriële systemen werden maar liefst 38.753 kwetsbaarheden aangetroffen.

Ook de Amerikaanse overheid waarschuwde deze zomer nog voor een groot aantal exploits voor scada-systemen, zoals buffer overflows, de mogelijkheid om eigen code uit te voeren, sql-injecties en denial of service-kwetsbaarheden.

"Beheerders zeggen vaak: ach, als het systeem de verkeerde dingen doet, dan corrigeren we het wel handmatig", zegt Nvidiot. Een aanvaller zou het systeem echter zodanig kunnen manipuleren dat het lijkt alsof alles goed gaat, terwijl alles stuk aan het gaan is.

Energiecentrale

Geavanceerde kennis?

Een veelgehoorde misvatting is dat geavanceerde kennis van een specifiek systeem nodig is om er misbruik van te kunnen maken: een aanvaller moet eerst weten welk systeem er wordt gebruikt om binnen te kunnen dringen. Bedrijven die erop rekenen dat maar weinig aanvallers over die kennis beschikken, maken zich schuldig aan security through obscurity en dat is niet bepaald een aanpak die bewezen effectief is.

Veel via het web toegankelijke scada-systemen identificeren zichzelf bijvoorbeeld al meteen in de http-headers. Daarnaast zetten veel fabrikanten testcases op hun website om potentiële nieuwe klanten binnen te halen - maar en passant is dat natuurlijk ook een prima bron van informatie voor eventuele kwaadwillenden. En als dat allemaal niet genoeg is, dan zijn er ook nog de insiders - zoals de Australiër die het rioleringssysteem van Maroochy Shire misbruikte.

Een tien jaar oud lek

Het is onbekend hoeveel scada-systemen kwetsbaar zijn, maar er is een aantal tekenende voorbeelden. Al in 2006 gaf Internet Security Systems op de Black Hat-conferentie een aantal voorbeelden van kwetsbare scada-systemen. Zo was er een bedrijf dat ontkende dat het scada-systeem van een energiecentrale aan het internet geknoopt was, maar indirect en via een tien jaar oud lek in Solaris kwamen aanvallers toch binnen.

In een ander geval was een 'onderdeel van het energienet' rechtstreeks aan het internet gekoppeld. Een hacker had met behulp van een sql-injectie kunnen inbreken en het systeem via een 'vpn-achtige tunnel' kunnen platleggen. In een nog ernstiger geval was het mogelijk om het gehele energienetwerk van een land plat te leggen door één speciaal geprepareerde url aan te roepen.

Er zijn ook recentere voorbeelden. In drie Amerikaanse steden wisten hackers eind vorig jaar in te breken op een scada-systeem waarmee een deel van de infrastructuur van de stad werd beheerd, en nog vorige week wisten hackers kortstondig een Amerikaanse treindienst plat te leggen.

Hack een vliegtuig

Beveiligingsonderzoeker Craig Wright benoemt een aantal andere voorbeelden, waarvan de ernstigste de Boeing 747 betreft. Wright moest de systemen van dit toestel testen en kon via een systeem voor video bij de controlesystemen van de motoren komen. "747's zijn grote vliegende Unix-hosts", schrijft hij.

Engines van een 747-400

Het patchen van het systeem, in dit geval Solaris, gebeurde niet goed genoeg en de geteste software moest ook nog eens via telnet worden benaderd, omdat de software niet met ssh-verbindingen overweg kon. Telnet wordt al jaren amper meer gebruikt omdat het protocol als onveilig bekendstaat. Het systeem kon al met al worden gebruikt om de instellingen van de motoren te wijzigen - en niet alleen op de grond, maar ook tijdens de vlucht. Het spreekt voor zich dat een aanval op deze systemen voor grote problemen zou kunnen zorgen.

Formeel was het scada-systeem voor de motoren gescheiden van het open netwerk voor de videosystemen, maar in de praktijk werden de netwerken alleen gescheiden met nat-filters. Dat is niet de beste manier om een netwerk te beveiligen, en daar kwam nog eens bij dat alleen inkomend verkeer werd gefilterd.

Een ander voorbeeld van Wright, dat ongeveer twee jaar geleden speelde, betreft een aantal energiecentrales waar eveneens geen firewall aanwezig was en waar een aantal computers nog op Windows 98 draaide. Bovendien stelde dit scada-systeem eventuele aanvallers in staat om zelf routes voor tcp-packets te bepalen, wat een inbraak flink vergemakkelijkte. Tot overmaat van ramp lekte een presentatie over de werking van dit scada-systeem uit, waardoor iedereen zich erin kon verdiepen.

Tot slot

Energiecentrales en vliegtuigen zijn fysiek goed beveiligd: je komt er vaak niet zomaar binnen. Dat is logisch, want gerommel met een vliegtuig of met het lichtnet kan grote en ernstige gevolgen hebben.

Zoals inmiddels duidelijk zal zijn, geldt dat niet voor netwerkbeveiliging. Het komt voor dat ongepatchte systemen die cruciale processen aansturen, direct of indirect aan het internet hangen. Het is moeilijk te zeggen hoe groot het beveiligingsprobleem is dat hieruit voortvloeit.

Duidelijk is wel dat leveranciers van scada-systemen en de gebruikers ervan niet alleen oog moeten hebben voor fysieke beveiliging. De worstcasescenario's lijken misschien op vergezochte scenario's voor Die Hard of Mission Impossible, maar gehackte scada-systemen zijn geen fictie.

De vraag is dan natuurlijk hoe scada-systemen goed kunnen worden beveiligd. Een mogelijke maatregel is de scheiding tussen interne netwerken en het internet. Een systeem rechtstreeks aan het internet hangen is misschien handig, maar dat maakt het nog niet verstandig. En hoewel het kennelijk nog niet overal beleid is, is het tijdig en volledig patchen van software en het dichttimmeren van de systemen - waarom zou je in een kerncentrale bijvoorbeeld usb-sticks moeten kunnen gebruiken - nog wel het minste wat een scada-beheerder moet doen.

Energiecentrale

Reacties (97)

97
97
77
13
4
11
Wijzig sortering
Siemens = Epic Fail
Couldn't agree more :)

Ik werk als netwerkspecialist bij een zuivelgigant en daar worden natuurlijk ook SCADA-systemen gebruikt in de productie. Nou bemoei ik mij weinig met industrial automation, maar ik krijg er af en toe wel mee te maken.
Overigens pakt mijjn werkgever het wel goed aan: niets direct aan het internet, layer-3 scheidingen tussen industrieel en kantoor, etc. etc. Maar hoeveel een bedrijf ook investeert in beveiliging en gedegen design: je blijft aan de goden overgeleverd, omdat de fabrikanten van PLC's en SCADA-systemen technologisch vaak nog in de steentijd leven. Denk aan de eerder vermeldde Wintendo 98 beheerstations, verouderde (al lang end-of-life) databases, etc. etc. Daar kun je je niet tegen wapenen. Dat moet van de leverancier komen, maar die staan over het algemeen niet te trappelen.
Dat is overigens niet zo vreemd, want een klant kan immers niet zo maar even overstappen naar een concurrerend systeem. Is er eenmaal gekozen voor een bepaalde leverancier, dan ben je als afnemer zo ongeveer aan de goden overgeleverd.

Daar zit, IMHO, het allergrootste probleem: er is voor leveranciers geen prikkel. Er zijn maar weinig bedrijven (if any) die, wanneer men een nieuwe productielocatie opzet, tegen de leverancier zegt: Luister: wij willen wel jullie systemen, maar dan eisen we dat we de boel kunnen beheren onder Windows 7 x64.
De leverancier lacht ze vierkant uit, want die kan op zijn vingers natellen dat overstappen naar een concurrent veel te duur wordt. Bovendien hebben alle fabrikanten zo hun eigen bugs. Siemens illustreert dat bijvoorbeeld, door glashard af te wijken van de 802.1AB standaard, hetgeen nogal wat problemen oplevert met de basic security die je toch minimaal wil hanteren op je switches. Flapping MAC-addresses zijn aan de orde van de dag. Port security aanzetten levert dus netwerkpoorten op die error disabled komen te staan, hetgeen dus betekent dat een hele productielijn stil komt te staan.

Ik heb eens even wat gegoogled en kom al forse kritiek tegen op CCIE-fora uit 2006!
Zeer recent heeft Siemens een bug-fix gereleased, maar die is wederom brak: in plaats van de standaarden te respecteren, komt dat MAC-adres (voor LLDP) alleen maar tijdens de initiële fase van het opstarten voorbij. Dat is dus geen fix: het is zelfs geen work-around! Want wat gebeurt er wanneer bijvoorbeeld de stroom even onderbroken wordt? Alle lijnen rebooten en zoeken hun netwerk: gevolg één lijn die draait en de anderen staan stil, vanwege MAC-flaps. Zes jaar wachten op een fix en dan afgescheept worden met zoiets :? Te zot voor woorden!

Het is ongelooflijk. De Voedingsmiddelenindustrie is, overigens zéér terecht, aan allerlei regels gebonden. Je moet er immers niet aan denken wat er met de volksgezondheid kan gebeuren in geval van, ik noem maar iets, vervuiling van producten. Je zou dan toch verwachten dat de producenten van SCADA-systemen voor die industrie toch ook wel aan de nodige eisen moeten voldoen. Maar nee: niets van dit alles. Dat zal wel te maken hebben met de economische belangen enerzijds en de machtige lobby van de fabrikanten anderzijds, maar het blijft idioot. En dit geldt overigens niet enkel voor de voedingsmiddelenindustrie. Het in het artikel aangehaalde voorbeeld van de Boeing 747 is wat dat betreft ook tekenend: de (civiele) luchtvaart is zo mogelijk nog erger bedolven onder wettelijke regelgeving, maar ook daar komen de SCADA-producenten weg met bewezen zwakke producten.

En Europa houdt zich bezig met universele laders voor mobieltjes en de maximale kromming van een komkommer.....

[Reactie gewijzigd door The Jester op 22 juli 2024 23:12]

@The Jester

Jammer dat je niet eerst hebt verdiept in ISA95 en ISA99, je kijkt duidelijk met een kantoor-IT achtergrond naar het een en ander.

Siemens doet het erg goed en is zelfs één van de betere en daarom ook één van de grootste PLC fabrikanten. Waarom loopt men achter? omdat MS in het verleden heeft bewezen enorm onbetrouwbaar te zijn met hun updates.

Bij Siemens test men dus elke (hot)-fix van MS eerst een aantal maanden voordat zij zelf een fix uitbrengen. In mijn ogen erg goed. Dit omdat veiligheid niet op nummer 1 staat, maar beschikbaarheid, dan betrouwbaarheid en dan veiligheid (ISA99 normering).

Kom dus uit je kleine wereld en verdiep je eerst, als je het niet aankunt ander werk zoeken zou ik zeggen.
Aha, ik ben dus een gedresseerde aap met tunnelvisie.
Nou: jij ook maar een goedemorgen, dan....

Okay: ik geef toe niet op de hoogte te zijn van ISA95 en ISA99, en ik kan er ook nog inkomen dat beschikbaarheid en betrouwbaarheid voor SCADA-systemen erg belangrijk zijn. Dat geeft producenten echter geen vrijbrief om af te wijken van industriële standaarden, zoals bijvoorbeeld IEEE 802.1AB.
De leveranciers weten dat die systemen remote beheerd moeten (kunnen) worden, dus zouden ze zich behoren te conformeren aan standaarden. Dat is gewoon gezond verstand en heeft niets van doen met het feit dat ik zó extreem beperkt ben dan ik slechts de keuze heb tussen network consultancy en een bijstandsuitkering.
IEEE 802.1AB zijn kantoor standaarden geen industriele standaarden, daar ga je scheef.

Nee geen tunnelvisie, gewoon realistisch en bekend met de vele beperkingen in de dagelijkse praktijk van management dat niet wil luisteren.
Remote beheer is een onbeheersbaar veiligheidsrisico en doen wij dus ook niet aan, bij elke storing gewoon naar de fabriek en oplossen. Geen connectie is het meest veilig mbt het internet.

Verder verdiep je gewoon eerst in de normen binnen de IACS
Waarom heb ik dan altijd ellende met siemens software? Ik heb al meer problemen gevonden in siemens software dan van alle andere fabrikanten tezamen die ik heb liggen en gebruik.

Bij siemens maken ze het programma zo dat je maximaal aantal functies (simpel) kunt gebruiken. Daardoor wordt het programma zeer onoverzichtelijk, onstabiel en zwaar.

Siemens heeft op hardware niveau zeker wel plus punten, maar de software is gewoon brak.
heb zelf zelden of nooit problemen met siemens software. Gewoon gestructureerd programmeren en zoveel mogelijk met structures en parametrering werken.

De hardware is super we hebben plc's zitten in de fabriek die al 30 jaar 24/7 aan staan en nog nooit ook maar 1x uitgevallen zijn door enig probleem.
Mee eens, ik vind Siemens ook één van de betere leveranciers op dat gebied. Een leverancier die wereldwijd actief is kan nu eenmaal niet heel vlug technologie na technologie sprongen maken. De beschikbaarheid, verkrijgbaarheid en ondersteuning van producten (hardware en software) moeten goed zijn en blijven. Ik verbaasde me in het verleden bij bv. Siemens dat CPU perfomance (in PLC's) achter liep op de concurrentie. Maar daar tegen over stond wel dat je 5 jaar oude technologie als spare part nieuw kon kopen.

On-topic, ik had graag meer praktijk voorbeelden gezien van gehackte Scada systemen en de gevolgen er van. Ik denk dat als je naar een industrieel netwerk kijkt dat gekoppeld is met een kantoornetwerk dat de beveiliging faalt op menselijk vlak via bv social engineering.
Wat betreft het niet updaten door leveranciers, Wellicht is het tijd dat een paar van dat gebruikers een clubje oprichten en een opensource oplossingen gaan bouwen die die oude troep en niet meewerkende leveranciers aan de kant zet.

Eenmaal opensource kan elke gebruiker er een programmeur op zetten om iig de bekende fouten zelf op te laten lossen.

Eventueel kun je gebruik maken van zo veel mogelijk andere opensource oplossingen zodat je nooit meer in een situatie komt waarbij je de veiligheid niet zelf kunt bijsturen omdat je leveranciers het wel best vinden.
Dan zou je de PLC's moeten gaan reverse-engineeren.
Ik denk dat binnen no-time de advocaten van de fabrikant aan je poort staat te rammelen.
gaat niet werken het management eist ondersteuning bij de zuivelgigant waar ik werk, dit heeft o.a. te maken met falende IT mangers die alleen verstand hebben van kantoorautomatisering.

Industriele automatisering is een ander wereld met ander eisen en invalshoeken, als je die bekijkt als kantoorauomatiseerder, dan vind je veel dingen vreemd.

ISA95 en ISA99 geven een mooie omschrijving waar en waarom er verschillen zijn, dus ik zou zeggen eerst lezen en informeren en dan beoordelen en stap uit je eigen blikveld.
Eén groot verschil met bijvoorbeeld kantoorautomatisering is dat bij industriële automatisering de levensduur van een systeem veel langer is. Wellicht in een grote fabriek niet zo zeer waar de productielijnen wellicht regelmatig worden gewijzigd en er vaker nieuwere meer up to date systemen toegepast kunnen worden, maar als ik naar mijn eigen vakgebied kijk (industriële automatisering voor onder andere rioolgemalen) kom ik daar plc's tegen van wel twintig jaar oud! Dan heb je al sneller met out of date software te maken.

Doorgaans zijn binnen een gemeente de gemalen ook via een Scada systeem gekoppeld (waarmee storingen gemeld worden, maar ook instellingen van gemalen gedaan kunnen worden en dus ook uitgeschakeld kunnen worden) en vooral bij de kleinere gemeentes zie je ook nog veel scada systemen draaien van tien jaar oud. Bij dit soort klanten krijgen onze vertegenwoordigers vaak ook slecht een voet tussen de deur om een modern volledig internetgebasseerd Scada-systeem te leveren wat wel goed beveiligd is omdat het volgens de gemeente het oude systeem prima werkt en er geen geld beschikbaar is voor nieuwe systemen.

Ook qua communicatie met de gemalen zelf valt nog veel winst te halen als het op beveiliging aan komt. Het toepassen van verbindingen zoals GPRS of ADSL (waarmee je in ieder geval doormiddel van VPN verbindingen enzo nog wat kan afschermen) is iets wat nog maar mondjesmaat toegepast wordt en wederom zijn het de kleine gemeentes die hier nog niet zo aan willen omdat het nu allemaal wel werkt en er ze niet snel willen investeren . Er wordt in deze wereld nog veel gebruik gemaakt van "ouderwetse" inbelverbindingen met PSTN of GSM (hoeveel mensen kunnen nog zeggen dat ze een 56K-modem aan hun pc hebben hangen :) ik heb er twee) waar als je het telefoonnummer van het gemaal weet, je overal ter wereld zonder wachtwoorden of wat dan ook contact met het gemaal kan krijgen en je die installatie zo buiten werking kan stellen.
Dat 56K-modem van jou ligt ook bij mij op kantoor!

Veel van onze klanten vragen ook voor een koppeling met het internet. Vooral klanten die meerdere fabrieken wereldwijd hebben staan en in 1 plaatje de actuele status willen zien. De telefoonlijn verdwijnt dan ook heel langzaam aan, maar bestaat nog steeds en wordt zelfs nog steeds verkocht. Systemen van 15 jaar oud draaien er nog steeds goed mee. Veiligheid... dat wordt soms gewaarborgd door de PSTN stekker eruit te halen en alleen aan te sluiten indien er even ingebeld mag worden.

Gelukkig gaan we nu langzaam over naar betere beveiliging. Zoals het artikel ook aanhaalt, 100% dicht krijg je het niet. Maar met IPsec, VPN, certificaten en dedicated hardware om remote service te bieden, gaan we volgens mij de goede kant op.
Punt blijft wel staan dat ons eigen netwerk goed dicht moet zitten, want als dat lek is hangen we nog de hele wereld aan het internet |:( .
Nu had ik al eens eerder gereageerd in een topic over SCADA - ik programmeer veiligheids systemen en stel deze ook in bedrijf op locatie. Ik ben denk ik per jaar betrokken bij drie of vier projecten waar ook een SCADA applicatie bij zit. Naar aanleiding van het vorige topic over at klimaat systeem dat via het internet te benaderen was met een standaard (of geen?) wachtwoord en een project dat in mijn bedrijf net werd opgeleverd hebben ik en een paar collega's een gesprek gehad over onze procedures etc. Hieruit volgde dat we voortaan in detail willen beschrijven voor de klant wat ze kunnen verwachten kwa veiligheid en IT, dit is:

-een admin account met een niet voor de hand liggend wachtwoord, dit account wordt normaal niet gebruikt.
-Een user account voor de operators en een voor onderhoud
-een netwerk poort voor de lokale IT afdeling om hun virus scanner up to date te houden
(gebruiken ze deze optie niet dan is het jammer, we hebben het geprobeerd)
-via gpedit worden de rechten voor normale accounts flink ingesnoeid
-de normale shell wordt niet opgestart, maar inplaats daarvan de SCADA app
-de PC logt automatisch in en start de SCADA applicatie
-OPC restricties worden via Dcom netjes geregeld (niet de makkelijk "everyone optie")

Hier zitten nog al wat hakken en ogen aan maar we hopen in het bedrijf alles te kunnen beschrijven en werkend te krijgen. Nu zijn veiligheids systemen op zich wel robuust, de standaarden schrijven voor dat setpoints etc niet via een communicatie link naar de PLC geschrven mogen worden maar als iemand er echt voor gaat zitten kan er best iets als stuxnet langs komen en veel schade doen.

Het gaat er vooral om dat er geen VNC clients achterblijven op machines, dat de machines goed dichtgetimmerd zitten en dat de IT afdeling van de klant betrokken wordt bij het project!

over drie maanden testen we het eerste project met deze nieuwe manier van werken, kijken wat er gebeurt....

edit: typo

[Reactie gewijzigd door The_Butler op 22 juli 2024 23:12]

Nu zijn veiligheids systemen op zich wel robuust, de standaarden schrijven voor dat setpoints etc niet via een communicatie link naar de PLC geschrven mogen worden
Hoe krijg je dat voor elkaar dan?

Veel SCADA systemen hebben bv een optie om een pomp oid in manual operation te zetten en handmatig een setpoint te geven. Verder worden veel setpoints in een procesbesturing direct of indirect bepaald door wat de operator instelt ( snelheden, debieten, hoeveelheden etc )
Hoe krijg je dat voor elkaar dan?


Kijk, dat is het verschil tussens het controle systeem en het veiligheids systeem; beide zijn onafhankelijk van elkaar. Een pijp met 98% H2SO4 bijvoorbeeld kan twee kleppen hebben; 1 variable klep om te kunnen doseren en een noodafsluiter die aan het veiligheids systeem hangt. In veel gevallen komen analoge signalen (denk in dit voorbeeld aan PH of temperatuur) binnen in het veiligheids systeem. Deze worden dan via een communicatie link aan het controle systeem gegeven. Deze communicatie kan maar via 1 kant gebeuren (als je het goed configureerd natuurlijk, maar daar zijn regels en standaarden voor). Het is altijd zo dat het controle systeem als eerste probeert te regelen / in te grijpen. Stel de temperatuur in het voorbeeld klimt veels te snel omhoog; het controle systeem moet dan ingrijpen; maar stel door een hack of een menselijke fout is het setpoint ver buiten de range gezet; dan zal het veiligheids systeem bij een arbitraire waarde ingrijpen. In een ideale situatie doet een veiligheids systeem nooit iets; het is altijd aan het controle systeem om controle over een proces te houden en te zorgen dat de boel niet uit de klauwen loopt.
Ah ok, je veiligheidsssyteem is een apart proces dat parallel draait aan de normale procesbesturing?
Dan nog, als een signaal via de normale procesbesturing naar het controle systeem gaat, valt het theoretisch zo te hacken dat het controle systeem niets in de gaten heeft. je zou dan alle relevante signalen apart moeten uitbedraden naar je controle systeem.
Het veiligheids systeem is fysiek ander proces in een fysiek andere bedradings kast, met andere hardware en wordt in het ideale geval door een ander bedrijf ontworpen. (zo wordt uitgesloten dat 1 programmeur / engineer zowel het controle als veiligheids systeem ontwikkelt en daar dezelfde misinterpretaties / fouten in kan laten sluipen).

Het uitbedraden van signalen gebeurt in 25% van de gevallen; ligt er een beetje aan wat de klant wil...

Hardware voor veiligheids systemen is ook vele malen duurder, omdat de componenten niet in een gevaarlijke toestand kapot mogen gaan (Fail to Danger). En de procedures en documentatie zijn ook niet mis, google voor de gein eens naar IEC61508 als je meer wilt weten over functional safety.

[Reactie gewijzigd door The_Butler op 22 juli 2024 23:12]

Erg goed artikel, heeft me goed geholpen om een aantal managers geïnformeerd te krijgen over wat een Scada systeem nu inhoud.
Maar er zijn wel meer systemen die al dan niet rechtstreeks aan het Internet hangen en die een forse impact op werkprocessen kunnen hebben. Denk maar aan allerlei webbased toegangssystemen of klant/balie systemen. Als security manager weiger ik standaard ieder verzoek van leveranciers om toegang te krijgen, via het Internet, om dergelijke systemen remote te beheren of updates uit te rollen.
Indien we een contract afsluiten waarbij de leverancier een stuk beheer op zich neemt wordt er in ieder geval door de netwerkbeheerders een VPN/Token/SSH/IP gefilterde constructie gemaakt zodat het systeem nooit rechtstreeks vanaf het internet te benaderen is. Indien de leverancier updates wil komen doen dan zetten ze dat maar op een cd of komen ze zelf gewoon maar langs.
Deze werkwijze geeft nog geen 100% veiligheid (bestaat niet) maar het komt wel in de buurt, hoop ik.

Overigens vindt ik de discussie over de onveiligheid van USB stick een beetje triviaal. Het grootste gevaar voor de veiligheid zit nog steeds in de gebruikers. In veel omgevingen wordt er standaard een USB verbod gevoerd terwijl de gebruikers wel gewoon volledige toegang tot Internet hebben. Tja, wat verwacht je dat je gebruikers gaan doen? Juist, Dropbox ed. zijn dan de gekozen alternatieven, met alle gevolgen van dien. Dus kun je gebruikers, indien de bedrijfspolicy dat toestaat, alternatieven bieden om bestanden met elkaar te kunnen delen of presentaties op een veilige plek neer te kunnen zetten en te delen. Daar gaat in de meeste gevallen gewoon om en als je daarin niet faciliteert gaan gebruikers zelf naar oplossingen zoeken.
gaan gebruikers zelf naar oplossingen zoeken.

Ja zoals split tunneling om en een vpn verbinding te hebben en tegelijkertijd te kunnen printen.
Anoniem: 121991 30 januari 2012 10:30
Ik zit ook in de SCADA-sector. Meerbepaald in de support-afdeling van onze firma.
Het is voor mij een koud kunstje om alle inloggegevens te verzamelen en na mijn ontslag te blijven gebruiken.

Bij ons bepaalt de klant hoe hij zijn systemen beschikbaar maakt aan onze support-afdeling. Vrijwel alle klanten hebben een mogelijkheid om hun systeem vanaf afstand te beheren. Hier zie je toch een grote diversiteit aan inbel-methodes. De meesten gebruiken een VPN. Een enkeling heeft een rechtstreekse RDP tot op zijn scada. Maar dit zit dan ook in een sector die geen gevaar vormt.

De VPN-sytemen variëren ook sterk. Je hebt er bij die de Windows VPN gebruiken (minderheid) en je hebt erbij die gebruik maken 3rd-party VPN systemen. Van die systemen zijn degene die werken met een token uiteraard de veiligste. Werkt een beetje als PC-banking. Je hebt een deel van de inloggegevens en als je de rest wil, moet je naar de werknemer in kwestie bellen die je de resterende gegevens bezorgd (token dat 6 cijfers geeft).


Wat me ook opvalt is dat SCADA-integratoren vaak dezelfde gebruikers/wachtwoorden gebruiken. Het is al meermaals voorgevallen dat ik bij een klant op een vreemd-systeem iets moet nazien. De klant weet vaak het wachtwoord niet van dat systeem, maar gelukkig had ik de week ervoor aan een soortgelijk systeem bij een concurrent gezeten dat door dezelfde firma was geplaatst. Gewoon hetzelfde wachtwoord ingegeven en ik was vertrokken..
Een groot deel van deze problemen worden imho veroorzaakt door:

- Onwetendheid en desinteresse bij de integrators van de industriele systemen. Veel mensen die in deze sector werken rollen vanuit bv een technische dienst in het PLC en SCADA verhaal. Je kunt niet verwachten dat zo iemand automatisch affiniteit heeft met dit soort beveiligingsvraagstukken. De uitspraak "Het werkt toch?!" is mij niet vreemd. ( Opleiden! )
- Ignorance bij het management dat koste wat het kost voor een dubbeltje op de eerste rang te zitten ( Dat kan Jan van de TD toch ook? ). Bekijk alleen al het verschil in beloning tussen een kantoorautomatiseerder en een industrieel automatiseerder; dat moet zich ergens in uiten natuurlijk. ( Belonen! )
- Doordat systemen 15 jaar of langer draaien zijn de platformen waarop ze draaien sterk verouderd en een spreekwoordelijke gatenkaas. De shift naar Windows in het verleden heeft dit probleem alleen maar groter gemaakt: Ik ben benieuwd hoeveel van die systemen nog op Win95/Win98/Win ME ( jaja! ) draait. ( Opener platformen! )
Zeer interessant onderwerp, tegenwoordig is het risico steeds minder fysieke oorlog. Dit soort lekken zullen, bij een oorlog, gebruikt worden om digitaal toe te slaan. Een nucleaire bom is erg, maar een hele bevolking verontreinigd water laten drinken gaat natuurlijk nog een stapje verder.
Wel schrikbarend om te zien dat er zoveel systemen openstaan en hier niet goed over nagedacht is.
Natuurlijk is "critical infrastructure security" een belangrijk thema, en er zijn ook genoeg mensen die er mee bezig zijn.

De noodzaak voor een remote verbinding is overigens niet alleen door "lui management" ingegeven, maar ook gewoon keihard nodig.
Klanten van ons willen ook remote management hebben, want hoe wil je anders bij een offshore windturbine in de gaten houden of de boel goed werkt? Bij slecht weer kan je er met de boot of met de helicopter niet naartoe, en medewerkers zitten er normaal gesproken niet 24/7 in. Dus moet je remote het systeem in de gaten kunnen houden, en in het ergste geval kunnen bijsturen of uitzetten. Knappe jongen die dat zonder internet-verbinding tot stand weet te brengen.

Maar op zich is veilig remote management toch niet zo moeilijk? Je koopt voor 3 tientjes een firewall-appliance die je moet configureren, zet een VPN-verbinding op, en je hebt je veilige remote-verbinding te pakken. Het probleem ligt hem dan ook vaak in de systeem-architectuur die voor zo'n systeem wordt bedacht, waar security historisch gezien niet heel belangrijk was, maar pas de afgelopen jaren belangrijker is geworden. Daardoor vermoed ik dat nieuwe systemen wel degelijk een stuk veiliger worden ontwikkeld, maar dan nog - een programmeerfoutje is snel gemaakt en moeilijk op te sporen.

De mensen die PLCs programmeren mogen ook wel eens achter hun oren krabben of ze alle memory-schrijfacties op bufferoverflows e.d. controleren. An sich zou je verwachten dat mensen in dit specialisme volgens een gedegen proces werken waar dat soort fouten er voor een groot deel uitgehaald worden in het testen, maar er glipt altijd wel weer tussendoor.

PS: om nou binnen een vliegtuig van SCADA te spreken is ook weer zoiets. Een vliegtuig heeft een heel andere manier van ontwerpen en ontwikkelen dan een industrieel systeem a la energiecentrale. Daarnaast is een vliegtuig nou niet bepaald online te benaderen, aangezien alle IMA redelijk in het vliegtuig blijft en alleen wat radio-connecties naar buiten gaan. Dat is echt een beetje appels en peren vergelijken.

[Reactie gewijzigd door Garyu op 22 juli 2024 23:12]

De reden dat die code onveiliger is, heeft te maken met hetgeen hieronder wordt gezegd: dat is niet bedoeld om van buitenaf opgeroepen te worden.

Heel stom voorbeeld: fatsoenlijk geheugenbeheer en memory safety wordt amper toegepast, omdat je in een erg voorspelbaar en gesloten 'ecosysteem' zit. Indien je een routine hebt die ergens wordt aangeroepen, ga je ervan uit dat diegene die ze aanroept, de nodige en correcte parameters meegeeft en bv. geen null pointers. Je mag daar van uitgaan omdat de enige die software schrijft die die procedure zal aanroepen, ofwel jijzelf ofwel de collega naast jou ofwel je opvolger is.

Tel daarbij nog dat een 8051-microcontroller geen Sandy Bridge quadcore is, een heel beperkte featureset en performantie heeft, en vaak nog in assembler of platte C geprogrammeerd wordt. Je hebt niet altijd de mogelijk om in elke laag de nodige checks te doen.

En tel daar nog bij dat dat niet altijd informatica zijn met kennis van design patterns en frameworks, maar vaak ingenieurs (elektronica, mechanica, elektromechanica, ...), die aan dit soort systemen meewerken of onderhouden, en het plaatje is compleet: slecht gedesignede code waar geen tijd/geld/interesse/mogelijkheid is om aan security te doen. No offense naar ingenieurs toe (ben er zelf één van opleiding), maar ik weet uit mijn directe omgeving dat het wel zo gaat in 't bedrijfsleven.

[Reactie gewijzigd door Bauknecht op 22 juli 2024 23:12]

Zijn er geen andere metoden dan internet om over een afstand te communiceren? Niet voor de hand liggend, maar zeker wel mogelijk. En voor een kern- of watercentrale belangrijk genoeg om te overwegen en in te investeren. My 2cts.
Op het moment dat je een powergrid hebt, kan je natuurlijk direct op je spanningslijnen moduleren, dit wordt voor SCADA van dat soort systemen meestal gebruikt. Makkelijke reden: de kabels liggen er al, en nieuwe kabels alleen voor communicatie neerleggen is duur, vooral omdat het meerdere 100 km moet beslaan. Dus ja, het kan wel. Maar het is niet altijd praktisch. En natuurlijk ook niet per se veiliger!
Is het zo lastig om bij de energiekabel die je toch al moet leggen ook een bosje glasvezel te bundelen? En die gewoon niet op het internet aan te sluiten?
Misschien niet moeilijk (heb ik verder geen verstand van), maar zeker wel een stuk duurder en daar gaat het om ;)
Een nucleaire bom is erg, maar een hele bevolking verontreinigd water laten drinken gaat natuurlijk nog een stapje verder.
Of zelfs gewoon compleet afsluiten van energie en water. 3 dagen is genoeg om een miljoenenstad compleet plat te krijgen.
Ah, de aloude belegering. Maar nu via internet, lekker vanuit uw luie stoel!
Lol, ik zie nu ineens mannen in harnassen achteroverleunend in een zwartlederen stoel op wieltjes, voeten op het bureau, toetsenplank op de metalen schoot en hellebaard in de hoek van de kamer voor me... Thanks I lolled!
Ik heb met scada systemen gewerkt, vooral waterzuiveringsinstallaties. Wat mij destijds ook al opviel dat was dat de meeste scada software werken met een bepaalde versie van Windows en dat men er vervolgens nooit meer een update achteraan gooit omdat men dan bang is dat het scada pakket dan niet meer werkt! snap niet dat er nog nooit wat gebeurd is in al die tijd :P Dit geldt overigens ook Monitor Pro van Schneider welke gebruikt maakt van SQL 2000 :P
werken met een bepaalde versie van Windows en dat men er vervolgens nooit meer een update achteraan gooit omdat men dan bang is dat het scada pakket dan niet meer werkt
Het erge is, dat dit in 8/10 gevallen ook nog echt zo is. Veel SCADA paketten zijn dwars en hange aan elkaar van de dependencies. Ik werk dagelijks met zulke systemen, de nieuwere paketten zijn vaak wel beter, maar echt leveranciers bieden geen support als je OS niet in hun lijstje staat.

Verder is er bij de leveranciers nog een stevig probleem. Of eigelijk een stukje mis-management. Vrijwel elke update kost geld, elke nieuwe versie kost geld.
En dit zijn geen kleine bedragen. Dit gaat ook op voor Security updates en bug's die duidelijk fouten zijn van de leveranciers.
In veel gevallen mag je het systeem zelfs niet aanpassen. Ik ken systemen waarbij ik een auth wou toevoegen aan de IIS server (IIS 7, win7 embedded) maar de fabrikant niet garant stond dat alles hierna nog zou werken omdat de hele machine beveilig was.
Het zou kunnen zijn dat het product hierna niet meer werkte omdat de klant zelf geen wijzigingen mocht maken.
Geen auth toevoegen betekende dat het apparaatje benaderbaar was met een wachtwoord van 4 cijfers.. en dan gek vinden dat iemand nog een extra beveiliging wil invoeren.

Ook meegemaakt dat in een omgeving telkens een virus gesignaleerd werd. Na wat uitzoekwerk bleek dat een windows XP machine zonder service packs vol stond met virussen, het ging hier om een waterpomp regel apparaat. (En dat vermeld ik het nog subtiel).

Het is gewoon vreemd in mijn ogen dat de fabrikanten het vaak zo dicht timmeren (soort van read-only modus) om te voorkomen dat mensen er zelf mee ga spelen. Hierdoor, en door andere reden durven beheerders vaak geen updates te draaien omdat ze gewoon niet weten of alles nog werkt. En bij de minst kritische systemen (denk aan de regeling van de verwarming) kun je toch al redelijk wat gedoe krijgen met het management, laat staan als het om kritische systemen gaat.

In mijn ogen is het probleem dan ook veelal te wijten aan de fabrikanten. Ze moeten dynamische systemen maken welke wel geüpdatet kunnen worden en out of the box met antivirusproducten en een firewall geleverd worden. Door de firewall kun je enkel poort 80 (of lievers zelf een onbekende poort) open zetten voor het externe beheer. En nog beter zelfs een aantal IP adressen whitelisten en de rest blokkeren. Daarnaast moeten ze ook het verhaaltje "het standaard wachtwoor kan helaas niet gewijzigd worden" afschaffen, we leven in 2012.
Met een aantal simpele maatregelen zorg je er al voor dat de apparaten out of the box vele malen beter beveiligd zijn.
Waarom zou je een virusscanner willen? Het lijkt me überhaupt niet de bedoeling dat dergelijke systemen andere programma's kunnen uitvoeren dan datgene waar ze voor bedoeld zijn.

Bij een dergelijk grote exploit gaat die virusscanner het ook niet redden.
Een SCADA zorgt voort de connectie tussen verschillende machines en een device. Deze host kan vervolgens allemaal data verzamelen en tonen aan een beheerder.

Het is begrijpelijk dat zulk apparaat op een bestaand OS draait in plaats van een embedded variant omdat ze op veel verschillende vlakken met verschillende devices ingezet worden. Stel je eens voor dat je zelf een apparaat moet maken (dus OS + hardware en drivers e.d.) welk connectie kan maken met de volgende communicatie middelen: ethernet, profibus, RS232, RS485 en MP.
Daarnaast moet je hier dan ook weer een webserver op draaien, ofwel voor verschillende OS-en een client gaan maken welke connectie kan leggen met het apparaat.

Het is dus veel goedkoper om een bestaand OS te gebruiken. Daarnaast hebben deze ook al bestaande database welke je kunt gebruiken, bestaande webservers en ga zo maar door.

Om simpelweg geen andere programma's toe te laten is dus niet vaak een optie omdat vaak bestaande OS-en gebruikt worden.

En een virusscanner is in dit geval gewoon een middel, net als dat een firewall een middel is. Met een aantal van deze middelen bij elkaar heb je al een redelijke out-of-the-box beveiliging klaar staan.

[Reactie gewijzigd door Schnoop op 22 juli 2024 23:12]

Ik zit regelmatig wat te prutsen met een Virtex II dev bordje met daarop twee PPC cores, je kan er prima in VHDL ethernet, RS232, RS485 aansturen (die MP/profibus zegt me niks maar lijkt mij sterk). Uiteindelijk heb ik in nog geen drie maanden vanuit nul-ervaring zelf een VGA (d-sub) aansturing geschreven op het ding. Je kan hierop ook een linux variant draaien die je aanvult met je webserver, tralalala maar om te claimen dat dat te duur is, is onzin, consumenten routers á 40 euro draaien ook embedded linuxen met custom hardware.

Het is ook vrij duidelijk geworden dat dergelijke systemen verre van goedkoop zijn dus om dan als leverancier de el-cheapo-tour op te gaan is eigenlijk gewoon gortig. Sowieso snap ik niet waarom Windows überhaupt in de mix zit, maar bon, ze gebruiken het ook op leger booten dus er zal wel een reden ergens zijn.
Ik geef niet aan dat het duur is om een linux variant i.p.v. Windows variant te maken, ik geef enkel aan dat het duur is om een eigen OS te bouwen in plaats van een bestaand OS te gebruiken.

En ook mij is het enigszins onduidelijk waarom er veelal Windows i.p.v. Linux o.i.d. gebruikt wordt. Ik kan wel een aantal dingen "gokken" zoals het betere driver support (touchscreen/netwerkkaarten/vga?) waardoor je hardware support wat breder is.
Denk er wel aan dat productie op de eerste plaats komt ALTIJD! en dat updaten die produktie in gevaar brengt.
Als je een update uitvoert alleen omdat de update er is en de productie valt stil, dan heb je een groot probleem, een productie chef heeft niets en dan ook helemaal niets met enig argument omtrent veiligheid.

Overigens zijn de ISA95 en ISA 99 normen uitstekend te gebruiken om dergelijke problemen op te lossen, alleen werken vrij weinig bedrijven er nog mee.
Denk er wel aan dat productie op de eerste plaats komt ALTIJD! en dat updaten die produktie in gevaar brengt.
En niet updaten doet dat dus ook. Wanneer er exploits zijn en jij besluit niet te updaten om dat te verhelpen en je verleent daardoor indirect een kwaadwillende toegang, dan ligt je productie ook stil.

En nu?
lees ISA99, die legt deze discussie geheel uit.

Een productiechef heeft nooit en dan ook helemaal nooit enige boodschap aan jouw mening op dit punt, of je nu gelijk hebt of niet vanuit IT-oogpunt, zo simpel ligt dat.
Je gaat daar dan ook op geen enkele manier doorheen komen, men weigert gewoon een update toe te staan als je geen zuivere 100% garantie durft/kan geven op geen uitval.

Zou dus betekenen dat je een schaduw systeem moet opzetten en daar is geen geld voor, dus ga je door zoals altijd.

Een productiechef heeft altijd het laatste woord op dit soort gebieden.

[Reactie gewijzigd door Anoniem: 44174 op 22 juli 2024 23:12]

Een verouderde Windows versie of niet updaten hoeft niet een probleem te zijn.
Als het echt niet anders kan dat het systeem toch via internet benaderd moet kunnen worden, is het ook mogelijk om voor een VPN/RemoteDesktop/VLC oplossing te kiezen, zoals bv. Juniper SA Series SSL VPN Appliances.
Hiermee scherm je toch het verouderde systeem volledig af van internet en kan het systeem alleen benaderd worden via een beschermd en volledig up-to-date te houden portal. Je bent wat dit betreft dan ook niet meer afhankelijk van de leverancier van het scada-systeem.
Anoniem: 288924 @ThaDude30 januari 2012 21:18
Je moet wachten tot de leverancier de update vrijgeeft. Anders kan niet gegarandeerd worden dat het stabiel werkt en kan je problemen krijgen met ondersteuning. Daarnaast heeft zo'n update de nodige voeten in de aarde voor grotere systemen.
Interessant verhaal,
Het verbaast mij altijd hoeveel verschillende fabrikanten systemen ontwerpen die totaal afhankelijk zijn van een specifieke versie van windows ....
Bij mijn vorige werkgever waren een aantal apparaten die bestuurd werden dmv windows NT software; de besturingspc hingen direct aan het net |:(
Als daar iemand op inbreekt dan is er enkel een HPLC machine of iets dergelijks niet te gebruiken, maar toch

[Reactie gewijzigd door dragonfly28 op 22 juli 2024 23:12]

Een groot gedeelte van de procesbeheersing is afhankelijk van Windows-features. OLE-objecten bijvoorbeeld. Als je een Excel tabelletje plakt in Word, wat je vervolgens kan wijzigen door er op te dubbel-klikken, da's een OLE object. Zie het als een dynamische verwijzing naar een ander programma.
Datzelfde mechanisme wordt ook gebruikt binnen veel Scada systemen. OPC: OLE objects for Process Control. Daarmee worden alle verschillende stukjes software aan elkaar gelijmd.

Die implementatie kan verschillen tussen Windows versies, waardoor het boeltje in de soep kan lopen. Daar zijn leveranciers van die Scada spullen bang voor althans. Daarom doen ze allemaal een versie string check bij opstarten. Matcht de string niet, niet opstarten. Ookal zou het gewoon gewerkt hebben.

En er is het commerciële aspect natuurlijk. Klanten op kosten jagen..
Tja, als je 2 jaar en 3 maanden moet wachten voordat Siemens z'n belangrijkste systeem, PCS7, geschikt heeft gemaakt voor windows 7, dan begrijp je gelijk al de helft van alle security problemen. Daarbij is windows Vista zelfs overgeslagen. Dus dan sla je jaren van updates aan de windows omgeving over. Siemens = Epic Fail

Ik heb 2 maanden geleden nog aan een niet essentieel deel van een nieuwe kolencentrale gewerkt waarbij dit pakket draaide op windows XP!
PCS7 maakt o.a. gebruik van WinCC en Siemens PLC's met ethernet. Dit is de combinatie waar het Stuxnet virus met Windows exploits op los ging.

Complete chemische plants in de Botlek draaien op dit soort systemen, en vaak is het voor Control Engineers mogelijk om via VPN service te verlenen. Zo iemand kan dan een complete plant in honderd laten draaien. Ik zou als terrorist zo iemand worden, gijzelen of chanteren om men doel te bereiken. Ik zou bijna voor willen stellen dat iemand die deze bevoegdheid krijgt een AIVD screening doorloopt.
Groot voordeel is nog wel dat al die fabrieken ook nog mechanische failsafes hebben, kleppen die dicht gaan of juist open bij bepaalde druk of temperatuur en vaak worden producten bij een ongecontroleerde shutdown eerst nog door een scrubber geleid voor het de lucht in gaat. Tuurlijk is het ongezond om er onder te staan en is het niet de bedoeling, maar de mogelijkheid om de hele fabriek via internet uit elkaar te laten klappen is er niet.

Als terrorist is het 100 keer makkelijker om het terrein binnen te dringen en gewoon de boel fysiek op te blazen, dan werken de failsafes niet meer. Daarnaast zijn er in elke fabriek 24/7 mensen aanwezig die de systemen controleren dus al zou die ene persoon gegijzeld worden dan nog zullen anderen ingrijpen voor het echt mis gaat.

En ja ik ben wel een heel aantal keren in verschillende fabrieken en controlekamers geweest in de Botlek en andere regios met chemische fabrieken in binnen en buitenland.
Ik werk er dagelijks en ben blij dat jij er alleen geweest bent.
Er is veel meer mogelijk dan je denkt.

Mechanische failsafes vangen alleen het eerste probleem op, daarna zal er nog wel meer moeten worden ingegrepen.
Op het moment dat een breekplaat klapt, dan staat die tank als het ware open (er is immers een gat waardoor de druk weg kon) je kan dan niet altijd zomaar even daar rond gaan lopen om wat op te lossen.
Of denk je werkelijk dat door het wegvallen van de druk opeens alles sluit en daarmee er geen probleem meer is?

Denk je eens in als de software is beinvloed en in een regelkamer er niets van te zien is dat de breekplaat is gegaan. Denk je eens in als allerlei kritieke punten softwarematig worden opgerekt of opgeheven! En zo kan ik nog wel even doorgaan.

Om hard te stellen dat er geen enkele mogelijkheid toe is... ik zou mijn handen er niet voor in het vuur durven steken, integendeel zelfs.
Kritieke situaties zijn best te creeeren.
Tja, als je 2 jaar en 3 maanden moet wachten voordat Siemens z'n belangrijkste systeem, PCS7, geschikt heeft gemaakt voor windows 7, dan begrijp je gelijk al de helft van alle security problemen. Daarbij is windows Vista zelfs overgeslagen. Dus dan sla je jaren van updates aan de windows omgeving over. Siemens = Epic Fail
Dat Vista niet support is wil niet zeggen dat je niet alle patches van XP kan installeren ;) XP (SP3) word nog steeds support door Microsoft, en daar komen ook nog netjes updates voor uit.
Infact, er is een rede waarom bedrijven niet meteen over gaan op een nieuw OS zodra dat uit is. In het begin zitten er vaak toch nog kleine bugs in. En bij een ouder OS zijn er al veel van die bugjes opgelost.

[Reactie gewijzigd door TMDevil op 22 juli 2024 23:12]

Op dit item kan niet meer gereageerd worden.