TigerTeam - suomalainen tietoturvablogi

Äskettäinen vakava tietoturvalöydös GitHubissa nostatti varmasti monien kulmakarvoja. Vaikka kyseessä ei ollut pahantahtoinen yritys hyökätä järjestelmää ja sen tietoja vastaan, koko kuviossa on monta mielenkiintoista ja huolestuttavaakin puolta.

Ensinnäkään moni ei varmaankaan ole oikeasti miettinyt, kuinka paljon avoimiin open source -komponentteihin oikeasti luotetaan. Tässä tapauksessa olisi ollut verrattain triviaalia saada ujutettua pahantahtoista koodia sopiviin projekteihin. Ehkä asia olisi huomattu, ehkä ei. Moni ei ole itse käynyt läpi käyttämäänsä avoimen lähdekoodin koodia, mutta voi toivoa että projektin kehittäjät kiinnittäisivät asiaan huomiota.

Toisekseen haavoittuvuuden käsittely (varsinaisesti Ruby on Railsissa) ei ehkä mennyt kaikkien taiteen sääntöjen mukaan. Selviönä ei voi pitää, että aina vakavatkaan ongelmat saataisiin oikeasti nopeasti korjattua.

Asiasta on kuitenkin nostettava esille sen perimmäinen ongelma, eli Ruby on Railsissa oleva haavoittuvuus. Se ei ole mitenkään uniikki, vaan samanlaisia ongelmia on nähty muissakin teknologioissa.

Entä kun parametreina onkin vihamielistä sisältöä

Teknisesti GitHubin tapauksessa kyse oli Ruby on Railsin ns. Mass Assignment -toiminnon väärinkäytöstä, jossa tietokantaa päivitetään automaattisesti käyttäjän lisäämien parametrien perusteella. Näin tapahtuu myös niiden kenttien osalta, joita ei ollut tarkoitettu päivitettäväksi.

Hyvin samantyyppinen ongelma todettiin vuonna 2008 Spring MVC -frameworkissa, tapaus tunnetaan nimellä Data Submission to Non-Editable Fields. Spring MVC:ssä todettiin pari vuotta sitten myös vakavampikin ongelma, jossa käyttäjän lähettämät request-parametrit käsiteltiin niin, että tuloksena palvelin lähti lataamaan taglibien koodia hyökkääjän antamasta HTTP-osoitteesta – uskomatonta mutta totta. Haavoittuvuus referensseineen on kuvattu CVE-2010-1622-dokumentissa.

Vastaavanlainen tapaus on Strutsin OGNL-lausekkeiden käsittely. Struts käsittelee käyttäjän antamia OGNL-muotoisia request-parametreja automaattisesti ja mahdollistaa esimerkiksi järjestelmäkomentojen ajamisen etänä palvelimella. Tekniikkaan liittyy lukuisa määrä vakavia haavoittuvuuksia (vanhimmasta uusimpaan CVE-2007-4556, CVE-2008-6504, CVE-2010-1870, CVE-2012-0391 ja CVE-2012-0838). Nämä haavoittuvuudet ovat siis olemassa vaikkei kyseistä toimintoa varsinaisesti käyttäisikään.

Kaikki tapaukset ovat vakavia tietoturvaongelmia. Parhaiten niitä kuvaa seuraava Dr Dobb’s Journalissa esitetty kaavio (Thompson, Whittaker: ”Testing for Software Security”, Dr Dobb’s Journal November 2002):

Pääosin ohjelmisto tekee sen mitä sen on speksattu tekevän. Kuitenkaan kaikilta osin se mitä järjestelmän speksataan tekevän, ei välttämättä päädy toteutukseen. Tällöin syntyy juuri niitä tyypillisiä ohjelmistobugeja. Yllättävää kyllä, ohjelmisto toisaalta tekee asioita, joita sen ei ole tarkoitettu tekevän.

Nämä ovat hyviä kandidaatteja tietoturvaongelmien lähteiksi, ja juuri tällaisista asioista edellä mainituissa tapauksissa on kyse.

Mistä tällainen speksaamaton toteutus sitten syntyy? Tietenkään harva koodailee järjestelmään ylimääräisiä kiemuroita ilman mitään varsinaista tarvetta, oli se kirjattu spekseihin tai ei.

Käytännössä kyse on jostain seuraavista asioista:

