Tietoturvatestaus

Tietoturvatestaus lyhyesti

Yleinen sovellusten ja järjestelmien tietoturvan arviointiin käytetty työkalu on tunkeutumistestaus. Rakkaalla lapsella on monta nimeä, ja tunkeutumistestaus tunnetaan myös nimellä pentest eli englanniksi penetration testing.

Jos yrityksiä tai organisaatioita testataan, kutsutaan sitä usein red teaming -harjoitukseksi.

Kun yrityksen järjestelmien sietokykyä eli resilisenssiä testataan, on kyseessä kuormitustestaus – tietoturvapuolella yleisemmin DDoS-testaus.

Yhtä kaikki, kyse on tietoturvatestauksesta. Kyseessä on luvallinen simuloitu hyökkäys, jolla pyritään hyväksikäyttämään sovellusta, järjestelmää tai ihmisiä siten, että se voi olla vahingollista joko kyseiselle järjestelmälle, yritykselle tai yrityksessä työskenteleville henkilöille tai niiden asiakkaille.

Mitä Mint Security toimittaa

Pentest

Pentestin tarkoituksena on pyrkiä simuloimaan hyökkääjän aikeita ja todentaa sovelluksen toiminta poikkeuksellisessa tilanteessa. Testauksen kriteeristönä käytetään tunnettuja ja yleisesti hyväksyttyjä, erityisesti web-sovellusten tietoturvan arviointiin luotuja tarkistuslistoja kuten OWASP Top 10.

Tunkeutumistestauksen tukena saatetaan myös käyttää lähdekooditarkastusta. Jos lähdekoodia päädytään tarkistamaan tarkemmin, käytetään useasti apuna OWASP ASVS -viitekehystä.

Red Team & Recon

Red teaming ei ole pelkästään fyysistä tunkeutumista toimistorakennuksiin tai roskisten penkomista. Red teaming -toimeksianto voidaan toteuttaa myös digitaalisessa maailmassa. Silloin aloitetaan tiedustelulla, eli recon-toiminnalla. Tiedustelusta edetään halutuimmalla tai helpoimmalla tavalla joko järjestelmien tai ihmisten kimppuun. Toimeksiannossa on monta ulottuvuutta — tärkein niistä on, että tilaaja ei juurikaan tiedä, mitä erilaisia keinoja hyökkääjä käyttää.

DDoS

Palvelunestohyökkäys on tapa testata järjestelmien teknistä resilienssiä. Palvelunestohyökkäystä harjoitellessa on syytä tietää hyvin tarkasti testattavan ympäristön yksityiskohdat. Palvelunestohyökkäyksellä on aina sivuvaikutuksia.

Osallisia harjoituksessa ovat käytännössä kaikki, jotka ovat jostain harjoituksen osasta vastuussa — tietoliikenne, infra, palvelimet, sovellukset, tietokannat — ihan kaikki. Asiakkaan tai harjoituksen tilaajan eri vastuuhenkilöitä ja edustajia unohtamatta.

Asiakkaiden tarpeet ja ratkaistavat haasteet

Asiakkaiden tarpeet voidaan jakaa esimerkiksi seuraaviin kategorioihin, jotka voidaan kuvata myös tietoturvatestauksen business caseina:

  • Halutaan verifioida, että halutut tietoturvakontrollit, kuten esimerkiksi palomuurit tai valtuushallinta, ovat toiminnassa ja kohdallaan
  • Halutaan ymmärtää sovelluksen ja sen ympäristön tekniset uhkakuvat sekä niihin liittyvät hyväksikäyttö- ja väärinkäytösmahdollisuudet, riskit mukaan lukien
  • Halutaan rikastaa riskirekisteriä ajanmukaisilla teknisillä löydöksillä
  • Halutaan ymmärtää organisaation sietokyky tai resilienssi uhkien edessä
  • Halutaan läpivalaista kolmannen osapuolen tuottaman sovelluksen tietoturva
  • Halutaan läpivalaista kolmannen osapuolen toimittama tekninen järjestelmä
  • Halutaan varmistua jonkun viitekehyksen tai standardin, kuten ISO27001 Annex A:n kontrollien, toimivuudesta
  • Halutaan ymmärtään yrityksen ulkoisia uhkatekijöitä ja niiden mahdollistajia

