Frika dhe urrejtja e DevSecOps

Ne kishim 2 analizues kodesh, 4 mjete testimi dinamike, zanatet tona dhe 250 skripta. Nuk është se e gjithë kjo është e nevojshme në procesin aktual, por sapo të filloni të zbatoni DevSecOps, duhet të shkoni deri në fund.

Burim. Krijuesit e personazheve: Justin Roiland dhe Dan Harmon.

Çfarë është SecDevOps? Po DevSecOps? Cilat janë dallimet? Siguria e aplikacionit - për çfarë bëhet fjalë? Pse nuk funksionon më qasja klasike? E di përgjigjen për të gjitha këto pyetje Yuri Shabalin nga Siguria e peshkut shpatë. Yuri do t'i përgjigjet gjithçkaje në detaje dhe do të analizojë problemet e kalimit nga modeli klasik i Sigurisë së Aplikimit në procesin DevSecOps: si t'i qaseni siç duhet integrimit të procesit të zhvillimit të sigurt në procesin DevOps dhe të mos prishni asgjë, si të kaloni fazat kryesore të testimit të sigurisë, cilat mjete mund të përdoren dhe çfarë ndryshojnë dhe si t'i konfiguroni ato në mënyrë korrekte për të shmangur grackat.

Rreth folësit: Yuri Shabalin - Arkitekt kryesor i sigurisë në kompani Siguria e peshkut shpatë. Përgjegjës për zbatimin e SSDL, për integrimin e përgjithshëm të mjeteve të analizës së aplikacionit në një ekosistem të unifikuar të zhvillimit dhe testimit. 7 vite eksperience ne sigurine e informacionit. Ka punuar në Alfa-Bank, Sberbank dhe Positive Technologies, e cila zhvillon softuer dhe ofron shërbime. Folës në konferencat ndërkombëtare ZerONights, PHDays, RISSPA, OWASP.

Siguria e aplikacionit: për çfarë bëhet fjalë?

Siguria e Aplikimit - Ky është seksioni i sigurisë që është përgjegjës për sigurinë e aplikacionit. Kjo nuk vlen për infrastrukturën ose sigurinë e rrjetit, por më tepër për atë që ne shkruajmë dhe për atë që zhvilluesit punojnë - këto janë mangësitë dhe dobësitë e vetë aplikacionit.

drejtim SDL ose SDLC - Cikli jetësor i zhvillimit të sigurisë - zhvilluar nga Microsoft. Diagrami tregon modelin kanonik SDLC, detyra kryesore e të cilit është pjesëmarrja e sigurisë në çdo fazë të zhvillimit, nga kërkesat deri te lëshimi dhe prodhimi. Microsoft e kuptoi se kishte shumë gabime në industri, kishte më shumë prej tyre dhe duhej bërë diçka për të, dhe ata propozuan këtë qasje, e cila është bërë kanonike.

Siguria e aplikacionit dhe SSDL nuk synojnë zbulimin e dobësive, siç besohet zakonisht, por parandalimin e shfaqjes së tyre. Me kalimin e kohës, qasja kanonike e Microsoft është përmirësuar, zhvilluar dhe futur në një zhytje më të thellë dhe më të detajuar.

SDLC kanonik është shumë i detajuar në metodologji të ndryshme - OpenSAMM, BSIMM, OWASP. Metodologjitë janë të ndryshme, por përgjithësisht të ngjashme.

Modeli i ndërtimit të sigurisë në maturim

Më pëlqen më së shumti BSIMM - Modeli i ndërtimit të sigurisë në maturim. Baza e metodologjisë është ndarja e procesit të Sigurisë së Aplikimit në 4 fusha: Qeverisja, Inteligjenca, pikat e kontaktit SSDL dhe vendosja. Çdo domen ka 12 praktika, të cilat përfaqësohen si 112 aktivitete.

Secila prej 112 aktiviteteve ka 3 nivele pjekurie: fillestar, mesatar dhe i avancuar. Ju mund të studioni të 12 praktikat seksion pas seksioni, të zgjidhni gjërat që janë të rëndësishme për ju, të kuptoni se si t'i zbatoni ato dhe të shtoni gradualisht elementë, për shembull, analizën statike dhe dinamike të kodit ose rishikimin e kodit. Ju shkruani një plan dhe punoni me qetësi sipas tij si pjesë e zbatimit të aktiviteteve të zgjedhura.

Pse DevSecOps

DevOps është një proces i përgjithshëm, i madh në të cilin duhet të merret parasysh siguria.

fillimisht DevOps përfshirë kontrollet e sigurisë. Në praktikë, numri i ekipeve të sigurisë ishte shumë më i vogël se tani, dhe ata nuk vepronin si pjesëmarrës në proces, por si një organ kontrolli dhe mbikëqyrës që i vendos kërkesat dhe kontrollon cilësinë e produktit në fund të lëshimit. Kjo është një qasje klasike në të cilën ekipet e sigurisë ishin prapa murit nga zhvillimi dhe nuk morën pjesë në proces.

