Qorxu və nifrət DevSecOps

2 kod analizatorumuz, 4 dinamik test alətimiz, öz sənətkarlığımız və 250 skriptimiz var idi. Bütün bunlar hazırkı prosesdə lazım deyildi, ancaq DevSecOps-u tətbiq etməyə başladıqdan sonra sona qədər getməlisiniz.

Mənbə. Castin Roiland və Dan Harmon tərəfindən yaradılmış personajlar.

SecDevOps nədir? Bəs DevSecOps? Fərqlər nələrdir? Proqram Təhlükəsizliyi - bu nə ilə bağlıdır? Niyə klassik yanaşma artıq işləmir? Bütün bu sualların cavabı məlumdur Yuri Şabalin haqqında Qılınc balığı təhlükəsizliyi. Yuri hər şeyə ətraflı cavab verəcək və klassik Tətbiq Təhlükəsizliyi modelindən DevSecOps prosesinə keçid problemlərini təhlil edəcək: təhlükəsiz inkişaf prosesinin DevOps prosesinə inteqrasiyasına necə düzgün yanaşmaq və heç nəyi pozmamaq, əsas mərhələlərdən necə keçmək. təhlükəsizlik testi, hansı vasitələrdən istifadə oluna bilər, onların necə fərqlənməsi və tələlərdən qaçmaq üçün onları düzgün konfiqurasiya etmək.

Natiq haqqında: Yuri Şabalin - Şirkətdə baş mühafizə memarı Qılınc balığı təhlükəsizliyi. SSDL-nin tətbiqinə, tətbiqin təhlili alətlərinin vahid inkişaf və sınaq ekosisteminə ümumi inteqrasiyasına cavabdehdir. İnformasiya təhlükəsizliyi sahəsində 7 illik təcrübə. Proqram təminatı hazırlayan və xidmət göstərən Alfa-Bank, Sberbank və Positive Technologies-də işləyib. ZerONights, PHDays, RISSPA, OWASP beynəlxalq konfransların spikeri.

Tətbiq təhlükəsizliyi: bu nə ilə bağlıdır?

Tətbiq Təhlükəsizliyi proqram təhlükəsizliyinə cavabdeh olan təhlükəsizlik bölməsidir. Söhbət infrastruktur və ya şəbəkə təhlükəsizliyi haqqında deyil, bizim yazdıqlarımız və tərtibatçıların nə üzərində işlədiyi haqqındadır - bunlar proqramın özünün qüsurları və zəiflikləridir.

Istiqamət SDL və ya SDLC - Təhlükəsizlik inkişafının həyat dövrü - Microsoft tərəfindən hazırlanmışdır. Diaqram kanonik SDLC modelini göstərir, onun əsas vəzifəsi tələblərdən tutmuş buraxılış və istehsala qədər inkişafın hər mərhələsində təhlükəsizliyin iştirakıdır. Microsoft başa düşdü ki, məclisdə həddən artıq çox səhv var, onlardan daha çox var və bununla bağlı nəsə etmək lazımdır və onlar kanonik hala gələn bu yanaşmanı təklif etdilər.

Tətbiq Təhlükəsizliyi və SSDL, ümumiyyətlə inanıldığı kimi zəiflikləri aşkarlamağa deyil, onların baş verməsinin qarşısını almağa yönəldilmişdir. Zaman keçdikcə Microsoft-un kanonik yanaşması təkmilləşdirildi, inkişaf etdirildi, daha dərin təfərrüatlı immersiyaya sahib oldu.

Kanonik SDLC müxtəlif metodologiyalarda yüksək təfərrüatlıdır - OpenSAMM, BSIMM, OWASP. Metodologiyalar fərqlidir, lakin ümumiyyətlə oxşardır.

Yetkinlik Modelində Təhlükəsizlik Tikintisi

Mən bunu ən çox bəyənirəm BSIMM - Yetkinlik Modelində Təhlükəsizlik Tikintisi. Metodologiyanın əsası Tətbiq Təhlükəsizliyi prosesinin 4 domenə bölünməsidir: İdarəetmə, Kəşfiyyat, SSDL Təmas nöqtələri və Yerləşdirmə. Hər domendə 12 fəaliyyət kimi təmsil olunan 112 təcrübə var.

112 fəaliyyətin hər biri var 3 yetkinlik səviyyəsi: başlanğıc, orta və qabaqcıl. Siz bölmələrdə bütün 12 təcrübəni öyrənə, sizin üçün vacib olan şeyləri seçə, onların necə həyata keçiriləcəyini anlaya və tədricən elementlər əlavə edə bilərsiniz, məsələn, statik və dinamik kod təhlili və ya kodun nəzərdən keçirilməsi. Seçilmiş fəaliyyətlərin həyata keçirilməsi çərçivəsində bir plan tərtib edirsiniz və ona uyğun olaraq sakit şəkildə işləyirsiniz.

Niyə DevSecOps

DevOps, təhlükəsizliyə diqqət yetirilməli olan ümumi böyük bir prosesdir.

İlkin DevOps təhlükəsizlik yoxlamaları daxildir. Təcrübədə mühafizə dəstələrinin sayı indikindən xeyli az idi və onlar prosesin iştirakçısı kimi yox, ona tələblər qoyan və buraxılışın sonunda məhsulun keyfiyyətini yoxlayan nəzarət və nəzarət orqanı kimi çıxış edirdilər. Bu, təhlükəsizlik qruplarının inkişafdan bir divar arxasında olduğu və prosesdə iştirak etmədiyi klassik bir yanaşmadır.

