Ads 468x60px

perjantai 4. heinäkuuta 2014

Havex / Dragonfly / Energetic Bear: kohteena automaatiojärjestelmät

Viime päivinä on uutisoitu runsaasti haittaohjelmasta, joka vaikuttaa olevan kohdennettu energiasektorin toimijoihin ja automaatiojärjestelmiin (Industrial Control Systems, ICS). Itse asiassa Havex-nimellä tunnettu haittaohjelma ja sen taustalla vaikuttava ryhmä ovat olleet virustorjuntaohjelmistojen valmistajien ja muiden tahojen tiedossa jo pidemmän aikaa.

Varsinainen uutinen tuli viime viikolla, kun F-Secure raportoi ensimmäisenä haittaohjelman ja sen taustatoimijoiden vaikuttavan olevan kiinnostuneita nimenomaan automaatiojärjestelmistä (Havex Hunts For ICS/SCADA Systems, 23.6.2014). Symantec, joka kutsuu ryhmää nimellä Dragonfly, julkaisi tällä viikolla oman analyysinsä aiheesta (Dragonfly: Western Energy Companies Under Sabotage Threat, 30.6.2014). Vaikka laajan ja paikoitellen raflaavan uutisoinnin perusteella voisi päätellä toisinkin, on tällä hetkellä käytössä olevan tiedon perusteella vielä vaikea lähteä arvioimaan, kuinka vakavasta asiasta on kyse. Potentiaalisesti erittäin vakavasta, mutta toistaiseksi olemme nähneet ainoastaan tiedusteluun viittaavia toimia.

Eräs pidempään Dragonflyn toimintaa tarkkaillut taho on CrowdStrike, joka käyttää ryhmästä nimeä Energetic Bear ja kertoo raportissaan toiminnan kohdistuneen erityisesti energiasektorin toimijoihin (CrowdStrike: 2013 Year in Review: Actors, Attacks, and Trends, 22.1.2014). Ohjelman aikaleimojen (käännösaika) ja hallintapalvelimien aktiviteettien ajoittumisen perusteella CrowdStrike arvioi ryhmän toimivan Venäjältä käsin. Hyökkäyksen kohteiden sijainnin ja luonteen, sekä toiminnan laajuuden ja ammattimaisuuden perusteella monet arvioivat, että ryhmällä saattaa olla kytköksiä Venäjän valtioon tai että se saattaa olla Venäjän rahoittama. Uutisotsikoissa haittaohjelma onkin jo nimetty venäläiseksi, mutta kuten tyypillistä kyberhyökkäysten osalta, on todellisen alkuperän osoittaminen erittäin vaikeaa ja se jää yleensä enemmän tai vähemmän spekulaation varaan.

Suomessa asiasta uutisoivat mm. Helsingin Sanomat ja Tekniikka & Talous. Maailmalla aiheeseen tarttuivat useat arvostetut julkaisut ja verkkosivut, mm. Wall Street Journal, Financial Times, New York Times ja CNN (linkkejä uutisiin ja muihin lähteisiin on listattu kirjoituksen lopussa). Uutistoimistot ja verkkosivustot tekevät nähdäkseni sitä mitä niiden pitääkin, eli tuovat asioita laajemman yleisön tietoon referoimalla mielenkiintoisten raporttien sisältöä parhaansa mukaan. Toimittajat eivät ymmärrettävästi voi olla jokaisen uutisoimansa aiheen asiantuntijoita, uutiset pitää saada pikaisesti julkaistua, ja värikkäät otsikot myyvät. Nämä tekijät huomioon ottaen suosittelen lukemaan muutaman uutisen aiheesta pikaisen yleiskuvan saamiseksi, ja siirtymään sen jälkeen F-Securen ja Symantecin blogikirjoitusten pariin tiedon "alkulähteille".

