Mobil Uygulama Güvenlik Gereksinim Standartları

#

Referans

Açıklama

L1 (Standart Güvenlik)

L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik)

1.1

MSTG-ARCH-1

Tüm uygulama bileşenleri tanımlanmalı ve bileşenlerin gerekli olup olmadığı, gerekli ise ne için gerekli olduğu bilinmelidir.

☒

☒

1.2

MSTG-ARCH-2

Güvenlik denetimleri yalnızca istemci tarafında değil, ilgili uzak uç noktalarda da uygulanmalıdır.

☒

☒

1.3

MSTG-ARCH-3

Mobil uygulama ve tüm bağlı uzak hizmetler için yüksek seviyeli bir mimari tanımlanmalı ve bu mimaride güvenlik ele alınmalıdır.

☒

☒

1.4

MSTG-ARCH-4

Mobil uygulama bağlamında hassas olduğu düşünülen veriler belirlenmelidir.

☒

☒

1.5

MSTG-ARCH-5

Tüm uygulama bileşenleri, sağladıkları iş işlevleri ve / veya güvenlik işlevleri açısından tanımlanır.

☐

☒

1.6

MSTG-ARCH-6

Mobil uygulama ve ilişkili uzak servisler için potansiyel tehditleri ve karşı önlemleri tanımlayan bir tehdit modeli oluşturulmalıdır.

☐

☒

1.7

MSTG-ARCH-7

Tüm güvenlik kontrolleri merkezi bir entegrasyon içermelidir.

☐

☒

1.8

MSTG-ARCH-8

Kriptografik anahtarların (varsa) nasıl yönetildiğine ve şifreleme anahtarlarının yaşam döngüsünün nasıl uygulandığına dair açık bir politika belirlenmelidir. İdeal olarak NIST SP 800-57 anahtar yönetim standardı kullanılabilir.

☐

☒

1.9

MSTG-ARCH-9

Mobil uygulamanın güncellemelerini zorunlu kılmak için bir mekanizma kullanılmalıdır.

☐

☒

1.10

MSTG-ARCH-10

Güvenlik, yazılım geliştirme yaşam döngüsünün tüm bölümlerinde ele alınmalıdır.

☐

☒

1.11

MSTG-ARCH-11

İfşa politikası olmalı ve etkin bir şekilde uygulanmalıdır.

☐

☒

1.12

MSTG-ARCH-12

Uygulama, gizlilik yasalarına ve regülasyonlara uyum sağlamalıdır.

☒

☒

#

Referans

Açıklama

L1 (Standart Güvenlik)

L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik)

2.1

MSTG-STORAGE-1

PII (Personally Identifiable Information), kullanıcı kimlik bilgileri veya kriptografik anahtarlar gibi hassas verileri depolamak için sistem kimlik depolama olanakları kullanılmalıdır.

☒

☒

2.2

MSTG-STORAGE-2

Hassas veriler, uygulama alanı veya sistem kimlik depolama alanları dışındaki alanlarda saklanmamalıdır.

☒

☒

2.3

MSTG-STORAGE-3

Uygulama günlüklerine hassas veriler yazılmamalıdır.

☒

☒

2.4

MSTG-STORAGE-4

Mimarinin gerekli bir parçası olmadığı sürece hiçbir hassas veri üçüncü taraflarla paylaşılmamalıdır.

☒

☒

2.5

MSTG-STORAGE-5

Hassas verileri işleyen metin girişlerinde klavye önbellek özelliği devre dışı bırakılmalıdır.

☒

☒

2.6

MSTG-STORAGE-6

IPC (Inter Process Communication) mekanizmaları aracılığıyla hiçbir hassas veri açığa çıkarılmamalıdır.

☒

☒

2.7

MSTG-STORAGE-7

Parola veya pin gibi hassas veriler, kullanıcı arabirimi aracılığıyla açığa çıkarılmamalıdır.

☒

☒

2.8

MSTG-STORAGE-8

Mobil işletim sistemi tarafından oluşturulan yedeklemelere hiçbir hassas veri dahil edilmemelidir.

☐

