Mali sme 2 analyzátory kódu, 4 dynamické testovacie nástroje, vlastné remeslá a 250 skriptov. Nie je to tak, že toto všetko je potrebné v aktuálnom procese, ale keď začnete implementovať DevSecOps, musíte ísť až do konca.
. Tvorcovia postáv: Justin Roiland a Dan Harmon.
Čo je SecDevOps? A čo DevSecOps? v čom sú rozdiely? Bezpečnosť aplikácií – o čo ide? Prečo už nefunguje klasický prístup? Pozná odpoveď na všetky tieto otázky Jurij Šabalin z Bezpečnosť mečúňa. Yuri odpovie na všetko podrobne a analyzuje problémy prechodu z klasického modelu zabezpečenia aplikácií na proces DevSecOps: ako správne pristupovať k integrácii procesu bezpečného vývoja do procesu DevOps a nič nepokaziť, ako prejsť hlavnými fázami bezpečnostného testovania, aké nástroje možno použiť a v čom sa líšia a ako ich správne nakonfigurovať, aby sa predišlo nástrahám.
O rečníkovi: Jurij Šabalin - Hlavný bezpečnostný architekt v spoločnosti Bezpečnosť mečúňa. Zodpovedá za implementáciu SSDL, za celkovú integráciu nástrojov na analýzu aplikácií do jednotného vývojového a testovacieho ekosystému. 7 rokov skúseností v informačnej bezpečnosti. Pracoval v Alfa-Bank, Sberbank a Positive Technologies, ktorá vyvíja softvér a poskytuje služby. Prednášajúci na medzinárodných konferenciách ZerONights, PHDays, RISSPA, OWASP.
Zabezpečenie aplikácií: o čo ide?
Bezpečnosť aplikácií - Toto je sekcia zabezpečenia, ktorá je zodpovedná za bezpečnosť aplikácie. Netýka sa to infraštruktúry či bezpečnosti siete, ale skôr toho, čo píšeme a na čom vývojári pracujú – to sú nedostatky a zraniteľnosti samotnej aplikácie.
smer - Životný cyklus vývoja bezpečnosti - vyvinutý spoločnosťou Microsoft. Diagram zobrazuje kanonický model SDLC, ktorého hlavnou úlohou je účasť bezpečnosti na každej fáze vývoja, od požiadaviek až po vydanie a výrobu. Microsoft si uvedomil, že v tomto odvetví je príliš veľa chýb, bolo ich viac a treba s tým niečo urobiť, a navrhli tento prístup, ktorý sa stal kanonickým.
Zabezpečenie aplikácií a SSDL nie sú zamerané na odhaľovanie zraniteľností, ako sa bežne verí, ale na predchádzanie ich výskytu. Postupom času sa kanonický prístup Microsoftu zdokonaľoval, vyvíjal a zavádzal do hlbšieho a podrobnejšieho ponoru.
Kanonická SDLC je veľmi podrobná v rôznych metodológiách - OpenSAMM, BSIMM, OWASP. Metodiky sú rôzne, ale vo všeobecnosti sú podobné.
Model budovania bezpečnosti v dospelosti
mne sa to páči najviac BSIMM - . Základom metodiky je rozdelenie procesu Aplikačnej bezpečnosti do 4 domén: Governance, Intelligence, SSDL Touchpoints a Deployment. Každá doména má 12 praktík, ktoré sú reprezentované ako 112 aktivít.
Každá zo 112 aktivít má 3 stupne zrelosti: začiatočník, mierne pokročilý a pokročilý. Všetkých 12 postupov si môžete preštudovať sekciu po sekcii, vybrať si veci, ktoré sú pre vás dôležité, prísť na to, ako ich implementovať a postupne pridávať prvky, napríklad statickú a dynamickú analýzu kódu alebo kontrolu kódu. Spíšete si plán a pokojne podľa neho pracujete v rámci realizácie vybraných aktivít.
Prečo DevSecOps
DevOps je všeobecný, rozsiahly proces, pri ktorom sa musí brať ohľad na bezpečnosť.
Spočiatku zahŕňali bezpečnostné kontroly. V praxi bol počet bezpečnostných tímov oveľa menší ako teraz a nevystupovali ako účastníci procesu, ale ako kontrolný a dozorný orgán, ktorý naň kladie požiadavky a na konci vydania kontroluje kvalitu produktu. Ide o klasický prístup, pri ktorom boli bezpečnostné tímy od vývoja za múrom a nezúčastňovali sa na procese.
Hlavným problémom je, že informačná bezpečnosť je oddelená od vývoja. Zvyčajne ide o nejaký okruh informačnej bezpečnosti a obsahuje 2-3 veľké a drahé nástroje. Raz za pol roka prichádza zdrojový kód alebo aplikácia, ktorú je potrebné skontrolovať, a raz ročne sa vyrába . To všetko vedie k tomu, že dátum vydania pre toto odvetvie je oneskorený a vývojár je vystavený obrovskému množstvu zraniteľností z automatizovaných nástrojov. Nie je možné to všetko rozobrať a opraviť, pretože výsledky za predchádzajúcich šesť mesiacov neboli vytriedené, ale tu je nová várka.
V priebehu práce našej spoločnosti vidíme, že bezpečnosť vo všetkých oblastiach a odvetviach chápe, že je čas dobehnúť zameškané a točiť sa s vývojom na jednom kolese – v . Paradigma DevSecOps dokonale zapadá do agilnej metodiky vývoja, implementácie, podpory a účasti na každom vydaní a opakovaní.
Prechod na DevSecOps
Najdôležitejšie slovo v životnom cykle vývoja bezpečnosti je "proces". Musíte to pochopiť skôr, ako budete premýšľať o kúpe nástrojov.
Jednoduché začlenenie nástrojov do procesu DevOps nestačí – dôležitá je komunikácia a porozumenie medzi účastníkmi procesu.
Ľudia sú dôležitejší, nie nástroje.
Plánovanie bezpečného procesu vývoja často začína výberom a nákupom nástroja a končí pokusmi o integráciu nástroja do súčasného procesu, ktoré zostávajú pokusmi. To vedie k nešťastným následkom, pretože všetky nástroje majú svoje vlastné charakteristiky a obmedzenia.
Bežný prípad je, keď si bezpečnostné oddelenie vybralo dobrý, drahý nástroj so širokými možnosťami a prišlo za vývojármi, aby ho integrovali do procesu. Ale to nefunguje - proces je štruktúrovaný tak, že obmedzenia už zakúpeného nástroja nezapadajú do súčasnej paradigmy.
Najprv opíšte, aký výsledok chcete a ako bude proces vyzerať. Pomôže to pochopiť úlohu nástroja a bezpečnosti v tomto procese.
Začnite s tým, čo sa už používa
Pred nákupom drahých nástrojov sa pozrite na to, čo už máte. Každá firma má bezpečnostné požiadavky na vývoj, existujú kontroly, pentesty – prečo to všetko nepretransformovať do podoby, ktorá je zrozumiteľná a pohodlná pre každého?
Zvyčajne sa vyžaduje papierový Talmud, ktorý leží na poličke. Vyskytol sa prípad, keď sme prišli do spoločnosti pozrieť sa na procesy a požiadali sme, aby sme videli bezpečnostné požiadavky na softvér. Špecialista, ktorý sa tým zaoberal, dlho hľadal:
- Niekde v poznámkach bola cesta, kde leží tento dokument.
V dôsledku toho sme dokument dostali o týždeň neskôr.
Pre požiadavky, kontroly a iné veci si vytvorte stránku napr. sútok - je to výhodné pre každého.
Je jednoduchšie preformátovať to, čo už máte, a použiť to na začiatok.
Použite bezpečnostných šampiónov
V priemernej firme so 100 – 200 vývojármi je zvyčajne jeden bezpečnostný špecialista, ktorý vykonáva viacero funkcií a fyzicky nemá čas všetko kontrolovať. Aj keď sa bude snažiť ako vie, len on sám neskontroluje všetok kód, ktorý vývoj generuje. Pre takéto prípady bol vyvinutý koncept - .
Security Champions sú ľudia vo vývojovom tíme, ktorí sa zaujímajú o bezpečnosť vášho produktu.
Security Champion je vstupným bodom do vývojového tímu a bezpečnostným evanjelistom v jednom.
Zvyčajne, keď bezpečnostný špecialista príde do vývojového tímu a upozorní na chybu v kóde, dostane prekvapenú odpoveď:
- A kto si ty? Vidím ťa prvýkrát. Všetko je v poriadku - môj starší priateľ mi dal „prihlášku“ na preskúmanie kódu, ideme ďalej!
Toto je typická situácia, pretože oveľa väčšia dôvera je v seniorov alebo jednoducho spoluhráčov, s ktorými vývojár neustále komunikuje v práci a pri kontrole kódu. Ak namiesto bezpečnostného dôstojníka na chybu a následky upozorní Bezpečnostný šampión, jeho slovo bude mať väčšiu váhu.
Tiež vývojári poznajú svoj kód lepšie ako ktorýkoľvek bezpečnostný špecialista. Pre osobu, ktorá má v nástroji statickej analýzy aspoň 5 projektov, je zvyčajne ťažké zapamätať si všetky nuansy. Šampióni bezpečnosti poznajú svoj produkt: čo interaguje s čím a na čo sa treba pozerať ako prvé – sú efektívnejšie.
Zvážte teda implementáciu bezpečnostných šampiónov a rozšírenie vplyvu vášho bezpečnostného tímu. To je užitočné aj pre samotného šampióna: profesionálny rozvoj v novej oblasti, rozširovanie jeho technických obzorov, zvyšovanie technických, manažérskych a vodcovských schopností, zvyšovanie trhovej hodnoty. Toto je nejaký prvok sociálneho inžinierstva, vaše „oči“ vo vývojovom tíme.
Fázy testovania
hovorí, že 20 % úsilia prináša 80 % výsledkov. Týchto 20 % predstavuje postupy analýzy aplikácií, ktoré môžu a mali by byť automatizované. Príkladmi takýchto činností sú statická analýza - SAST, dynamická analýza - DAST и Ovládanie otvoreného zdroja. Poviem vám podrobnejšie o činnostiach, ako aj o nástrojoch, s akými funkciami sa zvyčajne stretávame pri ich zavádzaní do procesu a ako to urobiť správne.
Hlavné problémy nástrojov
Upozorním na problémy, ktoré sú relevantné pre všetky nástroje a vyžadujú si pozornosť. Rozoberiem ich podrobnejšie, aby som ich ďalej neopakoval.
Dlhá doba analýzy. Ak od záväzku k uvoľneniu trvá 30 minút na všetky testy a zostavenie, kontroly bezpečnosti informácií budú trvať deň. Takže nikto nebude spomaľovať proces. Berte túto vlastnosť do úvahy a vyvodzujte závery.
Falošne negatívne alebo falošne pozitívne vysoká úroveň. Všetky produkty sú odlišné, všetky používajú rôzne rámce a svoj vlastný štýl kódovania. Na rôznych kódových základniach a technológiách môžu nástroje vykazovať rôzne úrovne falošne negatívneho a falošného pozitívu. Pozrite sa teda, čo presne tam je tvoj spoločnosti a pre tvoj aplikácie budú vykazovať dobré a spoľahlivé výsledky.
Žiadna integrácia s existujúcimi nástrojmi. Pozrite sa na nástroje z hľadiska integrácie s tým, čo už používate. Ak máte napríklad Jenkins alebo TeamCity, skontrolujte integráciu nástrojov s týmto softvérom a nie s GitLab CI, ktorý nepoužívate.
Nedostatok alebo nadmerná zložitosť prispôsobenia. Ak nástroj nemá API, prečo je potom potrebný? Všetko, čo sa dá urobiť v rozhraní, by malo byť dostupné cez API. V ideálnom prípade by mal mať nástroj možnosť prispôsobiť kontroly.
Žiadny plán vývoja produktu. Vývoj nestojí, stále používame nové rámce a funkcie, prepisujeme starý kód do nových jazykov. Chceme si byť istí, že nástroj, ktorý kupujeme, bude podporovať nové rámce a technológie. Preto je dôležité vedieť, že produkt má skutočný a správny rozvoj.
Funkcie procesu
Okrem funkcií nástrojov zohľadnite aj vlastnosti procesu vývoja. Častou chybou je napríklad brzdenie rozvoja. Pozrime sa na to, aké ďalšie funkcie treba brať do úvahy a na čo by si mal bezpečnostný tím dávať pozor.
Aby ste nepremeškali termíny vývoja a vydania, vytvorte iné pravidlá a rôzne ukázať zátky — Kritériá na zastavenie procesu zostavovania v prípade slabých miest — pre rôzne prostredia. Napríklad chápeme, že aktuálna pobočka ide do vývojového stánku alebo UAT, čo znamená, že sa nezastavíme a povieme:
"Máte tu slabé miesta, ďalej už nepôjdete!"
V tomto bode je dôležité povedať vývojárom, že existujú bezpečnostné problémy, ktoré si vyžadujú pozornosť.
Prítomnosť zraniteľností nie je prekážkou pre ďalšie testovanie: manuál, integrácia alebo manuál. Na druhej strane musíme nejako zvýšiť bezpečnosť produktu, aby vývojári nezanedbávali to, čo považujú za bezpečné. Preto niekedy robíme toto: na stánku, keď je nasadený do vývojového prostredia, vývoj jednoducho upozorníme:
- Chlapci, máte problémy, prosím, venujte im pozornosť.
Vo fáze UAT opäť zobrazujeme upozornenia na zraniteľnosti a vo fáze vydania hovoríme:
- Chlapci, niekoľkokrát sme vás varovali, nič ste neurobili - s tým vás nepustíme.
Ak hovoríme o kóde a dynamike, potom je potrebné ukázať a varovať pred zraniteľnosťami iba tých funkcií a kódu, ktorý bol práve napísaný v tejto funkcii. Ak vývojár posunie tlačidlo o 3 pixely a my mu povieme, že tam má SQL injekciu, a preto ho treba urgentne opraviť, je to nesprávne. Pozrite sa len na to, čo je napísané teraz a na zmenu, ktorá príde do aplikácie.
Povedzme, že máme určitú funkčnú chybu – spôsob, akým by aplikácia nemala fungovať: peniaze sa neprevedú, po kliknutí na tlačidlo neprejde na ďalšiu stránku alebo sa nenačíta produkt. Bezpečnostné chyby - sú to tie isté chyby, ale nie z hľadiska prevádzky aplikácie, ale z hľadiska bezpečnosti.
Nie všetky problémy s kvalitou softvéru sú bezpečnostnými problémami. Všetky bezpečnostné problémy však súvisia s kvalitou softvéru. Sherif Mansour, Expedia.
Keďže všetky zraniteľnosti sú rovnaké chyby, mali by byť umiestnené na rovnakom mieste ako všetky vývojové chyby. Zabudnite teda na správy a strašidelné PDF, ktoré nikto nečíta.
Keď som pracoval vo vývojárskej spoločnosti, dostal som správu od nástrojov na statickú analýzu. Otvoril som, zhrozil som sa, uvaril kávu, prelistoval 350 strán, zavrel a pokračoval v práci. Veľké správy sú mŕtve správy. Zvyčajne nikam nevedú, listy sú vymazané, zabudnuté, stratené alebo podnik hovorí, že akceptuje riziká.
Čo robiť? Potvrdené defekty, ktoré sme našli, jednoducho prevedieme do formy vhodnej pre vývoj, napríklad ich vložíme do backlogu v Jire. Uprednostňujeme chyby a odstraňujeme ich v poradí podľa priority spolu s funkčnými chybami a skúšobnými chybami.
Statická analýza - SAST
Toto je analýza kódu pre slabé miesta., ale nie je to to isté ako SonarQube. Nekontrolujeme len vzory alebo štýl. Pri analýze sa používa množstvo prístupov: podľa stromu zraniteľnosti, podľa , analýzou konfiguračných súborov. To je všetko, čo sa týka samotného kódu.
Plusy prístupu: identifikácia zraniteľností v kóde v ranom štádiu vývojakeď ešte nie sú stojany ani hotové nástroje, a schopnosť prírastkového skenovania: skenovanie časti kódu, ktorá sa zmenila, a iba funkcia, ktorú práve robíme, čo skracuje čas skenovania.
Zápory - ide o nedostatočnú podporu pre potrebné jazyky.
Potrebné integrácie, čo by podľa môjho subjektívneho názoru malo byť v nástrojoch:
- Integračný nástroj: Jenkins, TeamCity a Gitlab CI.
- Vývojové prostredie: Intellij IDEA, Visual Studio. Pre vývojára je pohodlnejšie neorientovať sa v nezrozumiteľnom rozhraní, ktoré si stále potrebuje zapamätať, ale vidieť všetky potrebné integrácie a zraniteľnosti, ktoré našiel priamo na pracovisku vo vlastnom vývojovom prostredí.
- Kontrola kódu: SonarQube a manuálna kontrola.
- Sledovači defektov: Jira a Bugzilla.
Na obrázku sú niektorí z najlepších predstaviteľov statickej analýzy.
Nie sú dôležité nástroje, ale proces, takže existujú riešenia s otvoreným zdrojom, ktoré sú dobré aj na testovanie procesu.
SAST Open Source nenájde veľké množstvo zraniteľností alebo komplexných dátových tokov, ale môžu a mali by byť použité pri budovaní procesu. Pomáhajú pochopiť, ako bude proces vytvorený, kto bude reagovať na chyby, kto bude hlásiť a kto bude hlásiť. Ak chcete vykonať počiatočnú fázu budovania bezpečnosti vášho kódu, použite riešenia Open Source.
Ako to možno integrovať, ak ste na začiatku svojej cesty a nemáte nič: žiadne CI, žiadne Jenkins, žiadne TeamCity? Uvažujme o integrácii do procesu.
Integrácia na úrovni CVS
Ak máte Bitbucket alebo GitLab, môžete sa integrovať na úrovni .
Podľa udalosti - vytiahnuť žiadosť, zaviazať sa. Naskenujete kód a stav zostavenia ukáže, či bezpečnostná kontrola prešla alebo zlyhala.
Spätná väzba. Samozrejme, spätná väzba je vždy potrebná. Ak ste práve vykonali zabezpečenie na boku, vložili ste to do krabice a nikomu ste o tom nič nepovedali a potom na konci mesiaca vyhodili veľa chýb - nie je to správne a nie je to dobré.
Integrácia so systémom kontroly kódu
Kedysi sme pôsobili ako predvolený kontrolór pre technického používateľa AppSec v mnohých dôležitých projektoch. V závislosti od toho, či sú v novom kóde identifikované chyby alebo neexistujú žiadne chyby, kontrolór nastaví stav žiadosti o stiahnutie na „prijať“ alebo „potrebovať prácu“ – buď je všetko v poriadku, alebo odkazy na to, čo presne treba zlepšiť je potrebné zlepšiť. Pre integráciu s verziou, ktorá sa chystá do výroby, sme povolili zákaz zlúčenia, ak neprejde test informačnej bezpečnosti. Zahrnuli sme to do manuálnej kontroly kódu a ostatní účastníci procesu videli stavy zabezpečenia pre tento konkrétny proces.
Integrácia so SonarQube
Mnohí majú z hľadiska kvality kódu. Tu je to rovnaké - rovnaké brány môžete vytvoriť iba pre nástroje SAST. Bude tam rovnaké rozhranie, rovnaká kvalitná brána, len sa bude volať bezpečnostná brána. A tiež, ak máte proces využívajúci SonarQube, môžete tam všetko jednoducho integrovať.
Integrácia na úrovni KI
Všetko je tu tiež celkom jednoduché:
- Na úrovni autotestov, jednotkové testy.
- Rozdelenie podľa vývojových etáp: vývoj, test, prod. Môžu byť zahrnuté rôzne sady pravidiel alebo rôzne zlyhania: zastavte zostavu, nezastavujte zostavu.
- Synchrónne/asynchrónne spustenie. Čakáme na koniec bezpečnostných testov alebo nie. To znamená, že sme ich len spustili a ideme ďalej a potom dostaneme stav, že všetko je dobré alebo zlé.
Všetko je to v dokonalom ružovom svete. V skutočnom živote nič také neexistuje, ale snažíme sa. Výsledok spustených bezpečnostných kontrol by mal byť podobný výsledkom jednotkových testov.
Napríklad sme vzali veľký projekt a rozhodli sme sa, že ho teraz naskenujeme pomocou SAST - OK. Tento projekt sme pretlačili do SAST, dal nám 20 000 zraniteľností a ráznym rozhodnutím sme sa rozhodli, že je všetko v poriadku. 20 000 zraniteľností je náš technický dlh. Dlh dáme do krabice, pomaly ho vyčistíme a pridáme chyby do sledovačov defektov. Najmime si firmu, urobme si všetko sami, alebo nech nám pomôžu šampióni bezpečnosti – a technický dlh sa zníži.
A všetky novo vznikajúce zraniteľnosti v novom kóde musia byť odstránené rovnakým spôsobom ako chyby v jednotke alebo v autotestoch. Relatívne povedané, montáž začala, spustili sme ju, dva testy a dva bezpečnostné testy zlyhali. OK - šli sme, pozreli sme sa, čo sa stalo, opravili jednu vec, opravili ďalšiu, spustili sme to nabudúce - všetko bolo v poriadku, neobjavili sa žiadne nové zraniteľnosti, nezlyhali žiadne testy. Ak je táto úloha hlbšia a musíte jej dobre porozumieť, alebo oprava zraniteľností ovplyvňuje veľké vrstvy toho, čo sa skrýva pod kapotou: do nástroja na sledovanie defektov bola pridaná chyba, je uprednostnená a opravená. Bohužiaľ, svet nie je dokonalý a testy niekedy zlyhávajú.
Príkladom bezpečnostnej brány je analógia kvalitnej brány z hľadiska prítomnosti a počtu zraniteľností v kóde.
Integrujeme sa so SonarQube - doplnok je nainštalovaný, všetko je veľmi pohodlné a cool.
Integrácia s vývojovým prostredím
Možnosti integrácie:
- Spustenie kontroly z vývojového prostredia pred potvrdením.
- Zobraziť výsledky.
- Analýza výsledkov.
- Synchronizácia so serverom.
Takto vyzerá prijímanie výsledkov zo servera.
V našom vývojovom prostredí jednoducho sa objaví ďalšia položka, ktorá vás informuje, že počas kontroly boli zistené takéto zraniteľnosti. Môžete okamžite upraviť kód, pozrieť sa na odporúčania a . To všetko sa nachádza na pracovisku vývojára, čo je veľmi výhodné - nie je potrebné sledovať ďalšie odkazy a pozerať sa na niečo ďalšie.
Open Source
Toto je moja obľúbená téma. Každý používa knižnice s otvoreným zdrojovým kódom – načo písať kopu barlí a bicyklov, keď si môžete vziať hotovú knižnicu, v ktorej je už všetko implementované?
To je, samozrejme, pravda, ale aj knižnice píšu ľudia, zahŕňajú aj určité riziká a sú tam aj slabiny, ktoré sú pravidelne, alebo neustále hlásené. Preto je tu ďalší krok v Aplikačnej bezpečnosti – to je analýza Open Source komponentov.
Open Source analýza - OSA
Nástroj obsahuje tri veľké stupne.
Hľadanie zraniteľností v knižniciach. Nástroj napríklad vie, že používame nejakú knižnicu, a to v alebo existujú nejaké zraniteľnosti v nástrojoch na sledovanie chýb, ktoré sa týkajú tejto verzie knižnice. Keď sa ho pokúsite použiť, nástroj vydá varovanie, že knižnica je zraniteľná, a odporučí vám použiť inú verziu, ktorá nemá chyby zabezpečenia.
Analýza čistoty licencií. To tu zatiaľ nie je obzvlášť populárne, ale ak pracujete v zahraničí, tak tam z času na čas môžete dostať daň za používanie open source komponentu, ktorý sa nedá použiť ani upraviť. Podľa zásad licencovanej knižnice to nemôžeme urobiť. Alebo, ak sme ho upravili a použili, mali by sme uverejniť náš kód. Samozrejme, nikto nechce zverejniť kód svojich produktov, ale aj pred tým sa môžete chrániť.
Analýza komponentov, ktoré sa používajú v priemyselnom prostredí. Predstavme si hypotetickú situáciu, že sme konečne dokončili vývoj a vydali najnovšie vydanie našej mikroslužby. Žije sa tam úžasne - týždeň, mesiac, rok. Nezbierame to, nevykonávame bezpečnostné kontroly, všetko sa zdá byť v poriadku. Zrazu sa však dva týždne po vydaní objavila kritická zraniteľnosť v komponente Open Source, ktorý používame v tejto konkrétnej zostave, v priemyselnom prostredí. Ak nezaznamenáme, čo a kde používame, túto zraniteľnosť jednoducho neuvidíme. Niektoré nástroje majú schopnosť monitorovať zraniteľné miesta v knižniciach, ktoré sa v súčasnosti v tomto odvetví využívajú. Je to veľmi užitočné.
vlastnosti:
- Rôzne politiky pre rôzne štádiá vývoja.
- Monitorovanie komponentov v priemyselnom prostredí.
- Kontrola knižníc v rámci organizácie.
- Podpora pre rôzne zostavovacie systémy a jazyky.
- Analýza obrázkov Docker.
Niekoľko príkladov lídrov v odvetví, ktorí sa zaoberajú analýzou otvoreného zdroja.
Jediná bezplatná je táto z OWASP. V prvých fázach ho môžete zapnúť, uvidíte, ako funguje a čo podporuje. V podstate sú to všetko cloudové produkty, alebo on-premise, no za ich základňou sa stále posielajú na internet. Na svoj server neposielajú vaše knižnice, ale haše alebo svoje vlastné hodnoty, ktoré vypočítavajú, a odtlačky prstov, aby získali informácie o prítomnosti zraniteľností.
Procesná integrácia
Kontrola obvodu knižníc, ktoré sú stiahnuté z externých zdrojov. Máme externé a interné úložiská. Napríklad Event Central prevádzkuje Nexus a my chceme zabezpečiť, aby v našom úložisku neboli žiadne zraniteľné miesta so stavom „kritický“ alebo „vysoký“. Proxy môžete nakonfigurovať pomocou nástroja Nexus Firewall Lifecycle tak, aby boli takéto zraniteľnosti odrezané a neskončili v internom úložisku.
Integrácia do KI. Na rovnakej úrovni s autotestmi, unit testami a rozdelením na vývojové stupne: dev, test, prod. V každej fáze si môžete stiahnuť ľubovoľné knižnice, použiť čokoľvek, ale ak je v „kritickom“ stave niečo ťažké, možno stojí za to upozorniť vývojárov na to vo fáze vydania do výroby.
Integrácia s artefaktmi: Nexus a JFrog.
Integrácia do vývojového prostredia. Nástroje, ktoré si vyberiete, by mali mať integráciu s vývojovými prostrediami. Vývojár musí mať prístup k výsledkom skenovania zo svojho pracoviska alebo možnosť naskenovať a skontrolovať kód sám, či neobsahuje zraniteľné miesta predtým, ako sa zapojí do CVS.
Integrácia CD. Toto je skvelá funkcia, ktorá sa mi veľmi páči a o ktorej som už hovoril – sledovanie vzniku nových zraniteľností v priemyselnom prostredí. Funguje to nejako takto.
Máme Verejné úložiská komponentov — niektoré nástroje zvonku a naše interné úložisko. Chceme, aby obsahoval iba dôveryhodné komponenty. Pri proxy serveri skontrolujeme, či stiahnutá knižnica nemá slabé miesta. Ak spadá pod určité pravidlá, ktoré nastavíme a nevyhnutne koordinujeme s vývojom, nenahrávame ho a sme vyzvaní, aby sme použili inú verziu. Preto, ak je v knižnici niečo skutočne kritické a zlé, vývojár nedostane knižnicu vo fáze inštalácie - nechajte ho použiť vyššiu alebo nižšiu verziu.
- Pri stavaní kontrolujeme, či sa nikomu nič zlé nezošmyklo, či sú všetky komponenty bezpečné a nikto na flash disk nepriniesol nič nebezpečné.
- V úložisku máme iba dôveryhodné komponenty.
- Pri nasadzovaní ešte raz skontrolujeme samotný balík: war, jar, DL alebo obrázok Docker, aby sme sa uistili, že je v súlade s politikou.
- Pri vstupe do odvetvia sledujeme, čo sa deje v priemyselnom prostredí: kritické zraniteľnosti sa objavujú alebo sa neobjavujú.
Dynamická analýza - DAST
Nástroje dynamickej analýzy sa zásadne líšia od všetkého, čo bolo povedané predtým. Ide o druh napodobňovania práce používateľa s aplikáciou. Ak ide o webovú aplikáciu, posielame požiadavky, simulujeme prácu klienta, klikáme na tlačidlá na prednej strane, posielame umelé údaje z formulára: úvodzovky, zátvorky, znaky v rôznych kódovaniach, aby sme videli, ako aplikácia funguje a spracováva externých údajov.
Rovnaký systém vám umožňuje kontrolovať zraniteľnosti šablón v Open Source. Keďže DAST nevie, ktorý otvorený zdroj používame, jednoducho vyvolá „škodlivé“ vzory a analyzuje odpovede servera:
- Áno, je tu problém s deserializáciou, ale nie tu.
Sú v tom veľké riziká, pretože ak vykonáte tento bezpečnostný test na tej istej lavici, s ktorou pracujú testeri, môžu sa stať nepríjemné veci.
- Vysoké zaťaženie siete aplikačného servera.
- Žiadne integrácie.
- Schopnosť zmeniť nastavenia analyzovanej aplikácie.
- Chýba podpora potrebných technológií.
- Ťažkosti s nastavením.
Mali sme situáciu, keď sme konečne spustili AppScan: dlho sme sa pokúšali získať prístup k aplikácii, získali sme 3 účty a boli sme šťastní - konečne všetko skontrolujeme! Spustili sme skenovanie a prvá vec, ktorú AppScan urobil, bolo, že vošiel do administračného panela, prepichol všetky tlačidlá, zmenil polovicu údajov a potom úplne zabil server pomocou -žiadosti. Vývoj s testovaním povedal:
- Chlapci, robíte si srandu?! Dali sme vám účty a vy ste postavili stánok!
Zvážte možné riziká. Ideálne je pripraviť samostatný stojan na testovanie informačnej bezpečnosti, ktorý bude aspoň nejako izolovaný od zvyšku prostredia a podmienečne skontrolovať admin panel, najlepšie v manuálnom režime. Toto je pentest – tie zostávajúce percentá úsilia, o ktorých teraz neuvažujeme.
Stojí za zváženie, že to môžete použiť ako analóg testovania záťaže. V prvej fáze môžete zapnúť dynamický skener s 10-15 vláknami a uvidíte, čo sa stane, ale zvyčajne, ako ukazuje prax, nič dobré.
Niekoľko zdrojov, ktoré zvyčajne používame.
Stojí za to vyzdvihnúť je „švajčiarsky nôž“ pre každého bezpečnostného profesionála. Používa to každý a je to veľmi pohodlné. Teraz bola vydaná nová demo verzia podnikovej edície. Ak to bol predtým iba samostatný nástroj s pluginmi, teraz vývojári konečne vytvárajú veľký server, z ktorého bude možné spravovať niekoľko agentov. To je super, odporúčam vyskúšať.
Procesná integrácia
Integrácia prebieha celkom dobre a jednoducho: spustiť skenovanie po úspešnej inštalácii aplikácie pre stojan a skenovanie po úspešnom testovaní integrácie.
Ak integrácie nefungujú alebo existujú útržky a falošné funkcie, je to zbytočné a zbytočné – bez ohľadu na to, aký vzor pošleme, server bude stále reagovať rovnako.
- Ideálne samostatný testovací stojan.
- Pred testovaním si zapíšte postupnosť prihlásenia.
- Testovanie administračného systému je len manuálne.
Proces
Trochu zovšeobecnené o procese vo všeobecnosti a o práci každého nástroja zvlášť. Všetky aplikácie sú odlišné – jedna funguje lepšie s dynamickou analýzou, iná so statickou analýzou, tretia s OpenSource analýzou, pentestami alebo niečo úplne iné, napríklad udalosti s .
Každý proces potrebuje kontrolu.
Aby ste pochopili, ako proces funguje a kde ho možno zlepšiť, musíte zbierať metriky zo všetkého, čo vám príde pod ruku, vrátane výrobných metrík, metrík z nástrojov a zo zariadení na sledovanie defektov.
Každá informácia je užitočná. Je potrebné pozrieť sa z rôznych uhlov na to, kde je lepšie použiť ten či onen nástroj, kde sa proces konkrétne prepadá. Možno by stálo za to pozrieť sa na časy odozvy vývoja, aby ste zistili, kde je možné zlepšiť proces na základe času. Čím viac údajov, tým viac sekcií je možné zostaviť od najvyššej úrovne až po detaily každého procesu.
Keďže všetky statické a dynamické analyzátory majú svoje vlastné API, svoje vlastné spúšťacie metódy, princípy, niektoré majú plánovače, iné nie – píšeme nástroj AppSec Orchestrator, ktorý vám umožňuje vytvoriť z produktu jeden vstupný bod do celého procesu a riadiť ho z jedného bodu.
Manažéri, vývojári a bezpečnostní inžinieri majú jeden vstupný bod, z ktorého môžu vidieť, čo beží, nakonfigurovať a spustiť kontrolu, prijímať výsledky kontroly a odosielať požiadavky. Snažíme sa ustúpiť od papierovačiek, všetko preložiť do ľudského, čo využíva vývoj – stránky na Confluence so statusom a metrikami, defekty v Jira či v rôznych defekt trackeroch, či integrácia do synchrónneho/asynchrónneho procesu v CI /CD.
Kľúčové jedlá
Nástroje nie sú to hlavné. Najprv si premyslite proces - potom implementujte nástroje. Nástroje sú dobré, ale drahé, takže môžete začať s procesom a vybudovať komunikáciu a porozumenie medzi vývojom a bezpečnosťou. Z bezpečnostného hľadiska nie je potrebné všetko „zastavovať“, z hľadiska vývoja platí, že ak existuje niečo vysoko mega superkritické, tak to treba odstrániť a nezatvárať pred problémom oči.
Kvalita produktu - spoločný cieľ bezpečnosť aj rozvoj. Robíme jednu vec, snažíme sa, aby všetko fungovalo správne a nedochádzalo k reputačným rizikám či finančným stratám. To je dôvod, prečo podporujeme prístup DevSecOps, SecDevOps na zlepšenie komunikácie a zlepšenie kvality produktu.
Začnite s tým, čo už máte: požiadavky, architektúra, čiastkové kontroly, školenia, usmernenia. Nie je potrebné okamžite aplikovať všetky postupy na všetky projekty - pohybovať sa iteratívne. Neexistuje jediný štandard - experimentovať a skúšať rôzne prístupy a riešenia.
Medzi chybami informačnej bezpečnosti a funkčnými chybami existuje rovnaké znamienko.
Automatizujte všetkože sa pohybuje. Čokoľvek sa nehýbe, presuňte to a zautomatizujte to. Ak sa niečo robí ručne, nie je to dobrá súčasť procesu. Možno to stojí za to skontrolovať a zautomatizovať to.
Ak je veľkosť tímu IS malá - použite bezpečnostných šampiónov.
Možno vám to, o čom som hovoril, nebude vyhovovať a prídete s niečím vlastným – a to je dobre. ale vyberte nástroje na základe požiadaviek na váš proces. Nepozerajte sa na to, čo hovorí komunita, že tento nástroj je zlý a tento dobrý. Možno, že opak bude pravdou pre váš produkt.
Požiadavky na náradie.
- Nízka úroveň falošne pozitívne.
- Primeraný čas analýzy.
- Pohodlie použitia.
- Dostupnosť integrácií.
- Pochopenie plánu vývoja produktu.
- Možnosť prispôsobenia nástrojov.
Yuriho report bol vybraný ako jeden z najlepších na DevOpsConf 2018. Aby ste sa zoznámili s ešte zaujímavejšími nápadmi a praktickými prípadmi, príďte 27. a 28. mája do Skolkova v rámci . Ešte lepšie je, ak ste pripravení podeliť sa o svoje skúsenosti na správu do 21. apríla.
Zdroj: hab.com