Leveransekjeder - en kjent risiko som krever bevisste valg

Solstorm

Allerede da vi skrev kapittelet Når nettene blir lange 1 i Digital Sikkerhet 2020 hadde en trusselaktør – senere attribuert til Russland – kompromittert SolarWinds Inc. sine systemer i halvannet år. Trusselaktøren hadde utnyttet deres mekanismer for programvareutvikling og distribusjon av oppdateringer for å få levert skadevaren til tusenvis av kunder (26. mars 2020).

Så sent som i desember 2020 var det fortsatt mulig å laste ned den kompromitterte programvaren fra SolarWinds Inc. sine hjemmesider, og sertifikatet som hadde signert den kompromitterte programvaren var fortsatt ikke trukket tilbake. Det er lett å se at håndteringen – på et tidspunkt da SolarWinds Inc. visste hva som hadde skjedd – ikke var optimal. Som utenforstående og etterpåklok er det lett å kritisere dem for det. Vel så interessant er det at bare ett av 67 antivirus programmer var i stand til å oppdage skadevaren på tjenesten Virus Total1 på dette tidspunktet.

Det er betimelig å stille spørsmål ved om SolarWinds forstod sitt ansvar og risikoeksponeringen de representerte for sine kunder? Og om de burde ha forstått det? Mange av kundene til SolarWinds Inc. er Managed Service Providers (MSP-er) som igjen har hundre- eller tusenvis av kunder som betjenes av denne programvaren. Hadde SolarWinds Inc. nødvendig kompetanse og kapasitet til å håndtere risikoen? Og førte de tilstrekkelig kontroll med hva som ble lagt til av ny kode?

Det er grunn til å tro at robuste sikkerhetskontroller i byggemiljøet kunne ha indikert at noe var galt. God praksis på området er veletablert, for eksempel med forskjellige former for automatisert kodeanalyse og sårbarhetstesting, og kunne trolig bidratt til å avverge eller begrenset effekten av angrepet. For endringer i særlig sensitive komponenter eller av betydelig omfang, kan endog menneskelig sidemannskontroll, med eller uten verktøybasert gjenkjenning, være en nødvendig forsikring.

Bare et uskyldig offer?

Det er også grunn til å stille spørsmål om de største kundene av SolarWinds kunne utøvd større grad av kontroll med leveransene fra SolarWinds, eller stilt tydeligere krav om at grundigere sikkerhetsmessig kvalitetskontroll var gjennomført av en kvalifisert tredjepart før leveranse. Eksempelvis er MSP-er, ved sin én-tilmange posisjon i verdikjeden og med privilegerte tilganger hos sine kunder, en effektiv og velkjent angrepsvektor.

Det er imidlertid ressurs- og kompetansekrevende virkemidler som må tas i bruk for å avdekke et vellykket programvareleveransekjede angrep i mottatt programvare, dersom leverandørens utviklings- eller byggemiljø er kompromittert og den kompromitterte programvaren fremstår helt autentisk. Med den betydelige mengden programvareverktøy en gjennomsnitts virksomhet faktisk benytter, vil mange nøle med å foreta så dyptgående verifikasjon.

Mange benytter kun grunnleggende integritetskontroll og skadevareanalyse ved mottak av programvare. Det er en start, men for avgjørende programvareleveranser blir det stadig tydeligere at ytterligere innsats er nødvendig for å møte en risiko som manifesterer seg i stadig flere alvorlige hendelser. Mer avanserte tiltak handler imidlertid ikke bare om sterkereevne til å avdekke kompromittert programvare og forhindre at den tas i bruk; god sikkerhetsovervåkning kan også bidra til tidlig deteksjon av at det faktisk har skjedd. Dette kan ha stor verdi, da det gjerne går noe tid fra initiell kompromittering gjennom leveransekjede, til trusselaktøren bruker de etablerte tilgangene mot utvalgte mål.

Året som gikk

Angrepet på SolarWinds Inc. har fått stor oppmerksomhet, men det var bare ett av flere alvorlige vellykkede leveransekjedeangrep det siste året. Vi merker oss blant annet:

«Skilpadder hele veien ned»

