Embed Size (px)
DESCRIPTION
First Tuesday Bergen 7 juni 2011
Citation preview
Smidig sikkerhetSikkerhet som en naturlig del av utviklingsprosessen
First Tuesday Bergen7. juni 2011
den agile
Lars Hopland Nestås
• MSc fra UiB, Institutt for informatikk: «Building Trust in Remote Internet Voting»
• Konsulent i Bouvet ASA siden august 2010• Risiko- og sårbarhetsanalyser• Sikkerhetstesting av webapplikasjoner• Kildekodegjennomgang• Utvikler (Java og PHP)• Sikkerhetskurs i regi av Bouvet
2
Oversikt
• Forvaltningsteam i Bouvet–Fordeler–Utfordringer
• Sikkerhet som en naturlig del av utviklingsprosessen–Microsoft SDL–Hva og hvordan gjør vi det i forvaltningsteamet?
3
Mediabildet
4
Forvaltningsteamet i Bouvet
• 6 konsulenter +/-• Java, PHP, iPhone og Android• Benytter Scrum som prosjektmetodikk• Utvikling av nye løsninger• Forvaltning av eksisterende løsningerNoen kunder siste 6 mnd.
5
Utfordringer• Ofte bytte av uviklingsmiljø• Sikkerhet som en naturlig del av
utviklingsprosessen –Mange små uviklingsoppgaver• En «typisk» oppgave er estimert til 4-8 timer
Fordeler• Godt miljø for deling av kompetanse• Flere konsulenter har kompetanse og kunnskap til
å utføre arbeid på alle prosjektene (god overlapp)• Kunden betaler kun for utført arbeid
6
Sikkerhet som en naturlig del av utviklingsprosessen
7
MS Security Development Lifecycle
«So now, when we face a choice between adding features and resolving security issues, we need to choose security.»
8 http://www.microsoft.com/security/sdl/
Aktiviteter i SDL*
9
Opplæring
Sikkerhetstrening
Design
Analysere angrepsflate og utarbeide trusselmodell
Oppfølging
Sikker forvaltning
Verifikasjon
Verifisering av trusselmodell og angrepsflate
Manuell og automatisert testing
Kravspek.
Analysere sikkerhets- og personvernsrisiko
Etablere målbilde for sikkerhetsnivå
Implementasjon
Håndheve implementasjons-regler
Spesifisere verktøy
Statisk kodeanalyse
Produksjon
Sikkerhetsgjennomgang
Utarbeide beredskapsplan
Arkivering av sikkerhetsrelatert prossessdokumentasjon
*Fritt etter MS Security Development Lifecycle
Sikker programutvikling*
10
Opplæring
Design
Oppfølging
Verifikasjon
Kravspek.
Implementasjon
Produksjon
*Etter mal fra MS Security Development Lifecycle
Agile Security Development Lifecycle
Ak:viteter i hver sprint Engangsak:viteter Regelmessige ak:viteter
Sikkerhetstrening
Analysere angrepsflate og utarbeide trusslemodell
Manuell og automatisert testing
Verifisering av trusselmodell og angrepsflate
Etablere målbilde for sikkerhetsnivå
Analysere sikkerhets- og personvernsrisiko
Spesifisere verktøy
Håndheve implementasjons-regler
Statisk kodeanalyseUtarbeide
beredskapsplan
SikkerhetsgjennomgangArkivering av sikkerhetsrelatert prossessdokumentasjon
Agile Security Development Lifecycle
Ak:viteter i hver sprint Engangsak:viteter Regelmessige ak:viteter
Etablere målbilde for sikkerhetsnivå
Spesifisere verktøy
Utarbeide beredskapsplan Sikkerhetstrening
Manuell og automatisert testing
Verifisering av trusselmodell og angrepsflate
Sikkerhetsgjennomgang
Analysere angrepsflate og utarbeide trusselmodell
Analysere sikkerhets- og personvernsrisiko
Håndheve implementasjonsregler
Statisk kodeanalyse
Arkivering av sikkerhetsrelatert prossessdokumentasjon
«SDL» i forvaltningsteamet
13
Opplæring
• Kurs i applikasjonssikkerhet–Kjennskap til mest vanlige angrepsteknikkene–Lære å beskytte seg mot de vanligste angrepene–Lære å identifisere sårbarheter/typiske problemområder i
applikasjoner og kildekode–Kjennskap til noen verktøy for testing–Strategi for sikker programutvikling
14
Opplæring
• Legge inn ondsinnet kode i kommentarfelter i forumet
• Hint 1: Utvikleren prøver å vaske inndata ved å fjerne <script>-tagger for å hindre at brukere kan legge inn javascript
Oppgave 8 -‐ Lagret XSS
• Hent filen etc/passwd ved hjelp av SQL-injection
Oppgave 12b -‐ SQL injec:on
15
Kravspesifikasjon og design
• Utføres som workshop sammen med kunden for å kartlegge:–Informasjonsverdier–Angrepsflate–Aktører
• Angrepsscenario (Misuse cases)–Alle deltakerene rangerer
scenarioene etter kritikalitet (lav til kritisk) hver for seg
• Inngår som en viktig del av trusselmodellen
Design
Analysere angrepsflate
Kravspek.
Analysere sikkerhets- og personvernsrisiko
Etablere målbilde for sikkerhetsnivå
16
17
1 Ta over andre brukersesjoner
2 Endre passord på andre brukeres konto
3 Oppgradere egen konto til admin
4 Levere oppgave for annen elev
5 Lesetilgang til andre elevers innleveringer
6 Gi andre elever utvidede rettigheter
7 Endre åpne- og lukketid for innleveringsmapper
8 Gi andre eller seg selv ekstratid på oppgaveinnleveringer
9 Lese kommentarer på andre elevers oppgaver
10 Legge til kommentarer på egne og andre elevers oppgaver
11 Opprette nye kontoer
12 Endre oppgavesammendrag på andre elevers innleveringer
13 Lese oppgavesammendrag på andre elevers innleveringer
14 Hindre at andre elever får levert oppgave (DoS-angrep)
15 Motta e-postvarsel når andre elever leverer oppgaver
16 Slette egne innleveringer
17 Se hvem som ikke har levert oppgave
Kri:sk
Stor
Midde
lsLav
Eksempel på angrepsscenario for aktøren «elev»
Angrepsscenario
• Inngår som grunnlag i:–Utarbeidelse av kravspesifikasjon–Implementasjonsfasen for å identifisere typiske
«problemområder»–Verifikasjonsfasen–Utarbeidelse av beredskapsplan og i
sikkerhetsgjennomgang før produksjon–Forvaltningsfasen ved utvikling av ny funksjonalitet
18
Implementasjon og verifikasjon
• For hver ny utviklingsoppgave utarbeider utvikleren en testplan før implementeringen begynner • Testplanen inneholder:–Kort beskrivelse av ny funksjonalitet–Kort beskrivelse av hvordan dette implementeres/løses–Krav til kodekvalitet–Krav til sikkerhet
• En annen konsulent gjennomfører testplanen innenfor estimatet for oppgaven
19
Eksempel på testplan:• Som administrator vil jeg kunne slå av og på
logging for de ulike web servicene
TestkriterierFunksjonalitet/Løsningsbeskrivelse:Administrator for XXX skal ha mulighet til å aktivere og deaktivere logging av feil for de ulike WS (xxx.php og zzz.php). Administrering av dette skjer i http://localhost:8888/xxx/yyy/zzz/index.php.
Når logging aktiveres/deaktiveres via admin-grensesnittet lagres i filen debug_config.php som ligger i mappen X. Skriving til debug_config.php skjer via zzz/debug_admin.php som kalles via admin-grensesnittet
Kodekvalitet:
• Skal være formattert iht. etablert standard• Koden skal være enkel å lese og ha gode kommentarerSikkerhet:
• Skriving til filer som skal inkluderes i applikasjonen kan være skummelt. Alle verdier som lagres i filen skal være hardkodet (dvs. ingen inndata fra brukeren skal skrives til fil).
20
Oppsummering
• Opplæring• Workshop for å utarbeide angrepsscenario• Testplaner for alle utviklingsoppgaver–Manuell testing av applikasjonen med fokus på sikkerhet–Koderevisjon–Kompetanseheving
• Automatiserte tester ved hjelp av verktøy• Statisk kildekodeanalyse (i nær fremtid)
21
Spørsmål?
22
