1 de cada 100: Dissenyar equips per solucionar el buit de seguretat

1 de cada 100

Fins i tot si treballeu per a una gran organització, hi ha la possibilitat que recordeu els noms de tot el personal de seguretat que treballi en informàtica. Segons una enquesta recent, la relació desenvolupador / seguretat és de 100: 1 (el mateix estudi indica una relació entre el desenvolupador i el sistema operatiu de 10: 1). Estudis anteriors han reportat relacions de 100: 3 a 100: 6, de manera que s'han avançat alguns, però no són prou ràpids.

Això no és un bon senyal de la capacitat d’aquestes organitzacions per afrontar les regulacions de protecció de dades properes com el GDPR de la Unió Europea i per aturar les dades que han circulat regularment a les notícies en els darrers anys. Avui no hi ha prou agents de seguretat qualificats per cobrir aquest buit. La introducció amb èxit de pràctiques operatives de desenvolupament i desenvolupament segur no només requereix una profunda comprensió tècnica, sinó també la capacitat de comunicar-se, convèncer i equilibrar-se per tal de prevaler entre els equips de desenvolupament i (sobretot) la direcció.

Encara estem en un cercle viciós on l’especialització en seguretat no és prou atractiva perquè les empreses no han donat prou prioritat a la seguretat en el passat. Les mateixes empreses tenen ara una necessitat creixent de millorar el seu joc de seguretat, però no tenen personal.

Quines opcions tenim per tancar aquesta vulnerabilitat?

Primer, deixem clar que l’automatització de les auditories bàsiques de seguretat (per exemple, vulnerabilitats de tercers) i les directrius de codificació, així com la integració de la seguretat al pipeline de desplegament no haurien de ser cap problema per a cap equip de desenvolupament de productes en aquests dies. El conjunt d’eines de DevSecOps s’està ampliant constantment i es compleixen els requisits tant de la comunitat com de l’empresa.

I on és la bretxa? És a la "mentalitat del pirata informàtic" una cerca constant de nous vectors potencials d'atac a les nostres aplicacions (el "desconegut desconegut"). A més, és una tasca difícil dur a terme una anàlisi significativa dels riscos i modelar les amenaces i traduir-les en mesures i prioritats. Es requereix un pensament de seguretat profund i coneixements de fons. No es pot demanar als equips de desenvolupament de productes que acceptin aquesta càrrega cognitiva addicional a més de les seves responsabilitats existents.

El treball que Matthew Skelton i jo vam fer per investigar, catalogar i explicar com les diferents topologies de DevOps poden tenir un paper important en l’avançament o el bloqueig de l’adopció de DevOps s’ajusten bé al problema actual.

Hi ha dues topologies d'equips (i possiblement complementàries) diferents:

A) Responsabilitats de seguretat completament compartides

B) La seguretat com a equip activador

Quines diferències, avantatges i desavantatges té els enfocaments?

Les responsabilitats de seguretat completament compartides comporten que cada equip de desenvolupament de productes integri almenys un membre de l’equip de forma T orientat a la seguretat. Aquest enfocament és adequat si l'organització pretén equips de desenvolupament de productes autònoms i funcionals. L’oficial de seguretat ha de ser capaç de traduir amenaces de seguretat complexes en informes de seguretat i criteris d’acceptació que l’equip pugui entendre i implementar des d’un punt de vista tècnic.

També han de ser capaços de comunicar riscos i costos potencials per a l’empresa (compliment, vendes i reputació) de manera que els empresaris puguin entendre i prioritzar. D’altra banda, si cal, haurien d’estar a punt per dur a terme tasques no relacionades amb la seguretat. Amb el temps, la responsabilitat de l’anàlisi i la implementació de la seguretat de l’equip s’hauria d’ampliar, mentre que la persona en seguretat en forma de T tindrà el coneixement relacionat amb les bones pràctiques, nous mètodes i eines i permetrà tallers relacionats amb la seguretat i estratègia de seguretat del producte líder. .

L’objectiu no és assignar tota la tasca de seguretat a la persona de seguretat. En cas contrari, només movem una sitja a nivell macro (equip de seguretat aïllat) a un nivell de micro (membre de l’equip aïllat).
Cada equip de producte (mostrat com a cercle groc) amb 7 a 9 membres de l'equip, almenys un dels quals és una persona de seguretat en forma de T, que es mostra en un cercle verd, però altres persones també participen en la tasca de seguretat.