Problemi kryesor është se siguria e informacionit është e ndarë nga zhvillimi. Zakonisht ky është një lloj qarku i sigurisë së informacionit dhe përmban 2-3 mjete të mëdha dhe të shtrenjta. Një herë në gjashtë muaj, vjen kodi burimor ose aplikacioni që duhet të kontrollohet dhe prodhohen një herë në vit pentestet. E gjithë kjo çon në faktin se data e lëshimit për industrinë është vonuar, dhe zhvilluesi është i ekspozuar ndaj një numri të madh dobësish nga mjetet e automatizuara. Është e pamundur të çmontoni dhe riparoni të gjitha këto, sepse rezultatet për gjashtë muajt e mëparshëm nuk u zgjidhën, por këtu është një grumbull i ri.

Gjatë punës së kompanisë sonë, ne shohim se siguria në të gjitha fushat dhe industritë e kupton se është koha për të kapur hapin dhe për t'u orientuar me zhvillimin në të njëjtën rrotë - në i shkathët. Paradigma e DevSecOps përshtatet në mënyrë të përkryer me metodologjinë e zhvillimit të shkathët, zbatimin, mbështetjen dhe pjesëmarrjen në çdo version dhe përsëritje.

Kalimi në DevSecOps

Fjala më e rëndësishme në ciklin jetësor të zhvillimit të sigurisë është "proces". Ju duhet ta kuptoni këtë përpara se të mendoni për blerjen e mjeteve.

Thjesht përfshirja e mjeteve në procesin DevOps nuk është e mjaftueshme - komunikimi dhe mirëkuptimi midis pjesëmarrësve të procesit është i rëndësishëm.

Njerëzit janë më të rëndësishëm, jo ​​mjetet.

Shpesh, planifikimi për një proces zhvillimi të sigurt fillon me zgjedhjen dhe blerjen e një mjeti dhe përfundon me përpjekjet për të integruar mjetin në procesin aktual, të cilat mbeten përpjekje. Kjo çon në pasoja fatkeqe, sepse të gjitha mjetet kanë karakteristikat dhe kufizimet e tyre.

Një rast i zakonshëm është kur departamenti i sigurisë zgjodhi një mjet të mirë, të shtrenjtë me aftësi të gjera dhe erdhi te zhvilluesit për ta integruar atë në proces. Por nuk funksionon - procesi është i strukturuar në atë mënyrë që kufizimet e mjetit të blerë tashmë të mos përshtaten në paradigmën aktuale.

Së pari, përshkruani se çfarë rezultati dëshironi dhe si do të duket procesi. Kjo do të ndihmojë në kuptimin e roleve të mjetit dhe sigurisë në proces.

Filloni me atë që është tashmë në përdorim

Para se të blini mjete të shtrenjta, shikoni atë që keni tashmë. Çdo kompani ka kërkesa sigurie për zhvillim, ka kontrolle, penteste - pse të mos e transformoni të gjithë këtë në një formë të kuptueshme dhe të përshtatshme për të gjithë?

Zakonisht kërkesat janë një Talmud letre që shtrihet në një raft. Kishte një rast kur erdhëm në një kompani për të parë proceset dhe kërkuam të shihnim kërkesat e sigurisë për softuerin. Specialisti që u mor me këtë kaloi një kohë të gjatë duke kërkuar:

- Tani, diku në shënime kishte një shteg ku qëndron ky dokument.

Si rezultat, ne e morëm dokumentin një javë më vonë.

Për kërkesat, kontrollet dhe gjëra të tjera, krijoni një faqe në p.sh. turmë - është i përshtatshëm për të gjithë.

Është më e lehtë të riformatosh atë që ke tashmë dhe ta përdorësh për të filluar.

Përdorni Champions Security

Në mënyrë tipike, në një kompani mesatare me 100-200 zhvillues, ekziston një specialist i sigurisë që kryen disa funksione dhe nuk ka kohë fizikisht për të kontrolluar gjithçka. Edhe nëse ai përpiqet më të mirën, ai i vetëm nuk do të kontrollojë të gjithë kodin që gjeneron zhvillimi. Për raste të tilla, është zhvilluar një koncept - Kampionët e sigurisë.

Kampionët e Sigurisë janë njerëz brenda ekipit të zhvillimit që janë të interesuar për sigurinë e produktit tuaj.

Kampioni i Sigurisë është një pikë hyrjeje në ekipin e zhvillimit dhe një ungjilltar sigurie i përfshirë në një.

Zakonisht, kur një specialist i sigurisë vjen në një ekip zhvillimi dhe tregon një gabim në kod, ai merr një përgjigje të befasuar:

- Dhe kush je ti? Po te shoh per here te pare. Gjithçka është në rregull me mua - miku im i vjetër më dha "aplikoni" në rishikimin e kodit, ne vazhdojmë!

Kjo është një situatë tipike, sepse ka shumë më tepër besim te të moshuarit ose thjesht shokët e skuadrës me të cilët zhvilluesi ndërvepron vazhdimisht në punë dhe në rishikimin e kodit. Nëse në vend të oficerit të sigurimit, kampioni i Sigurimit tregon gabimin dhe pasojat, atëherë fjala e tij do të ketë më shumë peshë.

Gjithashtu, zhvilluesit e dinë kodin e tyre më mirë se çdo specialist i sigurisë. Për një person që ka të paktën 5 projekte në një mjet analize statike, zakonisht është e vështirë të kujtosh të gjitha nuancat. Kampionët e sigurisë e dinë produktin e tyre: çfarë ndërvepron me atë dhe çfarë duhet parë në fillim - ato janë më efektive.

