Bu sayfa tek bir kayıt türüne sığmayan işleri anlatır: birkaç sistemin kaydını tek bir zaman eksenine oturtmak, bir teslimi şartnameyle madde madde karşılaştırmak, bir işlemin bir standarda uyup uymadığını göstermek. Dosyada zaten bir bilirkişi raporu varsa gereken çoğu zaman bilirkişi raporunun teknik değerlendirmesidir; ceza dosyasında literatür ağırlıklı bir görüş gerekiyorsa bilimsel mütalaa sayfasına bakın.
Teknik mütalaa mı, teknik rapor mu?
Fark sorunun genişliğindedir. Mütalaa tek bir teknik meseleye yeni edinim yapmadan cevap verir; rapor birden fazla kaynağı inceler.
| Ölçüt | Teknik mütalaa | Teknik rapor |
|---|---|---|
| Tipik soru | "NTFS'teki son erişim zamanı dosyanın o saatte açıldığını gösterir mi?" | "Müşteri listesi şirket dışına hangi yolla, ne zaman çıktı?" |
| Materyal | Dosyadaki belgeler ve raporlar | Ham kayıtlar, imajlar, dışa aktarımlar |
| Dosyaya sunulunca | Hukuk yargılamasında uzman görüşü (HMK m.293), ceza yargılamasında bilimsel mütalaa (CMK m.67/6) | |
Tablodaki ilk sorunun cevabı bir mütalaa örneğidir: NTFS son erişim zamanını diske yazmayı bir saate kadar erteleyebilir ve bu güncelleme ayarla tamamen kapatılabilir. Son erişim zamanı tek başına "o saatte açıldı" demeye yetmez.
Bilişim teknolojileri uzman görüşü
Bir sistemin, ağın ya da hizmetin olay tarihinde nasıl çalıştığını anlatan görüştür; mütalaa olarak başlar, kayıt incelemesi gerekirse rapora dönüşür. Tipik sorular:
- Bir bulut paylaşım bağlantısı olay tarihinde herkese açık mıydı, yoksa oturum mu gerektiriyordu?
- Sunucu, iletiyi teslim edilmiş gösterirken alıcı onu hiç görmemiş olabilir mi?
Teknik olay kronolojisi nasıl oluşturulur?
Olay kronolojisi, farklı kaynaklardaki kayıtların tek bir saat referansına çevrilip sıralandığı ve her satırın kaynağına kadar izlenebildiği tablodur. Sıralama işin kolay kısmıdır; asıl iş ondan önce yapılır.
- Kaynakları listeleriz. Her kaynak için sistem, kayıt türü, dışa aktarım yolu, dosya adı ve SHA-256 değeri. Kaynağı bilinmeyen satır kronolojiye girmez.
- Her kaynağın saat referansını belirleriz. Tipik durumlar aşağıdaki tabloda.
- Saat sapmasını ölçeriz. Senkronize olmayan saat kayar: NTP modelindeki 15 ppm frekans toleransı günde yaklaşık 1,3 saniye, üç ayda iki dakikaya yakın fark demektir (RFC 5905'ten hesap). Sistem saatinin değiştirilmesi Windows'ta 4616 olayı olarak, Linux'ta
wtmpkaydında görülebilir. - Tek dilime çeviririz. Tüm zamanlar tek bir dilime çevrilir (NIST SP 800-92). Kronolojide UTC ve okuma kolaylığı için Türkiye saati (UTC+3) iki ayrı sütundur.
- Birleştiririz, ham kaydı kaybetmeden. Büyük hacimde plaso (
log2timeline.py,psort.py) gibi araçlar kullanırız; her satırda kaynağın dosya yolu ve satır numarası kalır. - Tekilleştirir, boşlukları işaretleriz. Aynı olayı iki sistem kaydetmiş olabilir. Log rotasyonu ya da kapalı bir cihaz yüzünden boş kalan aralık "bir şey olmadı" demek değildir; ayrıca gösterilir.
| Kaynak | Zaman nasıl tutulur | Dikkat |
|---|---|---|
NTFS ($STANDARD_INFORMATION, $FILE_NAME) | UTC, 100 ns birimli FILETIME | $SI zamanları kullanıcı düzeyindeki araçlarla değiştirilebilir; $FN ve USN kaydıyla karşılaştırılır |
| FAT ve exFAT bellekler | Yerel saat, 2 saniye çözünürlük; exFAT'ta ofset alanı olabilir | Belleğe yazan cihazın o tarihteki saat dilimi bilinmelidir |
Nginx ($time_local), Apache (%t) | Yerel saat ve ofset (+0300) | Ofset satırda yazdığı için dönüşüm güvenlidir |
| Eski tip syslog (RFC 3164) | Yerel saat; yıl ve dilim yok | Yıl ve dilim bağlamdan çıkarılır, varsayım raporda yazılır |
| Operatör dökümleri (HTS) | Çoğunlukla yerel saat | Dökümde yazmıyorsa operatörün üst yazısından teyit edilir |
Tekil değerleri zaman damgası dönüştürücüyle kontrol edebilirsiniz; 2016 öncesi yaz ve kış saati geçişleri dahil tipik hatalar zaman damgası ve saat dilimi yazısında (kaynak: IANA tz, Europe/Istanbul).
Örnek (kurgusal): işten ayrılan bir çalışanla ilgili bir kronolojiden dört satır.
| # | UTC | UTC+3 | Kaynak | Olay |
|---|---|---|---|---|
| 1 | 18:02:11 | 21:02:11 | VPN ağ geçidi logu, satır 4.118 | kullanici07 hesabıyla oturum açıldı, kaynak 203.0.113.25 |
| 2 | 18:09:40 | 21:09:40 | Dosya sunucusu erişim denetim kaydı | musteri_listesi.xlsx okundu |
| 3 | 18:14:05 | 21:14:05 | İş bilgisayarı imajı, SYSTEM kayıt dosyası, USBSTOR | USB bellek bağlandı (son bağlanma zamanı) |
| 4 | 18:31:52 | 21:31:52 | E-posta sunucusu iletim kaydı | Ekli bir ileti alici@example.com adresine gönderildi |
Son sütun bilerek "olay" der, "eylem" demez. 3 numaralı satır belleğin bağlandığını gösterir, dosyanın belleğe kopyalandığını göstermez; bunu gösterecek başka bir kayıt (bellekteki dosyayı işaret eden bir LNK kaydı, belleğin kendisi) yoksa raporda da böyle yazar.
Birden fazla teknik delil birlikte nasıl değerlendirilir?
Birlikte değerlendirme, her delilin tek başına neyi gösterdiğini yazdıktan sonra aralarındaki bağlantıyı kurmaktır; bağlantı en zayıf halkasından güçlü olamaz. İnternet kaynaklı bir olayda tipik zincir:
sunucu logu (IP + kaynak port + UTC zaman) → erişim sağlayıcının NAT / oturum kaydı → abonelik kaydı → cihaz (imaj, HTS'deki IMEI) → kişi
Son ok teknik bir bağlantı değildir. Hattın ya da aboneliğin sahibi ile kullanıcısı farklı olabilir; CMK m.135/2 de iletişimin tespiti talebine hattın sahibini ve biliniyorsa kullanıcısını gösteren belgenin eklenmesini ister. Rapor zinciri kişiye kadar değil, verinin taşıyabildiği yere kadar kurar. İki kural daha uygularız:
- Bağımsız kaynaklar birbirini güçlendirir, aynı kaynaktan türeyenler güçlendirmez. Aynı hesabın ekran görüntüsü ile dışa aktarımı iki ayrı delil sayılmaz; sunucu logu ile erişim sağlayıcının kaydı ise bağımsız üretilmiştir.
- Çelişki saklanmaz. İki kaynak uyuşmuyorsa önce saat referansına ve kayıt kapsamına bakarız; çelişki giderilemiyorsa iki ihtimal de raporda yer alır.
Log kaynaklarının tek tek nasıl doğrulandığı log analizi sayfasında.
Teknik standart ve şartname incelemesi
Standart incelemesi
Standart incelemesi, bir işlemin (delilin edinimi, bir olay müdahalesi, bir sistemin yapılandırması) ilgili standardın öngördüğü adımlarla karşılaştırılmasıdır. Standart çoğu zaman "ne yapılmalı" der, "yapılmazsa ne olur" demez; sapmanın hangi bulguyu nasıl etkilediğini ayrıca yazarız. Sık başvurduğumuz belgeler:
- Delilin edinimi ve korunması: ISO/IEC 27037:2012. Analiz ve yorum: ISO/IEC 27042:2015.
- Olay müdahalesi: NIST SP 800-61 Rev. 3 (Nisan 2025). Eski raporlardaki dört aşamalı döngü 2012 tarihli Rev. 2'nin modelidir; Rev. 3 olay müdahalesini CSF 2.0 fonksiyonlarıyla ilişkilendirir.
- Log yönetimi ve saat senkronu: NIST SP 800-92. Paylaşılan IP adreslerinde sunucu loglaması: RFC 6302.
- Web uygulama güvenliği: OWASP Top 10:2025.
Uyum, olay tarihinde geçerli sürüme göre değerlendirilir: 2024'te yazılmış bir prosedürü 2025'te yayımlanan bir revizyona göre eksik saymak doğru olmaz.
Teknik şartname değerlendirmesi
Önce teslim edilen şeyin kimliği sabitlenir: hangi sürüm (commit hash, build numarası ya da özet değeri alınmış paket), hangi ortam, hangi test verisi. Ardından her şartname maddesi ayrı bir satır olur ve dört sonuçtan birini alır.
| Madde | Şartname metni (kurgusal) | Yapılan test | Sonuç |
|---|---|---|---|
| 4.2 | "Sistem 500 eşzamanlı kullanıcıyı desteklemelidir." | Test ortamında yük testi | Kısmen karşılandı: 350 kullanıcıya kadar hatasız, üzerinde isteklerin bir kısmı hata ile dönüyor |
| 6.1 | "Kullanıcı parolaları güvenli biçimde saklanmalıdır." | Veri tabanındaki parola alanının incelenmesi | Karşılanmadı: parolalar tuzsuz MD5 özetiyle tutuluyor |
| 7.3 | "Arayüz kullanıcı dostu olmalıdır." | Ölçülebilir kriter tanımlanmamış | Test edilemedi |
"Test edilemedi" bir kaçış değil, bulgudur. Böyle maddelerde neyin ölçülebileceğini (ör. bir görevin tamamlanma süresi) önerebiliriz; ölçütü seçmek ise tarafların ya da karar verenin işidir. Yazılım teslim uyuşmazlıklarının kod ve repository tarafı yazılım ve kaynak kod incelemesi sayfasında.
Şirket içi soruşturma, sigorta ve ihale uyuşmazlıkları
Dava dışı bir teknik raporun okuru çoğu zaman bir yönetim kurulu, bir hasar uzmanı ya da bir ihale komisyonudur:
| Durum | Tipik teknik soru | İşin başında netleşmesi gereken |
|---|---|---|
| Şirket içi soruşturma | Veri şirket dışına çıktı mı, hangi yolla, hangi hesapla? Bir kayıt kim tarafından, ne zaman değiştirildi? | İncelemenin hukuka uygunluğu (şirket cihazı mı, kişisel hesap mı) hukuk biriminizle; cihaz yeniden kurulmadan önce imaj |
| Siber sigorta ve hasar | Olay ne zaman başladı, ilk erişim hangi yoldan oldu, hangi sistemler ve veriler etkilendi? | Müdahale sırasında silinen loglar ve yeniden kurulan sunucular; poliçenin yorumu rapora değil sözleşmeye aittir |
| İhale ve tedarik | Teklif edilen ya da teslim edilen sistem teknik şartnameyi karşılıyor mu; ölçüm hangi yöntemle yapıldı? | Başvuru yolları ve süreleri avukatınız belirler; teknik takvim buna göre kurulur |
Böyle bir rapor da sonradan bir dosyaya girebilir; bu yüzden şirket içi incelemede de mahkemeye sunulacakmış gibi çalışırız.
Klavyenin başında kimin oturduğunu, bir işlemin kasıtlı mı yanlışlıkla mı yapıldığını, bir tarafın kusurlu olup olmadığını teknik rapor tek başına söyleyemez. Rapor kayıtların ne gösterdiğini yazar; kusur, kast ve sorumluluk hukuki değerlendirmedir.
Teknik rapor şablonu
Raporlarımız aşağıdaki iskeletle yazılır. Bölüm adları dosyadan dosyaya değişmez; karşı tarafın uzmanı da aradığını hep aynı yerde bulur.
Kapak Rapor no, sürüm, tarih · talep eden · hazırlayan (ad, soyad, imza) 1 Görev ve sorular Talep eden, amaç; sorular aynen 2 Kısa cevaplar Her soruya 1-3 cümle, bulgu numarasıyla (→ B-4, B-7) 3 Materyal ve bütünlük Dosya, kaynak, teslim tarihi, boyut, SHA-256 4 Saat referansı Kaynak başına: kayıt biçimi, dilim, ölçülen sapma, düzeltme 5 Yöntem Araç ve sürüm, ayarlar, dayanılan standartlar 6 Bulgular B-1, B-2 … her biri: kaynak dosya, satır veya kayıt kimliği 7 Kronoloji Özet tablo; tam tablo Ek-2'de 8 Değerlendirme Bulgunun soruyla ilişkisi, alternatif açıklamalar 9 Sınırlılıklar Eksik materyal, varsayımlar, cevaplanamayan sorular 10 Sonuç Sorular sırasıyla; hukuki nitelendirme yok 11 Kaynakça Mevzuat, standart, literatür (erişim tarihiyle) Ekler Ek-1 hash listesi · Ek-2 kronoloji (CSV) · Ek-3 ham çıktılar · Ek-4 şartname matrisi Sürüm geçmişi Taslak ile nihai sürüm arasındaki farklar
Üç bölüm çoğu raporda eksik kalır, biz özellikle önemseriz. Kısa cevaplar başa konur, çünkü karar verenlerin çoğu ilk iki sayfayı okur; her cevap bir bulgu numarasına bağlanır. Saat referansı tablosu, kronolojideki her satırın hangi dönüşümden geçtiğini gösterir. Sürüm geçmişi, taslakta yalnızca maddi hataların düzeltildiğini belgeler. Bölümlerin örnek satırları çalışma ilkelerimizde.
Hangi materyal gerekir?
- Cevaplanmasını istediğiniz sorular; bir cümle yeter, teknik biçime birlikte çeviririz.
- Kayıtların kendisi (log dışa aktarımları, imajlar,
.emldosyaları, veri tabanı yedekleri, operatör dökümleri), her birinin nereden ve nasıl alındığı, SHA-256 değeri. Değeri dosyayı yüklemeden hash hesaplama aracıyla hesaplayabilirsiniz. - Şartname işlerinde sözleşme, şartname, kabul kriterleri, teslim yazışmaları, hata kayıtları ve teslim edilen sürüm.