Tunkeutumistestaus on vakioelementti missä tahansa vakavassa tietoturvaohjelmassa. Kaupallisissa ympäristöissä se on suhteellisen hyvin ymmärretty harjoitus: ulkoiselle tiimille annetaan laajuus, toimintasääntöasiakirja ja aikaikkuna löytää hyödynnettävissä olevat haavoittuvuudet ennen kuin todelliset hyökkääjät tekevät niin. Lopputuloksena on raportti; korjauspolku on projektinhallintakysymys.

Puolustusympäristöissä mikään tuo viitekehys ei täysin päde. Oikeudellinen valtuutusrakenne on erilainen, uhkamalli on erilainen, testaajien koskettamia asioita koskevat rajoitukset ovat erilaiset, ja polku havainnosta korjaukseen kulkee virallisen akkreditointiprosessin kautta, jolla ei ole kaupallista vastinetta. Organisaatiot, jotka soveltavat kaupallisia tunkeutumistestauskäytäntöjä puolustusjärjestelmiin — tai jotka palkkaavat kaupallisia tunkeutumistestausyrityksiä ilman puolustuskokemusta — tuottavat rutiininomaisesti arviointeja, jotka jättävät huomioimatta relevantimmat riskit, toimivat oikeudellisesti puolustuskelvottomien rajojen ulkopuolella tai tuottavat havaintoja, joihin ohjelmatoimisto ei voi toimia.

Tässä artikkelissa tarkastellaan, mikä todella tekee puolustuksen tunkeutumistestauksesta erilaisen, mitä se tarkoittaa operatiivisesti ja miten rakentaa arviointi, joka tuottaa tuloksia, joita sotilasohjelma voi käyttää.

Oikeudellinen valtuutus: perusta, jolla ei ole kaupallista vastinetta

Kaupallisissa toimeksiannoissa tunkeutumistestauksen oikeudellinen perusta on sopimus ja toimintasääntöasiakirja, jonka allekirjoittaa joku, jolla on valtuutus sallia kohdejärjestelmien testaus. Tämä valtuutus on yleensä suoraviivainen — yritys omistaa järjestelmät ja CISO tai CTO voi myöntää luvan.

Puolustusympäristöissä valtuutusketju on monimutkaisempi ja seuraukset virheiden tekemisestä ovat huomattavasti vakavammat. Valtion tietojärjestelmät toimivat käyttöoikeuden (ATO) nojalla, jonka myöntää valtuuttava viranomainen (AO). ATO määrittelee tietoturva-asennon, jota järjestelmällä on valtuutus ylläpitää. Tunkeutumistestaus muuttaa tätä asentoa, ainakin väliaikaisesti, ja AO:n — ei pelkästään ohjelmajohtajan tai järjestelmän ISSO:n — on nimenomaisesti valtuutettava se.

Yhdysvaltojen DoD-järjestelmissä sovelletaan tietokonepetossäädöstä (Computer Fraud and Abuse Act, CFAA) ja UCMJ:tä. Henkilö, joka pääsee valtion tietojärjestelmään ilman asianmukaista valtuutusta — vaikka hyvässä tarkoituksessa, vaikka osana näennäisesti valtuutettua testiä — on syyllistynyt liittovaltion rikokseen. Valtuutusasiakirja ei ole muodollisuus: se on väline, joka muuttaa muutoin luvattoman pääsyn lainmukaiseksi testaukseksi. Jokainen valtuutuksessa mainittu testaaja on tunnistettava yksilöllisesti. Valtuutetun testauksen laajuuden on oltava spesifinen. Laajuuden ulkopuoliset toimet eivät ole suojattuja.

Oikeudellinen valtuutusvaatimus: Älä koskaan aloita puolustuksen tunkeutumistestausta ilman allekirjoitettua, spesifistä valtuutusasiakirjaa järjestelmän valtuuttavalta viranomaiselta. Ohjelmajohtajien tai pääurakoitsijoiden yleiset "tietoturva-arviointi"-hyväksynnät eivät tarjoa CFAA-suojaa. Valtuutuksessa on nimettävä testaajat, eriteltävä laajuuteen kuuluvat järjestelmät, määriteltävä testausikkuna ja lueteltava sallitut menetelmät.

