7 leksjoner fra å designe DEF CON Cloud Village CTF

7 leksjoner fra å designe DEF CON Cloud Village CTF

Tidsstempel: 10. januar 2024 8:00
7 leksjoner fra å designe DEF CON Cloud Village CTF PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Capture the Flag (CTF)-arrangementer er både morsomme og lærerike, og gir cybersikkerhetsfagfolk en måte å utvide hacking-ferdighetene sine mens de lærer nye konsepter i et konstruktivt og trygt miljø. Godt utformede CTFer utsetter enkeltpersoner og team for operasjonelle utfordringer, nye angrepsveier og kreative scenarier som senere kan brukes i deres arbeid både som offensive og defensive sikkerhetseksperter.

Men ikke alle CTF-er er skapt like, og det er mye mer som går med til å designe en vellykket CTF-konkurranse enn bare å komme opp med utfordringene. Sammen med de tekniske designutfordringene er det også operasjonelle hensyn involvert i å sette opp miljøet og faktisk kjøre konkurransen, kreativ planlegging som kreves for å sette opp et engasjerende spill, og å ta hensyn til detaljer knyttet til gamifying av utfordringene, for eksempel avveininger i hvordan poengsummen struktur er satt opp.

«Som designer vil jeg at det [CTF] skal være utfordrende moro. Jeg vil belønne folk som er flinke, som virkelig jobber med det, og som er utholdende, sier Jenko Hwong, hovedforsker på Netskopes Threat Research Labs-team og teamleder for fjorårets DEF CON Cloud Village CTF. "Det må også være praktisk for oss å gjennomføre."

Morsomt og praktisk var tankegangen som Hwong brakte til DEF CON CTF, en massiv flerdagers affære som hadde over 400 individer og lag som prøvde seg på utfordringen og et team på 20 som jobbet under ham for å gjennomføre arrangementet. En veteranforsker og erfaren CTF-deltaker, Hwong hadde aldri drevet en CTF før dette arrangementet. Et av hans største håp for hans første forsøk på jobben var å øke relevansen og realismen til utfordringene i arrangementet, noe som noen ganger kan være en bugaboo i CTF-er i dag.

«Noen ganger får du en veldig vanskelig utfordring i disse CTF-ene, men det er som om hva er vitsen med dette? Det vil være et dekrypterings- eller krypteringsproblem, der hendelsen går: "Her er noe, lykke til," og så må du hoppe gjennom alle disse bøylene som kanskje ikke er helt skilt fra virkeligheten, men som egentlig ikke passer inn i en større historie, sier han. "Så, da jeg fikk oppringningen, var tanken min 'la oss hoppe inn, la oss finne ut en god historie og et godt sett med utfordringer som vil være morsomme, men også som gir mening og kanskje relaterer seg til den virkelige verdenen av forskningspenetrasjonstesting, defensive tiltak, hva som skjer i den virkelige verden.'»

Mens han gikk inn i prosjektet, men en ting han syntes var spesielt utfordrende, er hvor lite informasjon det er der ute om å drive CTFer. De fleste oppskriftene er fra deltakere som vurderer et arrangement og forklarer hvordan de løste utfordringer, men det er sjelden informasjon som tilbys om beste praksis for å gjennomføre et arrangement. Som et resultat sa han at han og teamet hans måtte gjøre massevis av arbeid og skape utfordringer nesten fra bunnen av.

"Fellesskapet deler generelt massevis, så hvorfor deler vi ikke CTF-utfordringer?" han sier. – Jeg tror vi kan gjøre det bedre.

I den ånden av sikkerhetsfellesskapsdeling deler han noen viktige lærdommer som teamet hans tok opp underveis, slik at andre med ansvar for CTF-design kan lære og forstå av prosessen. Målet hans er å kjøre arrangementet igjen og bygge videre på det de lærte i fjor. Han håper også andre vil dele sin beste praksis, og til og med tekniske detaljer, slik at hele sikkerhetsfellesskapet kan forbedre kvaliteten på CTF-er som tilbys.

Historiefortelling er nøkkelen

Hwong sier at DEF CON Cloud Village-teamet hans var veldig opptatt av å lage en historie som var engasjerende og morsom. Han sier at han tenkte på historien som et filmmanus med realistiske cyber-scenarier innebygd. For arrangementet valgte de temaet "Gnomes" som var morsomt og morsomt. men det var ikke bare historieskrivingen som var viktig, men også hvordan de tekniske utfordringene ble planlagt i historien.

