Kyberrikos 2018 - verkkokaupan kyberriskit ja niihin varautuminen
1. Verkkokauppa.com kyberriskit ja niihin
varautuminen
Vähittäiskauppaa verkossa
(ja 4 myymälää)
Kyberrikos 2018
Tomi Järvinen
Tietoturvapäällikkö
• Riskejä, toteutuneita riskejä
• Suojakeinot ja käytännöt
• Hakkerointitapaus
2. Verkkokauppa.com numeroita
• Omat konesalit pääkaupunkiseudulla
• Useampi 100 virtuaalipalvelinta, > 90% linux, liiketoimintaan liittyvät Foobar-Linuxilla
• Korkea käytettävyys erittäin tärkeä, Infran SLA 99.999 tasolla.
• Vikasietoinen verkko, useampi kuitu, radiolinkki...
• 4,5 – 5 miljoonaa vierailijaa/kk
• Black Friday 2017, ainoa isoista joka oli pystyssä
• OHO- päivinä kymmeniä tuhansia yhtäaikaisia kävijöitä
• CD/CI Deploymentteja keskimäärin 20 / päivä (master - > tuotantoon 8-9 min)
• Tuhansia automaattitestejä / deployment (kesto esim. 3000/12sek, - 500/1-2 min)
3. Verkkokauppa.com järjestelmä
• Järjestelmänä itsekehitetty ERP, varastohallinta, kassat, osto, back-end ja
Web omaa tuotantoa
• Nyt ~40 kehittäjää, Scrum masterit, UI
• Teknologiaa mm. PHP, HTML, CSS, JS, Ansible, Node.js, React & Redux,
Docker, Kubernetes, Gitlab, Robot, Selenium, R, Python
• Muutos käynnissä monoliitti-ERP:stä microservice arkkitehtuuriin
• Continuous deployment, continuous integration, konttien käyttö
• Jotain Verkkokaupan komponentteja myös kumppaneilta, esim business-
analytiikkaa, tuotesuosituksia
4. Riskejä
• Tulva, laaja lakko, epidemia, rekka etuovesta sisään
– Katastrofiskenaariot, todellinen todennäköisyys?
• ”Perinteiset kyberriskit” DDos, malware outbreak, tietomurto...
• Toimitilat
– ”Trukki tavarahissiin”, kuljetuksiin saattaa tulla suurikin viive
– Sähkökatko, tietoliikennevika, palvelintilojen ongelma
• Maineriskit, taloudelliset riskit
– Iso moka verkossa, yllättävä markkinamuutos
• Tietovuoto, monilla eri tavoilla
– Näytöltä, roskista, möläytys kassalta, järjestelmävika
5. Riskejä
• Huijaukset, luottotappiot
– Erilainen rikollinen toiminta, ulkopuoliset tai sisäiset yhteistyössä
• Kaupan järjestelmä (ERP, Front, Backend, ”koodi”)
– Suunnitteluvirheet, bugit, koodaajien työasemat, ”developer as a target”,
kirjastot
• Henkilöiden toiminta
– Sisäiset mokat, tahallinen tai tahaton
– Kalasteluihin tai haittaohjelmiin lankeaminen
– Asiattomat toimistotiloissa, ilkivalta, varkaus
• Kumppanit
– Lakko,”siivoja lataa puhelinta case”
6. Myytävä ylimmälle johdolle
• Tietoturvan rakentamisessa ensimmäinen tehtävä
(riskitaso, tavoite, strategia, investointi)
• Vuosittainen ”one to one”, puhumista ja
perusteluja, miksi joku asia kannattaa?
mitä jos ei tehdä mitään? hyödyt esiin
• Asiat pitää saada esitettyä johdon kielellä
7. Järjestelmällinen riskienhallinta
• Seuraava tehtävä, mihin paukut kannat laittaa?
Luokittelu, järjestelmät, liiketoiminta, tieto-omaisuus
• Tarkka harkinta, todellinen todennäköisyys ja vaikutus liiketoiminnalle
• Analytiikkaa mukaan, statistiikkaa, yhden asiakkaan tietojen vuoto
laiteen mukana vs tunnin katkos kaupankäynnille?
• Työkalujen ja käytäntöjen pitää olla selkeitä ja helppoja käyttää
• ERM-tyyppinen työkalu pakollinen (tietokanta, linkitykset, ylläpito)
• Linkitys poikkeamien hallintaan sekä jatkuvuussuunnitteluun
8. Teknologian periaatteita
• Avoin koodi, tuetut komponentit
– Varmistetaan koodin/kirjastojen alkuperä ja turvallisuus
• CD/CI kehitysputki
– Palautuminen nopeaa, hyvin harvoin laaja vaikutus
– Pienet helposti katselmoitavat muutokset
– Kontit (päivitys/vko, CVE, ei ajeta roottina, ym)
• Infran haavoittuvuudet hoidetaan käytännössä heti
– päivityksistä aiheutuneita katkoksia ei juurikaan tule
• Motivoitunut ja osaavan kehitystiimi
– rekrytoinneissa ”´tiimin sopiminen, kokemusta ja tietoturvaa”
• Haavoittuvuuksien tai virhekonfiguraatioiden testaus
• Teknologiatiimien tietoturvakulttuuria rakennettu pitkään
9. Tietoturvaaorganisaatio
• Sec-team
– Kuukausipalaverit, kevyt ECAB jos tarpeen
– Mukana IT, Kehitys, Myymälä, Huolto, Asiakaspalvelu
– Kouluttaa, tiedottaa
– Helppo yhteydenotto mm. Security@verkkokauppa.com
https://verkkokauppa.com/security.txt , ”bug bounty”
• CIRT toiminta
– Mukana tärkeimmät kumppanit, IT ja kehitys, käytössä chattikanava
• Secops
– Kehitykseen järjestelmällisempää varautumista
– Proaktiivisuutta
– Kehityslapuissa tietoturva ja tietosuojatägit
11. DRP testit - opittua
• Vaihtuva teema
– IT-Infra, tietomurto, kiinteistöuhka, henkilöuhka
• Testin suunnittelu
– Varaa aikaa, mahdollisimman realistinen skenaario, kutsut ajoissa
• Järjestelyistä
– Kokoontuminen esim. eri neuvotteluhuoneisiin simuloimaan erillään oloa
– Alku aina hektinen, koordinaattorille ensimmäisten minuuttien tarkistuslista
– Intranetin työtilaan rakennettu työtila jossa asioita julkaistaan aikajanan mukaan
– Lokin pitäminen hankalaa, kaikki tiedottaminen samaan työtilaan ”sivu: Tiedote
medialle” tms.
Erinomainen
todiste
auditoijille tai
viranomaisille
Erinomainen
todiste
auditoijille tai
viranomaisille
12. Todisteiden kerääminen etukäteen
• GDPR oli hyvä herättäjä aiheeseen, mutta aiheuttanut myös
monen muun asian unohtamisen
• Muu vaatimuksenmukaisuus
• Mahdollinen rikostutkinta
• Vaatii suhteellisen raskaan dokumentoinnin ja ohjeistukset
• Vuosikellon mukainen toiminta, kirjaa versiot, tekijä
• Toisaalta ketterä CD/CI-tyyppinen kehitys ei ole ongelma
13. Hankinnat ja sopimukset – opittua
– Vaadittava sopimuskehikko valitettavan hankala
• Kaupallinen sopimus, salassapitosopimus/turvallisuussopimus
tietoturvaan ja jatkuvuuteen liittyvät tekniset vaatimukset, DPA (Data
processing Agreement) IFP (Instructions for Processing), SLA,
palvelutasosopimus, jne. jne...
– Kompromissit, niihin varautuminen jo vaatimuksissa
• Oikeus auditoida, suostumus alihankkijoiden käyttöön.
• Voidaan käyttää korvaavia suojakeinoja
• Vaatimukset suhteessa hankkeeseen (meriteknologiaa vai
kannettavia)
14. Sopimukset ja usein puuttuvat asiat
• Todellinen kuvaus henkilötiedoista
• Lain vaatimukset saattavat täyttyä, mutta onko oikeasti
toteuttamiskelpoinen tai onko lausekkeista hyötyä?
Esim. Vaatimukset suoraan asetuksesta ”right to erasure”,
”portability”
• Staattiset kontaktipisteet
• Tietovuodosta ilmoittamisen aikaraja, ”without undue delay”
• Päivitys ja seuranta, kumpi on aktiivinen?
• Meille lähes kriittinen, aplikaation sopimukseen oikeus
muokata koodia ja integroida
15. Tietoisuus
• Koko henkilökunta
– Kaikille ryhmille räätälöity tiivis koulutus (10min – 1 h)
– IT, Kehitys, Huolto, asiakaspalvelu kohtaa hyvin erilaisia haasteita
– Johtoryhmälle
• Myymälät, taukotilat, Intra, postereita, jaettava pikaohje
– Tietoiskuja
– Säännöllisesti peruskoulutus
• Vastuunjako
– Portaittainen: asiantuntija esimiehille, esimiehet työntekijöille
– Toimiva käytäntö myös uusille, vaikka vaihtuvuus
olisi nopeaa
17. Mitä tapahtui, mitä opittiin
• Viikonloppuna toimittajalta soitto 24-h kioskiin
– Kriisiorganisaation todellinen testi, kokoontuminen ”chatissa”, heti suunnittelu
käyntiin, tiedotteita (mm. Lehdistötiedote)
• Käytäntöjen tarkistus/perustaminen
– Viestintä kaipaa hiomista, turhaa selitystä, ei ketään kiinnosta että
kyseessä oli Json-feedi palveluntarjoajalta
– Hankinta ja sopimukset, tehtävä uusi kierros sidosryhmien kanssa, liiketoiminta
innostuu jostain uudesta kuten ennenkin - > koulutusta taas
– Auditointioikeus tapauksesta riippuen, tekninen tarkistus säännöllisesti tai edes kerran
• Teknistä kehitystyötä
– Voidaanko sisääntulevia Api-yhteyksiä tai feedejä varmistaa, esim. signauksella
– Voidaanko kumppanilta saada vain se, missä he ovat hyviä
– Vielä lisää tarkkuutta, mitä ja miten suoraan kaupan sivuille