Əsas problem informasiya təhlükəsizliyinin inkişafdan ayrı olmasıdır. Adətən bu, bir növ IB dövrəsidir və 2-3 böyük və bahalı alətdən ibarətdir. Altı ayda bir dəfə mənbə kodu və ya proqram yoxlanılmaq üçün gəlir və ildə bir dəfə pentestlər. Bütün bunlar sənaye üçün buraxılış tarixlərinin təxirə salınmasına və avtomatlaşdırılmış alətlərdən çoxlu sayda boşluqların tərtibatçıya düşməsinə səbəb olur. Bütün bunları sökmək və təmir etmək mümkün deyil, çünki əvvəlki altı ayda da nəticələr sökülməyib və burada yeni bir partiya var.

Şirkətimizin iş prosesində biz görürük ki, bütün sahələrdə və sənayelərdə təhlükəsizlik bir təkərdə inkişafa yetişməyin və fırlanmağın vaxtı olduğunu başa düşür. Çevik. DevSecOps paradiqması çevik inkişaf metodologiyasına, tətbiqinə, dəstəyinə və hər buraxılışda və təkrarlamada iştiraka mükəmməl uyğun gəlir.

DevSecOps-a keçid

Təhlükəsizlik İnkişafı Həyat Döngüsündə ən vacib sözdür "proses". Alətlər almağı düşünməzdən əvvəl bunu başa düşməlisiniz.

Sadəcə DevOps prosesinə alətlər daxil etmək kifayət deyil - proses iştirakçıları arasında ünsiyyət və anlaşma vacibdir.

İnsanlar alətlərdən daha vacibdir

Çox vaxt təhlükəsiz inkişaf prosesinin planlaşdırılması alətin seçilməsi və satın alınması ilə başlayır və aləti cari prosesə inteqrasiya etmək cəhdləri ilə başa çatır. Bu, kədərli nəticələrə gətirib çıxarır, çünki bütün alətlərin öz xüsusiyyətləri və məhdudiyyətləri var.

Ümumi bir hal, təhlükəsizlik departamentinin geniş xüsusiyyətlərə malik yaxşı, bahalı bir alət seçməsi və onu prosesə daxil etmək üçün tərtibatçılara gəlməsidir. Ancaq alınmır - proses elə qurulub ki, artıq alınmış alətin məhdudiyyətləri indiki paradiqmaya uyğun gəlmir.

Əvvəlcə hansı nəticəni istədiyinizi və prosesin necə görünəcəyini təsvir edin. Bu, prosesdə alətin və təhlükəsizliyin rollarını anlamağa kömək edəcək.

Artıq istifadə olunanlarla başlayın

Bahalı alətlər almadan əvvəl, artıq nəyə sahib olduğunuza baxın. Hər bir şirkətin inkişaf üçün tətbiq olunan təhlükəsizlik tələbləri var, yoxlamalar, nüfuz testləri var - niyə bütün bunları hamı üçün başa düşülən və rahat formaya çevirməyək?

Adətən tələblər rəfdə olan kağız Talmuddur. Belə bir hal olub ki, biz şirkətə gəlib proseslərə baxıb proqram təminatı üçün təhlükəsizlik tələblərini göstərməyi xahiş edirik. Bunu edən mütəxəssis çoxdan axtarırdı:

- İndi qeydlərdə hardasa bu sənədin olduğu cığır var idi.

Nəticədə sənədi bir həftə sonra aldıq.

Tələblər, yoxlamalar və daha çox şey üçün səhifə yaradın, məsələn qarışma - hamı üçün əlverişlidir.

Artıq mövcud olanı yenidən formatlaşdırmaq və başlamaq üçün ondan istifadə etmək daha asandır.

Təhlükəsizlik Çempionlarından istifadə edin

Adətən, 100-200 tərtibatçı üçün orta hesabla bir şirkətdə bir neçə funksiyanı yerinə yetirən və hər şeyi yoxlamağa fiziki olaraq vaxtı olmayan bir təhlükəsizlik işçisi var. O, əlindən gələni etsə belə, tək o, inkişafın yaratdığı bütün kodları yoxlamaz. Belə hallar üçün bir konsepsiya hazırlanmışdır - Təhlükəsizlik Çempionları.

Təhlükəsizlik Çempionları məhsulunuzun təhlükəsizliyi ilə maraqlanan inkişaf qrupunda olan şəxsdir.

Təhlükəsizlik Çempionu inkişaf komandasına giriş nöqtəsidir və təhlükəsizlik müjdəçisi hamısı bir yerə yığılmışdır.

Adətən, təhlükəsizlik işçisi inkişaf qrupuna gələrək koddakı səhvi qeyd etdikdə təəccüblü cavab alır:

- Bəs sən kimsən? Mən səni ilk dəfə görürəm. Mənimlə hər şey yaxşıdır - mənim böyük dostum kodun nəzərdən keçirilməsinə "müraciət et" dedi, davam edirik!

Bu tipik bir vəziyyətdir, çünki inkişaf etdiricinin işdə və kodun nəzərdən keçirilməsində daim qarşılıqlı əlaqədə olduğu yaşlılara və ya sadəcə komanda yoldaşlarına daha çox etibar var. Mühafizəçi əvəzinə, Mühafizə Çempionu səhvi və nəticələrini qeyd edərsə, onun sözü daha ağır olacaq.

Həmçinin, tərtibatçılar kodlarını hər hansı təhlükəsizlik işçisindən daha yaxşı bilirlər. Statik analiz alətində ən azı 5 layihəsi olan bir şəxs üçün adətən bütün nüansları yadda saxlamaq çətindir. Təhlükəsizlik Çempionları öz məhsullarını bilirlər: nə ilə qarşılıqlı əlaqədə və ilk növbədə nəyə baxmaq lazımdır - onlar daha səmərəlidir.

