Ürün veya sistemin koruma hedefleri (CIA triadı: Confidentiality, Integrity, Availability) net biçimde tanımlanmalıdır. Her hedef için:

• Koruma düzeyi (High/Medium/Low)
• Varlık türü (veri, kimlik bilgisi, iletişim kanalı, donanım)
• Koruma yöntemi (şifreleme, erişim kontrolü, doğrulama)
• Sorumlu taraf belirlenmelidir

Bu hedefler, Security Requirements Specification (SRS) dokümanına dahil edilmeli ve tasarım değişiklikleriyle birlikte güncellenmelidir. Hedeflerin belirlenmesi, ISO 27001 Madde 6 ve IEC 62443-4-1 gerekliliklerini karşılar.

Ürüne yönelik tüm potansiyel saldırı vektörleri belirlenmeli ve tehdit modeli oluşturulmalıdır. Bu model, sistemin fiziksel, ağ, yazılım ve kullanıcı katmanlarını kapsamalıdır.

Örnek analiz araçları ve yaklaşımlar:

• STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
• DREAD risk skorlaması
• Attack Tree veya Data Flow Diagram (DFD) tabanlı analiz

Her tehdit için olasılık, etki ve önleyici kontrol tanımlanmalıdır. Risk değerlendirmesi ISO 27005 ve NIST SP 800-30 metodolojilerine uygun olarak dokümante edilmelidir.

Her ürün grubunda güvenlikten sorumlu bir kişi atanmalıdır: Product Security Owner (PSO) veya Security Champion olarak tanımlanır.

Görevleri:

• Güvenlik gereksinimlerinin sürüm boyunca takibi
• Olay yönetimi (Incident Response) sürecinin yürütülmesi
• Güvenlik test planlarının onaylanması
• Müşteri geri bildirimlerinde zafiyet yönetimi

PSO rolü ürün yaşam döngüsü boyunca aktif olmalı ve tasarım değişiklikleri, firmware güncellemeleri ve PCN süreçlerine dahil edilmelidir. Bu uygulama, IEC 62443-4-1 ve ISO 27034 standardında tanımlanan "security governance" yapısını destekler.

Güvenlik, sonradan eklenen bir özellik değil, tasarımın ayrılmaz bir parçası olmalıdır. Bu nedenle geliştirme süreci Secure-by-Design prensiplerine göre yürütülmelidir:

• Gereksinim tanımlama aşamasında tehdit modelinin göz önüne alınması
• Kaynak kodu seviyesinde güvenlik prensiplerinin uygulanması
• Donanım tasarımında güvenli önyükleme, fiziksel erişim koruması, şifreleme donanımı (TPM, HSM, PUF) kullanımı
• Kod incelemeleri ve güvenlik testlerinin zorunlu hale getirilmesi

Bu yaklaşım, IEC 62443-4-1 Secure Development Lifecycle (SDL) modelinin doğrudan gereğidir.

Ürün piyasaya sürülmeden önce güvenlik testleri için yazılı bir Security Test Plan hazırlanmalıdır. Plan şu bileşenleri içermelidir:

• Test kapsamı (fiziksel, yazılım, ağ, bulut altyapısı)
• Test türleri (penetrasyon testi, fuzzing, code review, configuration validation)
• Test sıklığı ve sorumluluklar
• Kullanılacak araçlar (ör. Metasploit, OWASP ZAP, Nmap, Binwalk)

Test sonuçları, Security Validation Report olarak saklanmalı ve kritik açıklar giderilmeden ürün üretime alınmamalıdır. Bu plan, ISO 27034-1 ve NIST SP 800-115 (Technical Guide to Information Security Testing) standartlarına uygun olmalıdır.

Ürün üzerindeki tüm arayüzler için yetkilendirme politikası oluşturulmalıdır.

• Geliştirme arayüzleri (UART, JTAG, SWD) yalnızca mühendislik örneklerinde açık olmalı; seri üretim ürünlerinde devre dışı bırakılmalı veya parola / anahtar tabanlı erişim gerektirmelidir
• Kablosuz arayüzlerde (Wi-Fi, BLE) erişim, güçlü kimlik doğrulama (WPA3, BLE LE Secure Connections) ile korunmalıdır
• Web API ve bulut servislerinde API-Key veya OAuth 2.0 token zorunlu olmalıdır

Tüm bu arayüzlerin etkinliği üretim sonu testinde doğrulanmalı ve "Interface Security Matrix" dokümanına kaydedilmelidir.

Ürün hiçbir zaman varsayılan (default) kullanıcı adı veya parola içermemelidir.

• İlk kurulumda kullanıcıya şifre belirleme zorunluluğu getirilmelidir
• Şifre karma algoritması olarak en az SHA-256 veya bcrypt / Argon2 gibi modern fonksiyonlar kullanılmalıdır
• Şifreler açık metin (plaintext) biçiminde saklanmamalı; güvenli tuzlama (salt) uygulanmalıdır
• Yönetici (admin) erişimi bulunan cihazlarda parola politikası (min 8 karakter, karma yapı, periyodik değişim) zorunlu olmalıdır

