Son sürat yazı dizimize devam ediyoruz. Son bölüme hoş geldiniz. Yazı dizimizin birinci bölümünde ana başlığımız olan Security Desing Principles’ı açıkladıktan sonra onun alt başlıklarından Risk, Frame Risk, Treat Risk ve Information Systems’ Controls konularına değindik. Daha sonra yazımızın ikinci bölümünde yine Security Design Principles (Güvenlik Dizayn Prensipleri) içerisinde yer alan Need to Know, Least Privilege, Access Control, Seperation of Duties, Defense in-depth gibi konulara değindik.
Eğer ilk iki bölümü okumadıysanız bu yazıyı okumadan önce onları okumanızı tavsiye ederim. Aşağıdaki linklere tıklayarak ulaşabilirsiniz.
Yazı dizimizin son bölümünde aşağıdaki konseptlere yakından bakacağız.
- Fail Safe
- Economy of Mechanism and Leveraging Existing Components
- Complete Mediation
- Open Design
- Psychological Acceptability
- Least Common Mechanism and Single Point of Failure
Bu yazımızdan sonra yeni yazılarımızda artık konseptlerden uzaklaşıp işin içine girmeye başlayacağız.
Ben daha çok çay insanıyım. Kahveyi de severim ancak çay her zaman daha sıcak gelmiştir bana. Çayımız, kahvemiz hazırsa buyurun başlayalım. :)
Fail Safe
Fail’in safe’i mi olur? Olur. Olmak zorunda. Neden?
Bir sistem fail olurken, yani çökerken, çalışamaz hale gelirken veya hatalar sarmalına girerken bunu öyle bir yapmalı ki bu esnada sistemin veya şirketin güvenliğini, veri bütünlüğünü veya gizliliğini tehlikeye atmamalıdır.
Fail Safe aslında bir sistemin güvenliği tehlikeye atmayacak ve kuruluşun varlıklarını koruyacak şekilde başarısız olma kabiliyetidir. Fail Safe’i kendi içerisinde ikiye ayırabiliriz. Birincisi bildiğimiz fiziki koşullar. Elektrik kesintisi, sıcaklık yükselmesi veya donanım arızaları gibi. Diğer konu ise daha mantıksal alanda kalan Exception Handling konusu.
Bir sistemi fail safe yapan madalyonun iki yüzü vardır. Birincisi çökmelere karşı dayanıklılığı ve yedekli olmasıdır. Diğer yüzü de fail olurken ne yaptığı ve nasıl fail olduğudur.
Fail safe sistemlerin mantığını anlamak için birkaç kavramı açıklamamız gerekecek. Çünkü yazılım güvenliği söz konusu olunca fail safe olmanın yolu exception handling’den geçiyor.
Exception Handling kavramı, normal süreç akışının dışında bir işlemi işlemektir. Çoğu zaman error kavramı ile karıştırılır. Ancak her exception (yani istisna) bir error kökenli olmak zorunda değildir. Error yani hata dediğimiz kavram adı üstünde bir hatadır. Ancak exception yani istisna, bir fonksiyonel anomalidir. Beklenmeyen bir davranış şeklidir.
Bir sistemin fail safe olabilmesi için:
- Error ve Exception handling doğru şekilde uygulanmış olmalıdır.
- Gerekli loglama sistemi kurulmalıdır. Bu hem hatayı anlamak hem de güvenlik ihlallerine müdahale etmek için çok önemlidir.
- Deny by default, yani varsayılan olarak reddeden mantık çerçevesinde kurulmuş olmalıdır.
- Normal çalışma düzenine geçebilen bir yapı kurulmalıdır.
Yazılım dünyasında non-verbose diye bir kavram vardır. Anlamı ayrıntılı olmayandır. Eğer saldırganların bir fail durumunda sisteminiz ile ilgili detaylı bilgi edinmesini istemiyorsanız non-verbose error ve exception handling yapılmalıdır. Yani hatalar ve istisnalar saldırganlara bilgi kaçırmayacak kadar sıkı ama kullanıcı ve yazılımcıların hatayı anlayabileceği kadar açık ve net olmalıdır. Çok hassas bir denge değil mi?
İki konuya dikkat edilirse bu denge rahatlıkla korunabilir. Birincisi saldırganlara bir veri sağlayıp sağlamadığımızı kontrol etmeliyiz. İkincisi handling için error kodları kullanmalı ancak line numbers kullanmamalıyız.
Toparlayacak olursak, Fail Safe bir sistem varlıkların bir hata veya arıza durumunda korunmasını sağlar. Bunu da bahsettiğimiz yaklaşımlar ile sağlar.
Economy of Mechanism and Leveraging Existing Components
Ne kadar uzun bir terim. Önce Economy of Mechanism’den başlayalım. Şimdi söyleyeceğim şey size başta garip gelebilir. Güvenlik basitliği sever. Ne kadar çok karmaşa ve kompleks yapı özellikleri mevcutsa güvenliğin yönetimi o denli zorlaşır. Yani güvenlik ile karmaşıklık arasında negatif bir korelasyon vardır. Karmaşıklığı artan sistemlerin anlaşılabilirliği azalır, anlaşılabilirliği azalan yapıların güvenlik kontrolleri zorlaşır. Aynı zamanda bir şeylerin ters girmesi için çok fazla olasılık rotaya çıkmaya başlar.
4.000 satır koddan oluşan bir yazılımın güvenliği ile 2.000.000 satır koddan oluşan bir yazılımın güvenliğini kıyaslarsanız ne demek istediğimi daha net anlayabilirsiniz.
Ünlü fizikçi Albert Einstein diyor ki “If you can’t explain it simply, you don’t understand as well enough”. Eğer basitçe (sade bir şekilde) açıklayamıyorsan yeterince anlamamışsın demektir. Aynısını güvenlik ve yazılım dünyasına uyarlayacak olursak eğer bir ihtiyacı çözecek yazılımı en basit haliyle yaratamıyorsanız olayı anlamamışsınız demektir. Güvenlik zaten kendi içerisinde çok karmaşık dinamiklere sahip olduğu için işleri daha fazla karmaşıklaştırarak zorlaştırmamak gerekir.
Çünkü IT dünyasının her alanında olduğu gibi güvenlik alanında da bir sorunla karşılaşıldığında troubleshooting (sorun çözme) adımları uygulanır. Sistem ne kadar sade ise troubleshooting o kadar rahat olacaktır.
Economy of mechanism sadece işleri sadeleştirerek kolaylaştırmaz maliyet ve performans açısından da fayda sağlar. Örneğin bir çok uygulamamız olsun. Her biri de authentication ve authorization süreçlerine ihtiyaç duysun. Her biri için ayrı login/register sistemleri veya yetkilendirme sistemleri tasarlamak yerine bir Federated Identity Management çözümü, bir SSO (Single Sign-On) çözümü kullanılması hem karmaşıklığı azaltır, hem maliyeti düşürür hem de performansı arttırır.
Leveraging Existing Components, mevcut yazılım bileşenlerinin, kodun ve işlevselliğin yeniden kullanımını teşvik eden bir konsepttir. Bu sayede saldırı yüzey alanı artmaz ve yeni risklerin ortaya çıkma ihtimali azalır.
Bu sadece kendi oluşturduğumuz custom modüller için geçerli değildir. Aynı zamanda çok kullanılan librarylerin (kütüphane) kullanılması gibi. Oturup sıfırdan kütüphane yazmak mı mantıklı yoksa arkasında topluğu olan sürekli audit edilen ve hazır olarak sunulan open source kütüphaneleri kullanmak?
Leveraging Existing Components şunları sağlar:
- Sermaye giderleri azalır.
- Hali hazırda ödeme yaptığınız modülleri kullanırsınız.
- Ekstra insan ve operasyon gücüne ihtiyaç duyulmaz.
- Karmaşıklık artmaz.
Elbette bunların avantajları olduğu kadar dezavantajları da mevcuttur. Örneğin esnekliğinizi kaybedebilirsiniz. Veya belli başlı vendor’lara muhtaç kalabilirsiniz gibi.
Toparlayacak olursak Economy of Mechanism, birden fazla sistem için mevcut olan çözümlerin kullanılmasını sağlar. Leveraging Existing Components ise birden çok uygulama veya sistem tarafından kullanılabilecek ortak kütüphanelerin ve denetimlerin kullanılmasını sağlar.
Yine her maddede belirttiğimiz gibi, güvenlik bir denge işidir. Ne çok fazla, ne çok az. Her zaman gerektiği kadar.
Complete Mediation
Nesne, yazılım geliştirme süreçlerindeki en önemli elementlerden birisidir. Nesne dendiğinde akla birçok tanım gelebilir. Bu bahsedeceğimiz nesne ifadesini yazılım geliştirme süreçlerindeki herhangi bir şey olarak düşünebilirsiniz.
Complete Mediation, bir nesne için talep edilen yetkilendirmeleri (rights yani haklar, privileges yani ayrıcalıklar) kontrol ederek, her seferinde bu yetkilendirmelerin kontrol edilmesini ifade etmektedir. Biliyorum şu an hiç oturmadı. Kemerlerinizi bağlayın ve uçuşa geçmemizi bekleyin. Havadayken her şey daha net anlaşılacak. :)
Hadi netleştirelim, Serhan’ın (özne), bilgisayarı (nesne) ile müzik dinleme isteği (eylemle) olsun. Bunun için de Fatih Tezer’den yetki alması gereksin. Şimdi Serhan sadece bir müzik dinlemeyecek, belki ardı ardına 10 müzik dinleyecek. Complete Mediation öyle bir terimdir ki hem Serhan’ın kesintisiz müzik dinlemesini sağlamalı hem de yetkilendirme konularının bypass edilmediğinden emin olmalı, güvenliğe katkı sağlamalıdır.
Terim olarak konuyu sonuçlandırmak için bir alıntı yapalım:
Complete Mediation (Tam Arabuluculuk) bir öznenin, bir nesne ve bir eylemle ilgili olarak yetkilendirilmesi doğrulandığında, öznenin bir nesneye erişim talebinde bulunduğu her seferde bu doğrulamanın gerçekleştiğini belirtir. Yapı, tekrarlanan erişimlerde bile yetkilendirme sistemini hiçbir zaman engellenmeyecek şekilde tasarlanmalıdır. Bu ilke, güvenlik çekirdeğinin işletim sistemlerinde kullanımıyla ilgili olan, atlanamayan bir işlevselliktir ve işletim sistemi (OS) tarafından işlenen tüm iş parçacıkları için güvenlik yönetimine izin verir. Düzgün bir şekilde yapılandırılmış kimlik doğrulama sistemlerine sahip modern işletim sistemleri ve BT sistemlerinden doğrudan taviz vermek çok zordur. Çoğu riskten ödün verme yolu, kimlik doğrulama gibi kritik bir sistemin atlanmasını içerir. Bunu akılda tutarak, tasarım sırasında potansiyel bypass durumlarını incelemek ve bunların somutlaştırılmasını önlemek önemlidir.
Sonuç olarak sistem tasarlanırken Complete Mediation konseptinin uygulanması gerekir.
Open Design
Open Design, Türkçesi ile açık tasarım ilkesi, bir sistemin güvenliğinin güvenlik tasarımının biçiminden bağımsız olması gerektiğini belirtir. Yani yazılımın 1990 yılları öncesinde olduğu gibi kapalı bir kutu gibi saklanmaya çalışılmasının tersidir. Yazılımın güvenliği, sadece güvenlik tasarımına değil modern kriptografik anahtarların doğru şekilde kullanıldığı prensiplere bağlı olmalıdır. Yani güvenlik hangi şifreleme algoritmasının kullanıldığının gizli tutulması ile değil o şifreleme algoritmasının anahtarlarının doğru korunması ile ortaya çıkması görüşüdür. Siz bir sistemin hangi şifreleme algoritmasını kullandığını öğrenebilirsiniz. Bunda bir sorun olmamalıdır.
Yazılım, Open Design konsepti kullanılarak tasarlandığında, tasarımın kendisinin gözden geçirilmesi, incelenmesi ve hatta tersine mühendislik ile karşı karşıya kalması yazılımdaki güvenlik önlemlerine zarar veremeyecektir.
Psychological Acceptability
Türkçesi ile psikolojik olarak kabul edilebilirlik, güvenlik önlemlerinin kullanımını teşvik etmek için kullanılır. Bir sistemi korumak için alınabilecek o kadar çok önlem vardır ki bunları saymaya kalksak bitiremeyiz. Ve hatta bazı sistemleri o kadar güvenli yaparız ki asla hacklenmez. Çünkü o güvenlik önlemleri artık o sistemi kullanılamaz hale getirir :) İşin şakası bir yana güvenlik mimarisi, işlevselliği ve ürün özelliklerini baltalamamalı, kullanıcıda keşke bu güvenlik önlemi olmasa dedirtmemelidir. Çünkü önlemler kullanıldığı müddetçe geçerlidir.
Güvenlik mimarisi, işlevselliği kolay ve aynı zamanda kullanıcıya şeffaf olmalıdır. Kullanım kolaylığı ve şeffaflık psikolojik kabul edilebilirliğin en önemli iki unsurudur.
Bir de şu açıdan bakalım. Kullanıcılar, bir sistemin ve güvenliğinin en önemli parçalarından biridir. Bir kullanıcıyı bir sistemin güvenliğine dahil etmek, güvenlik hususlarının kullanıcı tarafından psikolojik olarak kabul edilebilir olacak şekilde tasarlanmasını gerektirir. Bir kullanıcıya, kullanıcıyı engellediği görülen bir güvenlik sistemi sunulduğunda o önlemlerin kullanım oranı oldukça düşecek ve hatta kötü niyetli olmasa bile yeni bypass metotlarının gelişmesine neden olacaktır.
Least Common Mechanism and Single Point of Failure
Bazı kavramlar Türkçeye çevrilmesi zor kavramlardır. Bu nedenle yazılarımızda terimlerin orijinal dilindeki halini kullanıp, içeriğini açıklamaya gayret gösteriyoruz. Çünkü iş hayatında bu kavram karşınıza “En az yaygın mekanizma kavramı” olarak çıkmayacak.
Least Common Mechanism bir bilginin yanlışlıkla paylaşılmasını önlemek amacıyla tasarlanmış bir konsepttir. Birden fazla prosesin ortak mekanizmalar tarafından paylaşılması, kullanıcılar veya prosesler arasında potansiyel bir bilgi yolu oluşturur. Ve yapılar büyüdükçe bu yol çok daha karmaşık bir hale gelir. Tıpkı İstanbul trafiği gibi. Yollara gelen yeni araçlar, yolların etrafına kurulan yeni yerleşim yerleri gibi durumlar süreci çözülemeyecek seviyelere getirebilir. Eğer kullanıcılar ve süreçler farklı ayrıcalık seviyelerinde ise bu güvenlik konsepti devreye girer, birden fazla kullanıcı veya işlem için ortak olan mekanizmaların paylaşılmasına izin verilmez.
Örneğin bir yılı dolan personelin kalan yıllık izinlerini hesaplayan prosesi henüz yılını doldurmamış bir personelin aynı fonksiyonu kullanılmasına izin verilmez.
Son konseptimiz SPoF yani Single Point of Failure. SPoF, bir sistemin başarısız olması durumunda tüm sistemin başarısız olduğu herhangi bir yönüdür. Zincirin kopmasına sebep olacan “zayıf halka”dır. Gerçekten güvenli olan sistemler bir SPoF’a sahip olmayan sistemlerdir. Yazılım tasarım aşamasındayken (görsel değil mimari tasarım) tüm sorun olabilecek noktaları analiz edilmeli ve herhangi bir komponentin tüm sistemin fail olmasına sebep olmayacak şekilde konumlandırılmasına dikkat edilmelidir.
Ve bu konsept ile birlikte bir yazı dizimizin daha sonuna geldik. “Güvenli Yazılım Geliştirme Yaşam Döngüsünün” ve “Güvenli Yazılım Mimari”lerinin temel konularını bitirmiş olduk. Artık daha aktif olacağımız konulara giriş yapacağız.
Sorularınız ve düzeltme önerileriniz için iletişim: serhanw@pm.me
Kaynaklar:
CSSLP Certification All-in-One Exam Guide, Second Edition 2nd Edition by Wm. Arthur Conklin, Daniel Shoemaker
Official (ISC)2 Guide to the CSSLP CBK ((ISC)2 Press) 2nd Edition by Mano Paul
