1 ud af 100: Sådan designes hold til at bygge bro over sikkerhedshullet

1 ud af 100

Selv hvis du arbejder for en stor organisation, er chancerne for, at du kan huske navnene på alle de sikkerhedspersoner, der arbejder inden for it. Det skyldes, at forholdet mellem udviklere og sikkerhed er 100: 1 ifølge en nylig undersøgelse (den samme undersøgelse indikerer et 10: 1-forhold mellem devs og ops). Tidligere undersøgelser har rapporteret forhold mellem 100: 3 til 100: 6, så der er nogle fremskridt, men ikke hurtigt nok.

Det gavner ikke godt for disse organisationers evne til at tackle kommende databeskyttelsesregler som Den Europæiske Union GDPR og stoppe spildet af data, der har været på nyhederne regelmæssigt i de sidste år. Der er ikke nok dygtige sikkerhedsfolk derude i dag til at udfylde kløften. En vellykket anvendelse af sikker udviklings- og driftspraksis kræver ikke kun dyb teknisk forståelse, men også kritisk besiddelse af kommunikations-, overtalelses- og balanceringsevner for at opnå indkøb fra udviklingshold og (oftere end ikke) seniorledelse også.

Vi er stadig inde i en ond cirkel, hvor sikkerhedsspecialisering ikke er attraktiv nok, fordi virksomheden historisk set ikke har prioriteret sikkerhed nok. De samme virksomheder står nu over for et stigende behov for at opgradere deres sikkerhedspil, men de mangler mennesker.

Så hvilke muligheder har vi for at bygge bro over dette sikkerhedskløft?

Lad os først afklare, at automatisering af grundlæggende sikkerhedskontrol (f.eks. Tredjeparts sårbarheder) og kodning af retningslinjer og integrering af sikkerhed i leveringspipelinjen skal være en no-brainer for ethvert produktudviklingsteam i dag. Værktøjssættet i DevSecOps udvides fortsat, og kravene til både samfund og virksomhedskvalitet er godt tjent.

Så hvor er kløften? Det er i "hacker-tankegangen", en konstant søgning efter nye potentielle angrebsvektorer i vores applikationer (de "ukendte ukendte"). Og det er også den hårde opgave at give meningsfuld risikoanalyse og trusselmodellering og dens oversættelse til handlinger og prioriteter. Disse kræver dyb sikkerhedstænkning og baggrund, det er ikke noget, produktudviklingshold kan blive bedt om at indtage som ekstra kognitiv belastning på toppen af ​​deres nuværende ansvar.

Det arbejde, som Matthew Skelton og jeg har udført med at forske, katalogisere og forklare, hvordan forskellige DevOps-topologier kan spille en vigtig rolle i fremskridt eller blokering af DevOps-vedtagelse, passer fint til det aktuelle problem.

To distinkte (og muligvis komplementære) teamtopologier tænker på:

A) Fuldt delt sikkerhedsansvar

B) Sikkerhed som et aktiverende team

Hvad er forskellene, fordele og ulemper ved hver tilgang?

Fuldt delt sikkerhedsansvar betyder, at hvert produktudviklingshold integrerer mindst et sikkerhedsfokuseret T-formet teammedlem. Denne tilgang er tilstrækkelig, når organisationen stræber efter tværfunktionelle autonome produktudviklingshold. Sikkerhedspersonen skal være i stand til at oversætte komplekse sikkerhedstrusler til handlingsmæssige sikkerhedshistorier og acceptkriterier, som teamet kan forstå og implementere fra et teknisk synspunkt.

De skal også være i stand til at kommunikere risici og potentielle omkostninger for organisationen (compliance, indtægter og omdømme) på en måde, som virksomhedsejere kan forstå og prioritere. På den anden side skal de være klar til at udføre ikke-sikkerhedsrelaterede opgaver, når det er nødvendigt. Over tid bør ejerskab af sikkerhedsanalyse og -implementering sprede sig i teamet, mens den T-formede sikkerhedsperson muligvis holder en ekspertise med hensyn til at holde sig på toppen af ​​sikkerhedsmæssige bedste praksis, nye metoder og værktøjer, letter sikkerhedsrelaterede workshops og førende produktsikkerhed strategi.

Målet er ikke, at sikkerhedspersonen skal tildeles alt sikkerhedsarbejdet, ellers flytter vi bare en silo på et makroniveau (isoleret sikkerhedsteam) til et mikroniveau (isoleret teammedlem).
Hvert produkthold - afbildet som en gul cirkel - med 7 til 9 teammedlemmer, hvor mindst én er en T-formet sikkerhedsperson - afbildet i en grøn cirkel - men andre mennesker deltager også i sikkerhedsarbejdet