• Järjestelmän toimintalogiikkaa ei ole mietitty riittävän kattavasti, joten tietyillä syötteen arvoilla oikea toiminta on jätetty määrittämättä. Koska järjestelmän täytyy kuitenkin tehdä jotain syötteelle, ollaan vaarallisella vyöhykkeellä. “Hauskimpia” esimerkkejä ovat online-ostospalvelut, joissa voi esimerkiksi jättää palvelulle negatiivista tippiä. Tällöin ostoksen loppusumma pienenee sopivasti. Koska missään ei erikseen määritelty (tai mietitty) mitä negatiivisille arvoille tehdään, niin järjestelmä luonnollisesti laskee loppusumman ostosten hinnan ja tipin matemaattisena summana.

• Järjestelmässä käytetään komponentteja, jotka helpottavat koodaajan työtä ja tekevät erilaisia asioita automaattisesti ja pyytämättä. Erilaiset automaattiset request-parametrien käsittelyt menevät juuri tähän kategoriaan. Kätevä toiminto, kyllä, mutta kovin vaarallinen. Jos miettii millainen määrä koodia oikeasti ajaa tyypillistä web-tietojärjestelmää, niin räätälöidyn ohjelmakoodin osuus on häviävän pieni verrattuna frameworkeihin, komponentteihin, sovelluspalvelimen koodiin ja muuhun ajettavaan koodiin, vaikka jättäisi käyttöjärjestelmätason kokonaan huomioimatta. Tämän huomaa helposti katsomalla virhetilanteiden yhteydessä näkyviä ns. stack traceja, joissa kutsupuun muutama taso on räätälöityä koodia ja 100 tasoa kaikenlaista muuta koodia.

• Järjestelmässä on tuotantokäytön kannalta kuollutta koodia, esimerkiksi testaukseen ja vianselvitykseen käytettävää logiikkaa. Tällaista logiikkaa voi tietenkin olla myös muualla kuin räätälöidyssä koodissa, tyypillisesti vaikkapa frameworkin esimerkkikoodin muodossa.

Pahantahtoisen koodin ja takaporttien mahdollisuutta ei tietenkään voi sulkea pois, mutta käytännössä tällaiset tapaukset ovat kovin harvinaisia.

Mitä asialle sitten pitäisi tehdä?

Pohjimmiltaan pitäisi pystyä tarkasti määrittämään, mitkä ovat järjestelmän kannalta sallittuja ja odotettuja syötteitä (esim. URL-osoitteita, parametrien nimiä ja syötteiden arvoja). Kaikki muu pitäisi olla kiellettyä. Käytännössä tällaisen teknisen määrityksen muodostaminen, ylläpitäminen ja tekninen käyttö on hyvin hankalaa. Yhtenä vaihtoehtona on varmistaa, että käyttäjältä hyväksytään vain toimintoja ja syötteitä, jotka järjestelmä itse tarjoaa käyttäjälle. Parhaimmillaan tähän soveltuu käytetyn UI-frameworkin omat suojaukset (esim. linkkien kryptaus à la Wicket), mutta ulkoisiakin komponentteja voi sovitella paikalleen (esim. HDIV). Voi myös kerätä lokia järjestelmälle tulevista syötteistä ja parametreista ja sitten määrittää sallittu syötejoukko. Tietysti itse syötteiden arvoja harvoin pystyy kiinnittämään.

Jos ongelman onnistuu taklaamaan, samalla tulee usein hoitaneeksi OWASP:in Top 10 -listan ongelmat A4, A5 ja A8. Käänteisesti toimiminen ei kuitenkaan toimi eli Top 10 -listan huomioiminen ei suojaa tällaisilta ongelmilta.

Pahimpaan on kuitenkin syytä varautua ja rakentaa järjestelmän puolustus useamman kerroksen varaan ja hyviä periaatteita noudattaen. Toimiva komponenttihaavoittuvuuksien seuranta on myös keskeinen osa haavoittuvuuskartalla pysymistä.

Vielä lyhyesti alun GitHub/Ruby on Rails -ongelmaan. Hyviä yksirivisiäkin puolustustapoja sitä vastaan löytyy, kunhan niistä ollaan tietoisia ja velvoitetaan koodaajatkin seuraamaan valittua toimintatapaa. Tapa tulee kirjata kehittäjien Secure Coding Guidelinesiin tai vastaavaan käytännön ohjeeseen. Ja jos ohjeistusta ei vielä ole, sellainen on viimeistään nyt hyvä muodostaa ja ottaa käyttöön.