Selvitysvaatimukset lisäävät toisen kerroksen. Luokitellun järjestelmän testaaminen edellyttää, että testaajilla on voimassaolevat selvitykset asianmukaisella luokittelutasolla. Testausorganisaatiolla on oltava tilatason turvallisuusselvitys (FCL) kyseisellä tasolla. Selvittämättömän henkilöstön tuominen — vaikka tukevissa rooleissa — luokiteltuun testiympäristöön on tietoturvarikkomus riippumatta siitä, mitä he todella näkevät tai koskettavat.

ITAR (International Traffic in Arms Regulations) asettaa lisärajoituksia ohjelmille, joissa käsitellään valvottuja puolustusartikkeleita. ITAR-valvottujen järjestelmien haavoittuvuuksia koskeva tieto voi itsessään olla vientivalvontarajoitusten alainen, mikä rajoittaa sitä, mitä voidaan dokumentoida, siirtää tai jakaa kansainvälisten rajojen yli — myös monikansallisissa liittolaisten ohjelmissa. Kansainvälisten alihankintajärjestelyjen nojalla toimivien testausyritysten on otettava tämä nimenomaisesti huomioon.

Uhkatoimijan jäljittely: kansallisvaltiotason TTP:t, ei geneerisiä hyväksikäyttöjä

Kaupallinen tunkeutumistestaus keskittyy usein löytämään minkä tahansa hyödynnettävissä olevan haavoittuvuuden — yleisimmät, helpoimmin saatavilla olevat, korkeimman CVSS-pisteytetyt ongelmat kohteen hyökkäyspinnalla. Yritysverkolle tämä on kohtuullinen lähestymistapa: opportunistinen hyökkääjä hyödyntää helpoimmin saatavilla olevaa polkua.

Puolustusjärjestelmät kohtaavat perustavanlaatuisesti erilaisen uhkajoukon. Korkean arvon puolustuskohteiden ensisijaiset vastustajat ovat kansallisvaltiotoimijoita, joilla on huomattavat resurssit, kehittyneet kyvyt ja pitkät aikahorisonttia. Heitä ei pysäytä CVSS-10-pisteytetyn OpenSSL-ongelman paikkaaminen, jos he voivat kiertää luotetun toimitusketjukumppanin, vanhan sulautetun komponentin tai poikkialueisen ratkaisun virheellisen konfiguraation kautta.

Tehokas puolustuksen tunkeutumistestaus käyttää vastustajan jäljittelyä: testiryimi replikoi tiettyjen ohjelman uhkamallin kannalta relevanttien uhkatoimijaryhmien taktiikoita, tekniikoita ja menettelytapoja (TTP:t). MITRE ATT&CK-viitekehys tarjoaa strukturoidun taksonomian tähän, ja Enterprise- ja ICS-matriisit kattavat tekniikat, joita edistyneet pysyvät uhkatoimijaryhmät useimmin käyttävät.

Puolustusjärjestelmien kannalta relevantit uhkatoimijat sisältävät tyypillisesti:

  • APT28 (Fancy Bear / GRU:n yksikkö 26165) — Venäjän sotilastiedustelu, tunnettu spearphishing-hyökkäyksistä, tunnistetietojen keräämisestä ja pysyvyydestä laillisten työkalujen väärinkäytön kautta. Puolustusohjelmistoihin liittyvät taktiikat sisältävät kehittäjien työasemien ja rakennusputkien kohdistamisen haitallisen koodin injektoimiseksi ylöspäin käyttöönottoon nähden.
  • Lazarus Group (DPRK) — Pohjois-Korean valtion toimija, jonka historiaan kuuluu puolustusurakoitsijoiden ja avaruusyritysten kohdistaminen, erityisesti vesireikähyökkäysten ja aseistettujen työnhakuviestien kautta, jotka kohdistuvat selvitettyyn henkilöstöön.
  • Volt Typhoon (PRC) — Kiinan valtion toimija, joka keskittyy maalla elämisen tekniikoihin pysyvän, matalaprofiilisen pääsyn saavuttamiseksi kriittiseen infrastruktuuriin ja puolustusverkkoihin. Merkittävä siitä, että se välttää mukautettua haittaohjelmaa sisäänrakennettujen järjestelmätyökalujen hyväksi havainnoinnin välttämiseksi.

Testisuunnitelman tulisi täsmentää, mitä vastustajan profiilia jäljitellään ja miksi, ohjelman uhka-arvioinnin perusteella. Testi, joka jäljittelee Volt Typhoonin maalla elämisen lähestymistapaa, näyttää hyvin erilaiselta kuin testi, joka jäljittelee APT28:n tunnistetietokeskeisiä operaatioita — ja molemmat näyttävät erilaisilta kuin testi, joka keskittyy sisäpiiriuhkaskenaarioihin tai toimitusketjun eheyteen.