Per descomptat, encara hi ha un lloc important en l'organització per a una visió centralitzada de la seguretat en diversos productes i àrees de negoci. L’intercanvi d’experiències, enfocaments i resultats és crucial. Tot i això, això pot prendre la forma d’una comunitat de pràctiques o gremi (en idioma Spotify) a partir de persones motivades que es reuneixen regularment en lloc d’un equip dedicat (tot i que això podria funcionar si teniu recursos).

Avantatges

  • La responsabilitat per la seguretat de l’equip augmenta, la qual cosa comporta una resolució més ràpida (no trivial) d’incidents de seguretat i, potser més important, aprendre d’ells per evitar que el dolor es repeteixi en el futur.
  • Com que els equips tenen un límit de mida natural (entre 8 i 9 persones), la relació entre el personal informàtic i el personal de seguretat (en forma de T) s’hauria d’aproximar de manera significativa al llarg del temps amb aquesta topologia d’equip. La diversitat del bagatge tècnic només aportarà avantatges a l'hora d'abordar els problemes i les prioritats.
  • El pas a aquesta topologia enviarà un senyal indiscutible a tothom de l’organització que la seguretat en els nostres productes ara és un ciutadà de primera qualitat.

Inconvenients

  • El cost de la cerca i la contractació (que podria requerir paquets generosos) i la posada en marxa d’aquests nou guàrdies de seguretat addicionals (en una organització amb 100 desenvolupadors) serà un problema greu (tal com s’explica a la introducció d’aquest post). Espereu que aquesta transició trigui un temps. Durant aquest temps, s’han d’utilitzar diferents models (alguns equips de producte autònoms i d’altres que encara depenen d’un equip central) i considerar quins equips s’han de seleccionar primer. Per exemple, comenceu a assignar personal de seguretat amb més experiència als equips que treballen en els productes més arriscats de la vostra empresa.
  • Podents equips autònoms es basen en l’estabilitat i el coneixement de les fortaleses i debilitats mútues. Qualsevol canvi en la composició de l'equip, fins i tot si hi ha una sola persona, inevitablement comportarà interrupcions. L’equip pot tenir la sensació que estiguin rendint menys i que siguin menys productius considerant el nou aspecte de seguretat. És crucial que tothom entengui que això és normal i acceptat.
  • Cap punt de contacte central per qüestions de seguretat. En concret, els executius podrien sentir que en una estructura descentralitzada ningú no està al volant de la seguretat. Aquí pot ser útil assegurar-se que hi hagi canals de comunicació disponibles i que les persones puguin reenviar sol·licituds d’informació de seguretat als equips adequats (o a una comunitat de pràctiques).

Heurística

  • La vostra organització ja disposa d’equips funcionals que integren propietaris d’empreses, són responsables de l’assegurament de la qualitat i controlen i gestionen les aplicacions que desenvolupen?
  • Els productes (o serveis) mostren perfils de risc molt diferents?
  • Els productes (o serveis) funcionen en infraestructures tècniques heterogènies?

Si la resposta a una o més de les preguntes anteriors és positiva, aquesta topologia pot resultar ser una bona manera de tancar la vulnerabilitat.

La seguretat com a equip activador significa que un equip de seguretat dedicat dóna suport i suporta equips de desenvolupament de productes (per exemple, directrius creades per a un desenvolupament segur).

És crucial que l’equip de seguretat centralitzat no realitzi l’anàlisi i la implementació de seguretat reals, sinó que el promogui i el dirigeixi si cal.

És igualment important que aquest equip estigui involucrat en el projecte o publicació des del primer moment per tal que l’equip de producte pugui considerar implicacions, enfocaments i pràctiques de seguretat en totes les etapes del cicle de vida.

Un equip de seguretat transversal, que es mostra verticalment en gris, admet tres equips de productes, mostrats horitzontalment en taronja. Això comporta una responsabilitat compartida per a la seguretat, que es representa com un cercle verd clar

Moltes organitzacions han escollit aquest enfocament, incloses Spotify i Sportradar. Es requereix un canvi estructural molt menys dràstic del tradicional "sitja de l'equip de seguretat", ja que, essencialment, canviem les responsabilitats d'aquest equip (orientació i suport en lloc de la implementació). Tot i això, això podria dificultar la resta de l'empresa per adonar-se que s'espera que els equips de producte tinguin una millor adherència a la seguretat dels seus sistemes.