Bu yaklaşım ETSI EN 303 645 Madde 5.1 ("No universal default passwords") gerekliliğini karşılar.

Tüm kullanıcı ve sistem erişimleri için çok katmanlı doğrulama uygulanmalıdır.

• Minimum gereklilik: hash + salt + nonce ile korunan kimlik doğrulama
• Ağ tabanlı sistemlerde TLS 1.2+ ile korunan oturum kimliği (session ID)
• Kritik sistemlerde iki faktörlü kimlik doğrulama (2FA) veya donanım token (YubiKey, OTP) desteği
• Parola saklama ve yönetimi, OWASP IoT Security Guidelines doğrultusunda yapılmalıdır

Başarısız oturum denemeleri lock-out mekanizmasıyla sınırlandırılmalıdır (ör. 5 deneme → 10 dakika kilit).

Sistemdeki erişim hakları Rol Bazlı Erişim Kontrolü (RBAC) prensibiyle düzenlenmelidir.

Örnek roller: Admin, Servis Teknisyeni, Kullanıcı, Misafir. Her rol için:

• İzin verilen işlemler
• Komut veya API erişim sınırları
• Konfigürasyon değiştirme yetkileri açıkça tanımlanmalıdır

Yetki yönetimi merkezi bir dizin (ör. LDAP, OAuth claims) veya yerel erişim tablosu üzerinden yürütülmelidir. RBAC yapısı firmware güncellemelerinde korunmalı, yetki bypass'ı (privilege escalation) testlerle doğrulanmalıdır.

Uygulama ve web arayüzlerinde oturum güvenliği temel gerekliliktir.

• Oturumlar, belirli bir süre sonra otomatik olarak sonlandırılmalı (idle timeout 15 dakika veya daha kısa)
• Erişim token'ları belirli aralıklarla yenilenmeli (refresh token flow)
• Token ve çerezler yalnızca HTTPS Secure flag + HttpOnly parametreleriyle saklanmalıdır
• Çoklu oturum tespiti veya eşzamanlı giriş kısıtlaması uygulanmalıdır
• Oturum kimlikleri rastgele ve yeterli entropiye sahip UUID v4 veya 256-bit random değer olmalıdır

Bu maddeler OWASP Session Management Cheat Sheet ile uyumludur.

Cihaz üzerindeki fiziksel portlar ve bakım bağlantıları yetkisiz erişime karşı korunmalıdır.

• Debug portları (UART, JTAG, SWD) üretim sürümlerinde devre dışı bırakılmalı veya epoksi / metal kapakla mühürlenmelidir
• Servis konektörleri sadece yetkili teknisyenlerin kullanacağı özel adaptörlerle erişilebilir olmalıdır
• SD kart veya çıkarılabilir medya yuvaları için donanım kilidi (write-protect) ve dijital imza doğrulaması uygulanmalıdır
• Fiziksel açılma (tamper) durumunda cihazın kendini kilitlemesi veya olay kaydı oluşturması sağlanmalıdır

Bu önlemler, IEC 62443-4-2 CR 3.5 ve NIST SP 800-88 fiziksel güvenlik ilkeleriyle uyumludur.

Cihazın bootloader aşamasında dijital imzalı firmware doğrulaması yapılmalıdır.

• Her firmware imajı, RSA-2048 veya ECDSA-P256 algoritmasıyla dijital olarak imzalanmalıdır
• Bootloader, firmware'in doğruluğunu üreticiye ait public key üzerinden kontrol etmelidir
• İmza doğrulaması başarısızsa sistem başlatılmamalı ve güvenli hata moduna (safe mode) geçmelidir

Bu yöntem, yetkisiz veya kötü niyetli firmware yüklemelerini (malware injection) tamamen engeller. Standart referans: NIST SP 800-193 (Platform Firmware Resiliency), ETSI EN 303 645 Madde 5.7.2.

Firmware dosyasının bütünlüğü, önyükleme ve güncelleme aşamasında hash algoritması ile kontrol edilmelidir.

• Minimum gereklilik: SHA-256, tercih edilen yöntem: HMAC-SHA256 (anahtarlı doğrulama)
• Bootloader, firmware'in imzası dışında hash değerini de doğrulamalıdır
• Hash, firmware meta verilerinde (manifest) saklanmalı ve imza dosyasıyla ilişkilendirilmelidir

Bu kontrol, veri bozulması (corruption) veya manipülasyon risklerini ortadan kaldırır.

Tüm başlatma süreci, güvenli bir Trust Chain yapısı üzerinden ilerlemelidir:

1. Boot ROM: Donanım içine gömülü ve değiştirilemez, bootloader imzasını doğrular
2. Bootloader: Firmware imzasını doğrular
3. Application: Sadece doğrulanmış imaj üzerinden başlatılır

