Haavoittuvuuksien korjaus
Havaintoja on helppo tuottaa ja kallista jättää auki. Kun ympäristö on ymmärretty, uhkatoimijan näkökulma -arvion, tunkeutumistestin tai jonkun muun kirjoittaman raportin pohjalta, ArcTech toteuttaa korjaukset ja varmistaa että ne pitävät pilvessä, identiteetissä, rajapinnoissa, webissä, sovelluskoodissa ja verkossa. Kun havaintoa ei voi korjata, koska kirjastosta ei ole korjattua versiota tai uudelleenrakentaminen maksaa enemmän kuin riski edellyttää, estetään sen sijaan sen hyödyntäminen ja jäännösriski kirjataan ylös. Työ priorisoidaan hyökkäysketjun eikä vakavuusluokan mukaan: matalat ja keskitason havainnot jotka yhdessä muodostavat reitin toimialueen tai tenantin valtaamiseen ovat kiireellisempiä kuin yksittäinen korkea havainto joka ei johda mihinkään.
Pyydä tarjous · Tyypillisesti 2–3 kuukautta · laajuuden mukaan
- Lähtötilanteen selvittäminenArvio, testiraportti tai oma havaintolistanne, mitä ikinä on olemassa. Epäselvät tai varmistamattomat kohdat vahvistetaan ennen aikatauluttamista, koska väärän positiivisen korjaaminen maksaa saman kuin oikean.
- Korjaussuunnitelma ja järjestysHavainnot ryhmitellään juurisyyn eikä raporttirivin mukaan, ja vaiheistetaan niiden hyökkäysketjujen mukaan joihin ne kuuluvat. CVSS-pistemäärä kuvaa yhtä ongelmaa erillään; hyökkääjät yhdistelevät ongelmia. Vain luku -virhekonfiguraatio, vanhentunut palvelutili ja ylioikeutettu sovellusrekisteröinti voivat kukin olla luokitukseltaan keskitasoa ja muodostaa yhdessä reitin Global Administrator -oikeuksiin, tuo ketju suljetaan ennen toisiinsa liittymätöntä korkean vakavuuden havaintoa joka ei johda mihinkään. Jokaisella kohdalla on työmääräarvio, joten suunnitelma voidaan mitoittaa budjettiin.
- Sovitut oikeudet ja muutoksenhallintaKirjoitusoikeudet rajattuna täsmälleen siihen mitä muutetaan, työskennellen muutosprosessinne sisällä eikä sen ohi. Tuotannossa ei muuteta mitään ilman sitä hyväksyntää jota se normaalisti vaatii.
- ToteutusItse työ koko pinossa: Conditional Access ja PIM rakennetaan uudelleen, oikeuksia karsitaan Entra ID:ssä ja Active Directoryssä, valtuutuslogiikka korjataan sovelluskoodissa, rajapintojen autentikointi ja istunnonhallinta korjataan, verkkopolut segmentoidaan, salaisuudet siirretään hallittuun säilytykseen, infrastruktuuri kuvataan koodina ja putket kovetetaan.
- Kun suoraa korjausta ei oleKaikkia havaintoja ei voi sulkea koodia muuttamalla. Haavoittuvasta kirjastosta ei välttämättä ole korjattua versiota, ylempi riippuvuus voi lukita sen, komponentti voi olla kolmannen osapuolen tai tuen ulkopuolella, tai uudelleenrakentaminen maksaa enemmän kuin riski edellyttää. Silloin työ siirtyy virheen korjaamisesta sen hyödyntämisen estämiseen: rajataan reitti joka komponenttiin johtaa, karsitaan oikeudet joilla se ajetaan, segmentoidaan mihin se saa olla yhteydessä, lisätään havainnointi sinne missä estäminen ei ole mahdollista, tai sijoitetaan se kontrollin taakse joka on ensin ohitettava. Havainto kirjataan lievennetyksi eikä korjatuksi, ja jäännösriski sekä perustelut kirjataan ylös, jotta asiaan voidaan palata kun rajoite muuttuu.
- VarmistusJokainen suljettu havainto testataan uudelleen ja varmistetaan, ettei sen hyökkäyspolku enää toteudu. Havainnon sulkeminen varmistamatta polun sulkeutumista on se tapa, jolla sama ongelma ilmestyy uudelleen seuraavassa testissä.
- LuovutusDokumentaatio siitä mitä muutettiin ja miksi, matkan varrella kirjoitettu automaatio ja työkalut sekä työpaja tiiminne kanssa, jotta osaaminen jää taloon. Työkalut jäävät teille.
- Havainnot suljettuina, ei vain kirjattuina
- Varmistustodisteet jokaisesta
- Korjaamatta jäänyt kirjattuna lievennetyksi, jäännösriskeineen
- Kirjaus siitä mitä muutettiin ja miksi
- Automaatio ja työkalut jäävät teille
- Luovutustyöpaja tiiminne kanssa
Usein kysyttyä
Kuinka kauan korjaus yleensä kestää?
Kahdesta kolmeen kuukautta on tyypillistä. Todelliset tekijät ovat ympäristön laajuus, käytettävissä oleva budjetti ja se, kuinka paljon jäännösriskiä olette valmiita kantamaan, ohjelma voi perustellusti päättyä kun ne ketjut jotka johtavat johonkin arvokkaaseen on suljettu, jolloin vähemmän merkittävät havainnot dokumentoidaan ja hyväksytään. Kahden viikon lyhyet toimeksiannot ovat mahdollisia kun laajuus on tietty havaintojoukko; kuutta kuukautta lähestyvä työ tarkoittaa yleensä että taustalla oleva suunnittelu rakennetaan uudelleen eikä paikata.
Miten voitte arvioida tämän tuntematta koodipohjaamme?
Emme tarkasti, ja jokainen joka lupaa kiinteän luvun näkemättömälle koodipohjalle arvaa. Etukäteen sovitaan laajuus ja aika, ei suljettujen havaintojen määrä. Suunnitelma järjestää työn hyökkäysketjujen mukaan niin että arvokkaaseen johtavat polut sulkeutuvat ensin, ja toimeksianto vie tuota järjestystä niin pitkälle kuin sovittu aika riittää. Lopuksi saatte kirjallisen selvityksen siitä mitä korjattiin, mitä lievennettiin korjaamisen sijaan ja miksi, sekä mitä jäi ja mitä se veisi nyt kun koodipohja on tuttu. Loput voidaan aikatauluttaa, rajata uudelleen tai hyväksyä jäännösriskinä ymmärtäen eikä jälkikäteen huomaten.
Mistä tiedätte, että korjaus oikeasti toimi?
Koska sama kyvykkyys joka löytää hyökkäyspolun pystyy myös varmistamaan ettei se enää toteudu. Toimittaja joka vain toteuttaa muutoksia voi kertoa että muutos tehtiin; se on eri väite kuin että reitti on suljettu, ja juuri siinä erossa sama havainto palaa seuraavassa auditoinnissa. Täällä jokainen suljettu havainto testataan uudelleen ja sen ketju kuljetaan läpi, tekijänä henkilö joka tekee tuota testausta ammatikseen eikä rastina ruutuun.
Miten päätätte mitä korjataan ensin?
Hyökkäysketjun mukaan, ei vakavuusluokan. Vakavuuspisteet arvioivat jokaisen havainnon erillään, eikä murtautuminen tapahdu niin, tunkeutuja ketjuttaa yhteen sen mitä on saatavilla. Kaksi tai kolme matalaksi tai keskitasoiseksi luokiteltua havaintoa muodostavat usein yhdessä täyden reitin tavallisesta käyttäjätilistä toimialueen tai tenantin valtaamiseen, kun taas korkean vakavuuden havainto eristetyssä järjestelmässä ilman jatkoyhteyksiä on aidosti vähemmän kiireellinen. Suunnitelma sulkee ne ketjut jotka johtavat johonkin tavoittelemisen arvoiseen, siinä järjestyksessä mihin ne johtavat.
Pitääkö meidän olla ostanut teiltä ensin arvio tai testi?
Ei. Toisen toimittajan raportti on aivan kelvollinen lähtökohta, samoin sisäinen havaintolista. Epäselvät tai varmistamattomat kohdat vahvistetaan ennen aikatauluttamista, väärän positiivisen korjaaminen maksaa yhtä paljon kuin oikean.
Mitä pino kattaa?
Azure ja pilvi-infrastruktuuri, Entra ID ja identiteetti mukaan lukien Conditional Access ja PIM, Active Directory ja hybridifederointi, rajapinnat, verkkosovellukset, sovelluskoodi, verkkosuunnittelu ja segmentointi, infrastruktuuri koodina Bicepillä ja Terraformilla sekä CI/CD-putket. Tämän ulkopuolinen työ kieltäydytään mieluummin kuin yritetään.
Onko eturistiriita korjata itse löytämänsä?
Vain jos palkkio kasvaisi havaintojen myötä, eikä se kasva: katselmukset ja testit rajataan ja arvioidaan ennen työn alkua, eikä arvio muutu siksi että raportista tuli pitempi. Käytännössä huomattava osa korjaustyöstä alkaa jonkun toisen raportista. Testi tehtiin kaksi tai kolme vuotta sitten, osa korjattiin, loput eivät, ja sekä ympäristö että koodi ovat sen jälkeen muuttuneet. Siinä ei ole mitään mitä ArcTech olisi voinut paisutella. Toimeksianto etenee silloin silmukkana, korjaa ja testaa uudelleen ja korjaa taas, kunnes laajuuteen kuuluvat havainnot on joko suljettu tai tietoisesti hyväksytty. Sen jälkeen lopputarkastus on vapaasti tilattavissa keneltä tahansa, ja jos tilintarkastaja edellyttää varmistuksen olevan riippumaton korjauksen tekijästä, juuri niin se kuuluu tehdä.
Toimitteko konsulttitalojen ja välittäjien kautta?
Kyllä. Merkittävä osa ArcTechin työstä toteutetaan alihankintana konsulttitaloille tai välittäjien kautta, suorien toimeksiantojen ohella.
Mitä meille jää jälkeenpäin?
Dokumentaatio siitä mitä muutettiin ja miksi, kaikki toimeksiannon aikana kirjoitettu automaatio sekä luovutustyöpaja. Työkalut jäävät teille.