Pra, merrni parasysh zbatimin e Kampionëve të Sigurisë dhe zgjerimin e ndikimit të ekipit tuaj të sigurisë. Kjo është gjithashtu e dobishme për vetë kampionin: zhvillimi profesional në një fushë të re, zgjerimi i horizontit teknik, përmirësimi i aftësive teknike, menaxheriale dhe drejtuese, rritja e vlerës së tregut. Ky është një element i inxhinierisë sociale, "sytë" tuaj në ekipin e zhvillimit.

Fazat e testimit

Paradigma 20 deri në 80 thotë se 20% e përpjekjeve prodhon 80% të rezultateve. Ky 20% është praktika e analizës së aplikacioneve që mund dhe duhet të automatizohen. Shembuj të aktiviteteve të tilla janë analiza statike - SAST, analiza dinamike - DAST и Kontrolli me burim të hapur. Do t'ju tregoj më në detaje për aktivitetet, si dhe për mjetet, cilat veçori hasim zakonisht kur i futim në proces dhe si ta bëjmë atë në mënyrë korrekte.

Problemet kryesore të mjeteve

Do të nënvizoj problemet që janë të rëndësishme për të gjitha instrumentet dhe kërkojnë vëmendje. Do t'i analizoj më hollësisht për të mos i përsëritur më tej.

Kohë e gjatë e analizës. Nëse nga angazhimi deri në lëshim duhen 30 minuta për të gjitha testet dhe montimin, atëherë kontrollet e sigurisë së informacionit do të zgjasin një ditë. Kështu që askush nuk do ta ngadalësojë procesin. Merrni parasysh këtë veçori dhe nxirrni përfundime.

Niveli i lartë False Negative ose False Pozitive. Të gjitha produktet janë të ndryshme, të gjitha përdorin korniza të ndryshme dhe stilin e tyre të kodimit. Në baza dhe teknologji të ndryshme kodesh, mjetet mund të tregojnë nivele të ndryshme të False Negative dhe False Positive. Pra, shikoni se çfarë saktësisht është në e juaj kompanitë dhe për e juaja aplikacionet do të tregojnë rezultate të mira dhe të besueshme.

Asnjë integrim me mjetet ekzistuese. Shikoni mjetet për sa i përket integrimeve me ato që përdorni tashmë. Për shembull, nëse keni Jenkins ose TeamCity, kontrolloni integrimin e mjeteve me këtë softuer, dhe jo me GitLab CI, të cilin nuk e përdorni.

Mungesa ose kompleksiteti i tepërt i personalizimit. Nëse një mjet nuk ka një API, atëherë pse është i nevojshëm? Çdo gjë që mund të bëhet në ndërfaqe duhet të jetë e disponueshme përmes API-së. Në mënyrë ideale, mjeti duhet të ketë aftësinë për të personalizuar kontrollet.

Nuk ka udhërrëfyes për zhvillimin e produktit. Zhvillimi nuk qëndron ende, ne jemi gjithmonë duke përdorur korniza dhe funksione të reja, duke rishkruar kodin e vjetër në gjuhë të reja. Ne duam të jemi të sigurt se mjeti që blejmë do të mbështesë korniza dhe teknologji të reja. Prandaj, është e rëndësishme të dini se produkti është i vërtetë dhe i saktë Udhërrëfyesi zhvillimin.

Karakteristikat e procesit

Përveç veçorive të mjeteve, merrni parasysh veçoritë e procesit të zhvillimit. Për shembull, pengimi i zhvillimit është një gabim i zakonshëm. Le të shohim se cilat veçori të tjera duhet të merren parasysh dhe çfarë duhet t'i kushtojë vëmendje ekipi i sigurisë.

Për të mos humbur afatet e zhvillimit dhe lëshimit, krijoni rregulla të ndryshme dhe të ndryshme tregojnë ndalesat — kriteret për ndalimin e procesit të ndërtimit në prani të dobësive — për ambiente të ndryshme. Për shembull, ne e kuptojmë se dega aktuale shkon në stendën e zhvillimit ose UAT, që do të thotë se ne nuk ndalemi dhe themi:

"Ju keni dobësi këtu, nuk do të shkoni askund më tej!"

Në këtë pikë, është e rëndësishme t'u thuash zhvilluesve se ka çështje sigurie që kërkojnë vëmendje.

Prania e dobësive nuk është pengesë për testime të mëtejshme: manual, integrim ose manual. Nga ana tjetër, ne duhet të rrisim disi sigurinë e produktit dhe në mënyrë që zhvilluesit të mos lënë pas dore atë që ata e shohin të sigurt. Prandaj, ndonjëherë ne e bëjmë këtë: në stendë, kur ajo është hedhur në mjedisin e zhvillimit, ne thjesht njoftojmë zhvillimin:

- Djema, keni probleme, ju lutemi kushtojini vëmendje atyre.

Në fazën UAT ne përsëri tregojmë paralajmërime për dobësitë, dhe në fazën e lëshimit themi:

- Djema, ne ju paralajmëruam disa herë, nuk keni bërë asgjë - ne nuk do t'ju lëmë të dilni me këtë.