Vähemmän teknisten lukijoidenkaan ei kannata säikähtää F-Securen kirjoituksen sisältämiä koodinpätkiä, sillä itse teksti on erittäin hyvä ja kiinnostava vaikka osa yksityiskohdista menisikin ohitse. Kannattaa myös lukea Symantecin tarkempi raportti aiheesta (pdf löytyy täältä) ja Yhdysvaltain ICS-CERT:n varoitus ja tiedote.. Kooste aiheeseen liittyvistä resursseista löytyy myös ScadaHackerin sivuilta, ja kuten tavallista, Dale Peterson ja Digital Bond tarjoaa hyviä kannanottoja. Jos työskentelet automaation (tietoturvan) parissa tai olet muuten kiinnostunut aiheesta, suosittelen ehdottomasti lisäämään kolme viimeistä lähdettä lukulistallesi, jos ne eivät siellä jo ole.

En käsittele tässä yksityiskohtaisemmin haittaohjelman toimintaa, koska se on jo ansiokkaasti tehty muualla - asiaa paremmin ymmärtävien toimesta. Pyrin kuitenkin käymään läpi nimenomaan automaation tietoturvan kannalta kiinnostavia kohtia, ja pohtimaan millaisia puolustuskeinoja olisi mahdollisesti voitu hyödyntää.

Mistä on kyse, hyvin lyhyesti:

Havex-haittaohjelmaa on tämän hetkisen tiedon mukaan levitetty ainakin kolmella tavalla:
  1. Lähettämällä haitallinen liitetiedosto sähköpostitse. Kyseessä kohdennettu kampanja, yritykset ja vastaanottajat on valikoitu.
  2. Saastuttamalla "tavallisia" verkkosivuja, joilla vierailevat saavat haittaohjelmatartunnan. Jälleen kohdennettu, viimeisimmässä vaiheessa valittu sellaisia sivustoja, joilla energia-alan toimijat mahdollisesti vierailevat. Tästä käytetään termiä Strategic Web Compromise, SWC, tai watering hole attack.
  3. Saastuttamalla valmistajien verkkosivuilta ladattavia ohjelmistojen asennuspaketteja. Kohteena ollut tämän hetkisen tiedon mukaan vähintään kolme nimenomaan automaatioalan laite/ohjelmistotoimittajaa. Myös tästä levityskeinosta käytetty termiä watering hole attack, koska tässäkin lopulliseen kohteeseen pyritään pääsemään sellaisten välietappien kautta, joista lopullinen kohde todennäköisesti olisi kiinnostunut.
Mitä haittaohjelma (muun muassa) tekee kohteessa?
  1. Yrittää ottaa yhteyden tunnettuihin verkkosivuistoihin/palvelimiin selvittääkseen onko sillä yhteys Internetiin. Jos on, haittaohjelma ottaa yhteyden joihinkin useista hallintapalvelimista.
  2. Hallintapalvelimelta ladataan ohjeet jatkotoiminnalle, eli lisäkomponentteja suoritettavaksi.
  3. Komponentit keräävät monenlaista tietoa ja lähettävät sitä hallintapalvelimelle. Mielenkiintoinen on komponentti, joka analysoi lähiverkkoon kytkettyjä laitteita ja erityisesti etsii OPC-palvelimia ja kerää niistä eri tietoja. 

Miksi tätä kutsutaan "ICS/SCADA-haittaohjelmaksi"?

Yllä esitettyä tai hyvin vastaavaa toimintamallia noudattavat monet haittaohjelmat, eikä tietyn toimialan valitseminen kohteeksi ole myöskään mitenkään ennenkuulumatonta. Mikä nyt käsiteltävästä tapauksesta sitten tekee erikoislaatuisen ja automaatiospesifin?

Ensinnäkin se, että levittämiskeinoista kolmannessa (asennuspakettien saastuttaminen) on valittu nimenomaan automaatioalan toimittajien sivuilta ladattavia asennuspaketteja. Jos olisi haluttu vain saastuttaa mahdollisimman monia kohteita toimialasta riippumatta, olisi varmasti parempiakin vaihtoehtoja löytynyt. Toisekseen se, että ohjelma monen muun keräämänsä tiedon lisäksi vaikuttaa etsivän lähiverkosta OPC-palvelimia.

Lyhyesti: mikä on OPC?