Lisää aiheesta: How Homakov hacked GitHub and the line of code that could have prevented it

Vain vuosi siitä kun edellinen versio BSIMM:stä tuli ulos McGraw, Miguel ja Chess ovat päivittäneet BSIMM:n uuteen 2.0-aikaan. BSIMM (Build Security In Maturity Model) on tietoturvallisen ohjelmistokehityksen kypsyysmalli, jonka avulla voidaan arvioida organisaation kyvykkyyttä tuottaa tietoturvallisia ohjelmistoja. Kysymys on siis siitä kuinka hyvin tietoturva otetaan ohjelmistokehityksen aikana huomioon. BSIMM:n tekijöillä on ollut tavoitteena muodostaa sellainen malli, jota oikeasti on käytetty käytännössä, ja tekijät ovat keränneet eri yrityksiltä tietoa siitä, millä keinoilla ja menetelmillä yritykset ovat toteuttaneet tietoturvallista ohjelmistokehitystyötä.

Pienempiä toimijoita mukana otoksessa

Tällä kerralla muutokset mallissa ovat olleet pieniä, mutta haastateltujen yritysten määrä on kasvanut 30:een, ja mukaan on tullut aikaisempaa pienempiä yrityksiä. Tietoahan ei ole julkaistu suoraan, mutta se on pääteltävissä keskiarvojen pienentymisestä.

Yksi merkittävimmistä tunnusluvuista kuitenkin on pysynyt samana – tietoturvallisen ohjelmistokehityksen yksikön koko on vieläkin 1 % ohjelmistokehittäjien lukumäärästä. Tietoturvaa saa siis halvalla? Ehkä ei niinkään. Mallissa on 109 tehtävää tai toimintoa, joista jokaista harrastetaan siis vähintään yhdessä yrityksessä. Parhaimmat yritykset pystyvät kuitenkin tekemään samanaikaisesti 74 näistä, ja huonoimmat yhdeksän keskiluvun ollessa noin viidenkymmenen paikkeilla. Eli prosentilla saa noin puolet tietoturvasta? Onko malli liian kunnianhimoinen, vai onko osa tehtävistä sellaisia, jotka vain soveltuvat erityisen hyvin jollekin organisaatiolle? Ilmeisesti ainakaan mallin tekijöiden mielestä tehtäviä ei ollut liikaa, sillä 2.0-versiopäivityksessä vain niiden tasoja korjailtiin.

Mikä sitten harvojen herkkua?

Kuitenkin mallissa on vielä kuusi tehtävää, joita tekee vain muutama yritys. Automaattiseen koodivirheiden analysointiin ja raportointiin, missä otetaan huomioon havainnot useasta lähteestä, uskoo vain yksi yritys. Tällaisen rakentamiseenkin toki voi jo mennä vuosi jos toinenkin, ja tulevaisuus näyttää, pysyykö tämä mielenkiintoinen mutta epäilemättä harvoin kustannustehokas koodinkatselmointityökalu mallissa mukana.

No mitä useimmat tekevät? 66 % yrityksistä tekevät näitä, mutta kirjoittajatkin myöntävät, että tilastoista ei taida olla mallin tekijäksi, vaan suosittelevat, että tietoturvallista ohjelmistokehitystä kehittävät harkitsisivat seuraavia toimenpiteitä:

• Tietoturvakriteerien asettaminen [SSDL Gates]

• Vaatimuksenmukaisuusvaatimusten [Compliance] ymmärtäminen (PCI, SOX, HIPAA, VARe, VAHTI, tietoturvatasot)

• Yksityisyydensuojan tietoisuuden korostaminen [promote]

• Ohjelmistokehityksen tietoturvapolitiikan luominen asiakastarpeita ja säätelyä vastaavaksi

• Tietoturvatietoisuuskoulutuksen järjestäminen

• Tiedon luokitteluun ja säilytykseen tarkoitetun järjestelmän luominen

• Asiakkaan tarpeita vastaavien tietoturvastandardien luominen

• Tietoturvavaatimuksien katselmointi

• Sekä automaattisten työkalujen että manuaalisen katselmoinnin käyttäminen

• QA:n raja-arvotestauksen tukemisen varmistaminen [edge/boundary value condition testing]

• Ulkoisen hyökkäystestaajan käyttäminen

• Verkon suojauksen varmistaminen

• Poikkeustilaprosessien luominen

• Tuotannossa havaittujen virheiden vieminen tuotekehitykseen