Der er selvfølgelig stadig et vigtigt sted for et centralt syn på sikkerhed på tværs af flere produkter og forretningsområder i organisationen. Det er kritisk at dele erfaringer, tilgange og resultater. Men dette kan tage form af et praksisfællesskab eller en orden (i Spotify parlance) af motiverede individer, der samles regelmæssigt, snarere end et dedikeret team (selvom det kunne fungere så godt, hvis du har midlerne).

Fordele

  • Holdsikkerhedsejerskab vil stige, hvilket fører til hurtigere (ikke-triviel) løsning af sikkerhedshændelser og, måske vigtigere, at lære af dem for at undgå at gentage smerterne i fremtiden.
  • Da hold har en naturlig størrelsesbegrænsning (8–9 personer), bør forholdet mellem it-medarbejdere og sikkerhed (T-formet) personale bevæge sig meget tættere på 10: 1 over tid med denne teamtopologi. Mangfoldigheden i teknisk baggrund alene vil give fordele med hensyn til tilgang til problemer og prioriteter.
  • Overgangen til denne topologi sender et ubestrideligt signal til alle i organisationen om, at sikkerhed nu er en førsteklasses borger i vores produkter.

Ulemper

  • Omkostningerne ved at finde og rekruttere (som muligvis kræver generøse pakker) og opløse de ekstra 9 sikkerhedspersoner (i en organisation med 100 udviklere) vil være et alvorligt problem (pr. Introduktion til dette indlæg). Forvent, at denne overgang tager en betydelig mængde tid, hvor du skal have en blanding af modeller på plads (nogle autonome produkthold og nogle stadig afhængigt af et centraliseret team), og tænk over en strategi for at vælge, hvilke hold der går først. Begynd for eksempel med at tildele de mere erfarne sikkerhedsfolk til de teams, der arbejder på de mere risikable produkter i din organisation.
  • Højpresterende autonome hold er baseret på stabilitet og at kende hinandens stærke og svage punkter. Enhver ændring af holdets sammensætning, selv en enkelt person, vil uundgåeligt medføre en vis forstyrrelse. Holdet kan måske føle, at det leverer mindre og bliver mindre produktivt, mens det indtager den nye sikkerhedsvinkel. Det er vigtigt, at alle forstår, at dette er normalt og accepteret.
  • Manglende et centralt kontaktpunkt for sikkerhedsmæssige problemer. Især seniorledere kan måske føle, at der er "ingen ved sikkerhedshjulet" i en decentral struktur. At sikre, at der er kommunikationskanaler, og at personer, der er i stand til at rette anmodninger om sikkerhedsinformation til de rigtige teams (eller til et praksisfællesskab), kan hjælpe her.

Heuristik

  • Har din organisation allerede tværfunktionelle teams, der integrerer virksomhedsejere og ejer ansvar for QA og overvåger og kører de applikationer, de udvikler?
  • Viser produkter (eller tjenester) meget forskellige risikoprofiler?
  • Kører produkter (eller tjenester) på heterogene tech-stakke og infrastruktur?

Hvis svaret på endnu et af de ovenstående spørgsmål bekræfter, kan denne topologi vise sig at være egnet til at tackle sikkerhedsgabet.

Sikkerhed som et aktiverende team betyder, at et dedikeret sikkerhedsteam yder support og vejledning (for eksempel at producere sikre udviklingsretningslinjer) til produktudviklingshold.

Af afgørende betydning udfører det centraliserede sikkerhedsteam ikke det egentlige sikkerhedsanalyser og implementeringsarbejde, men fremmer og vejleder det, hvor det er nødvendigt.

Det er lige så kritisk, at dette team bliver involveret helt fra starten af ​​projektet eller frigivelsen for at hjælpe produktgruppen med at overveje sikkerhedsmæssige implikationer, tilgange og praksis på hvert trin i livscyklussen.

Et tværgående sikkerhedsteam - afbildet lodret i grå - understøtter tre produkthold - afbildet vandret i orange - hvilket resulterer i delt ansvar for sikkerhed - afbildet som en lysegrøn cirkel

Mange organisationer har taget denne tilgang, herunder Spotify og Sportradar. Det kræver en meget mindre drastisk strukturændring fra den traditionelle "sikkerhedsteamsilo", da vi væsentligt skifter dette teams ansvar (vejledning og support snarere end implementering). Men det kan muligvis gøre det sværere for resten af ​​organisationen at indse, at produktteam forventes at tage et større ejerskab af sikkerheden i deres systemer.