☒

2.9

MSTG-STORAGE-9

Uygulama, arka plana taşındığında hassas verileri görünümlerden kaldırmalıdır.

☐

☒

2.10

MSTG-STORAGE-10

Uygulama hassas verileri hafızada gerekenden daha uzun süre tutmamalı ve kullanımdan sonra hafıza temizlenmelidir.

☐

☒

2.11

MSTG-STORAGE-11

Uygulama, kullanıcının bir cihaz şifresi ayarlamasını zorunlu kılmak gibi minimum bir cihaz erişimi güvenliği politikası uygulamalıdır.

☐

☒

2.12

MSTG-STORAGE-12

Uygulama, kullanıcıyı işlenen kişisel olarak tanımlanabilir bilgi türlerinin yanı sıra kullanıcının uygulamayı kullanırken izlemesi gereken en iyi güvenlik uygulamaları konusunda eğitmelidir.

☐

☒

2.13

MSTG-STORAGE-13

Mobil cihazda yerel olarak hiçbir hassas veri depolanmamalıdır. Bunun yerine, veriler gerektiğinde uzak bir uç noktadan alınmalı ve yalnızca bellekte tutulmalıdır.

☐

☒

2.14

MSTG-STORAGE-14

Hassas verilerin yine de yerel olarak depolanması gerekiyorsa, kimlik doğrulaması gerektiren donanım destekli depolamadan türetilen bir anahtar kullanılarak şifrelenmelidir.

☐

☒

2.15

MSTG-STORAGE-15

Çok sayıda başarısız kimlik doğrulama girişiminden sonra uygulamanın yerel depolama alanı silinmelidir.

☐

☒

#

Referans

Açıklama

L1 (Standart Güvenlik)

L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik)

3.1

MSTG-CRYPTO-1

Uygulama, tek şifreleme yöntemi olarak sabit kodlanmış anahtarlarla simetrik kriptografiye güvenmemelidir.

☒

☒

3.2

MSTG-CRYPTO-2

Uygulama, kriptografik temellerin kanıtlanmış uygulamalarını kullanılmalıdır.

☒

☒

3.3

MSTG-CRYPTO-3

Uygulama, endüstri standartlarına uyan parametrelerle yapılandırılmalı, belirli bir kullanım senaryosu için uygun olan şifreleme ilkelerini kullanmalıdır.

☒

☒

3.4

MSTG-CRYPTO-4

Uygulama, güvenlik nedeniyle yaygın olarak kullanımdan kaldırılan kriptografik protokolleri veya algoritmaları kullanmamalıdır.

☒

☒

3.5

MSTG-CRYPTO-5

Uygulama, aynı şifreleme anahtarını birden çok amaç için yeniden kullanmamalıdır.

☒

☒

3.6

MSTG-CRYPTO-6

Tüm rasgele değerler, yeterince güvenli bir rasgele sayı üreteci kullanılarak üretilmelidir.

☒

☒

#

Referans

Açıklama

L1 (Standart Güvenlik)

L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik)

4.1

MSTG-AUTH-1

Uygulama, kullanıcıların uzak bir hizmete erişmesini sağlıyorsa, uzak uç noktada kullanıcı adı / parola kimlik doğrulaması gibi bir tür kimlik doğrulama işlemi gerçekleştirilmelidir.

☒

☒

4.2

MSTG-AUTH-2

Stateful (Durumsal) oturum yönetimi kullanılıyorsa, uzak uç nokta, kullanıcının kimlik bilgilerini göndermeden istemci isteklerinin kimliğini doğrulamak için rastgele oluşturulmuş oturum tanımlayıcılarını kullanılmalıdır.

☒

☒

4.3

MSTG-AUTH-3

Stateless (Durumsuz) token tabanlı kimlik doğrulama kullanılırsa, sunucu, güvenli bir algoritma kullanılarak imzalanmış bir token sağlamalıdır.

☒

☒

4.4

MSTG-AUTH-4

Uzak uç nokta, kullanıcı oturumu kapattığında mevcut oturumu sonlandırmalıdır.

☒

☒