"Nissen og nisser-historien omsluttet alt, men det viktigste var å komme opp med rimelige scenarier som du kan støte på som sikkerhetsekspert, inkludert angrepsveier og fornuftige forsvar du vil møte," sier han. "Jo mer vi kan gjøre det som CTF-designere, jo bedre er det for læring og jo morsommere er CTF."

Ta en tilnærming til programvareutvikling

CTF-skapere bør definitivt ta en programvareutviklingstilnærming for å designe de tekniske elementene i utfordringen deres, anbefaler Hwong.

"Du må tenke på design, implementering og testing," sier han, og forklarer at han og teamet hans lærte på den harde måten hvor vanskelig det kan være å teste utfordringer i et komplekst CTF-miljø som kan manipuleres av deltakerne på mange måter .

«Det som skjedde – og jeg vil ta på meg skylden som hovedskaperen for ikke å lede testingen – er at vi gikk glipp av det negative testpasset, så vel som levedyktighetskontrollene,» sier han. "En del av det er at vi ikke hadde nok tid til å teste, så jeg fortsatte å låse ned noen miljøer mens utfordringen var i gang, slik at noen av utfordringene ikke skulle være for enkle og det var ingen smutthull. Jeg tror at jeg på et tidspunkt i en time eller to endte opp med å lage noe uløselig på et bestemt trinn."

Så en av de store lærdommene han lærte er at CTF-designere må ta med programvareutvikling strenghet til bordet som går hele veien gjennom testing og levedyktighetsarbeid.

Operasjonell strenghet ... og litt koffein

Nøye i programvareutvikling er ikke den eneste tekniske evnen som må komme på bordet. Mannskapet som driver en CTF trenger også en viss operativ strenghet.

"Vi hadde noen fantastiske folk som kjørte serverne og AWS-kontoene og Google- og Azure-kontoene og sørget for at ting fortsatte å kjøre og at vi overvåket ting," sier han. "Alt sånt må håndteres. Og hvis du ignorerer det, kan det bare bety at ting feiler, går i stykker eller at du har ytelsesproblemer.»

Et av de operasjonelle problemene de møtte var at de opplevde en kollisjon mellom deltakere og utfordringer, da teamet opererte med en begrensning ved at de ikke kunne lage et frittstående miljø for hver deltaker på tvers av AWS, Google og Azure.

"Fordi det var i det samme miljøet, hjalp det dem på andre utfordringer, og hvis du har en utfordring som krever å endre miljøet, har du folk som tråkker hverandre på tærne og endrer et felles objekt," sa han og forklarte at han og hans teamet måtte tilbakestille policyer mens CTF rullet fremover slik at deltakerne ikke skulle støte på hverandre.

Han og teamet hans prøver å lære av erfaringen for å finne ut en praktisk metode – fra tid, innsats og kostnadsperspektiv – for å gi deltakerne et virkelig isolert miljø uten å gjøre hele CTF mindre levedyktig fordi ting går i stykker eller tar evigheter å utføre.

Til slutt sier Hwong at på den operative fronten må CTF-showløpere også være oppmerksomme på den konstante kommunikasjonen de trenger for å lette mellom laget og deltakerne.

"Jeg var på Discord etter midnatt, og jeg tenker: 'Jeg har en tale å holde i morgen, vil du legge deg?'" spøkte Hwong, som forklarte at deltakerne vil ha spørsmål og at de kommer til å være ping arrangører for tips og tips til enhver tid.

Det er vanskelig å designe forskjellige vanskelighetsgrader

Det kan være vanskeligere å få vanskelighetsnivåene til utfordringene riktig og lage et rettferdig poengsystem enn en nybegynner CTF-arrangør i utgangspunktet tror, ​​advarte Hwong. Han forklarte at noen av nivåene som teamet hans utformet som enklere var vanskeligere for deltakerne å fullføre enn de hadde forventet, mens noen av de mer utfordrende nivåene ble fullført av flere deltakere enn forventet.

