Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Smidig sikkerhet Lars Hopland Nestås

908 views

Published on

First Tuesday Bergen 7 juni 2011

  • Be the first to comment

  • Be the first to like this

Smidig sikkerhet Lars Hopland Nestås

  1. 1. Smidig sikkerhetSikkerhet som en naturlig del av utviklingsprosessen den agileFirst Tuesday Bergen7. juni 2011
  2. 2. 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 Bouvet2
  3. 3. 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
  4. 4. Mediabildet4
  5. 5. Forvaltningsteamet i Bouvet • 6 konsulenter +/- • Java, PHP, iPhone og Android • Benytter Scrum som prosjektmetodikk • Utvikling av nye løsninger • Forvaltning av eksisterende løsninger Noen  kunder  siste  6  mnd.5
  6. 6. 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 Utfordringer • Ofte bytte av uviklingsmiljø • Sikkerhet som en naturlig del av utviklingsprosessen – Mange små uviklingsoppgaver • En «typisk» oppgave er estimert til 4-8 timer6
  7. 7. Sikkerhet som en naturlig del av utviklingsprosessen7
  8. 8. 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/
  9. 9. Aktiviteter i SDL* Manuell og automatisert testing Analysere angrepsflate Verifisering av Sikker Sikkerhetstrening og utarbeide trusselmodell og forvaltning trusselmodell angrepsflate Opplæring Design Verifikasjon Oppfølging Kravspek. Implementasjon Produksjon Etablere målbilde for sikkerhetsnivå Spesifisere verktøy Utarbeide beredskapsplan Analysere Håndheve implementasjons- Sikkerhetsgjennomgang sikkerhets- og personvernsrisiko regler Arkivering av Statisk sikkerhetsrelatert kodeanalyse prossessdokumentasjon9 *Fritt etter MS Security Development Lifecycle
  10. 10. Sikker programutvikling* Opplæring Kravspek. Design Implementasjon Verifikasjon Produksjon Oppfølging10 *Etter mal fra MS Security Development Lifecycle
  11. 11. Agile Security Development Lifecycle Manuell og automatisert testing Håndheve implementasjons- Verifisering av regler Sikkerhetstrening trusselmodell og angrepsflate Spesifisere verktøy Arkivering av Sikkerhetsgjennomgang sikkerhetsrelatert prossessdokumentasjon Analysere Analysere angrepsflate og sikkerhets- og utarbeide personvernsrisiko Etablere målbilde trusslemodell Statisk for sikkerhetsnivå Utarbeide kodeanalyse beredskapsplanAk:viteter  i  hver  sprint Engangsak:viteter Regelmessige  ak:viteter
  12. 12. Agile Security Development Lifecycle Analysere angrepsflate og utarbeide trusselmodell Analysere sikkerhets- og personvernsrisiko Verifisering av Håndheve trusselmodell og implementasjonsregler angrepsflate Arkivering av Spesifisere verktøy Manuell og sikkerhetsrelatert Etablere målbilde automatisert testing prossessdokumentasjon for sikkerhetsnivå Sikkerhetsgjennomgang Statisk kodeanalyse Utarbeide Sikkerhetstrening beredskapsplanAk:viteter  i  hver  sprint Engangsak:viteter Regelmessige  ak:viteter
  13. 13. «SDL» i forvaltningsteamet13
  14. 14. 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 programutvikling14
  15. 15. Opplæring Oppgave  8  -­‐  Lagret  XSS • 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  12b  -­‐  SQL  injec:on • Hent filen etc/passwd ved hjelp av SQL-injection15
  16. 16. Kravspesifikasjon og design • Utføres som workshop sammen Analysere angrepsflate med kunden for å kartlegge: – Informasjonsverdier Design – Angrepsflate Kravspek. – Aktører • Angrepsscenario (Misuse cases) Etablere målbilde – Alle deltakerene rangerer for sikkerhetsnivå scenarioene etter kritikalitet (lav til Analysere kritisk) hver for seg sikkerhets- og personvernsrisiko • Inngår som en viktig del av trusselmodellen16
  17. 17. Eksempel på angrepsscenario for aktøren «elev» 1 Ta over andre brukersesjoner 2 Endre passord på andre brukeres konto 3 Oppgradere egen konto til admin Kri:sk 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 Stor 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 Middels 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 Lav 17 Se hvem som ikke har levert oppgave17
  18. 18. 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 funksjonalitet18
  19. 19. 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 oppgaven19
  20. 20. Eksempel på testplan: • Som administrator vil jeg kunne slå av og på logging for de ulike web servicene Testkriterier Funksjonalitet/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 kommentarer Sikkerhet: • 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
  21. 21. 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
  22. 22. Spørsmål?22
  23. 23. Takk! Lars  Hopland  Nestås lars.nestas@bouvet.no23

×