Veri öncelikli güvenlik çağrısı

Son yirmi yılda, güvenliğin giderek daha ayrıntılı hale geldiğini, donanımdan ağa, sunucuya, kapsayıcıya ve şimdi de giderek daha fazla koda kadar nesilden nesile yığın üretimine daha derine indiğini gördük.

Verilere odaklanılmalıdır. Birinci.

Güvenlikte bir sonraki sınır veriler, özellikle de hassas verilerdir. Hassas veriler, kuruluşların sızdırıldığını veya ihlal edildiğini görmek istemedikleri verilerdir. Buna PHI, PII, PD ve finansal veriler dahildir. Hassas verilerin ihlali gerçek cezalar getirir. GDPR cezaları (10 milyon avro veya yıllık gelirin %2’si), FTC cezaları (örn. karşı 150 milyon dolar twitter) ve yasal ücretler. Ardından, müşteri güveninin kaybı gibi maddi olmayan maliyetler vardır (örn. Chegg maruz veri 40 milyon kullanıcıya ait), yeniden yapılandırma ağrısı ve daha kötüsü.

>>Özel sayımızı kaçırmayın: CIO gündemi: BT liderleri için 2023 yol haritası.<<

Günümüzün veri koruma teknolojileri, cıvata bağlantılı yaklaşımları fazlasıyla benimsiyor. Sadece kimlik yönetimine bakın. Kimin kim olduğunu doğrulamak için tasarlandı. Gerçekte, bu yaklaşımlar kaçınılmaz başarısızlık noktaları içerir. Kimlik yönetimi tarafından yetkilendirildikten sonra, kullanıcılar önemli verilere minimum kısıtlamalarla erişmek için tam yetkiye sahip olur.

Verileri güvenlik evreninin merkezi yapsaydınız ne olurdu?

Kuruluşların korumak istediği en değerli varlıklardan biri verilerdir ve büyük veri ihlalleri ve veri sızıntıları çok sık meydana gelir. Siber güvenliğin yeni bir evriminin zamanı geldi: önce veri güvenliği.

Veriler farklı

Öncelikle, verilerin boşlukta var olmadığını kabul edelim. GDPR’yi anlamakta ve bunlara uymakta zorlandıysanız, verilerin birçok sisteme sıkı sıkıya bağlı olduğunu bilirsiniz. Veriler sistemler tarafından ve sistemler arasında işlenir, saklanır, kopyalanır, değiştirilir ve aktarılır. Her adımda güvenlik açığı potansiyeli artar. Bunun nedeni, veriler olduğu için değil, bu adımlarla ilişkili sistemlerin savunmasız olmasıdır.

Temel kavram basittir. Taşıdıkları veriler ve aralarındaki bağlantılar hakkında herhangi bir bilgi sahibi olmadan her sisteme ayrı ayrı odaklanmayı bırakın. Bunun yerine, verilerle başlayın, ardından iş parçacığını çekin. Hassas veriler geveze günlükçülere dahil mi? Veriler yetkisiz üçüncü kişilerle paylaşılıyor mu? S3 klasörlerinde depolanan verilerde güvenlik denetimleri eksik mi? Verilerde şifreleme eksik mi? Potansiyel güvenlik açıklarının listesi uzundur.

Veri güvenliğiyle ilgili zorluk, verilerin özellikle bulut tabanlı bir altyapıda sistemler arasında neredeyse sonsuz şekilde akmasıdır. İdeal bir dünyada, her sistemdeki verileri ve bunlarla ilişkili riskleri ve güvenlik açıklarını herhangi bir zamanda takip edebilmemiz gerekir. Gerçekte, biz bundan çok uzaktayız.

Önce veri güvenliği kodda başlamalıdır. Bu, geliştiriciler için şu anlama gelir: Sola kaydırın. Buna göre GitLab, Güvenlik ekiplerinin %57’si güvenliği çoktan bıraktı veya bu yıl için plan yapıyor. Kod yazarken verilerinizin güvenliğini sağlamaya yolculuğun en başından başlayın.

Ancak sola kaydırmanın kirli sırrı, çoğu zaman kuruluşların mühendislik ekibine daha fazla iş yüklemesi anlamına gelmesidir. Örneğin, küresel ekonomiler, yerel pazarlar ve yüksek düzeyde düzenlenmiş dikey endüstriler genelinde veri yönetişimi gereklilikleri konusunda uzmanlığa sahip olduklarını varsayan anketler ve soru formları doldurmalarını sağlayabilirler. Geliştiricilerin yaptığı bu değil.

Bu nedenle, önce veri güvenlik yaklaşımı üç bileşen içermelidir: 1) Başka bir güvenlik yükümlülüğü olamaz; 2) Sahiplik bağlamını anlamalıdır; 3) Özel iş mantığındaki hatalara karşı koruma sağlar (her ihlal bir hata içermez).

Başka bir güvenlik yükümlülüğü değil

Güvenlik, riski azaltmakla ilgilidir. Yeni bir araç veya satıcı eklemek bu temel ilkeye aykırıdır. Hepimizin aklında SolarWinds var, ancak diğerleri her gün ortaya çıkıyor. Üretim ortamınızla bütünleşen yeni bir araca sahip olmak, yalnızca güvenlik ekibi için değil, SRE/Ops ekibi için de büyük bir sorudur. Üretim altyapısında veri keşfi gerçekleştirmek, gerçek değerlere, potansiyel müşteri verilerine – esasen ilk etapta korumaya çalıştığımız şeylere – bakmak anlamına gelir. Belki de başka bir risk haline gelmemenin en iyi yolu hassas altyapılara ve verilere erişmemektir.

