We hadden de beschikking over 2 code-analysatoren, 4 dynamische testtools, eigen handwerk en 250 scripts. Het is niet zo dat dit allemaal noodzakelijk is in het huidige proces, maar zodra je begint met de implementatie van DevSecOps, moet je het tot het einde doorvoeren.
. Personages gecreëerd door Justin Roiland en Dan Harmon.
Wat is SecDevOps? Hoe zit het met DevSecOps? Wat zijn de verschillen? Applicatiebeveiliging - Waar gaat het over? Waarom werkt de klassieke aanpak niet meer? Hij kent het antwoord op al deze vragen Joeri Sjabalin van Zwaardvisbeveiliging. Yuri beantwoordt alles gedetailleerd en analyseert de problemen bij de overgang van het klassieke Application Security-model naar het DevSecOps-proces: hoe pak je de integratie van het beveiligde ontwikkelingsproces in het DevOps-proces op de juiste manier aan zonder iets te verstoren, hoe doorloop je de belangrijkste fasen van beveiligingstesten, welke tools kunnen worden gebruikt, hoe verschillen ze en hoe configureer je ze correct om valkuilen te vermijden.
Over de spreker: Joeri Sjabalin - Hoofdbeveiligingsarchitect in het bedrijf Zwaardvisbeveiliging. Verantwoordelijk voor de implementatie van SSDL, voor de algehele integratie van applicatieanalysetools in één ontwikkelings- en test-ecosysteem. 7 jaar ervaring in informatiebeveiliging. Heeft gewerkt bij Alfa-Bank, Sberbank en Positive Technologies, een bedrijf dat software ontwikkelt en diensten levert. Spreker op internationale conferenties ZerONights, PHDays, RISSPA, OWASP.
Applicatiebeveiliging: wat is het?
Applicatiebeveiliging — Dit is het beveiligingsgedeelte dat verantwoordelijk is voor de beveiliging van de applicatie. Het gaat hier niet om de infrastructuur of netwerkbeveiliging, maar om wat wij schrijven en waar ontwikkelaars aan werken. Dat zijn de tekortkomingen en kwetsbaarheden van de applicatie zelf.
richting - Levenscyclus van beveiligingsontwikkeling — ontwikkeld door Microsoft. Het diagram toont het canonieke SDLC-model. Het hoofddoel hiervan is om beveiliging te betrekken bij elke ontwikkelingsfase, van vereisten tot release en productie. Microsoft besefte dat er te veel bugs in de industrie waren, dat er zelfs nog meer bugs waren en dat er iets aan gedaan moest worden. Ze stelden deze aanpak voor, die standaard werd.
Application Security en SSDL zijn niet gericht op het detecteren van kwetsbaarheden, zoals vaak wordt gedacht, maar op het voorkomen ervan. In de loop van de tijd is de standaardaanpak van Microsoft verbeterd, verder ontwikkeld en er is dieper en gedetailleerder op ingegaan.
De canonieke SDLC is zeer gedetailleerd in verschillende methodologieën - OpenSAMM, BSIMM, OWASP. De methodologieën verschillen, maar zijn over het algemeen vergelijkbaar.
Het opbouwen van veiligheid in het volwassenheidsmodel
Ik vind het het leukst BSIMM - . De basis van de methodologie is de verdeling van het Application Security-proces in 4 domeinen: Governance, Intelligence, SSDL Touchpoints en Deployment. Elk domein heeft 12 praktijken, die worden gepresenteerd in de vorm van 112 activiteiten.
Elk van de 112 activiteiten heeft 3 niveaus van volwassenheid: beginner, halfgevorderd en gevorderd. Alle 12 praktijken kunnen in delen worden bestudeerd, waarbij u de zaken selecteert die voor u belangrijk zijn, uitzoekt hoe u deze kunt implementeren en geleidelijk elementen toevoegt, bijvoorbeeld statische en dynamische codeanalyse of codebeoordeling. Je maakt een plan en gaat hier rustig mee aan de slag binnen de kaders van de uitvoering van de gekozen werkzaamheden.
Waarom DevSecOps
DevOps is een groot proces waarbij u rekening moet houden met de beveiliging.
Eerste veronderstelde veiligheidscontroles. In de praktijk was het aantal beveiligingsteams veel kleiner dan nu en fungeerden ze niet als deelnemers aan het proces, maar als een controlerend en toezichthoudend orgaan dat eisen aan het product stelt en de kwaliteit ervan aan het einde van de release controleert. Dit is een klassieke aanpak waarbij beveiligingsteams buiten de ontwikkelingsmuren werden gehouden en niet bij het proces betrokken waren.
Het grootste probleem is dat informatiebeveiliging losstaat van ontwikkeling. Meestal is dit een specifiek informatiebeveiligingscircuit en het bevat 2-3 grote en dure tools. Eens per zes maanden komt er een broncode of applicatie binnen die gecontroleerd moet worden, en eens per jaar, . Dit alles leidt ertoe dat de releasedatum voor productie wordt uitgesteld en dat de ontwikkelaar wordt geconfronteerd met een groot aantal kwetsbaarheden van geautomatiseerde tools. Het is onmogelijk om dit allemaal te demonteren en te repareren, omdat de resultaten van de afgelopen zes maanden nog niet zijn gesorteerd en er dan weer een nieuwe lichting is.
Tijdens het werk van ons bedrijf zien we dat de beveiliging op alle gebieden en in alle industrieën begrijpt dat het tijd is om de achterstand in te halen en in hetzelfde wiel te draaien als de ontwikkeling - in . Het DevSecOps-paradigma sluit perfect aan bij de Agile-ontwikkelingsmethodiek, implementatie, ondersteuning en deelname aan elke release en iteratie.
Overgang naar DevSecOps
Het belangrijkste woord in de Security Development Lifecycle is "proces". U moet dit begrijpen voordat u overweegt gereedschap aan te schaffen.
Het is niet voldoende om alleen tools in het DevOps-proces op te nemen. Interactie en begrip tussen de deelnemers aan het proces zijn ook belangrijk.
Mensen zijn belangrijker dan gereedschappen
Vaak begint de planning van een veilig ontwikkelingsproces met het selecteren en aanschaffen van een tool en eindigt het met pogingen om de tool te integreren in het huidige proces. Dit blijven pogingen. Dit heeft trieste gevolgen, omdat elk instrument zijn eigen kenmerken en beperkingen heeft.
Een veelvoorkomend geval is wanneer de beveiligingsafdeling een goede, dure tool met uitgebreide mogelijkheden heeft gekozen en naar de ontwikkelaars stapt om deze in het proces te integreren. Maar dat lukt niet – het proces is zo gestructureerd dat de beperkingen van het reeds aangeschafte gereedschap niet in het huidige paradigma passen.
Beschrijf eerst het gewenste resultaat en hoe het proces eruit zal zien. Hiermee krijgt u inzicht in de rol van gereedschap en beveiliging in het proces.
Begin met wat al in gebruik is
Kijk eerst eens naar wat u al heeft, voordat u duur gereedschap koopt. Elk bedrijf heeft beveiligingsvereisten die aan de ontwikkeling worden voorgelegd, er zijn controles, pentests - waarom zouden we dit niet allemaal omzetten in een vorm die begrijpelijk en handig is voor iedereen?
Normaal gesproken zijn de vereisten een papieren boek dat in de kast ligt. Zo kwamen we bij een bedrijf langs om de processen te bekijken en vroegen we of we de beveiligingsvereisten voor de software konden laten zien. De specialist die dit deed, zocht er lang naar:
- Ergens in de notities stond een pad naar de locatie waar dit document zich bevond.
Het resultaat was dat we het document een week later ontvingen.
Voor eisen, controles, enz., maak een pagina aan, zoals samenvloeiing - het is handig voor iedereen.
Het is gemakkelijker om iets wat al bestaat opnieuw te formatteren en daarmee aan de slag te gaan.
Maak gebruik van Security Champions
In een gemiddeld bedrijf is er één beveiligingsspecialist die voor 100-200 ontwikkelaars werkt. Deze persoon vervult meerdere functies en heeft fysiek niet de tijd om alles te controleren. Ook al doet hij zijn best, hij alleen kan niet alle code controleren die de ontwikkeling genereert. Voor dergelijke gevallen is een concept ontwikkeld: .
Security Champions zijn mensen binnen het ontwikkelteam die geïnteresseerd zijn in de beveiliging van uw product.
Security Champion is het toegangspunt tot het ontwikkelteam en een ware beveiligingsevangelist in één.
Wanneer een beveiligingsspecialist bij een ontwikkelteam komt en een fout in de code signaleert, krijgt hij doorgaans een verbaasde reactie:
- En wie ben jij? Ik zie je voor het eerst. Het gaat goed - mijn senior collega gaf me "toepassen" bij de codebeoordeling, we gaan verder!
Dit is een typische situatie, omdat er veel meer vertrouwen is in senior- of teamcollega's met wie de ontwikkelaar op het werk en bij codereviews voortdurend contact heeft. Als een Security Champion de fout en de gevolgen ervan aankaart in plaats van een beveiligingsprofessional, dan heeft zijn woord meer gewicht.
Bovendien kennen ontwikkelaars hun code beter dan welke beveiligingsprofessional dan ook. Voor iemand die minimaal 5 projecten in een statische analysetool heeft, is het vaak moeilijk om alle nuances te onthouden. Security Champions kennen hun product: ze zijn effectiever als ze weten wat met wat samenhangt en waar ze eerst naar moeten kijken.
Overweeg daarom om Security Champions te implementeren en de invloed van uw beveiligingsteam uit te breiden. Ook voor de kampioen zelf is dit nuttig: professionele ontwikkeling in een nieuw vakgebied, verbreding van de technische horizon, verbetering van technische, management- en leiderschapsvaardigheden, stijging van de marktwaarde. Dit is een onderdeel van social engineering: jouw 'ogen' in het ontwikkelteam.
Testfasen
zegt dat 20% van de inspanningen 80% van het resultaat oplevert. Deze 20% zijn toepassingsanalysepraktijken die geautomatiseerd kunnen en moeten worden. Voorbeelden van dergelijke activiteiten zijn statische analyse - SAST, dynamische analyse - DAST, и Open Source Control. Ik zal je meer vertellen over activiteiten, maar ook over hulpmiddelen, welke functies we doorgaans tegenkomen bij het implementeren ervan in het proces en hoe je dit op de juiste manier doet.
Belangrijkste problemen met gereedschappen
Ik zal de kwesties belichten die voor alle instrumenten relevant zijn en aandacht behoeven. Ik zal ze wat uitgebreider bekijken, zodat ik niet in herhaling val.
Lange analysetijd. Als het 30 minuten duurt van commit tot release tot productie voor alle tests en assemblage, dan duren informatiebeveiligingscontroles een dag. Op deze manier vertraagt niemand het proces. Houd rekening met dit kenmerk en trek uw conclusies.
Hoog niveau van vals-negatieven of vals-positieven. Elk product is anders, gebruikt een ander framework en heeft zijn eigen codeerstijl. Op verschillende codebases en technologieën kunnen tools verschillende niveaus van False Negative en False Positive weergeven. Kijk dus eens wat er precies in zit uw bedrijven en voor uw toepassingen zullen goede en betrouwbare resultaten opleveren.
Geen integraties met bestaande tools. Bekijk de tools op basis van integraties met wat u al gebruikt. Als u bijvoorbeeld Jenkins of TeamCity hebt, controleer dan de integratie van de tools met deze software en niet met GitLab CI, die u toch niet gebruikt.
Gebrek aan of overmatige complexiteit van maatwerk. Als een tool geen API heeft, waar is deze dan voor? Alles wat in de interface kan worden gedaan, zou ook via de API beschikbaar moeten zijn. Idealiter zou de tool de mogelijkheid moeten hebben om controles aan te passen.
Er is geen stappenplan voor productontwikkeling. De ontwikkeling staat niet stil, we gebruiken voortdurend nieuwe frameworks en functies en herschrijven oude code in nieuwe talen. Wij willen er zeker van zijn dat de tool die wij kopen, nieuwe frameworks en technologieën ondersteunt. Daarom is het belangrijk om te weten dat het product een echte en correcte ontwikkeling.
Proces functies
Naast de kenmerken van de tools, moet u ook rekening houden met de kenmerken van het ontwikkelingsproces. Een veelgemaakte fout is bijvoorbeeld het ingrijpen in de ontwikkeling. Laten we eens kijken naar welke andere functies in aanmerking moeten worden genomen en waar het beveiligingsteam op moet letten.
Om te voorkomen dat u ontwikkelings- en releasedeadlines mist, maakt u verschillende regels en anders showstoppers — criteria voor het stoppen van het bouwproces in geval van kwetsbaarheden — voor verschillende omgevingen. Wij begrijpen bijvoorbeeld dat de huidige branch naar de ontwikkelaarsstand of UAT gaat, dus wij stoppen niet en zeggen:
- Hier zitten kwetsbaarheden, verder kom je niet!
In deze fase is het belangrijk om de ontwikkelaars te laten weten dat er beveiligingsproblemen zijn die moeten worden aangepakt.
De aanwezigheid van kwetsbaarheden vormt geen belemmering voor verder testen: handmatig, geïntegreerd of handmatig. Aan de andere kant moeten we de veiligheid van het product op de een of andere manier verbeteren, zodat ontwikkelaars niet negeren wat veilig is. Daarom doen we het soms zo: op de stand, wanneer het wordt uitgerold naar de ontwikkelaarsomgeving, stellen we de ontwikkelaars simpelweg op de hoogte:
- Jongens, jullie hebben problemen, besteed er alsjeblieft aandacht aan.
In de UAT-fase geven we opnieuw waarschuwingen over kwetsbaarheden, en in de fase van het in productie nemen zeggen we:
- Jongens, we hebben jullie al meerdere keren gewaarschuwd, jullie hebben niks gedaan - we laten jullie hier niet voor vrij.
Als we het over code en dynamiek hebben, dan is het noodzakelijk om alleen kwetsbaarheden weer te geven en te waarschuwen voor die functies en code die net in deze functie zijn geschreven. Als een ontwikkelaar een knop 3 pixels verplaatst en wij hem vertellen dat er een SQL-injectie is en dat dit daarom dringend moet worden opgelost, dan klopt dat niet. Kijk alleen naar wat er nu geschreven staat en naar de verandering die dit met zich meebrengt voor de applicatie.
Stel dat er sprake is van een functioneel defect, een probleem waardoor de applicatie niet zou moeten werken: er wordt geen geld overgemaakt, bij het klikken op een knop wordt er niet naar de volgende pagina gegaan of het product wordt niet geladen. Beveiligingslekken — dit zijn dezelfde gebreken, maar dan niet in termen van de werking van de applicatie, maar in termen van beveiliging.
Niet alle problemen met de softwarekwaliteit zijn beveiligingsproblemen. Maar alle beveiligingsproblemen hebben te maken met de kwaliteit van de software. Sherif Mansour, Expedia.
Omdat alle kwetsbaarheden bugs zijn, zouden ze zich op dezelfde plaats moeten bevinden als alle ontwikkelingsbugs. Vergeet dus de rapporten en angstaanjagende PDF's die niemand leest.
Toen ik bij een ontwikkelingsbedrijf werkte, ontving ik een rapport van een tool voor statische analyse. Ik opende het, was geschokt, zette wat koffie, bladerde door de 350 pagina's, deed het dicht en ging weer aan het werk. Grote rapporten zijn dode rapporten. Meestal gaan ze nergens heen, worden de e-mails verwijderd, vergeten, raken kwijt of het bedrijf zegt dat het de risico's accepteert.
Wat moet ik doen? We zetten de gevonden bevestigde defecten eenvoudigweg om in een vorm die handig is voor ontwikkeling. We plaatsen ze bijvoorbeeld in de backlog in Jira. We prioriteren en elimineren defecten in volgorde van prioriteit, samen met functionele defecten en testdefecten.
Statische analyse - SAST
Dit is een analyse van de code op kwetsbaarheden., maar het is niet hetzelfde als SonarQube. Wij letten niet alleen op patronen of stijlen. Bij de analyse worden verschillende benaderingen gebruikt: per kwetsbaarheidsboom, per , door configuratiebestanden te analyseren. Dat is alles wat betrekking heeft op de code zelf.
Voordelen van de aanpak: het identificeren van kwetsbaarheden in code in een vroeg stadium van de ontwikkeling, als er nog geen standaards en kant-en-klare gereedschappen zijn, en Incrementele scanmogelijkheid: het scannen van het gedeelte met code dat is gewijzigd, en alleen de functie die we op dat moment aan het uitvoeren zijn, wat de scantijd verkort.
Tegens - dit is het gebrek aan ondersteuning voor de vereiste talen.
Noodzakelijke integraties, die volgens mijn subjectieve mening in de tools zou moeten staan:
- Integratietool: Jenkins, TeamCity en Gitlab CI.
- Ontwikkelomgeving: Intellij IDEA, Visual Studio. Voor een ontwikkelaar is het handiger om niet in een onbegrijpelijke interface te kruipen die nog onthouden moet worden, maar om in zijn eigen ontwikkelomgeving direct alle noodzakelijke integraties en kwetsbaarheden te zien die hij op zijn werkplek heeft aangetroffen.
- Codebeoordeling: SonarQube en handmatige beoordeling.
- Defecttrackers: Jira en Bugzilla.
De afbeelding toont enkele van de beste vertegenwoordigers van statische analyse.
Het gaat niet om de tools, maar om het proces. Daarom zijn er Open Source-oplossingen die ook geschikt zijn om het proces te testen.
SAST Open Source zal niet veel kwetsbaarheden of complexe gegevensstromen ontdekken, maar het kan en moet wel worden gebruikt bij het bouwen van een proces. Ze helpen inzicht te krijgen in hoe het proces zal worden gestructureerd, wie op bugs zal reageren, wie ze zal rapporteren, en wie er zal rapporteren. Als u de eerste stap wilt zetten bij het inbouwen van beveiliging in uw code, gebruik dan Open Source-oplossingen.
Hoe kan dit geïntegreerd worden als je nog maar aan het begin van de reis staat en nog niets hebt: geen CI, geen Jenkins, geen TeamCity? Laten we de integratie in het proces eens bekijken.
Integratie op CVS-niveau
Als je Bitbucket of GitLab hebt, kun je integratie op het niveau doen .
Per evenement — pull-aanvraag, commit. U scant de code en in de buildstatus ziet u of de beveiligingscontrole is geslaagd of mislukt.
Feedback. Natuurlijk is feedback altijd nodig. Als je de beveiliging ernaast doet, het in een doos stopt en er verder met niemand over praat, en dan aan het eind van de maand een heleboel bugs dumpt, dan is dat niet juist en niet goed.
Integratie met codebeoordelingssysteem
We hadden ooit een technische gebruiker van AppSec als standaard reviewer voor een aantal belangrijke projecten. Afhankelijk van of er fouten in de nieuwe code zijn gevonden of dat er geen fouten zijn, zet de reviewer de status van de pull request op 'accepteren' of 'moet worden verbeterd'. Dit betekent dat alles in orde is of dat er verbetering nodig is. De reviewer koppelt vervolgens wat er precies verbeterd moet worden. We hadden een samenvoegingsverbod ingeschakeld voor integratie met de versie die in productie gaat als de informatiebeveiligingstest niet is geslaagd. We hebben dit opgenomen in de handmatige codebeoordeling en andere deelnemers aan het proces konden de beveiligingsstatussen voor dit specifieke proces zien.
Integratie met SonarQube
Veel mensen hebben het op basis van de kwaliteit van de code. Hier is het hetzelfde: je kunt dezelfde poorten maken, alleen dan voor SAST-gereedschappen. Er zal dezelfde interface zijn, dezelfde kwaliteitspoort, het zal alleen zo heten beveiligingspoort. En als u een proces hebt ingesteld met behulp van SonarQube, kunt u alles daar eenvoudig integreren.
Integratie op CI-niveau
Ook hier is alles vrij eenvoudig:
- Op gelijke voet met geautomatiseerde tests, eenheidstesten.
- Indeling in ontwikkelingsfasen:ontwikkeling, testen, produceren. Er kunnen verschillende sets regels of verschillende faalvoorwaarden worden ingeschakeld: stop de build, stop de build niet.
- Synchrone/asynchrone start. We wachten tot de veiligheidstesten zijn afgerond, of we wachten niet. Dat wil zeggen dat we ze gewoon lanceren en verdergaan, en dan krijgen we de status dat alles goed of slecht is.
Het is allemaal een perfecte, roze wereld. In het echte leven gebeurt dit niet, maar we streven er wel naar. De resultaten van het uitvoeren van beveiligingscontroles moeten vergelijkbaar zijn met de resultaten van unittests.
We hebben bijvoorbeeld een groot project genomen en besloten dat we het nu met SAST zouden scannen - OK. We hebben dit project naar SAST gestuurd, wat ons 20 kwetsbaarheden opleverde en we hebben de sterke beslissing genomen dat alles in orde was. 000 kwetsbaarheden vormen onze technische schuld. We stoppen de schuld in een doos, lossen deze langzaam op en voeren de bugs in defect trackers in. We huren een bedrijf in, doen het zelf of laten Security Champions ons helpen en de technische schuld zal afnemen.
En alle nieuwe kwetsbaarheden in nieuwe code moeten op dezelfde manier worden geëlimineerd als fouten in unit- of autotests. Grofweg gezegd werd de build gestart, uitgevoerd en mislukten twee tests en twee beveiligingstests. Oké, we zijn gaan kijken wat er gebeurd is, hebben één ding opgelost, een ander ding opgelost en hebben het de volgende keer opnieuw uitgevoerd. Alles is in orde, er zijn geen nieuwe kwetsbaarheden opgedoken en de tests zijn niet mislukt. Als de taak diepgaander is en grondiger moet worden begrepen, of als de oplossing voor de kwetsbaarheid grote delen van het probleem beïnvloedt, wordt een bug ingevoerd in de defect tracker, waarna deze prioriteit krijgt en wordt opgelost. Helaas is de wereld niet perfect en mislukken tests soms.
Een voorbeeld van een security gate is een analogie van een quality gate, wat betreft de aanwezigheid en het aantal kwetsbaarheden in de code.
Wij integreren met SonarQube: de plugin is geïnstalleerd en alles is heel handig en cool.
Integratie met de ontwikkelomgeving
Integratiemogelijkheden:
- Voer een scan uit vanuit de ontwikkelomgeving voordat u een commit uitvoert.
- Bekijk de resultaten.
- Analyse van resultaten.
- Synchronisatie met de server.
Dit is ongeveer hoe het eruitziet als u resultaten van de server ontvangt.
In onze ontwikkelomgeving Er verschijnt gewoon een extra item dat aangeeft dat dergelijke kwetsbaarheden tijdens het scannen zijn gedetecteerd. U kunt de code direct bewerken, aanbevelingen bekijken en . Dit alles bevindt zich op de werkplek van de ontwikkelaar, wat erg handig is: hij hoeft geen andere links te volgen en naar nog iets anders te kijken.
Open-Source
Dit is mijn favoriete onderwerp. Iedereen maakt gebruik van Open Source-bibliotheken. Waarom zou je alleen maar krukken en fietsen schrijven als je een kant-en-klare bibliotheek kunt gebruiken waarin alles al is geïmplementeerd?
Dat is natuurlijk waar, maar bibliotheken worden ook door mensen geschreven, ze brengen ook bepaalde risico's met zich mee en ze hebben ook kwetsbaarheden die periodiek, of zelfs voortdurend, worden gerapporteerd. Er is daarom een volgende stap in applicatiebeveiliging: de analyse van Open Source-componenten.
Open Source Analyse - OSA
De tool bestaat uit drie hoofdfasen.
Zoeken naar kwetsbaarheden in bibliotheken. De tool weet bijvoorbeeld dat we een bepaalde bibliotheek gebruiken, en dat in of er zijn enkele kwetsbaarheden in de bugtrackers die betrekking hebben op deze versie van de bibliotheek. Wanneer u het probeert te gebruiken, geeft de tool een waarschuwing dat de bibliotheek kwetsbaar is en adviseert u een andere versie te gebruiken die geen kwetsbaarheden heeft.
Analyse van de zuiverheid van de licentie. Het is hier nog niet erg populair, maar als u met het buitenland werkt, kunt u regelmatig een boete krijgen voor het gebruik van een open source-component die niet kan worden gebruikt of gewijzigd. Volgens het bibliotheeklicentiebeleid kunnen we dit niet doen. Of, als we het hebben aangepast en gebruiken, moeten we onze code posten. Natuurlijk wil niemand de code van zijn producten openbaar maken, maar je kunt jezelf hiertegen beschermen.
Analyse van componenten die in een industriële omgeving worden gebruikt. Stel je een hypothetische situatie voor waarin we de ontwikkeling eindelijk hebben afgerond en de nieuwste versie van onze microservice in productie hebben genomen. Hij woont daar fantastisch - een week, een maand, een jaar. Wij monteren het niet, wij voeren geen veiligheidscontroles uit, alles lijkt in orde. Maar plotseling, twee weken na de release, ontstaat er een kritieke kwetsbaarheid in het Open Source-onderdeel dat we in deze specifieke build gebruiken, in de productieomgeving. Als we niet vastleggen wat en waar we gebruiken, dan merken we dit beveiligingslek niet. Sommige tools hebben de mogelijkheid om kwetsbaarheden in bibliotheken die momenteel in de industrie worden gebruikt, te monitoren. Dit is erg nuttig.
kenmerken:
- Verschillende beleidsmaatregelen voor verschillende ontwikkelingsstadia.
- Componenten in een industriële omgeving bewaken.
- Controle over bibliotheken binnen de organisatie.
- Ondersteuning voor verschillende bouwsystemen en talen.
- Docker-afbeeldingsanalyse.
Voorbeelden van leiders in het vakgebied die zich bezighouden met Open Source-analyses.
De enige gratis is deze van OWASP. Je kunt het in de eerste fasen inschakelen, zien hoe het werkt en wat het ondersteunt. In principe zijn dit allemaal cloudproducten of on-premise-producten, maar de basis is nog steeds online. Ze sturen niet jouw bibliotheken, maar hashes of eigen berekende waarden en vingerafdrukken naar hun server om informatie te verkrijgen over de aanwezigheid van kwetsbaarheden.
Integratie in het proces
Monitoring van bibliotheken in de perimeter, die van externe bronnen worden gedownload. Wij hebben externe en interne opslagplaatsen. Zo is Nexus onderdeel van Event Central en willen we ervoor zorgen dat er zich in onze repository geen kwetsbaarheden met een kritieke of hoge status bevinden. U kunt proxying configureren met behulp van de Nexus Firewall Lifecycle-tool, zodat dergelijke kwetsbaarheden worden uitgefilterd en niet in de interne opslagplaats terechtkomen.
Integratie in CI. Op hetzelfde niveau als geautomatiseerde tests, unittests en de onderverdeling in ontwikkelingsfasen: dev, test, prod. In elke fase kunt u alle bibliotheken downloaden en alles gebruiken, maar als er iets mis is met de status "kritiek", is het wellicht de moeite waard om de ontwikkelaars hierop te attenderen tijdens de release-fase van de productie.
Integratie met artefacten: Nexus en JFrog.
Integratie in de ontwikkelomgeving. De tools die u kiest, moeten geïntegreerd zijn met ontwikkelomgevingen. De ontwikkelaar moet toegang hebben tot de scanresultaten op zijn werkplek, of de mogelijkheid hebben om de code te scannen en te controleren op kwetsbaarheden voordat hij overgaat op CVS.
CD-integratie. Dit is een leuke functie die ik erg waardeer en waar ik al eerder over heb gesproken: het monitoren van het ontstaan van nieuwe kwetsbaarheden in de industriële omgeving. Het werkt ongeveer zo:
Wij hebben Openbare componentrepositories — enkele hulpmiddelen extern en onze interne opslagplaats. Wij willen dat het alleen vertrouwde componenten bevat. Wanneer we een aanvraag proxyen, controleren we of de gedownloade bibliotheek geen kwetsbaarheden bevat. Indien het onder bepaalde beleidsregels valt die wij opstellen en noodzakelijkerwijs afstemmen op de ontwikkeling, dan uploaden we het niet en ontvangen we een afwijzing om een andere versie te gebruiken. Als er dus iets echt kritisch of slecht is in de bibliotheek, dan zal de ontwikkelaar de bibliotheek niet ontvangen bij de installatie. In plaats daarvan kan hij een hogere of lagere versie gebruiken.
- Tijdens de bouw controleren we of niemand iets verkeerds heeft meegenomen, of alle onderdelen veilig zijn en of niemand gevaarlijke dingen op een flashdrive heeft meegenomen.
- Er staan alleen vertrouwde componenten in onze repository.
- Bij de implementatie controleren we nogmaals het pakket zelf: war, jar, DL of Docker-image om er zeker van te zijn dat het voldoet aan het beleid.
- Wanneer we met de productie beginnen, houden we in de gaten wat er in de industriële omgeving gebeurt: of er kritieke kwetsbaarheden optreden of niet.
Dynamische analyse - DAST
Dynamische analysetools verschillen fundamenteel van alles wat hiervoor is gezegd. Dit is een soort imitatie van hoe de gebruiker met de applicatie werkt. Als het om een webapplicatie gaat, versturen we verzoeken, simuleren we het werk van de klant, klikken we op knoppen in de front-end, versturen we kunstmatige gegevens uit het formulier: aanhalingstekens, haakjes, tekens in verschillende coderingen, om te zien hoe de applicatie werkt en externe gegevens verwerkt.
Met hetzelfde systeem kunt u sjabloonkwetsbaarheden in Open Source controleren. Omdat DAST niet weet welke Open Source we gebruiken, genereert het simpelweg 'kwaadaardige' patronen en analyseert het de serverreacties:
- Ja, er is hier sprake van een deserialisatieprobleem, maar hier niet.
Dit brengt grote risico's met zich mee, want als je de beveiligingstest uitvoert op dezelfde standaard als waar de testers mee bezig zijn, kunnen er vervelende situaties ontstaan.
- Hoge belasting van het applicatieservernetwerk.
- Geen integraties.
- Mogelijkheid om de instellingen van de geanalyseerde applicatie te wijzigen.
- Er is geen ondersteuning voor de vereiste technologieën.
- Complexiteit van de installatie.
Toen we AppScan eindelijk lanceerden, zaten we in een situatie: we hebben lang geprobeerd toegang te krijgen tot de applicatie, kregen 3 accounts en waren tevreden - eindelijk gaan we alles controleren! We hebben een scan gestart en het eerste wat AppScan deed was in het admin-paneel komen, alle knoppen aanzetten, de helft van de gegevens veranderen en vervolgens de server volledig uitschakelen met zijn -verzoeken. Ontwikkeling met testen zei:
- Jongens, maken jullie een grapje?! Wij gaven je de registratiedocumenten en jij zette de stand op!
Denk na over de mogelijke risico's. Idealiter bereidt u een aparte stand voor voor het testen van de informatiebeveiliging, die op de een of andere manier geïsoleerd is van de rest van de omgeving. Ook is het raadzaam om het admin-paneel handmatig en onder voorwaarden te controleren. Dit is pentesting: de resterende percentages van inspanningen waar we nu niet naar kijken.
Het is de moeite waard om te overwegen dat dit gebruikt kan worden als een analoog voor belastingstesten. In de eerste fase kun je een dynamische scanner in 10-15 streams inschakelen en kijken wat er gebeurt. Meestal, zoals de praktijk leert, levert dit echter niets goeds op.
Enkele bronnen die wij vaak gebruiken.
Het is de moeite waard om te benadrukken — is een “Zwitsers zakmes” voor elke beveiligingsspecialist. Iedereen gebruikt het en het is heel handig. Er is nu een nieuwe demoversie van de Enterprise-editie uitgebracht. Vroeger was het alleen een zelfstandig hulpprogramma met plug-ins, maar nu maken de ontwikkelaars eindelijk een grote server waarmee meerdere agents beheerd kunnen worden. Dat is cool, ik raad je aan het te proberen.
Integratie in het proces
De integratie is vrij goed en eenvoudig: Start met scannen na succesvolle installatie toepassingen voor de stand en scannen na succesvolle integratietesten.
Als integraties niet werken of als er stubs en mock-functies zijn, is het zinloos en nutteloos: ongeacht welk patroon we sturen, de server zal nog steeds op dezelfde manier reageren.
- Idealiter een aparte testbank.
- Noteer de inlogvolgorde voordat u begint met testen.
- Het testen van het administratiesysteem gebeurt uitsluitend handmatig.
Процесс
Een kleine generalisatie over het proces in het algemeen en over de werking van elke tool in het bijzonder. Alle toepassingen zijn anders - de ene werkt beter met dynamische analyse, een andere met statische analyse, een derde met OpenSource-analyse, pentests of iets heel anders, bijvoorbeeld gebeurtenissen met .
Elk proces heeft controle nodig.
Om te begrijpen hoe een proces werkt en waar het verbeterd kan worden, moet u gegevens verzamelen uit alles wat u maar kunt vinden, waaronder productiegegevens, gereedschapsgegevens en defecttrackers.
Alle gegevens zijn nuttig. Het is noodzakelijk om naar verschillende aspecten te kijken om te zien waar dit of dat hulpmiddel het beste kan worden ingezet en waar het proces specifiek tekortschiet. Het kan zinvol zijn om naar de reactietijden van ontwikkelingen te kijken om te zien waar het tijdgebaseerde proces verbeterd kan worden. Hoe meer gegevens, hoe beter we van de hoofdlijnen tot de details van elk proces kunnen doordringen.
Omdat alle statische en dynamische analysers hun eigen API, hun eigen startmethoden en principes hebben, hebben sommige schedulers, andere niet – schrijven we een tool AppSec Orchestrator, waarmee u één toegangspunt voor het gehele proces van een product kunt creëren en het vanaf één punt kunt beheren.
Managers, ontwikkelaars en beveiligingstechnici hebben één toegangspunt van waaruit ze kunnen zien wat er wordt uitgevoerd, scans kunnen configureren en uitvoeren, scanresultaten kunnen ophalen en vereisten kunnen indienen. We proberen af te stappen van papier en alles om te zetten in een menselijke taal die door de ontwikkeling wordt gebruikt: pagina's op Confluence met status en statistieken, defecten in Jira of in verschillende defect trackers, of integratie in een synchroon/asynchroon proces in CI/CD.
Key Takeaways
Gereedschap is niet het belangrijkste. Denk eerst goed na over het proces en implementeer daarna de hulpmiddelen. De tools zijn goed, maar duur. Het is daarom verstandig om met het proces te beginnen en de interactie en het begrip tussen de ontwikkelaars en de beveiligingsmedewerkers te vergroten. Vanuit veiligheidsoogpunt is er geen noodzaak om alles te ‘stoppen’. Vanuit het ontwikkelingsperspectief geldt: als er iets heel mega superkritisch is, dan moet het worden opgelost. We mogen de ogen niet sluiten voor het probleem.
Productkwaliteit - gemeenschappelijk doel zowel veiligheid als ontwikkeling. We doen één ding: we zorgen ervoor dat alles goed werkt en dat er geen reputatieschade of financiële verliezen ontstaan. Daarom promoten wij de DevSecOps- en SecDevOps-aanpak om de communicatie te verbeteren en het product te verbeteren.
Begin met wat je al hebt: vereisten, architectuur, deeltesten, trainingen, richtlijnen. Het is niet nodig om alle werkwijzen tegelijk op alle projecten toe te passen - iteratief bewegen. Er is geen enkele standaard - experiment en probeer verschillende benaderingen en oplossingen.
Er is een gelijk teken tussen gebreken in de informatiebeveiliging en functionele gebreken..
Automatiseer alles, dat beweegt. Alles wat niet beweegt, beweegt en automatiseert. Als iets met de hand wordt gedaan, is dat geen goed onderdeel van het proces. Misschien is het de moeite waard om het te herzien en ook te automatiseren.
Als de omvang van het informatiebeveiligingsteam klein is - Maak gebruik van Security Champions.
Misschien bevalt wat ik u verteld heb u niet en bedenkt u zelf wel iets - en dat is goed. Maar kies tools op basis van de vereisten van uw proces. Kijk niet naar wat de community zegt, dat deze tool slecht is en deze goed. Het kan zijn dat voor uw product het tegenovergestelde geldt.
Vereisten voor gereedschap.
- Laag aantal fout-positieve resultaten.
- Voldoende analysetijd.
- Gebruiksgemak.
- Beschikbaarheid van integraties.
- Inzicht in de productontwikkelingsroutekaart.
- Mogelijkheid tot aanpassing van gereedschappen.
De lezing van Yuri werd gekozen als een van de beste op DevOpsConf 2018. Om kennis te maken met nog meer interessante ideeën en praktijkvoorbeelden, kom op 27 en 28 mei naar Skolkovo om binnen het kader . En nog beter, als je bereid bent om je ervaring te delen, dan voor een rapport vóór 21 april.
Bron: www.habr.com
