We hadden 2 code-analyzers, 4 dynamische testtools, onze eigen ambachten en 250 scripts. Het is niet zo dat dit allemaal nodig is in het huidige proces, maar zodra je begint met het implementeren van DevSecOps, moet je tot het einde gaan.
. Karaktermakers: 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? Weet het antwoord op al deze vragen Yuri Shabalin van Zwaardvis beveiliging. Yuri zal alles in detail beantwoorden en de problemen analyseren van de overgang van het klassieke Application Security-model naar het DevSecOps-proces: hoe de integratie van het veilige ontwikkelingsproces in het DevOps-proces op de juiste manier te benaderen en niets kapot te maken, hoe de belangrijkste fasen te doorlopen van beveiligingstests, welke tools kunnen worden gebruikt, wat ze verschillen en hoe ze correct kunnen worden geconfigureerd om valkuilen te voorkomen.
Over de spreker: Joeri Shabalin - Chief Security Architect van het bedrijf Zwaardvis beveiliging. Verantwoordelijk voor de implementatie van SSDL, voor de algehele integratie van applicatieanalysetools in een verenigd ontwikkel- en testecosysteem. 7 jaar ervaring in informatiebeveiliging. Werkte bij Alfa-Bank, Sberbank en Positive Technologies, dat software ontwikkelt en diensten levert. Spreker op internationale conferenties ZerONights, PHDays, RISSPA, OWASP.
Applicatiebeveiliging: waar gaat het over?
Applicatiebeveiliging - Dit is de beveiligingssectie die verantwoordelijk is voor de beveiliging van de applicatie. Dit geldt niet voor de infrastructuur of netwerkbeveiliging, maar eerder voor wat we schrijven en waar ontwikkelaars aan werken - dit zijn de tekortkomingen en kwetsbaarheden van de applicatie zelf.
richting - Levenscyclus van beveiligingsontwikkeling - ontwikkeld door Microsoft. Het diagram toont het canonieke SDLC-model, waarvan de hoofdtaak de deelname van beveiliging in elke ontwikkelingsfase is, van vereisten tot release en productie. Microsoft realiseerde zich dat er te veel bugs in de branche waren, er waren er meer en er moest iets aan gedaan worden, en zij stelden deze aanpak voor, die canoniek is geworden.
Application Security en SSDL zijn niet gericht op het detecteren van kwetsbaarheden, zoals vaak wordt aangenomen, maar op het voorkomen ervan. In de loop van de tijd is de canonieke benadering van Microsoft verbeterd, ontwikkeld en geïntroduceerd in een diepere, meer gedetailleerde duik.
De canonieke SDLC is zeer gedetailleerd in verschillende methodologieën: OpenSAMM, BSIMM, OWASP. De methodieken zijn verschillend, maar over het algemeen vergelijkbaar.
Beveiliging opbouwen in het volwassenheidsmodel
Ik vind het het leukst BSIMM - . De basis van de methodiek is de opdeling van het Applicatiebeveiligingsproces in 4 domeinen: Governance, Intelligence, SSDL Touchpoints en Deployment. Elk domein kent 12 praktijken, die worden weergegeven als 112 activiteiten.
Elk van de 112 activiteiten heeft 3 niveaus van volwassenheid: beginner, gemiddeld en gevorderd. Je kunt alle twaalf praktijken sectie voor sectie bestuderen, dingen selecteren die voor jou belangrijk zijn, uitzoeken hoe je ze kunt implementeren en geleidelijk elementen toevoegen, bijvoorbeeld statische en dynamische codeanalyse of codebeoordeling. Je schrijft een plan op en werkt hier rustig naar toe als onderdeel van de uitvoering van de geselecteerde activiteiten.
Waarom DevSecOps
DevOps is een algemeen, groot proces waarbij rekening gehouden moet worden met veiligheid.
Eerste veiligheidscontroles betrokken. In de praktijk was het aantal beveiligingsteams veel kleiner dan nu en fungeerden zij niet als deelnemers aan het proces, maar als controle- en toezichthoudend orgaan dat daaraan eisen stelt en aan het eind van de release de kwaliteit van het product controleert. Dit is een klassieke aanpak waarbij beveiligingsteams tijdens de ontwikkeling achter de muur stonden en niet aan het proces deelnamen.
Het grootste probleem is dat informatiebeveiliging los staat van ontwikkeling. Meestal is dit een soort informatiebeveiligingscircuit en bevat het 2-3 grote en dure tools. Eén keer per half jaar komt de te controleren broncode of applicatie binnen en één keer per jaar wordt deze geproduceerd . Dit alles leidt ertoe dat de releasedatum voor de branche wordt uitgesteld en dat de ontwikkelaar wordt blootgesteld aan 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 niet zijn uitgezocht, maar hier is een nieuwe batch.
In de loop van het werk van ons bedrijf zien we dat de beveiliging in alle gebieden en sectoren begrijpt dat het tijd is om de achterstand in te halen en de ontwikkeling op hetzelfde wiel te laten draaien – in . Het DevSecOps-paradigma sluit perfect aan bij de agile ontwikkelmethodologie, implementatie, ondersteuning en deelname aan elke release en iteratie.
Overgang naar DevSecOps
Het belangrijkste woord in de levenscyclus van beveiligingsontwikkeling is "proces". U moet dit begrijpen voordat u nadenkt over het kopen van gereedschap.
Het simpelweg opnemen van tools in het DevOps-proces is niet voldoende; communicatie en begrip tussen procesdeelnemers is belangrijk.
Mensen zijn belangrijker, geen hulpmiddelen.
Vaak begint de planning voor een veilig ontwikkelingsproces met het kiezen en aanschaffen van een tool, en eindigt met pogingen om de tool in het huidige proces te integreren, wat pogingen blijven. Dit leidt tot ongelukkige gevolgen, omdat alle tools hun eigen kenmerken en beperkingen hebben.
Een veelvoorkomend geval is dat de beveiligingsafdeling een goede, dure tool met brede mogelijkheden koos en naar de ontwikkelaars kwam om deze in het proces te integreren. Maar het werkt niet: het proces is zo gestructureerd dat de beperkingen van de reeds aangeschafte tool niet passen in het huidige paradigma.
Beschrijf eerst welk resultaat u wilt en hoe het proces eruit zal zien. Dit zal helpen de rol van gereedschap en veiligheid in het proces te begrijpen.
Begin met wat al in gebruik is
Kijk voordat je dure gereedschappen aanschaft wat je al hebt. Elk bedrijf heeft veiligheidseisen voor ontwikkeling, er zijn controles, pentests - waarom zou u dit niet allemaal omzetten in een vorm die voor iedereen begrijpelijk en handig is?
Meestal zijn de vereisten een papieren Talmoed die op een plank ligt. Er was een geval waarin we bij een bedrijf naar de processen kwamen kijken en vroegen naar de beveiligingsvereisten voor de software. De specialist die zich hiermee bezighield heeft lang gezocht naar:
- Ergens in de aantekeningen stond een pad waar dit document zich bevindt.
Als gevolg daarvan ontvingen wij het document een week later.
Voor eisen, controles en andere zaken maakt u een pagina aan op b.v. samenvloeiing - het is handig voor iedereen.
Het is gemakkelijker om wat u al heeft opnieuw te formatteren en het te gebruiken om aan de slag te gaan.
Gebruik Beveiligingskampioenen
In een gemiddeld bedrijf met 100-200 ontwikkelaars is er doorgaans één beveiligingsspecialist die verschillende functies vervult en fysiek geen tijd heeft om alles te controleren. Zelfs als hij zijn best doet, zal hij alleen 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 veiligheid van uw product.
Security Champion is een toegangspunt tot het ontwikkelteam en een beveiligingsevangelist in één.
Wanneer een beveiligingsspecialist naar een ontwikkelteam komt en wijst op een fout in de code, krijgt hij meestal een verrast antwoord:
- En wie ben jij? Ik zie je voor de eerste keer. Met mij gaat alles goed - mijn senior vriend gaf me 'solliciteren' bij de codebeoordeling, we gaan verder!
Dit is een typische situatie, omdat er veel meer vertrouwen is in senioren of gewoon teamgenoten met wie de ontwikkelaar voortdurend communiceert op het werk en bij het beoordelen van code. Als, in plaats van de veiligheidsagent, de Veiligheidskampioen wijst op de fout en de gevolgen, zal zijn woord zwaarder wegen.
Bovendien kennen ontwikkelaars hun code beter dan welke beveiligingsspecialist dan ook. Voor iemand die minstens vijf projecten in een statische analysetool heeft, is het meestal moeilijk om alle nuances te onthouden. Beveiligingskampioenen kennen hun product: wat met wat in wisselwerking staat en waar ze eerst naar moeten kijken - ze zijn effectiever.
Overweeg dus om Security Champions te implementeren en de invloed van uw beveiligingsteam uit te breiden. Dit is ook nuttig voor de kampioen zelf: professionele ontwikkeling op een nieuw gebied, zijn technische horizon verbreden, technische, management- en leiderschapsvaardigheden verbeteren, de marktwaarde vergroten. Dit is een onderdeel van social engineering, jouw ‘ogen’ in het ontwikkelteam.
Fasen testen
stelt dat 20% van de inspanning 80% van de resultaten oplevert. Deze 20% bestaat uit applicatieanalysepraktijken die kunnen en moeten worden geautomatiseerd. Voorbeelden van dergelijke activiteiten zijn statische analyse - SAST, dynamische analyse - DAST и Open Source-controle. Ik zal je meer in detail vertellen over de activiteiten, maar ook over de tools, welke functies we meestal tegenkomen als we ze in het proces introduceren, en hoe we dit op de juiste manier kunnen doen.
Belangrijkste problemen van gereedschappen
Ik belicht problemen die voor alle instrumenten relevant zijn en aandacht behoeven. Ik zal ze in meer detail analyseren om ze niet verder te herhalen.
Lange analysetijd. Als het van commit tot release 30 minuten duurt voor alle tests en assemblage, dan zullen informatiebeveiligingscontroles een dag duren. Niemand zal het proces dus vertragen. Houd rekening met deze functie en trek conclusies.
Hoog niveau Vals negatief of Vals positief. Alle producten zijn verschillend, gebruiken allemaal verschillende frameworks en hun eigen codeerstijl. Op verschillende codebases en technologieën kunnen tools verschillende niveaus van fout-negatief en fout-positief weergeven. Kijk dus goed wat er precies in zit uw bedrijven en voor uw toepassingen zullen goede en betrouwbare resultaten opleveren.
Geen integraties met bestaande tools. Kijk naar tools in termen van integraties met wat je al gebruikt. Als je bijvoorbeeld Jenkins of TeamCity hebt, controleer dan de integratie van de tools met deze software, en niet met GitLab CI, die je niet gebruikt.
Gebrek aan of buitensporige complexiteit van maatwerk. Als een tool geen API heeft, waarom is deze dan nodig? Alles wat in de interface kan worden gedaan, moet beschikbaar zijn via de API. Idealiter zou de tool de mogelijkheid moeten hebben om cheques aan te passen.
Geen routekaart voor productontwikkeling. De ontwikkeling staat niet stil, we gebruiken altijd nieuwe raamwerken en functies en herschrijven oude code in nieuwe talen. We willen er zeker van zijn dat de tool die we kopen nieuwe raamwerken en technologieën zal ondersteunen. Daarom is het belangrijk om te weten dat het product echt en correct is ontwikkeling.
Proces functies
Houd naast de kenmerken van de tools rekening met de kenmerken van het ontwikkelingsproces. Het belemmeren van de ontwikkeling is bijvoorbeeld een veelgemaakte fout. Laten we eens kijken met welke andere functies rekening moet worden gehouden en waar het beveiligingsteam op moet letten.
Om de ontwikkelings- en releasedeadlines niet te missen, creëert u verschillende regels en anders toonstoppers — criteria voor het stoppen van het bouwproces in geval van kwetsbaarheden — voor verschillende omgevingen. We begrijpen bijvoorbeeld dat de huidige vestiging naar de ontwikkelingsstand of UAT gaat, wat betekent dat we niet stoppen en zeggen:
“Je hebt hier kwetsbaarheden, verder kom je niet!”
Op dit punt is het belangrijk om ontwikkelaars te vertellen dat er beveiligingsproblemen zijn die aandacht behoeven.
De aanwezigheid van kwetsbaarheden vormt geen belemmering voor verder testen: handmatig, integratie of handmatig. Aan de andere kant moeten we op de een of andere manier de veiligheid van het product vergroten, zodat ontwikkelaars niet verwaarlozen wat zij veilig vinden. Daarom doen we dit soms: op de stand, als het uitgerold wordt naar de ontwikkelomgeving, melden we simpelweg de ontwikkeling:
- Jongens, jullie hebben problemen, let daar alsjeblieft op.
In de UAT-fase laten we opnieuw waarschuwingen zien over kwetsbaarheden, en in de releasefase zeggen we:
- Jongens, we hebben jullie meerdere keren gewaarschuwd, jullie hebben niets gedaan - we laten jullie hiermee niet vrij.
Als we het hebben over code en dynamiek, dan is het noodzakelijk om alleen kwetsbaarheden van die functies en code te tonen en te waarschuwen voor die functies en code die zojuist in deze functie is geschreven. Als een ontwikkelaar een knop 3 pixels verplaatst en wij hem vertellen dat hij daar een SQL-injectie heeft en daarom dringend gerepareerd moet worden, dan is dit fout. Kijk alleen naar wat er nu geschreven staat en naar de verandering die in de applicatie komt.
Laten we zeggen dat we een bepaald functioneel defect hebben: de manier waarop de applicatie niet zou moeten werken: er wordt geen geld overgemaakt, als je op een knop klikt, is er geen overgang naar de volgende pagina, of het product laadt niet. Beveiligingsdefecten - dit zijn dezelfde gebreken, maar niet in termen van de werking van de applicatie, maar in de beveiliging.
Niet alle softwarekwaliteitsproblemen zijn beveiligingsproblemen. Maar alle beveiligingsproblemen houden verband met de kwaliteit van de software. Sherif Mansour, Expedia.
Omdat alle kwetsbaarheden dezelfde defecten zijn, moeten ze zich op dezelfde plaats bevinden als alle ontwikkelingsfouten. Vergeet dus rapporten en enge pdf's die niemand leest.
Toen ik bij een ontwikkelingsbedrijf werkte, ontving ik een rapport van statische analysetools. Ik opende het, was geschokt, zette koffie, bladerde door 350 pagina's, sloot het en ging door met werken. Grote rapporten zijn dode rapporten. Meestal gaan ze nergens heen, worden de brieven verwijderd, vergeten, verloren of zegt het bedrijf de risico's te accepteren.
Wat moeten we doen? De bevestigde defecten die we tegenkomen, zetten we eenvoudig om in een vorm die handig is voor ontwikkeling, we plaatsen ze bijvoorbeeld in een backlog in Jira. We geven prioriteit aan defecten en elimineren deze in volgorde van prioriteit, samen met functionele defecten en testdefecten.
Statische analyse - SAST
Dit is een codeanalyse op kwetsbaarheden., maar het is niet hetzelfde als SonarQube. We controleren niet alleen op patronen of stijl. Bij de analyse worden een aantal benaderingen gebruikt: volgens de kwetsbaarheidsboom, volgens , door configuratiebestanden te analyseren. Dit is alles wat de code zelf betreft.
Voordelen van de aanpak: het identificeren van kwetsbaarheden in code in een vroeg ontwikkelingsstadiumals er nog geen standaards of kant-en-klaar gereedschap is, en incrementele scanmogelijkheden: het scannen van een codegedeelte dat is gewijzigd, en alleen de functie die we momenteel gebruiken, waardoor de scantijd wordt verkort.
Tegens - dit is het gebrek aan ondersteuning voor de noodzakelijke talen.
Noodzakelijke integraties, wat naar mijn subjectieve mening in de tools zou moeten zitten:
- Integratietool: Jenkins, TeamCity en Gitlab CI.
- Ontwikkelomgeving: Intellij IDEA, Visual Studio. Het is handiger voor een ontwikkelaar om niet door een onbegrijpelijke interface te navigeren die nog moet worden gememoriseerd, maar om alle noodzakelijke integraties en kwetsbaarheden die hij heeft gevonden direct op de werkplek in zijn eigen ontwikkelomgeving te zien.
- Codebeoordeling: SonarQube en handmatige beoordeling.
- Defecte trackers: Jira en Bugzilla.
De afbeelding toont enkele van de beste vertegenwoordigers van statische analyse.
Niet de tools zijn belangrijk, maar het proces, dus er zijn Open Source-oplossingen die ook goed zijn om het proces te testen.
SAST Open Source zal geen enorm aantal kwetsbaarheden of complexe DataFlows vinden, maar ze kunnen en moeten worden gebruikt bij het bouwen van een proces. Ze helpen begrijpen hoe het proces zal worden opgebouwd, wie zal reageren op bugs, wie zal rapporteren en wie zal rapporteren. Als u de eerste fase van het opbouwen van de beveiliging van uw code wilt uitvoeren, gebruik dan Open Source-oplossingen.
Hoe kan dit worden geïntegreerd als je aan het begin van je reis staat en niets hebt: geen CI, geen Jenkins, geen TeamCity? Laten we eens kijken naar de integratie in het proces.
Integratie op CVS-niveau
Als je Bitbucket of GitLab hebt, kun je op niveau integreren .
Per gebeurtenis - pull-verzoek, commit. Je scant de code en de buildstatus laat zien of de veiligheidscontrole is geslaagd of mislukt.
Feedback. Uiteraard is feedback altijd nodig. Als je gewoon de beveiliging ernaast hebt gedaan, het in een doos hebt gestopt en er niemand iets over hebt verteld, en aan het einde van de maand een aantal bugs hebt gedumpt - dit is niet correct en niet goed.
Integratie met het codebeoordelingssysteem
Ooit traden we op als standaardreviewer voor een technische AppSec-gebruiker bij een aantal belangrijke projecten. Afhankelijk van of er fouten in de nieuwe code worden geïdentificeerd of dat er geen fouten zijn, stelt de reviewer de status van het pull-verzoek in op "accepteren" of "werk nodig" - alles is in orde, of de links naar wat er precies moet worden verbeterd moeten worden verbeterd. Voor integratie met de versie die in productie gaat, hebben we een samenvoegverbod ingeschakeld als de informatiebeveiligingstest niet wordt doorstaan. We hebben dit opgenomen in de handmatige codebeoordeling en andere deelnemers aan het proces hebben de beveiligingsstatussen voor dit specifieke proces gezien.
Integratie met SonarQube
Velen hebben dat gedaan op het gebied van codekwaliteit. Het is hier hetzelfde: je kunt dezelfde poorten alleen voor SAST-tools maken. Er zal dezelfde interface zijn, dezelfde kwaliteitspoort, alleen deze zal worden aangeroepen veiligheidspoort. En als u een proces heeft dat SonarQube gebruikt, kunt u alles daar eenvoudig integreren.
Integratie op CI-niveau
Alles is hier ook vrij eenvoudig:
- Vergelijkbaar met autotests, eenheidstests.
- Indeling naar ontwikkelingsfasen: ontwikkelaar, test, prod. Er kunnen verschillende sets regels of verschillende faalvoorwaarden zijn opgenomen: stop de montage, stop de montage niet.
- Synchrone/asynchrone lancering. We wachten op het einde van de beveiligingstests of niet. Dat wil zeggen, we hebben ze gewoon gelanceerd en gaan verder, en dan krijgen we de status dat alles goed of slecht is.
Het bevindt zich allemaal in een perfecte roze wereld. In het echte leven bestaat zoiets niet, maar we streven ernaar. Het resultaat van het uitvoeren van veiligheidscontroles moet vergelijkbaar zijn met de resultaten van unit-tests.
We hebben bijvoorbeeld een groot project genomen en besloten dat we het nu zullen scannen met SAST - OK. We hebben dit project in SAST gepusht, het leverde ons 20 kwetsbaarheden op en door een wilskrachtige beslissing besloten we dat alles in orde was. 000 kwetsbaarheden vormen onze technische schuld. We stoppen de schulden in een doos, we ruimen ze langzaam op en voegen bugs toe aan de trackers van defecten. Laten we een bedrijf inhuren, alles zelf doen, of Security Champions ons laten helpen - en de technische schulden zullen afnemen.
En alle nieuw opkomende kwetsbaarheden in de nieuwe code moeten op dezelfde manier worden geëlimineerd als fouten in een unit of in autotests. Relatief gezien begon de montage, we voerden deze uit, twee tests en twee beveiligingstests mislukten. Oké - we gingen, keken wat er gebeurde, repareerden het ene, repareerden het andere en voerden het de volgende keer uit - alles was in orde, er verschenen geen nieuwe kwetsbaarheden, geen enkele test mislukte. Als deze taak dieper gaat en je deze goed moet begrijpen, of als het oplossen van kwetsbaarheden grote lagen van wat er onder de motorkap ligt beïnvloedt: er is een bug toegevoegd aan de defecttracker, deze wordt geprioriteerd en gecorrigeerd. Helaas is de wereld niet perfect en mislukken tests soms.
Een voorbeeld van een beveiligingspoort is een analoog van een kwaliteitspoort, in termen van de aanwezigheid en het aantal kwetsbaarheden in de code.
We integreren met SonarQube - de plug-in is geïnstalleerd, alles is erg handig en cool.
Integratie met ontwikkelomgeving
Integratie opties:
- Voer een scan uit vanuit de ontwikkelomgeving voordat u een commit uitvoert.
- Bekijk resultaten.
- Analyse van resultaten.
- Synchronisatie met de server.
Zo ziet het eruit om resultaten van de server te ontvangen.
In onze ontwikkelomgeving er verschijnt eenvoudigweg een extra item dat u informeert dat dergelijke kwetsbaarheden tijdens de scan zijn gedetecteerd. U kunt de code onmiddellijk bewerken, aanbevelingen bekijken en . Dit bevindt zich allemaal op de werkplek van de ontwikkelaar, wat erg handig is: het is niet nodig om andere links te volgen en naar iets extra's te kijken.
Open Source
Dit is mijn favoriete onderwerp. Iedereen gebruikt Open Source-bibliotheken - waarom zou je een hoop krukken en fietsen schrijven als je een kant-en-klare bibliotheek kunt nemen waarin alles al is geïmplementeerd?
Natuurlijk is dat zo, maar bibliotheken zijn ook door mensen geschreven, ze brengen ook bepaalde risico's met zich mee en er zijn ook kwetsbaarheden die periodiek of voortdurend worden gerapporteerd. Daarom is er de volgende stap in Applicatiebeveiliging: dit is de analyse van Open Source-componenten.
Open source-analyse - OSA
De tool omvat drie grote fasen.
Zoeken naar kwetsbaarheden in bibliotheken. De tool weet bijvoorbeeld dat we een bibliotheek gebruiken, en dat in of er zijn enkele kwetsbaarheden in 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 bevat.
Analyse van de zuiverheid van licenties. Dit is hier nog niet bijzonder populair, maar als je in het buitenland werkt, kun je daar van tijd tot tijd belasting krijgen voor het gebruik van een open source-component die niet kan worden gebruikt of aangepast. Volgens het beleid van de gelicentieerde bibliotheek kunnen we dit niet doen. Of, als we het hebben aangepast en gebruikt, moeten we onze code posten. Natuurlijk wil niemand de code van hun producten publiceren, maar je kunt jezelf hier ook tegen beschermen.
Analyse van componenten die worden gebruikt in een industriële omgeving. Laten we ons een hypothetische situatie voorstellen waarin we eindelijk de ontwikkeling hebben voltooid en de nieuwste release van onze microservice hebben uitgebracht. Hij woont daar geweldig - een week, een maand, een jaar. We verzamelen het niet, we voeren geen veiligheidscontroles uit, alles lijkt in orde te zijn. Maar plotseling, twee weken na de release, verschijnt er een kritieke kwetsbaarheid in de Open Source-component, die we in deze specifieke build gebruiken, in de industriële omgeving. Als we niet vastleggen wat en waar we gebruiken, zien we deze kwetsbaarheid simpelweg niet. Sommige tools hebben de mogelijkheid om kwetsbaarheden te monitoren in bibliotheken die momenteel in de branche worden gebruikt. Het is heel handig.
kenmerken:
- Verschillende beleidsmaatregelen voor verschillende ontwikkelingsstadia.
- Bewaking van componenten in een industriële omgeving.
- Controle over bibliotheken binnen de organisatie.
- Ondersteuning voor verschillende bouwsystemen en talen.
- Analyse van Docker-images.
Een paar voorbeelden van marktleiders die zich bezighouden met Open Source-analyse.
De enige gratis is deze van OWASP. Je kunt het in de eerste fasen inschakelen, kijken hoe het werkt en wat het ondersteunt. In principe zijn dit allemaal cloudproducten, of on-premise, maar achter hun basis worden ze nog steeds naar internet gestuurd. Ze sturen niet uw bibliotheken, maar hashes of hun eigen waarden, die ze berekenen, en vingerafdrukken naar hun server om informatie te ontvangen over de aanwezigheid van kwetsbaarheden.
Procesintegratie
Perimetercontrole van bibliotheken, die worden gedownload van externe bronnen. We hebben externe en interne opslagplaatsen. Event Central draait bijvoorbeeld Nexus, en we willen er zeker van zijn dat er binnen onze repository geen kwetsbaarheden voorkomen met een ‘kritieke’ of ‘hoge’ status. U kunt proxying configureren met behulp van de Nexus Firewall Lifecycle-tool, zodat dergelijke kwetsbaarheden worden afgesneden en niet in de interne repository terechtkomen.
Integratie in CI. Op hetzelfde niveau met autotests, unit-tests en indeling in ontwikkelingsfasen: dev, test, prod. In elke fase kun je alle bibliotheken downloaden en alles gebruiken, maar als er iets moeilijks is met de status 'kritiek', is het misschien de moeite waard om de aandacht van ontwikkelaars hierop te vestigen in de fase van release en 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 vanaf zijn werkplek toegang hebben tot de scanresultaten, of de mogelijkheid hebben om de code zelf te scannen en te controleren op kwetsbaarheden voordat hij tot CVS overgaat.
CD-integratie. Dit is een coole functie die ik erg leuk vind en waar ik het al over heb gehad: het monitoren van de opkomst van nieuwe kwetsbaarheden in een industriële omgeving. Het werkt ongeveer zo.
We hebben Opslagplaatsen voor openbare componenten – enkele tools buiten ons, en onze interne repository. We willen dat het alleen vertrouwde componenten bevat. Bij het proxyen van een verzoek controleren we of de gedownloade bibliotheek geen kwetsbaarheden bevat. Als het onder bepaald beleid valt dat we hebben opgesteld en noodzakelijkerwijs coördineren met de ontwikkeling, dan uploaden we het niet en worden we gevraagd een andere versie te gebruiken. Dienovereenkomstig, als er iets heel kritisch en slecht in de bibliotheek zit, zal de ontwikkelaar de bibliotheek niet ontvangen in de installatiefase - laat hem een hogere of lagere versie gebruiken.
- Bij het bouwen controleren we of niemand iets ergs heeft laten glijden, of alle componenten veilig zijn en niemand iets gevaarlijks op de flashdrive heeft gebracht.
- We hebben alleen vertrouwde componenten in de repository.
- Bij de implementatie controleren we nogmaals het pakket zelf: war, jar, DL of Docker-image om er zeker van te zijn dat het aan het beleid voldoet.
- Wanneer we de industrie betreden, houden we in de gaten wat er in de industriële omgeving gebeurt: kritieke kwetsbaarheden verschijnen of verschijnen niet.
Dynamische analyse - DAST
Dynamische analysetools zijn fundamenteel anders dan alles wat eerder is gezegd. Dit is een soort imitatie van het werk van de gebruiker met de applicatie. Als dit een webapplicatie is, sturen we verzoeken, simuleren het werk van de klant, klikken op de knoppen aan de voorkant, sturen kunstmatige gegevens uit het formulier: aanhalingstekens, haakjes, tekens in verschillende coderingen, om te zien hoe de applicatie werkt en verwerkt externe gegevens.
Met hetzelfde systeem kunt u kwetsbaarheden in sjablonen in Open Source controleren. Omdat DAST niet weet welke Open Source we gebruiken, genereert het eenvoudigweg “kwaadaardige” patronen en analyseert het de reacties van de server:
- Ja, er is hier een deserialisatieprobleem, maar niet hier.
Hier zitten grote risico’s aan, want als je deze beveiligingstest uitvoert op dezelfde bank waar de testers mee werken, kunnen er vervelende dingen gebeuren.
- Hoge belasting van het applicatieservernetwerk.
- Geen integraties.
- Mogelijkheid om de instellingen van de geanalyseerde applicatie te wijzigen.
- Er is geen ondersteuning voor de noodzakelijke technologieën.
- Moeilijkheid bij het opzetten.
We hadden een situatie toen we AppScan eindelijk lanceerden: we hebben lang geprobeerd toegang te krijgen tot de applicatie, hadden drie accounts en waren blij - we zullen eindelijk alles controleren! We lanceerden een scan en het eerste wat AppScan deed was naar het beheerderspaneel gaan, alle knoppen doorprikken, de helft van de gegevens wijzigen en vervolgens de server volledig afsluiten met zijn -verzoeken. Ontwikkeling met testen zei:
- Jongens, maken jullie een grapje?! We hebben u rekeningen gegeven en u heeft een stand opgezet!
Houd rekening met mogelijke risico's. Idealiter bereidt u een aparte stand voor voor het testen van informatiebeveiliging, die op zijn minst op de een of andere manier geïsoleerd zal zijn van de rest van de omgeving, en controleert u het beheerderspaneel voorwaardelijk, bij voorkeur in de handmatige modus. Dit is een pentest: de resterende percentages van de inspanning waar we nu niet over nadenken.
Het is de moeite waard om te overwegen dat u dit kunt gebruiken als analoog aan belastingtests. In de eerste fase kun je een dynamische scanner met 10-15 threads inschakelen en kijken wat er gebeurt, maar meestal, zoals de praktijk laat zien, niets goeds.
Een paar bronnen die we meestal gebruiken.
Het benadrukken waard is een “Zwitsers mes” voor elke beveiligingsprofessional. Iedereen gebruikt het en het is erg handig. Er is nu een nieuwe demoversie van de enterprise-editie uitgebracht. Was het vroeger slechts een op zichzelf staand hulpprogramma met plug-ins, nu maken de ontwikkelaars eindelijk een grote server van waaruit het mogelijk zal zijn om meerdere agenten te beheren. Dit is cool, ik raad je aan het te proberen.
Procesintegratie
Integratie gebeurt vrij goed en eenvoudig: begin met scannen na een succesvolle installatie aanvragen voor de stand en scannen na succesvolle integratietests.
Als de integraties niet werken of als er stubs en nepfuncties zijn, is het zinloos en nutteloos. Welk patroon we ook sturen, de server zal nog steeds op dezelfde manier reageren.
- Idealiter een aparte proefopstelling.
- Noteer vóór het testen de inlogvolgorde.
- Het testen van het administratiesysteem gebeurt uitsluitend handmatig.
Процесс
Een beetje algemeen over het proces in het algemeen en over het werk van elke tool in het bijzonder. Alle toepassingen zijn verschillend: de ene werkt beter met dynamische analyse, de 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 je meetgegevens verzamelen van alles wat je te pakken kunt krijgen, inclusief productiemeetgegevens, meetgegevens van tools en van defecttrackers.
Alle informatie is nuttig. Het is noodzakelijk om vanuit verschillende invalshoeken te kijken naar waar dit of dat hulpmiddel beter kan worden gebruikt, waar het proces specifiek zakt. Het kan de moeite waard zijn om naar de reactietijden van de ontwikkeling te kijken om te zien waar het proces op basis van tijd kan worden verbeterd. Hoe meer gegevens, hoe meer secties kunnen worden opgebouwd, van het hoogste niveau tot de details van elk proces.
Omdat alle statische en dynamische analysers hun eigen API's hebben, hun eigen startmethoden en principes, sommige hebben planners, andere niet - we schrijven een tool AppSec-orkestrator, waarmee u vanuit het product één toegangspunt tot het gehele proces kunt creëren en vanaf één punt kunt beheren.
Managers, ontwikkelaars en beveiligingsingenieurs hebben één toegangspunt van waaruit ze kunnen zien wat er wordt uitgevoerd, een scan kunnen configureren en uitvoeren, scanresultaten kunnen ontvangen en vereisten kunnen indienen. We proberen afstand te nemen van papierwerk, om alles te vertalen naar een menselijk document, dat wordt gebruikt door ontwikkeling - pagina's over Confluence met status en statistieken, defecten in Jira of in verschillende defecttrackers, of integratie in een synchroon/asynchronisch proces in CI /CD.
Key Takeaways
Gereedschap is niet het belangrijkste. Denk eerst na over het proces en implementeer vervolgens de tools. De tools zijn goed maar duur, dus u kunt met het proces beginnen en de communicatie en het begrip tussen ontwikkeling en beveiliging opbouwen. Vanuit veiligheidsoogpunt is het niet nodig om alles te ‘stoppen’. Vanuit ontwikkelingsoogpunt: als er iets hoog mega-superkritisch is, dan moet dit worden geëlimineerd en mogen we niet de ogen sluiten voor het probleem.
Productkwaliteit - gemeenschappelijk doel zowel veiligheid als ontwikkeling. We doen één ding: we proberen ervoor te zorgen dat alles correct werkt en dat er geen reputatierisico's of financiële verliezen zijn. Dit is de reden waarom we een DevSecOps, SecDevOps-aanpak promoten om de communicatie te verbeteren en de kwaliteit van het product te verbeteren.
Begin met wat je al hebt: eisen, architectuur, deelcontroles, trainingen, richtlijnen. Het is niet nodig om alle praktijken onmiddellijk op alle projecten toe te passen - iteratief verplaatsen. Er is niet één standaard – experiment en probeer verschillende benaderingen en oplossingen.
Er is een gelijk teken tussen informatiebeveiligingsdefecten en functionele defecten.
Automatiseer allesdat beweegt. Wat niet beweegt, verplaats het en automatiseer het. 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 IS-team klein is - gebruik Beveiligingskampioenen.
Misschien past datgene waar ik het over had niet bij je en kom je met iets van jezelf - en dat is goed. Maar kies tools op basis van de vereisten voor uw proces. Kijk niet naar wat de gemeenschap zegt, dat deze tool slecht is en deze goed. Misschien geldt voor uw product het tegenovergestelde.
Vereisten voor gereedschap.
- Laag niveau Vals positief.
- Voldoende analysetijd.
- Gebruiksgemak.
- Beschikbaarheid van integraties.
- Inzicht in de routekaart voor productontwikkeling.
- Mogelijkheid om gereedschappen aan te passen.
Het rapport van Yuri werd op DevOpsConf 2018 verkozen tot een van de beste. Om kennis te maken met nog meer interessante ideeën en praktijkcases, kom naar Skolkovo op 27 en 28 mei binnenin . Beter nog, als u bereid bent uw ervaringen te delen voor het rapport tot 21 april.
Bron: www.habr.com