4.5

MSTG-AUTH-5

Uzak uç noktada bir parola politikası olmalı ve bu politikaya uygun parolalar oluşturulması sağlanmalıdır.

☒

☒

4.6

MSTG-AUTH-6

Uzak uç nokta, kimlik bilgilerinin aşırı sayıda gönderilmesine (kaba kuvvet saldırıları) karşı koruma sağlamak için bir mekanizma uygulamalıdır.

☒

☒

4.7

MSTG-AUTH-7

Önceden tanımlanmış bir hareketsizlik durumu (inaktivite) ve erişim tokenlarının süresi dolduktan sonra uzak uç noktadaki oturumlar geçerliliğini yitirmelidir.

☒

☒

4.8

MSTG-AUTH-8

Eğer biyometrik kimlik doğrulama varsa, olaya bağlı olmamalıdır (yani, yalnızca "true" veya "false" döndüren bir API). Bunun yerine, anahtar zinciri / anahtar deposunun kilidini açmaya dayanmalıdır.

☐

☒

4.9

MSTG-AUTH-9

Uzak uç noktada ikinci bir kimlik doğrulama faktörü olmalı ve 2FA gereksinimi sürekli olarak uygulanmalıdır.

☐

☒

4.10

MSTG-AUTH-10

Hassas işlemler, adım adım kimlik doğrulaması gerektirmelidir.

☐

☒

4.11

MSTG-AUTH-11

Uygulama, kullanıcıyı hesabıyla ilgili tüm hassas etkinlikler konusunda bilgilendirmelidir. Kullanıcılar, cihazların bir listesini ve bağlamsal bilgileri (IP adresi, konum, vb.) görüntüleyebilmeli ve belirli cihazları engelleyebilmelidir.

☐

☒

4.12

MSTG-AUTH-12

Yetkilendirme modelleri uzak uç noktada tanımlanmalı ve uygulanmalıdır.

☒

☒

#

Referans

Açıklama

L1 (Standart Güvenlik)

L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik)

5.1

MSTG-NETWORK-1

Veriler ağda TLS kullanılarak şifrelenmelidir. Güvenli kanal, uygulama genelinde tutarlı bir şekilde uygulanmalıdır.

☒

☒

5.2

MSTG-NETWORK-2

TLS ayarları, mevcut en iyi uygulamalarla uyumlu olmalıdır veya mobil işletim sistemi önerilen standartları desteklemiyorsa mümkün olduğunca en iyi standartlara yakın olmalıdır.

☒

☒

5.3

MSTG-NETWORK-3

Uygulama, güvenli kanal kurulduğunda uzak uç noktanın X.509 sertifikasını doğrulamalıdır. Yalnızca güvenilir bir CA tarafından imzalanan sertifikalar kabul edilmelidir.

☒

☒

5.4

MSTG-NETWORK-4

Uygulama, kendi sertifika deposunu kullanmalı, uç nokta sertifikasını veya public key bilgisini sabitlemelidir ve güvenilir bir CA tarafından imzalanmış olsa bile farklı bir sertifika veya anahtar sunan uç noktalarla bağlantı kurulmamalıdır. (SSL Pinning)

☐

☒

5.5

MSTG-NETWORK-5

Uygulama, kayıtlar ve hesap kurtarma gibi kritik işlemler için tek bir güvenli olmayan iletişim kanalına (e-posta veya SMS) güvenmemelidir.

☐

☒

5.6

MSTG-NETWORK-6

Uygulama yalnızca güncel bağlantı ve güvenlik kütüphanelerine bağlı olmalıdır.

☐

☒

#

Referans

Açıklama

L1 (Standart Güvenlik)

L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik)

6.1

MSTG-PLATFORM-1

Uygulama yalnızca gerekli olan, minimum izinlere erişim istemelidir.

☒

☒

6.2

MSTG-PLATFORM-2

Harici kaynaklardan ve kullanıcıdan gelen tüm girdiler doğrulanmalı ve gerekirse sterilize edilmelidir. Bu, kullanıcı arayüzü, intentler gibi IPC mekanizmaları, özel URL'ler ve ağ kaynakları aracılığıyla alınan verileri de içermelidir.

