L'impatto della sicurezza su DevOps
•Transferir como PPTX, PDF•
0 gostou•96 visualizações
L'impatto della sicurezza su DevOps WebDay 2022 10 mar 2022 https://www.ugidotnet.org/e/2840/Web-Day-2022
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a L'impatto della sicurezza su DevOps
Semelhante a L'impatto della sicurezza su DevOps (20)
Mais de Giulio Vian
Mais de Giulio Vian (20)
Último
Último (20)
L'impatto della sicurezza su DevOps
- 1. What it’s all about The environmental pressure on software has dramatically changed in few years. In quality and quantity.
- 2. Seguici su Telegram: https://t.me/ugidotnet Kudos to Sponsors
- 3. What it’s all about The environmental pressure on software has dramatically changed in few years. In quality and quantity. Mainly security concerns.
- 4. Pressure impact How we automate. How we plan, budget I suggest to introduce a new term: Technical Inflation. Inflation differs from Technical Debt. Software value decrease (even drops) over time without intervention.
- 5. We won’t address today Infrastructure security Explain SCA, SAST, DAST, IAST, … Secure SDLC Secrets Management Governance …
- 6. Hardware spec: 1 KB RAM 4 KB ROM First computer Past employers Communities Giulio Vian Principal DevOps Engineer @giulio_vian giuliovdev@hotmail.com
- 7. Agenda DevOps & Security Why should you care? Consequences
- 8. DevOps & Security Background Information Image source: Reddit
- 9. What is DevOps? Cartoon by ROELBOB
- 10. What is DevOps? «The result of applying Lean principles to the technology value stream» The DevOps Handbook, Gene Kim et al., 2016 The Three Ways: The Principles Underpinning DevOps
- 11. Achievement unlocked! Zero-bugs! No known security issues in code! No known security issues in infrastructure! Guilio
- 12. …except…
- 13. High-level process CVE triggers Security instructs Developer Teams fix code Release Management deploy
- 14. Finding code Which code matches production? master main release/* v* tags Multiple production branches release/* and hotfix/* Untagged releases SCA tools pipeline-bound Rarely built code Pipeline does not work anymore
- 15. Vulnerability may affect Application stack Container images Virtual Machine images Application itself Application code Libraries Internal 3rd party Self-contained run-time Application Run-time OS libraries Docker base image Self- contained
- 16. Tools to Identify Vulnerabilities Static Application Security Testing (SAST) Software Composition Analysis (SCA) Commercial Synopsys Black Duck, Snyk, WhiteSource Bolt, Sonatype Nexus Platform, JFrog Xray OSS npm audit, OWASP Dependency Check, GitHub dependabot, Trivy Application Run-time OS libraries v
- 17. Fixing code Scan multiple repositories Patch code Regression test Can be automated?
- 18. Trivial case Mono-repo Unified pipeline Image: clutter by Ashton
- 19. Everyone else Many teams Many repos My company has 3,000 repos across 100 teams, storing over 13 million lines of code, and using 2,800 pipelines A single vulnerability may affect 10s teams and 100s of repos Image: The Crowd For DMB 1 by Moses
- 20. Redeploy. Every. Day. Simplest pattern Once automated patching is in place Zero-downtime deploy in place Consider pipeline resources Image: the gerbil wheel pose by dbgg1979
- 21. Setup a Code Metabase Reverse indexes Library → Binaries [SCA tool] O.S. API → Binaries [SAST tool] Binary → Pipelines [artifact store] Pipeline → Repo(s) [pipeline tool] Pipeline Binaries Production Library Repo
- 22. Expedite pipelines Separation of Duties Regulation / audit requirement Slows 0-day patching Tightly controlled usage Automated checks Single commit with limited churn Additional approvers for quick turnaround Image courtesy of SpaceX
- 23. Breadth of change Fix impacting many systems at once Hundreds of concurrent pipelines Can your build & deploy tool auto-scale? Can your approval process scale? How fast can you rebuild a substantial portion of IT systems?
- 24. Why should I care? Image © Mediaset
- 25. Vulnerabilities over year Source: mitre.org
- 26. Zero-days exploits are increasing Source: Google
- 27. Dependencies An average .NET project has 11 direct, and 76 indirect dependencies [Source: Snyk] Project == nuget.org package The average application contains 118 open- source libraries [Source: Contrast Security] Application: Java/.NET/NodeJS
- 28. Open source dependency & vulnerability Source: Sonatype
- 29. App Platform shift Chrome 1 month patched after 14 days Node.JS 30 months (LTS) patched every 25 days 6 months Go 6 months patched every 26 days Two major releases supported. MongoDB 30 months patched every 5 weeks .NET 3 years (LTS) patched every 6 weeks 18 months Java 3 years (LTS) patched every 6 months 12 weeks
- 30. Base images vmdk, VHD, VDI, OVA, … AMI , VHD Docker, OCI, ACI, … Application Run-time OS libraries Base image
- 31. Security SLA Mean Time to Patch Single component Multiple components at once! In Production
- 32. Consequences
- 33. Technical Debt «describes the consequences of software development actions that intentionally or unintentionally prioritize client value and/or project constraints such as delivery deadlines, over more technical implementation and design considerations.» Holvitie J., Licorish S.A., et al. - Technical debt and agile software development practices and processes – Information and Software Technology, iss. 96 (2018) p.142 Image by ThoBel-0043
- 34. Technical Inflation Unintended reduction in value of a software product over time, independent of source code changes. Depreciation does not capture two elements: Unintentionality Value can be restored Image source: Max Pixel
- 35. 1974 Continuing Change law «A[n E-type] system must be continually adapted or it becomes progressively less satisfactory.» Image source: WikiMedia
- 36. Restoring Value At most two platform versions Zero-(security-)issues policy Expedite pipelines Image by Marek Ślusarczyk
- 38. Change
- 39. Never forget about consequences Image by Lionel Allorge
- 40. Seguici su Telegram: https://t.me/ugidotnet Kudos to Sponsors
- 41. Thank you! @giulio_vian giuliovdev@hotmail.com Slides that follow list bibliographic references
- 43. References (2/4) https://heartbleed.com/ Why Every Business Is a Software Business — Watts S. Humphrey Informit, Feb 22, 2002 http://www.informit.com/articles/article.aspx?p=25491 https://en.wikipedia.org/wiki/Watts_Humphrey https://www.sonatype.com/resources/state-of-the-software-supply-chain-2021 https://www.shopify.com/enterprise/global-ecommerce-statistics https://blog.cloudflare.com/popular-domains-year-in-review-2021/ https://radar.cloudflare.com/year-in-review-2021 https://snyk.io/blog/net-open-source-security-insights/ https://www.contrastsecurity.com/the-state-of-the-oss-report-2021 https://octoverse.github.com/static/github-octoverse-2020-security-report.pdf
Notas do Editor
- Buonasera a tutti, sono GV E vi parlero’ dell’impatto della sicurezza su devops
- Anzitutto ringraziamo gli sponsor di questo evento e dei loro contributi
- Il tema che voglio approfondire con voi questa sera si riassume brevemente: La pressione sull’IT e sullo sviluppo software e` drasticamente aumentata in pochissimi anni, sia in ampiezza che in profondita`, in particolar modo su questioni di sicurezza
- Tale pressione ci costringera`, se gia` non lo ha fatto, a modificare diversi processi, non ultime le modalita’ con cui gestiamo la pianificazione tecnica e quella finanziaria, ovvero il budget. Per meglio interloquire, tanto con i manager e la leadership tecnologica, quanto con le divisioni di business che si appoggiano ogni giorno di piu’ sull’IT, suggerisco di introdurre una nuova espressione: iniziamo a parlare di Inflazione Tecnica, distinta dall’ormai classico Debito Tecnico. La novita` consiste nel calo di valore, ovvero nel deprezzamento, che avviene automaticamente sul software indipendentemente dagli interventi evolutivi o manutentivi.
- Focalizzandoci sul tema dell’Inflazione Tecnica, dovro` necessariamente tralasciare molti altri argomenti, sia tecnici che manageriali, riguardanti il rapport tra sicurezza e DevOps. Quindi mi limito’ ad accennare alcuni tipi di strumenti utili ad arginare l’Inflazione Tecnica: SCA e SAST, sigle che vedremo tra breve. Static Application Security Testing Dynamic Application Security Testing Interactive Application Security Testing IAST places an agent within an application and performs all its analysis in the app in real-time and anywhere in the development process IDE, continuous integrated environment, QA or even in production.
- Dopo aver introdotto il tema di questa sera, un breve cenno biografico volto a inquadrare la mia esperienza professionale. Lavoro come Principal Engineer negli uffici irlandesi di Unum dove siamo circa 200 persone tutte nella struttura IT. Unum e` una assicurazione statunitense, una Fortune 500, con fatturato di 12 miliardi di $ e 10,000+ employees (1,000+ in IT). Precedentemente ho lavorato in diverse aziende in Italia e all’estero, sia grandi che medie. Qualcuno di voi mi ricordera` per lunghi anni nella consulenza Microsoft Italia o come Microsoft MVP. Per contattarmi su questo e altri argomenti DevOps usate tranquillamente Twitter giulio_vian o anche direttamente per mail.
- La presentazione di questa sera si articolera` su tre momenti: come la sicurezza interseca i processi DevOps e in particolare riguardo il Continuous Delivery in quale misura e` aumentata la pressione e sia cruciale affrontarla adeguatamente come spiegare il fenomeno e cambiare la fase di pianificazione
- Spesso la relazione tra devops e sicurezza non e` delle migliori si blocca un ingresso, ma si trascurano tutti gli altri
- Prima di entrare nel vivo, e` opportuno che ci accordiamo su una definizione di DevOps Per molti si traduce come Continous Integration e Continous Delivery ma, a mio parere e di molti altri, si tratta di una visione riduttiva perche` risolve i problemi dei dev lasciando le rogne agli altri Source: https://devops.com/12-factor-app-build-release-run/
- Quindi ora vi subite il pippone metodologico, ma provero` a farla breve DevOps vuol dire applicare gli stressi principi lean che adotta l’industra manufatturiera (e in particolare automobilistica) applicati pero` al flusso di valore tecnologico, che include l’assemblaggio di hardware e software come prodotto o servizio. In questa visione l’automazione e’ solo un mezzo per snellire i processi informatici ma l’obiettivo e` trasformare l’intera organizzazione perche` si concentri sulla catena del valore in modo organico e complete lasciando da parte visioni ristrette e corporative cio` si articola in tre dimensioni Flow / Flusso – principalmente automazione, ma anche rimuovere ogni elemento di rallentamento Feedback/ritorno – verificare continuamente il ritorno degli investimenti, dal monitoraggio delle performance tecniche, al dismettere funzionalita` inutile, al migliorare l’esperienza dell’utente Continual learning and experimentation – ogni anello della catena spende energie per migliorare il proprio contributo diretto e indiretto, ben sapendo che chi si ferma e` perduto Adesso che abbiamo chiarito la visione DevOps, passiamo a parlare di sicurezza. Pensiamo ad un caso ideale…
- …il signor Guilio (80% delle volte che scrivono il mio nome, convinti, eh) Dicevamo, il signor Guilio ha raggiunto la vetta piu’ alta: la sua applicazione SparagnaSchei non ha piu` bug noti di alcun genere. Il sistemista Giuseppi, ha fatto un lavoro eccellente, l’infrastruttura che ha realizzato resiste a tutti gli attacchi noti. Fantastico, l’azienda vuole premiare questi eccezzionali lavoratori…
- …peccato che il giorno dopo, ecco che abbiamo una nuova vulnerabilita’ Ce n’e’ di ogni genere BLAH ma a Guilio interessa soprattutto il primo tipo
- Com’e’ che l’ha scoperta? La dott.ssa Georgia della sicurezza ha ricevuto la notiza per posta e l’ha girata a Guilio. Loosely related to Security Orchestration, Automation and Response (SOAR) How we run the process today? Publication of a CVE triggers the Security team in the organization, Security team instructs Dev Teams to fix application code as needed, code must be deployed to Production under Release Management team supervision A Release Management role may be required by SOX, Basilea, and similar regulation Deploy where? Production! We don’t care about the rest (although…), so we need to…
- Sotto version control c’e` moltissimo codice con mille mila branches, come trova Guilio i sorgenti da modificare? Ci sono convenzioni diverse! Alcuni usano master per rappresentare la versione in produzione, chi lo chiama main chi mainline, altri creano un branch di release, altri marcano con un Tag corrispondente alla versione SemVer dei binary, e altre varianti ancora? C’e’ persino chi non fa’ nulla e si affida allo strumento di CI/CD per identificare a ritroso la versione di produzione! Come potra` orientarsi Guilio in questo marasma? Le pipeline di build offrono un aiuto perche` usano uno strumento di SCA (ci torniamo su questo) ma purtroppo ci son dei limiti. L’applicazione CalendarioPerpetuo non viene aggiornata da tre anni! Guilio prova a lanciare la build ma la nuova versione di SDK da’ errori e non si riesce neanche a ricompilare! E intanto la sabbia scorre… tic tac, tic tac… Here we discuss how to identify: 1. the code that needs to be patched 2. the pipeline that release that code in Production and some issues that one may face: If more than one branch can reach prod, which one you choose? How do you match the exact version of code? Software Composition Analysis kicks in only through pipelines? Is triggered by the deploy pipeline? The deploy pipeline hasn’t been used in months and doesn’t work anymore (e.g. a token expired, or there is no more an apt agent)
- Apriamo un parentesi per spiegare che cavolo sia uno strumento SCA. Purtroppo ci vuole un secondo pippone, se non altro e` di roba tecnica e non di metodologia. Prendiamo SparagnaSchei.ReteMondiałe (Risparmia Web) Come tutte le applicazioni di buona famiglia non e` mica scritta in linguaggio assembler x86 (anche perche` avrebbe problemi sui nuovi Mac), eh no, e` scritta in Java che e` tanto portabile. Quindi abbiamo il codice dell’applicazione, il quale usa delle librerie (inclusa la famigerata Log4J) e richiede una JRE (Java Runtime Environment). Questo schema vale anche per SparagnaSchei.Pomo (Risparmia iOS) che invece usa Xamarin e .NET Core (dai .NET 5) e SparagnaSchei.Mòbiłe la versione Android. Uuuuh. ReteMondiałe e` in un container Docker, quindi bisogna re-buildarlo ogni 3 mesi per rinferscare la JRE dentro l’imagine Docker. Pomo e Mòbiłe sono self-contained e vanno aggiornate ogni 40 giorni con un nuovo rilascio di .NET. You stop and think: what is affected by these vulnerabilities? Which is the portion I am responsible for? Thus, you analyse and find three (four) layers BLAH BLAH …and the next question is…
- Ma Guilio non si perde d’animo e sa come trovo vulnerabilita` nel codice e nelle librerie usate: SAST e SCA! Static Application Security Testing (SAST) analizza i sorgenti per errori come il mancato controllo dell’input o SQL injection. Software Composition Analysis (SCA) analizza i binari o i sorgenti per identificare le versioni di librerie in uso e controllare in un database continuamente aggiornato se hanno vulnerabilita` note. Quegli strumenti SCA che validano i binari sono in grado di indentificare anche componenti di runtime o del Sistema operative riguardo a vulnerabilita` note. Guilio non ha budget e quindi usera` un versione open source o freemium per la sua ricerca. E chiudiamo la parentesi …are there tools to support me and detect vulnerabilities in the code I deliver? Yes, there are BLAH
- Difatti Guilio e` molto stimolato dalle gentili parole del mega-direttore galattico sul suo personale future e riesce a identificare tutte le applicazioni e componenti da aggiornare. Alcuni casi son complicati: parent pom files, Directory.Build.props, Directory.Build.targets, ma Si. Puo`. Fare! La faccenda e` assai laboriosa: pur usando la stessa piattaforma, i team usano convenzioni diverse per organizzare il codice. Chi butta lo script di build in cima, chi pretende avere una cartella src. Lo stesso team non e` coerente nel tempo e non si cura di riarmonizzare il codice. Automatizzare le modifiche e` un compito improbo, lasciamolo perdere, pensa Guilio, tanto non ci sara` piu` un altra Log4J. Che ne dite, avra` ragione? The vulnerability could be a bad code pattern, use of an API, a vulnerable dependency; in any case we need to find the impacted code. We must scan all repositories that contain production code. Non-production repositories should be included in the search but listed separately to remove noise. Some patching can be easily automated, in particular library dependencies listed in project file (e.g. package.json, pom.xml,.csproj, …)
- Val la pena di menzionare che la situazione di Guilio non si applica a tutti: se non hai tanti repo, tante app, tante pipeline, come alcuni fortunati hanno, e’ facile affrontare la situazione con un approccio manuale. If you have a uber-pipeline that deploys everything, you do not need anything fancy. Sadly, this is a rare scenario in modern landscape: your organization can have lot of legacy, or can be a big IT with dozens or hundreds of teams, or a hundreds or thousand of micro-services.
- A Guilio va ancora bene, se provate a mettervi nei miei panni, comprenderete come sia ben difficile gestire lo scenario di Guilio con una gestione completamente manuale. Vediamo alcune idee per una gestione su scala.
- Current tooling may offer some information but a well-rounded process lot of cross-reference data. Dependency management is a weak spot in general, SCA (Software Composition Analysis) can identify vulnerabilities in libraries. Use of API may be caught by security scans Artifact management tool can track the source (build) of binaries if properly used. Pipeline knows which repositories they use, what we need here is ability to call a REST API that tell us the dependency. If you can use such tools, great. Maybe you need to follow a bit of conventions and write some query tools. In the worst scenario, you have to build and maintain your own database.
- A Release Management role may be required by SOX, Basilea, and similar regulation But you need speed when it is a 0-day exploit. For example, you must be able to deploy a patch within hours of its release from a 3rd party (an OSS project or a vendor). fast-track (expedite) pipelines are not for normal usage: there should be some kind of trigger, like a new CVE, a communication from the Security team or upper management.
- As mentioned, on a small scale, it is easy. Problems raise when you need to manage at scale: more than a few teams, repos, or pipeline. Consider the scenario where a single vulnerability impacts most of your applications (which is probable when you the majority of you code use the same platform, e.g. Log4J impacting all Java-based applications). You need to patch lots of repositories and deploy lots of components, each through a separate pipeline. In such scenario, you need new capabilities: Global editing tool Launch most pipelines in parallel (consider batching) Auto-scale build resources to sustain the spike Single-approval for the set of pipeline runs These aren’t offered by current systems.
- What is the way to solve this burning problem?
- …they are not decreasing, quite the opposite. Increasing more than linearly!
- …display the same pattern, even more. Why?
- .NET Core 3.1 3.1.0 December 3, 2019 3.1.22 December 14, 2021 got 22 patch releases in 3 years i.e. every 45 days/6 weeks Node v14 (Fermium) Active LTS start 2020-10-27 v14.15.0 2022-02-01, Version 14.19.0 total 19 releases in 463 days or 66 weeks i.e. every 24.4 days JDK 11 Java SE 11 (LTS)September 25, 2018 11.0.13+8 (GA), October 19th 2021 total 13 releases(updates) in 1121 days i.e. every 12.3 weeks or 86.2 days Go 1.16 released 2021-02-16 go1.16.14 (released 2022-02-10) total 14 updates in 360 days i.e. 26 days go1 (released 2012-03-28) -> go1.17 (released 2021-08-16) 17 major releases in 3429 days or 490 weeks MongoDB 5.0 5.0.0 - Jul 13, 2021 5.0.6 - January 31, 2022 total 6 releases in 203 days or 29 weeks i.e. every 4.8 weeks
- Crucial metric that IT can discuss with Business and translate in Cost and Risk
- What is the way to solve this burning problem?
- Johannes Holvitie, Sherlock A. Licorish, Rodrigo O. Spínola, et al. - Technical debt and agile software development practices and processes: An industry practitioner survey - Information and Software Technology, issue 96 (2018) p.142 Le conseguenze di azioni che con o senza intenzione danno priorita
- «An E-program is written to perform some real-world activity; how it should behave is strongly linked to the environment in which it runs, and such a program needs to adapt to varying requirements and circumstances in that environment» “On understanding laws, evolution, and conservation in the large-program life cycle” Lehman M.M. - Journal of Systems and Software Vol. 1, 1979–1980, pp. 213-221
- Non siate passivi come Guilio Preparatevi, iniziate ad adottare strumenti di SAST ed SCA, ad includere scenari d’emergenza e massivi nei processi e nelle automazioni Adopt SAST and SCA Free tier No issues allowed! Break the build! Design expedite process Today
- Portate queste discussioni al livello superiore, fate riconsiderare i rischi legati a trascurare i problemi di sicurezza Cambiate come viene distribuito il budget Change budget allocation