Lähestymistapamme on teknisen näkökulman ja teknisesti kattavan testin toteuttamisen lisäksi ymmärtää liiketoiminta sekä uhkamallit. Sitä kautta pystymme kertomaan ja auttamaan siinä, mihin havainnot vaikuttavat, miten niitä käytännössä voidaan hyväksikäyttää – ja miten uhkilta käytännössä voidaan suojautua.

Tarkemmin menetelmistämme ja työkaluistamme

Tavoitteenamme on toimittaa osaamista lyhentämättömänä asiakkaillemme. Hyödynnämme toimeksiannoissa tiimimme kaikkia jäseniä, kun tilanne niin vaatii – ja joskus se vaatiikin.

Jokaiseen toimeksiantoon kuuluu myös QA; valvomme työn laatua ja katselmoimme tulokset ja raportit ennen lopullista toimitusta.

Filosofiamme

Vaikka käytämme paljon erilaisia työkaluja, ei testauksemme ole lähtökohtaisesti työkaluvetoista. Raporttimme eivät perustu yhden työkalun antamaan tulokseen. Pyrimme aina tuottamaan lisäarvoa ajattelemalla kuten vastustaja ja muodostamalla siten sopivan strategian kuhunkin toimeksiantoon. Pyrimme ajattelemaan kuin hakkerit.

Päävastuullinen testaaja

Päätestaajamme ja resident hakkerimme on Jarmo Puttonen. Jarmo tunnetaan paremmin tietoturvapiireissä nimeltä Putsi. Jarmo on Suomen kovimpia tietoturvatestaajia ja hän tekee työkseen sekä perinteistä tietoturvatestausta että bug bounty -ohjelmia. Jarmo on Suomen menestyksekkäin bug bounty  hakkeri ja hän on HackerOne-alustalla jatkuvasti maailman top-100 listalla. Suomalaisissa bug bounty -ohjelmissa Jarmo on niittänyt mainetta ja kunniaa muun muassa LähiTapiolan, Veron, Suomifi:n sekä Väestörekisterikeskuksen ohjelmissa. Jarmo on myös työskennellyt ohjelmistosuunnittelinana, josta syystä hänellä on kokemusta ja osaamista erilaisten ohjelmointikielten käytöstä – ja niiden heikkouksista.

Jarmo Puttonen
Jarmo Puttonen

Ideoidaan yhdessä

Ideoimme aina asiakkaan kanssa yhdessä mahdolliset toimeksiannot. Testaustapoja ovat esimerkiksi

  • Kertaluontoiset testit ja tarkistukset (tai harvemmin kuin kerran vuodessa toistuvat)
  • Jatkuva testaaminen tai tutkiva testaaminen  (recon-toiminta)
  • Projektitestaaminen (sprinttitestaaminen osana kehitysprosessia)
Lopullinen malli päätetään aina asiakkaan kanssa asiakkaan tarpeesta riippuen. Voimme myös toimia yhdessä asiakkaan tiimin kanssa.
Team workshop

Pelkkä pentestaus? Onnistuu.

Suoraviivaisissa pentestauksissa meillä on etukäteen määritelty kolmetasoinen malli, jossa meillä on kiinteä hinnoittelu. Mallien eroavaisuudet ovat erityisesti uhkamallinnuksessa sekä raporttien ja läpikäyntien laajuudessa. Jokaisessa mallissa toimitamme kaikki havainnot asiakkaille.

Malleina ovat Full, Agile ja Limited.

Mallit soveltuvat yhden webbisovelluksen tai sovelluskokonaisuuden (esim. sovellus + API) testaamiseen. Laajemmat kokonaisuudet arvioidaan ja kustomoidaan erikseen Custom -mallissa.

