SOC 2 ja tunkeutumistestaus: valitse testi, joka kertoo tietoturvasta

Tunkeutumistestaus tuottaa näyttöä määritellyn järjestelmän hyödynnettävissä olevista heikkouksista. Sen arvo riippuu siitä, mitä testaajat tarkastelevat, miten he tutkivat sitä ja mitä tuotekehitys tekee havainnoilla. Raportti, josta puuttuvat tuotteen tärkeät luottamusrajat, voi täyttää sisäisen määräajan mutta kertoa tietoturvasta vain vähän.

Teknologiajohtajalle (CTO) hyödyllinen kysymys ei ole pelkästään se, onko testi tehty. Kysymys on siitä, haastaako toimeksianto asiakastietoja suojaavat hallintakeinot ja tuottaako se havaintoja, jotka tiimi pystyy toistamaan, korjaamaan ja varmentamaan.

Mitä SOC 2 edellyttää ja mitä ei

SOC 2 on varmennusraportti, ei sertifiointi. Sen kriteerit ovat periaatepohjaisia; ne eivät aseta kaikille organisaatioille yhtä universaalia tunkeutumistestausvaatimusta tai vuosittaista toistotiheyttä. Riski, kuvaamanne hallintakeinot, auditoijan odotukset ja asiakassopimukset määrittävät, millainen testaus on tarkoituksenmukaista.

Keskustele tavoitteesta ja odotetusta näytöstä auditoijanne kanssa ennen toimeksiannon tilaamista. Jos dokumentoitu hallintakeinonne lupaa tietyn testaustiheyden tai soveltamisalan, suunnittele, miten osoitatte sitoumuksen täyttymisen.

Asiakkaiden varmuus on erillinen näkökohta. Ostaja voi edellyttää riippumatonta sovellustestausta, vaikka auditointilähestymistapanne ei sitä määräisi. Selvitä nämä odotukset varhain, mutta älä anna hankinnan tarkistuslistan korvata teknistä rajausta. SOC 2 -raportti tai tunkeutumistestaus ei osoita, ettei järjestelmässä olisi haavoittuvuuksia.

Rajaa hyökkäyspinta, älä vain verkkosivustoa

Aloita arkkitehtuurista, arkaluonteisista tietovirroista ja luottamusrajoista. OWASPin uhkamallinnusohjeistus tarjoaa hyödyllisen perustan sen tunnistamiseen, mikä voi mennä pieleen ja mihin testauksen pitäisi keskittyä.

Usean vuokralaisen SaaS-tuotteessa pelkän julkisen aloitussivun testaaminen jättää tärkeät sovellusrajat tarkastelematta. Anna palveluntarjoajalle inventaario, joka sisältää rajapinnat, taustaprosessoinnin, hallintatyökalut ja asiaankuuluvan infrastruktuurin, ei pelkkää verkkotunnusluetteloa.

Määrittele poissulkemiset ja rajoitukset nimenomaisesti. Testaamattoman mobiilisovelluksen, käytettävissä olemattoman roolin tai saavuttamattoman ympäristön on pysyttävä näkyvissä loppuraportissa. Soveltamisalan pitäisi myös erottaa omistamanne järjestelmät kolmansien osapuolten palveluista, joihin ette voi valtuuttaa testaajia hyökkäämään.

Valitse menetelmä, joka vastaa kysymyksiinne

Automaattinen skannaus tunnistaa mahdollisia heikkouksia ja tukee toistuvaa perushygieniaa. Tunkeutumistestaus lisää tähän asiantuntevan tutkimuksen hyödynnettävyydestä ja merkityksellisistä hyökkäyspoluista valtuutetun soveltamisalan sisällä. Työkalut ovat hyödyllisiä; tunkeutumistestaukseksi uudelleen nimetty skannerin vienti ei vastaa tällaista tutkimusta.

