Miksi moderni kyberturvallisuus on rakennettava kestämään hyökkäyksiä

Kyberturvallisuutta pidettiin pitkään kerroksena, joka lisättiin järjestelmien päälle vasta niiden rakentamisen jälkeen. Palomuuri tänne, päätelaitesuojaus tuonne, ja vaatimustenmukaisuus dokumentoitiin lopuksi. Tämä malli on hiljalleen murentunut.

Tämän päivän todellisuus on toinen. Hyökkääjät liikkuvat minuuteissa, eivät päivissä. Infrastruktuuri jakautuu pilveen, paikallisiin ympäristöihin ja operatiiviseen teknologiaan. Käyttäjät ja laitteet muodostavat yhteyksiä kaikkialta. Tässä ympäristössä vanha kysymys “miten pidämme hyökkääjät ulkona?” ei enää ole oikea kysymys.

Oikea kysymys kuuluu: kun hyökkääjä pääsee sisään, kuinka paljon vahinkoa hän voi todellisuudessa aiheuttaa?

Tämä on Assumed Breach -ajattelutavan ydin. Se ei tarkoita, että ennaltaehkäisystä luovuttaisiin. Se tarkoittaa, että järjestelmät, prosessit ja reagointisuunnitelmat suunnitellaan sen oletuksen varaan, että ennaltaehkäisy voi joskus pettää ja varmistetaan, että näin tapahtuessa vaikutukset pysyvät rajattuina.

Assumed Breach ei ole enää vain kypsien tietoturvatiimien erikoistunut toimintamalli. Siitä on tulossa oletuslähtökohta kaikille organisaatioille, jotka suhtautuvat digitaalisiin riskeihin vakavasti. Samalla se muokkaa hiljaisesti sitä, miten Secure by Design -periaatetta toteutetaan Pohjoismaissa.

Miksi vanha tietoturvamalli ei enää toimi

Perinteinen, verkon ulkokehään perustuva tietoturva rakentui yksinkertaiselle ajatukselle: verkon sisäpuolella oleviin asioihin voidaan luottaa, ulkopuolella oleviin ei. Tämä oletus lakkasi pitämästä paikkaansa jo kauan sitten, mutta moni organisaatio toimii edelleen kuin se olisi yhä voimassa.

Kolme muutosta on tehnyt vanhasta mallista kestämättömän:

• Verkon rajat ovat hälvenneet. Etätyö, SaaS-palvelut, monipilviympäristöt ja OT-yhteydet tarkoittavat, ettei enää ole selkeää “sisäpuolta”, jota puolustaa.
• Hyökkääjät toimivat nopeammin ja automaattisemmin. Aika haavoittuvuuden julkitulosta sen hyväksikäyttöön on lyhentynyt viikoista tunteihin. Kehitystä vauhdittavat yhä enemmän tekoälypohjainen tiedustelu ja automatisoidut työkalut.
• Seuraukset ovat vakavampia. Kiristyshaittaohjelmat, NIS2-direktiivin mukaiset sääntelyyn liittyvät sanktiot sekä käyttökatkot kriittisillä aloilla, kuten energiantuotannossa ja terveydenhuollossa, tekevät lyhyistäkin tietomurroista aidosti kalliita.

Tässä todellisuudessa oletus siitä, että vahva verkon ulkokehä riittää, ei ole vain vanhentunut, se on riski.

Zero Trust: Assumed Breach -arkkitehtuurin perusta

Assumed Breach -ajattelun ytimessä on Zero Trust. Periaate on suoraviivainen: yhteenkään käyttäjään, laitteeseen tai järjestelmään ei luoteta oletusarvoisesti. Jokainen käyttöoikeuspyyntö varmennetaan joka kerta.

“Kyse ei ole siitä, luotetaanko siihen, että käyttäjä on kirjautunut oikein”, sanoo Henrik Lund, Team Lead Fortinet NetNordicilla. “Kyse on siitä, että varmistetaan jatkuvasti, että kyseessä on oikea käyttäjä, oikealla laitteella, oikeita resursseja käyttämässä.”

Käytännössä tämä tarkoittaa sen varmistamista:

• Kuka käyttäjä on
  Vahva tunnistautuminen, ei pelkkä salasana.
• Mitä laitetta hän käyttää
  Onko laite hallittu, päivitetty ja kunnossa?
• Miksi käyttäjä tarvitsee pääsyn
  Onko pyyntö hänen roolinsa, ajankohdan ja kyseisen resurssin kannalta perusteltu?