Hånd i hånd med vanskelighetsutfordringen er å finne ut et poengsystem som gir mening. Etter sin erfaring fra DEF CON, er Hwong en talsmann for å gjøre et slags Bell Curve-scoringssystem. Men han sier at problemet ikke er så enkelt som å etablere en kurve. Det er også spørsmålet om å normalisere og balansere fordelen som store CTF-lag har ved å samle utfordringspoeng – et problem som en av deltakerne ga ham tilbakemelding om etter arrangementet.

"Så hvis utfordringene dine kan deles og gjøres parallelt med flere spillere, hvis jeg har 10 personer vil jeg være 10 ganger er raskt. Og så det er en fordel, sier han. "Poenget hans var en slags dynamisk scoring nivåer det litt. Hvis det er ting han er veldig, veldig god på, kan han være den eneste som løser det, og han vil få maksimale poeng. Klokkekurven vil belønne ham kontra skala spiller ingen rolle om det er noe i hans styrehus av ekspertise i form av 10 mot en. Det er noen diskutable ting her som vi må jobbe gjennom.»

En mulighet er å gjøre utfordringer sekvensielle, men ulempen med det er at det kan gjøre CTF for rigid og lineær, og det kan skape en flaskehals eller avhengigheter som kan sprenge en eller flere utfordringer. Hwong sier at han også ville elske å se flere CTF-er belønne deltakere på teknikker som hvor snikt de opererer i et miljø eller kaipunkter hvis de etterlater for mange fotavtrykk og fingeravtrykk, og det er et område han gjerne vil utforske når han designer fremtidige arrangementer .

Uansett, men dynamisk scoring er noe som kan lindre noen av utjevningsproblemene, og han og teamet hans jobber med det for det kommende året.

Blå lag trenger flere morsomme CTF-utfordringer

Etter å ha jobbet gjennom sin første CTF, tror Hwong også i økende grad at disse arrangementene ikke gjør nok for å utfordre og virkelig engasjere deltakere i det blå laget.

"Blå teamøvelser har en tendens til å gå slik: 'Vi har et feilkonfigurert miljø med mange sårbarheter. Kan du gå og fikse dem?'» sier han. " Og det de gjør er at de bare tester om disse konfigurasjonene er endret eller ikke, eller om jeg har tilgang til denne offentlige bøtten. Og så snart du gjør det privat, vet vi at du fikset det, og du får poeng. Det ville være mye bedre å gjøre ting på toppen av det, for eksempel hva hvis du er kompromittert, det er en angriper i miljøet ditt, du må finne dem og sparke dem ut. Så du har en hendelse på gang akkurat nå, og så lenge angriperen er det, har de legitimasjon og så lenge de vil gjøre ting, kan du kanskje oppdage det. Det er jobben din som deltaker. Og inntil du tilbakekaller tilgangen deres, løser du det ikke, og du får ikke maksimalpoeng.»

Slike scenarier er vanskeligere å gjøre, men de er mer realistiske for forsvarere og vil gjøre CTF-er mer verdifulle for dem, sier han og forklarer at det er på radaren hans til neste gang.

CTF-er trenger flere ferske og relevante komponenter.

Hwong utfordrer også CTF-designere – og seg selv – til å inkludere mer fersk utnyttelses- og sårbarhetsinformasjon i utfordringene deres. Dette var en av tingene han ønsket at han hadde mer tid til å dykke ned i i sin første tur på DEF CON Cloud Village, og som han har bestemt seg for å forbedre til neste år.

"Dette er et av områdene hvor CTF-er kan være mer et lærings- og treningsverktøy," forklarer han. "Vi vil gjerne bruke relevante ideer og utnyttelser ferske fra forskere som fant sted tidligere på året eller til og med presentert på DEF CON."

CTF 'byggeklosser' for å forbedre 'gjenbrukbarhet'

Til slutt, en av de største lærdommene Hwong sier han lærte er at industrien må finne flere måter å lage gjenbrukbare komponenter for CTF akkurat som programvareutviklere gjør for applikasjoner. Han har drømmer om å hjelpe til med å organisere et åpent GitHub-lager med små øvelser i kode som kan danne byggesteinene for å bygge ut en CTF.

"Du må fortsatt tilpasse det og legge til din egen vri, men ideen er at vi skal få de første 60 % ut av veien slik at CTF-arrangører kan fokusere på virkelig nye ting. På den måten er det ingen som finner opp hjulet på nytt, sier han. "Og så kan de resterende 40% legge til nye teknikker, scenarier og historier."

Tidstempel:

Mer fra Mørk lesning