{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Angst en haat voor DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

We had 2 code analyzers, 4 dynamic testing tools, our own creations, and 250 scripts. Not that all of this was needed in the current process, but once we started implementing DevSecOps, we must follow through.<\/p>\n

\"Angst
\n
\nBron<\/a><\/noindex>. Character creators: Justin Roiland and Dan Harmon.<\/i><\/p>\n

What is SecDevOps? And DevSecOps? What are the differences? Application Security - what is it about? Why is the classic approach no longer effective? Answers to all these questions are known Yuri Shabalin<\/b> uit\u00a0Swordfish Security. <\/b>Yuri will answer everything in detail and discuss the challenges of transitioning from the classic Application Security model to the DevSecOps process: how to integrate secure development into the DevOps process without breaking anything, how to navigate the main stages of security testing, what tools can be used, how they differ, and how to configure them correctly to avoid pitfalls.
\n<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\nAbout the speaker:<\/b> Yuri Shabalin - <\/b>Chief Security Architect at Swordfish Security<\/b>. Responsible for implementing SSDL, integrating application analysis tools into a unified development and testing ecosystem. 7 years of experience in information security. Worked at Alfa-Bank, Sberbank, and Positive Technologies, which develops software and provides services. Speaker at international conferences ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Application Security: what is it about?<\/h2>\n

\nApplication Security<\/b>\u00a0is a branch of security that focuses on the security of applications. It does not relate to infrastructure or network security, but specifically to what we write and what developers work on - the flaws and vulnerabilities of the application itself.<\/p>\n

Direction SDL or SDLC<\/a><\/noindex>\u00a0\u2014 Security development lifecycle<\/b>\u00a0was developed by Microsoft. The diagram shows the canonical SDLC model, whose main task is to involve security at every stage of development, from requirements to release and production deployment. Microsoft realized that there were too many bugs in production, that they were increasing, and something had to be done, leading to the proposal of this approach, which became canonical.<\/p>\n

\"Angst
\n
\nApplication Security and SSDL are not aimed at detecting vulnerabilities, as is commonly believed, but at preventing their emergence. Over time, the canonical approach from Microsoft has been improved and developed, incorporating a more in-depth detailed immersion.<\/p>\n

\"Angst
\n
\nHet canonieke SDLC is sterk gedetailleerd in verschillende methodologie\u00ebn - OpenSAMM, BSIMM, OWASP. De methodologie\u00ebn verschillen, maar zijn over het algemeen vergelijkbaar.<\/p>\n

Building Security In Maturity Model<\/h3>\n

\nIk voel me het meest verbonden met BSIMM<\/b>\u00a0\u2014 Building Security In Maturity Model<\/a><\/noindex>. De basis van de methodologie is het opdelen van het proces van Application Security in 4 domeinen: Governance, Intelligence, SSDL Touchpoints en Deployment. In elk domein zijn er 12 praktijken die zijn weergegeven in 112 activiteiten.<\/p>\n

\"Angst
\n
\nElke van de 112 activiteiten heeft 3 niveaus van volwassenheid<\/b>: basiss, gemiddeld en gevorderd. Alle 12 praktijken kunnen per sectie worden bestudeerd, belangrijke zaken voor jou worden geselecteerd, en je kunt leren hoe ze ge\u00efmplementeerd kunnen worden en geleidelijk elementen toevoegen, zoals statische en dynamische code-analyse of code reviews. Je schrijft een plan en werkt daarmee rustig aan de implementatie van de geselecteerde activiteiten.<\/p>\n

Waarom DevSecOps<\/h2>\n

<\/p>\n

DevOps is een overkoepelend groot proces waarin aandacht voor veiligheid noodzakelijk is.<\/p><\/blockquote>\n

\nOorspronkelijk DevOps<\/b><\/a><\/noindex> ging uit van beveiligingscontroles. In de praktijk was het aantal beveiligingsteams veel kleiner dan nu, en fungeerden ze niet als deelnemers aan het proces, maar als een controle- en toezichthoudend orgaan dat eisen stelt en de productkwaliteit aan het einde van de release controleert. Dit is de klassieke aanpak, waarbij beveiligingsteams achter de schermen van de ontwikkeling zaten en niet deelnamen aan het proces.<\/p>\n

\"Angst
\n
\nHet belangrijkste probleem is dat de informatiebeveiliging gescheiden staat van de ontwikkeling. Gewoonlijk bestaat er een soort informatiebeveiliging-contour met 2-3 grote en dure tools. Het broncode of de applicatie komt om de zes maanden binnen en moet gecontroleerd worden, en elk jaar worden penetratietests<\/a><\/noindex>. Dit leidt er allemaal toe dat de tijd om in productie te gaan wordt uitgesteld, en ontwikkelaars worden overspoeld met een enorme hoeveelheid kwetsbaarheden uit geautomatiseerde middelen. Dit is allemaal niet te ontleden en op te lossen, omdat de resultaten van de voorgaande zes maanden nog niet zijn bekeken, en er nu een nieuwe lading binnenkomt.<\/p>\n

In het proces van ons bedrijf zien we dat beveiliging in alle gebieden en industrie\u00ebn begrijpt dat het tijd is om zich aan te passen en samen met de ontwikkeling in \u00e9\u00e9n wiel te draaien - in\u00a0Agile<\/b><\/a><\/noindex>. De DevSecOps-paradigma past prachtig in de methodologie van agile ontwikkeling, op implementatie, ondersteuning en deelname aan elke release en iteratie.<\/p>\n

\"Angst
\n<\/p>\n

Overgang naar DevSecOps<\/h2>\n

\nHet belangrijkste woord in de Security Development Lifecycle is \"proces\"<\/b>Je moet dit begrijpen voordat je denkt aan het kopen van tools.<\/p>\n

Het is niet genoeg om tools in het DevOps-proces op te nemen - interactie en begrip tussen de deelnemers aan het proces zijn belangrijk.<\/p><\/blockquote>\n

<\/p>\n

Mensen zijn belangrijker dan tools.<\/h3>\n

\nVaak begint de planning van een veilig ontwikkelingsproces met de keuze en aankoop van een tool, en eindigt het met pogingen om de tool in het huidige proces te integreren, die slechts pogingen blijven. Dit leidt tot teleurstellende resultaten, omdat elke tool zijn eigen kenmerken en beperkingen heeft.<\/p>\n

Een vaak voorkomend geval is wanneer de beveiligingsafdeling een goede, dure tool heeft gekozen met uitgebreide mogelijkheden en deze aan de ontwikkelaars komt voorleggen - om in het proces te integreren. Maar het werkt niet - het proces is zo ingericht dat de beperkingen van de al gekochte tool niet passen binnen de huidige paradigma.<\/p>\n

Beschrijf eerst welk resultaat je wilt en hoe het proces eruit zal zien. Dit helpt om de rol van de tool en beveiliging in het proces te begrijpen.<\/p><\/blockquote>\n

<\/p>\n

Begin met wat al gebruikt wordt.<\/h3>\n

\nVoordat je dure tools koopt, kijk naar wat je al hebt. Iedere organisatie heeft beveiligingsvereisten die aan de ontwikkeling worden gesteld, er zijn controles, pentests - waarom niet alles omzetten naar een begrijpelijke en gebruiksvriendelijke vorm?<\/p>\n

Meestal zijn de vereisten een papieren rommel die op een plank ligt. Er was een geval waarin we naar een bedrijf gingen om de processen te bekijken en vroegen om de beveiligingsvereisten voor software te laten zien. De specialist die hiermee bezig was, zocht lang:<\/p>\n

\u2014 Even kijken, er was ergens in mijn notities een pad naar dit document.<\/i><\/p>\n

Uiteindelijk hebben we het document na een week ontvangen.<\/p>\n

Voor vereisten, controles en dergelijke, maak een pagina, bijvoorbeeld op\u00a0Confluence<\/b>\u00a0\u2014 dit is handig voor iedereen.<\/p>\n

Het is eenvoudiger om te herstructureren wat al bestaat en dit als uitgangspunt te gebruiken.<\/p><\/blockquote>\n

<\/p>\n

Gebruik Security Champions. <\/h3>\n

\nGewoonlijk werkt in een gemiddeld bedrijf met 100-200 ontwikkelaars \u00e9\u00e9n beveiligingsspecialist die meerdere functies vervult en fysiek niet in staat is om alles te controleren. Zelfs als hij zijn best doet, kan hij niet de hele code controleren die de ontwikkeling genereert. Voor dergelijke gevallen is het concept ontwikkeld van de Security Champions.<\/b><\/a><\/noindex>.<\/p>\n

Security Champions zijn mensen binnen het ontwikkelingsteam die betrokken zijn bij de veiligheid van uw product.<\/p><\/blockquote>\n

\"Angst
\n
\nSecurity Champion is het aanspreekpunt binnen het ontwikkelingsteam en de evangelist voor veiligheid in \u00e9\u00e9n persoon.<\/p>\n

Normaal gesproken, wanneer een beveiligingsspecialist het ontwikkelingsteam binnenkomt en een fout in de code aanwijst, krijgt hij vaak een verraste reactie:<\/p>\n

\u2014 Wie ben jij? Ik zie je hier voor het eerst. Met mij gaat alles goed - mijn senior collega heeft een 'apply' gezet tijdens de code review, we gaan verder!<\/i><\/p>\n

Dit is een typische situatie, omdat er veel meer vertrouwen is in senioren of gewoon collega's waarmee de ontwikkelaar regelmatig samenwerkt en die betrokken zijn bij de code review. Als in plaats van de beveiligingsspecialist een Security Champion de fout en de gevolgen aanwijst, zal zijn uitspraak zwaarder wegen.<\/p>\n

Ook weten ontwikkelaars hun code beter dan elke beveiligingsspecialist. Voor iemand die minimaal 5 projecten in een statische analysetool heeft, is het meestal moeilijk om alle nuances te onthouden. Security Champions kennen hun product: wat met wat interacteert en waar ze als eerst op moeten letten - ze zijn effectiever.<\/p>\n

Dus denk erover na om Security Champions in te voeren en de invloed van het beveiligingsteam uit te breiden. Voor de Champion zelf is dit ook voordelig: professionele ontwikkeling in een nieuw gebied, verbreding van technische kennis, verbetering van technische, management- en leiderschapsvaardigheden, en verhoging van de marktwaarde. Het is een soort sociale engineering, uw 'ogen' in het ontwikkelingsteam.<\/p>\n

Testfasen<\/h2>\n

\nDe 20 op 80-paradigma<\/a><\/noindex>\u00a0zegt dat 20% van de inspanningen 80% van het resultaat oplevert. Deze 20% zijn de analysemethoden voor applicaties die geautomatiseerd kunnen en moeten worden. Voorbeelden van dergelijke activiteiten zijn statische analyse - SAST<\/b>, dynamische analyse - DAST,<\/b> en\u00a0beheersing van Open Source<\/b>. Ik zal meer vertellen over de activiteiten, evenals over de tools, met welke bijzonderheden we meestal worden geconfronteerd bij hun implementatie in het proces, en hoe we dit goed kunnen doen.<\/p>\n

\"Angst
\n<\/p>\n

Belangrijkste problemen van de tools<\/h3>\n

\nIk zal de huidige problemen die voor alle tools relevant zijn, uitlichten die aandacht vereisen. Ik zal ze uitgebreider bespreken om herhaling te voorkomen.<\/p>\n

Langdurige analyse. <\/b>Als er 30 minuten van commit tot productielancering verstrijken voor alle tests en de build, dan zullen de controles op informatiebeveiliging een dag duren. Niemand wil dat het proces wordt vertraagd. Houd rekening met deze eigenschap en trek conclusies.<\/p>\n

Hoge mate van False Negative of False Positive. <\/b>Alle producten zijn verschillend, ze gebruiken verschillende frameworks en hebben hun eigen stijl van coderen. Op verschillende codebases en technologie\u00ebn kunnen de tools verschillende niveaus van False Negative en False Positive vertonen. Kijk daarom naar wat specifiek in de\u00a0uw<\/b> bedrijf en voor uw<\/b> applicaties goede en betrouwbare resultaten zal opleveren.<\/p>\n

Geen integraties met bestaande tools<\/b>. Kijk naar de tools vanuit het perspectief van integraties, met wat u al gebruikt. Bijvoorbeeld, als u Jenkins of TeamCity heeft, controleer dan de integratie van de tools specifiek met deze software, en niet met GitLab CI, dat u niet gebruikt.<\/p>\n

Afwezigheid of overmatige complexiteit van maatwerk. <\/b>Als een tool geen API heeft, waarom zou hij dan nodig zijn? Alles wat in de interface kan worden gedaan, moet ook via de API toegankelijk zijn. Idealiter zou de tool de mogelijkheid moeten hebben om controles aan te passen.<\/p>\n

Geen productontwikkelingsroadmap. <\/b>De ontwikkeling staat niet stil, we gebruiken altijd nieuwe frameworks en functies, en herschrijven oude code naar nieuwe talen. We willen er zeker van zijn dat de tool die we kopen nieuwe frameworks en technologie\u00ebn zal ondersteunen. Daarom is het belangrijk te weten dat het product een echte en juiste Roadmap<\/a><\/noindex> ontwikkeling heeft.<\/p>\n

Kenmerken van het proces<\/h3>\n

\nNaast de kenmerken van de tools, houd ook rekening met de kenmerken van het ontwikkelingsproces. Verbetering van de ontwikkeling is bijvoorbeeld een typische fout. Laten we kijken naar welke andere kenmerken in overweging moeten worden genomen en waar het beveiligingsteam op moet letten.<\/p>\n

Om vertragingen in de ontwikkeling en release te voorkomen, cre\u00eber verschillende regels<\/b> en verschillende show stoppers\u00a0<\/b>\u2014 criteria voor het stoppen van het bouwproces bij de aanwezigheid van kwetsbaarheden \u2014 voor verschillende omgevingen.<\/b>Bijvoorbeeld, we begrijpen dat de huidige tak naar de ontwikkelstand of UAT gaat, wat betekent dat we niet stoppen en niet zeggen:<\/p>\n

\u2014 U heeft hier kwetsbaarheden, u gaat niet verder!<\/i><\/p>\n

In deze fase is het belangrijk om de ontwikkelaars te informeren dat er beveiligingsproblemen zijn waarop ze moeten letten.<\/p>\n

Kwetsbaarheden zijn geen belemmering voor verder testen<\/b>: handmatig, integratie of manueel. Aan de andere kant moeten we de beveiliging van het product op een of andere manier verbeteren, zodat ontwikkelaars niet vergeten wat de beveiliging ontdekt. Daarom handelen we soms als volgt: op de stand, wanneer het wordt uitgerold naar de ontwikkelomgeving, informeren we de ontwikkeling gewoon:<\/p>\n

\u2014 Jongens, jullie hebben problemen, let alsjeblieft op.<\/i><\/p>\n

In de UAT-fase tonen we opnieuw waarschuwingen over kwetsbaarheden, en in de releasefase zeggen we:<\/p>\n

\u2014 Jongens, we hebben jullie meerdere keren gewaarschuwd, jullie hebben niets gedaan \u2014 hier laten we jullie niet mee doorgaan.<\/i><\/p>\n

Als we het over code en dynamiek hebben, is het nodig om kwetsbaarheden alleen te tonen en te waarschuwen voor de functies en code die net in deze functie zijn geschreven. Als een ontwikkelaar een knop met 3 pixels heeft verplaatst en we hem vertellen dat er een SQL-injectie is en dat hij het snel moet oplossen \u2014 dat is niet juist. Kijk alleen naar wat er nu is geschreven en naar de wijziging die in de applicatie komt.<\/p>\n

Stel dat we een bepaalde functionele fout hebben - iets wat de applicatie niet zou moeten doen: geld wordt niet overgemaakt, bij het klikken op de knop wordt er niet doorgeschakeld naar de volgende pagina of wordt het product niet geladen. Beveiligingsdefecten<\/b>\u00a0\u2014 dat zijn dezelfde defecten, maar dan niet vanuit het perspectief van de werking van de applicatie, maar van de beveiliging. <\/p>\n

Niet alle softwarekwaliteitsproblemen zijn beveiligingsproblemen. Maar alle beveiligingsproblemen hangen samen met softwarekwaliteit. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nAangezien alle kwetsbaarheden dezelfde defecten zijn, moeten ze zich daar bevinden waar alle ontwikkelingsdefecten zich bevinden. Vergeet daarom rapporten en enge PDF's die niemand leest.<\/p>\n

\"Angst
\n
\nToen ik bij een ontwikkelingsbedrijf werkte, kreeg ik een rapport uit statische analysetools. Ik opende het, schrok, zette koffie, bladerde door 350 pagina's, sloot het en ging verder met werken. Grote rapporten zijn dode rapporten<\/b>. Gewoonlijk gaan ze nergens heen, worden e-mails verwijderd, vergeten, verloren of zegt de business dat ze risico's aanvaarden.<\/p>\n

Wat te doen? Gecertificeerde defecten die zijn gevonden, zetten we om in een ontwikkelingsvriendelijke weergave, bijvoorbeeld door ze in de backlog van Jira te plaatsen. We prioriteren de defecten en verhelpen ze op volgorde van prioriteit, samen met functionele defecten en testdefecten.<\/p>\n

Statische analyse - SAST<\/h2>\n

\nDit is een code-analyse op kwetsbaarheden<\/b>, maar dit is niet hetzelfde als SonarQube. We controleren niet alleen op patronen of stijl. Bij de analyse worden verschillende benaderingen toegepast: op basis van een kwetsbaarhedenboom, op\u00a0DataFlow<\/a><\/noindex>, op de analyse van configuratiebestanden. Dit betreft alles wat direct met de code te maken heeft.<\/p>\n

Voordelen van de aanpak<\/b>: identificatie van kwetsbaarheden in de code in een vroeg stadium van de ontwikkeling<\/b>, wanneer er nog geen omgevingen en gereed gereedschap zijn, en\u00a0de mogelijkheid voor incrementele scans<\/b>: het scannen van het deel van de code dat is gewijzigd, en alleen die functie die we nu aan het maken zijn, wat de scan tijd vermindert.<\/p>\n

Nadelen<\/b>\u00a0\u2014 is het ontbreken van ondersteuning voor noodzakelijke talen.<\/p>\n

Nodige integraties, <\/b>die volgens mijn subjectieve mening aanwezig moeten zijn in de tools:<\/p>\n