Pablo Jensen, CTO i Sportradar, fortalte for nylig om deres dedikerede informationssikkerhedsteams rolle med at fremme sikkerhedsretningslinjer og politikker i tæt samarbejde med produkthold, lytte til deres feedback og iterere over tid. En af deres projektlivscyklusporte er en "egnethed til at starte udvikling", som kræver godkendelse fra sikkerhedsteamet, at der er tænkt nok på sikkerhedsmæssige implikationer og arbejdet planlagt i overensstemmelse hermed. Dette team rapporterer direkte til CEO og har autoritet til at stoppe produktlanceringer, hvis det er nødvendigt.

Rollen hos et centraliseret sikkerhedsteam, der giver vejledning snarere end at udføre produktsikkerhedsarbejdet (Kredit: Pablo Jensen, CTO på Sportradar - lysbilleder fra sin QCon London 2018-præsentation)

Fordele

  • Kortere tidsramme for at flytte til en aktiveringsmodel fra et traditionelt isoleret sikkerhedsteam, der udfører størstedelen af ​​sikkerhedsarbejdet.
  • Vil ikke kræve et stort antal nye ansættelser, og dermed undgå al den tilknyttede indsats og potencialt teamforstyrrelse. Fokus her skal være på at sikre, at det aktiverende team som helhed har alle de bløde færdigheder, der kræves, oven på tekniske færdigheder.

Ulemper

  • Dette team er nødt til at mestre effektiv kommunikation, hvilket i sig selv er en god ting. Dette er en færdighed, der skal slås sammen over tid, og der kan derfor initialt kræves investering i ekstern eller intern hjælp til at definere kommunikationsstrategier og kuratindhold.
  • Skift til denne model udsender et svagt signal om ændringen i sikkerhedsfokus. Signalet skal forstærkes og kan kræve gentagelse i lang tid, indtil det synker ind som en del af org-kulturen.
  • Introduktion af nye ansvarsområder, praksis og værktøjer kan være udfordrende for produktudviklingshold allerede på toppen af ​​deres kapacitet. Det centraliserede aktiveringshold kan blive overvældet med anmodninger om hjælp og blive udsat for pres for at hjælpe med implementering af produktsikkerhed, som ville besejre hele formålet med modellen.
  • Over tid forsvinder sikkerhedsfokus i produktgrupper muligvis uden en sikkerhedsperson, der deltager i holdets frigivelses- / sprintplanlægning og daglige standups. Der skal indføres en form for regeringsførelse for at undgå denne virkning.

Heuristik

  • Er der et lille antal produktudviklingshold (der muliggør et tættere samarbejde med sikkerhedsteamet)?
  • Viser produktgruppemedlemmerne interesse for sikkerhedsemner og appetit på at lære (for eksempel at deltage i tekniske konferencer eller møder)?
  • Involverer løsningen af ​​sikkerhedsrelaterede hændelser i produktionen naturligvis både sikkerheds- og udviklingsfolk (i modsætning til et skyldspil, hvor hver side holder sig væk fra ansvaret)?

Hvis svaret på endnu et af de ovenstående spørgsmål bekræfter, kan denne topologi vise sig at være egnet til at tackle sikkerhedsgabet.

Konklusion

DevSecOps har hævet profilen for sikkerhed inden for it, og den regelmæssige strøm af alvorlige dataovertrædelser har afsløret sikkerhedsgabet i de fleste organisationer. I dette indlæg præsenterede jeg et par mulige tilgange til at bygge bro over dette hul (fuldt ud delt sikkerhedsansvar vs sikkerhed som et aktiverende team) sammen med deres fordele og ulemper og heuristik baseret på kontekst.

Husk, at teamdesign ikke skal være statisk. Organisationer, mennesker og processer udvikler sig naturligt over tid, og hvad dagens bedste pasning kan være morgendagens hindring for hurtigere og mere sikker software. Det er sandsynligvis en organisation, der først vil flytte fra en traditionel sikkerhedssilotilgang til en ”sikkerhed som muliggør team” -model ved første og over tid overgang til en ”fuldt delt sikkerhedsansvar” -struktur, da sikkerhedsbevidsthed og ekspertise spredes på tværs af produktteams.

Hvilke andre teamtopologier og sikkerhedsstrategier har du set i dine organisationer eller klienter? Kommenter venligst nedenfor eller mail mig på:

mig på manuelpais dot net