ASVS Standard
ASVS on avatud standard ja kehtestab nõuded internetilehekülgedele ja -teenustele
Autentimine
1. Kõik lehed ja ressursid peavad nõudma autentimist. Välja arvatud need, mis on mõeldud edastama avalikku informatsiooni. (ASVS vastav punkt V2.1)
2. Parooli sisestamisel ei tohi ekraanil olla parool avalikult nähtav. (V2.2)
3. Kogu autentimine peab olema teostatud serveri poolel. (V2.4)
4. Ebaõnnestunud sisselogimine peab lõppema turvaliselt, et ründajale ei jääks võimalust sisse tungida. (V2.6)
5. Paroolide sisestusväljad peavad olema piisavalt pikad, et võimaldada sisestada keerukaid paroole või salafraase. Samuti ei tohi sisestusväli lubada liiga lühikeste ja kergelt ära arvatavate paroolide sisestust. (V2.7)
6. Kõik kasutaja autentimise funktsioonid (nagu näiteks registreerimine, profiili uuendamine, „unustasin kasutajanime“/“unustasin salasõna“, keelatud või vana võti, tehniline tugi), mis võivad uuesti avada konto, peavad olema vähemalt sama turvalised kui esmase autentimise mehhanism. (V2.8)
7. Kasutaja turvatunnuste (kasutajanimed, paroolid, sertifikaadid) vahetamine peab olema sama vastupidav rünnete vastu kui esmase autentimise mehhanism. (V2.9)
8. Kõik autentimise otsused peavad olema logitud. See peab hõlmama ka vigaseid ja puudulikult täidetud autentimise taotlusi. See on vajalik info lehe turvalisuse tagamiseks. (V2.12)
9. Kõik kasutaja paroolid peavad olema krüpteeritud unikaalse võtmega (nt. kasutaja lokaalne ID) ja parooli salvestamisel kasutada bcrypt, scrypt või PBKDF2 meetodit. (V2.13)
10. Kasutaja tuvastamiseks kasutatav info või kasutaja isiklik info ei tohi liikuda krüpteerimata või nõrgalt krüpteeritud kanalite kaudu. (V2.16)
11. „Ununenud parool“ funktsiooni ja muud konto taasavamise teed ei tohi näidata kehtivat parooli ega saata uut parooli avatud tekstina. (V2.17)
12. Kasutajanimede loendamine ei tohi olla võimalik läbi sisselogimise, parooli lähtestamise või „unustasin parooli“ funktsionaalsuse. (V2.18)
13. Aplikatsioonide või selle komponentide juures ei tohi olla kasutusel vaikimisi antud kasutajatunniseid (näiteks "admin /password"). (V2.19)
14. Sisselogimine peab olema kaitstud vertikaalse (ühte kontot testitakse kõikvõimalike paroolidega) ja horisontaalse (kõiki kontosid katsetatakse sama salasõnaga nt. "Password1") katsetuste vastu. Vale parooli sisestamisel peab tekkima viivitus, enne kui lubatakse uuesti proovida. (V2.20)
15. Kõik välise rakenduse autentimiseks kasutatavad kasutajatunnused peavad olema krüpteeritud ja salvestatud kaitstud kohas (mitte lähtekoodis). (V2.21)
16. „Unustatud parooli“ või muu konto taasavamise link peab saatma enne parooli ajaliselt piiratud kehtivusajaga võtme. Võtme alusel saab uue parooli. Täiendavaks autentimiseks võib kasutada ka lisavõimalusi (nt. SMS teel võtme saatmine, mobiili rakenduse kaasamine jne). (V2.22)
17. Unustasin parooli“ funktsionaalsus ei tohi lukustada või muul viisil blokeerida kontot enne, kui kasutaja on edukalt muutnud oma salasõna. See aitab vältida kehtiva kasutajakonto lukustumist. (V2.23)
18. Konto taasavamiseks kasutatavad küsimused/vastused ei tohi sisaldada üldiselt teadaolevaid fakte. (nn. "salajased" küsimused ja vastused). (V2.24)
19. Süsteemi peab saama seadistada mitme varasema parooli taaskasutamise keelamisele. (V2.25)
Seansihaldus
1. Aplikatsioon peab kasutama keskkonna sessiooni haldamise vahendeid. (V3.1)
2. Kasutaja väljalogimisel peab sessioon muutuma kehtetuks. (V3.2)
3. Mitteaktiivse kasutaja sessioon peab ise sulguma kindlaksmääratud ajavahemiku järel. (V3.3)
4. Administraatori poolt seadistatav ajaperiood peab toimima, olenemata kasutaja tegevusest (absoluutne timeout). (V3.4)
5. Kõik leheküljed, mis nõuavad juurdepääsuks autentimisist, peavad sisaldama ka logout linke. (V3.5)
6. Sessiooni ID ei tohi olla mujal kui küpsiste päises, aga mitte URL osades, veateadetes või logides. See hõlmab ka kontrolli, et URL ei saa seansiküpsiseid ümber kirjutada. (V3.6)
7. Sessiooni kaaperdamise vältimiseks tuleb sisselogimisel luua alati uus sessiooni ID. (V3.7)
8. Sessiooni id peab muutuma pärast uuesti autentimist. (V3.8)
9. Ainult rakenduse keskkonnas loodud sessiooni ID-sid tohib aplikatsioon lugeda kehtivateks. (V3.10)
10. Autenditud sessiooni võti peab olema piisavalt pikk ja juhuslik, et taluda sessiooni võtme äraarvamise laadseid rünnakud. (V3.11)
11. Sessiooni autentimise jaoks kasutatavad küpsised peavad järgima sellele saidile seatud piiranguid. Küpsistele esitatavad nõuded peavad järgima ka üldise nõudeid, näiteks „single-sign-on“. (V3.12)
12. Sessiooni autentimiseks HTTP kaudu saadetavate võtmete küpsiseid peavad olema kaitstud, kasutades "HttpOnly" meetodit. (V3.14)
13. Sessiooni autentimiseks kasutatavate võtmete küpsised peavad olema kaitstud "secure" atribuudiga ning transpordi range turvalisuse päisega (näiteks Strict- Transport-Security: max-age = 60000; includeSubDomains). (V3.15)
14. Rakendus ei tohi võimalda samaaegseid dubleerivaid seansse erinevatest allikatest. (V3.16)
Ligipääsukontroll
1. Kasutajale võib olla juurdepääs ainult neile turvatud funktsioonidele või teenustele, mille jaoks nad.omavad luba. (V.4.1)
2. Kasutajad saavad juurdepääsu ainult neile turvatud URL-idele, mille jaoks neil on luba. (V4.2)
3. Kasutajad tohivad saada juurdepääsu ainult neile turvatud failidele, mille jaoks nad omavad luba. (V4.3)
4. Vahetud viited objektidele peavad olema kaitstud. Ainult teatud objektid või andmed on kättesaadavad igale kasutajale. (V4.4)
5. Kataloogi sirvimine peab olema keelatud, välja arvatud juhul, kui see on teadlikult soovitud. (V4.5)
6. Ebaõnnestunud juurdepääsukatse peab lõppema turvaliselt. (V4.8)
7. Esitluskihis kehtestatud juurdepääsureeglid peavad olema kehtestatud serveri poolel. Nii et kõrgema privileegiga väline kasutaja ei saa endale teise kasutaja parameetreid lisada või üle võtta. (V4.9)
8. Lõppkasutaja ei tohi ilma konkreetse volituseta muuta ligipääsu kontrolliks vajalike kasutaja ja andmete atribuute ning turvapoliitika seadistusi. (V4.10)
9. Kogu juurdepääsu kontrolli tagamine on serveri poolel. (V4.11)
10. Kõik juurdepääsu kontrolli otsused ja kõik ebaõnnestunud juurdepääsu otsused peavad olema logitud. (V4.14)
11. Rakenduse või raamistiku koostatud anti-CSRF (Cross-Site Request Forgery) võti peab olema maksimaalselt juhuslikest märkidest koosnev ja igale kasutajale unikaalne. Aplikatsioon peab kontrollima kõrge turvalisuse nõudega tehingute või tundlike andmetele juurdepääsu puhul, et kasutaja oleks tuvastatud. (V4.16)
12. Andmete kogumise kaitse - kontrollsüsteemi peab kaitsma tundlikke andmeid nende kokku kogumise või pideva sagedase päringu vastu. Näiteks võib piirata muudatuste arvu tunnis, et vältida kogu andmebaasi kokku kogumist ühe kasutaja poolt. (V4.17)
Sisendi käitlemine
1. Rakenduse keskkond ei tohi võimalda või peab turvakontroll vältima puhvri ületäitumist. (V5.1)
2. Kõik sisendi kontrollimisel leitud vead peavad põhjustama sisendi tagasilükkamise. (V5.3)
3. Valitud kooditabel, näiteks UTF-8, peab olema kehtestatud kõikides sisendi allikates. (V5.4)
4. Kõik sisendi kontrollid või kodeeringud teostatakse ja täidetakse serveri poolel. (V5.5)
5. Kõik sisendandmed peavad olema kanoonilised allavoolu dekoodrite jaoks või interpreteeritud enne kontrollimist. (V5.8)
6. Rakenduse keskkond ei tohi lubada või peab turvakontroll vältima SQL päringu nakatamist. (V5.10)
7. Rakenduse keskkond ei tohi lubada või peab turvakontroll vältima LDAPi nakatamist. (V5.11)
8. Rakenduse keskkond ei tohi lubada või peab turvakontroll vältima OS käskude nakatamist. (V5.12)
9. Rakenduse keskkond ei tohi lubada või peab turvakontroll vältima välisest keskkonnast tulevate XML päringute nakatamist. (V5.13)
10. Rakenduse keskkond ei tohi lubada või peab turvakontrolli vältima XML päringute nakatamist. (V5.14)
11. Ebausaldusväärsed HTML sisendandmed (sh. HTML elemendid, HTML atribuudid, JavaScript väärtused, CSS ja URL atribuudid) peavad olema rakenduse sisendist korrektselt eemaldatud . (V5.16)
12. Kui raamistik võimaldab automaatset parameeterite massilist omistamist (nimetatakse ka automaatne muutujate seostamine- „automatic variable binding“), tuleb kontrollida, et tundlikes valdkondades nagu "kontojääk", "roll" või "parool" on kaitstud pahatahtliku automaatse vale seostamise eest. (V5.17)
13. Rakenduses peavad olema kaitsemehhanismid HTTP parameeter muutmise rünnakute vastu, eriti juhul, kui taotluse raames ei tehta vahet taotluse parameetrite allika kohta (GET, POST, küpsised, päised, keskkond jne.). (V5.18)
Krüptohaldus
1. Kõik turvalisuse tagamiseks vajalikud krüptograafiilised funktsioonid tuleb teostada serveri poolel. (V7.1)
2. Kõik krüptograafilised moodulid peavad vea korral lõpetama töö turvaliselt. (V7.2)
3. Juhtvõti (juhtvõti on kettale salvestatud avatud tekstiga võti, mis kaitseb ülejäänud süsteemi turvalise konfiguratsiooni andmeid), peab olema kaitstud volitamata juurdepääsu eest. (V7.3)
4. Kõik juhuslikud arvud, juhuslikud failinimed, juhuslikud GUID, ja juhuslikud stringid peavad olema ründajale raskelt ära arvatavad ja peavad olema loodud krüptograafilise mooduli poolt aktsepteeritud juhusliku numbri generaatori poolt. (V7.6)
5. Krüptograafiliste võtmete haldamiseks (nt. loomine, levitamine, tühistamine, aegumine) peab olema kehtestatud selge poliitika. Poliitika peab olema nõuetekohaselt jõustatud. (V7.9)
Vigade käitlemine ja logimine
1. Rakendus ei tohi väljastada veateateid või viiteid, mis sisaldaksid ründajat aitavaid tundlikke andmeid. Sealhulgas sessiooni ID ja isiklikke andmeid. (V8.1)
2. Kogu vigade haldus peab toimuma läbi usaldusväärsete seadmete. (V8.2)
3. Kogu sisselogimise kontroll teostatakse serveris. (V8.3)
4. Turvakontrolli vigade käsitlemise loogika ei tohi lubada vaikimisi ligipääsu. (V8.4)
5. Turvalist sisselogimist tagavad mehhanismid peavad olema võimelised logima nii edukaid, kui ka ebaedukaid sisselogimiskatseid. (V8.5)
6. Kõik logisündmused peavad sisaldama usaldusväärset ajatemplit; sündmuse olulisuse informatsiooni; sündmuse tekitanud kasutaja identiteeti (kui on olemas sündmusega seotud kasutaja); sündmusega seotud allika IP aadressi; kas sündmus õnnestus või ebaõnnestus ja sündmuse kirjeldust. (V8.6)
7. Logi peab olema kaitstud loata juurdepääsu ja muutmise eest. (V8.8)
8. Aplikatsioon ei tohi lisada logisse tundlikke andmeid, mis võiks ründajat aidata. Sealhulgas kasutaja seansi identifikaatoreid ja isiklikku või tundlikku teavet. Viiteid tundliku informatsiooni olemasolule ja mahtule võib logida. (V8.10)
9. Logide analüüsiks peab olema tööriist, mis võimaldab analüütikul otsida sarnaste sündmuste kombinatsioone süsteemi poolt logitavate kirjete ja väljade seast. (V8.11)
Andmekaitse
1. Kliendi pool ei tohi vahemällu salvestada tundlikku informatsiooni, sealhulgas automaatse täitmise funktsioonidesse. (V9.1)
2. Tundlikke andmeid võib saata serverisse HTTP sõnumi kehas (st. URL parameetreid ei kasutata kunagi tundlikke andmete saatmiseks). (V9.3)
3. Kõik kliendile saadetud tundlikke andmete sisaldavad puhverdatud või ajutised koopiad peavad olema kaitstud autoriseerimata ligipääsu eest või muudetakse peale seanssi kehtetuteks (näiteks sobib no-cache ja no-store sisse lülitamine Cache-Control päises). (V9.4)
4. Kõik serverisse salvestatud tundlikke andmete puhverdatud või ajutised koopiad peavad olema kaitstud loata juurdepääsu eest või muudetakse kehtetuks pärast kasutaja pöördumise lõppemist. (V9.5)
Kommunikatsioon
1. Andmevahetuseks tohib kasutada ainult usaldusväärseid ja autoriseeritud sertifikaate omavaid Transport Layer Security (TLS) servereid ja iga serveri sertifikaat peab kehtima. (V10.1)
2. TLS-i tuleb kasutada kõikide autenditud, tundlikke andmeid või -funktsioone vahendavate ühenduste (sealhulgas nii välis- kui seesmiste ühendused) jaoks. (V10.3)
3. Sisemise TLS ühenduse rikked peavad olema logitud. (V10.4)
4. Kõik väliste süsteemide ühendused, mis edastavad tundlikku informatsiooni või ülesandeid, peavad olema autenditud. (V10.6)
5. Kõik tundlikku informatsiooni või ülesandeid edastavad väliste süsteemide ühenduste jaoks loodud serverite kasutajakontod peavad olema minimaalsete privileegidega. Privileegid võimaldavad teostada ainult vajalikke toimingud. (V10.7)
HTTP
1. Taotluse tohib vastu võtta ainult kokkulepitud HTTP meetoditega, näiteks GET ja POST. Kasutamata meetodeid peavad olema blokeeritud. (V11.2)
2. Iga HTTP vastus peab sisaldama päist, kus määratakse sisu tüübi jaoks kasutatav ohutu kooditabeli (nt. UTF-8). (V11.3)
3. Kõik HTTP päringud ja vastused tohivad sisaldada ainult trükitavaid ASCII tähemärke. (V11.6)
4. HTTP päised ja/või teised mehhanismid peavad vanemate brauserite jaoks lisama kaitse clickjacking rünnakute vastu. (V11.8)
5. Lõppkasutaja ei tohi saada muuta rakenduse sisendiks kasutatavat, teise rakenduse (näiteks X-Real-IP) väljundi poolt lisatud pealdist (spoofing). (V11.9 )
6. Neis kohtades, kus sisu ei tohiks olla nähtav kolmanda osapoole X-Frame’ile, tuleb see piirata HTTP päises, X-Frame-options abil. Üldine võimalus on saata SAMEORIGIN, mis tähendab, et ainult sama päritoluga veebilehed võivad seda sisu kasutada. (V11.10)
7. HTTP päis ei tohi edastada süsteemi komponentide detailset informatsiooni. (V11.12)
Äriloogika
1. Aplikatsiooni protsessid või olulised äriloogika etapid peavad toimuma usalduslikus keskkonnas, näiteks kaitstud ja jälgitavas serveris. (V15.1)
2. Aplikatsioon peab vältima oluliste tehingute võltsimist. Näiteks mitte lasta ründajal muuta või taaskasutada teise kasutaja sessiooni, tehingut või tehingu/kasutaja ID-d. (V15.2)
3. Aplikatsioon ei tohi lubada moonutada olulisi äriloogika parameetrid, nagu (kuid mitte ainult): hind, intress, soodustus, isikuandmed (PII- Personally Identifiable Information), saldo, kauba koodid jms. (V15.3)
4. Rakendusel peab olema kaitse katkestatud rünnakute vastu, nagu näiteks kontrollitav ja kaitstud tehingute register, kontrolljäljendid või süsteemi logid ja oluliste süsteemide järelevalve reaalajas kasutaja tegevuse ja tehingute anomaaliate kohta. (V15.4)
5. Aplikatsioon peab kaitsma teavet avalikustamise eest, näiteks vältima otsest viidet objektidele, sessiooni rikkumist või jõuga lahti murdmist või muid rünnakuid. (V15.5)
6. Aplikatsioonil peab olema enda kaitsmiseks võime avastada ja kontrollida jõuvõtteid, (näiteks ründala poolt pidevalt ühe funktsiooni kasutamine) või DOS rünnakud. (V15.6)
7. Aplikatsioonil juurdepääsud peavad olema piisavalt kontrollitud, et vältida spetsiifilisemaid rünnakud. Näiteks kasutades anonüümset kasutajat või kaaperdatud kasutajakontot privilegeeritud funktsioonide käivitamiseks, saades sedasi juurdepääs turvatud andmetele või funktsioonidele. (V15.7)
8. Aplikatsioon peab töötlema kõiki äriloogika protsesse kindlas järjestuses ja realistliku ajaga. Vales järjestuses, vahele jäetud, teise kasutaja poolt algatatud või erakordselt kiirelt algatatud protsesse ei tohi töödelda. (V15.8)
9. Aplikatsioon peab omama täiendavat kontrolli madalama tasemega süsteemidele (näiteks võib kasutada kontrolli kõrgemal tasemel või adaptiivset autentimist ja/või oluliste operatsioonide eraldamist). See parandab pettuse tuvastamise võimalust. (V15.9)
10. Aplikatsioon peab omama ärilisi piiranguid. Piiranguid hoitakse turvalises keskkonnas (turvalises serveris). Piirangute ületamises hoiatatakse kasutajat või takistatakse toimingu tegemist. Näiteks ei tohiks tervishoiusüsteemi lubada ühe arsti juurde rohkem patsiente kui neid on võimalik mõistlikult päevas ravida või väikeettevõte rahandussüsteem ei tohi lubada rohkem kui 20 arve maksmist päevas. (V15.10)
Failid ja ressursid
1. URL ümber- ja edasisuunamised ei tohi sisaldada kontrollimata andmeid. (V16.1)
2. Ebausaldusväärsest allikast saadud failinimed ja faili puu kirjeldus peab olema kanoonilisel kujul, et vältida failisüsteemi ründeid. (V16.2)
3. Ebausaldusväärsest allikast saadud faili tuleb skaneerida viirusetõrje skanneriga, et ennetada pahatahtlikku sisu üleslaadimist. (V16.3)
4. Ebausaldusväärsest allikast tulnud parameetreid ei tohi kasutada failinimede, kataloogi teede või failisüsteemi objektidega manipuleerimiseks. Päringus peavad olema kanoonilisel kujul ja kontrollitud, et vältida kohalikku failisüsteemi pahatahtliku faili lisamist. (V16.4)
5. Parameetrid peavad olema kanoonilisel kujul, sisend kinnitatud, ja väljund kodeeritud, et vältida välise faili lisamisega teostatavaid rünnakud. Eriti juhul, kui fail on täidetav fail, näiteks päist, allikat või malli sisaldava faili lisamine parameetrisse. (V16.5)
6. Domeenide vahel jagatavad Iframe ja HTML5 ei tohi lubada sisestada kokkuleppimata sisu. (V16.6)
7. Ebausaldusväärsest allikast tulnud faili ei tohi salvestada veebi juurkataloogi. (V16.7)
8. Veebi- või rakenduse server peab olema vaikimisi konfigureeritud nii, et väljaspool veebi või rakenduse serverit on serveri ressurssidele või süsteemile juurdepääs keelatud. (V16.8)
9. Ebausaldusväärsest allikast üleslaetud koodi ei tohi täita. (V16.9)
10. Flash, Silverlight või teiste interneti aplikatsioonide (Rich Internet Application- RIA) domeenide vaheline ressursside jagamise peab olema konfigureeritud nii, et oleks välditud autentimata või volitamata kaugjuurdepääs. (V16.10)
Mobiilseadmed
1. Klient peab kinnitama SSL sertifikaadid. (V17.1)
2. Unikaalse seadme ID (UDID) väärtused ei tohi kasutata turvakontrolli. (V17.2)
3. Mobiilirakendus ei tohi talletada tundlikke andmeid jagatud ressurssidega seadmesse (nt. SD-kaardile või jagatud kaustadesse). (V17.3)
4. Tundlikke andmeid ei tohi salvestatda kasutaja seadme SQLite andmebaasi. (V17.4)
5. Salajased võtmed või paroole ei tohi olla koodi sisse kirjutatud. (V17.5)
6. Mobiilirakendus peab vältima tundlike andmete lekkimist iOS autosnapshot kaudu. (V17.6)
7. Rakendus ei tohi töötada muudetud (jailbroken or rooted) seadmes. (V17.7)
8. Sessiooni lõpu ajapiirang (timeout) peab omama mõistlikku väärtust. (V17.8)
9. Juurdepääsuks vajalikud õigused ja seadmed tuleb üle kontrollida (st. AndroidManifest.xml, iOS Entitlements). (V17.9)
10. Veateadete logi ei tohi sisaldada tundlikke andmeid. (V17.10)
11. Kõik katseandmed peavad olema enne rakenduse käiku andmist eemaldatud rakenduse konteinerist (.ipa, APK, .bar). (V17.12)
12. Süsteem ei tohi lisada tundlikke andmeid süsteemi või failisüsteemi logisse. (V17.13)
13. Rakendus ei tohi võimaldada automaatset täitmist tundlikule tekstisisestus väljadesse, näiteks parool, isikuandmeid või krediitkaardid. (V17.14)
Veebiteenus
1. Klient ja server peavad kasutama sama kodeeringut. (V18,1)
2. Veebiteenuse haldamise ja juhtimise funktsioone võib teostada ainult veebiteenuse administraator. (v18.2)
3. XML või JSON skeem peab olema olemas ja kontrollitud enne, kui lubatakse andmeid sisestada. (v18.3)
4. Kõigil sisenditel peab olema kehtestatud suuruse piirang. (v18.4)
5. SOAP põhine veebiteenused peab olema vähemalt Web Services-Interoperability (WS-I) Basic Profile’ga vastavuses. (v18.5)
6. Autentimine ja autoriseerimine peavad olema sessiooni põhised. Vältida tuleb staatilisi "API võtmeid". ( v18.6)
7. REST teenus peab olema kaitstud CSRF (Cross-Site Request Forgery) taotluse võltsimise eest. (v18.7)
8. REST teenust peab alati kontrollima sissetuleva info sisu tüüpi (Content-Type) mis peab vastama eeldatavale tüübile. Nagu näiteks application/xml või application/Json. (v18.8)
9. Sõnumite maht peab olema kokku lepitud, et tagada kliendi ja teenuse vaheline usaldusväärne transport. (V18.9)
10. Alternatiivseid ja vähem turvalisi juurdepääsu teed ei tohi olla lubatud. (V18.10)
Konfiguratsioon
1. Kõik komponendid peavad olema viimase turvakonfiguratsiooniga ja versiooniga. See hõlmab ka mittevajalike konfiguratsioonide ja kataloogide, proovirakenduste, platvormi dokumentatsiooni ja vaikimisi- või näidiskasutajate eemaldamist. (v19.1)
2. Komponentide vaheline suhtlus, näiteks rakendusserveri ja andmebaasi serveri vaheline suhtlus, peab olema krüpteeritud. Eriti kui osad on kas eri konteinerites või erinevates süsteemides. (v19.2)
3. Komponentide vahelise ühenduse, näiteks rakendusserveri ja andmebaasi serveri vaheline ühenduse, jaoks tuleb kasutada minimaalsete, ainult vajalike õigustega kasutajat. (v19.3)
4. Rakendus peab olema paigaldatud liivakasti, konteineritesse või muul viisil isoleeritud, et takistada ründajal rünnata rakenduse kaudu teisi rakendusi. (v19.4)
5. Aplikatsioonide arendus ja juurutamine peavad toimuma turvalises keskkonnas. (v19.5)