Beləliklə, Təhlükəsizlik Çempionlarını tətbiq etməyi və təhlükəsizlik komandasının təsirini genişləndirməyi düşünün. Çempionun özü üçün bu da faydalıdır: yeni sahədə peşəkar inkişaf, texniki üfüqlərin genişləndirilməsi, texniki, idarəetmə və liderlik bacarıqlarının artırılması, bazar dəyərinin artırılması. Bu, sosial mühəndisliyin bəzi elementidir, inkişaf komandandakı "gözləriniz".

Test mərhələləri

Paradiqma 20 ilə 80 deyir ki, səylərin 20%-i nəticənin 80%-ni verir. Bu 20% avtomatlaşdırıla bilən və edilməli olan tətbiq təhlili təcrübələridir. Bu cür fəaliyyətlərə misal olaraq statik analizi göstərmək olar SAST, dinamik analiz - DAST и açıq mənbə nəzarəti. Mən sizə fəaliyyətlər, eləcə də alətlər, prosesə daxil olanda adətən hansı xüsusiyyətlərlə qarşılaşdığımız və bunu necə düzgün etmək barədə ətraflı məlumat verəcəyəm.

Əsas alət problemləri

Mən diqqət tələb edən bütün alətlər üçün aktual olan problemləri qeyd edəcəyəm. Özümü təkrarlamamaq üçün onları daha ətraflı nəzərdən keçirəcəyəm.

Uzun analiz müddəti. Əgər bütün sınaqlar və montajlar üçün öhdəliyin buraxılmasından 30 dəqiqə çəkirsə, informasiya təhlükəsizliyi yoxlamaları bir gün çəkəcək. Beləliklə, heç kim prosesi yavaşlatmayacaq. Bu xüsusiyyəti nəzərdən keçirin və nəticə çıxarın.

Yüksək Yalan Mənfi və ya Yanlış Müsbət. Bütün məhsullar fərqlidir, hamısı fərqli çərçivələrdən və öz kodlaşdırma üslubundan istifadə edir. Müxtəlif kod əsasları və texnologiyalarında alətlər müxtəlif səviyyələrdə Yanlış Mənfi və Yanlış Müsbət göstərə bilər. Beləliklə, görün nə var sənin şirkətlər və üçün sənin tətbiqlər yaxşı və etibarlı nəticə göstərəcəkdir.

Mövcud alətlərlə inteqrasiya yoxdur. Artıq istifadə etdiyiniz şeylərlə inteqrasiya baxımından alətlərə baxın. Məsələn, Jenkins və ya TeamCity varsa, istifadə etmədiyiniz GitLab CI ilə deyil, bu proqram təminatı ilə alətlərin inteqrasiyasını yoxlayın.

Fərdiləşdirmənin olmaması və ya həddindən artıq mürəkkəbliyi. Alətin API-si yoxdursa, o zaman niyə lazımdır? İnterfeysdə edilə bilən hər şey API vasitəsilə mövcud olmalıdır. İdeal olaraq, alət çekləri fərdiləşdirmək imkanına malik olmalıdır.

Məhsulun inkişafı yol xəritəsi yoxdur. İnkişaf hələ də dayanmır, biz həmişə yeni çərçivələrdən və funksiyalardan istifadə edirik, köhnə kodu yeni dillərə yenidən yazırıq. Aldığımız alətin yeni çərçivə və texnologiyaları dəstəkləyəcəyinə əmin olmaq istəyirik. Buna görə də, məhsulun həqiqi və düzgün olduğunu bilmək vacibdir Yol inkişaf.

Proses xüsusiyyətləri

Alətlərin xüsusiyyətlərinə əlavə olaraq, inkişaf prosesinin xüsusiyyətlərini nəzərdən keçirin. Məsələn, inkişafa müdaxilə etmək tipik bir səhvdir. Gəlin görək başqa hansı xüsusiyyətlərə diqqət yetirilməlidir və təhlükəsizlik komandası nələrə diqqət etməlidir.

İnkişafı pozmamaq və son tarixləri buraxmamaq üçün yaradın fərqli qaydalar və fərqli tıxacları göstərin - zəifliklər olduqda tikinti prosesinin dayandırılması üçün meyarlar - müxtəlif mühitlər üçün. Məsələn, hazırkı filialın inkişaf stendinə və ya UAT-a getdiyini başa düşürük, buna görə dayanıb demirik:

- Burada zəiflikləriniz var, daha heç yerə getməyəcəksiniz!

Bu nöqtədə, tərtibatçılara diqqət yetirməli olan təhlükəsizlik problemlərinin olduğunu söyləmək vacibdir.

Zəifliklərin olması sonrakı sınaqlar üçün maneə deyil: dərslik, inteqrasiya və ya təlimat. Digər tərəfdən, biz məhsulun təhlükəsizliyini birtəhər yaxşılaşdırmalıyıq və tərtibatçılar təhlükəsizliyin tapdıqlarına qiymət verməsinlər. Buna görə də, bəzən bunu edirik: stenddə, inkişaf mühitinə çıxdıqda, biz sadəcə olaraq inkişafa məlumat veririk:

- Uşaqlar, problemləriniz var, onlara fikir verin.

UAT mərhələsində biz yenidən zəifliklər barədə xəbərdarlıqlar göstəririk və balonun çıxış mərhələsində deyirik:

“Uşaqlar, biz sizə bir neçə dəfə xəbərdarlıq etdik, siz heç nə etmədiniz – bununla sizi buraxmayacağıq.

Əgər kod və dinamikadan danışırıqsa, onda yalnız bu funksiyada yenicə yazılmış funksiyaların və kodun zəifliklərini göstərmək və xəbərdarlıq etmək lazımdır. Tərtibatçı düyməni 3 piksel hərəkət etdiribsə və biz ona orada SQL inyeksiyasının olduğunu və buna görə də təcili düzəldilməli olduğunu söyləyiriksə, bu səhvdir. Yalnız indi yazılanlara və ərizəyə gələn dəyişikliyə baxın.

Tutaq ki, bizdə hansısa funksional qüsur var - tətbiqin işləməməsi qaydası: pul köçürülmür, düyməni basanda növbəti səhifəyə keçid olmur və ya məhsul yüklənmir. Təhlükəsizlik Qüsurları - bunlar eyni qüsurlardır, lakin tətbiq kontekstində deyil, təhlükəsizlik.

Proqram təminatının keyfiyyəti ilə bağlı bütün problemlər təhlükəsizlik məsələləri deyil. Lakin bütün təhlükəsizlik problemləri proqram təminatının keyfiyyəti ilə bağlıdır. Şərif Mənsur, Expedia.

Bütün zəifliklər eyni qüsurlar olduğundan, onlar bütün inkişaf qüsurları ilə eyni yerdə yerləşdirilməlidir. Beləliklə, heç kimin oxumadığı hesabatları və qorxulu PDF-ləri unut.

Bir inkişaf şirkəti üçün işlədiyim zaman statik analiz alətlərindən hesabat aldım. Açdım, dəhşətə gəldim, qəhvə hazırladım, 350 səhifəni vərəqlədim, bağladım və işə davam etdim. Böyük hesabatlar ölü hesabatlardır. Adətən onlar heç yerə getmirlər, e-poçtlar silinir, unudulur, itirilir və ya biznes risk aldığını deyir.

Nə etməli? Biz sadəcə aşkar etdiyimiz təsdiqlənmiş qüsurları inkişaf üçün əlverişli formaya çeviririk, məsələn, onu Jira-da geri qalan plana əlavə edirik. Qüsurlar funksional qüsurlar və sınaq qüsurları ilə birlikdə prioritet sırasına görə prioritetləşdirilir və aradan qaldırılır.

Statik Analiz - SAST

Bu, zəifliklər üçün kod analizidir., lakin SonarQube ilə eyni deyil. Biz yalnız naxışlara və ya üsluba görə yoxlayırıq. Təhlil bir sıra yanaşmalardan istifadə edir: zəiflik ağacı ilə, by məlumat axını, konfiqurasiya fayllarını təhlil etməklə. Bütün bunlar kodun özü üçündür.

Yanaşma üstünlükləri: inkişafın ilkin mərhələsində koddakı zəifliklərin müəyyən edilməsistendlər və hazır alətlər olmadıqda və artımlı tarama qabiliyyəti: kodun dəyişdirilmiş bölməsini və yalnız hazırda etdiyimiz funksiyanı skan edir ki, bu da skan vaxtını azaldır.

Eksiler tələb olunan dillərə dəstəyin olmamasıdır.

Tələb olunan inteqrasiyalar, mənim subyektiv fikrimcə, alətlərdə olmalıdır:

• İnteqrasiya aləti: Jenkins, TeamCity və Gitlab CI.
• İnkişaf mühiti: Intellij IDEA, Visual Studio. Bir tərtibatçı üçün hələ də yadda saxlanmalı olan anlaşılmaz bir interfeysə dırmaşmaq deyil, iş yerində tapdığı bütün zəruri inteqrasiyaları və zəiflikləri öz inkişaf mühitində görmək daha rahatdır.
• Kodun nəzərdən keçirilməsi: SonarQube və əl ilə baxış.
• Qüsur izləyiciləri: Jira və Bugzilla.

Şəkildə statik analizin ən yaxşı nümayəndələrindən bəziləri göstərilir.

Vacib olan alətlər deyil, prosesdir, ona görə də prosesi idarə etmək üçün yaxşı olan Açıq Mənbə həlləri var.

SAST Açıq Mənbə çoxlu sayda zəiflik və ya mürəkkəb DataFlow tapmayacaq, lakin onlar proses qurarkən istifadə edilə bilər və istifadə edilməlidir. Onlar prosesin necə qurulacağını, kimin səhvlərə cavab verəcəyini, kimin hesabat verəcəyini, kimin hesabat verəcəyini anlamağa kömək edir. Kodunuzun təhlükəsizliyinin qurulmasının ilkin mərhələsini həyata keçirmək istəyirsinizsə, Açıq Mənbə həllərindən istifadə edin.

Səyahətinizin başlanğıcındasınızsa, bunu necə birləşdirə bilərsiniz, heç bir şeyiniz yoxdur: nə CI, nə Jenkins, nə də TeamCity? Proses inteqrasiyasını nəzərdən keçirin.

CVS səviyyəsində inteqrasiya

Əgər sizdə Bitbucket və ya GitLab varsa, səviyyədə inteqrasiya edə bilərsiniz Paralel versiyalar sistemi.

Hadisə ilə tələb etmək, öhdəsindən gəlmək. Siz kodu skan edirsiniz və quraşdırma statusunda təhlükəsizlik yoxlamasının keçdiyini və ya uğursuz olduğunu göstərirsiniz.