Mange klient-applikasjoner er i dag nettleserbaserte. Dette har sin naturlige årsak. De fleste nettlesere er nå å regne som fullverdige operativsystemer med viktige sikkerhetsmekanismer og ikke minst standardiserte programmeringsgrensesnitt som, uavhengig om nettleseren kjøres på Windows, Mac, Linux eller en mobiltelefon, kan kjøre samme applikasjonskode. Kostnadene for å utvikle slike applikasjoner reduseres dermed kraftig.

En ytterligere faktor, som bidrar til å redusere tid og kost, er dynamisk bruk av tredjeparts-biblioteker som Node, JQuery og Chartbeat. Med dynamisk menes at bibliotekene enten lastes ned når applikasjonen bygges eller når den kjører i en nettleser. På den ene siden medvirker ofte slike biblioteker til sikrere kode, ettersom de ofte hjelper programmerere å «gjøre ting riktig», mens de på den andre siden øker risikoen for å bli kompromittert gjennom leverandørkjeden. Dette ble behørig demonstrert i februar da en sikkerhetsforsker beskrev hvordan han hadde utnyttet denne typen dynamisk nedlastning ved å publisere pakker med konseptuell «skadevare» til forskjellige offentlige rammeverk (NPM, RubyGems og PyPI) med samme, eller nesten samme, navn som det flere større teknologiselskaper selv benyttet på sine interne moduler.3

For en mindre virksomhet, uten egen kapasitet til dypkvalitetskontroll av tredjepartskomponenter, eller økonomi til å kjøpe slik bistand, kan det å dynamisk hente siste publiserte versjon fra offentlige kilder ha større sikkerhetsgevinst enn nedside. Man er i hvert fall sikker på å få med seg de siste sikkerhetsforbedringene, til tross for at man samtidig løper risikoen for å få med seg det siste leveransekjede-angrepet som «lik i lasten». For andre virksomheter kan risikoen – både egen og kundenes – tilsi større grad av kontroll.

Dette rettferdiggjør ressursbruk på dyptgående kvalitetskontroll som kan redusere sannsynligheten for at et hittil ukjent leveransekjedeangrep slipper gjennom.

Dynamisk henting av tredjepartskomponenter krever en risikobasert avveiing mellom tillit og kontroll. Dette må tuftes på forståelse av egen og kundenes risikotoleranse. Telenor Norge har førstehåndserfaring fra hvordan dette kan utspille seg, da en programvareleveranse fra en leverandør viste seg å inneholde ondsinnet kode fra et bibliotek som var hentet dynamisk inn, flere nivåer ned i avhengighetshierarkiet. For vår del ble det heldigvis oppdaget før koden kom inn i vår tjenesteproduksjon. I dette tilfellet ville den ikke gjort skade der da den hadde et helt annet spesifikt mål for øyet. Vi noterer imidlertid trusselaktørens økonomisk motiverte vilje til å innplassere kode, som ender opp i flere tusen programvarer, og «brenne» sitt eget lille åpen kildekodeprosjekt, kun for å nå én programvare som brukte dette biblioteket.

Åpen kildekode – leveransekjeder omfatter mer enn klassiske «leverandører»

Et annet – og ganske annerledes – leveransekjedeangrep som vakte noe oppsikt tidlig i 2021, er innsnikingen av “sårbarheter” i Linux kernel kode fra studenter ved University of Minnesota4). Studentene tok utgangspunkt i universitetsmiljøets gode renommé hos Linux kernel utviklere, og leverte kodebidrag med bevisste «sårbarheter» som deretter ble akseptert av autoriserte kernel-utviklere og inkludert i den offisielle Linux-kjernen.

Saken har vakt en stor debatt om hvorvidt det var etisk riktig å gjøre et slikt sikkerhetseksperiment. I forhold til leveransekjeder illustrerer saken hvor sårbare mange grunnleggende åpenkildekode- prosjekter, som mye moderne IT er basert på, egentlig er. At alle kan se kildekoden, gir ikke nødvendigvis god sikkerhetsmessig kontroll, selv om det i dette tilfellet til slutt ble oppdaget. Graden av kontroll, innsatsen på sikkerhetsmessige forbedringer og evne til å adressere sårbarheter, avhenger av tilgjengelige ressurser i prosjektene.

