I vår modenhetsstudie av programvaresikkerhet i offentlige virksomheter pekte penetreringstesting seg ut som en aktivitet som generelt sett ikke gjøres som en del av utviklingen – dette er overraskende når man tenker på hvor mange verktøy som er fritt tilgjengelige. Noen kunne hevde at den jevne utvikler ikke har tilstrekkelig kompetanse til å drive penetreringstesting, men vårt svar er at da er det på tide at de lærer seg noen nye triks!

Hovedmålet med praksisen “Penetreringstesting” er kvalitetskontroll av programvare som er i ferd med å bli rullet ut. De som utfører penetreringstesting må sørge for at sikkerhetsdefekter oppdages og korrigeres. Programvaresikkerhetsgruppen (SSG) må sørge for at standarder blir fulgt, og at godkjente sikkerhetsmekanismer gjenbrukes.

PT Nivå 1:    Oppdater kode etter penetreringstestingsresultater.

Ledere og SSG må initiere penetreringstestingsprosessen, med interne eller eksterne ressurser. Ledere og SSG må sørge for at oppdagede feil adresseres, og at alle er gjort kjent med fremdriften.

• PT1.1: Bruk eksterne penetreringstestere for å finne problemer
  Mange virksomheter er ikke villige til å adressere programvaresikkerhet før det er ugjendrivelig bevis for at virksomheten ikke på noe magisk vis er immun for problemet. Hvis sikkerhet ikke har vært prioritert, demonstrerer eksterne penetreringtestere at virksomhetens kode trenger hjelp. Penetreringstestere kan hentes inn for å bryte en høyprofil applikasjon for å markere poenget. Over tid flyttes fokuset for penetreringstesting fra “jeg fortalte deg at koden din er råtten” til en røyktest og sjekk av at ting ikke er helt på jordet som utføres før leveranse. Eksterne penetreringstestere bidrar med et nytt sett øyne på problemet.
• PT1.2: Mat resultater tilbake til feilhåndterings- og opprettings-systemet
  Resultater fra peneteringstesting mates tilbake til utviklerne via et etablert system for å håndtere feil og oppretting, og utviklerne responderer via deres feilhåndterings- og utgivelsesprosess. Øvelsen demonstrerer virksomhetens evne til å forbedre sikkerhetstilstanden. Mange virksomheter begynner å fremheve den kritiske viktigheten av å ikke bare identifisere, men også fikse sikkerhetsproblemer. En måte å sikre oppmerksomhet er å legge til et sikkerhetsflagg i feilsporing og feilhåndteringssystemet. Evolverende DevOps og integrerte arbeidsgruppestrukturer eliminerer ikke behovet for formaliserte feilhåndteringssystemer.
• PT1.3: Bruk penetreringstestingsverktøy internt
  Virksomheten oppretter en intern penetreringstestings kapabilitet som gjør bruk av verktøy. Denne kapabiliteten kan være en del av SSG, eller del av en spesielt opplært gruppe et annet sted i virksomheten. Verktøyene forbedrer effektiviteten og repeterbarheten av testprosessen. Verktøyene kan omfatte hyllevare produkter, standard nettverkspenetreringsverktøy som forstår applikasjonslaget, og håndskrevne kommandofiler.

PT Nivå 2:    Planlegg jevnlig penetreringstesting utført av informerte penetreringstestere.

SSG må legge til rette for en penetreringstestingsaktivitet som periodisk utføres på alle applikasjoner. SSG må dele sin sikkerhetskunnskap og testresultater med alle penetreringstestere.

• PT2.2: Utstyr penetreringstestere med all tilgjengelig informasjon
  Penetreringstestere, enten de er interne eller eksterne, bruker all tilgjengelig informasjon om målet. Penetreringstestere kan utføre dypere analyser og finne mer interessante problemer når de har tilgang på kildekode, designdokumenter, og resultater fra arkitekturanalyse og kodegjennomgang. Gi penetreringstesterne alle artefakter du har laget i løpet av din SSDL . Hvis penetreringstesteren ikke ber om koden trenger du en ny penetreringstester.
• PT2.3: Planlegg periodiske penetreringstester for å dekke opp alle applikasjoner
  Test all applikasjonene som faller inn under SSG regelmessig, dvs. etter en bestemt tidsplan (som kan knyttes til kalenderen eller utgivelsessyklusen). Testingen tjener som en sjekk på at ting ikke er helt på jordet (sanity check), og hjelper til med å sikre at gårsdagens kode ikke er sårbar for dagens angrep. Høyprofil-applikasjoner vil kanskje penetreringstestes en gang i året. Ett viktig aspekt ved periodisk testing er å forsikre seg om at problemene som identifiseres i en penetreringstest faktisk er ordnet, og at de ikke lurer seg tilbake i kodebasen.

PT Nivå 3:    Utfør dypdykk-penetreringstesting.

Ledere må sørge for at virksomhetens penetreringstestingskunnskap holder følge med fremskrittene som angriperne gjør. SSG må dra nytte av organisasjonsmessig kunnskap for å skreddersy penetreringstestingsverktøy.

• PT3.1: Bruk eksterne penetreringstestere til å gjøre dypdykk-analyse
  Virksomheten bruker eksterne penetreringstestere for å gjøre dypdykk-analyse for kritiske prosjekter og for å introdusere friske tanker i SSG. Disse testerne er eksperter og spesialister. De løfter virksomheten opp med siste nytt fra angriperens perspektiv, og de har en merittliste som demonstrerer erfaring med å knekke samme type programvare som testes. Dyktige penetreringstestere vil alltid knekke systemet. Spørsmålet er om de demonstrere nye typer tenkning rundt angrep som kan være nyttig når man skal designe, implementere og herde nye systemer. Det å lage nye typer angrep fra trusselinformasjon og abuse cases forhindrer sjekkliste-baserte tilnærminger som bare ser etter kjente typer problemer.
• PT3.2: La SSG skreddersy penetreringstestingsverktøy og kommandofiler
  SSG enten lager penetreringstestingsverktøy fra grunnen av, eller tilpasser offentlig tilgjengelige verktøy slik at de kan angripe virksomhetens systemer på en mer omfattende og effektiv måte. Verktøy forbedrer effektiviteten til penetreringstestingsprosessen uten å ofre dybden av problemer SSG kan identifisere. Verktøy som kan tilpasses er alltid å foretrekke over generelle verktøy.

 

Illustrasjon ved Yogendra Joshi, CC-BY-2.0