Lista ei vaikuta mitenkään hirvittävän vaativalta, ja voihan olla, että nämä tehtävät toteutetaan suurimmassa osassa yrityksiä, koska ne nyt vain ovat helpoimpia. Mallin kattavuuden arviontia eivät ulkopuoliset tämän tarkemmin pääse arvioimaan, koska kirjoittajat eivät julkista tarkempia tutkimustietoja.

BSIMM sinällään näyttäisi olevan mielenkiintoinen malli tietoturvallisuuden ohjaamiseen, joka korostaisi mallin käytettävyyttä verrattuna ylhäältä annettuun malliin. Tällä hetkellä joko suppeahko otos verottaa johtopäätösten tekemistä tai malli sinällään ei toimi. Se ei kylläkään vie arvoa yhdestäkään mallissa esiteltävästä tehtävästä ja aivan varmasti voidaan todeta, että jos yritys pystyy toteuttamaan puoletkin näistä tehtävistä on tietoturvan taso merkittävästi paremmalla tolalla kuin ilman näitä tehtäviä.

Vertailun vuoksi voidaan mainita, että erilaisia kypsyysmalleja tietoturvalliseen ohjelmistokehitykseen on olemassa useita, joista OWASPin OpenSAMM lienee viimeisin, ja SSE-CMM niitä vanhimpia, ja se on viety ISO-standardiksi ISO/IEC ISO 21827 saakka. Microsoftilla on oma SDL (Security Development Lifecycle) ja OWASPilta löytyy vielä CLASP-prosessinsa – Comprehensive, Lightweight Application Security Process. Nixu tarjoaa Turvaluotsi-palvelua ohjelmistokehityksen tietoturvan parantamiseksi. Palvelu on toteutettu käyttäen hyväksi alan parhaita käytäntöjä.

Tämä blogikirjoitus on tiivistelmä OWASP Helsingin alajaoksen 17.11. järjestetyssä tilaisuudessa pitämästäni esityksestä Manuaalinen ja automaattinen koodianalyysi (Manual vs. Automated Code Analysis). Englanninkielinen esitys on ladattavissa myös jaoksen verkkosivuilla.

Sovellustietoturvan tarkistus voidaan jakaa neljään osa-alueeseen, sen mukaan onko tarkastus dynaamista vai staattista ja tehdäänkö tarkastus automaattisesti vai käsin. Tässä tarkastellaan vain staattisen eli koodiin perustuvan tarkastuksen eroja, ulkopuolelle jäävät siis pentestit yms.

Automaattinen koodin skannaus voi perustua monenlaiseen lähestymistapaan, yksinkertaisimmillaan pelkkään tekstimatchaukseen ja monimutkaisimmillaan koko koodin jäsentämiseen ja analysointiin tai jopa tilastollisiin menetelmiin. Ääripäiden väliin jää token matching, syntaksipuuhun perustuva haku (jolloin analysaattori ymmärtää erottaa esim. funktiokutsut ja muuttujat toisistaan), ja data flow analyysi.

Käsin koodin läpikäynti voi tapahtua hyvin monella tavalla, mutta tyypillisiä lähestymistapoja ovat mm. tiettyjen merkkijonojen etsiminen (työkalulla), hyökkäyspinnan selvittäminen ja tarkastelu, input/output-polkujen ja komponenttikirjastojen konfiguraation tarkastelu, autorisointilogiikan ja esimerkiksi hyväksymissääntöjen validointi ja ennen kaikkea arkkitehtuurin analysointi mm. sisäisten rajapintojen osalta. Luonnollisesti käytössä ovat myös erilaiset tarkistuslistat.

Automaattisen analysoinnin etu on kiistatta se, että se on huomattavasti nopeampaa, laaja-alaisempaa (ainakin katetun koodin mielessä) ja toistettavaa. Automaattisesta analysoinnista saatavat tulokset on kuitenkin jonkun aina tulkittava ja arvioitava löydöksistä:

• mitkä ovat todellisia löydöksiä eli oikeita haavoittuvuuksia?
• mitkä ovat vääriä hälytyksiä?
• miten paljon haavoittuvuuksia jäi löytymättä?

Lisäksi todellisten löydösten korjaukset täytyy suunnitella, mihin työkalu joko antaa tai ei anna hyvää suositusta.

Application Security Verification Standard (ASVS)

