Güvenlik zayıflıklarını güçlendirmenize ve her iki haftalık geliştirme sprintinde saat gibi görünen değişikliklere ve yeni ortamlara daha hızlı tepki vermenize yardımcı olması için bu kaynakları kullanmayı planladınız.
Peki, bir CISO ne yapacak? Mühendislerinize daha çok çalışmalarını söylemek gerçekten işe yaramaz. İşi daha verimli bir şekilde tamamlamanın ve daha azıyla daha fazlasını yapmanın bir yoluna ihtiyacınız var. Otomasyona ihtiyacınız var. Herkesin ilk tepkisi, otomasyonun her yerde çalışmadığıdır – ve bu doğru – ancak çalıştığı pek çok durum vardır.
Neyin Otomatikleştirileceğini Belirleme
Otomasyonun zamandan tasarruf etmesinin, çözümün ön geliştirme ve bakım maliyetini haklı çıkarabileceği kadar sık gerçekleşen, tekrarlayan görevleriniz olduğunda otomasyona ulaşın. Düşünülmesi gereken şeyler:
- Sıklık: Görev ne sıklıkla gerçekleşir? Haftada 100 kez yapıyorsanız, 30 saniyelik kısa bir görev bile otomasyon için değerli bir hedef olabilir.
- Standardizasyon: Görev standartlaştırılmış mı? İyi belgelenmiş oyun kitaplarına sahip olan veya personelinizin uykularında yapabileceklerini hissettikleri tekrarlanan görevler, otomasyon için harika adaylardır, ancak önemli ölçüde insan ilgisi gerektiren görevler değildir.
- Alt görevler: Bir görevin bir kısmı bölünebilir ve otomatikleştirilebilir mi? Uçtan uca otomasyon her zaman mümkün değildir, ancak kısmi otomasyon değerli olabilir. Ancak, kısmi otomasyonlar aşağıdakilerle sınırlıdır:
- Fırsat maliyeti: Bu görevin dikkate alınması gereken harici maliyetleri var mı? Bir mühendisin iş akışını kesintiye uğratan ve işi 20 dakika geciktiren 5 dakikalık bir görev aslında 25 dakikalık bir iştir. Bu mühendisin zamanı, tamamlanmış kesintiye dayalı görevlere kıyasla inşa etmeye daha iyi hizmet ediyorsa, görev, otomasyon için en önemli adaydır. Bir görevi otomatikleştirmenin fırsat maliyetini değerlendirirken bu faktörleri eklediğinizden emin olun.
Bir görev otomasyon için iyi bir aday değilse, ancak yine de çok zaman alıyorsa, otomatikleştirmek ve bir görevin gerçekleştirilmesi gereken sayısını azaltmak için farklı ancak ilgili bir süreç tanımlayabilir misiniz? Örneğin, güvenlik açığı bulunan bağımlılıkları üretimde otomatik olarak güncelleyemeyebilirsiniz, ancak bunları geliştirme sırasında işaretlemek, o kadar ileri giden çok daha az bağlantınız olduğu anlamına gelebilir.
Örnek: PCI Taramalarını ve Raporlamayı Otomatikleştirme
Otomasyonu, birçok güvenlik ekibinin varlığının belası olan güvenlik açığı taraması bağlamında ele alalım. Bir işverende, tüm altyapımız için haftalık PCI taramaları yapmam gerekiyordu. Her hafta, bu taramayı çalıştırmadan önce, bulut altyapısı sağlayıcılarımızdan IP ve ana bilgisayar adları listelerini manuel olarak derleyerek ve ardından tarayıcının Web arayüzünde hedef listesini güncelleyerek varlık envanterini güncellemem gerekiyordu. Bunu sadece haftada bir kez yapıyorduk ama her seferinde yaklaşık 30 dakika sürüyordu.
Hem bulut altyapısı sağlayıcılarının hem de tarayıcının bir API’si vardı, bu nedenle her iki sistemde de kimlik doğrulaması yapabilen ve ilgili bilgileri derleyebilen otomasyon oluşturmak nispeten basitti. Bu bir otomasyon zaferiydi.
Güvenlik açığı tarayıcı raporları üretildikten sonra, bulguları gözden geçirmemiz ve bunlara göre hareket etmemiz gerekiyordu; bu, birkaç saat süren başka bir haftalık görevdi. Raporlar XML’de sağlandığı için, bunların makine tarafından ayrıştırılması, tekilleştirilmesi ve e-posta yoluyla özetlenmesi ve yeni sayıların bilet olarak kaydedilmesi yeterince basitti. Bu daha da büyük bir otomasyon kazancıydı.
Nereden Başlamalı?
Bilgi güvenliğindeki her şeyde olduğu gibi, güvenlik otomasyonuna başlamak önceliklendirmeye indirgenir. Muhtemelen her şeyi aynı anda halledemezsiniz, bu yüzden olasılıklar listesini belirleyin; hem risk hem de potansiyel çaba tasarrufu açısından ne kadar önemli olduklarına göre sıralayın; ve listede ilerlemeye başlayın.
Otomasyon konusunda tamamen yeniyseniz, daha küçük, daha kolay kazançlarla başlayın ve oradan ilerleyin.
Örneğin, istediğinizden daha sık karşılaştığınız bir güvenlik operasyonları senaryosunu ele alalım: açık S3 klasörleri. AWS’nin bunlara karşı uyarmak için elinden gelenin en iyisini yapmasına rağmen, açık S3 klasörleri her zaman oluyor gibi görünüyor. Yüksek sıklıkta gerçekleşen standart bir süreç olduğu için bu, otomasyon için iyi bir aday olabilir. AWS komut satırı arabirimiyle bunu gerçekleştirmenin bir yolu aşağıdadır.
AWS CLI komutu aws s3api liste grupları mevcut tüm S3 gruplarını listeler. Bu listeden her bir grup adını alın ve komutu kullanın. aws s3api get-bucket-policy –bucket YOUR_BUCKET_HERE paketin izinlerini almak için.
Bu, kovaya uygulanan IAM politikasının çıktısını verir. İzin veren politikaları arayarak IAM politikasını ayrıştırın Tüm kullanıcılar (İnternetteki herkes), Kimliği Doğrulanmış Kullanıcılar (bir AWS hesabı olan herkes, hatta kuruluşunuzdaki kişiler dahil) veya * müdür. Bu şekilde, tüm açık kovaların bir listesini oluştururuz.
aynısını kullanabilirsin aws s3api get-bucket-policy komutu ile –politika Bu boşlukları kapatabilmeniz için bu izinlere sahip olmayan yeni bir ilke dosyası yüklemek için parametre. Bu görevleri komut satırında gerçekleştirmeye yeterince aşina olduğunuzda, tekrarlanabilir adımları bir Python veya kabuk betiğine yazmaya başlayabilirsiniz. Sonunda siz uyurken veya başka işler yaparken tüm süreci otomatik olarak başlatabilir ve çalıştırabilirsiniz.
Otomatikleştirme Zorluklar Sunabilir
Otomasyonunuzun üretim ortamınızın prime time taleplerine hazır olmayacağından endişeleniyorsanız, geliştirme ve hazırlama ortamlarında ve hatta satış mühendisliği ve veri bilimi ortamlarında görevleri otomatikleştirerek başlayın.
Son olarak, üretimde otomatikleştirmek istiyor ancak iş üzerindeki etkileriyle ilgili endişeleriniz varsa, bir CI/CD sisteminden veya AWS’nin EventBridge’inden alınan son değişikliklere yanıt olarak otomatikleştirmeye odaklanın. Yeni dağıtılan bir sistem için yaşam döngüsünün ilk dakikasında (sistemi yeni dağıtan ekipler tarafından yakından izleniyorken) bir istisnaya ihtiyacınız olduğunu bulmak, bir hafta önce çalıştıktan sonra bozulduğu için onu bulmaktan çok daha lezzetlidir. dokuz ay ve şimdi müşteriler şikayet ediyor.
Bu otomasyonu oluşturmak ve sürdürmekle ilgili maliyetler vardır. Bu maliyetler, sizin için mevcut araçlara ve ekibinizin becerilerine bağlı olarak değişir. Bazı ekipler Python/Ruby/Perl/Bash’te her şeyi özel komut dosyası olarak yazmayı ve bunu CI/CD işlem hattınızdaki cron işleri ve modüller aracılığıyla düzenlemeyi tercih eder. Diğer ekipler, bakım maliyetlerinin bir kısmını bir iyileştirme satıcısına kaydırmayı tercih edebilir – doğrudan katılımlarını bir SIEM/SOAR ile arayüz oluşturan araçları yapılandırmakla sınırlandırır ve bunu başka bir araca yerleşik düşük kodlu/kodsuz düzeltme iş akışlarını başlatmak için kullanır.
Harici bir satıcı kullanma seçeneği, çözümünüzün devam eden bakım maliyetlerini düşürmenin iyi bir yolu olabilir. Bu, özellikle değişiklikleri araçlarınızı bozabilecek API’ler ve hizmetlerle olan etkileşimler için geçerlidir.
Otomasyonun Kümülatif Etkisi
Her bir bireysel görev çok önemli görünmeyebilir. Bununla birlikte, tüm bir organizasyonun tamamı için tüm bir ekibin değerindeki görevler üzerinden, tasarruflar artmaya başlar ve maliyet çok daha olumlu bir şekilde ölçeklenmeye başlar.
Otomasyon asla bir güvenlik ekibinin yerini alamaz — bazı görevler insan etkileşimi ve insan kararları gerektirir. Bununla birlikte, işletmeler büyümeye devam ettikçe ve güvenlik bütçeleri daha da sıkılaştıkça, bu insanların daha fazlasını yapmasına, daha etkili ve daha üretken olmasına yardımcı olabilir.