Det er overraskende mange åpen kildekode-prosjekter av nærmest global kritisk karakter, som avhenger av noen få ildsjelers ubetalte innsats. For eksempel oppdaget verden i forbindelse med Heartbleed5, at det populære SSL-biblioteket OpenSSL i realiteten ble vedlikeholdt av kun én person. Heldigvis har flere kommersielle virksomheter de senere årene fått øynene opp for nødvendigheten av å støtte disse prosjektene – og det rimelige i at aktører som fremstiller svært lønnsomme produkter med FOSS-komponenter (Free and open-source software) som innsatsfaktor, også gir noe tilbake.

Kan du vite hva du får? (Software Bill of Materials)

Det blir stadig vanligere i leveranseavtaler å ikke kun stille krav om at de fysiske leveransene er detaljert spesifisert i Bill of Materials, men også at programvareleveransene og hva de inneholder er beskrevet i en Software Bill of Materials (SBOM). En SBOM beskriver alle programvarekomponenter som inngår i leveransen, inkludert del- og underkomponenter med presise spesifikasjoner som for eksempel versjon- og byggnummer. Det er mange fordeler ved å vite hva du faktisk får levert ned på dette nivået. De mest umiddelbare kan knyttes til sikkerhets-kvalitetsvurdering av en leveranse både før og etter kjøpsbeslutningen er tatt, input/supplement til asset inventory, sårbarhetshåndtering og underlag for sikkerhetsverifikasjon av den mottatte varen. Skulle det ikke være helt selvsagt å få dokumentert hva leveransen inneholder?

Programvareleveranser kan ofte ha en omfattende komponentliste og -hierarki. Det er derfor nødvendig, ikke minst for å kunne gjøre effektiv bruk av informasjonen, å produsere SBOM som et maskinlesbart strukturert datasett. Flere standardformater og verktøy for å lese, skrive og konvertere mellom dem er åpent tilgjengelig. Vi tror de fleste virksomheter som anskaffer programvare bør stille krav om en slik “innholdsdeklarasjon”. US Department of Commerce har en god introduksjon til SBOM, med mange gode referanser.6

Kan du vite hva det gjør? (Communications Bill of Materials)

En SBOM beskriver hvilke komponenter en sammensatt programvare består av. Vi vil hevde det er like viktig å få god og detaljert informasjon fra programvareleverandøren om hvordan programvaren skal forventes å oppføre seg, og da spesielt hvordan den kommuniserer. Om Communications Bill of Materials vil få rotfeste som allment begrep i programvareanskaffelser tør vi ikke spå, men vi mener det er viktig å stille krav om at forventet by-design kommunikasjon til og fra den leverte programvaren er beskrevet. Det understøtter både implementasjon med minimert eksponering på alle protokoll-lag, for eksempel snever hvitlisting i både brannmurer, proxyer og applikasjonslagsinspeksjon, anomalideteksjon i sikkerhetsovervåkning, og er grunnlag til sikkerhetsverifikasjon av den mottatte varen.

I sammensatte programvareprodukter bør Communication Bill of Materials også beskrive den interne kommunikasjonen mellom løsningskomponentene, noe som blant annet gir grunnlag for å designe innplassering i en forsvarbar infrastruktur med høy grad av segregering/segmentering, og strengt regulert (eksplisitttillatt) kommunikasjon mellom komponentene. Dokumentasjon av en programvares kommunikasjon er ikke like modent og strukturert som dokumentasjon av programvarens innhold (SBOM), men vi mener det er like selvsagt å forvente dette dokumentert – og noe kjøpere av programvare bør forvente og kravstille.

Valgene vi tar

Det er nå ti år siden det første virkelig store leveransekjedeangrepet vi kjenner til; angrepet på RSA, der kinesiske statlige

operatører stjal såkalte seed-verdier til SecurID kodebrikker. Med disse kunne operatørene komme seg forbi to-faktor autentiseringen hos alle deres SecurID-kunder, blant annet en underleverandør til Lockheed Martin, Level 3 Communications og Northrop Grumman7. Etter dette etablerte Lockheed Martin begrepet Cyber Kill Chain8 som gir en strukturert gjennomgang av syv generiske hovedtrinn i digitale operasjoner. Lockheed Martin valgte senere samme år å etablere og publisere en modell for en moderne forsvarbar sikkerhetsarkitektur9.

Den vedvarende strømmen av vellykkede leveransekjedeangrep – fra RSA-angrepet frem til i dag – understreker et av våre hovedbudskap fra Når nettene blir lange 1 i Digital Sikkerhet 2020; du må som ansvarlig leverandør forstå hvilken risiko dine leveranser utgjør for dine kunders verdier. Uten dette har du heller ikke grunnlag for å forstå egen attraktivitet for trusselaktører, og eget beskyttelsesbehov.