OPC on kokoelma standardeja, jotka on kehitetty ratkaisuksi yhteensopivuusongelmiin automaatiomaailmassa. Alunperin se on lyhenne sanoista OLE (Object Linking and Embedding) for Process Control. Alkuperäinen versio on 1990-luvulta ja perustuu Microsoftin COM/DCOM-teknologiaan. Idea on vähentää työmäärää, kun jokaiseen eri ohjelmistoon ei tarvitse kirjoittaa erillistä kommunikointirajapintaa jokaiselle mahdolliselle automaatiolaitteelle. Karkeasti esittäen: hyödynnettäessä OPC:tä riittää, että jokainen toteuttaa OPC:n mukaisen rajapinnan, ja pystyy sitten keskustelemaan minkä tahansa muun OPC:n mukaisen laitteen/ohjelmiston kanssa. Ilman yhteistä standardia tarvittava rajapintojen määrä kasvaa räjähdysmäisesti kommunikoivien osapuolien määrän kasvaessa.

Alkuperäisen OPC:n ilmestymisestä on pian kaksikymmentä vuotta, ja aikanaan se auttoi ratkaisemaan merkittävän ongelman. Siinä on myös merkittäviä heikkouksia - ei vähiten tietoturvan kannalta - jotka on, jos ei muuten niin jälkiviisaana, helppo havaita. Joka tapauksessa se on yhä erittäin laajassa käytössä automaatiossa. Sittemmin OPC on kehittynyt merkittävästi, mm. uudemman Unified Architecturen (OPC UA) -määrittelyn myötä, joka ei enää käytä COM/DCOM-teknologiaa. Lyhenteen merkityskin on muutettu muotoon "Open Platform Communications". ICS-CERT:n tiedotteen mukaan tämän hetken tunnetut haittaohjelmakomponentit Dragonfly-operaatiossa etsivät nimenomaan OPC:n vanhemman ("classic") version palvelimia, mutta eivät ole kiinnostuneita uudemmista OPC UA:sta.

Seuraava Stuxnet?

Ymmärrettävästi tapaus on yhdistetty aiempaan automaatiojärjestelmiin kohdennettuun haittaohjelmaan, Stuxnetiin. Kuitenkin tämän hetken tiedon perusteella yhteistä vaikuttaisi olevan lähinnä se, että kohteena on automaatiojärjestelmä(t) ja taustalla saattaa olla valtiollisia toimijoita. Toistaiseksi tässä tapauksessa on vain kerätty tietoa, ei aiheutettu varsinaista vahinkoa fyysisille järjestelmille. Vain aika näyttää, joudummeko seuraavaksi todistamaan vakavampia seuraamuksia.

Todettakoon myös, että on haastavuudeltaan omaa luokkaansa luoda haittaohjelma, joka saa kohteena olevan automaatiojärjestelmän toimimaan juuri halutulla tavalla (Stuxnet). Se vaatii syvällistä kohteen tuntemusta. Todennäköisesti paljon helpompaa on luoda ohjelma, joka tekee sattumanvaraisia muokkauksia, mahdollisesti pysäyttäen automaatiojärjestelmän tai pahimmillaan aiheuttaa (sattumanvaraista) tuhoa. Kohteen kannalta molemmat vaihtoehdot ovat tietysti äärimmäisen ikäviä.

Havex-haittaohjelman levittämistä ICS-toimittajien ohjelmistojen asennuspakettien kylkiäisenä voidaan pitää "innovatiivisena" keinona, ja nähdä siinäkin mielessä yhteneväisyyksiä Stuxnetiin. Tämäkin huomioon ottaen tällä hetkellä tiedetyn perusteella Dragonfly / Energetic Bear -operaatio ei ole monimutkaisuudessaan Stuxnetin luokkaa.

Mitä suojauskeinoja olisi voitu käyttää?

Hyökkäys voidaan mieltää useista vaiheista muodostuvaksi ketjuksi, ja eri vaiheita voidaan joko tehdä hyökkääjälle hankalammaksi tai hyökkäys voidaan kokonaan pysäyttää. Käsitellään seuraavaksi muutamia kiinnostavia suojautumismahdollisuuksia. Torjumista voidaan yrittää esimerkiksi estämällä:
  • haittaohjelman leviäminen ja tartunnan saaminen
  • koneelle päätyneen ohjelman suoritus 
  • jo suoritettavaksi päätyneen haittaohjelman "soitto kotiin" eli yhteydenotto hallintapalvelimelle 
  • auktorisoimaton pääsy OPC-palvelimelle
  • ...