Önce veri güvenlik yaklaşımı, hassas veri bilgisine dayandığından, bu keşfi yalnızca kod tabanından gerçekleştirebilmek şaşırtıcı olabilir – özellikle de DLP ve veri güvenliği duruş yönetimi (DSPM) çözümlerine alışkın olduğumuzda, keşif gerçekleştiren üretim verileri. Kod tabanında gerçek verilere (değerlere) erişimimiz olmadığı, yalnızca meta verilere erişimimiz olduğu doğrudur. Ancak ilginç bir şekilde, hassas verileri bu şekilde keşfetmek de çok doğru. Aslında, değerlere erişim eksikliği, sınıflandırma için anahtar olan çok sayıda bağlama erişimle dengelenir.

Geleneksel sola kayma güvenliği ne kadar değerli olsa da, önce veri güvenlik yaklaşımı, kuruluş için başka bir risk oluşturmama söz konusu olduğunda daha da fazla değer sağlar.

Sahiplik bağlamı

Veri güvenliği ve veri koruması söz konusu olduğunda, her şey siyah veya beyaz değildir. Bazı risklerin ve güvenlik açıklarının tespit edilmesi son derece kolaydır. Örnekler arasında PHI sızdıran bir kaydedici veya PD’yi açığa çıkaran bir SQL enjeksiyonu yer alır, ancak diğerleri riski değerlendirmek ve nihayetinde en iyi düzeltmeye karar vermek için belirli bir düzeyde tartışma gerektirir. Şimdi, veri güvenliğinden bahsederken asla çok uzak olmayan uyum sınır bölgesine giriyoruz.

Bu verileri neden saklıyoruz? Bu verileri bu üçüncü tarafla paylaşmanın iş nedeni nedir? Bunlar kuruluşların belli bir noktada cevaplaması gereken sorulardır. Bugün bu sorular, özellikle bulut yerel ortamlarda, güvenlik ekipleri tarafından giderek daha fazla ele alınmaktadır. “Sahipliği” ortaya çıkarmadan bunları yanıtlamak ve ilgili riskleri belirlemek neredeyse imkansızdır.

Kodun bakış açısından önce veri güvenliğini sağlayarak, çok büyük bağlamsal bilgilere doğrudan erişimimiz var – özellikle, Ne zaman bir şey tanıtıldı ve tarafından kime. DSPM çözümleri, yalnızca üretim veri depolarına bakarak bu bağlamı sağlayamaz.

Kuruluşlar sıklıkla “manuel değerlendirmeye” güvenir. Hangi hassas verilerin, neden ve nasıl işlendiğini anlamak için tüm mühendislik ekibine anketler gönderirler. Geliştiriciler bu anketlerden nefret ederler ve çoğu zaman soruların çoğunu anlamazlar. Zayıf veri güvenliği sonuçları tahmin edilebilir.

Çoğu “teknik” şeyde olduğu gibi, en etkili yaklaşım, özellikle geniş ölçekte veri güvenliği konusunda ciddiyseniz, sıkıcı görevleri mevcut iş akışlarına en az veya hiç sürtünme olmadan düşen bir süreçle otomatik hale getirmektir.

Özel iş mantığı

Her kuruluş farklı olduğu için kodlama uygulamaları ve ilişkili politikalar, özellikle daha büyük mühendislik ekipleri için farklılık gösterir. Uygulama düzeyinde şifreleme, uçtan uca şifreleme yapan veya veri ambarlarına çok özel yollarla bağlanan birçok şirket gördük. Bu mantık akışlarının çoğunun kodun dışında tespit edilmesi son derece zordur, bu da izleme eksikliğine ve güvenlik açıklarının ortaya çıkmasına neden olur.

Airbnb’yi örnek olarak alalım. BT herkesin bildiği gibi kendi veri koruma platformunu oluşturdu. Burada ilginç olan, şirketin hassas verilerini şifrelemek için uyguladığı özel mantıktır. Airbnb, üçüncü taraf bir şifreleme hizmetine veya kitaplığına (düzinelerce var) güvenmek yerine kendi şifre. Bu, geliştiricilerin hassas verileri anında şifrelemesine ve şifresini çözmesine olanak tanıyan farklı dillerde kitaplıklar sağlar. Kod tabanı dışındaki bazı hassas verilerde bu şifreleme mantığının veya daha da önemlisi eksikliğinin tespit edilmesi çok zor olacaktır.

Ancak kod yeterli mi?

Koddan önce veri odaklı bir güvenlik yolculuğuna başlamak, özellikle orada bulunan pek çok içgörüye başka hiçbir yerden erişilemediği için (bazı bilgilerin eksik olabileceği ve yalnızca altyapı veya üretim düzeyinde bulunabileceği doğru olsa da) çok anlamlıdır.

Kod ve üretim arasındaki bilgileri uzlaştırmak, özellikle her yerde akan veri varlıkları varken son derece zordur. Airbnb ne kadar karmaşık olabileceğini gösteriyor. İyi haber şu ki, kod olarak altyapıya (IaC) geçişle, bağlantıları kod düzeyinde kurabiliyor ve sancılı uzlaşmayla uğraşmaktan kurtulabiliyoruz.

Güvenlik ve verilerle ilgili zorluklar göz önüne alındığında, her güvenlik çözümünün en azından “verilere duyarlı” ve muhtemelen içinde bulundukları yığının hangi katmanında “veri öncelikli” olması gerekecektir. Bulut güvenlik duruşu yönetimini (CSPM) şimdiden görebiliriz. ) DSPM ile harmanlanan çözümler, ancak yeterli olacak mı?

Guillaume Montard, Bearer’ın kurucu ortağı ve CEO’sudur.