En viss leveransekjederisiko kommer ingen virksomhet unna, men grad av eksponering og risiko er resultat av bevisste valg. Hvilke leverandører velger du, og på hvilket grunnlag? Hvilke krav stiller du, og hvordan? Hvor mye investerer du i kontrollaktiviteter? Hvordan forbereder du deg på å håndtere det neste leveransekjedeangrepet når det treffer din virksomhet?

Hva skjer når leverandøren selges?

Virksomheter kjøpes og selges. I 2021 fikk salget av Bergen Engines stor oppmerksomhet i norske medier. Dette med bakgrunn i bekymringer om kjøperens intensjoner sett i forhold til norske nasjonale sikkerhetsinteresser. Problematikken er imidlertid ikke avgrenset til nasjonal sikkerhet.

Salg av en leverandør, helt eller delvis, kan innvirke betydelig på leveransekjederisikoen du utsettes for og på flere måter. Måten leverandørvirksomheten drives på kan endres betydelig, og påvirke både leveranseevne og kommersielle betingelser. Hvor virksomhetens ulike funksjoner er lokalisert, eller hvor hovedkvarteret til den overtakende virksomheten ligger, kan påvirke både sikkerheten i leveransene og hvordan din informasjon blir håndtert av leverandøren. Både jurisdiksjon, korrupsjonsindeks og samfunnsmessig stabilitet spiller inn her. Objektive forhold ved leverandørvirksomheten kan også endres ved eller som følge av en virksomhetsoverdragelse; for eksempel leverandørens økonomiske soliditet og objektiv sikkerhet. Alt dette har i sum stor betydning for deg som mottaker av leverandørens varer eller tjenester.

I tillegg til ordinære leverandørvurderinger og priskonkurranse, bør langsiktig stabilitet og sannsynlighet for at leverandørvirksomheten blir overdratt til vilkårlig tredjepart tas i betraktning i leverandørvalg. Spesielt der disse forholdene kan ha stor betydning for din virksomhet. Slik vurdering krever blant annet innsikt i leverandørselskapet/leverandør-industrigruppens sammensetning, deres syn på egen kjernevirksomhet, virksomhetens påregnelige og fremtidige kapitalbehov. Dersom varen eller tjenesten du kjøper, eller enheten som produserer den, ligger noe på siden av leverandørens kjernevirksomhet er det forhøyet risiko for et skifte av hender. Studie av trender og tendenser til konsolidering i leverandørens marked og bransje kan også gi viktige indikasjoner.

Uansett hvor grundig forarbeid som gjøres ved avtaleinngåelse, er fremtidige eierskifter, konsolideringer og virksomhetsoverdragelser vanskelig å forutse. Dersom det inntreffer, bør det imidlertid gjøres en risikovurdering med tanke på om leveransekjedeeksponeringen og -risikoen er vesentlig endret. I en periode, eller som et varig tiltak, kan det være nødvendig å forvalte leverandørrelasjonen mindre tillitsbasert og med større grad av faktisk kontroll og verifikasjon. For eksempel gjennom styrket tilsyn med leverandørvirksomhetens sikkerhetstilstand og leveransenes sikkerhetsmessige kvalitet. Dersom identifisert risiko grenser opp mot uakseptabelt nivå, eller leverandøren motsetter seg tilsyn du har vurdert å være nødvendig, vil skifte av leverandør være siste utvei. Det er sjeldent ønskelig, men kan ikke utelukkes.

Der det er identifisert forhøyet risiko for endrede eierforhold hos viktige leverandører, bør det vurderes om risikoreduserende tiltak skal iverksettes før eierskiftet eventuelt inntreffer. Når du definerer hva som er viktige leverandører må du ta i betraktning leverandørens og leveransens negative påvirkningspotensiale mot din virksomhet, dine leveranser og dine kunder. Ikke bare hvor kritisk bidraget fra leverandøren er for å opprettholde egen produksjon. Dersom slik risiko er identifiserbar ved avtaleinngåelse kan det være handlingsrom i kontraktsarbeidet, for eksempel ved forkjøpsrett til den aktuelle delen av leverandøren. En insourcing som forkorter leveransekjeden kan uansett vurderes som risikoreduserende tiltak hvis en leverandørvirksomhet, eller en del av den, blir tilbudt for salg. En mer pragmatisk og langt vanligere tilnærming er standby-avtaler med alternativ leverandør. Prisen for dette vil ofte være et visst minstekjøp fra en mindre prisgunstig standby-leverandør. Et permanent oppsett med to eller flere leverandører kan også være et risikoreduserende tiltak. Den reelle evnen til å falle tilbake på kun én av dem, og ikke minst risikoøkningen ved å eksponere seg mot flere leveransekjeder, må veies mot sikkerhetsgevinsten ved et slikt tiltak. 