Haittaohjelman leviämisen vaikeuttaminen tai estäminen

Levityskeinot 1. ja 2., eli haittaohjelmien levittäminen sähköpostilla tai verkkosivujen kautta on hyvin yleistä, ja eri suojauskeinoja on myös paljon. Tänä päivänä tuskin kukaan kuitenkaan ajattelee, että näiltä tartunnoilta voitaisiin kokonaan välttyä. Osa koneista saa luultavasti tartunnan, mutta mitkä koneet ja missä? Kohteissa, joissa on automaatiojärjestelmiä, on tärkeää pohtia koko verkon arkkitehtuuria: onko tarpeen että samalla koneella selaillaan Internetiä ja luetaan sähköposteja ja ollaan toisaalta yhteydessä OPC-palvelimille? Vastaus voi olla tapauskohtainen, mutta nykyisissä toteutuksissa on varmasti parantamisen varaa. Asiaa hankaloittaa myös se, että OPC on turvallisten palomuuriavausten suhteen erittäin haastava kommunikaatiokeino. Luonnollisesti mille tahansa toimistoverkon työasemalle päätyvä haittaohjelma on ikävä asia. Se on kuitenkin pieni murhe verrattuna haittaohjelmaan koneella, jolla on kyky lukea ja kirjoittaa tietoja OPC-palvelimelle ja siten mahdollisesti ohjata automaatiojärjestelmän laitteita.

Entä sitten haittaohjelman levittäminen asennuspakettien kylkiäisenä? Pohjimmiltaan on kyse tutusta ongelmasta: miten varmistat, että ajettava koodi on peräisin luotettavasta lähteestä eikä sitä ole manipuloitu? Esimerkiksi piraattiversio maksullisesta ohjelmasta tai epäluotettavasta lähteestä ladattu ilmaisohjelma voi periaatteessa sisältää mitä tahansa haitallisia komponentteja. Tässä tapauksessa lähteet olivat kuitenkin luotettavana pidettyjä.

Ilmeisesti toimittajien palvelimilla olleita haavoittuvuuksia hyväksikäyttämällä hyökkääjä onnistui korvaamaan verkkosivuilla jaettavat asennuspaketit omilla, haittaohjelman sisältämillä versioilla. Luonnollisesti toimittajien tulee parhaansa mukaan suojautua tällaiselta tilanteelta (tutuilla keinoilla kuten päivityksistä huolehtimisella, asianmukaisilla kovennuksilla, jne.) Tässä on myös takuuvarmasti parantamisen varaa. Silti, tuskin kukaan lähtee ajatuksesta, että minkään toimittajan yksikään palvelin ei ole ikinä haavoittuva.

Merkittävästi turvallisuutta parantava ratkaisu on tietysti koodin digitaalinen allekirjoittaminen. Näin voidaan (ainakin yrittää) varmentaa, että asennuspaketti on peräisin luotettavasta lähteestä ja ettei sitä ole muokattu. On huomattava, että tämä keskustelu perustuu vain oletukselle, että koodia ei oltu allekirjoitettu. Asiaa ei ole varsinaisesti mainittu alkuperäisissä lähteissä, eikä tietääkseni toistaiseksi ole virallisesti julkistettu toimittajien nimiä, josta saastuneet paketit oli ladattavissa. Yleisesti ottaen alalla ohjelmistot ja päivitykset eivät läheskään aina ole allekirjoitettuja.


Toki allekirjoitus on hyödyllinen vain mikäli allekirjoitusavainten turvallisuudesta huolehditaan. Teoreettinen riski luotetulla avaimella allekirjoitetulle haittaohjelmalle on aina olemassa, mutta valtaosa asiantuntijoista piti aiemmin sellaista hyvin epätodennäköisenä. Myös tämä kuvaa Stuxnetin edistyksellisyyttä: se osoitti, että myös käytännössä voidaan toteuttaa hyökkäys, jossa haittakoodi on allekirjoitettu luotettavana pidetyllä avaimella. Sittemmin tällaiset haittaohjelmat ovat muutenkin yleistyneet, mutta niiden luominen vaatii edelleen merkittävästi enemmän resursseja kuin allekirjoittamattoman haittaohjelman. Olisi siis erittäin suositeltavaa, että ohjelmat ja päivitysversiot allekirjoitettaisiin myös automaatioalan toimittajien toimesta: 
Haittaohjelman yhteydet muihin koneisiin