Əlaqə. Təbii ki, rəy həmişə lazımdır. Bunu yalnız təhlükəsizlik tərəfində etmisinizsə, qutuya qoyun və bu barədə heç kimə heç nə demədinizsə və ayın sonunda bir dəstə səhv atdınızsa, bu düzgün deyil və yaxşı deyil.

Kod nəzərdən keçirmə sistemi ilə inteqrasiya

Bir dəfə biz AppSec texniki istifadəçisini bir sıra mühüm layihələrdə standart rəyçi kimi təyin etdik. Yeni kodda xətaların aşkar edilib-edilməməsindən və ya xətaların olmamasından asılı olaraq, rəyçi “qəbul etmək” və ya “iş lazımdır” statusunu çəkmə sorğusuna qoyur - ya hər şey qaydasındadır, ya da yekunlaşdırıb dəqiq nəyə keçid verməlisiniz yekunlaşdırmaq. Çıxarılan versiya ilə inteqrasiya üçün IS testindən keçməzsə birləşməni qeyri-aktiv etdik. Biz bunu manuel kodun nəzərdən keçirilməsinə daxil etdik və qalan proses iştirakçıları bu xüsusi proses üçün təhlükəsizlik statuslarını gördülər.

SonarQube ilə inteqrasiya

Çoxları var keyfiyyətli qapı kodun keyfiyyəti baxımından. Burada da eynidir - eyni qapıları yalnız SAST alətləri üçün edə bilərsiniz. Eyni interfeys, eyni keyfiyyət qapısı olacaq, yalnız o çağırılacaq təhlükəsizlik qapısı. Həmçinin, SonarQube istifadə edərək qurulmuş bir prosesiniz varsa, orada hər şeyi asanlıqla birləşdirə bilərsiniz.

CI səviyyəsində inteqrasiya

Burada da hər şey olduqca sadədir:

• Avtotestlərlə bərabər, vahid testləri.
• İnkişaf mərhələlərinə görə bölmə: inkişaf, sınaq, istehsal. Müxtəlif qaydalar dəsti daxil edilə bilər və ya müxtəlif uğursuzluq şərtləri: biz montajı dayandırırıq, montajı dayandırmırıq.
• Sinxron/Asinxron Run. Təhlükəsizlik testlərinin bitməsini gözləyirik və ya gözləmirik. Yəni biz onları indicə işə salıb irəliləyirik, sonra hər şeyin yaxşı və ya pis olması statusu alırıq.

Hamısı mükəmməl çəhrayı dünyadadır. Real həyatda belə deyil, amma çalışırıq. Təhlükəsizlik yoxlamalarının nəticəsi vahid sınaqların nəticələrinə oxşar olmalıdır.

Məsələn, biz böyük bir layihə götürdük və qərara gəldik ki, indi onu SAST - OK ilə skan edəcəyik. Biz bu layihəni SAST-a itələdik, o, bizə 20 zəiflik verdi və hər şeyin yaxşı olduğuna dair iradəli bir qərar verdik. 000 zəiflik bizim texniki borcumuzdur. Borcu bir qutuya qoyacağıq, yavaş-yavaş yığacağıq və qüsur izləyicilərində səhvlərə başlayacağıq. Bir şirkət işə götürün, hər şeyi özümüz edək və ya Təhlükəsizlik Çempionları bizə kömək etsin və texniki borc azalacaq.

Və yeni kodda görünən bütün zəifliklər vahiddə və ya avtotestlərdə olan səhvlər kimi aradan qaldırılmalıdır. Nisbətən desək, məclis başladı, getdi, iki sınaq və iki təhlükəsizlik testi düşdü. OK - getdik, baş verənlərə baxdıq, birini düzəltdik, ikincisini düzəltdik, növbəti dəfə sürdük - hər şey yaxşıdır, heç bir yeni zəiflik yaranmadı, sınaqlar uğursuz olmadı. Bu tapşırıq daha dərindirsə və onu yaxşı başa düşmək lazımdırsa və ya zəifliklərin aradan qaldırılması başlıq altında olanların böyük təbəqələrinə təsir edirsə: qüsur izləyicisinə bir səhv gətirilir, ona prioritet verilir və düzəldilir. Təəssüf ki, dünya mükəmməl deyil və sınaqlar bəzən uğursuz olur.

Təhlükəsizlik qapısına misal olaraq kodda zəifliklərin mövcudluğu və sayı baxımından keyfiyyətli qapının analoqudur.

Biz SonarQube ilə inteqrasiya edirik - plagin quraşdırılıb, hər şey çox rahat və sərindir.

İnkişaf mühitinin inteqrasiyası

İnteqrasiya variantları:

• Təhlükədən əvvəl inkişaf mühitindən skan etməyə başlamaq.
• Nəticələrə baxın.
• Nəticələrin təhlili.
• Server ilə sinxronizasiya.

Serverdən nəticələr əldə etmək belə görünür.

İnkişaf mühitimizdə İntellekt İDEA yalnız skan zamanı belə boşluqların aşkar edildiyini söyləyən əlavə bir maddə görünür. Siz dərhal kodu redaktə edə, tövsiyələrə baxa və axın qrafiki. Bütün bunlar geliştiricinin iş yerində yerləşir, bu da çox rahatdır - qalan bağlantıları izləmək və əlavə bir şey izləmək lazım deyil.

Open Source

Bu mənim sevimli mövzumdur. Hər kəs Açıq Mənbəli kitabxanalardan istifadə edir - hər şeyin artıq həyata keçirildiyi hazır kitabxananı götürə bildiyiniz halda, niyə bir dəstə qoltuqaltı və velosiped yazmalısınız?