Nëse flasim për kodin dhe dinamikën, atëherë është e nevojshme të tregojmë dhe paralajmërojmë për dobësitë vetëm të atyre veçorive dhe kodeve që sapo janë shkruar në këtë veçori. Nëse një zhvillues lëviz një buton me 3 piksel dhe ne i themi se ai ka një injeksion SQL atje dhe për këtë arsye duhet të rregullohet urgjentisht, kjo është e gabuar. Shikoni vetëm atë që është shkruar tani dhe ndryshimin që vjen në aplikacion.

Le të themi se kemi një defekt të caktuar funksional - mënyra se si aplikacioni nuk duhet të funksionojë: paratë nuk transferohen, kur klikoni në një buton nuk ka kalim në faqen tjetër, ose produkti nuk ngarkohet. Defektet e sigurisë - këto janë të njëjtat defekte, por jo në aspektin e funksionimit të aplikacionit, por në siguri.

Jo të gjitha problemet e cilësisë së softuerit janë probleme sigurie. Por të gjitha problemet e sigurisë lidhen me cilësinë e softuerit. Sherif Mansour, Expedia.

Meqenëse të gjitha dobësitë janë të njëjtat defekte, ato duhet të vendosen në të njëjtin vend si të gjitha defektet e zhvillimit. Pra, harroni raportet dhe PDF-të e frikshme që askush nuk i lexon.

Kur punoja në një kompani zhvillimi, mora një raport nga mjetet e analizës statike. E hapa, u tmerrova, bëra kafe, shfletova 350 faqe, e mbylla dhe vazhdova punën. Raportet e mëdha janë raporte të vdekura. Zakonisht nuk shkojnë askund, letrat fshihen, harrohen, humbasin ose biznesi thotë se i pranon rreziqet.

Çfarë duhet bërë? Ne thjesht i konvertojmë defektet e konfirmuara që gjetëm në një formë të përshtatshme për zhvillim, për shembull, i vendosim ato në një grumbull të mbetur në Jira. Ne i japim përparësi defekteve dhe i eliminojmë ato sipas prioritetit, së bashku me defektet funksionale dhe defektet e testimit.

Analiza Statike - SAST

Kjo është një analizë kodi për dobësitë., por nuk është njësoj si SonarQube. Ne nuk kontrollojmë vetëm për modelet apo stilin. Në analizë përdoren një sërë qasjesh: sipas pemës së cenueshmërisë, sipas Rrjedha e të Dhënave, duke analizuar skedarët e konfigurimit. Kjo është gjithçka që ka të bëjë me vetë kodin.

Të mirat e qasjes: identifikimi i dobësive në kod në një fazë të hershme të zhvillimitkur nuk ka ende stenda apo mjete të gatshme dhe aftësia e skanimit në rritje: skanimi i një seksioni të kodit që ka ndryshuar dhe vetëm funksioni që po bëjmë aktualisht, i cili redukton kohën e skanimit.

Cons - kjo është mungesa e mbështetjes për gjuhët e nevojshme.

Integrimet e nevojshme, e cila duhet të jetë në mjete, sipas mendimit tim subjektiv:

• Mjeti i integrimit: Jenkins, TeamCity dhe Gitlab CI.
• Mjedisi i zhvillimit: Intellij IDEA, Visual Studio. Është më i përshtatshëm për një zhvillues që të mos lundrojë në një ndërfaqe të pakuptueshme që ende duhet të memorizohet, por të shohë të gjitha integrimet dhe dobësitë e nevojshme që ai ka gjetur pikërisht në vendin e punës në mjedisin e tij të zhvillimit.
• Rishikimi i kodit: SonarQube dhe rishikimi manual.
• Gjurmuesit e defekteve: Jira dhe Bugzilla.

Fotografia tregon disa nga përfaqësuesit më të mirë të analizës statike.

Nuk janë mjetet që janë të rëndësishme, por procesi, kështu që ka zgjidhje me burim të hapur që janë gjithashtu të mira për testimin e procesit.

SAST Open Source nuk do të gjejë një numër të madh dobësish ose DataFlows komplekse, por ato mund dhe duhet të përdoren gjatë ndërtimit të një procesi. Ato ndihmojnë për të kuptuar se si do të ndërtohet procesi, kush do t'i përgjigjet gabimeve, kush do të raportojë dhe kush do të raportojë. Nëse dëshironi të kryeni fazën fillestare të ndërtimit të sigurisë së kodit tuaj, përdorni zgjidhjet me burim të hapur.

Si mund të integrohet kjo nëse jeni në fillim të udhëtimit tuaj dhe nuk keni asgjë: pa CI, pa Jenkins, pa TeamCity? Le të shqyrtojmë integrimin në proces.

Integrimi i nivelit CVS

Nëse keni Bitbucket ose GitLab, mund të integroheni në nivel Sistemi i versioneve të njëkohshme.

Sipas ngjarjes - tërheq kërkesë, angazhohem. Ju skanoni kodin dhe statusi i ndërtimit tregon nëse kontrolli i sigurisë kaloi apo dështoi.

Komente Natyrisht, reagimet janë gjithmonë të nevojshme. Nëse thjesht keni bërë siguri në anën, vendoseni në një kuti dhe nuk i keni treguar askujt asgjë për të, dhe më pas në fund të muajit hodhët një tufë defektesh - kjo nuk është e saktë dhe jo e mirë.