Myte 1 – «APT angrep kan vi ikke gjøre noe med»

Å vise til at det var «et svært avansert angrep» har blitt en vanlig forklaring fra kompromitterte virksomheter. Det er selvsagt et snev av sannhet i det, selv om forklaringen blir flittig brukt i media også når hverken aktøren eller teknikken var spesielt avansert. Det er riktig at de virkelig avanserte og målrettede aktørene er svært krevende å beskytte seg mot. Det er imidlertid mulig å redusere sannsynligheten for at angrepet lykkes, får vedvare, får spre seg, eller får katastrofale konsekvenser. En ansvarlig virksomhet kan ikke strekke hendene i været og gi opp «fordi APT».

1.        Gjør det dyrt for dem, ved å ivareta basis sikkerhetshygiene. Sikkerhets-patching og sikker konfigurasjon bidrar til at angriperen må bruke mer kompetente ressurser. APT-aktører rår over store ressurser, men også de må prioritere. Det koster dem mye mer å finne og bruke hittil ukjente sårbarheter. Selv om det er legitimt å ta risiko og eksponering av sårbarhetene i betraktning når man prioriterer patching, er det verdt å merke seg det nå er helt vanlig å kombinere sårbarheter med «lav» risiko-score, slik at de til sammen muliggjør et alvorlig sikkerhetsbrudd. Patching av low og medium sårbarheter kan derfor ikke utsettes i det uendelige.10

2.       Forsinke dem. Segmentering og minimert eksponering både eksternt og internt, tvinger angriperen til å bruke tid på å bevege seg gjennom infrastrukturen fra det første angrepspunktet. Dette gir deg blant annet mer tid til å observere og begrense et angrep under utvikling. Vit, og vær bevisst på, hva du eksponerer til hvem og hvordan – all eksponering skal bunne i et reelt behov.

3.       Kjenn din infrastruktur. En verdenskjent APT11 har selv pekt på at de som regel har gjort seg bedre kjent med målets infrastruktur enn målets egen IT-avdeling.

4.       Instrumenter for deteksjon. Robust sikkerhetsovervåkning krever synlighet og analyse både på logghendelser, trafikk (også “internt”) og på host/workload.

5.       Tenk lagdelt sikkerhet i design, arkitektur og trusselmodellering. Det bør aldri være nok at én mekanisme svikter for at et angrep skal lykkes. Fjern avhengigheter på tvers der det er mulig slik at omfanget og effekten av et vellykket angrep begrenses.

6.       Planlegg for kontinuitet. Offline backup og konkrete gjenopprettingsplaner kan bidra til å redusere de forretningsmessige skadevirkningene. Selv om mange APT-angrep har innhenting og informasjonstyveri som mål, har vi sett flere eksempler på at APT-verktøy kommer organiserte kriminelle i hende – der destruktive ransomware-angrep er høyst relevant.

Myte 2 – «Vi må fikse brukerne!»

«Brukerne er det svake leddet», hører vi stadig. Ser vi på inngangsvektorer for cyberangrep er det ingen tvil om at mennesker og menneskelighet blir utnyttet. Drive-by angrep ved surfing, eposter med infiserte vedlegg og lenker som tar brukeren til både skadevare og phishing, er vektorer som gjerne henføres til at det er mennesket som har sviktet. Konklusjonen blir dermed ofte at vi må «fikse mennesket» for å hindre at slikt skjer. Flere awareness-kampanjer, phishing tester og lignende aktiviteter er ment å sette brukerne bedre i stand til å opptre med sunn skepsis og kritisk sans i sitt møte med angriperne. Det er ikke dumt, men det tar oss ikke i mål. Vi spiller bare videre i våpenkappløpet der angriperne blir stadig mer kreative og utspekulerte, og fortsatt klarer å lure brukerne.