Bu zincir, her aşamanın bir öncekini kriptografik olarak doğrulaması prensibine dayanır. Donanım destekliyorsa Root of Trust (RoT) veya TPM/PUF tabanlı anahtar depolama kullanılmalıdır. Zincir tamamlanmadan sistemin çalışmasına izin verilmemelidir. Bu uygulama, IEC 62443-4-2 CR 3.1 – Secure Boot Integrity Verification maddesini doğrudan karşılar.

Tüm firmware güncellemeleri, güvenli ve şifreli iletişim kanalları üzerinden yapılmalıdır:

• OTA (Over-the-Air) güncellemelerde TLS 1.2 veya TLS 1.3 zorunludur
• Yerel güncellemelerde (USB, SD kart) AES-256-CBC veya GCM modunda şifrelenmiş dosya kullanılmalıdır
• Güncellemeler imzalı manifest dosyasıyla birlikte doğrulanmalıdır
• Yetkisiz güncelleme girişimleri sistem log'larına kaydedilmeli ve engellenmelidir

Bu yaklaşım, NIST SP 800-147B ve ETSI EN 303 645 Section 5.5 standartlarında tanımlanan güvenli güncelleme gerekliliklerine uygundur.

Cihaz, başarısız veya bozuk güncellemeler sonrasında önceki kararlı sürüme otomatik dönebilmelidir.

Rollback mekanizması:

• İki firmware bölümü (A/B partition) veya çift imaj sistemi üzerinden çalışmalıdır
• Yeni sürüm doğrulanmazsa sistem otomatik olarak "last known good" sürümü başlatmalıdır
• Rollback işlemi log'lanmalı ve kullanıcıya bildirilmelidir

Bu özellik, brick riskini azaltır ve sistem sürekliliğini korur. Standart karşılığı: PSA Certified Security Model – Firmware Update Resilience.

Her firmware yüklemesi veya güncellemesi sonrasında aşağıdaki bilgiler log sistemine kaydedilmelidir:

• Firmware versiyonu (v1.0.3 vb.)
• İmza doğrulama sonucu (PASS / FAIL)
• Güncelleme kaynağı (OTA / USB / lokal)
• Tarih–zaman damgası
• Kullanıcı veya sistem kimliği

Bu loglar yalnızca salt-okunur (read-only) hafızada veya güvenli log deposunda (secure log storage) tutulmalıdır. Kritik log kayıtları imzalanmalı veya HMAC ile korunmalıdır. Bu gereklilik, ISO 27001 A.12.4 (Logging and Monitoring) ve ETSI EN 303 645 Section 5.8 ile uyumludur.

Ürün yalnızca işlevsel olarak gerekli verileri toplamalıdır. Her veri türü için şu analiz yapılmalıdır:

• Amaç: Bu veri hangi işlev için toplanıyor?
• Gereklilik: Bu veri olmadan cihaz çalışabilir mi?
• Risk: Verinin sızması durumunda kullanıcı veya sistem etkilenir mi?

Gereksiz veri toplama yasaklanmalı, "Data Inventory" ve "Privacy Impact Assessment (PIA)" belgeleri ile doğrulanmalıdır. Bu yaklaşım, GDPR Madde 5(1)(c) ve KVKK Madde 4(2)(ç) ("Veri işleme amaçla sınırlı olmalıdır") gerekliliğini karşılar.

Tüm kişisel, finansal, konum veya kimlik bilgileri cihazda şifreli biçimde saklanmalıdır.

• En az: AES-128-GCM, tercihen AES-256-GCM veya ChaCha20-Poly1305
• Anahtarlar donanım tabanlı güvenli bölgede tutulmalı (TPM, Secure Element, PUF)
• Şifreli veri alanları için ayrı dosya sistemi (örn. LUKS, eCryptFS, veya AES-XTS disk bölümü) kullanılabilir
• Hassas veriler (ör. şifre, token, konum) asla açık metin (plaintext) saklanmamalıdır

Bu uygulama, ISO 27001 A.10.1 (Cryptographic Controls) ve IEC 62443-4-2 CR 3.4 standartlarıyla uyumludur.

Tüm veri iletişimi güvenli bir kanal üzerinden yapılmalıdır.

• IP tabanlı haberleşmede TLS 1.2 / 1.3 veya DTLS 1.3 kullanılmalıdır
• MQTT, CoAP gibi IoT protokolleri TLS veya DTLS katmanıyla korunmalıdır
• Uçtan uca bağlantılar için VPN, IPSec veya WireGuard entegrasyonu tercih edilmelidir
• Sertifika doğrulaması (certificate pinning) aktif olmalı; self-signed sertifikalar üretim sistemlerinde yasaktır
• Eski ve zayıf protokoller (SSLv3, TLS 1.0, RC4, MD5) kesinlikle devre dışı bırakılmalıdır

Bu kontrol, ETSI EN 303 645 Madde 5.5 ("Secure communications") gerekliliğini doğrudan karşılar.