Koodikatselmointi

Koodikatselmointia tehdään harvoin sellaisenaan. Koodikatselmointi tapahtuu yleensä osana pentestaustoimeksiantoa, tukevana lisätoimenpiteenä itse testaukseen. Aina ei myöskään sovelluksen koodia ole kattavasti tarjolla.

Suosimme kuitenkin koodikatselmoinnissa automatiikkaa ja käytämme mielellämme Veracode-työkaluja (SAST ja SCA) tässä hyväksemme. Veracode on jatkuvaan tietoturvan testaukseen tarkoitettu staattisen analyysin työkalu, mutta me voimme myös myydä toimeksiantojen osana ns. single scaneja.

Työkalut

Käytämme työkaluina perinteisiä pentestaustyökaluja kuten Burp Suitea. Lisäksi käytämme erilaisia täsmätyökaluja riippuen toimeksiannosta ja järjestelmien tekniikoista.

Erikoistyökaluina ja erikseen lisensoitavissa toimeksiantokohtaisesti ovat myös seuraavat:

  • Holm Security Vulnerability Management Platform – sekä kertaluontoinen että jatkuva testaus
  • Holm Security Fraud Assessment – phishing-simulattori, voidaan hyödyntää osana red teamingia
  • Veracode SAST ja SCA – sovellusten ja sovelluskoodin kertaluontoinen staattinen analyysi
  • RedWolf platform – erityisesti DDoS-testauksen alusta, jolla on mahdollista tehdä isompia testausohjelmiasisältäen valtavasti erilaisia työkaluja
  • Spamhaus Passive DNS – DNS-hakukone ja tietokanta

Lisäksi hyödynnämme erilaisia OSINT tietolähteitä hyökkäyspintalan selvittäiseksi red teaming ja recon toimeksiannoissa.

Redteaming - Search Engine
Blogit
Thomas

Red Teaming ja Recon

Recon and red teaming can be done separately, but they also work hand in hand. It may be a good idea for a company to do a thorough recon to understand the adversaries view on the organization – and this not only in the technical sense.

Read More »
OWASP Top-10 Application Risk
Blogit
Thomas

Mitä on pentestaaminen?

Yleinen web-sovelluksen tietoturvan arviointiin käytetty työkalu on tunkeutumistestaus. Rakkaalla lapsella on monta nimeä, ja tunkeutumistestaus tunnetaan myös nimellä pentest eli englanniksi penetration testing. Kyseessä on luvallinen simuloitu hyökkäys, jolla pyritään käyttämään sovellusta siten, että se voi olla vahingollista joko järjestelmälle, järjestelmässä olevalle tiedolle tai järjestelmää kättäville henkilöille.

Read More »
Auditoinnista raporttiin
Blogit
Thomas

Miten toteutamme auditoinnin

Kun asiakas on todennut auditointitarpeen ja tilannut meiltä auditoinnin, toteutus aloitetaan määrittelemällä yhdessä auditoinnin tavoitteet ja osa-alueet. Tässä työvaiheessa on tyypillisesti mukana asiakkaan puolelta järjestelmästä tai projektista vastaava henkilö ja/tai hänen valtuuttamansa henkilöt.

Read More »
Auditoinnin punainen lanka
Blogit
Thomas

Miten tilaan onnistuneen auditoinnin?

Auditoinnin tilaaminen aloitetaan määrittelemällä sen tarkoitus. Näin saadaan heti lähtökuopissa kiinni siitä, mitä tavoitellaan ja mitä sillä voi enimmillään saavuttaa. Tavoitteiden on oltava realistisia ja niihin on aina luettava mukaan myös oman toiminnan kehittyminen ja virheistä oppiminen.

Read More »

ota yhteyttä

Pyydä rohkeasti lisätietoa. Vastaamme todennäköisesti nopeammin kuin osasit kuvitella.