OWASP:n Application Security Verification Standard eli ASVS määrittää vaatimukset eritasoisille sovellustietoturvan tarkistuksille. Se koostuu neljästä tasosta, joista ensimmäinen kattaa pintapuolisen tarkistuksen ja neljäs taso edellyttää jo hyvinkin perusteellista tarkastusta.

Karkeasti ottaen ASVS:n ensimmäinen taso voidaan toteuttaa automaattisilla (staattisilla ja dynaamisilla) työkaluilla, joskin niiden antamat tulokset täytyy käydä käsin läpi. Toiselle tasolle päästäkseen sovellus tulee käydä manuaalisesti läpi, dynaamisesti (käsin testaamalla) ja/tai staattisesti (käsin katselmoimalla). Kolmas ja neljäs taso syventävät käsin tehdyn katselmoinnin vaatimuksia. Työkalujen käyttö on sallittu muillakin kuin ensimmäisellä tasolla, mutta silloin ne toimivat vain käsin tehtävän tarkastuksen apuna.

ASVS:ssä on 14 vaatimusosa-aluetta, mm. autentikaatioon, syötteen validointiin, tiedon suojaamiseen ja lokitukseen liittyen. Näille vaatimuksille on tarkemmat sisältömääritykset, joista kunkin kohdalta on mainittu, miltä osin tarkastusvaatimus sisältyy millekin ASVS:n tasolle, ts. käytännössä onko sen katsottu voitavan tehdä automaattisesti vai käsin ja dynaamisesti vai staattisesti.

Semitieteellisesti tarkasteltuna, kun verrataan ASVS:n tasoille 1B (eli automaattinen koodin skannaus) ja 2B (eli käsin tehtävä koodin läpikäynti) asetettuja vaatimuksia, havaitaan että taso 2B sisältää huomattavasti enemmän tarkastuskohteita. Nämä ovat käytännössä sellaisia, joihin ei automaattinen työkalu edes pure, esimerkkinä:

• V2.5 Verify that all authentication controls (including libraries that call external authentication services) have a centralized implementation.

• V2.13 Verify that account passwords are salted using a salt that is unique to that account (e.g., internal user ID, account creation) and hashed before storing.

• V14.2 Verify that security control interfaces are simple enough to use that developers are likely to use them correctly.

Toisaalta taas, automaattinen työkalu kelpuutetaan tarkastamaan seuraavat asiat lähdekoodista:

• V5.2 Verify that a positive validation pattern is defined and applied to all input.

• V6.1 Verify that all untrusted data that are output to HTML (including HTML elements, HTML attributes, JavaScript data values, CSS blocks, and URI attributes) are properly escaped for the applicable context. (Saattaa onnistua ns. tekstimatchingiin perustuvilta työkaluilta.)

• V11.2 Verify that the application accepts only a defined set of HTTP request methods, such as GET and POST. (Vaatii työkalulta ymmärrystä konfiguraatiosta, esim. Struts tai Spring MVC.)

Automaattisen koodin skannauksen ongelmakohtia

Yleisesti ottaen automaattiselle koodiskannerille ongelmia tuottavat mm. big picturen katsominen ja arkkitehtuurin selkeyden ja turvallisuuden arviointi, ei-toiminnalliset vaatimukset (esim. kuinka hyvin järjestelmä sietää kuormitusta ja DoS-hyökkäyksiä), loogiset virheet esimerkiksi autorisoinnissa, tai puuttuvat tietoturvavaatimukset tai niiden toteutus.

Skannausta hankaloittaa tietysti myös koodi, joka on osa järjestelmää jollain epätavallisella tavalla, esim. plugin, sekä järjestelmän konfiguraation tulkinta, erityisesti kun käytössä on jokin framework kuten Hibernate, Spring, Wicket yms.

Johtopäätökset

Loppupäätelmänä ei voi tietysti sanoa, että jompi kumpi koodin analysointitapa olisi ainoa oikea, mutta ne tukevat toisiaan ja sopivat eri tilanteisiin. Tapojen painotuksessa on syytä pohjata päätös järjestelmän luonteeseen ja riskianalyysiin. Esimerkiksi web-portaalin ohjelmakoodi voidaan saada melko hyvinkin skannattua automaattisesti, mutta monimutkaisen extranet-sovelluksen logiikan monimutkaisuus ja riskit saattavat olla liian suuria automaattiselle työkalulle jätettäväksi.

On siis hyvä tiedostaa, että automaattinen analyysi ei useinkaan anna kovin täydellistä raporttia tietyntyyppisistä ongelmia, ja lisäksi ihmistyötä tarvitaan aina tulosten analysointiin. Toisaalta taas käsin tehtävä läpikäynti voi hyötyä suuresti automaattisten työkalujen kaivamista alustavista tuloksista.

