Testaus 2014 -seminaari. Pauli Kauppila, Secrays Oy. Mitä jokaisen testaajan tulee tietää tietoturvasta ja tietoturvatestauksesta?
•Download as PPTX, PDF•
1 like•614 views
Tietoturvatestaus kuuluu kaikille testaajille, eikä siihen tulisi suhtautua erillisenä saarekkeena.
Recommended
Recommended
More Related Content
Similar to Testaus 2014 -seminaari. Pauli Kauppila, Secrays Oy. Mitä jokaisen testaajan tulee tietää tietoturvasta ja tietoturvatestauksesta?
Similar to Testaus 2014 -seminaari. Pauli Kauppila, Secrays Oy. Mitä jokaisen testaajan tulee tietää tietoturvasta ja tietoturvatestauksesta? (20)
More from Tieturi Oy
More from Tieturi Oy (20)
Testaus 2014 -seminaari. Pauli Kauppila, Secrays Oy. Mitä jokaisen testaajan tulee tietää tietoturvasta ja tietoturvatestauksesta?
- 1. Mitä jokaisen testaajan tulisi tietää tietoturvasta ja tietoturvatestauksesta Pauli Kauppila, Secrays Oy
- 2. Sisältö • Tietoturvan peruskomponentit • Uhka-analyysit • OWASP • Testaus ja tietoturvatestaus 11.4.2013
- 3. Tietoturva järjestelmissä • Tietoturva on laatuominaisuus • Laadukas ohjelmisto on tietoturvallisempi kuin huonolaatuinen • Toiminnalliset ja ei-toiminnalliset vaatimukset • Tietoturvan testaaminen on hankalampaa kuin tiettyjen toiminnallisuuksien testaaminen • Tietoturva ulottuu järjestelmän kaikkiin osiin • Osa tietoturvavaatimuksista voi olla liiketoiminnallisia ja selkeästi määriteltävissä • Esimerkiksi session pituus • Osa taas on johdettavissa järjestelmän luonteesta mutta liiketoiminnallinen määrittely vaikeampaa 11.4.2013
- 4. Testaamisen ongelmat 11.4.2013 Suunniteltu järjestelmä ja toiminnallisuus Testaus määriteltyä toiminnallisuutta vasten Toteutettu järjestelmä Testaus?
- 5. Sovellusten tietoturvariskit 11.4.2013 Lähde: OWASP https://www.owasp.org/index.php/Top_10_2013-Risk
- 7. Tietoturvan peruskomponentit • Tietoturvaominaisuuksia voidaan tarkastella loogisen jaottelun avulla • Luottamuksellisuus (Confidentiality) • Eheys (Integrity) • Saatavuus (Availability) • Kiistämättömyys (Nonrepudiation) • Autentikointi (Authentication) • Autorisointi (Authorization) 11.4.2013 Confidentiality Integrity Availability Nonrepudiation Authentication Authorization
- 8. Luottamuksellisuus • Useimmiten IT-tietoturvaa ajateltaessa mieleen tulee ensimmäisenä salaus • Salauksen avulla toteutetaan luottamuksellisuutta • Lisäksi tarvitaan todentamisen ja valtuuttamisen mekanismit • Salaus voi olla symmetristä tai epäsymmetristä • Salauksen toteuttaminen järjestelmiin on vaativaa • Laskentaintensiteetti • Salausavainten hallinta • Varmenteiden hallinta • Mietittävä tarkkaan mikä on riski ja haluttu luottamuksellisuuden taso 11.4.2013 Integrity Availability Nonrepudiation Authentication Authorization Confidentiality
- 9. Eheys • Eheydellä tarkoitetaan että sanoman vastaanottaja voi luottaa sanoman säilyneen muuttumattomana lähettäjältä • On hyvä huomata, että salaus pelkästään ei takaa eheyttä • Eheyden mekanismeja ovat allekirjoitukset • Allekirjoituksen ja salauksen avulla toteutetaan eheys ja luottamuksellisuus • Allekirjoitukset johtavat kiistämättömyyteen 11.4.2013 Confidentiality Availability Nonrepudiation Authentication Authorization Integrity
- 10. Saatavuus • Järjestelmän toimintavarmuuden turvaaminen • Ohjelmistot • Laitteet • Toipuminen poikkeustilanteissa • Myös häiriönsietokyky vaikuttaa saatavuuteen • “Robustisuus” • Huomioitava järjestelmän/ohjelmiston kehittämisessä ja tuotantoympäristön konfiguroinnissa • Riskiarviointi tahallisille ja tahattomille häiriöille 11.4.2013 Confidentiality Integrity Availability Nonrepudiation Authentication Authorization
- 11. Kiistämättömyys ja allekirjoitukset • Kiistämättömyys tarkoittaa, että sanoman lähettäjä on yksikäsitteisesti todennettavissa • Lähettäjä ei voi kiistää lähettäneensä sanomaa • Tyypillisesti salauksen ja allekirjoitusten yhteydessä käytetään varmenteita 11.4.2013 Confidentiality Integrity Availability Nonrepudiation Authentication Authorization
- 12. 12 Sanoma Sanomaotsake Liiketoiminnallinen sanoma Sanoma Lähettäjä Vastaanottaja 1 2 3 4 1) Lähettäjä liittää oman varmenteensa sanomaotsakkeeseen 2) Lähettäjä laskee sanomasta ns. Tiivisteen ja salaa sanoman yksityisellä avaimellaan 3) Vastaanottaja todentaa kutsujan sanomatsakkeessa tulevan varmenteen perusteella 4) Vastaanottaja purkaa sanomasalauksen varmenteesta saatavalla lähettäjän julkisen avaimella ja laskee tiivisteen uudelleen ja tarkistaa sanomatiivisteen vastaavuuden Salattu tietoliikenneyhteys Varmenne 2 Allekirjoitus Liiketoiminnallinen sanoma Sanomaotsake Varmenne X.509 varmenne ja allekirjoitus Yksityinen avain Allekirjoitus Julkinen avain
- 13. Autentikointi • Autentikointi eli todentaminen • Autentikoinnilla varmennetaan käyttäjän identiteetti • Tyypillinen todennusmekanismi on käyttäjätunnus ja salasana • Vahva tunnistus tarkoittaa, että käyttäjän identiteetti varmennetaan vähintään kahdella seuraavasta kolmesta • Jotain minkä käyttäjä tietää (salasana) • Jotain mikä käyttäjällä on (laite) • Jotain käyttäjän ominaisuuksiin liittyen (sormenjälki) • Tyypillinen tapa toteuttaa vahva autentikointi • Käyttäjätunnus ja salasana sekä lisäksi erillinen autentikointikanava: puhelinviesti, autentikointitoken tai –ohjelmisto (esim. puhelimessa). 11.4.2013 Confidentiality Integrity Availability Nonrepudiation Authorization Authentication
- 14. Auktorisointi (valtuutus) • Käyttäjän profilointi todennetun identiteetin perusteella • Valtuutusprosessin avulla käyttäjälle tarjotaan (vain) hänelle kuuluvat palvelut • Roolipohjaiset käyttövaltuudet • Ryhmään liittyvät oikeudet • Rooli+käyttäjä+tietosisältö yhdessä määrittävät käyttäjän oikeudet 11.4.2013 Confidentiality Integrity Availability Nonrepudiation Authentication Authorization
- 16. STRIDE uhkien tunnistaminen Uhka Määrittely Esimerkki Spoofing ”Väärentäminen” Toisena esiintyminen Esimerkiksi sanomakutsuun liittyvän identiteetin väärentäminen ( tai väärentyminen) Tampering ”Peukalointi” Tiedon muuttaminen Tiedoston, sanoman tai tietokannan sisällön muokkaus Repudiation ”Kiistäminen” Kiistetään jonkun toimenpiteen suorittaminen “En käynyt sillä sivulla…” “En lähettänyt sitä viestiä” Information Disclosure Tiedon paljastuminen Tieto näkyy jollekin jolla ei ole oikeutta nähdä sitä Esimerkiksi tyypillisesti web- sovelluksessa: voidaanko kuunnella liikennettä edustan ja kannan välillä? Sanomien tai aineistojen välivarastointi ja oikeudet? Denial of Service Palvelunesto Joko tahallinen tai tahaton palvelunestyminen asiakkaalta Julkisen palvelun rajoittamaton käyttö Huono tai olematon varautuminen kuormituspiikkeihin Syötteiden validoinnin puutteet Elevation of Privilege, oikeuksien nostaminen Ei auktorisoida Admin-käyttö, toisen asiakkaan tietojen luku 11.4.2013
- 17. DREAD uhkien luokittelu 11.4.2013 Uhka Määrittely Esimerkki Damage Potential If a threat exploit occurs, how much damage will be caused? 0 = Nothing 5 = Individual user data is compromised or affected. 10 = Complete system or data destruction Reproducibility How easy is it to reproduce the threat exploit? 0 = Very hard or impossible, even for administrators of the application. 5 = One or two steps required, may need to be an authorized user. 10 = Just a web browser and the address bar is sufficient, without authentication. Exploitability What is needed to exploit this threat? 0 = Advanced programming and networking knowledge, with custom or advanced attack tools. 5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools. 10 = Just a web browser Affected Users How many users will be affected? 0 = None 5 = Some users, but not all 10 = All users Discoverability How easy is it to discover this threat? 0 = Very hard to impossible; requires source code or administrative access. 5 = Can figure it out by guessing or by monitoring network traces. 9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine. 10 = The information is visible in the web browser address bar or in a form.
- 18. OWASP 11.4.2013
- 19. OWASP • Open Web Application Security Project • Vapaaehtoinen yhteisö ja keskustelufoorumi, jonka tavoitteena on kasvattaa tietoisuutta turvallisen ohjelmistokehityksen menetelmistä • Lähtökohtana ”open source” ajattelu • OWASP myös pyrkii kehittämään open source –ratkaisuja tietoturvahaasteisiin • OWASP Helsinki järjestää kaikille avoimia tilaisuuksia 3-4 kertaa vuodessa • OWASP Top 10 on lista yleisimmistä haavoittuvuuksista • Uusitaan muutaman vuoden välein • OWASP on julkaissut myös useita oppaita • OWASP Developer’s guide, Testing guide 11.4.2013
- 21. OWASP Top 10: A1 Injection • Tyypillisesti johtuu siitä, että ohjelmistossa luotetaan sanomaan ja sen parametreihin • Klassinen tapaus on syötteen tarkistus käyttöliittymällä (selain) mutta ei palvelimella • Web-sovelluksessa syötteen tarkistus käyttöliittymällä parantaa käyttökokemusta mutta ei tietoturvaa • Syötetarkistukset on aina tehtävä myös palvelinosuudessa • Muoto, pituus, sallitut merkit • Suurissa järjestelmissä palvelut saattavat olla koosteisia, ja niiden kutsureitit monikanavaisia • Kutsuja selaimelta, mobiilisovellukselta, palvelimilta • Puolustuslinjana palvelinkutsujen ohjaaminen keskitetyn tietoturvallisen väylän kautta 11.4.2013
- 22. OWASP Top 10: A3 Cross-Site Scripting (XSS) • Käyttäjän antama syöte välitetään selaimelle sellaisenaan tarkastamatta ja käsittelemättä sitä ensin • Tämä mahdollistaa hyökkääjältä tulevien komentojen suorittamisen sovelluksen alaisuudessa • Komennoilla voidaan muuttaa selaimessa esimerkiksi sivuston ulkoasua tai kaapata sivuston istuntotunnisteet • Puolustuslinjat • HTML escaping • Merkistön käsittelytekniikka, jossa tulostemerkistöä käsitellään datana eikä tulkinnallisesti merkitsevinä merkkeinä/kombinaatioina • Oikein tehtynä escaping ei aiheuta vahinkoa, merkit kaiuttuvat selaimessa oikein: “<“ on “<” on “<“ • Lisäksi syötetarkistus kuten aiemmin mainittiin 11.4.2013
- 23. OWASP ASVS • ASVS Application Security Verification Standard • ASVS määrittelee tietoturvan kannalta oleelliset tekniset kontrollit, jotka tulee tarkastaa testausprosessissa • Kyseessä on erittäin laaja standardi, jota voi soveltaa eri vaiheissa • Sovellusten kehitys • Sopimukset toimittajien kanssa • Testaussuunnittelussa 11.4.2013 V1 - Security Architecture Documentation Requirements V2 - Authentication Verification Requirements V3 - Session Management Verification Requirements V4 - Access Control Verification Requirements V5 - Input Validation Verification Requirements V6 - Output Encoding/Escaping Verification Requirements V7 - Cryptography Verification Requirements V8 - Error Handling and Logging Verification Requirements V9 - Data Protection Verification Requirements V10 - Communication Security Verification Requirements V11 - HTTP Security Verification Requirements V12 - Security Configuration Verification Requirements V13 - Malicious Code Search Verification Requirements V14 - Internal Security Verification Requirements
- 25. Toiminnallinen testaus ja tietoturvatestaus • Toiminnallinen testaus pyrkii todentamaan ohjelmiston toiminnan määrittelyn mukaisesti • Kuten alussa todettiin laatuominaisuuksien kannalta se ei ole riittävää • Ohjelmisto voi toimia määritysten mukaisesti, mutta • ei ole suorituskykyinen • ei ole häiriösietoinen • avaa mahdollisuuksia väärinkäyttötapauksille, tahallisille tai tahattomille • Voidaanko (liike)toiminnallisessa testauksessa tehdä mitään tietoturvan parantamiseksi? • Ilman haavoittuvuusskannereiden opettelua ja käyttöä
- 26. Ehdotuksia • Väärinkäyttötapaukset • Riski- tai uhka-analyysin perusteella • Testitapaukset, joista osa toteutettavissa ”normaalin” testauksen puitteissa • Tietyn tyyppisten toiminnallisuuksien tunnistaminen • Sisäänkirjaus • Käyttövaltuudet • Uloskirjaus • Seuraavassa esimerkkejä ASVS:n pohjalta 11.4.2013
- 27. Autentikoinnin testaaminen • Verify that all pages and resources require authentication except those specifically intended to be public. • Kokeillaan että jokainen sivu vaatii autentikoinnin, esimerkiksi kirjoittamalla sivun osoite selaimeen • Verify that all authentication decisions are logged • Tarkistetaan että sisäänkirjautumisesta ja sen epäonnistumisesta kirjataan lokiin
- 28. Sessionhallinnan testaaminen • Verify that sessions are invalidated when the user logs out. • Kokeillaan että sessioon ei pääse esimerkiksi selaimen back- näppäimellä tai kirjoittamalla osoiteriville uudestaan sovelluksen osoite • Verify that sessions timeout after a specified period of inactivity. • Testataan määrittelyn mukaisesti • Verify that all pages that require authentication to access them have logout links. • Tarkistetaan jokaiselta sivulta • Verify that the session id is changed or cleared on logout. • Tarkistetaan selaimen session id:n muuttuminen
- 29. Auktorisoinnin testaaminen • Verify that users can only access services for which they possess specific authorization. • Tarkistetaan että jokaisella roolilla pääse vain sille tarkoitettuihin toimintoihin • Verify that users can only access secured URLs for which they possess specific authorization • Tarkistetaan että jokaisella roolilla pääse vain sille tarkoitettuihin osoitteisiin
- 30. Sisällön tarkistaminen • Verify that all input validation failures result in input rejection or input sanitization. • Esimerkiksi testataan postinumero-kenttään kirjaimia ja enemmän kuin viisi merkkiä • Tarkistetaan vakuutusnumeron muoto • 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. • Käytetään yksinkertaista scriptiä syöttökentissä tai URLissa
- 31. Virheen hallinta • Verify that that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id and personal information. • Tarkistetaan ettei virheviestit sisällä sensitiivistä informaatiota