2 kod analizörümüz, 4 dinamik test aracımız, kendi zanaatlarımız ve 250 komut dosyamız vardı. Mevcut süreçte tüm bunlara ihtiyaç duyulmuyor ancak DevSecOps'u uygulamaya başladığınızda sonuna kadar gitmeniz gerekiyor.
. Karakter yaratıcıları: Justin Roiland ve Dan Harmon.
SecDevOps nedir? DevSecOps'a ne dersiniz? Farklılıklar nedir? Uygulama Güvenliği - neyle ilgili? Neden klasik yaklaşım artık işe yaramıyor? Bütün bu soruların cevabını biliyor Yuri Shabalin arasında Kılıçbalığı Güvenliği. Yuri her şeyi ayrıntılı olarak yanıtlayacak ve klasik Uygulama Güvenliği modelinden DevSecOps sürecine geçiş sorunlarını analiz edecek: güvenli geliştirme sürecinin DevOps sürecine entegrasyonuna nasıl doğru şekilde yaklaşılır ve hiçbir şeyi bozmamak, ana aşamalardan nasıl geçilir? Güvenlik testi, hangi araçların kullanılabileceği, bunların ne gibi farklılıklar gösterdiği ve tuzaklardan kaçınmak için bunların doğru şekilde nasıl yapılandırılacağı.
Konuşmacı hakkında: Yuri Şabalin - Şirketin Baş Güvenlik Mimarı Kılıç Balığı Güvenliği. Uygulama analiz araçlarının birleşik bir geliştirme ve test ekosistemine genel entegrasyonundan ve SSDL'nin uygulanmasından sorumludur. Bilgi güvenliği alanında 7 yıllık deneyim. Yazılım geliştiren ve hizmet veren Alfa-Bank, Sberbank ve Positive Technologies'de çalıştı. ZerONights, PHDays, RISSPA, OWASP uluslararası konferanslarda konuşmacı.
Uygulama Güvenliği: neyle ilgili?
Uygulama Güvenliği - Uygulama güvenliğinden sorumlu olan güvenlik bölümüdür. Bu, altyapı veya ağ güvenliği için geçerli değildir, daha ziyade yazdıklarımız ve geliştiricilerin üzerinde çalıştığı şeyler için geçerlidir; bunlar uygulamanın kendisindeki eksiklikler ve güvenlik açıklarıdır.
Yön - Güvenlik geliştirme yaşam döngüsü - Microsoft tarafından geliştirilmiştir. Diyagram, temel görevi gereksinimlerden sürüme ve üretime kadar geliştirmenin her aşamasında güvenliğin katılımı olan kanonik SDLC modelini göstermektedir. Microsoft, sektörde çok fazla hata olduğunu, daha fazlasının olduğunu ve bu konuda bir şeyler yapılması gerektiğini fark etti ve artık kanonik hale gelen bu yaklaşımı önerdi.
Uygulama Güvenliği ve SSDL, yaygın olarak inanıldığı gibi güvenlik açıklarını tespit etmeyi değil, bunların ortaya çıkmasını önlemeyi amaçlamaktadır. Zamanla Microsoft'un kanonik yaklaşımı iyileştirildi, geliştirildi ve daha derin, daha ayrıntılı bir incelemeye sunuldu.
Kanonik SDLC, OpenSAMM, BSIMM, OWASP gibi çeşitli metodolojilerde oldukça ayrıntılıdır. Metodolojiler farklı olsa da genel olarak benzerdir.
Olgunluk Modelinde Bina Güvenliği
En çok bunu beğendim BSIMM - . Metodolojinin temeli, Uygulama Güvenliği sürecinin 4 alana bölünmesidir: Yönetişim, İstihbarat, SSDL Temas Noktaları ve Dağıtım. Her alanın 12 aktivite olarak temsil edilen 112 uygulaması vardır.
112 aktivitenin her biri 3 olgunluk seviyesi: başlangıç, orta ve ileri düzey. 12 uygulamanın tümünü bölüm bölüm inceleyebilir, sizin için önemli olan şeyleri seçebilir, bunları nasıl uygulayacağınızı anlayabilir ve örneğin statik ve dinamik kod analizi veya kod incelemesi gibi öğeleri yavaş yavaş ekleyebilirsiniz. Bir plan yazarsınız ve seçilen faaliyetlerin uygulanması kapsamında sakin bir şekilde ona göre çalışırsınız.
Neden DevSecOps
DevOps, güvenliğin dikkate alınması gereken genel ve büyük bir süreçtir.
Başlangıçta güvenlik kontrollerini içeriyordu. Uygulamada, güvenlik ekiplerinin sayısı şu ana göre çok daha azdı ve süreçte katılımcı olarak değil, gereksinimler getiren ve piyasaya sürülme sonunda ürünün kalitesini kontrol eden bir kontrol ve denetleyici organ olarak hareket ediyorlardı. Bu, güvenlik ekiplerinin geliştirme aşamasında duvarın arkasında olduğu ve sürece katılmadığı klasik bir yaklaşımdır.
Temel sorun bilgi güvenliğinin geliştirmeden ayrı olmasıdır. Genellikle bu bir tür bilgi güvenliği devresidir ve 2-3 büyük ve pahalı araç içerir. Altı ayda bir kontrol edilmesi gereken kaynak kodu veya uygulama gelir ve yılda bir kez üretilir. . Tüm bunlar, sektör için çıkış tarihinin ertelenmesine ve geliştiricinin otomatik araçlardan kaynaklanan çok sayıda güvenlik açığına maruz kalmasına yol açıyor. Tüm bunları söküp onarmak imkansız çünkü önceki altı ayın sonuçları çözülmedi, ancak işte yeni bir parti.
Şirketimizin çalışması sürecinde, tüm alanlarda ve sektörlerde güvenliğin, aynı çarkta gelişmeyi yakalamanın ve döndürmenin zamanının geldiğini anladığını görüyoruz. . DevSecOps paradigması, her sürümde ve yinelemede çevik geliştirme metodolojisine, uygulamaya, desteğe ve katılıma mükemmel şekilde uyar.
DevSecOps'a Geçiş
Güvenlik Geliştirme Yaşam Döngüsünde en önemli kelime: "işlem". Alet satın almayı düşünmeden önce bunu anlamalısınız.
Araçların yalnızca DevOps sürecine dahil edilmesi yeterli değildir; süreç katılımcıları arasındaki iletişim ve anlayış önemlidir.
Araçlar değil, insanlar daha önemlidir.
Çoğu zaman, güvenli bir geliştirme süreci için planlama, bir aracın seçilmesi ve satın alınmasıyla başlar ve aracın mevcut sürece entegre edilmesine yönelik girişimlerle sona erer; bunlar da girişim olarak kalır. Bu durum talihsiz sonuçlara yol açmaktadır çünkü tüm araçların kendine has özellikleri ve sınırlamaları vardır.
Yaygın bir durum, güvenlik departmanının geniş yeteneklere sahip iyi ve pahalı bir araç seçmesi ve bunu sürece entegre etmek için geliştiricilere gelmesidir. Ancak işe yaramıyor - süreç, halihazırda satın alınan aracın sınırlamalarının mevcut paradigmaya uymayacağı şekilde yapılandırılmıştır.
Öncelikle nasıl bir sonuç istediğinizi ve sürecin nasıl görüneceğini açıklayın. Bu, süreçte aracın ve güvenliğin rollerinin anlaşılmasına yardımcı olacaktır.
Halihazırda kullanımda olanlarla başlayın
Pahalı aletler satın almadan önce, halihazırda sahip olduklarınıza bakın. Her şirketin geliştirme için güvenlik gereksinimleri vardır, kontroller, sızma testleri vardır - neden tüm bunları herkes için anlaşılır ve kullanışlı bir biçime dönüştürmeyelim?
Genellikle gereksinimler rafta duran kağıt bir Talmud'dur. Süreçlere bakmak için bir şirkete geldiğimizde ve yazılımın güvenlik gereksinimlerini görmek istediğimizde bir durum vardı. Bu konuyla ilgilenen uzman uzun süre şunu aradı:
- Şimdi, notların bir yerinde bu belgenin bulunduğu bir yol vardı.
Sonuç olarak belgeyi bir hafta sonra aldık.
Gereksinimler, kontroller ve diğer şeyler için ör. Izdiham - herkes için uygundur.
Halihazırda sahip olduğunuz şeyi yeniden biçimlendirmek ve başlamak için onu kullanmak daha kolaydır.
Güvenlik Şampiyonlarını Kullan
Tipik olarak, 100-200 geliştiricinin bulunduğu ortalama bir şirkette, çeşitli işlevleri yerine getiren ve fiziksel olarak her şeyi kontrol edecek zamanı olmayan bir güvenlik uzmanı vardır. Elinden gelenin en iyisini yapsa bile, geliştirmenin ürettiği tüm kodu tek başına kontrol etmeyecektir. Bu gibi durumlar için bir konsept geliştirildi: .
Güvenlik Şampiyonları, geliştirme ekibinde yer alan ve ürününüzün güvenliğiyle ilgilenen kişilerdir.
Güvenlik Şampiyonu, geliştirme ekibine bir giriş noktasıdır ve bir güvenlik misyoneri bir aradadır.
Genellikle bir güvenlik uzmanı geliştirme ekibine gelip koddaki bir hatayı belirttiğinde sürpriz bir yanıt alır:
- Ve sen kimsin? Seni ilk defa görüyorum. Benim için her şey yolunda - kıdemli arkadaşım kod incelemesinde bana "başvur" dedi, devam ediyoruz!
Bu tipik bir durumdur, çünkü geliştiricinin işte ve kod incelemesinde sürekli etkileşimde bulunduğu kıdemlilere veya sadece ekip arkadaşlarına çok daha fazla güven vardır. Güvenlik Şampiyonu, güvenlik görevlisi yerine hatayı ve sonuçlarını belirtirse, onun sözü daha fazla ağırlık kazanacaktır.
Ayrıca geliştiriciler kodlarını herhangi bir güvenlik uzmanından daha iyi bilirler. Statik analiz aracında en az 5 projesi olan bir kişinin tüm nüansları hatırlaması genellikle zordur. Güvenlik Şampiyonları ürünlerini biliyor: Neyin neyle etkileşime girdiğini ve ilk olarak neye bakılacağını; daha etkili oluyorlar.
Bu nedenle, Güvenlik Şampiyonlarını uygulamaya koymayı ve güvenlik ekibinizin etkisini genişletmeyi düşünün. Bu aynı zamanda şampiyonun kendisi için de faydalıdır: yeni bir alanda profesyonel gelişim, teknik ufkunun genişletilmesi, teknik, yönetim ve liderlik becerilerinin geliştirilmesi, piyasa değerinin arttırılması. Bu, sosyal mühendisliğin bir unsurudur, geliştirme ekibindeki "gözleriniz"dir.
Test aşamaları
Çabanın %20'sinin sonuçların %80'ini ürettiğini belirtir. Bu %20, otomatikleştirilebilen ve otomatikleştirilmesi gereken uygulama analizi uygulamalarıdır. Bu tür faaliyetlere örnek olarak statik analiz verilebilir. SAST, dinamik analiz - DAST и Açık Kaynak kontrolü. Etkinlikler ve araçlar hakkında, onları sürece dahil ederken genellikle hangi özelliklerle karşılaştığımızı ve bunun nasıl doğru şekilde yapılacağını size daha ayrıntılı olarak anlatacağım.
Aletlerin ana sorunları
Tüm enstrümanları ilgilendiren ve dikkat gerektiren sorunları vurgulayacağım. Daha fazla tekrarlamamak için bunları daha ayrıntılı olarak analiz edeceğim.
Uzun analiz süresi. Taahhütten itibaren tüm testler ve montaj 30 dakika sürerse bilgi güvenliği kontrolleri bir gün sürecektir. Dolayısıyla kimse süreci yavaşlatamaz. Bu özelliği dikkate alın ve sonuç çıkarın.
Yüksek düzeyde Yanlış Negatif veya Yanlış Pozitif. Tüm ürünler farklıdır, hepsi farklı çerçeveler ve kendi kodlama stillerini kullanır. Farklı kod tabanlarında ve teknolojilerde, araçlar farklı düzeylerde Yanlış Negatif ve Yanlış Pozitif gösterebilir. Peki tam olarak ne olduğuna bakın sizin şirketler ve için Sizin uygulamalar iyi ve güvenilir sonuçlar verecektir.
Mevcut araçlarla entegrasyon yok. Araçlara halihazırda kullandığınız araçlarla entegrasyon açısından bakın. Örneğin, Jenkins veya TeamCity'niz varsa araçların entegrasyonunu kullanmadığınız GitLab CI ile değil, bu yazılımla kontrol edin.
Özelleştirmenin eksikliği veya aşırı karmaşıklığı. Bir aracın API'si yoksa neden buna ihtiyaç duyulur? Arayüzde yapılabilecek her şeyin API aracılığıyla mevcut olması gerekir. İdeal olarak, aracın kontrolleri özelleştirme yeteneğine sahip olması gerekir.
Ürün Geliştirme Yol Haritası Yok. Geliştirme durmuyor; her zaman yeni çerçeveler ve işlevler kullanıyoruz, eski kodları yeni dillere yeniden yazıyoruz. Satın aldığımız aracın yeni çerçeveleri ve teknolojileri destekleyeceğinden emin olmak istiyoruz. Bu nedenle ürünün gerçek ve doğru olduğunu bilmek önemlidir. gelişme.
Süreç özellikleri
Araçların özelliklerine ek olarak geliştirme sürecinin özelliklerini de dikkate alın. Örneğin gelişimi engellemek yaygın bir hatadır. Gelin başka hangi özelliklerin dikkate alınması gerektiğine ve güvenlik ekibinin nelere dikkat etmesi gerektiğine bakalım.
Geliştirme ve sürüm son tarihlerini kaçırmamak için farklı kurallar ve farklı tıpaları göster — güvenlik açıklarının bulunması durumunda oluşturma sürecini durdurma kriterleri — farklı ortamlar için. Örneğin, mevcut şubenin geliştirme standına veya UAT'ye gittiğini anlıyoruz, bu da durup şunu söylemediğimiz anlamına geliyor:
“Burada zayıf noktalarınız var, daha ileri gitmeyeceksiniz!”
Bu noktada geliştiricilere dikkat edilmesi gereken güvenlik konularının olduğunu söylemek önemlidir.
Güvenlik açıklarının varlığı daha ileri testlere engel değildir: manuel, entegrasyon veya manuel. Öte yandan ürünün güvenliğini de bir şekilde arttırmamız gerekiyor ki geliştiriciler güvenli bulduklarını ihmal etmesinler. Bu nedenle bazen bunu yapıyoruz: stantta, geliştirme ortamına sunulduğunda, yalnızca geliştirmeyi bilgilendiriyoruz:
-Arkadaşlar, sorunlarınız var, lütfen onlara dikkat edin.
UAT aşamasında yine güvenlik açıklarına ilişkin uyarılar gösteriyoruz ve sürüm aşamasında şunu söylüyoruz:
- Beyler, sizi defalarca uyardık, hiçbir şey yapmadınız - sizi bu şekilde bırakmayacağız.
Kod ve dinamiklerden bahsedersek, yalnızca bu özelliklerin ve bu özelliğe az önce yazılan kodun güvenlik açıklarını göstermek ve uyarmak gerekir. Bir geliştirici bir düğmeyi 3 piksel hareket ettirirse ve ona burada SQL enjeksiyonu olduğunu ve bu nedenle acilen düzeltilmesi gerektiğini söylersek bu yanlıştır. Sadece şu anda yazılanlara ve uygulamada gelen değişikliğe bakın.
Diyelim ki belirli bir işlevsel kusurumuz var - uygulamanın çalışmaması gerektiği gibi: para aktarılmıyor, bir düğmeye tıkladığınızda bir sonraki sayfaya geçiş olmuyor veya ürün yüklenmiyor. Güvenlik Kusurları - bunlar aynı kusurlardır ancak uygulamanın işleyişi açısından değil, güvenlik açısından.
Yazılım kalitesi sorunlarının tümü güvenlik sorunları değildir. Ancak tüm güvenlik sorunları yazılım kalitesiyle ilgilidir. Şerif Mansour, Expedia.
Tüm güvenlik açıkları aynı kusurlar olduğundan, bunların tüm geliştirme kusurlarıyla aynı yerde bulunması gerekir. Kimsenin okumadığı raporları ve korkutucu PDF'leri unutun.
Bir geliştirme şirketinde çalışırken statik analiz araçlarından bir rapor aldım. Açtım, dehşete düştüm, kahve yaptım, 350 sayfa karıştırdım, kapattım ve çalışmaya devam ettim. Büyük raporlar ölü raporlardır. Genellikle hiçbir yere varmazlar, mektuplar silinir, unutulur, kaybolur veya işletme riskleri kabul ettiğini söyler.
Ne yapalım? Bulduğumuz doğrulanmış kusurları geliştirmeye uygun bir forma dönüştürüyoruz, örneğin bunları Jira'da birikmiş yığına koyuyoruz. Kusurları önceliklendiriyor ve bunları işlevsel kusurlar ve test kusurlarıyla birlikte öncelik sırasına göre ortadan kaldırıyoruz.
Statik Analiz - SAST
Bu, güvenlik açıklarına yönelik bir kod analizidir., ancak SonarQube ile aynı değil. Sadece desenleri veya stili kontrol etmiyoruz. Analizde çeşitli yaklaşımlar kullanılmaktadır: güvenlik açığı ağacına göre, , yapılandırma dosyalarını analiz ederek. Kodun kendisini ilgilendiren tek şey budur.
Yaklaşımın artıları: Geliştirmenin erken bir aşamasında koddaki güvenlik açıklarının belirlenmesihenüz stand veya hazır alet bulunmadığında ve artımlı tarama yeteneği: Kodun değişen bir bölümünü ve yalnızca şu anda yapmakta olduğumuz özelliği taramak, bu da tarama süresini azaltır.
Eksileri - bu gerekli diller için destek eksikliğidir.
Gerekli entegrasyonlar, öznel görüşüme göre araçlarda olması gereken:
- Entegrasyon aracı: Jenkins, TeamCity ve Gitlab CI.
- Geliştirme ortamı: Intellij IDEA, Visual Studio. Bir geliştiricinin, hala ezberlenmesi gereken, anlaşılmaz bir arayüzde gezinmek yerine, işyerinde bulduğu tüm gerekli entegrasyonları ve güvenlik açıklarını kendi geliştirme ortamında görmesi daha uygundur.
- Kod incelemesi: SonarQube ve manuel inceleme.
- Kusur izleyicileri: Jira ve Bugzilla.
Resimde statik analizin en iyi temsilcilerinden bazıları gösterilmektedir.
Önemli olan araçlar değil süreçtir; dolayısıyla süreci test etmek için de iyi olan Açık Kaynak çözümleri vardır.
SAST Açık Kaynak, çok sayıda güvenlik açığı veya karmaşık DataFlow bulmaz ancak bunlar bir süreç oluştururken kullanılabilir ve kullanılmalıdır. Sürecin nasıl inşa edileceğini, hatalara kimin yanıt vereceğini, kimin rapor vereceğini ve kimin rapor vereceğini anlamaya yardımcı olurlar. Kodunuzun güvenliğini oluşturmanın ilk aşamasını gerçekleştirmek istiyorsanız Açık Kaynak çözümlerini kullanın.
Yolculuğunuzun başındaysanız ve hiçbir şeyiniz yoksa: CI yok, Jenkins yok, TeamCity yok, bu nasıl entegre edilebilir? Sürece entegrasyonu ele alalım.
CVS düzeyinde entegrasyon
Bitbucket veya GitLab'ınız varsa seviyede entegrasyon yapabilirsiniz. .
Etkinliğe göre - istek çekme, taahhüt etme. Kodu tararsınız ve yapı durumu, güvenlik kontrolünün başarılı mı yoksa başarısız mı olduğunu gösterir.
Bize. Elbette geri bildirime her zaman ihtiyaç vardır. Güvenliği bir kenara koyduysanız, onu bir kutuya koyun ve kimseye bu konuda hiçbir şey söylemediyseniz ve ayın sonunda bir sürü hata attıysanız - bu doğru değil ve iyi değil.
Kod inceleme sistemiyle entegrasyon
Bir zamanlar, bir dizi önemli projede teknik bir AppSec kullanıcısı için varsayılan incelemeci olarak hareket ettik. Yeni kodda hataların tanımlanıp tanımlanmadığına veya herhangi bir hata olmamasına bağlı olarak, gözden geçiren kişi çekme isteğindeki durumu "kabul ediyorum" veya "çalışmaya ihtiyaç var" olarak ayarlar - ya her şey yolundadır ya da tam olarak neyin iyileştirilmesi gerektiğine ilişkin bağlantılar iyileştirilmesi gerekiyor. Üretime girecek sürümle entegrasyon için bilgi güvenliği testini geçememesi durumunda birleştirme yasağını etkinleştirdik. Bunu manuel kod incelemesine dahil ettik ve süreçteki diğer katılımcılar bu özel sürecin güvenlik durumlarını gördü.
SonarQube ile entegrasyon
Birçoğu var Kod kalitesi açısından. Burada da durum aynı; aynı kapıları yalnızca SAST araçları için yapabilirsiniz. Aynı arayüz, aynı kalitede kapı olacak, sadece çağrılacak güvenlik kapısı. Ayrıca SonarQube kullanan bir işleminiz varsa her şeyi oraya kolayca entegre edebilirsiniz.
CI düzeyinde entegrasyon
Buradaki her şey de oldukça basit:
- Otomatik testlerle aynı seviyede, birim testleri.
- Geliştirme aşamalarına göre bölümleme: geliştirici, test, üretim. Farklı kural kümeleri veya farklı arıza koşulları dahil edilebilir: Montajı durdurun, montajı durdurmayın.
- Senkron/asenkron başlatma. Güvenlik testlerinin bitmesini ya da bitmesini bekliyoruz. Yani, onları yeni başlattık ve devam ettik ve sonra her şeyin iyi ya da kötü olduğu durumunu aldık.
Hepsi mükemmel pembe bir dünyada. Gerçek hayatta böyle bir şey yok ama çabalıyoruz. Güvenlik kontrollerinin çalıştırılmasının sonucu, birim testlerinin sonuçlarına benzer olmalıdır.
Mesela büyük bir proje aldık ve şimdi onu SAST - OK ile tarayacağımıza karar verdik. Bu projeyi SAST'a aktardık, bize 20 güvenlik açığı verdi ve güçlü bir kararla her şeyin yolunda olduğuna karar verdik. 000 güvenlik açığı bizim teknik borcumuzdur. Borcu bir kutuya koyacağız, yavaş yavaş temizleyeceğiz ve kusurlu izleyicilere hatalar ekleyeceğiz. Bir şirket kiralayalım, her şeyi kendimiz yapalım veya Güvenlik Şampiyonlarının bize yardım etmesini sağlayalım; böylece teknik borç azalacaktır.
Ve yeni kodda yeni ortaya çıkan tüm güvenlik açıklarının, bir ünitedeki veya otomatik testlerdeki hatalarla aynı şekilde ortadan kaldırılması gerekiyor. Nispeten konuşursak, montaj başladı, biz çalıştırdık, iki test ve iki güvenlik testi başarısız oldu. Tamam - gittik, ne olduğuna baktık, bir şeyi düzelttik, diğerini düzelttik, bir dahaki sefere çalıştırdık - her şey yolundaydı, yeni bir güvenlik açığı ortaya çıkmadı, hiçbir test başarısız oldu. Bu görev daha derinse ve onu iyi anlamanız gerekiyorsa veya güvenlik açıklarını düzeltmek, işin altında yatanların büyük katmanlarını etkiliyorsa: kusur izleyiciye bir hata eklendi, önceliklendiriliyor ve düzeltiliyor. Ne yazık ki dünya mükemmel değil ve testler bazen başarısız oluyor.
Güvenlik kapısına bir örnek, koddaki güvenlik açıklarının varlığı ve sayısı açısından kalite kapısının bir benzeridir.
SonarQube ile entegre oluyoruz - eklenti yüklü, her şey çok kullanışlı ve harika.
Geliştirme ortamıyla entegrasyon
Entegrasyon seçenekleri:
- Kaydetmeden önce geliştirme ortamından bir tarama çalıştırma.
- Sonuçları Görüntüle.
- Sonuçların analizi.
- Sunucuyla senkronizasyon.
Sunucudan sonuçları almak böyle görünüyor.
Geliştirme ortamımızda tarama sırasında bu tür güvenlik açıklarının tespit edildiğini bildiren ek bir öğe görünür. Kodu hemen düzenleyebilir, önerilere bakabilir ve . Bunların hepsi geliştiricinin işyerinde bulunur ve bu çok kullanışlıdır - diğer bağlantıları takip etmenize ve ek bir şeye bakmanıza gerek yoktur.
Açık Kaynak
Bu benim en sevdiğim konudur. Herkes Açık Kaynak kitaplıklarını kullanır - her şeyin zaten uygulandığı hazır bir kitaplığı alabildiğinizde neden bir sürü koltuk değneği ve bisiklet yazasınız ki?
Elbette bu doğru ama kütüphaneler de insanlar tarafından yazılıyor, aynı zamanda belirli riskleri de içeriyor ve ayrıca periyodik veya sürekli olarak bildirilen güvenlik açıkları da var. Bu nedenle, Uygulama Güvenliğinde bir sonraki adım vardır; bu, Açık Kaynak bileşenlerinin analizidir.
Açık Kaynak Analizi - OSA
Araç üç büyük aşama içerir.
Kütüphanelerdeki güvenlik açıklarını aramak. Örneğin, araç bir kütüphane kullandığımızı biliyor ve bunu veya hata izleyicilerde kütüphanenin bu sürümüyle ilgili bazı güvenlik açıkları var. Kullanmaya çalıştığınızda araç, kitaplığın savunmasız olduğuna dair bir uyarı verecek ve güvenlik açığı olmayan başka bir sürümü kullanmanızı tavsiye edecektir.
Lisans saflığının analizi. Bu henüz burada pek popüler değil, ancak yurt dışında çalışıyorsanız, kullanılamayan veya değiştirilemeyen bir açık kaynak bileşeni kullandığınız için zaman zaman orada vergi alabilirsiniz. Lisanslı kütüphanenin politikası gereği bunu yapamayız. Veya değiştirip kullanırsak kodumuzu yayınlamalıyız. Elbette kimse ürünlerinin kodunu yayınlamak istemez ama siz de kendinizi bundan koruyabilirsiniz.
Endüstriyel ortamda kullanılan bileşenlerin analizi. Sonunda geliştirmeyi tamamladığımızı ve mikro hizmetimizin en son sürümünü yayınladığımızı varsayalım. Orada harika bir şekilde yaşıyor - bir hafta, bir ay, bir yıl. Onu almıyoruz, güvenlik kontrolleri yapmıyoruz, her şey yolunda görünüyor. Ancak aniden, sürümden iki hafta sonra, bu özel yapıda kullandığımız Açık Kaynak bileşeninde endüstriyel ortamda kritik bir güvenlik açığı ortaya çıkıyor. Neyi, nerede kullandığımızı kaydetmezsek bu güvenlik açığını göremeyiz. Bazı araçlar, halihazırda sektörde kullanılan kütüphanelerdeki güvenlik açıklarını izleme özelliğine sahiptir. Bu çok kullanışlı.
Özellikler:
- Gelişimin farklı aşamaları için farklı politikalar.
- Endüstriyel ortamda bileşenlerin izlenmesi.
- Kurum içindeki kütüphanelerin kontrolü.
- Çeşitli yapı sistemleri ve dilleri için destek.
- Docker görüntülerinin analizi.
Açık Kaynak analiziyle uğraşan sektör liderlerinden birkaç örnek.
Ücretsiz olan tek şey bu OWASP'tan. İlk aşamalarda açıp nasıl çalıştığını ve neleri desteklediğini görebilirsiniz. Temel olarak, bunların hepsi bulut ürünleridir veya şirket içidir, ancak tabanlarının arkasında hala İnternet'e gönderilmektedir. Güvenlik açıklarının varlığı hakkında bilgi almak için kitaplıklarınızı değil, hesapladıkları karmaları veya kendi değerlerini ve parmak izlerini sunucularına gönderirler.
Süreç entegrasyonu
Kütüphanelerin çevre kontrolü, harici kaynaklardan indirilenler. Harici ve dahili depolarımız var. Örneğin, Event Central, Nexus'u çalıştırıyor ve biz, depomuzda "kritik" veya "yüksek" durumu olan hiçbir güvenlik açığının bulunmadığından emin olmak istiyoruz. Bu tür güvenlik açıklarının ortadan kaldırılması ve dahili depoya gitmemesi için Nexus Güvenlik Duvarı Yaşam Döngüsü aracını kullanarak proxy oluşturmayı yapılandırabilirsiniz.
CI'ya entegrasyon. Otomatik testler, birim testleri ve geliştirme aşamalarına bölünme ile aynı seviyede: geliştirme, test, üretim. Her aşamada, herhangi bir kütüphaneyi indirebilir, herhangi bir şeyi kullanabilirsiniz, ancak "kritik" durumda olan zor bir şey varsa, belki de üretime geçme aşamasında geliştiricilerin dikkatini buna çekmeye değer.
Yapılarla entegrasyon: Nexus ve JFrog.
Geliştirme ortamına entegrasyon. Seçtiğiniz araçların geliştirme ortamlarıyla entegrasyonu olmalıdır. Geliştiricinin iş yerindeki tarama sonuçlarına erişimi olmalı veya CVS'ye başlamadan önce kodu kendisi tarayıp güvenlik açıklarını kontrol etme becerisine sahip olmalıdır.
CD entegrasyonu. Bu gerçekten hoşuma giden ve daha önce de bahsettiğim harika bir özellik: endüstriyel ortamda yeni güvenlik açıklarının ortaya çıkmasını izlemek. Bunun gibi bir şey çalışıyor.
Sahibiz Genel Bileşen Depoları — dışarıdaki bazı araçlar ve dahili depomuz. Yalnızca güvenilir bileşenleri içermesini istiyoruz. Bir isteğin proxy'sini oluştururken, indirilen kitaplığın güvenlik açıklarının olup olmadığını kontrol ederiz. Belirlediğimiz ve geliştirmeyle mutlaka koordine ettiğimiz belirli politikaların kapsamına giriyorsa, onu yüklemeyiz ve başka bir sürümü kullanmamız istenir. Buna göre, kütüphanede gerçekten kritik ve kötü bir şey varsa, geliştirici kurulum aşamasında kütüphaneyi almayacaktır - daha yüksek veya daha düşük bir sürümü kullanmasına izin verin.
- İnşaat sırasında kimsenin kötü bir şey kaydırmadığını, tüm bileşenlerin güvende olduğunu ve hiç kimsenin flash sürücüye tehlikeli bir şey getirmediğini kontrol ediyoruz.
- Depoda yalnızca güvenilir bileşenlerimiz var.
- Dağıtım sırasında, politikaya uygun olduğundan emin olmak için paketin kendisini bir kez daha kontrol ederiz: war, jar, DL veya Docker görüntüsü.
- Sektöre girerken endüstriyel ortamda olup bitenleri izliyoruz: kritik güvenlik açıkları ortaya çıkıyor veya görünmüyor.
Dinamik Analiz - DAST
Dinamik analiz araçları, daha önce söylenenlerin hepsinden temel olarak farklıdır. Bu, kullanıcının uygulamayla yaptığı çalışmanın bir tür taklididir. Bu bir web uygulamasıysa, uygulamanın nasıl çalıştığını ve işlediğini görmek için müşterinin çalışmasını simüle eden istekler göndeririz, ön taraftaki düğmelere tıklar, formdan yapay veriler göndeririz: tırnak işaretleri, köşeli parantezler, farklı kodlamalardaki karakterler. harici veri.
Aynı sistem, Açık Kaynak'taki şablon güvenlik açıklarını kontrol etmenize olanak tanır. DAST hangi Açık Kaynağı kullandığımızı bilmediğinden, yalnızca "kötü amaçlı" kalıplar atar ve sunucunun yanıtlarını analiz eder:
- Evet, burada seri durumdan çıkarma sorunu var ama burada değil.
Bunda büyük riskler var çünkü bu güvenlik testini test uzmanlarının çalıştığı tezgahta yaparsanız hoş olmayan şeyler yaşanabilir.
- Uygulama sunucusu ağında yüksek yük.
- Entegrasyon yok.
- Analiz edilen uygulamanın ayarlarını değiştirme yeteneği.
- Gerekli teknolojiler için destek yoktur.
- Kurulum zorluğu.
Sonunda AppScan'i başlattığımızda bir durumla karşılaştık: uygulamaya erişmek için uzun süre uğraştık, 3 hesap aldık ve mutluyduk - sonunda her şeyi kontrol edeceğiz! Bir tarama başlattık ve AppScan'in yaptığı ilk şey yönetici paneline girmek, tüm düğmeleri delmek, verilerin yarısını değiştirmek ve ardından sunucuyu tamamen kapatmak oldu. -talepler. Testlerle geliştirme şunları söyledi:
- Arkadaşlar benimle dalga mı geçiyorsunuz? Biz size hesap verdik, siz ise stand kurdunuz!
Olası riskleri göz önünde bulundurun. İdeal olarak, bilgi güvenliğini test etmek için en azından bir şekilde ortamın geri kalanından izole edilecek ayrı bir stand hazırlayın ve yönetici panelini tercihen manuel modda koşullu olarak kontrol edin. Bu bir sızma testidir; şu anda dikkate almadığımız kalan çaba yüzdeleri.
Bunu bir yük testi analogu olarak kullanabileceğinizi düşünmeye değer. İlk aşamada, 10-15 iş parçacıklı dinamik bir tarayıcıyı açabilir ve ne olduğunu görebilirsiniz, ancak genellikle uygulamanın gösterdiği gibi, iyi bir şey yoktur.
Genellikle kullandığımız birkaç kaynak.
Vurgulamaya değer herhangi bir güvenlik profesyoneli için bir “İsviçre bıçağıdır”. Herkes kullanıyor ve çok kullanışlı. Kurumsal sürümün yeni bir demo sürümü artık yayınlandı. Daha önce sadece eklentilere sahip bağımsız bir yardımcı program olsaydı, şimdi geliştiriciler sonunda birkaç aracıyı yönetmenin mümkün olacağı büyük bir sunucu yapıyorlar. Bu harika, denemenizi tavsiye ederim.
Süreç entegrasyonu
Entegrasyon oldukça iyi ve basit bir şekilde gerçekleşir: Başarılı kurulumdan sonra taramaya başlayın stand başvuruları ve başarılı entegrasyon testinden sonra tarama.
Entegrasyonlar işe yaramazsa veya taslaklar ve sahte işlevler varsa, bu anlamsız ve işe yaramaz; hangi modeli gönderirsek gönderelim, sunucu yine aynı şekilde yanıt verecektir.
- İdeal olarak ayrı bir test standı.
- Test etmeden önce oturum açma sırasını yazın.
- Yönetim sisteminin testi yalnızca manueldir.
Süreç
Genel olarak süreç ve özel olarak her aracın çalışması hakkında biraz genelleştirilmiş. Tüm uygulamalar farklıdır; biri dinamik analizle, diğeri statik analizle, üçüncüsü Açık Kaynak analiziyle, sızma testleriyle veya tamamen başka bir şeyle, örneğin olaylarla daha iyi çalışır. .
Her sürecin kontrole ihtiyacı vardır.
Bir sürecin nasıl çalıştığını ve nerede geliştirilebileceğini anlamak için, üretim ölçümleri, araçlardan alınan ölçümler ve kusur izleyicilerinden alınan ölçümler dahil, elinize geçen her şeyden ölçümler toplamanız gerekir.
Her türlü bilgi faydalıdır. Şu veya bu aracın daha iyi kullanıldığı, sürecin özellikle sarktığı yere farklı açılardan bakmak gerekir. Sürecin zamana bağlı olarak nerede iyileştirilebileceğini görmek için geliştirme yanıt sürelerine bakmak faydalı olabilir. Ne kadar çok veri olursa, her sürecin en üst seviyesinden ayrıntılarına kadar o kadar çok bölüm oluşturulabilir.
Tüm statik ve dinamik analizörlerin kendi API'leri, kendi başlatma yöntemleri ve ilkeleri olduğundan, bazılarının zamanlayıcıları vardır, bazılarının yoktur; bir araç yazıyoruz AppSec OrkestratörüÜründen tüm sürece tek bir giriş noktası oluşturup tek noktadan yönetmenizi sağlar.
Yöneticiler, geliştiriciler ve güvenlik mühendisleri, neyin çalıştığını görebilecekleri, bir taramayı yapılandırıp çalıştırabilecekleri, tarama sonuçlarını alabilecekleri ve gereksinimleri gönderebilecekleri tek bir giriş noktasına sahiptir. Evrak işlerinden uzaklaşmaya, her şeyi geliştirme tarafından kullanılan insana dönüştürmeye çalışıyoruz - durum ve metriklerle birleşme sayfaları, Jira'daki veya çeşitli kusur izleyicilerindeki kusurlar veya CI'da senkronize/asenkron bir sürece entegrasyon /CD.
Önemli Noktalar
Araçlar asıl mesele değil. Öncelikle süreci iyice düşünün, ardından araçları uygulayın. Araçlar iyi ama pahalıdır; bu nedenle süreçle başlayabilir ve geliştirme ile güvenlik arasında iletişim ve anlayış oluşturabilirsiniz. Güvenlik açısından her şeyi "durdurmaya" gerek yok, geliştirme açısından bakıldığında, yüksek mega süper kritik bir şey varsa, o zaman ortadan kaldırılması ve soruna göz yumulmaması gerekir.
Ürün kalitesi - ortak hedef Hem güvenlik hem de kalkınma. Tek bir şey yapıyoruz, her şeyin doğru şekilde çalışmasını ve itibar riski veya mali kayıp olmamasını sağlamaya çalışıyoruz. Bu nedenle iletişimi geliştirmek ve ürünün kalitesini artırmak için DevSecOps, SecDevOps yaklaşımını destekliyoruz.
Zaten sahip olduklarınızla başlayın: gereksinimler, mimari, kısmi kontroller, eğitimler, yönergeler. Tüm uygulamaların tüm projelere hemen uygulanmasına gerek yoktur - yinelemeli olarak hareket et. Tek bir standart yok deney ve farklı yaklaşımları ve çözümleri deneyin.
Bilgi güvenliği kusurları ile işlevsel kusurlar arasında eşit bir işaret vardır.
Her şeyi otomatikleştirinbu hareket ediyor. Hareket etmeyen ne varsa taşıyın ve otomatikleştirin. Bir şey elle yapılıyorsa, bu sürecin iyi bir parçası değildir. Belki de onu incelemeye ve otomatikleştirmeye değer.
IS ekibinin boyutu küçükse - Güvenlik Şampiyonlarını kullanın.
Belki de bahsettiğim şey sana uymayacak ve kendine ait bir şey bulacaksın - ve bu iyi. Ancak prosesinizin gereksinimlerine göre araçları seçin. Topluluğun bu aracın kötü, bunun iyi olduğuna dair söylediklerine bakmayın. Belki ürününüz için tam tersi geçerli olacaktır.
Araçlar için gereksinimler.
- Düşük seviyeli Yanlış Pozitif.
- Yeterli analiz süresi.
- Kullanım kolaylığı.
- Entegrasyonların kullanılabilirliği.
- Ürün geliştirme yol haritasını anlamak.
- Araçları özelleştirme imkanı.
Yuri'nin raporu DevOpsConf 2018'in en iyilerinden biri olarak seçildi. Daha da ilginç fikirler ve pratik vakalarla tanışmak için 27 ve 28 Mayıs'ta Skolkovo'ya gelin. içinde . Daha da iyisi, deneyiminizi paylaşmaya hazırsanız, o zaman Rapor için 21 Nisan'a kadar.
Kaynak: habr.com