Əlbəttə ki, bu doğrudur, lakin kitabxanalar da insanlar tərəfindən yazılır, müəyyən riskləri də ehtiva edir və vaxtaşırı və ya davamlı olaraq bildirilən zəifliklər də var. Buna görə də, Tətbiq Təhlükəsizliyində növbəti addım var - bu, Açıq Mənbə komponentlərinin təhlilidir.

Açıq Mənbə Analizi - OSA

Alət üç əsas addımdan ibarətdir.

Kitabxanalarda zəifliklərin tapılması. Məsələn, alət bilir ki, biz bir növ kitabxanadan istifadə edirik və bu CVE və ya səhv izləyicilərində kitabxananın bu versiyası ilə əlaqəli bəzi boşluqlar var. Onu istifadə etməyə cəhd etsəniz, alət kitabxananın həssas olduğu barədə sizi xəbərdar edəcək və heç bir boşluq olmayan başqa versiyadan istifadə etməyi tövsiyə edəcək.

Lisenziya təmizliyinin təhlili. Bu hələ bizim üçün çox populyar deyil, ancaq xarici ölkə ilə işləyirsinizsə, orada vaxtaşırı istifadə edilə və ya dəyişdirilə bilməyən açıq mənbə komponentindən istifadə üçün hücum ala bilərsiniz. Lisenziyalı kitabxananın siyasətinə görə biz bunu edə bilmərik. Və ya əgər biz onu dəyişdirmişiksə və istifadə etmişiksə, kodumuzu yerləşdirməliyik. Təbii ki, heç kim öz məhsulunun kodunu yerləşdirmək istəmir, lakin siz də özünüzü bundan qoruya bilərsiniz.

Sənaye mühitində istifadə olunan komponentlərin təhlili. Təsəvvür edin ki, biz nəhayət inkişafı tamamladıq və mikroservisimizin son buraxılışını sənayeyə buraxdıq. Orada gözəl yaşayır - bir həftə, bir ay, bir il. Biz onu yığmırıq, təhlükəsizlik yoxlaması aparmırıq, deyəsən hər şey qaydasındadır. Ancaq birdən, buraxılışdan iki həftə sonra, bu xüsusi montajda, sənaye mühitində istifadə etdiyimiz Açıq Mənbə komponentində kritik bir zəiflik ortaya çıxır. Nəyi və harada istifadə etdiyimizi qeyd etməsək, bu zəiflik sadəcə görünməyəcək. Bəzi alətlər hazırda baloda istifadə olunan kitabxanalardakı zəifliklərə nəzarət etmək imkanına malikdir. Bu, çox faydalıdır.

Xüsusiyyətləri:

• İnkişafın müxtəlif mərhələləri üçün müxtəlif siyasətlər.
• Sənaye mühitində komponentlərə nəzarət edin.
• Təşkilatın konturunda kitabxanalara nəzarət.
• Müxtəlif quruluş sistemləri və dilləri üçün dəstək.
• Docker şəkillərinin təhlili.

Açıq Mənbənin təhlili ilə məşğul olan sahə liderlərindən bir neçə nümunə.

Yalnız pulsuzdur Asılılıq yoxlanışı OWASP-dən. Siz onu ilk mərhələdə yandıra bilərsiniz, necə işlədiyini və nəyi dəstəklədiyini görə bilərsiniz. Əsasən, bunlar hamısı bulud məhsullarıdır və ya yerlidir, lakin bazalarının arxasında yenə də İnternetə gedirlər. Onlar boşluqların olması barədə xəbərləri almaq üçün kitabxanalarınızı deyil, heşləri və ya hesabladıqları dəyərləri və barmaq izlərini serverlərinə göndərirlər.

Prosesin inteqrasiyası

Perimetr kitabxanasına nəzarətxarici mənbələrdən yüklənmişdir. Xarici və daxili depolarımız var. Məsələn, bizdə Event Central daxilində Nexus var və biz depomuzda "kritik" və ya "yüksək" statuslu boşluqların olmadığına əmin olmaq istəyirik. Siz Nexus Firewall Lifecycle alətindən istifadə edərək proksiinq qura bilərsiniz ki, belə zəifliklər kəsilib daxili repozitoriyaya daxil olmasın.

CI inteqrasiyası. Avtotestlər, vahid testləri və inkişaf mərhələlərinə bölmə ilə eyni səviyyədə: inkişaf, test, istehsal. Hər mərhələdə hər hansı bir kitabxananı yükləyə, hər hansı bir şeydən istifadə edə bilərsiniz, ancaq "kritik" statusu ilə çətin bir şey varsa, ehtimal ki, baloya girmə mərhələsində tərtibatçıların diqqətini buna cəlb etməlisiniz.

Artefakt inteqrasiyası: Nexus və JFrog.

İnkişaf mühitinə inteqrasiya. Seçdiyiniz alətlər inkişaf mühitləri ilə inteqrasiyaya malik olmalıdır. Tərtibatçının iş yerindən skan nəticələrinə girişi və ya kodu skan etmək və onu CVS-də yerinə yetirməzdən əvvəl zəiflikləri yoxlamaq imkanı olmalıdır.

CD inteqrasiyası. Bu, mənim çox bəyəndiyim və haqqında artıq danışdığım əla xüsusiyyətdir - sənaye mühitində yeni zəifliklərin yaranmasının monitorinqi. Bu belə işləyir.