Edes oikeat tunnukset vaarantuneella laitteella eivät saisi automaattisesti antaa pääsyä. Ja kun pääsy myönnetään, sen tulisi rajoittua täsmälleen siihen, mitä käyttäjä tarvitsee kyseisen tehtävän suorittamiseen ei enempään. Tätä kutsutaan vähimpien oikeuksien periaatteeksi, ja se on yksi vaikuttavimmista muutoksista, joita organisaatio voi tehdä.

Vaikutusten rajaaminen: miltä Assumed Breach näyttää käytännössä

Jos hyväksytään, että tietomurto tapahtuu ennemmin tai myöhemmin, myös suunnittelun kysymys muuttuu. Kyse ei ole enää siitä, “miten pysäytämme jokaisen hyökkäyksen?”, vaan siitä, “miten varmistamme, ettei läpi päässyt hyökkäys pääse leviämään?”

Tällä ajattelutavan muutoksella on käytännön seurauksia:

• Vaarantuneen kannettavan tietokoneen ei pitäisi antaa pääsyä tuotantopalvelimille.
• Tietojenkalastelun kautta kaapatun ylläpitäjätilin ei pitäisi paljastaa koko identiteettihakemistoa.
• Yhden SaaS-integraation haavoittuvuuden ei pitäisi ketjuuntua läpi liiketoimintajärjestelmien.

Vaikutusten rajaaminen on arkkitehtuurin ominaisuus. Se rakennetaan sisään verkon segmentoinnin, identiteettirajojen, käyttöoikeuksien eriyttämisen ja komponenttien välisten selkeiden luottamussuhteiden avulla. Kun nämä rajat ovat vahvat, tietomurrosta tulee hallittu poikkeama eikä kriisi.

Mikrosegmentointi: laajoista vyöhykkeistä hallittuun pääsyyn

Monet pohjoismaiset organisaatiot luottavat edelleen perinteiseen verkkosegmentointiin, järjestelmät jaetaan muutamaan suureen vyöhykkeeseen, kuten tuotantoon, toimistoverkkoon, vierasverkkoon ja OT-ympäristöön. Malli on helppo hallita, mutta kun hyökkääjä pääsee minkä tahansa vyöhykkeen sisälle, sivuttaisliikkuminen on usein hyvin helppoa.

Mikrosegmentointi lähestyy asiaa täysin eri tavalla. Muutaman suuren vyöhykkeen sijaan pääsyä hallitaan paljon tarkemmalla tasolla, usein yksittäisen työkuorman, sovelluksen tai palvelun tasolla. Jokainen vuorovaikutus vaatii varmennuksen. Jokainen järjestelmä eristetään niin pitkälle kuin mahdollista.

Logiikka on yksinkertainen: vähemmän pääsyä tarkoittaa vähemmän riskiä.

Mikrosegmentointiin liittyy kuitenkin myös kompromissi. Sen käyttöönotto on monimutkaisempaa, se vaatii hyvän näkyvyyden sovellusten riippuvuuksiin ja edellyttää asiantuntemusta, jotta oikeita työnkulkuja ei rikota. Huonosti toteutettuna se turhauttaa käyttäjiä ja ajaa heitä varjo-IT:n pariin. Hyvin toteutettuna se pienentää merkittävästi yksittäisen vaarantumisen vaikutusaluetta.

Tämä on yksi niistä osa-alueista, joissa suunnitteluosaamisella ja kokemuksella on aidosti merkitystä – ja joissa väärä suunta alussa voi maksaa vuosia myöhemmin.

Automatisoitu korjauspäivitys ja altistumisikkuna

Vaikka käyttöoikeuksien hallinta olisi vahvaa, haavoittuvuuksia jää aina. Ohjelmistoja kirjoittavat ihmiset, ja ihmiset tekevät virheitä. Toimittajat julkaisevat korjauspäivityksiä, mutta niiden käyttöönotto ei juuri koskaan tapahdu välittömästi.

Tästä viiveestä syntyy se, mitä hyökkääjät etsivät: altistumisikkuna, aika, joka kuluu haavoittuvuuden julkitulosta siihen, että omat järjestelmät on suojattu. Automaattisten skannaus- ja hyväksikäyttötyökalujen vuoksi tätä ikkunaa mitataan usein tunneissa.

Sen sulkeminen vaatii kahta asiaa:

Automatisoitua korjauspäivitystä, jotta päivitykset otetaan käyttöön niin nopeasti kuin operatiivisesti on mahdollista.

Arkkitehtuuria, joka tukee päivittämistä ilman käyttökatkoja: redundanssia, vaiheittaisia päivityksiä ja canary-julkaisuja.

Pelkkä automaatio ei riitä. Sen on oltava sisäänrakennettu osa kokonaisuutta. Jälleen kerran vastaus palaa siihen, miten järjestelmät on alun perin rakennettu.