«Ikke åpne vedlegg fra folk du ikke kjenner» og «ikke klikk på linker» er velmente råd, men for mange er nettopp dette del av arbeidshverdagen og jobbinnholdet. «Hvis du er i tvil, ring gjerne avsenderen for å verifisere» har vi «sikkerhetseksperter» også sagt. Rådene krever at man faktisk er i tvil om ektheten av henvendelsen, og at man tar seg tid til å sjekke dette i en hektisk hverdag. Begge disse to forutsetningen står for fall. I tillegg dukker det fra tid til annen opp zero click sårbarheter som kan utnyttes. Det ble funnet to slike i iOS i mai. Da har brukeren lite å stille opp med.

Vi mener de aller fleste virksomheter må gå lengre i å bruke teknologiske virkemidler som tar høyde for at bruk av nettjenester og epost med vedlegg er en del av arbeidshverdagen og arbeidsprosessene. De fleste arbeidstakere er ikke ansatt for å bruke all sin tid og tankekraft på å unngå å bli lurt, men har andre oppgaver. Trusselaktøren har bare én oppgave å tenke på; hvordan kan jeg klare å lure mottakeren? Trusselaktørene har også et skala-overtak; noen få angripere kan rette samme våpen mot mange ofre.

Etablerte virkemidler som scanning av e-post og SSL-inspeksjon kan lete etter kjente skadevarer og skadevaremønstre. Det må imidlertid legges større vekt på å hindre at konsekvensene blir fatale når noe slipper gjennom. Denne siste-skansen omtaler vi gjerne som containment; grep du tar for å hindre at den skadelige effekten inntreffer, eller at den i det minste begrenses til et isolert miljø.

Authentic8 Silo og Cloudflare Browser Isolation er eksempler på tjenestekategorien Remote Browser Isolation (RBI). Her vil en virtualisert «engangs» nettleser kjøre i deres plattform, og enhver utnyttelse av sårbarheter i nettleseren eller andre programmer som en nedlasting gjennom nettleseren kan interagere med, forblir isolert på deres plattform og er borte ved neste surfe-sesjon. HP Sure Click (tidligere Bromium) er et eksempel på prosessisolasjon på brukerens PC hvor spesifikke prosesser, for eksempel nettleser, dokumentleser og Office-programmer, kan styres til å kjøre i en egen mikro-kernel. Slik begrenses skaden og mest trolig hindres skadevaren i å få utfolde seg.

Til og med svært enkle grep kan ha god effekt; som for eksempel:

•         Assosiere alle script-filtyper, slik som “.bat” og “.ps1” i Windows (hvis de skulle slippe inn til brukerens pc-plattform) til åpning i en tekst-editor,

•         Frata brukeren administratorrettigheter,

•         Herde klienten,

•         Holde klientene oppdatert,

•         Bruke en sikret DNS-tjeneste som filtrerer kjente ondsinnede domener, for eksempel OpenDNS Umbrella, Telenor Nettvern, Cloudflare 1.1.1.2 eller Quad9 9.9.9.9.

Security awareness training har likevel sin plass i sikkerhetsprogrammet – det er mange andre måter å bli lurt på.

1 https://virustotal.com

2 Anbefalt lesning med relevant beskrivelse og teknisk analyse: https://blog.group-ib.com/colunmtk_apt41

3 https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

4 The Verge: How a University Got Itself Banned from the Linux Kernel – https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minnesota-banned-open-source

5 https://heartbleed.com

6 U.S. Dpt. of Commerce - National Telecommunications and Information Administration: https://www.ntia.gov/SBOM

7 I år har tidligere ansatte i RSA endelig kunnet snakke om angrepet, og vi har fått mer kunnskap om det https://www.wired.com/story/the-full-story-of-the-stunning-rsa-hack-can-finally-be-told/

8 Lockheed Martin – The Cyber Kill Chain: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html

9 Lockheed Martin: Defendable Architectures https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Defendable-Architectures.pdf

10 Chris Gates – “Pentesting from LOW to PWNED” https://www.youtube.com/watch?v=u68QvWXYW_Q

11 Rob Joyce, Head of NSA Tailored Access Operations: https://www.usenix.org/conference/enigma2016/conference-program/presentation/joyce