Tüm sistem loglarında kişisel veriler maskeleme veya anonimleştirme yoluyla saklanmalıdır.

Örnek:

• IP adresleri → 192.168.xxx.xxx
• Kullanıcı adları → hashed_user_id
• Konum verileri → yuvarlatılmış veya bölgesel bazda saklama

Log'lar salt okunur alanda tutulmalı, imzalanmalı (HMAC veya ECDSA) ve yetkisiz erişimden korunmalıdır. Bu uygulama, ISO 27018 (PII protection for cloud services) ve GDPR Recital 26 (Anonymization) prensipleriyle uyumludur.

Kullanıcı verisi cihazdan, buluttan veya veritabanından kalıcı olarak silinebilmelidir.

Silme süreci:

1. Kullanıcı isteği (RTBF – Right to be Forgotten) alınır
2. Veriler üretici altyapısından, yedeklerden ve cihazdan silinir veya anonimleştirilir
3. Silme işlemi denetlenebilir kayıtla (audit trail) belgelenir

Anonimleştirme, veriyle kişinin ilişkilendirilemeyeceği şekilde yapılmalıdır (örn. hash + salt + random ID). Bu adım, GDPR Madde 17 (Erasure Right) ve KVKK Madde 7 (Silme, yok etme, anonimleştirme) gerekliliğini karşılar.

Tüm veri türleri için saklama süresi (retention period) ve silme kriterleri tanımlanmalıdır.

Örnek:

• Sistem logları: 90 gün
• Kullanıcı etkinlik kayıtları: 1 yıl
• Sensör ölçüm verisi: 3 yıl
• Kişisel veriler: kullanıcı hesabı kapatıldığında silinir

Politika, "Data Retention Policy" başlıklı belgede yer almalı ve ERP/PLM sistemlerinde işaretlenmelidir. Silme işlemleri doğrulama log'u ile kanıtlanmalıdır (audit evidence). Bu gereklilik, ISO 27001 A.18.1.3 (Retention of Records) ve GDPR Art.5(1)(e) standartlarına uygundur.

Kullanıcıya, veri erişimi, düzeltme, silme ve taşınabilirlik hakları sağlanmalıdır:

• RTBF (Right to Be Forgotten): Verilerin kalıcı silinmesi
• Data Export: Kullanıcı verilerinin açık formatta (JSON, CSV) dışa aktarımı
• Access Request: Kullanıcının kendisiyle ilgili verileri sorgulama hakkı
• Consent Management: Kullanıcı rızasının izlenmesi, geri çekilmesi veya yeniden verilmesi

Bu özellikler, ürünün yönetim arayüzünde veya mobil uygulamasında erişilebilir olmalıdır. Her talep için işlem süresi ve doğrulama adımları (ör. kimlik kontrolü) dokümante edilmelidir. Bu madde GDPR Chapter 3 (Art. 12–23) ve KVKK Madde 11 hükümleriyle doğrudan uyumludur.

Tüm uzun ömürlü kriptografik anahtarlar (ör. private key, session master key, firmware signing key) donanım güvenlik modüllerinde saklanmalıdır:

• TPM (Trusted Platform Module) veya Secure Element (ATECC608, STSAFE) gibi çipler kullanılmalıdır
• Sunucu tarafında anahtar depolama için HSM (Hardware Security Module) zorunlu olmalıdır
• Anahtarlar asla flash veya EEPROM üzerinde açık biçimde tutulmamalıdır
• Erişim yalnızca donanım içi API'ler (PKCS#11, TEE, PSA Crypto API) üzerinden sağlanmalıdır

Bu yöntem, NIST SP 800-57 Part 1 Section 5.6.2.2 ve FIPS 140-3 Level 2+ kriterlerini karşılar.

Tüm anahtar türleri (master, session, update, device key) için yazılı bir Key Management Policy hazırlanmalıdır.

Politika içeriği:

• Anahtar oluşturma yöntemi (TRNG/DRBG tabanlı)
• Saklama yeri (TPM, HSM, Secure Element, Encrypted File)
• Yaşam süresi (key lifetime) ve yenileme periyodu
• Dağıtım ve yetkilendirme kuralları
• Yedekleme (key escrow) ve kurtarma prosedürü
• İptal ve imha (key revocation/destruction) süreci

Politika belgesi, ISO 27001 A.10.1.2 ve NIST SP 800-57 Part 2 ile uyumlu olmalıdır.

Anahtar değişimi sırasında kullanılan algoritmalar güncel güvenlik standartlarını karşılamalıdır:

• RSA 2048+, ECDH (P-256, Curve25519) veya X25519 kullanılmalıdır
• Eski algoritmalar (DH 2048 bit'ten az, RSA 1024, MD5, SHA-1) tamamen yasaklanmalıdır
• Ephemeral anahtar değişimi (ECDHE) tercih edilerek forward secrecy sağlanmalıdır
• TLS profilleri, RFC 8446 (TLS 1.3) veya RFC 7919 uyumlu olmalıdır

Ayrıca, algoritma parametreleri ve sertifika imzaları düzenli olarak güvenlik denetiminden geçirilmelidir.

Tüm kriptografik işlemler, güvenilir rastgelelik kaynakları kullanmalıdır.

• Donanım tabanlı TRNG (True Random Number Generator) öncelikli olarak kullanılmalı; mevcut değilse, NIST onaylı DRBG (Deterministic Random Bit Generator) algoritması uygulanmalıdır
• Rastgelelik kalitesi FIPS 140-2 Annex C veya AIS 31 testleriyle doğrulanmalıdır
• Entropi kaynakları (thermal noise, ring oscillator, ADC jitter) izlenmeli ve test sonuçları üretim log'una kaydedilmelidir

Zayıf RNG kaynakları, anahtar tahminine ve kriptografik zafiyetlere yol açabilir.

Üründe kullanılan tüm kriptografi kütüphaneleri (ör. mbedTLS, OpenSSL, WolfSSL, libsodium) belirli sürüm güvenlik kontrollerinden geçmelidir:

• Sürüm kontrolü: en son LTS (Long Term Support) sürümü kullanılmalıdır
• Güvenlik açıkları (CVE) düzenli olarak izlenmelidir
• Derleme sırasında zayıf algoritmalar ve protokoller devre dışı bırakılmalıdır
• Kütüphaneler "reproducible build" prensibine uygun olarak doğrulanmalıdır

Bu kontrol, CWE-327 (Use of Broken Cryptographic Algorithm) ve ISO 27002:2022 A.8.28 maddelerini karşılar.

Anahtar sızıntısı veya yetkisiz erişim durumunda sistem, ilgili anahtarları otomatik olarak geçersiz kılma (revocation) mekanizmasına sahip olmalıdır.

• Revocation listesi (CRL) veya OCSP desteklenmelidir
• Cihaz, güncelleme veya yeniden bağlantı sırasında yeni anahtar/sertifika alabilmelidir
• Sızıntı tespiti sonrası tüm oturumlar ve imzalar otomatik olarak iptal edilmelidir
• Üretici altyapısı "Key Compromise Response Plan" dokümanına sahip olmalıdır

Bu yapı, ETSI EN 303 645 Madde 5.7.3 ve NIST SP 800-57 Part 3 gereklilikleriyle uyumludur.

Tüm ağ bağlantılarında, şifrelenmemiş veya kimliksiz protokoller yasaklanmalıdır.

• Ethernet / IP tabanlı: yalnızca TLS 1.2 veya TLS 1.3; HTTP yerine HTTPS, FTP yerine SFTP/FTPS kullanılmalıdır
• Wi-Fi: minimum WPA2-PSK (AES) veya tercihen WPA3-SAE; WEP ve TKIP tamamen devre dışı bırakılmalıdır
• BLE: yalnızca "LE Secure Connections" modu etkin olmalı, pairing sırasında 6 haneli PIN veya OOB anahtar kullanılmalıdır
• 4G/LTE: operatör SIM kimlik doğrulaması aktif olmalı, APN erişimi sınırlandırılmalıdır

Cihazın ağ yapılandırması "Network Interface Security Checklist" dokümanıyla doğrulanmalıdır.

Cihazda çalışan tüm servisler (TCP/UDP) belirlenmeli ve yalnızca zorunlu olanlar açık bırakılmalıdır.

• Port tarama (Nmap, Masscan) testleri düzenli yapılmalıdır
• Debug, Telnet, FTP, SNMP v1/2c gibi zayıf servisler tamamen kaldırılmalıdır
• Servis dinleme adresleri yalnızca iç arayüzlerle (localhost, management VLAN) sınırlanmalıdır
• "Network Exposure Report" hazırlanarak her sürümde güncellenmelidir

Bu kontrol, OWASP IoT-1: Weak Network Services maddesini doğrudan karşılar.

Cihaz ve bulut arasındaki TLS sertifikalarının:

• Geçerlilik süresi (expiry date) otomatik izlenmeli, yenileme planı oluşturulmalıdır
• Sertifika zinciri tam olmalı (root → intermediate → server)
• RSA 2048+ veya ECDSA P-256 anahtar uzunluğu kullanılmalıdır
• Self-signed sertifikalar yalnızca geliştirme ortamlarında kabul edilmelidir

Üretim sistemlerinde OCSP veya CRL check aktif olmalıdır. Bu gereklilik RFC 5280 ve ETSI EN 319 411 sertifika yönetimi standartlarıyla uyumludur.

Cihaz istemci tarafında sertifika pinning veya public key pinning (HPKP) desteğine sahip olmalıdır.

• Her bağlantı, yalnızca önceden tanımlı CA veya public key ile doğrulanmalıdır
• DNS spoofing, MITM ve proxy saldırılarına karşı sertifika parmak izi (SHA-256 fingerprint) kontrolü yapılmalıdır
• Sertifika değişimi planlandığında, yeni parmak izi önceden OTA ile dağıtılmalıdır

Bu uygulama, NIST SP 800-52 Rev.2 ve OWASP Mobile Top 10 M3 (Insecure Communication) rehberleriyle uyumludur.

Cihazın bulut veya harici sistemlerle haberleşmesinde her API çağrısı kimlik doğrulamalı olmalıdır.

• API Key, JWT veya OAuth 2.0 Bearer token kullanılmalıdır
• Token'ların ömrü sınırlı (ör. 24 saat) ve yenileme (refresh token) mekanizması olmalıdır
• "Least Privilege" prensibiyle her token yalnızca belirli endpoint'lere erişebilmelidir
• API log'ları kimlik, zaman ve işlem türüyle birlikte imzalanmalıdır

Bu adım, ISO 27034 (App Security Framework) gerekliliğini karşılar.

IoT iletişim protokolleri güvenli taşıma katmanı kullanmalıdır:

• MQTT: TLS 1.2+ veya PSK tabanlı oturum (MQTTS, port 8883)
• CoAP: yalnızca DTLS 1.3 veya OSCORE (RFC 8613)
• Topic'ler, kullanıcı kimliği veya gizli veri içermemelidir
• Broker kimliği sertifikayla doğrulanmalı, anonymous connect devre dışı bırakılmalıdır

Bu kontrol, ETSI EN 303 645 Madde 5.5 ("Secure communications") standardını doğrudan karşılar.

Cihaz veya sunucu, brute-force ve DoS saldırılarını azaltmak için aşağıdaki korumalara sahip olmalıdır:

• Oturum açma ve API çağrıları için rate limit (örn. 10 istek / dakika)
• Giriş denemelerinde başarısızlık eşiği (5 deneme → 10 dakika kilit)
• SYN flood, UDP amplification ve ping saldırılarına karşı firewall / IDS kuralı
• Ağ katmanında fail2ban veya benzeri dinamik engelleme sistemi
• Anormallik tespiti için SIEM veya log analizi (örn. ELK, Splunk)

Bu yaklaşım, IEC 62443-4-2 CR 7.1 – Denial of Service Protection gerekliliğini karşılar.

Ürün yazılımında kullanılan tüm harici bileşenler, açık kaynak kütüphaneler ve bağımlılıklar bir SBOM (Software Bill of Materials) listesinde tanımlanmalıdır.

SBOM içeriği:

• Kütüphane adı, sürümü ve lisansı
• Kaynak deposu (repository URL)
• Ürün sürümünde kullanım alanı
• SHA-256 checksum ve bütünlük doğrulaması

SBOM, her sürümle birlikte güncellenmeli ve üretim dosyalarına dahil edilmelidir. Bu gereklilik, NTIA SBOM Framework, ISO/IEC 5230 (OpenChain) ve US Executive Order 14028 standartlarına uygundur.

Tüm açık kaynak ve üçüncü taraf kütüphaneler düzenli olarak zafiyet veri tabanlarına (CVE/NVD, GitHub Security Advisories, OSS Index) göre taranmalıdır.

• Tarama araçları: Trivy, Snyk, Anchore, Dependency-Check
• Otomatik CI/CD pipeline entegrasyonu yapılmalı
• Kritik zafiyet (CVSS 7.0 veya daha yüksek) tespitlerinde otomatik bildirim ve blokaj uygulanmalıdır

Her sürüm öncesi "Vulnerability Scan Report" hazırlanmalı ve kalite onayından geçmelidir. Bu uygulama, OWASP SAMM Governance 2.3 ve NIST SP 800-218 (SSDF PRM.3.2) gerekliliklerini karşılar.

Kuruluş, güvenlik danışmanlığı hizmeti veya otomatik CVE bildirim sistemi kullanmalıdır.

• Günlük veya haftalık CVE feed'leri (NVD JSON, GitHub Security Alerts) izlenmelidir
• Kritik bileşenlerde (ör. OpenSSL, glibc, BusyBox, Linux kernel) CVE takip sorumlusu atanmalıdır
• Yeni bir zafiyet duyurulduğunda, etki analizi (impact assessment) ve düzeltme planı 72 saat içinde yapılmalıdır

Bu yaklaşım, ISO 30111 (Vulnerability Handling Processes) ve FIRST PSIRT Guidelines standartlarıyla uyumludur.

Yazılım güncellemeleri yalnızca işlevsel değişiklikleri değil, güvenlik yamalarını da içermelidir.

• Her yeni firmware sürümünde "Security Patch List" oluşturulmalı
• Kritik CVE yamaları planlı güncellemelerde dahil edilmeden sürüm yayınlanmamalıdır
• Geriye dönük (legacy) ürünler için de minimum güvenlik güncellemesi politikası tanımlanmalıdır (ör. 5 yıl destek)

Bu madde, ETSI EN 303 645 Section 5.3 ("Keep software updated") gerekliliğini doğrudan karşılar.

Tüm yazılım ve firmware derlemeleri imzalama pipeline'ı üzerinden geçmelidir:

• Kod imzalama süreci yalnızca yetkili kişilerin erişebileceği HSM veya "signing server" üzerinde çalışmalıdır
• İmzalama anahtarları (private keys) developer makinelerinde asla bulunmamalıdır
• İmzalı build çıktıları, "Signature Verification Script" ile test edilmelidir
• Kod imzalama süreci yılda en az bir kez iç denetim (audit) tarafından gözden geçirilmelidir

Bu madde, NIST SP 800-218 (SSDF RVF.1) ve SLSA Level 3+ gerekliliklerine uygundur.

Derleme altyapısı (CI/CD pipeline, build server, container, toolchain) yetkisiz erişime, kötü niyetli kod eklenmesine ve sürüm manipülasyonuna karşı korunmalıdır.

• Geliştirici erişimleri RBAC ve MFA ile sınırlandırılmalıdır
• Derleme ortamı yalnızca imzalı, doğrulanmış kaynak koddan build almalıdır
• Her build çıktısı için hash değeri (checksum) ve imza doğrulaması yapılmalıdır
• Build log'ları değiştirilemez biçimde arşivlenmelidir
• CI/CD ortamında kaynak kod, binary ve artifact tutarlılığı ("reproducible builds") test edilmelidir

Bu önlem, NIST Secure Software Development Framework (SSDF PM.2, RVF.2) ve Google SLSA Level 4 standardında tanımlanan tedarik zinciri güvenliği ilkeleriyle uyumludur.

Cihaz, ağ ve bulut servislerinde gerçekleşen tüm güvenlik olayları kayıt altına alınmalıdır.

Log sistemi şu olayları en azından izlemelidir:

• Başarısız oturum açma denemeleri
• Erişim reddi veya yetkisiz API çağrısı
• Yetkisiz firmware yükleme / konfigürasyon değişiklikleri
• Dosya bütünlüğü ihlali (hash mismatch)
• Anormal ağ trafiği veya servis yüklenmesi

Loglama düzeyi (info/warning/error/critical) ürün tipine göre belirlenmeli, zaman damgası NTP veya RTC senkronizasyonuyla doğrulanmalıdır. Bu madde IEC 62443-4-2 CR 6.1 "Audit Log Capability" standardıyla uyumludur.

Tüm log dosyaları manipülasyona karşı korunmalıdır.

• Log kayıtları HMAC-SHA256 veya ECDSA imzası ile bütünlük doğrulamasına sahip olmalıdır
• Log dosyaları salt okunur bölgeye (read-only partition / WORM storage) yazılmalıdır
• Her log bloğu zaman damgası, cihaz kimliği ve imza zinciri (hash chain) içererek doğrulanabilir olmalıdır
• Dışa aktarılan loglar şifreli biçimde (AES-GCM) iletilmeli ve yalnızca yetkili servis tarafından okunmalıdır

Bu yaklaşım, NIST SP 800-92 (Guide to Computer Security Log Management) gerekliliklerini karşılar.

Kuruluşta resmi bir Güvenlik Olayı Müdahale Planı (Incident Response Plan – IRP) hazırlanmalıdır.

IRP içeriği:

1. Olay sınıflandırması (kritik, yüksek, orta, düşük)
2. Bildirim zinciri ve sorumluluklar (Product Security Owner, IT, yönetim)
3. İlk müdahale adımları (containment, eradication, recovery)
4. Olay sonrası analiz ve dokümantasyon (post-mortem)
5. İyileştirme ve önleyici aksiyon planı

Plan yılda en az bir kez tatbikatla test edilmeli; PSIRT (Product Security Incident Response Team) organizasyonu aktif olmalıdır. Standart uyum: ISO/IEC 27035-1:2016 ve FIRST PSIRT Framework.

Sistem, kritik zafiyet veya güvenlik ihlali tespit ettiğinde hem kullanıcıya hem üreticiye bildirim gönderebilmelidir.

• Kullanıcı uyarıları: ekran, LED, mobil bildirim veya e-posta ile
• Üretici bildirimleri: otomatik log transferi, SNMP trap, MQTT event veya REST API ile PSIRT sistemine
• Olay sınıfı: firmware bütünlük hatası, başarısız güncelleme, tekrarlayan brute-force saldırısı vb.

Bildirim sistemi, ISO/IEC 30111 (Vulnerability Handling) ve ETSI EN 303 645 Section 5.6 ("Report of security vulnerabilities") gerekliliklerini karşılamalıdır.

Cihaz logları, merkezi SIEM (Security Information & Event Management) altyapısına aktarılmalıdır.

• Log iletimi TLS 1.2+, Syslog-TLS (RFC 5425) veya MQTT/HTTPS üzerinden yapılmalıdır
• Kişisel veriler (PII) anonimleştirilmiş veya maskelenmiş biçimde gönderilmelidir
• SIEM korelasyon kuralları anormallikleri otomatik tespit etmelidir (ör. 5 başarısız oturum / 10 dk)
• Kullanılabilecek çözümler: ELK, Splunk, Graylog, Wazuh, Sentinel

Bu yapı, ISO 27001 A.12.4 (Logging and Monitoring) ve IEC 62443-4-1 SR 6.2 (Security Event Monitoring) ile uyumludur.

Her firmware veya yazılım sürümünde yapılan güvenlik iyileştirmeleri açık şekilde dokümante edilmelidir:

• "Security Changelog" veya "Release Notes" içerisinde CVE numaraları ve düzeltme açıklamaları belirtilmelidir
• Kritik düzeydeki yamalar için risk seviyesi (CVSS skoru) ve etkilenen bileşen listesi sunulmalıdır
• Kullanıcılar, yeni sürümde hangi açıkların kapatıldığını şeffaf biçimde görebilmelidir

Bu uygulama, ISO 29147 (Vulnerability Disclosure) ve ETSI EN 303 645 Section 5.3 ("Keep software updated") ilkelerini karşılar.

Üretim hattında firmware veya konfigürasyon dosyaları yüklenirken, yetkisiz erişim veya manipülasyon riski önlenmelidir.

• Firmware yükleme (flashing) işlemleri yalnızca TLS/SSH veya şifreli yerel bağlantı (AES-256) üzerinden yapılmalıdır
• Yükleme aracı, imzalı firmware doğrulaması (signature verification) gerçekleştirmelidir
• Firmware dosyaları üretim ağı dışında saklanmamalı, erişim sadece yetkili personel tarafından MFA (Multi-Factor Authentication) ile sağlanmalıdır
• Flash işlemi sonrası doğrulama hash'i (SHA-256) otomatik olarak kaydedilmelidir

Bu uygulama, IEC 62443-4-1 SR 5.4 "Secure Delivery & Integration" standardını karşılar.

Her cihaz, benzersiz bir seri numara (SN) ve donanım güvenlik kimliği (UID / Device ID / PUF) ile tanımlanmalıdır.

• Bu iki kimlik üretim esnasında veri tabanında eşleştirilerek kaydedilmelidir
• UID bilgisi cihazın kriptografik kimlik doğrulamasında (ör. mutual TLS, device attestation) kullanılmalıdır
• UID hiçbir zaman kullanıcıya açık veya dışa aktarılabilir biçimde gösterilmemelidir

Bu ilişkilendirme, izlenebilirlik (traceability) ve güvenli tedarik zinciri yönetimi için zorunludur. Standart referans: ISO/IEC 20243 (Open Trusted Technology Provider Standard – OTTPS).

Tüm servis, konfigürasyon veya test araçları yalnızca imzalı ve doğrulanmış cihazlarla etkileşime girebilmelidir.

• Servis yazılımları cihaz kimliğini (UID veya sertifika) kontrol etmeden işlem yapmamalıdır
• Cihaz–servis iletişimi mutual TLS veya donanım imzası doğrulamasıyla korunmalıdır
• Servis yazılımları da imzalı olmalı (code-signing certificate) ve sadece güvenli platformlarda çalıştırılmalıdır
• Cihaz kimliği eşleşmeyen veya yetkisiz cihazlarda servis işlemi reddedilmelidir

Bu madde, IEC 62443-4-2 CR 3.3 "Integrity of Information" standardıyla uyumludur.

Üretim sonrası kalite testleri tamamlandıktan sonra tüm debug arayüzleri kalıcı biçimde devre dışı bırakılmalıdır.

• MCU güvenlik bitleri (Lock bits, Read-out Protection, Security Fuse) üretim sonunda aktif edilmelidir
• Bu işlem firmware doğrulama testinden sonra yapılmalı; üretim kaydında zaman damgası ile log'lanmalıdır
• Test sonrasında JTAG, SWD, UART gibi portlar yazılım veya donanım seviyesinde erişilemez olmalıdır
• Servis erişimi gerekiyorsa özel "signed unlock token" mekanizması kullanılmalıdır

Bu uygulama, CWE-1191 (Improper Restriction of Debug Interface Access) riskini ortadan kaldırır.

Servis veya özel bakım modlarına geçiş yalnızca fiziksel erişimle ve doğrulanmış kimlik ile mümkün olmalıdır.

• Servis modu; cihaz açılarak, özel konektör veya PIN kombinasyonu kullanılarak etkinleştirilmeli
• Yazılım tabanlı servis erişimi (remote mode) yalnızca imzalı komut ve geçici token ile açılabilmelidir
• Servis moduna geçiş ve çıkış tüm log sistemine kaydedilmelidir
• Kritik ürünlerde (ör. medikal, endüstriyel kontrol) servis moduna giriş sırasında otomatik güvenlik denetimi (safety interlock) yapılmalıdır

Bu kural, ISO/SAE 21434 (Cybersecurity for Road Vehicles) ve IEC 62368-1 (Service Access Control) ilkeleriyle uyumludur.