Integrimi me sistemin e rishikimit të kodit

Një herë, ne vepruam si rishikues i paracaktuar për një përdorues teknik të AppSec në një numër projektesh të rëndësishme. Në varësi të faktit nëse gabimet janë identifikuar në kodin e ri ose nuk ka gabime, rishikuesi vendos statusin në kërkesën e tërheqjes për të "pranuar" ose "duhet punë" - ose gjithçka është në rregull, ose lidhjet me atë që saktësisht duhet të përmirësohet duhet të përmirësohen. Për integrimin me versionin që është duke hyrë në prodhim, ne kemi mundësuar një ndalim bashkimi nëse testi i sigurisë së informacionit nuk kalon. Ne e përfshimë këtë në rishikimin manual të kodit dhe pjesëmarrësit e tjerë në proces panë statuset e sigurisë për këtë proces të veçantë.

Integrimi me SonarQube

Shumë kanë porta cilësore për sa i përket cilësisë së kodit. Është e njëjta gjë këtu - mund të bëni të njëjtat porta vetëm për mjetet SAST. Do të ketë të njëjtën ndërfaqe, të njëjtën portë cilësore, vetëm ajo do të quhet porta e sigurisë. Dhe gjithashtu, nëse keni një proces duke përdorur SonarQube, mund të integroni lehtësisht gjithçka atje.

Integrimi në nivel CI

Gjithçka këtu është gjithashtu mjaft e thjeshtë:

• Në të njëjtin nivel me autotestet, testet e njësisë.
• Ndarja sipas fazave të zhvillimit: dev, test, prod. Mund të përfshihen grupe të ndryshme rregullash ose kushte të ndryshme dështimi: ndaloni montimin, mos e ndaloni montimin.
• Nisja sinkron/asinkron. Jemi në pritje të përfundimit të testeve të sigurisë apo jo. Kjo do të thotë, ne thjesht i kemi lëshuar ato dhe vazhdojmë përpara, dhe më pas marrim statusin se gjithçka është e mirë ose e keqe.

Është e gjitha në një botë të përsosur rozë. Nuk ka një gjë të tillë në jetën reale, por ne përpiqemi. Rezultati i kryerjes së kontrolleve të sigurisë duhet të jetë i ngjashëm me rezultatet e testeve të njësisë.

Për shembull, morëm një projekt të madh dhe vendosëm që tani do ta skanojmë me SAST - OK. Ne e shtymë këtë projekt në SAST, ai na dha 20 dobësi dhe me një vendim me vullnet të fortë vendosëm që gjithçka ishte në rregull. 000 dobësi janë borxhi ynë teknik. Ne do ta vendosim borxhin në një kuti, do ta pastrojmë ngadalë dhe do të shtojmë defekte në gjurmuesit e defekteve. Le të punësojmë një kompani, të bëjmë gjithçka vetë ose të na ndihmojnë Kampionët e Sigurisë - dhe borxhi teknik do të ulet.

Dhe të gjitha dobësitë e reja të shfaqura në kodin e ri duhet të eliminohen në të njëjtën mënyrë si gabimet në një njësi ose në autoteste. Relativisht filloi montimi, e bëmë, dy teste dhe dy teste sigurie dështuan. OK - shkuam, shikuam se çfarë ndodhi, rregulluam një gjë, rregulluam një tjetër, e ekzekutuam herën tjetër - gjithçka ishte mirë, nuk u shfaqën dobësi të reja, asnjë test nuk dështoi. Nëse kjo detyrë është më e thellë dhe ju duhet ta kuptoni mirë, ose ndreqja e dobësive ndikon në shtresa të mëdha të asaj që ndodhet nën kapuç: një defekt është shtuar në gjurmuesin e defekteve, ai jepet përparësi dhe korrigjohet. Fatkeqësisht, bota nuk është e përsosur dhe testet ndonjëherë dështojnë.

Një shembull i një porte sigurie është një analog i një porte cilësore, për sa i përket pranisë dhe numrit të dobësive në kod.

Ne integrohemi me SonarQube - shtojca është instaluar, gjithçka është shumë e përshtatshme dhe e lezetshme.

Integrimi me mjedisin e zhvillimit

Opsionet e integrimit:

• Kryerja e një skanimi nga mjedisi i zhvillimit përpara kryerjes.
• Shiko rezultatet.
• Analiza e rezultateve.
• Sinkronizimi me serverin.

Kështu duket të marrësh rezultate nga serveri.

Në mjedisin tonë të zhvillimit IDE e intelektit thjesht shfaqet një artikull shtesë që ju informon se dobësi të tilla janë zbuluar gjatë skanimit. Ju mund të modifikoni menjëherë kodin, të shikoni rekomandimet dhe Grafiku i rrjedhës. E gjithë kjo ndodhet në vendin e punës të zhvilluesit, i cili është shumë i përshtatshëm - nuk ka nevojë të ndiqni lidhje të tjera dhe të shikoni diçka shtesë.

Open Source

Kjo është tema ime e preferuar. Të gjithë përdorin biblioteka me burim të hapur - pse të shkruani një mori patericash dhe biçikletash kur mund të merrni një bibliotekë të gatshme në të cilën gjithçka është zbatuar tashmë?