Web-sovellusten tietoturvaa seuraava Web Application Security Consortium on julkaissut päivitetyn version yleisesti käytössä olevien sovellusten tietoturvatilannetta kuvaavasta Web Application Security Statistics -raportistaan. Raportin perustana olevat tiedot on kerätty yli 12 000 web-sovelluksesta sekä testaamalla niitä automaattityökaluilla että analysoimalla sovelluskoodia yksityiskohtaisesti.

Sovelluksista löytyi lähes 100 000 erilaista haavoittuvuutta ja muuta tietoturvaongelmaa. Yleisimmät ongelmatyypit ovat alttius erityyppisille cross-site scripting -hyökkäyksille, jota havaittiin 39 prosentissa analysoiduista sovelluksista, sekä taipumus vuotaa käyttäjälle kuulumatonta tietoa, mihin syyllistyi 32 prosenttia sovelluksista.

Haavoittuvuuksia aiheuttavat sekä ohjelmointi- että järjestelmänhallinta- ja asennusvirheet tasapuolisesti. 57 prosentissa sovelluksista löytyi huolimattomasta toteutuksesta johtuvia haavoittuvuuksia, ja www-osoitteiden perusteella peräti 85 % toimivista järjestelmistä osoittautui tavalla tai toisella puutteellisesti asennetuksi tai konfiguroiduiksi. Vain yksi prosentti tarkastetuista sovelluksista oli täysin PCI DSS -standardin tietoturvamääritykset täyttäviä.

Automaattinen hyödyntäminen helppoa

Huolestumiseen antaa aihetta tieto, että 13% sovelluksista oli sellaisia, joiden tietoturva-aukkoja on mahdollista hyödyntää täysin ohjelmallisesti. Niitä vastaan voi siten hyökätä automaattisesti osoiteavaruutta läpikäyvällä ohjelmalla, joka tunnistaa haavoittuvuudet ja murtautuu niiden avulla sovelluksiin.

Vaikka yleisimmät haavoittuvuudet voidaan myös havaita automaattisesti noin puolessa tapauksista, valtaosa vakavimmista, PCI DSS -luokituksen mukaan Urgent- tai Critical-tyyppisistä ongelmista paljastui vasta käsin testaamalla ja ohjelmakoodia analysoimalla.

Raportin julkaisseeseen konsortioon kuuluu useita johtavia tietoturvayrityksiä, muun muassa HP Application Security Center, Positive Technologies, Whitehat Security ja Veracode. Raportti on luettavissa tässä osoitteessa.

PCI-tietoturvastandardin vaatimus 6.6, joka tähän asti on ollut ainoastaan suositus, muuttuu pakolliseksi tänään 30.6. Vaatimus 6.6 käsittelee web-sovellusten suojausta, joka voidaan toteuttaa kahdella pääasiallisella tavalla: koodikatselmoinnilla tai web-sovelluspalomuurilla.

Koodikatselmointi ei välttämättä tarkoita manuaalista työtä, vaan sen voi toteuttaa myös automaattisilla siihen tarkoitetuilla työkaluilla. Katselmoinnin voi suorittaa kuka tahansa riittävät taidot omaava henkilö yrityksen sisältä tai ulkoa. Mikäli yritys tekee katselmoinnin sisäisesti, tulisi katselmoijan kuitenkin olla organisatorisesti eriytetty web-sovelluksen omistajista/tekijöistä.

Web-sovelluspalomuuri (Web Application Firewall, WAF) on vaihtoehtoinen tapa täyttää tämä PCI-vaatimus. WAF tulee asettaa web-sovelluksen ja asiakkaan (client) väliin niin, että se muodostaa yhden suojauskerroksen lisää perinteisten palomuurien lisäksi sovelluskerrokselle. WAF:n tulisi pystyä reagoimaan tunnettuihin web-hyökkäyksiin kuten niihin, jotka on kuvattu OWASP Top 10:ssä ja PCI-vaatimus 6.5:ssä.

Kannattaa huomioida, että vaikka yritys auditoitaisiin seuraavan kerran esimerkiksi vasta puolen vuoden päästä, on vaatimus 6.6 kuitenkin pakollinen jo tänään.

PCI Council:in hyvä tietopaketti aiheesta löytyy täältä (pdf).