bizdə var İctimai Komponent Repozitoriyaları - kənarda bəzi alətlər və daxili depomuz. Biz orada yalnız etibarlı komponentlərin olmasını istəyirik. Sorğunu proksiləşdirərkən biz yüklənmiş kitabxanada zəifliyin olmadığını yoxlayırıq. Əgər o, müəyyən etdiyimiz və mütləq inkişafla əlaqələndirdiyimiz müəyyən siyasətlərə tabedirsə, biz onu yükləmirik və fərqli versiyadan istifadə etmək üçün cavab gəlir. Müvafiq olaraq, kitabxanada həqiqətən kritik və pis bir şey varsa, o zaman tərtibatçı quraşdırma mərhələsində belə kitabxananı almayacaq - daha yüksək və ya daha aşağı versiyadan istifadə etsin.

• Quraşdırarkən, heç kimin pis bir şey sürüşmədiyini, bütün komponentlərin təhlükəsiz olduğunu və heç kimin flash sürücüyə təhlükəli bir şey gətirmədiyini yoxlayırıq.
• Anbarda yalnız etibarlı komponentlərimiz var.
• Yerləşdirmə zamanı paketin özünü bir daha yoxlayırıq: siyasətə uyğun olması üçün müharibə, jar, DL və ya Docker təsviri.
• Sənaye mühitinə daxil olarkən biz sənaye mühitində baş verənləri izləyirik: kritik zəifliklər görünür və ya görünmür.

Dinamik Analiz - DAST

Dinamik analiz vasitələri əvvəllər deyilən hər şeydən əsaslı şəkildə fərqlənir. Bu, istifadəçinin proqramla işinin bir növ imitasiyasıdır. Bu bir veb tətbiqidirsə, biz müştərinin işini təqlid edən sorğular göndəririk, ön tərəfdəki düymələri klikləyirik, formadan süni məlumatlar göndəririk: tətbiqin necə işlədiyinə və xarici proqramları emal etdiyinə baxmaq üçün sitatlar, mötərizələr, müxtəlif kodlaşdırmalardakı simvollar. data.

Eyni sistem Open Source-də şablon zəifliklərini yoxlamağa imkan verir. DAST bizim hansı Açıq Mənbədən istifadə etdiyimizi bilmədiyi üçün o, sadəcə olaraq “zərərli” nümunələri atır və serverin cavablarını təhlil edir:

- Bəli, burada serializasiya problemi var, amma burada yox.

Bunun böyük riskləri var, çünki bu təhlükəsizlik testini test edənlərin işlədiyi eyni stenddə keçirsəniz, xoşagəlməz hadisələr baş verə bilər.

• Tətbiq server şəbəkəsində yüksək yük.
• İnteqrasiya yoxdur.
• Təhlil edilən tətbiqin parametrlərini dəyişdirmək imkanı.
• Lazımi texnologiyalara dəstək yoxdur.
• Quraşdırmanın çətinliyi.

Nəhayət AppScan-ı işə saldığımız zaman belə bir vəziyyət yarandı: biz uzun müddət proqrama girişi dayandırdıq, 3 hesab aldıq və sevindik - nəhayət, hər şeyi yoxlayacağıq! Biz skan etməyə başladıq və AppScan-ın etdiyi ilk şey admin panelinə daxil olmaq, bütün düymələri deşmək, məlumatların yarısını dəyişmək və sonra serveri tamamilə öz funksiyası ilə öldürmək oldu. poçt forması-istək. Test ilə inkişaf dedi:

“Uşaqlar, mənimlə zarafat edirsiniz?! Biz sizə haqq-hesab verdik, siz isə dayanasınız!

Mümkün riskləri nəzərdən keçirin. İdeal olaraq, ən azı bir şəkildə ətraf mühitin qalan hissəsindən təcrid olunacaq informasiya təhlükəsizliyini yoxlamaq üçün ayrıca bir stend hazırlayın və şərti olaraq idarəetmə panelini, tercihen əl rejimində yoxlayın. Bu bir pentestdir - indi nəzərdən keçirmədiyimiz səylərin qalan faizi.

Bunu yük testinin analoqu kimi istifadə edə biləcəyinizi nəzərə almağa dəyər. Birinci mərhələdə dinamik skaneri 10-15 ipdə yandırıb nə baş verdiyini görə bilərsiniz, lakin adətən, təcrübənin göstərdiyi kimi, yaxşı bir şey yoxdur.

Adətən istifadə etdiyimiz bir neçə resurs.

Vurğulamağa dəyər Burp Suite istənilən təhlükəsizlik mütəxəssisi üçün “İsveçrə bıçağı”dır. Hər kəs istifadə edir və çox rahatdır. İndi müəssisə nəşrinin yeni demo versiyası buraxılıb. Əvvəllər bu, plaginləri olan müstəqil bir yardım proqramı idisə, indi tərtibatçılar nəhayət, bir neçə agenti idarə etmək mümkün olacaq böyük bir server hazırlayırlar. Gözəldir, sınamağı məsləhət görürəm.

Prosesin inteqrasiyası

İnteqrasiya olduqca yaxşı və sadədir: uğurlu quraşdırmadan sonra skan etməyə başlayın stenddəki tətbiqlər və uğurlu inteqrasiya testindən sonra tarama.

Əgər inteqrasiyalar işləmirsə və ya stublar və istehza funksiyaları varsa, bu, mənasız və faydasızdır - hansı nümunəni göndərməyimizdən asılı olmayaraq, server yenə də eyni şəkildə cavab verəcəkdir.

• İdeal olaraq, ayrı bir sınaq dəzgahı.
• Test etməzdən əvvəl giriş ardıcıllığını yazın.
• İdarəetmə sisteminin sınaqdan keçirilməsi yalnız əl ilə aparılır.

proses