Vastustajan valintahuomio: Uhkatoimijaprofiilin tulee perustua ohjelman tiedusteluun perustuvaan uhka-arviointiin, ei testaajan mieltymykseen tai geneerisiin "kehittynyt"-leimiin. Ohjelmilla, joilla on erityisiä maantieteellisiä uhkaprofiileja tai tunnettua kohdistamishistoriaa, ISSO:n tulisi perehdyttää testiryimi nykyiseen uhkaraportointiin ennen toimeksiannon alkamista.

Laajuudenhallinta: käyttökatkosten rajoitukset ja eristetyt testiympäristöt

Kaupalliset tunkeutumistestauksen laajuusrajoitukset koskevat ensisijaisesti vastuun rajoittamista ja vaivan kohdistamista. Puolustuksen laajuusrajoituksilla on lisäulottuvuuksia, jotka perustavanlaatuisesti muovaavat sitä, miten testi voidaan toteuttaa.

Monet puolustusjärjestelmät eivät voi hyväksyä mitään käyttökatkosta testauksen aikana. Komento- ja hallintajärjestelmät, viestintäinfrastruktuuri ja reaaliaikaiset sensorifuusioalustat voivat olla operatiivisesti aktiivisia testausikkunan aikana. Hyväksikäyttöyritys, joka aiheuttaa palvelukeskeytyksen — vaikka lyhyen — voi aiheuttaa operatiivisia seurauksia, joita mikään sopimuksellinen korvaus ei voi korjata. Vakio kaupallinen lähestymistapa testata tuotantojärjestelmiä vastaan "lopeta jos näet jotain epävakaata" -säännöllä ei ole hyväksyttävä näissä ympäristöissä.

Käytännön seurauksena on, että monet puolustuksen tunkeutumistesteistä suoritetaan erillisiä testiympäristöjä vastaan: eristettyjä verkkosegmenttejä, staging-ympäristöjä tai laboratorioreplikoita, jotka vastaavat tuotantoa mahdollisimman tarkasti. Testiympäristön tarkkuus on äärimmäisen tärkeää. Testiympäristö, joka käyttää eri laiteohjelmistoversiota, josta puuttuu tuotantointegraatiot tai joka toimii löysemmillä käyttöoikeusvalvonnoilla verrattuna tuotantoon, tuottaa havaintoja, jotka eivät heijasta operatiivisen järjestelmän todellista riskiasentoa. Testiympäristön tarkkuus on investointi, johon ohjelmatoimiston on sitouduttava — se ei ole testaustiimin ongelma ratkaistavaksi.

Laajuusrikkomuksia käsitellään suuremmalla vakavuudella puolustusympäristöissä kuin kaupallisissa. Järjestelmän vahingossa koskettaminen valtuutetun laajuuden ulkopuolella ei ole pieni menettelyllinen ongelma — se voi muodostaa luvattoman pääsyn valtion tietojärjestelmään. Testaajien on ylläpidettävä yksityiskohtaista toimintalokia koko toimeksiannon ajan, dokumentoiden merkittävät toimet lähes reaaliajassa, jotta mahdolliset laajuuskysymykset, jotka ilmenevät testin aikana tai jälkeen, voidaan ratkaista todisteilla eikä muistikuvilla.

Puolustuskohtaiset haavoittuvuusluokat

Menettelyllisten erojen lisäksi puolustusjärjestelmissä esiintyy haavoittuvuusluokkia, jotka ovat aliedustettuina kaupallisissa tunkeutumistestausmetodologioissa.

Vanhat sulautetut järjestelmät. Puolustusalustat toimivat rutiininomaisesti ohjelmistoilla laitteistoissa, jotka ovat 10–20 vuotta vanhoja, sulautetulla laiteohjelmistolla, jota ei voida paikata normaalien ohjelmiston päivitysmekanismien kautta. Näiden komponenttien haavoittuvuudet voivat olla tunnettuja mutta hoidettavissa järjestelmän elinkaaren aikana — tunkeutumistestauksen havainto muodostuu pysyväksi POAM-merkinnäksi poikkeamispyynnöllä korjauslipun sijasta. Testaajien on ymmärrettävä, mitä "havainto" tässä kontekstissa tarkoittaa: arvo on riskin dokumentoinnissa ja kvantifioinnissa, ei välttämättä välittömän korjauksen ajamisessa.