Sigurisht, kjo është e vërtetë, por bibliotekat shkruhen gjithashtu nga njerëz, ato gjithashtu përfshijnë rreziqe të caktuara dhe ka gjithashtu dobësi që raportohen periodikisht, ose vazhdimisht. Prandaj, ekziston hapi tjetër në Sigurinë e Aplikimit - kjo është analiza e komponentëve me burim të hapur.

Analiza me burim të hapur - OSA

Mjeti përfshin tre faza të mëdha.

Kërkimi i dobësive në biblioteka. Për shembull, mjeti e di se ne jemi duke përdorur një bibliotekë, dhe se në CVE ose ka disa dobësi në gjurmuesit e gabimeve që lidhen me këtë version të bibliotekës. Kur përpiqeni ta përdorni, mjeti do të lëshojë një paralajmërim se biblioteka është e cenueshme dhe ju këshillon të përdorni një version tjetër që nuk ka dobësi.

Analiza e pastërtisë së licencës. Kjo nuk është ende veçanërisht e popullarizuar këtu, por nëse punoni jashtë vendit, atëherë herë pas here mund të merrni një taksë atje për përdorimin e një komponenti me burim të hapur që nuk mund të përdoret ose modifikohet. Sipas politikës së bibliotekës së licencuar, ne nuk mund ta bëjmë këtë. Ose, nëse e modifikojmë dhe e përdorim, duhet të postojmë kodin tonë. Sigurisht, askush nuk dëshiron të publikojë kodin e produkteve të tyre, por ju gjithashtu mund të mbroheni nga kjo.

Analiza e komponentëve që përdoren në një mjedis industrial. Le të imagjinojmë një situatë hipotetike që më në fund kemi përfunduar zhvillimin dhe kemi lëshuar versionin më të fundit të mikroshërbimit tonë. Ai jeton atje mrekullisht - një javë, një muaj, një vit. Ne nuk e mbledhim atë, nuk bëjmë kontrolle sigurie, gjithçka duket se është në rregull. Por befas, dy javë pas lëshimit, shfaqet një cenueshmëri kritike në komponentin Open Source, të cilin ne e përdorim në këtë ndërtim të veçantë, në mjedisin industrial. Nëse nuk regjistrojmë se çfarë dhe ku përdorim, atëherë thjesht nuk do ta shohim këtë cenueshmëri. Disa mjete kanë aftësinë për të monitoruar dobësitë në biblioteka që përdoren aktualisht në industri. Është shumë e dobishme.

Features:

• Politika të ndryshme për faza të ndryshme zhvillimi.
• Monitorimi i komponentëve në një mjedis industrial.
• Kontrolli i bibliotekave brenda organizatës.
• Mbështetje për sisteme dhe gjuhë të ndryshme ndërtimi.
• Analiza e imazheve të Docker.

Disa shembuj të liderëve të industrisë të cilët janë të angazhuar në analizën me burim të hapur.

E vetmja falas është kjo Varësia-Kontrollo nga OWASP. Mund ta aktivizoni në fazat e para, të shihni se si funksionon dhe çfarë mbështet. Në thelb, këto janë të gjitha produkte cloud, ose në premisë, por prapa bazës së tyre ato ende dërgohen në internet. Ata nuk dërgojnë bibliotekat tuaja, por hash ose vlerat e tyre, të cilat i llogaritin, dhe gjurmët e gishtërinjve në serverin e tyre për të marrë informacion në lidhje me praninë e dobësive.

Integrimi i procesit

Kontrolli rrethues i bibliotekave, të cilat shkarkohen nga burime të jashtme. Ne kemi depo të jashtme dhe të brendshme. Për shembull, Event Central drejton Nexus dhe ne duam të sigurojmë që nuk ka dobësi brenda depove tona me një status "kritik" ose "i lartë". Mund të konfiguroni proksimin duke përdorur veglën e "Nexus Firewall Lifecycle" në mënyrë që dobësi të tilla të ndërpriten dhe të mos përfundojnë në depon e brendshme.

Integrimi në CI. Në të njëjtin nivel me autotestet, testet e njësive dhe ndarjen në fazat e zhvillimit: dev, test, prod. Në çdo fazë, mund të shkarkoni çdo bibliotekë, të përdorni ndonjë gjë, por nëse ka diçka të vështirë me statusin "kritik", mbase ia vlen të tërhiqni vëmendjen e zhvilluesve për këtë në fazën e lëshimit në prodhim.

Integrimi me artefakte: Nexus dhe JFrog.

Integrimi në mjedisin e zhvillimit. Mjetet që zgjidhni duhet të kenë integrim me mjediset e zhvillimit. Zhvilluesi duhet të ketë akses në rezultatet e skanimit nga vendi i tij i punës, ose aftësinë për të skanuar dhe kontrolluar vetë kodin për dobësi përpara se të angazhohet në CVS.

Integrimi i CD-ve. Ky është një tipar i lezetshëm që më pëlqen shumë dhe për të cilin kam folur tashmë - monitorimi i shfaqjes së dobësive të reja në një mjedis industrial. Punon diçka si kjo.

