Hej, jag heter Tyler Welton. Jag är säkerhetsingenjör på Planview AgilePlace och jag älskar det. Jag tillbringar en stor del av min tid med att utföra både defensiva och offensiva säkerhetsuppgifter för vår webbapplikation, infrastruktur och säkerhetskultur.
Informationssäkerhet är svårt. Det är ännu svårare att tillhandahålla god säkerhet. Agil utvecklingsmetodik och Lean-principerna har gjort det möjligt för branschledare att producera och distribuera programvara snabbare och oftare än på flera årtionden tidigare. Naturligtvis måste vår omsorg att skydda denna programvara och våra sätt att göra det också utvecklas.
Säkerheten har alltid följt den tekniska utvecklingen, och det med rätta - utan tekniken skulle det inte finnas något att skydda. Jag tror att det är ganska uppenbart, bara genom att observera de aktuella händelserna, att skyddet av kunddata och förstärkning av koden mot attacker är något som måste stå i förgrunden för modern mjukvaruutveckling.
Tyvärr verkar det inom säkerhetsbranschen alltid finnas en fördröjning mellan förändringen av programvaruutvecklingen och förändringen av skyddet av programvaran. Problem uppstår när man försöker förbättra arbetsflödet vid utveckling och ge ett synligt värde för både användaren av programvaran och utvecklingsorganisationen.
Säkerhet av den gamla skolan ger säkert ett mervärde till verksamhet av den gamla skolan, men frekventa, iterativa programvaruversioner kan inte skyddas av system och metoder som är utformade för att skydda monoliter. Säkerheten måste komma ikapp.
Gamla skolan: Utanför loopen
Låt oss först ta itu med de strypgrepp som föråldrade metoder sätter på flödet. Det finns stereotyper som du hör i IT- och DevOps-världen, som inkluderar men inte är begränsade till: smärtsamma möten med rådgivande nämnder för förändringar (CAB) och komiskt byråkratiska hierarkier för godkännande av tekniska förändringar.
Även om dessa processer ursprungligen uppstod ur ett genuint intresse för säkerhet har de på många sätt levt upp till sina stereotyper. De har gjort det ironiskt nog svårt att snabbt lappa, göra frekventa sårbarhetsanalyser och integrera säkerheten, och på lång sikt kan de påverka en organisations säkerhetsställning negativt.
Dessa begränsningar finns inte bara i infrastrukturen utan även i programvaruutvecklingscykeln. Inom den gamla skolan av informationssäkerhet kan utvecklare arbeta med en programvara i månader innan den släpps. Ofta är säkerheten den sista anhalten på spåret. När säkerheten upptäcker ett problem med koden kan programvaran behöva skrivas om i stor omfattning. I dessa fall är säkerheten oengagerad, distanserad och inte så effektiv som den skulle kunna vara.
Värde är en annan Lean-idé som är en motsats till den traditionella, kolossala säkerheten. Ett bättre sätt att uttrycka det är kanske "det upplevda värdet". Framgångsrik säkerhet är svår att kvantifiera, eftersom en korrekt implementering av säkerheten inte bör ge några större resultat (överträdelser, incidenter osv.).
Vad som är ännu värre är att riktigt dåliga säkerhetsrutiner verkar ge samma kvantifierbara resultat, på grund av bristande insikt i hotbilden. Detta gör att säkerhetsingenjörer, specialister på applikationssäkerhet och hackare hamnar i en svår situation där de måste hitta ett sätt att uttrycka den risk som har minskats genom de system som de har infört.
Ny skola: Kontinuerlig distribution som en säkerhetsfunktion
Jag hörde ett konferenssamtal av Zane Lackey, tidigare på Etsy, som hävdade att kontinuerlig driftsättning var deras främsta säkerhetsfunktion. Detta har också varit sant på Planview AgilePlace, på flera sätt.
För det första möjliggör frekventa iterationer av både programvaruinstallationer och infrastrukturförändringar en grundligare säkerhets- och sårbarhetsanalys. Om ändringen som ska genomföras är tillräckligt liten kan säkerhetsanalysen vara extremt fokuserad. Fler möjliga vägar för utnyttjande kan undersökas när ljuset bara lyser på några få förändringar och allt sker inom det befintliga flödet i SDLC.
För det andra tvingar kontinuerlig driftsättning säkerhet till ett mer intimt förhållande med utveckling. När detta sker har säkerheten möjlighet att införa säkerhetsinsikt på kodnivå. Dessa mätvärden kan sedan användas och en verklig hotbild kan börja avslöjas. Detta gör det möjligt att presentera värdet av säkerheten på ett kvantifierbart sätt. I stället för en "dysfunktionell familjedynamik" kan utveckling och säkerhet börja med ett mer symbiotiskt förhållande.
Att komma igång med Lean
Lean-metoder lämpar sig väl för progressiv informationssäkerhet, men var börjar man på denna väg? Finns det någon utbildning för utvecklare som behöver äga rum? Måste politiken utformas och införas innan förändringar kan ske?
Jag har inga svar på dessa frågor eftersom lösningarna skiljer sig åt mellan olika organisationer. Men jag kan säga att det hjälper att ha resurser tillgängliga för utvecklare och IT-driftsarbetare. Teknikanställda är för det mesta vana vid att lära sig och ta till sig nya koncept, men de ägnar större delen av sitt fokus åt annat. Om en enkel katalog över resurser kan göras tillgänglig för konsumtion kan den i hög grad bidra till en kulturell förändring.
Vi är inte perfekta här på Planview AgilePlace, men jag har haft förmånen att få arbeta med några mycket säkerhetsmedvetna människor. Men även om det finns en brist på säkerhetsmedvetenhet inom ett företag kan en pool av relevanta resurser räcka långt. Vi är trots allt ett lag.
Det finns en fantastisk potential för att öka värdet av säkerheten samtidigt som man behåller och till och med förbättrar det moderna arbetsflödet. Allt detta betyder inte att det inte finns problem med moderna metoder - men agila team som värdesätter Lean-principerna har åtminstone en ram som gör det möjligt att snabbt utvecklas för att åtgärda dessa problem.
Avslutande reflektioner
Bruce Schneier sa: "Om du tror att tekniken kan lösa dina säkerhetsproblem förstår du varken problemen eller tekniken." Det är processen för att skapa säkerhet som är viktigare än de lösningar som finns på plats. Säkerhet är förmågan att reagera och anpassa sig för att upprätthålla integriteten hos de data och resurser som skyddas. Säkerheten, på gott och ont, är beroende av människor. Och det är människorna som måste skapa förändringen.
![En global plan för hantering av samarbetsarbete [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
