TSA Uçuşa Yasak Listesi Snafu, Geliştirme Ortamlarında Hassas Verileri Tutma Riskini Vurguluyor



Canı sıkılan bir hacker’ın TSA’nın uçuş yasağı listesindeki 1,5 milyon kişinin İnternet’e açık bir sunucuda korumasız bir şekilde oturduğu bir liste bulduğu yakın tarihli bir olay, üretim verilerini ve hassas bilgileri geliştirme ortamlarında kullanmanın riskli uygulamasını bir kez daha vurguladı.

İsviçreli bilgisayar korsanı “maia kundakçılık suç” yakın zamanda, bölgesel uçuşlarda United Airlines operasyonlarını destekleyen Ohio merkezli bir havayolu şirketi olan CommuteAir’e ait bir Jenkins açık kaynaklı otomasyon sunucusunda TSA listesini keşfetti. Olayı ilk bildiren Daily Dot’a yaptığı yorumlarda, Shodan arama motorunu kullanarak İnternet’e açık Jenkins sunucularını ararken uçuşa yasak listeyi bulduğunu ve sorunu şirkete bildirdiğini söyledi.

Açıkça Erişilebilir

“NoFly.csv” adlı bir metin dosyasında yer alan liste, ABD hükümetinin güvenlik endişeleri nedeniyle uçmasını yasakladığı 1,5 milyondan fazla kişinin adını içeriyordu. TSA, listeyi dünyanın dört bir yanındaki havayollarının kullanımına sunar, böylece ABD’den, ABD’ye veya üzerinden uçmayı planlayan yolcuları tarayabilirler.

Daily Dot, kendisini “güvenlik araştırmacısı” olarak tanımlayan maia kundakçılık suçunun aynı sunucuda CommuteAir’e ait yaklaşık 40 Amazon S3 klasörünün kimlik bilgilerini bulduğunu söylediğini aktardı. Bu kimlik bilgilerinden biri onu, yaklaşık 900 CommuteAir çalışanına ait pasaport numaraları, telefon numaraları ve posta adresleri gibi hassas bilgileri içeren bir veri tabanına götürdü.

CommuteAir kurumsal iletişim müdürü Erik Kane, bir medya açıklamasında sızıntının yanlış yapılandırılmış bir geliştirme sunucusundan kaynaklandığını açıkladı.

Kane, “Araştırmacı, federal uçuşa yasak listenin adı, soyadı ve doğum tarihini içeren eski bir 2019 sürümünü içeren dosyalara erişti” dedi. “Ayrıca, araştırmacı, sunucuda bulunan bilgiler aracılığıyla CommuteAir çalışanlarının kişisel olarak tanımlanabilir bilgilerini içeren bir veritabanına erişim keşfetti.”

Kane, ilk araştırmanın başka hiçbir müşteri verisinin açığa çıkmadığını gösterdiğini ve CommuteAir’in, bilgisayar korsanı şirkete sorun hakkında bilgi verdikten sonra etkilenen sunucuyu hemen çevrimdışı duruma getirdiğini ekledi.

Açıklamada, “CommuteAir, Siber Güvenlik ve Altyapı Güvenliği Ajansı’na veri ifşasını bildirdi ve ayrıca çalışanlarını bilgilendirdi.”

Hassas Verileri Test ve Geliştirme için Kullanma

Olay, kuruluşlar üretim verilerinin veya hassas bilgilerin geliştirme ve test ortamlarında (bu durumda bir Jenkins sunucusu) kullanımına izin verdiğinde ters gidebilecek şeylere bir örnektir.

Kalite güvence ekipleri ve geliştiriciler, uygulamaları test ederken, geliştirirken veya hazırlarken genellikle ham üretim verilerini kesip ortamlarına yapıştırırlar çünkü bu, test verilerini kullanmaya kıyasla işleri yapmak için daha ucuz, daha hızlı ve daha geçerli bir yol sunar. Ancak güvenlik uzmanları, geliştirme ve test ortamlarında tipik olarak canlı bir üretim ortamında bulunan güvenlik denetimlerinden yoksun olduklarından, uygulamanın risklerle dolu olduğu konusunda uzun süredir uyarıda bulunuyorlar.

Yaygın sorunlar arasında aşırı izinler, ağ bölümleme eksikliği, zayıf yama yönetimi ve veri gizliliği gereksinimleri konusunda genel bir farkındalık eksikliği yer alır.

Uygulamayla ilgili güvenlik, gizlilik ve uyumluluk sorunlarıyla ilgili endişeler, aslında birçok kuruluşu hassas ve canlı üretim verilerini test veya geliştirme için kullanmadan önce maskeleme, karartma veya şifreleme gibi ek önlemler almaya itmiştir. Birçoğu, yazılımı test ederken veya hazırlarken gerçek şeyin yerine sahte verileri kullanır. Buna rağmen, güvenlik uzmanlarına göre geliştirme ve test ayarlarında ham üretim verilerini ve hassas bilgileri kullanma pratiği oldukça yaygın olmaya devam ediyor.

Netenrich’in baş tehdit avcısı John Bambenek, “Ne yazık ki, üretim verileriyle test yapmak çok yaygın,” diyor. “Oldukça basit, güvenilir ve ölçekli test verileri oluşturmak, özellikle benzersiz veri kümeleriyle uğraşırken genellikle karmaşıktır.” Test ekipleri genellikle testlerinin mümkün olduğunca gerçek dünyayı temsil etmesini ister, bu nedenle üretim verilerini kullanmanın çok doğal bir cazibe olduğunu söylüyor.

Keeper Security’de güvenlik ve mimariden sorumlu başkan yardımcısı Patrick Tiquet, DevOps sunucularının genellikle canlı üretim sunucularından daha az korundukları için saldırganlar için birincil hedef olma eğiliminde olduğunu söylüyor. Veriler ne kadar zararsız görünürse görünsün, kuruluşların üretim verilerini üretim dışı ortamlarda kullanmaktan kaçınmasını savunur.

Tiquet, “Geliştirme sistemlerinde üretim verilerinin kullanılması, bu bilgilerin ifşa edilme riskini artırır, çünkü birçok kuruluşta geliştirme sistemleri, üretim sistemleri kadar korunmayabilir” diyor.

Uygulamaya izin veren kuruluşların, birçok veri gizliliği düzenlemesinin, kapsanan kuruluşların, ortamda nerede bulunabileceklerine veya nasıl kullanıldıklarına bakılmaksızın hassas verileri korumak için belirli kontroller uygulamasını gerektirdiği gerçeğini kabul etmesi gerekir. Tiquet, üretim verilerini bir geliştirme ortamında kullanmanın bu gereksinimleri ihlal edebileceğini söylüyor.

“Hassas verilerin ifşa edilmesi, bir kuruluşu yalnızca verilere bağlı olarak davaya veya devletle ilgili sorunlara açmakla kalmaz, aynı zamanda müşteri güveninin erozyona uğramasına da yol açabilir” diye uyarıyor. “Kuruluşların test ortamlarını korumak için veri maskeleme ve şifreleme gibi atabilecekleri birçok adım olsa da, en önemlisi güvenlik ekiplerinin DevOps sunucularının kurulumuna ve sürekli yönetimine dahil edilmesi olacaktır.”



Source link