Ne kemi Depot e Komponenteve Publike — disa mjete jashtë dhe depoja jonë e brendshme. Ne duam që ai të përmbajë vetëm komponentë të besuar. Kur përcaktojmë një kërkesë, ne kontrollojmë që biblioteka e shkarkuar të mos ketë dobësi. Nëse bie nën politika të caktuara që ne vendosim dhe koordinojmë domosdoshmërisht me zhvillimin, atëherë nuk e ngarkojmë atë dhe na kërkohet të përdorim një version tjetër. Prandaj, nëse ka diçka vërtet kritike dhe të keqe në bibliotekë, atëherë zhvilluesi nuk do ta marrë bibliotekën në fazën e instalimit - le të përdorë një version më të lartë ose më të ulët.

• Gjatë ndërtimit, ne kontrollojmë që askush të mos ketë rrëshqitur ndonjë gjë të keqe, që të gjithë komponentët të jenë të sigurt dhe askush të mos ketë sjellë ndonjë gjë të rrezikshme në flash drive.
• Ne kemi vetëm komponentë të besuar në depo.
• Gjatë vendosjes, ne kontrollojmë edhe një herë vetë paketën: imazhin e luftës, jar, DL ose Docker për t'u siguruar që ajo përputhet me politikën.
• Kur hyjmë në industri, ne monitorojmë se çfarë po ndodh në mjedisin industrial: dobësitë kritike shfaqen ose nuk shfaqen.

Analiza Dinamike - DAST

Mjetet e analizës dinamike janë thelbësisht të ndryshme nga gjithçka që është thënë më parë. Ky është një lloj imitimi i punës së përdoruesit me aplikacionin. Nëse ky është një aplikacion ueb, ne dërgojmë kërkesa, duke simuluar punën e klientit, klikojmë në butonat në pjesën e përparme, dërgojmë të dhëna artificiale nga formulari: thonjëza, kllapa, karaktere në kodime të ndryshme, për të parë se si funksionon dhe përpunohet aplikacioni. të dhëna të jashtme.

I njëjti sistem ju lejon të kontrolloni dobësitë e shabllonit në Open Source. Meqenëse DAST nuk e di se cilin burim të hapur po përdorim, ai thjesht hedh modele "me qëllim të keq" dhe analizon përgjigjet e serverit:

- Po, këtu ka një problem deserializimi, por këtu jo.

Ka rreziqe të mëdha në këtë, sepse nëse e kryeni këtë test sigurie në të njëjtin stol me të cilin punojnë testuesit, mund të ndodhin gjëra të pakëndshme.

• Ngarkesa e lartë në rrjetin e serverit të aplikacionit.
• Asnjë integrim.
• Aftësia për të ndryshuar cilësimet e aplikacionit të analizuar.
• Nuk ka mbështetje për teknologjitë e nevojshme.
• Vështirësi në konfigurim.

Ne patëm një situatë kur më në fund lançuam AppScan: kaluam një kohë të gjatë duke u përpjekur të hynim në aplikacion, morëm 3 llogari dhe ishim të lumtur - më në fund do të kontrollojmë gjithçka! Ne nisëm një skanim dhe gjëja e parë që bëri AppScan ishte hyrja në panelin e administratorit, shpoi të gjithë butonat, ndryshoi gjysmën e të dhënave dhe më pas vrau plotësisht serverin me formular postare-kërkesat. Zhvillimi me testim tha:

- Djema, po talleni me mua?! Ne ju dhamë llogari, dhe ju ngritët një stendë!

Merrni parasysh rreziqet e mundshme. Në mënyrë ideale, përgatitni një stendë të veçantë për testimin e sigurisë së informacionit, i cili do të jetë i izoluar nga pjesa tjetër e mjedisit të paktën disi, dhe kontrolloni me kusht panelin e administratorit, mundësisht në modalitetin manual. Ky është një testim - ato përqindje të mbetura të përpjekjeve që ne nuk po i konsiderojmë tani.

Vlen të merret në konsideratë që ju mund ta përdorni këtë si një analog të testimit të ngarkesës. Në fazën e parë, mund të ndizni një skaner dinamik me 10-15 fije dhe të shihni se çfarë ndodh, por zakonisht, siç tregon praktika, asgjë e mirë.

Disa burime që ne zakonisht i përdorim.

Vlen të theksohet Suitë burp është një “thikë zvicerane” për çdo profesionist të sigurisë. Të gjithë e përdorin atë dhe është shumë i përshtatshëm. Tani është lëshuar një version i ri demo i edicionit të ndërmarrjes. Nëse më parë ishte vetëm një mjet i pavarur me shtojca, tani zhvilluesit më në fund po krijojnë një server të madh nga i cili do të jetë e mundur të menaxhohen disa agjentë. Kjo është e bukur, ju rekomandoj ta provoni.

Integrimi i procesit

Integrimi ndodh mjaft mirë dhe thjesht: filloni skanimin pas instalimit të suksesshëm aplikimet për stendë dhe skanimi pas testimit të suksesshëm të integrimit.

Nëse integrimet nuk funksionojnë ose ka cung dhe funksione tallëse, është e kotë dhe e kotë - pavarësisht se çfarë modeli dërgojmë, serveri do të përgjigjet përsëri në të njëjtën mënyrë.

• Idealisht, një stendë e veçantë testimi.
• Para testimit, shkruani sekuencën e hyrjes.
• Testimi i sistemit të administrimit është vetëm manual.

proces