Ümumilikdə proses və xüsusən də hər bir alətin işi haqqında bir az ümumiləşdirilmişdir. Bütün proqramlar fərqlidir - biri dinamik analizlə, digəri statik analizlə, üçüncüsü OpenSource analizi, pentestlər və ya ümumiyyətlə başqa bir şeylə, məsələn, hadisələrlə daha yaxşı işləyir. Waf.

Hər bir prosesə nəzarət etmək lazımdır.

Prosesin necə işlədiyini və onun harada təkmilləşdirilə biləcəyini başa düşmək üçün istehsal göstəriciləri, alətlərdən alınan göstəricilər və qüsur izləyiciləri daxil olmaqla, əldə edə biləcəyiniz hər şeydən ölçüləri toplamaq lazımdır.

İstənilən məlumat faydalıdır. Bu və ya digər alətin daha yaxşı istifadə edildiyi, prosesin xüsusi olaraq aşağı düşdüyü yerlərdə müxtəlif bölmələrə baxmaq lazımdır. Zamana əsaslanaraq prosesi harada təkmilləşdirəcəyini görmək üçün inkişafa cavab vaxtına baxmağa dəyər ola bilər. Nə qədər çox məlumat olarsa, hər bir prosesin təfərrüatlarına yuxarı səviyyədən bir o qədər çox kəsiklər tikilə bilər.

Bütün statik və dinamik analizatorların öz API-ləri, öz işə salma üsulları, prinsipləri olduğundan, bəzilərinin planlaşdırıcıları var, digərlərində isə yoxdur - biz alət yazırıq. AppSec Orkestratoru, bu, məhsuldan bütün prosesə tək bir giriş nöqtəsi yaratmağa və onu bir nöqtədən idarə etməyə imkan verir.

Menecerlərin, tərtibatçıların və təhlükəsizlik mühəndislərinin nə işlədiyini görə biləcəyi, skanları konfiqurasiya edə və işə sala, skan nəticələrini əldə edə və tələbləri təqdim edə biləcək bir giriş nöqtəsi var. Biz kağız parçalarından uzaqlaşmağa, hər şeyi inkişafın istifadə etdiyi insana çevirməyə çalışırıq - status və ölçülərlə birləşmədəki səhifələr, Jira-da və ya müxtəlif qüsur izləyicilərində qüsurlar və ya CI / CD-də sinxron / asinxron prosesə daxil etmək.

Key Takeaways

Alətlərin əhəmiyyəti yoxdur. Əvvəlcə prosesi düşünün, sonra alətləri tətbiq edin. Alətlər yaxşıdır, lakin bahalıdır, ona görə də siz prosesdən başlaya və inkişaf və təhlükəsizlik arasında qarşılıqlı əlaqə və anlaşmanı dəqiq tənzimləyə bilərsiniz. Təhlükəsizlik nöqteyi-nəzərindən hər şeyi ard-arda “dayandırmağa” ehtiyac yoxdur.İnkişaf nöqteyi-nəzərindən, əgər yüksək meqa super kritik bir şey varsa, bu problemə bağlanmamaqla aradan qaldırılmalıdır. .

Məhsul keyfiyyəti - ümumi məqsəd həm təhlükəsizlik, həm də inkişaf. Biz bir işi görürük, çalışırıq ki, hər şey düzgün işləsin və heç bir reputasiya riski və maliyyə itkisi olmasın. Buna görə də biz rabitə qurmaq və məhsulu daha yaxşı etmək üçün DevSecOps, SecDevOps-a yanaşmanı təbliğ edirik.

Artıq orada olandan başlayın: tələblər, memarlıq, qismən yoxlamalar, təlimlər, təlimatlar. Bütün təcrübələri bütün layihələrə dərhal tətbiq etmək lazım deyil - iterativ olaraq hərəkət edin. Vahid standart yoxdur təcrübə və müxtəlif yanaşma və həll yollarını sınayın.

IS qüsurları və funksional qüsurlar arasında bərabər işarə.

Hər şeyi avtomatlaşdırınbu hərəkət edir. Hərəkət etməyən, hərəkət edən və avtomatlaşdırılmayan hər şey. Bir şey əl ilə edilirsə, bu prosesin yaxşı bir hissəsi deyil. Bəlkə də onu yenidən nəzərdən keçirməyə və avtomatlaşdırmağa dəyər.

IB komandasının ölçüsü kiçikdirsə - Təhlükəsizlik Çempionlarından istifadə edin.

Ola bilsin ki, danışdıqlarım sizə uyğun gəlməyəcək və siz özünüzdən bir şey tapacaqsınız - və bu yaxşıdır. Amma prosesinizin tələblərinə əsasən alətlər seçin. Baxmayın, camaat deyir ki, bu alət pisdir, bu da yaxşıdır. Ola bilsin ki, məhsulunuzda əksinə olacaq.

Alət tələbləri.

• Aşağı Yanlış Müsbət.
• Adekvat analiz vaxtı.
• Istifadə rahatlığı.
• İnteqrasiyaların mövcudluğu.
• Məhsulun inkişafı yol xəritəsini başa düşmək.
• Alətləri fərdiləşdirmək bacarığı.

Yuriyin hesabatı DevOpsConf 2018-də ən yaxşılardan biri seçildi. Daha maraqlı ideyalar və praktiki işlərlə tanış olmaq üçün mayın 27 və 28-də Skolkovoya gəlin. DevOpsConf daxilində festivalı RIT++. Daha yaxşısı, təcrübənizi bölüşməyə hazırsınızsa, o zaman müraciət edin Hesabatınızı aprelin 21-dək təqdim edin.

Mənbə: www.habr.com