Virtuaalinen paikkaus OT- ja legacy-järjestelmissä kriittisessä infrastruktuurissa

Kaikkia järjestelmiä ei voida päivittää. Voimalaitosten, vesihuollon, valmistavan teollisuuden ja liikenteen operatiivinen teknologia toimii usein alustoilla, jotka ovat vuosikymmeniä vanhoja, sertifioitu tiettyihin olosuhteisiin tai liian kriittisiä pysäytettäviksi päivityksen ajaksi. Terveydenhuollon, finanssialan ja julkishallinnon legacy-sovelluksilla on samankaltaisia rajoitteita.

Erityisesti pohjoismaisella energia-alalla tämä ei ole teoreettinen ongelma. IT:n ja OT:n lähentyminen on todellisuutta: SCADA- ja ohjausjärjestelmät, jotka olivat aiemmin eristettyjä, on nyt yhdistetty yritysverkkoihin, pilvivalvontaan ja etäoperointikeskuksiin. Hyökkäyspinta on kasvanut nopeammin kuin taustalla olevaa teknologiaa on pystytty modernisoimaan.

Tässä kohtaa virtuaalisesta paikkauksesta tulee välttämätöntä. Sen sijaan, että haavoittuvaa järjestelmää muutettaisiin, sen ympärille asetetaan suojaavia kontrolleja:

Verkkoliikennettä tarkastetaan ja suodatetaan.

Tunnetut hyväksikäyttömallit estetään ennen kuin ne saavuttavat järjestelmän.

Epäilyttävä toiminta käynnistää hälytykset ja rajaavat toimenpiteet.

Virtuaalinen paikkaus ei korvaa varsinaista korjauspäivitystä silloin, kun päivittäminen on mahdollista. Mutta kriittisissä järjestelmissä, joita ei voida muuttaa, se pitää altistumisikkunan suljettuna siihen asti, kun modernisointi on mahdollista, usein usean vuoden aikajänteellä.

Kriittisen infrastruktuurin toimijoille tämä lähestymistapa ei ole enää valinnainen. Se on puolustettavan tietoturva-asennon perusta NIS2:n ja toimialakohtaisen sääntelyn näkökulmasta.

Assumed Breach ja NIS2: vaatimustenmukaisuus suunnittelun kautta

NIS2 ja sen kansalliset toimeenpanot, kuten Norjan digitalsikkerhetsloven, antavat muodollista painoarvoa sille, mitä tietoturvatiimit ovat sanoneet jo vuosia: resilienssi on rakennettava sisään, ei lisättävä jälkikäteen.

Vaatimustenmukaisuuden liimaaminen olemassa olevan arkkitehtuurin päälle on kallista, hidasta ja yleensä puutteellista. Organisaatiot, jotka onnistuvat NIS2:n kanssa, käsittelevät sitä arkkitehtuurivaatimuksena alusta asti:

Riskien arviointi ohjaa suunnittelupäätöksiä, ei vain dokumentaatiota.

Lokitus, valvonta ja poikkeamaraportointi rakennetaan osaksi kokonaisuutta, eikä niitä lisätä myöhemmin.

Toimittaja- ja kolmannen osapuolen riskit ovat osa arkkitehtuuria, eivät erillinen harjoitus.

Kun tämä tehdään oikein, vaatimustenmukaisuudesta tulee hyvän suunnittelun tulos eikä rinnakkainen projekti. Ja mikä on hallitusten ja johdon kannalta olennaista: ratkaisu kestää myös tarkastelun.

Poikkeamiin reagointi: harjoittelua väistämätöntä varten

Jopa parhaiten suunnitelluissa järjestelmissä tapahtuu poikkeamia. Assumed Breach lähtee tästä oletuksesta ja valmistautuu siihen.

Valmistautuminen on paljon enemmän kuin dokumentoitu suunnitelma SharePoint-kansiossa. Kypsät organisaatiot toteuttavat nykyään säännöllisiä simulaatioita: tabletop-harjoituksia, Red Team -toimeksiantoja ja täysimittaisia “war game” -harjoituksia, joissa poikkeamiin reagointia testataan realistisen paineen alla.

Syy on yksinkertainen: kun todellinen poikkeama tapahtuu, silloin ei ole aikaa opetella. Roolien on oltava selkeät. Päätösten on oltava ennalta valtuutettuja. Eskalointipolkujen on oltava kaikkien tiedossa. Vakavan poikkeaman ensimmäinen tunti määrittää suunnan seuraaville kolmelle kuukaudelle.

