2021'in ilk yazısından herkese merhaba. Umarım bu yıl 2020'ye nazaran daha az kaos, daha çok umut dolu geçer. Core Security Concepts Part-1 ve Part-2'de ana güvenlik konularımızın kavramlarını inceledik. Şimdi de Security Concepts dizisini 3 bölüme ayırıp yine konseptleri kavram olarak göreceğiz. İncelediğimiz tüm bu kavramlar ileride mimari oluştururken bilmemiz gereken kavramlar. Yine bu yazıdaki bilgilere anlam verebilmeniz için bir önceki bölümdeki iki yazıyı okumuş olmanızı tavsiye ediyorum.
Eğer Yazılım Güvenliği: Core Security Concepts Part-1 ve Part-2'yi henüz okumadıysanız aşağıdaki linklere tıklayarak okuyabilirsiniz:
Bu dizide 3 bölüm halinde aşağıdaki konseptleri inceleyeceğiz:
- Security Design Principles
- Risk
- Frame Risk
- Treat Risk
- Information Systems’ Controls
- Need to Know
- Least Privilege
- Access Control
- Seperation of Duties
- Defense in-depth
- Fail Safe
- Economy of Mechanism and Leveraging Existing Components
- Complete Mediation
- Open Design
- Psychological Acceptability
- Least Common Mechanism and Single Point of Failure
Birazdan bahsedeceğimiz Security Design Principles, bu yazı dizisinde değineceğimiz konuların ana başlığı aslında. Yani tüm başlıkları güvenli yazılım dizayn etme başlığı altında incelemiş oluyoruz.
Security Design Principles
Burada konumuz Core Security Concepts’in nasıl implemente edileceğidir. Diğer bir deyişle hangi mekanizmaları CIA ve IAM için IT sistemlerimize entegre edebileceğimiz ile ilgilenmektir.
Güvenlik yazılımlara entegre edilirken dört başlığın dördünde de dizayn aşaması güvenlik ile harmanlanmalıdır:
- Applications
- Networks
- Hosts
- Databases
İş dünyasında güvenliğin karşılık bulmasını sağlayan şey var olan riskler ve o risklerin azaltılması isteğidir. Biraz daha açacak olursak, aslında bir tehditin istismar ve güvenlik açığından yararlanma ve dolayısıyla bir varlığa zarar verme olasılığının minimize edilmesi amaçlanır.
Tüm bu işlemler kontroller ile gerçekleştirilir. Kontrol kelimesini hem kontrol etmek hem kontrol listesi gibi düşünebilirsiniz. Bu kontroller birkaç ayrı kategoride oluşturulur:
- Yönetimsel kontroller
Genellikle şirketlerin yönetim takımı tarafından taleplerin yerine getirilip getirilmediğinin takip edilmesi amacıyla oluşturulur. Daha çok Business Logic (İş Mantığı) ile ilgili kontrollerdir.
Teknik kontroller
Genellikle şirketlerin teknik/IT ekipleri tarafından oluşturulan kontrollerdir. Genel amaç teknik olarak yapılması gerekenlerin yapılıp yapılmadığının kontrol edilmesidir.
Fiziki/Operasyonel Kontroller
Genellikle şirketlerin operasyonu yöneten idari işler gibi ekipleri tarafından oluşturulan kontrollerdir. Amaç hem teknik kontrollerin hem yönetim kontrollerinin ihtiyaç duyacağı aktivitelerin takibidir.
Kontroller bazen limitasyon için bazen mali kısıtlamalar için bazen de bir tehlikeyi önlemek için uygulanmaktadır.
Toparlayacak olursak güvenliğin temel amacı riskleri azaltarak işin kontrol altında tutulmasını sağlamaktır. Bunun için işin hangi kontrollere ihtiyacı varsa o ihtiyaçlar belirlenmeli ve onlara uygun olarak kontroller oluşturulmalıdır.
Risk
Belki de tüm dünyanın en büyük sorunu. Öngörülemeyen tehlikeler, öngörülemeyen zamanlarda işin aksamasına ve hatta durmasına sebep olabilir. Bir önceki maddemizde kontrollerin amacı riski azaltmaktır dedik. Şimdi ise risk konusunda girelim.
Öncelikle şunu iyi anlamak gerekir. İş hayatında her assetin bir değeri vardır. Ve bu değer onun ne kadar korunması gerektiğini gösterir. Bu değer bazen kanunlara göre, regülasyonlara göre veya assetin barındırdığı verilere göre belirlenir. Bu belirleme yapılmadan güvenliğin sağlanması mümkün değildir. Çünkü önce neyi koruduğumuzu bilmeliyiz. Aksi takdirde, hak ettiğinden daha fazla efor harcanan assetler diğer açık kapılarımızı görmemizi engelleyebilir ve maliyetlerimizi çok yükseltebilir.
Kimsenin şirketteki assetlere hak ettiğinden daha fazla değer ve güvenlik vermemesi gerekir. Ve elbette hak ettiğinden daha azını da.
Bir güvenlik mimarisi kurgulanmadan önce tüm riskler belirlenmeli ve tüm kontrollerin bu dizaynda riskleri adreslediğinden emin olunmalıdır.
Riskin kontrol altında tutulabilmesi için (bakınız burada riskin bitirilmesi demiyoruz) risk management yani risk yönetimi yapılması gerekir. Risk yönetimi, iş hedeflerine ve amaçlarına ulaşılıp ulaşılmadığını ortaya koyar. Aynı zamanda istenmeyen olayların tespit edilmesine ve bu tespit sonrasında ne yapılacağının belirlenmesine olanak sağlar.
Risk nedir? Risk budur. 😄 Şakayı bir kenara bırakacak olursak risk, istenmeyen olayların gerçekleşme ihtimalidir. Risk sadece sözel olarak belirtilen bir olgu değildir. Yani risk bir işletmenin potansiyel durum veya olay tarafından ne ölçüde tehdit edildiğinin bir ölçüsü ve tipik olarak, durumun veya olayın meydana gelme olasılığını artırması durumunda ortaya çıkabilecek olumsuz etkilerin bir fonksiyonunu spesifik olarak ölçümlemektir.
Bu kadar karmaşık cümleler sizi korkutmasın. Aslında olay şudur:
- Koruduğum şey ne ve nelere sahip?
- Olabilecek şeyler ne?
- İhtimalleri ne?
- Sonuçları ne?
Bunun için özel bir framework var. NIST SP800–39. Detaylı bilgi isteyenler ayrıca aşağıdaki linkten inceleyebilirler.
Risk o kadar geniş bir konu ki, bununla ilgili detaylı bir doküman daha yazıp yayınlamayı planlıyorum.
Bir de bizim açımızdan risk nedir dersek CIA’in bozulmasıdır.
Frame Risk
Frame Risk, riskin çerçevesidir. Bir metafor yapacak olursak sistemimizin hangi ortamda yer alacağının bir haritasının çıkarılmasıdır. Örneğin sistemimiz herkese açık mı yoksa izole mi? Bu bütün risklerin bakış açısını değiştirecektir.
Temel soru şudur: Sistemimiz ne kadar kritik ve biz bu sisteme nasıl bir güvenlik uygulamalıyız? Bu sorunun cevabını verebilmek için sistemimizin risk çerçevesini bilmeli, sınırlarını anlamalı ve içinde bulunduğu çevreyi (environment) çok iyi algılamalıyız.
Bu çerçeveyi çizebilmek için öncelikle tehditlerin (threat) kaynakları neler olabilir onlara bakalım.
Tehditler doğal kaynaklı (afet, deprem, yangın vb.), insan kaynaklı (çalışan, dış kaynak nedenli, bilinçli veya bilinçsiz), koşullara bağlı (yan odada yangın çıkması gibi) veya çevresel (elektrik kesintisi, soğutma sistemi arızası gibi) olabilir. Bu kaynaklardan gelebilecek tehditler sistemimizi nasıl etkiliyor onun bir çerçevesi çizilmelidir.
Toparlayacak olursak frame risk, iş ve IT risklerini ele almak için kontrol çerçevesinin geliştirilmesine destek sağlar.
Treat Risk
Treat risk veya bir diğer adıyla risk treatment, risk önleme, azaltma veya riski düşürme anlamında kullanılabilir. Burada amaç risk değerlendirmesinin sonucuna göre bir response (yanıt) sistemi oluşturmaktır.
Bu aşama genellikle şirket yönetimlerinin bakış açısına, hukuki durumlara ve regülasyonlara göre planlanır.
Genelde üç aşaması vardır:
- Avoid Risk (Riskten Kaçınma)
Riski oluşturacak tüm faaliyetlerden kaçınmak temel amaçtır. Eğer risk oluşuyorsa ve o faliyetten kaçınma hakkımız var ise kaçınma hakkı kullanılır.
2. Transfer/Share (Transfer etmek veya paylaşmak)
Tıpkı sigorta yaptırır gibi, eğer riskimizi paylaşabileceğimiz üçüncü partiler var ise onlarla riski paylaşmak veya riskin tamamını diğer tarafa transfer etmek amaçlanır.
3. Accept (Kabul etme)
Teoride riskleri bertaraf etmek mükemmel gözükse de gerçek yaşamda maalesef tüm riskleri bertaraf etmek mümkün olmuyor. Hatta bu riskler bazen transfer edilemediği gibi başkaları ile de paylaşılamaz. Bu gibi durumlarda riskin kabul edilmesi gerekir.
Hadi gelin bir de dördüncü madde ekleyelim:
4. Reduce/Mitigate (Riski azaltma veya riskten kaçınma)
Eğer riski oluşturan eylemden vazgeçemiyorsak, birine transfer etme veya biriyle paylaşma hakkımız yoksa, riski olduğu gibi kabul etmek bizim için sorun olacaksa o riskin etkilerini minimize etmek için çalışmalar yapılmalıdır.
Bu konuyu sonlandırmadan önce hakim olunması gereken üç konseptten bahsetmem gerekiyor.
Risk Acceptance
Bu kavram şirketin kaybetmeyi göze alacağı sonuçlar için risk kabul seviyeleridir. Bunların da risk çalışmasında mutlaka yer etmesi gerekir.
Residual Risk
Bu kavram kontrollerin uygulanmasından sonra hala kalan riskin kendisidir.
Cost/Benefit Analysis
Bu kavram ise tamamen paraçokomel eğrisi ile ilgili. Yani ne kadar ekmek o kadar köfte. Bunu en güzel şu örnek ile anlatabiliriz. İstanbul’a üçüncü köprü yapıldığında bazı sınıflardaki araçların sadece oradan geçmesi zorunlu kılındı. Eğer yeni yapılan köprüden geçmez birinci ve ikinci köprüden geçerseniz bir para cezası kesiliyordu. Ancak o ceza olan X ₺, köprüden geçiş ücreti olan Y ₺’den çok daha düşüktü. Bu durumda birçok insan risk alıp ceza yemeyi tercih etti. Ta ki X ₺ olan ceza XXX₺ yapılana kadar. :)
Toparlayacak olursak risk treatment, riski oluşturan eylemden tamamen kurtulmak, kurtulamıyorsak o riski başkasına transfer etmek, veya riski paylaşmak, o da olmuyorsa riskin sonuçlarını mümkün olduğu kadar azaltmak/hafifletmek ve o da olmuyorsa riski kabullenmektir.
Information Systems’ Controls
Information Systems’ Controls, yani IT kontrolleri, iş amaçlarına ve hedeflerine ulaşılacağına dair makul güvence sağlar. Peki bunu nasıl sağlar? İstenmeyen olayların önlenmesi veya tespit edilip düzeltilmesi ile.
Bu kontroller, riski azaltmak için bir organizasyon içindeki her seviyede var olmalıdır. Kontroller tek başına yeterli olmayıp, şirket içindeki tüm bireylerin uygun şirketteki risk kültürüne sahip olması ve kontrol etkinliklerine aktif olarak katılmaları sağlanmalıdır. Bakın güvenlik konusunda insan kaynaklarının önemine değindik. :) Güvenlik sadece Cyber Security ekiplerinin sağlayacağı bir olgu değildir.
IS kontrolleri neler olabilir onlara bakalım:
- Preventative (Önleyici)
- Detective (Tespit edici)
- Corrective (Düzeltici)
- Manual (Her seferinde manuel olarak yapılan)
- Automated (Tamamen otomatize edilmiş)
Tüm bu kontrollerin gerçekleştirilebilmesi için sektörde standart haline gelmiş çalışmalar vardır. Bu çalışmalar “Control Frameworks” olarak geçer. Onlara örnek verecek olursak Cobit 5, ISO/IEC 27001, ISO/EC 27002 ve NIST SP800–53'ü örnek verebiliriz.
Güvenlik sektörüne adım atanlar “yahu güvenlik güvenlik dedik şimdi gelmiş sürekli konsept, kontrol, standart konuşuyuz bu nasıl iş!!!” diyebilir. Ancak ileride detaylı olarak inceleyeceğimiz yazılım güvenliği konularının ve tam anlamıyla bir süreç olan güvenli yazılım geliştirmenin anlaşılabilmesi için tüm bu konseptlere, bilgilere ve kavramlara hakim olunması gerekiyor.
Yazılım Güvenliği: Security Concepts yazı dizisinin 2. bölümünde Need to Know, Least Privilege, Access Control, Seperation of Duties ve Defense in-depth konularını inceleyeceğiz.
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