Poikkialueratkaisut. Järjestelmät, jotka käsittelevät tietoa useilla luokittelutasoilla, käyttävät poikkialueratkaisuja (CDS) tiedon siirtämiseen tietoturvadomainien välillä. Nämä ovat korkean arvon kohteita: CDS, jota voidaan manipuloida siirtämään tietoa väärään suuntaan, kumoaa koko tietojenkäsittelyarkkitehtuurin. CDS-testaus vaatii erikoisosaamista ja erityistä valtuutusta — näitä komponentteja käsitellään usein erillisinä laajuuksina laajemman ohjelman arvioinnin puitteissa.

Toimitusketjun eheys. Viime vuosien merkittävimmät ohjelmiston toimitusketjuhyökkäykset (SolarWinds, XZ Utils) ovat kohdistaneet rakennusputkiin ja riippuvuusinjektioon käynnissä olevien järjestelmien sijaan. Puolustusohjelmat ovat korkean arvon kohteita tälle hyökkäysluokalle. Tunkeutumistestauksen tulisi sisältää rakennusympäristön arviointi: voiko hyökkääjä kehittäjän työasemalle päästyään tuoda haitallista koodia, joka selviää tuotantorakennukseen? Voiko vaarantunut riippuvuus tuoda olemassa olevien kontrollien laukaisematta?

Varmenteen ja avaimen hallinta. Puolustusjärjestelmät ovat vahvasti riippuvaisia PKI-infrastruktuurista todennuksessa ja viestinnän tietoturvassa. Väärin konfiguroidut varmenteen validoinnit, liian laajat luottamuksen ankurikonfiguraatiot ja heikko avaimen elinkaaren hallinta ovat johdonmukaisesti korkean vakavuuden havaintoja. Toisin kuin sovellusten haavoittuvuudet, nämä ovat usein näkymättömiä automaattiselle skannaukselle ja vaativat manuaalisen PKI-arkkitehtuurin tarkistuksen järjestelmän tietoturvasuunnitelmaa vastaan.

Havaintojen elinkaari: POAM, ATO-vaikutus ja poikkeamispyynnöt

Kaupallisissa toimeksiannoissa tunkeutumistestausraportti menee CISO:lle, havainnot priorisoidaan, osa korjataan ja loput vanhenevat seurannassa seuraavaan arviointiin asti. Prosessia ohjaavat riskinottohalu ja insinöörikapasiteetti.

Puolustusympäristöissä havainnot syötetään viralliseen akkreditointielinkaareen, jolla on oikeudellisia ja sopimusoikeudellisia vaikutuksia. Keskeinen käsite on Plan of Action and Milestones (POAM): asiakirja, joka seuraa jokaista tunnettua puutetta järjestelmässä, jolle on myönnetty tai haetaan käyttöoikeutta (ATO). Jokainen tunkeutumistestauksen havainto, jota ei voida välittömästi korjata, on kirjattava POAM:iin suunnitellulla korjauspäivämäärällä, vastuullisella omistajalla ja väliaikaisella lieventämistoimenpiteellä.

Valtuuttava viranomainen tarkastelee POAM:ia ATO:n ylläpidon ehtona. Avoimet korkean vakavuuden kohteet ilman riittäviä väliaikaisia lieventämistoimia tai realistisia korjausaikatauluja voivat käynnistää ATO:n keskeyttämisen — käytännössä ottamalla järjestelmän pois käytöstä, kunnes riskiasento on käsitelty. Ohjelmatoimistolle tämä tulos on niin vakava, että jotkut ohjelmat viivyttävät tai rajoittavat tunkeutumistestauksen laajuutta välttääkseen havaintojen tuottamisen, jotka voisivat käynnistää ATO-tarkistuksen. Tämä on riskienhallinnan epäonnistuminen: haavoittuvuudet ovat olemassa riippumatta siitä, dokumentoidaanko ne vai ei.

Havainnoille, joita ei voida korjata — vanhoille komponenteille, joihin ei ole saatavilla korjaustiedostoja, arkkitehtuurirajoituksille, jotka vaatisivat täyden järjestelmän uudelleensuunnittelun — ohjelmatoimisto voi toimittaa poikkeamispyynnön tai riskinhyväksynnän AO:lle. Tämä ei ole epäonnistumisen myöntäminen; se on virallinen mekanismi toimimiseksi tunnetun jäännösriskin kanssa nimenomaisen valtuutuksen nojalla. Testaajien tulisi ymmärtää tämä prosessi ja muotoilla havainnot tavoin, jotka auttavat ISSO:a rakentamaan puolustuskelpoisia POAM-merkintöjä ja poikkeamispyyntöjä, ei vain tavoin, jotka maksimoivat CVSS-pisteitä.