Asentumisen jälkeen haittaohjelma pyrkii ottamaan yhteyden hallintapalvelimelle, josta se lataa seuraavat ajettavat komponentit, ja jonne se lähettää keräämiään tietoja. On huomattava, että ilmeisesti haittaohjelma ei edes yritä ottaa yhteyttä hallintapalvelimeen, ellei se ensin pysty toteamaan, että käytössä on toimiva yhteys Internetiin (yrittämällä ottaa  yhteyden tunnettuihin verkkosivustoihin).

Eräs suojakeino on yrittää tunnistaa tällaiset yhteydet hallintapalvelimiin ja estää ne. Tyypillisesti käytetyt portit ovat sellaisia, että palomuurilla liikennettä on hankala tai mahdoton estää. Mikäli hallintapalvelimet eivät ole entuudestaan tunnettuja ja päätyneet suodatuslistoille, on torjuminen hankalaa myös IDS/IPS-ratkaisuilla. Tässä tapauksessa haittaohjelman toiminta on niin tyypillistä, että luultavasti kehittyneimmät anomaliapohjaiset suojausteknologiat (FireEye ja vastaavat) pystyvät tunnistamaan haittaohjelman ja estämään callback-yhteydet. Näitä teknologioita on kuitenkin toistaiseksi käytössä vielä rajoitetusti.

Jälleen, vastaava tietoja keräävä haittaohjelma on ikävä missä kohteessa tahansa, mutta erityisen ikävä jos se pyrkii (ja pystyy) kommunikoimaan automaatiojärjestelmien kanssa. Kuvitellaan tilanne, jossa järjestelmän ja verkon arkkitehtuurista riippuen haittaohjelman saastuttaneella koneella on
  1. yhteys Internetiin ja mahdollisuus kommunikoida komentopalvelimen kanssa 
  2. yhteys OPC-palvelimeen (ja mahdollisesti oikeus lukea/kirjoittaa tietoa)
  3. molemmat ylläolevista
Kolmas tilanne on kahta ensimmäistä merkittävästi ikävämpi, koska tällöin hyökkääjä voi mahdollisesti ensin kysellä tietoja OPC-palvelimelta, ja tiedon perusteella antaa ohjauskäskyjä palvelimen kautta automaatiolaitteille. Stuxnet osoitti, että myös ilman tällaista aktiivista hallintayhteyttä voidaan vaikuttaa automaatiojärjestelmään halutulla tavalla. Tällainen "sokkona" toimiminen on kuitenkin ymmärrettävästi erittäin paljon haastavampaa. Aktiivisen yhteyden muodostamisen jälkeen ohjausten välittäminen automaatiolle on sitä vastoin (tietyin oletuksin eli pahimmassa tapauksessa) lähes triviaalia.

Tämä ei ole ehdoton patenttiratkaisu kaikkeen, mutta järjestelmien ja verkkojen nykyisen tilanteen huomioon ottaen panostamalla oikeanlaiseen arkkitehtuuriin voidaan merkittävästi parantaa tietoturvaa. Riippuu paljon tilanteesta ja toiminnallisista vaatimuksista mitä voidaan tehdä, mutta uskoisin että yllä esitetyistä skenaarioista ensimmäinen ja toinen ovat vähemmän epämukavia kuin kolmas.

OPC:n tietoturva

Perinteinen OPC on monessa suhteessa haastava tietoturvan kannalta. Aihe on laajahko, enkä tässä kirjoituksessa paneudu siihen sen syvemmin. Iso ongelma on OPC:n käyttämä dynaaminen porttien allokointi, mikä perinteisessä palomuurissa käytännössä pakottaisi tekemään niin laajat avaukset, ettei palomuurista ole juuri hyötyä. Toinen iso ongelma on käyttöoikeuksien ja pääsynhallinnan määritykset. Niiden konfigurointi on hankalaa ja oikeudet jäävät hyvin laajoiksi - tämä saattaa olla jopa valmistajan suositus. Myös OPC:n käyttämät protokollat, mm. DCOM ja RPC voivat sisältää vakavia haavoittuvuuksia.