☒

☒

6.3

MSTG-PLATFORM-3

Uygulama, güvenlik mekanizmaları düzgün bir şekilde korunmadığı sürece özel URL şemaları aracılığıyla hassas fonksiyonları dışa aktarmamalıdır.

☒

☒

6.4

MSTG-PLATFORM-4

Uygulama, güvenlik mekanizmaları uygun şekilde korunmadığı sürece IPC aracılığıyla hassas fonksiyonları dışa aktarmamalıdır.

☒

☒

6.5

MSTG-PLATFORM-5

Eğer özel ihtiyaç yoksa, WebView yapılarında JavaScript desteği devre dışı bırakılmalıdır.

☒

☒

6.6

MSTG-PLATFORM-6

WebView yapıları, yalnızca gereken minimum protokol işleyici kümesine izin verecek şekilde yapılandırılmalıdır (ideal olarak, yalnızca https desteklenir). Dosya, telefon ve uygulama kimliği gibi potansiyel olarak tehlikeli işleyiciler devre dışı bırakılmalıdır.

☒

☒

6.7

MSTG-PLATFORM-7

Uygulamanın native metodları bir WebView yapısına maruz kalırsa, WebView yalnızca uygulama paketinde bulunan JavaScript'i çalıştırmalıdır.

☒

☒

6.8

MSTG-PLATFORM-8

Object desrialization işlemi varsa güvenli serialization API'leri kullanılmalıdır.

☒

☒

6.9

MSTG-PLATFORM-9

Uygulama, screen overlay saldırılarına karşı kendini korumalıdır. (Yalnızca Android)

☐

☒

6.10

MSTG-PLATFORM-10

WebView yok edilmeden önce WebView önbelleği, deposu ve yüklenen kaynakları (JavaScript, vb.) temizlenmelidir.

☐

☒

6.11

MSTG-PLATFORM-11

Hassas veri girişi sırasında uygulama özel üçüncü taraf klavyelerin kullanımını engellemelidir (yalnızca iOS).

☐

☒

#

Referans

Açıklama

L1 (Standart Güvenlik)

L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik)

7.1

MSTG-CODE-1

Uygulama özel anahtarı uygun şekilde korunan geçerli bir sertifika ile imzalanmalıdır.

☒

☒

7.2

MSTG-CODE-2

Uygulama, yayına uygun ayarlarla hazırlanmalıdır (örneğin, hata ayıklama modu kapalı).

☒

☒

7.3

MSTG-CODE-3

Native binary dosyalardan hata ayıklama sembolleri kaldırılmalıdır.

☒

☒

7.4

MSTG-CODE-4

Hata ayıklama kodu ve geliştirici yardım kodu (ör. Test kodu, arka kapılar, gizli ayarlar) kaldırılmalıdır. Uygulama ayrıntılı hataları veya hata ayıklama mesajlarını uygulama günlüğüne kaydetmemelidir.

☒

☒

7.5

MSTG-CODE-5

Kütüphaneler ve frameworkler gibi mobil uygulama tarafından kullanılan tüm üçüncü taraf bileşenleri tanımlanmalıdır ve bilinen güvenlik açıkları açısından kontrol edilmelidir.

☒

☒

7.6

MSTG-CODE-6

Uygulama olası istisnaları yakalamalı ve ele almalıdır.

☒

☒

7.7

MSTG-CODE-7

Güvenlik kontrollerindeki hata işleme mantığı, varsayılan olarak erişimi reddetmelidir.

☒

☒

7.8

MSTG-CODE-8

Yönetilmeyen kodda, bellek ayrılmalı, serbest bırakılmalı ve güvenli bir şekilde kullanılmalıdır.

☒

☒

7.9

MSTG-CODE-9

Araç zincirinin sunduğu bayt kodu küçültme, yığın koruma, PIE (Position-independent executable) desteği ve otomatik referans sayma gibi ücretsiz güvenlik özellikleri etkinleştirilmelidir.

☒

☒

#

Referans

Açıklama