Raportin muotoilu puolustusohjelmille: Puolustuksen tunkeutumistestausraporttien tulisi sisältää jokaisen havainnon osalta: luokittelumerkintä, vakavuusluokitus, joka on sovitettu ohjelman riskinhyväksymiskriteereihin, arvio hyödynnettävyydestä ohjelman todellisten uhkatoimijoiden suhteen sekä suositeltu POAM-käsittely. Kaupallisessa muodossa kirjoitetut raportit — CVSS-pisteet, geneerinen korjausneuvonta, ei-tekniselle johtoryhmälle suunnatut tiivistelmät — vaativat merkittävää muokkausta ennen kuin ISSO voi käyttää niitä.

Kuinka määritellä laajuus ja valtuuttaa puolustuksen tunkeutumistesti

Seuraavat vaiheet heijastavat vaatimuksia puolustuskelpoista, laillisesti valtuutettua tunkeutumistestausta varten puolustusohjelmistojärjestelmällä.

Vaihe 1: Luo oikeudellinen valtuutus ja kirjallinen lupa. Hanki allekirjoitettu testivaltuutusasiakirja järjestelmän AO:lta. Asiakirjan on nimettävä testaajat, eriteltävä laajuuteen kuuluvat järjestelmät, määriteltävä testausikkuna ja lueteltava sallitut menetelmät. Tämä ei ole muodollisuus — se on väline, joka tekee testauksesta laillista.

Vaihe 2: Tarkista selvitys- ja tilatason tunnistetiedot. Varmista, että kaikilla testaajilla on voimassaolevat selvitykset kohdejärjestelmän luokittelutasolla ja että testausorganisaatiolla on vaaditun tason FCL. Perehdytä kaikki testaajat ohjelman turvallisuusluokitteluoppaaseen ennen kuin he pääsevät mihinkään luokiteltuun ympäristöön.

Vaihe 3: Määrittele laajuus ja testiympäristön rajat. Tunnista, mitkä järjestelmät, verkot ja rajapinnat kuuluvat laajuuteen. Jos operatiiviset järjestelmät eivät voi hyväksyä käyttökatkoksia, perusta erillinen testiympäristö. Dokumentoi nimenomaiset poissulkemiset ja perehdytä testaajat laajuusrikkomusten oikeudellisiin seurauksiin.

Vaihe 4: Valitse ja tarkista testaustyökalut. Tarkista ITAR-velvollisuudet ja ohjelman akkreditointivaatimukset määrittääksesi, mitkä työkalut ovat sallittuja. Poista käytöstä työkalut, joissa on ulkomaislähtöisiä komponentteja, pilvipohjainen lisensointi tai lähtevä telemetria. Dokumentoi työkalusto testisuunnitelmaan ja toimita se ohjelmatoimiston tarkistettavaksi ennen toimeksiannon alkamista.

Vaihe 5: Toteuta uhkatoimijan jäljittely ohjelman uhkamallin perusteella. Valitse järjestelmälle relevantein vastustajan profiili. Käytä MITRE ATT&CK:ia ICS:lle tai Enterpriselle tarpeen mukaan, räätälöitynä järjestelmän arkkitehtuuriin ja tehtäväprofiiliin. Älä korvaa geneeristä "kehittynyttä" testausta todellisella vastustajan jäljittelyllä.

Vaihe 6: Dokumentoi toiminta ja havainnot luokittelumerkinnöillä. Ylläpidä yksityiskohtaista toimintalokia koko toimeksiannon ajan. Kaikissa havainnoissa on oltava asianmukaiset luokittelumerkinnät ja vakavuusluokitukset, jotka on sovitettu ohjelman riskinhyväksymiskriteereihin.

Vaihe 7: Kirjaa havainnot POAM:iin ja seuraa korjausta. Tee yhteistyötä ISSO:n kanssa kirjataksesi kaikki avoimet havainnot POAM:iin. Määritä korjausomistajat, aikataulutetut päivämäärät ja väliaikaiset lieventämistoimet. Raportoi korkean vakavuuden havainnot suoraan AO:lle — älä anna kriittisten haavoittuvuuksien jäädä jonoon ilman nimenomaista riskinhyväksyntää tai aktiivista korjausta.