Automaatiomaailmalle tyypillisesti tärkeintä on järjestelmän toimivuus ja tuotannon pyöriminen. OPC:n konfiguroiminen mahdollisimman tietoturvallisesti on varsin hankalaa, ja aiemmin tietoturvan merkitys automaatiossa on ollut paljon vähäisempi. Yritykset konfiguroida OPC tietoturvallisemmaksi johtavat helposti siihen, että kommunikaatio ei enää toimi. Tämä on johtanut siihen, että usein pyritään vain saamaan järjestelmä toimimaan välittämättä tietoturvasta. Ongelmat ovat kyllä varsin hyvin tiedossa. Niihin on myös olemassa erilaisia ratkaisuja, tietoturvallisen konfiguroinnin lisäksi esimerkiksi OPC:n tunnelointi palomuurissa ja uudemman OPC-UA:n käyttö. Monessa tapauksessa kehitystoimiin on varmasti myös ryhdytty. Dragonfly-operaatio toimii toivottavasti herätteenä näiden asioiden pikaiselle kehittämiselle niissäkin kohteissa, jossa tietoturvaa ei ole aiemmin riittävästi huomioitu.

Kävinkö väärässä pubissa? - tiedonjako saastuneista "juomapaikoista"

Huomionarvoista on, että toistaiseksi missään ei ole (ainakaan tietääkseni) virallisesti julkaistu niiden automaatiotoimittajien nimiä, joiden sivuilta saastuneita asennuspaketteja oli ladattavissa. Myöskään Strategic Web Compromise -hyökkäyksen kohteiksi joutuneita verkkosivuja ei ole ilmoitettu. Tämä tieto helpottaisi merkittävästi sen arviointia, kuinka todennäköisesti oma organisaatio on joutunut hyökkäyksen kohteeksi.

Toki voi olla perusteltua, että esimerkiksi Symantec ja F-Secure eivät voi tai halua tätä tietoa julkisesti jakaa. Digital Bondin Dale Peterson kritisoi puutteita tiedonjaossa - jos ei yhtiöiden toimesta niin esimerkiksi CERT:ien tulisi (voida) jakaa tietoa. Kirjoituksessa on myös mainittu nimeltä (luultavasti) tunnistetut kaksi kolmesta automaatiotoimittajasta, joiden sivuilla saastutettuja asennuspaketteja jaettiin. Onnistuneen hyökkäyksen kohteeksi joutuminen ei varmasti tee hyvää yrityksen maineelle, mutta yleensä vielä pahempaa on viivytellä tiedon julkaisemista, jos se kuitenkin ennen pitkää tulee julki. 

Viime hetken päivitys: eWon -yritys kertoo verkkosivuillaan, että heihin kohdistunut murto liittyy nimenomaan tähän tapaukseen.
Mielenkiintoinen idea on esitetty myös Digital Bondin toisen kirjoituksen lopussa: eikö ICS-CERT:n tulisi käydä läpi eri haittaohjelmanäytteitä, ja yrittää selvittää mitkä niistä ovat mahdollisesti kohdennettuja automaatiojärjestelmiin? Jos tällainen idea toteutettaisiin, voisi se pidentää varoitusaikaa, kun tieto automaatiojärjestelmiin kohdennetuista haittaohjelmista voisi saavuttaa alan toimijat jo ennen kuin hyökkäys pääsee täyteen vauhtiin.

Yhteenveto

Mitä tästä kaikesta pitäisi ajatella? Tähän mennessä nähdyn perusteella uutisointi on ollut paikoin liioiteltua. Silti tämä ja vastaavat operaatiot ovat mahdollisesti vain alkusoittoa ja tiedon keräämistä kohteista. Seuraavat vaiheet voivat potentiaalisesti olla katastrofaalisia. Tämän tyyppisen operaation voisi hyvin kuvitella olevan kybersodankäynnin vaikuttamiskyvyn kehittämisen ensimmäisiä vaiheita. Voi hyvin olla, että eri valtioilla ja muillakin toimijoilla on jo nyt keinot vaikuttaa toisten maiden kriittiseen infrastruktuurin. Rikollisuuden, haktivismin ja terrorismin tapauksissa kybervaikuttamisen kyvykkyyttä todennäköisesti jossain vaiheessa myös käytetään, tai ainakin halutaan muilla keinoin todistaa että sellaista on. Valtiollisen tason toimijoiden tapauksessa voi olla, että iskukykyä kehitetään "pahimman varalle", mutta sitä ei välttämättä koskaan käytetä tai osoiteta olevan olemassa, jos tilanne ei sitä vaadi.