Zero Trustin, automaation, segmentoinnin, vaatimustenmukaisuuden ja reagoinnin läpi toistuu sama kaava: sisäänrakennettu tietoturva kestää. Jälkikäteen lisätty tietoturva ei kestä.

Periaatteista käytäntöön: miten NetNordic auttaa

Assumed Breach on ajattelutapa, mutta sen vieminen arkkitehtuuriin, operatiiviseen toimintaan ja hallintamalleihin on se kohta, jossa useimmat organisaatiot kohtaavat haasteita. Tässä oikean kumppanin merkitys korostuu.

NetNordic työskentelee pohjoismaisten organisaatioiden kanssa energiasektorilla, julkishallinnossa, finanssialalla ja yrityssektorilla ja auttaa viemään nämä periaatteet käytännöllisiksi, kestäviksi arkkitehtuureiksi. Tämä sisältää:

Cyber Advisory – strategia, arkkitehtuurikatselmoinnit, NIS2-valmius ja Zero Trust -tiekartat.

Offensive Security – penetraatiotestaus, Red Team -harjoitukset ja Assumed Breach -harjoitukset, joilla puolustusta validoidaan todellista hyökkääjäkäyttäytymistä vasten.

Managed SOC – 24/7-valvonta ja reagointi, rakennettuna sen oletuksen varaan, että jotakin pääsee lopulta läpi.

Turvalliset infrastruktuuri- ja verkkopalvelut – suunniteltuna niin, että segmentointi, automaatio ja resilienssi ovat oletusarvoja.

Tavoitteena ei ole täydellinen ennaltaehkäisy. Tavoitteena on suunniteltu resilienssi: järjestelmät, jotka rajaavat uhat, operatiivinen toiminta, joka reagoi tehokkaasti, ja liiketoiminta, joka jatkaa toimintaansa.

Usein kysytyt kysymykset

Mitä Assumed Breach -ajattelutapa tarkoittaa?
Assumed Breach on kyberturvallisuuden lähestymistapa, joka perustuu oletukseen, että ennaltaehkäisy voi joskus pettää. Sen sijaan, että luotettaisiin pelkästään hyökkääjien pitämiseen ulkopuolella, se keskittyy järjestelmien, prosessien ja reagointikyvykkyyksien suunnitteluun niin, että tietomurron vaikutukset voidaan rajata.

Miten Assumed Breach eroaa Zero Trustista?
Zero Trust on arkkitehtuuriperiaate – älä koskaan luota, varmista aina. Assumed Breach on laajempi operatiivinen ajattelutapa, johon Zero Trust usein kuuluu. Zero Trust vastaa siihen, miten pääsy suunnitellaan; Assumed Breach vastaa siihen, miksi, koska suunnittelet järjestelmiä sitä hetkeä varten, jolloin jokin pääsee läpi.

Onko Assumed Breach relevantti pienille ja keskisuurille organisaatioille?
Kyllä. Itse asiassa pienemmät organisaatiot hyötyvät siitä usein eniten, koska niillä on vähemmän kapasiteettia selviytyä suuresta poikkeamasta. Periaatteet, vähimmät oikeudet, segmentointi ja testattu reagointi, skaalautuvat alaspäin yhtä hyvin kuin ylöspäin.

Miten Assumed Breach tukee NIS2-vaatimuksia?
NIS2 edellyttää nimenomaisesti riskienhallintaa, poikkeamiin reagointia ja toimitusketjun turvallisuutta. Assumed Breach -arkkitehtuuri vastaa näihin vaatimuksiin suunnittelun kautta, ei erillisenä vaatimustenmukaisuusharjoituksena.

Mistä organisaation kannattaa aloittaa?
Useimmat organisaatiot saavat suurimman hyödyn kolmesta asiasta: identiteetin- ja käyttöoikeuksien hallinnan nykytilan arvioinnista, verkkosegmentoinnin katselmoinnista, erityisesti IT:n ja OT:n välillä, sekä testatusta poikkeamiin reagointisuunnitelmasta. Jo nämä kolme asiaa sulkevat suurimman osan kuilusta.

Oletteko valmiita siihen, mitä seuraavaksi tulee?

Jos rakennatte organisaationne puolustusta vuoden 2026 ja sen jälkeisten realiteettien varaan, ensimmäinen askel on ymmärtää, missä olette tänään.

Varaa 30 minuutin Assumed Breach -valmiuskeskustelu: maksuton keskustelu yhden tietoturva-asiantuntijamme kanssa. Käymme läpi nykytilaanne ja tunnistamme, missä suunnittelutason muutoksilla olisi suurin vaikutus. Lähetä lomake ja varaa nyt!