Black box -testaus alkaa rajallisella tiedolla järjestelmästä. Gray box -testauksessa annetaan valikoituja tietoja tai pääsyoikeuksia, usein myös tilejä. White box -testaus tarjoaa syvemmän näkyvyyden, mahdollisesti lähdekoodin ja arkkitehtuurin. Nämä lähestymistavat vastaavat eri kysymyksiin eivätkä muodosta yksinkertaista laatujärjestystä.

Sovelluksen valtuutuksen testauksessa usean roolin ja vuokralaisen tilit voivat tehostaa tutkimusta. Pelkkä ulkoisen infrastruktuurin testaus ei voi osoittaa, pystyvätkö todennetut käyttäjät ylittämään vuokralaisten väliset rajat.

Arvioi palveluntarjoaja ja tuotokset

Kysy, kuka työn tekee ja onko hän testannut vastaavia arkkitehtuureja. Asiaankuuluvat pätevyydet tukevat huolellisuusarviointia, mutta pelkät sertifikaatit eivät osoita sovelluskohtaista osaamista. Pyydä anonymisoitu esimerkkiraportti ja keskustele siitä, miten tiimi tutkii liiketoimintalogiikkaa, ei vain tunnettuja ohjelmistohaavoittuvuuksia.

Selvitä ennen allekirjoittamista:

• Mitkä järjestelmät, roolit ja hyökkäyspolut katetaan ja miten työmäärä jaetaan.
• Mitä manuaalista tutkimusta automaattisten työkalujen lisäksi tehdään.
• Miten kiireellisistä havainnoista viestitään ennen loppuraporttia.
• Sisältävätkö havainnot toistettavissa olevan näytön, koskevat komponentit, vaikutuksen ja korjausohjeet.
• Sisältyykö uudelleentestaus, mikä sen aikaikkuna on ja mitä tapahtuu, jos korjaukset valmistuvat myöhemmin.
• Miten raportit, tunnistetiedot ja kerätyt tiedot suojataan ja lopulta poistetaan.

Vertaile tarjouksia kattavuuden ja tuotosten perusteella, älä pelkän hinnan. Edullisempi tarjous voi tarkoittaa kapeampaa toimeksiantoa eikä samaa työtä tehokkaammin toteutettuna.

Sovi turvalliset toteutussäännöt

Dokumentoi valtuutus ja toimeksiannon säännöt (rules of engagement) ennen testauksen alkua. Yksilöi hyväksytyt palvelimet, tilit, ympäristöt, testausikkunat, hätäyhteyshenkilöt ja pysäytysehdot. Sopikaa, jätetäänkö palvelunestotestaus, käyttäjiin kohdistuva manipulointi, pysyvän pääsyn luominen tai tietojen poiminta ulkopuolelle.

Tuotannossa tehtävä testaus voi paljastaa todellisia konfiguraatio-ongelmia, mutta se luo myös operatiivista riskiä. Edustava testiympäristö voi olla turvallisempi, kunhan erot tuotantoon kirjataan. Käytä mahdollisuuksien mukaan synteettisiä vuokralaistietoja ja sopikaa, mikä näyttö riittää vaikutuksen osoittamiseen keräämättä tarpeettomasti asiakastietoja.

Varmista, että valvontatiimit osaavat erottaa valtuutetun toiminnan asiaan liittymättömästä poikkeamasta. Testaus ei saa muuttua tekosyyksi poistaa suojaavia hallintakeinoja käytöstä dokumentoimatta seurauksia.

Esimerkki: vuokralaisten eristystä koskeva havainto

Tarkastellaan havainnollistavaa SaaS-toimeksiantoa. Oletetaan, että tuotteessa on kaksi testivuokralaista, tavallisia käyttäjiä, vuokralaisten ylläpitäjiä ja tukirooli. Testi sisältää todennetut rajapinnat ja vientityönkulut; kolmannen osapuolen identiteetti-infrastruktuuri on rajattu ulkopuolelle.