Pak e përgjithësuar për procesin në përgjithësi dhe për punën e secilit mjet në veçanti. Të gjitha aplikacionet janë të ndryshme - njëra funksionon më mirë me analizën dinamike, tjetra me analizën statike, e treta me analizën OpenSource, pentestet ose diçka tjetër, për shembull, ngjarjet me WAF.

Çdo proces ka nevojë për kontroll.

Për të kuptuar se si funksionon një proces dhe ku mund të përmirësohet, ju duhet të grumbulloni metrikë nga gjithçka që ju vjen në dorë, duke përfshirë metrikat e prodhimit, metrikat nga mjetet dhe nga gjurmuesit e defekteve.

Çdo informacion është i dobishëm. Është e nevojshme të shikoni nga këndvështrime të ndryshme se ku përdoret më mirë ky apo ai mjet, ku procesi në mënyrë specifike ulet. Mund të ia vlen të shikoni kohët e reagimit të zhvillimit për të parë se ku mund të përmirësohet procesi bazuar në kohë. Sa më shumë të dhëna, aq më shumë seksione mund të ndërtohen nga niveli i lartë deri në detajet e secilit proces.

Meqenëse të gjithë analizuesit statikë dhe dinamikë kanë API-të e tyre, metodat e tyre të nisjes, parimet, disa kanë planifikues, të tjerët jo - ne po shkruajmë një mjet Orkestratori i AppSec, i cili ju lejon të krijoni një pikë të vetme hyrjeje në të gjithë procesin nga produkti dhe ta menaxhoni atë nga një pikë.

Menaxherët, zhvilluesit dhe inxhinierët e sigurisë kanë një pikë hyrjeje nga e cila mund të shohin se çfarë po ekzekutohet, të konfigurojnë dhe të ekzekutojnë një skanim, të marrin rezultatet e skanimit dhe të paraqesin kërkesa. Ne po përpiqemi të largohemi nga shkresa, të përkthejmë gjithçka në një njerëzore, e cila përdoret nga zhvillimi - faqet në Konfluencë me status dhe metrikë, defekte në Jira ose në gjurmues të ndryshëm defektesh, ose integrim në një proces sinkron/asinkron në CI /CD.

Ndërmarrjet kryesore

Mjetet nuk janë gjëja kryesore. Së pari mendoni gjatë procesit - më pas zbatoni mjetet. Mjetet janë të mira, por të shtrenjta, kështu që ju mund të filloni me procesin dhe të ndërtoni komunikim dhe mirëkuptim midis zhvillimit dhe sigurisë. Nga pikëpamja e sigurisë, nuk ka nevojë të "ndaloni" gjithçka. Nga pikëpamja e zhvillimit, nëse ka diçka të lartë mega super kritike, atëherë ajo duhet të eliminohet dhe të mos mbyllet një sy ndaj problemit.

Kualiteti i produktit - qëllimi i përbashkët si sigurinë ashtu edhe zhvillimin. Ne bëjmë një gjë, përpiqemi të sigurojmë që gjithçka të funksionojë siç duhet dhe të mos ketë rreziqe reputacioni ose humbje financiare. Kjo është arsyeja pse ne promovojmë një qasje DevSecOps, SecDevOps për të përmirësuar komunikimin dhe për të përmirësuar cilësinë e produktit.

Filloni me atë që keni tashmë: kërkesat, arkitektura, kontrollet e pjesshme, trajnimet, udhëzimet. Nuk ka nevojë të zbatohen menjëherë të gjitha praktikat për të gjitha projektet - lëvizin në mënyrë të përsëritur. Nuk ka asnjë standard të vetëm - eksperiment dhe provoni qasje dhe zgjidhje të ndryshme.

Ekziston një shenjë e barabartë midis defekteve të sigurisë së informacionit dhe defekteve funksionale.

Automatizoni gjithçkaqë lëviz. Çfarëdo që nuk lëviz, lëvizni dhe automatizoni atë. Nëse diçka bëhet me dorë, nuk është pjesë e mirë e procesit. Ndoshta ia vlen ta rishikoni dhe ta automatizoni gjithashtu.

Nëse madhësia e ekipit të IS është e vogël - përdorni Champions Security.

Ndoshta ajo për të cilën fola nuk do t'ju përshtatet dhe ju do të dilni me diçka tuajën - dhe kjo është mirë. Por zgjidhni mjete bazuar në kërkesat për procesin tuaj. Mos shikoni çfarë thotë komuniteti, se ky mjet është i keq dhe ky është i mirë. Ndoshta e kundërta do të jetë e vërtetë për produktin tuaj.

Kërkesat për mjete.

• Pozitive false e nivelit të ulët.
• Koha e duhur e analizës.
• Lehtësia e përdorimit.
• Disponueshmëria e integrimeve.
• Kuptimi i udhërrëfyesit të zhvillimit të produktit.
• Mundësia e personalizimit të mjeteve.

Raporti i Yuri u zgjodh si një nga më të mirët në DevOpsConf 2018. Për t'u njohur me ide edhe më interesante dhe raste praktike, ejani në Skolkovo më 27 dhe 28 maj DevOpsConf brenda festivali RIT++. Më mirë akoma, nëse jeni gati të ndani përvojën tuaj, atëherë aplikoni për raportin deri më 21 prill.

Burimi: www.habr.com