Pablo Jensen, CTO de Sportradar, va parlar recentment del paper del seu equip dedicat de seguretat de la informació en la promoció de polítiques i directrius de seguretat en estreta col·laboració amb els equips de producte. Una de les portes del seu cicle de vida del projecte és una "Elegibilitat per iniciar el desenvolupament" que requereix l'aprovació de l'equip de seguretat, que s'han tingut en compte les implicacions de seguretat i s'ha planificat el treball en conseqüència. Aquest equip informa directament del CEO i està autoritzat per aturar els llançaments de productes si fos necessari.

Paper d’un equip de seguretat centralitzat que no assumeix la tasca de seguretat del producte, però assessorament (font: Pablo Jensen, CTO de Sportradar - diapositives de la seva presentació a QCon London 2018)

Avantatges

  • Menys de temps per a la transició cap a un model d’activació d’un equip de seguretat aïllat tradicional que fa la major part de les tasques de seguretat.
  • No requereix un gran nombre de nous empleats i evita així l’esforç associat i possibles interrupcions a l’equip. El focus aquí ha de ser el de garantir que el conjunt de l'equip habilitador tingui totes les habilitats suaus necessàries, a més de les tècniques.

Inconvenients

  • Aquest equip ha de dominar la comunicació efectiva, la qual cosa és bona per si mateixa. Aquesta és una habilitat que cal millorar amb el pas del temps. Per tant, pot ser necessari primer invertir en ajuda externa o interna per definir estratègies de comunicació i curar contingut.
  • Si canvieu a aquest model, s’emetrà un senyal feble per canviar l’enfocament de seguretat. El senyal ha de ser amplificat i pot haver de repetir-se durant molt de temps abans d’enfonsar-se com a part de la cultura orgànica.
  • La introducció de noves responsabilitats, pràctiques i eines pot ser un repte per als equips de desenvolupament de productes que ja tinguin la seva capacitat màxima. L’equip d’activació centralitzada pot veure’s desbordat i pressionat per aconseguir ajuda per implementar la seguretat del producte, que anul·la l’objectiu general del model.
  • Amb el pas del temps, el focus de seguretat en els equips de producte pot disminuir sense que una persona de seguretat participi en la planificació de llançament / sprint i en la plantilla diària de l'equip. Cal evitar aquest tipus de govern.

Heurística

  • Hi ha un nombre reduït d’equips de desenvolupament de productes (que permeten una col·laboració més estreta amb l’equip de seguretat)?
  • Els membres de l’equip de producte mostren interès pels temes de seguretat i voluntat d’aprendre (per exemple, assistint a conferències tècniques o reunions de reunions)?
  • Per descomptat, la solució als incidents relacionats amb la seguretat en la producció afecta tant el personal de seguretat com el de desenvolupament (a diferència d’un joc de culpa en què cada costat es distancia de la responsabilitat)?

Si la resposta a una o més de les preguntes anteriors és positiva, aquesta topologia pot resultar ser una bona manera de tancar la vulnerabilitat.

Conclusió

DevSecOps ha reforçat el perfil de seguretat en informàtica i el flux regular de greus incompliments de dades ha exposat el buit de seguretat de la majoria de les empreses. En aquest post vaig presentar alguns possibles enfocaments per cobrir aquest buit (responsabilitat de seguretat totalment compartida vs seguretat com a equip empoderador), juntament amb els seus avantatges i inconvenients i heurístiques basades en el context.

Tingueu en compte que el disseny de l’equip no ha de ser estàtic. Les organitzacions, les persones i els processos es desenvolupen de forma natural amb el pas del temps. El que millor s’adapta avui pot ser un obstacle per al programari de demà més ràpid i segur. És totalment possible que una empresa pugui passar inicialment d’un plantejament tradicional de sitja de seguretat a un model de “seguretat com a equip d’activació” i amb el pas del temps a una estructura amb “responsabilitats de seguretat completament compartides” a mesura que la consciència i el canvi de coneixement en matèria de seguretat. als equips de producte.

Quines altres topologies i estratègies de seguretat heu vist a les vostres organitzacions o clients? Comenteu a continuació o envieu-me un correu electrònic a:

jo a manuelpais dot net