MASVS-R - Dayanıklılık (Resilience)

8.1

MSTG-RESILIENCE-1

Uygulama, kullanıcıyı uyararak veya uygulamayı sonlandırarak root'lu veya jailbreak'li bir cihazın varlığını algılamalı ve duruma uygun bir şekilde yanıt vermelidir.

☒

8.2

MSTG-RESILIENCE-2

Uygulama, hata ayıklamayı engellemeli ve / veya bir hata ayıklayıcının bağlanmasını algılamalı ve duruma uygun bir şekilde yanıt vermelidir. Mevcut tüm hata ayıklama protokolleri kapsanmalıdır.

☒

8.3

MSTG-RESILIENCE-3

Uygulama, kendi sanal alanındaki yürütülebilir dosyaları ve kritik verileri değişiklik ve müdahaleleri algılamalı ve bunlara yanıt vermelidir.

☒

8.4

MSTG-RESILIENCE-4

Uygulama, cihazda yaygın olarak kullanılan tersine mühendislik araçlarının ve çerçevelerinin varlığını algılamalı ve bunlara yanıt vermelidir.

☒

8.5

MSTG-RESILIENCE-5

Uygulama, bir emülatörde çalışma durumunu algılamalı ve yanıt vermelidir.

☒

8.6

MSTG-RESILIENCE-6

Uygulama, kendi hafıza alanındaki kod ve verilerde değişiklik ve müdahaleleri algılamalı ve bunlara yanıt vermelidir.

☒

8.7

MSTG-RESILIENCE-7

Uygulama, her savunma kategorisinde (8.1 - 8.6) birden fazla mekanizma uygulamalıdır. Dayanıklılığın, kullanılan mekanizmaların orijinalliğinin miktarı ve çeşitliliği ile ölçeklendiği unutulmamalıdır.

☒

8.8

MSTG-RESILIENCE-8

Algılama mekanizmaları, gecikmeli ve gizli yanıtlar dahil olmak üzere farklı türlerdeki yanıtları tetiklemelidir.

☒

8.9

MSTG-RESILIENCE-9

Obfuscation (Gizleme), programatik savunmalara uygulanmalıdır ve bu da dinamik analiz yoluyla kod üzerinde tersine mühendisliği zorlaştırır.

☒

#

Referans

Açıklama

MASVS-R - Dayanıklılık (Resilience)

8.10

MSTG-RESILIENCE-10

Uygulama, cihaza özgü birçok özellikten türetilen bir cihaz parmak izini (fingerprint) kullanarak bir "cihaz bağlama" işlevselliği uygulamalıdır.

☒

#

Referans

Açıklama

MASVS-R - Dayanıklılık (Resilience)

8.11

MSTG-RESILIENCE-11

Uygulamaya ait tüm yürütülebilir dosyalar ve kütüphaneler ya dosya düzeyinde şifrelenmeli ve / veya yürütülebilir dosyalar içindeki önemli kod ve veri bölümleri şifrelenmeli veya paketlenmelidir. Statik analiz, önemli kodu veya verileri ortaya çıkarmamalıdır.

☒

8.12

MSTG-RESILIENCE-12

Obfuscation işleminin amacı hassas hesaplamaları korumaksa, halihazırda yayınlanan araştırmalar dikkate alınarak hem belirli görev için uygun hem de manuel ve otomatik gizleme çözme yöntemlerine karşı sağlam olan bir gizleme şeması kullanılmalıdır. Obfuscation planının etkinliği manuel testlerle doğrulanmalıdır. Mümkün olduğunda, donanım tabanlı izolasyon özelliklerinin obfuscation işlemine göre daha çok tercih edildiğini unutmayın.

☒

#

Referans

Açıklama

MASVS-R - Dayanıklılık (Resilience)

8.13

MSTG-RESILIENCE-13

Derinlemesine bir savunma olarak, iletişim kuran tarafların sağlam bir şekilde güçlendirilmesinin yanı sıra, gizli dinlemeyi daha da engellemek için uygulama düzeyinde yük şifrelemesi uygulanmalıdır.

☒