Testaaja havaitsee, että vientipäätepiste tarkistaa kirjautumisen mutta ei johdonmukaisesti varmista vuokralaisomistajuutta. Synteettisiä tietueita käyttäen hän osoittaa, että vuokralaisen A käyttäjä voi pyytää vuokralaiselle B kuuluvan viennin.

Havainnossa pitäisi yksilöidä päätepiste, vaaditut oikeudet, koskeva työnkulku, toistettavissa oleva näyttö ja liiketoimintavaikutus. Tuotekehitys jäljittää ongelman taustatyöprosessiin, joka luottaa pyynnön mukana annettuun vuokralaistunnisteeseen.

Korjaus varmistaa omistajuuden ennen viennin ajastamista ja uudelleen sitä haettaessa. Regressiotestit kattavat vuokralaisten väliset pyynnöt ja asiaankuuluvat roolit. Uudelleentestaus vahvistaa, että alkuperäinen polku on estetty, ja tarkistaa siihen liittyvät vientipolut. Tiimi säilyttää alkuperäisen havainnon, toteutusnäytön ja uudelleentestauksen tuloksen; se ei vain merkitse tikettiä valmiiksi.

Muuta havainnot vastuulliseksi tekniseksi työksi

Luokittele havainnot teknisen vakavuuden ja liiketoiminnallisen altistumisen perusteella. Huomioi vaaditut oikeudet, internetiin näkyvyys, koskevat tiedot, hyödyntämisen luotettavuus ja korvaavat hallintakeinot. Nimellisesti kohtalainen ongelma voi vaatia kiireellistä käsittelyä, jos se rikkoo kriittisen asiakasrajan.

Osoita jokaiselle havainnolle omistaja, tavoitepäivä ja varmennustapa. Ota tarvittaessa käyttöön väliaikainen lieventävä toimenpide pysyvää korjausta valmisteltaessa. Pyydä nimettyä riskinomistajaa hyväksymään mahdollinen jäännösriski perusteluineen ja katselmointipäivineen; tuotekehityksen hiljaisuus ei ole hyväksyntä.

Kirjaa testattu tuoteversio ja ympäristö. Ennen merkittävää valtuutuksen uudelleensuunnittelua saatu tulos ei voi kuvata uutta toteutusta. Käytännön suosituksena arvioi testaustarpeet uudelleen merkittävien arkkitehtuurimuutosten, vakavien poikkeamien tai uuden altistumisen jälkeen vakiintuneen testausrytmin rinnalla.

Pidä näyttö hyödyllisenä auditoijille ja ostajille

Säilytä sovittu soveltamisala, toimeksiannon säännöt, loppuraportti, korjaustietueet, uudelleentestauksen näyttö ja riskipäätökset. Pidä koko raportti rajattuna, koska se voi sisältää arkaluonteisia hyväksikäytön yksityiskohtia.

Laadi asiakkaille suunnattu yhteenveto, jossa kuvataan testauspäivät, soveltamisala, menetelmä, rajoitukset ja korjaavien toimenpiteiden tila paljastamatta tarpeettomasti hyökkäysohjeita. Jatkokysymyksiä varten lue varmennuksen katselmointia käsittelevä oppaamme.

Kytke Secanissa testinäyttö asiaankuuluviin järjestelmiin, vaatimuksiin, hallintakeinoihin, omistajiin ja katselmointipäätöksiin. Seuraa näyttöpuutteita tehtävinä ja säilytä johtopäätösten ihmisen tekemä hyväksyntä. Näin yhteys testatun ja muuttuneen välillä pysyy saatavilla myöhempää katselmointia varten.

Laadi ennen tarjouspyyntöjä yhden sivun soveltamisalakuvaus, joka kattaa luottamusrajat, testitilit, poissulkemiset, tuotokset ja uudelleentestausta koskevat odotukset. Asiakirja antaa palveluntarjoajalle, auditoijalle ja tuotekehitykselle yhteisen perustan testille, joka kertoo tietoturvasta.