Joka tapauksessa viimeistään nyt on selvää, että on olemassa haittaohjelmia ja hyökkääjiä, jotka ovat kiinnostuneita nimenomaan automaatiojärjestelmistä. Spekuloitavaksi jää, millaista kyvykkyyttä ja millä toimijoilla on tällä hetkellä olemassa. Vain aika näyttää mitä seuraavaksi tulee tapahtumaan. Uskaltaisin veikata, että automaatiojärjestelmiä ja kriittistä infrastruktuuria vastaan tehtävät hyökkäykset tulevat yleistymään. Toivon mukaan tietoturvaan panostetaan ennen kuin vahinkoa tapahtuu.

Suunnitelmallisen automaation tietoturvan kehittämisen lisäksi välittöminä toimenpiteinä on suositeltavaa viimeistään nyt päivittää virustorjuntaohjelmistojen tunnisteet ja tarkistaa järjestelmät tartuntojen varalta. Myös mahdollisten IDS/IPS -järjestelmien tunnisteet tulee päivittää. Yleisiä mitigointikeinoja ja mm. OPC:n tietoturvan kehitystoimenpiteitä on listattu ICS-CERT:n varoituksen ja tiedotteen lopussa, ne on myös suositeltavaa käydä läpi.

Aiheesta muualla: 

23.6.2014 F-Secure: Havex Hunts For ICS/SCADA Systems 
26.6.2014 Digital Bond: Havex / Stuxnet / ICS-CERT / DHS
27.6.2014 ICS-CERT: Alert (ICS-ALERT-14-176-02A) ICS Focused Malware
30.6.2014 Symantec: Dragonfly: Western Energy Companies Under Sabotage Threat
30.6.2014 ICS-CERT: Advisory (ICSA-14-178-01) ICS Focused Malware
2.7.2014 Digital Bond: Havex Hype & Unhelpful Mystery
2.7.2014 McAfee: Operation Dragonfly Imperils Industrial Protocol

3.7.2014 Viestintävirasto: Tietoturva Nyt! Energiasektoriin kohdistuva kybervakoilukampanja

Symantec White Paper (pdf)
CrowdStrike Report (pdf)
SCADAHacker.com -resurssisivu

Uutisointia:
24.6.2014 Helsingin Sanomat: Uusi verkkovakoilulöytö: Rikolliset saastuttavat teollisuuden automaatiojärjestelmiä
30.6.2014  Tekniikka & Talous: Venäläinen haittaohjelma iski satoihin eurooppalaisiin sähkövoimaloihin
1.7.2014 Helsingin Sanomat: Verkkohyökkääjät iskivät Euroopan ja Yhdysvaltain energiayhtiöihin

24.6.2014 PCWorld: New Havex malware variants target industrial control system and SCADA users
24.6.2014 SecurityWeek: Attackers Using Havex RAT Against Industrial Control Systems
24.6.2014 ArsTechnica: Attackers poison legitimate apps to infect sensitive industrial control systems
25.6.2014 SCMagazine: 'Havex' malware strikes industrial sector via watering hole attacks
26.6.2014 Darkreading.com: As Stuxnet Anniversary Approaches, New SCADA Attack Is Discovered
26.6.2014 The Register: Attackers fling Stuxnet-style RATs at critical control software in EUROPE
30.6.2014 Financial Times: Energy companies hit by cyber attack from Russia-linked group (vaatii kirjautumisen)
30.6.2014 The New York Times: Russian Hackers Targeting Oil and Gas Companies
30.6.2014 Daily Mail: Over 1,000 European and US energy firms hit by Russian 'Energetic Bear' virus that let hackers take control of power plants
1.7.2014 BBC: Energy firms hacked by 'cyber-espionage group Dragonfly'
2.7.2014 CNN: Russia attacks U.S. oil and gas companies in massive hack

Ei kommentteja:

Lähetä kommentti