HTS Analizi: Adli Bilişim Perspektifinden Trafik, Cihaz, Zaman, Konum ve İlişki Verilerinin İncelenmesi

HTS Analizi: Adli Bilişim Perspektifinden Trafik, Cihaz, Zaman, Konum ve İlişki Verilerinin İncelenmesi

HTS/CDR verisini trafik, cihaz, zaman, baz, konum ve ilişki boyutlarında; veri bütünlüğü, belirsizlik, korelasyon, grafik analizi ve adli yorum sınırlarıyla birlikte ele alan teknik ders notu.

HTS/CDR verisi tek başına "kim, nerede, ne yaptı?" sorusuna kesin cevap veren bir kayıt değildir. Kaynağı, üretim biçimi, zaman ve konum belirsizliği, cihaz-hat ayrımı, iletişim grafiği ve hukuki bağlamı birlikte değerlendirilmesi gereken bir adli bilişim veri kümesidir.

1. Giriş

HTS analizi, yüzlerce veya milyonlarca satırlık telefon trafik kaydını Excel üzerinde filtrelemekten ibaret değildir. Asıl problem, elektronik haberleşme sisteminin farklı katmanlarında üretilmiş kayıtların hangi olayı temsil ettiğini, hangi olayı temsil etmediğini, birbirleriyle nasıl ilişkilendirilebileceğini ve bu ilişkiden ne ölçüde sonuç çıkarılabileceğini belirlemektir.

Adli bilişim uzmanı açısından temel ayrımlar şunlardır:

Kaynak kayıt ≠ yorum
Baz kaydı ≠ kesin konum
Abonelik ≠ fiilî kullanıcı
IMEI ≠ kişi
İletişim sayısı ≠ ilişkinin niteliği
Korelasyon ≠ nedensellik
Algoritmik aday ≠ adli sonuç

NIST dijital adli bilişimi; dijital verinin bütünlüğü korunarak tanımlanması, toplanması, incelenmesi ve analiz edilmesi, chain of custody, doğrulama, tekrarlanabilirlik ve raporlama ile birlikte ele alır. ISO/IEC 27037 potansiyel dijital delilin tanımlanması, toplanması, edinilmesi ve korunmasına; ISO/IEC 27042 ise analiz ve yorumun geçerlilik, yeniden üretilebilirlik ve tekrarlanabilirlik boyutlarına odaklanır.[1][2][3]

Benim adli bilişim yaklaşımımda HTS incelemesi dört katmana ayrılır:

ÖZGÜN KAYNAK
     ↓
DETERMİNİSTİK / İZLENEBİLİR DÖNÜŞÜM
     ↓
ALGORİTMİK ÇIKARIM / ADAY ÜRETİMİ
     ↓
UZMAN DEĞERLENDİRMESİ

Bir numaranın kaynak dosyadaki değeri birinci katmandadır. +90 5xx... ile 05xx... gösterimlerini aynı canonical numaraya dönüştürmek ikinci katmandadır. İki hattın iletişim kümelerinin Jaccard benzerliğini hesaplamak üçüncü katmandadır. Bunun soruşturma bağlamındaki anlamını değerlendirmek dördüncü katmandadır.

Bu katmanların birbirine karıştırılmaması HTS analizinin temel ilkesidir: verinin söylediğinden fazlasını söylememek; söylediği şeyi de kaybetmemek.


2. HTS, CDR ve trafik verisi

Türkiye'de uygulamada HTS ifadesi çoğunlukla Geçmiş Trafik Sorgulama kayıtlarını anlatır. Uluslararası teknik literatürde daha genel kavram Call Detail Record (CDR) ve trafik/charging kayıtlarıdır.

3GPP TS 32.298, Charging Data Record parametrelerini telekomünikasyon yönetimi ve ücretlendirme mimarisi içinde tanımlar; TS 32.297 CDR dosya biçimi ve aktarımıyla ilgilidir.[4][5] Adli makama gelen operatör çıktısı standardın bütün alanlarını içermek zorunda değildir. SWGDE, operatör kayıtlarının biçimlerinin farklılaşabildiğini; tarih-saat, kaynak/hedef numara, süre ve hücre/sektör gibi temel alanların ise yaygın olduğunu ve operatörün kayıt açıklama anahtarının yorum bakımından önemli olduğunu belirtir.[6]

Avrupa ePrivacy Direktifi trafik verisini iletişimin iletilmesi veya ücretlendirilmesi amacıyla işlenen veri olarak tanımlar. Yönlendirme, süre, zaman, hacim, protokol, terminal konumu ve bağlantının başlangıç/bitişi trafik verisinin parçaları olabilir. Konum verisi terminal cihazının coğrafi konumunu belirten şebeke verisidir.[7]

HTS esas olarak metadatadır. Çoğu durumda:

  • hangi numara,
  • hangi numarayla,
  • ne zaman,
  • hangi yönde,
  • ne kadar süre,
  • hangi cihaz kimliğiyle,
  • hangi hücre/baz bağlamında,
  • hangi iletişim türüyle

etkileşim kurmuştur sorularına veri sağlar. Konuşmanın veya mesajın içeriğini HTS kaydından çıkarmak ise başka bir iddiadır ve standart trafik kaydıyla karıştırılmamalıdır.


3. Temel varlıklar: kişi, hat, SIM ve cihaz aynı şey değildir

3.1 MSISDN

Telefon numarası analiz grafiğinin en görünür düğümüdür; fakat doğrudan kişi değildir. Hat başka biri tarafından kullanılabilir, kurumsal olabilir, aile içinde paylaşılabilir veya abonelik sahibi ile fiilî kullanıcı farklı olabilir.

Bu nedenle:

subscriber(number) = X
```ile
```text
user(number, t) = X

aynı önerme değildir.

3.2 IMSI

IMSI mobil aboneliği/SIM'i şebeke düzeyinde tanımlar. Telefon numarasıyla aynı kavram değildir. Numara, abonelik ve cihaz ilişkisi zaman içinde değişebilir.

3.3 IMEI

GSMA'ya göre IMEI 15 hanedir; ilk 8 hane TAC'tır ve cihazın üretici/model ailesini tanımlamak için kullanılır.[8]

Adli model:

KİŞİ → HAT/SIM → CİHAZ

üç ayrı varlık içerir.

Aynı IMEI'nin birden fazla numarayla görülmesi cihaz paylaşımı, SIM değişimi veya veri kalitesi problemi gibi farklı açıklamalara sahip olabilir. Aynı numaranın birden fazla IMEI ile görülmesi de cihaz değişimini gösterebilir.

Bu nedenle MSISDN ↔ IMEI ilişkisi zaman aralığı olan bir ilişki olarak tutulmalıdır.


4. Baz istasyonu: konum değil, şebeke gözlemidir

Baz/hücre verisi HTS analizinin en sık yanlış yorumlanan bölümüdür.

SWGDE Historical Cell Site Analysis rehberi, CDR'nin belirli tarih ve saatte cihaz tarafından kullanılan hücre/sektörü gösterebildiğini; fakat cihazın kesin fiziksel konumunu, belirli bir adresi veya kavşağı tek başına belirlemediğini açıkça vurgular.[6]

“Cell X kullanılmıştır.”
```ile
```text
“Cihaz Cell X'in koordinatındadır.”

aynı ifade değildir.

Hücre seçimini etkileyebilecek faktörler:

  • RF yayılımı,
  • anten azimutu ve sektör,
  • frekans,
  • arazi ve yapılaşma,
  • şebeke yükü,
  • optimizasyon,
  • handover,
  • cihaz/radyo koşulları.

RF saha ölçümü de geçmiş olay anını birebir yeniden üretmez; ölçüm anındaki RF ortamını örnekler.[6]


5. Hukuki çerçeve

HTS teknik veri olsa da ilk soru algoritmik değildir:

Veri hangi hukuki yetki ve süreçle elde edilmiştir?

Türkiye'de telekomünikasyon yoluyla iletişimin tespiti ve sinyal bilgilerinin değerlendirilmesinde CMK m.135 temel düzenlemelerden biridir. İletişimin tespiti, dinleme/kayda alma ve sinyal bilgisinin değerlendirilmesi aynı işlem değildir; somut tedbirin kapsamı ayrıca değerlendirilmelidir.[9][10]

Anayasa Mahkemesi HTS kayıtlarının temini ve teknik analizine ilişkin kararlarında verinin elde edilme yöntemi, güvenilirliği, teknik anlamlandırılması ve savunmanın itiraz imkânı gibi unsurları birlikte ele almıştır. AYM'nin aktardığı Yargıtay yaklaşımında kişiselleştirilmiş ve ayrıntılı HTS raporlarının önemi de vurgulanmaktadır.[11]

Elektronik haberleşme verileri kişisel veri ve haberleşmenin gizliliği bağlamındadır. BTK'nın açıklamalarında 5809 sayılı Kanun m.51 ve ilgili yönetmelik kapsamında amaçla bağlantılılık, sınırlılık, ölçülülük ve güvenlik ilkeleri vurgulanır.[12][13]

Teknik zincir:

Yetki kapsamı
   ↓
Edinilen veri kapsamı
   ↓
Teknik bütünlük
   ↓
Analiz
   ↓
Yorum
   ↓
Rapor

6. Delil yaşam döngüsü ve provenance

Kaynak dosya geldiğinde ilk işlem tabloyu filtrelemek olmamalıdır.

Kaydedilecek asgari metadata:

dosya adı
dosya boyutu
teslim zamanı
teslim eden / alan
dosya biçimi
resmî yazı / talep referansı
varsa sağlayıcı hash'i
hesaplanan hash
çalışma kopyası kimliği

SWGDE özgün elektronik kopyanın saklanmasını, çalışma kopyası kullanılmasını, hash ve chain-of-custody kayıtlarının korunmasını önerir.[6][14]

6.1 Hash

SHA-256(source.xlsx) = ...
SHA-256(working-copy.xlsx) = ...

Hash byte bütünlüğünü destekler. Dosyanın maddi içeriğinin doğru yorumlandığını kanıtlamaz.

6.2 Kaynak ve türev

source.xlsx
   ↓
normalized dataset
   ↓
deduplicated dataset
   ↓
analysis tables
   ↓
graph / timeline / map
   ↓
report

Her türev kaynağa geri izlenebilmelidir.


7. ETL: analizden önce veri mühendisliği

HTS analizinin en kritik fakat en görünmez kısmı Extract--Transform--Load sürecidir.

Dosya
 ↓
container / biçim doğrulama
 ↓
sheet ve başlık tanıma
 ↓
operatör/veri türü
 ↓
kolon eşleme
 ↓
satır ayrıştırma
 ↓
canonical veri

Farklı operatörlerin alan adları ve rapor biçimleri değişebildiğinden kaynak formatının açıklama anahtarı önemlidir.[6]

7.1 Canonical şema

record_id
source_file
source_row
target_msisdn
peer_msisdn
event_type
direction
event_time
duration_seconds
target_imei
peer_imei
cell_id
sector
lac_tac
cell_raw
latitude
longitude
province
district
ip_address
source_port
destination_port
subscriber_id
subscriber_name
operator

Temel kural:

Kaynak kolon kaybolmamalı; canonical değer kaynağa geri izlenebilmelidir.


8. Normalizasyon

8.1 Telefon numarası

05321234567
5321234567
905321234567
+905321234567

aynı numarayı temsil edebilir.

normalize_msisdn(x):
    trim
    remove formatting
    apply documented country rule
    validate
    return canonical

Ülke bağlamı bilinmeden varsayım yapılmamalıdır.

8.2 IMEI

IMEI matematiksel sayı değil kimliktir; string olarak korunmalıdır. Excel scientific notation riski vardır.

Kontroller:

yalnız rakam?
uzunluk?
Luhn?
TAC makul mü?
scientific notation bozulması var mı?

Başarısız kontrol kaydı silmek için değil, kalite bayrağı üretmek için kullanılmalıdır.

8.3 Tarih-saat

09.09.2026 14:05:01
2026-09-09 14:05:01
Excel serial date
09/09/26 14:05

tek timestamp modeline çevrilir.

Belgelenmesi gerekenler:

  • timezone,
  • saniye hassasiyeti,
  • timestamp'in başlangıç mı bitiş mi olduğu,
  • kaynak sistem semantiği.

8.4 Olay tipi

VOICE_OUT
VOICE_IN
SMS_OUT
SMS_IN
MISSED
GPRS_SESSION
WAP
OTHER

Operatör kodu doğrulanmadan anlam atanmamalıdır.


9. Duplicate ve tekilleştirme

Naif SELECT DISTINCT * her zaman doğru değildir.

Aynı olay hedef ve karşı sorgularında veya tekrar dışa aktarımlarda görünebilir. Bir kopyada ek baz alanı bulunabilir.

Aday anahtar:

target
peer
event_type
timestamp
duration
cell
imei

Akış:

ham veri
 ↓
duplicate candidate grouping
 ↓
alan bazlı karşılaştırma
 ↓
provenance koruma
 ↓
dedup görünüm

Ham ve dedup sonuçların ikisi de raporlanabilir.


10. Veri kalitesi analizi

Analize başlamadan:

N_total
N_invalid_time
N_empty_target
N_empty_peer
N_invalid_msisdn
N_invalid_imei
N_missing_cell
N_unresolved_cell
N_duplicate_candidate
N_unknown_event_type

ölçülmelidir.

q_{time}=1-frac{N_{invalid_time}}{N_{total}}
q_{cell}=frac{N_{resolved_cell}}{N_{cell_records}}

Eksik veri oranı bilinmeden "eşleşme yok" sonucu güçlü yorumlanamaz.


11. Genel iletişim profili

Bir hedef için:

toplam olay
arama / aranma
SMS gönderme / alma
cevapsız
toplam konuşma süresi
benzersiz karşı numara
benzersiz IMEI
benzersiz baz
aktif gün
ilk kayıt
son kayıt

çıkarılır.

Bu aşama bulgu üretmekten çok veri setinin ölçek ve karakterini anlamaktır.


12. İrtibat analizi

Her karşı numara için:

count_total
count_out
count_in
count_sms
duration_total
first_seen
last_seen
distinct_days
distinct_cells

hesaplanır.

C(u,v)=|{e:e=(u,v)}|
D(u,v)=sum_{e=(u,v)} duration(e)

İletişim sayısı veya süre ilişkinin niteliğini tek başına belirlemez.


13. Top-N, tek görüşme ve uzun görüşme

En çok görüşülen

GROUP BY peer
ORDER BY COUNT(*) DESC

Bir kez görüşülen

GROUP BY peer
HAVING COUNT(*) = 1

En uzun tekil görüşme

FILTER voice
FILTER duration > 0
ORDER BY duration DESC

maksimum tekil süre ile toplam ilişki süresi farklı metriklerdir.


14. İletişim yönü ve asimetri

O=giden,quad I=gelen
A=(|O-I|)/(O+I)

A → 0 dengeli, A → 1 daha tek yönlü trafik örüntüsüdür.

Bu yalnız iletişim yönü ölçüsüdür; ilişkinin sosyal/hukuki anlamı değildir.


15. Zaman analizi

Saatlik yoğunluk:

H(h)=sum_i1(hour(t_i)=h)

Günlük yoğunluk:

D(d)=sum_i1(date(t_i)=d)

Hafta içi/hafta sonu, gün ve saat profilleri çıkarılabilir. Sabit "gece = anormal" kabulü yerine kişinin kendi baseline'ı tercih edilmelidir.


16. Aktivite kesintisi

Sıralı zamanlar:

t_1<t_2<...<t_n
gap_i=t_{i+1}-t_i

gap_i ≥ T ise kesinti adayıdır.

sort by time
for adjacent events:
    gap = next - current
    if gap >= threshold:
        emit gap

Eşik, hattın normal kullanım sıklığıyla birlikte değerlendirilmelidir.


17. Olay öncesi ve sonrası

Olay zamanı t0:

W_before = [t0 - Δb, t0)
W_after = (t0, t0 + Δa]

Pencerelerde:

  • iletişim,
  • baz,
  • IMEI,
  • şehir,
  • karşı taraf

değişimleri karşılaştırılır.

Olay zamanına yakınlık nedensellik değildir.


18. İletişim grafiği

G=(V,E)

V: numaralar E: iletişim

Edge özellikleri:

count
duration
first_seen
last_seen
direction
distinct_days

Telekom literatüründe CDR üzerinden weighted graph, social-network similarity ve centrality ölçümleri yaygın biçimde kullanılmaktadır.[15]

Yüksek degree veya centrality, kişinin sosyal/hukuki rolünü otomatik belirlemez. Çağrı merkezleri doğal olarak yüksek degree üretebilir.


19. Ortak irtibat

P_A=contacts(A),quad P_B=contacts(B)
C=P_Acap P_B

Birden çok hedef:

C=bigcap_i P_i

Daha esnek model:

peer → kaç farklı hedefle iletişim kurdu?

Ortak irtibat yapısal bağlantıdır; ilişkinin niteliği ayrıca değerlendirilir.


20. Jaccard benzerliği

J(A,B)=(|Acap B|)/(|Acup B|)

Aynı yöntem:

contact_jaccard
cell_jaccard
district_jaccard

için kullanılabilir.

Jaccard bir benzerlik ölçüsü, kimlik kararı değildir.


21. Sosyal yakınlık

Özellik vektörü:

f1 = iletişim sayısı
f2 = toplam süre
f3 = farklı gün
f4 = gece iletişimi
f5 = karşılıklılık
f6 = güncellik
S(u,v)=sum_iw_i,norm(f_i)

Ağırlıklar gerekçelendirilmelidir. Skor, ilişkiyi sınıflandırmak yerine inceleme önceliği vermek için daha güvenli kullanılır.


22. Hedefler arası iletişim

Hedef kümesi T için:

u ∈ T AND v ∈ T

olan edge'ler seçilir.

Canonical pair:

(min(u,v), max(u,v))

ile iki yön tek ilişki altında gruplanabilir; yön ayrıca korunur.


23. IMEI analizi

23.1 Numara → IMEI

IMEI
first_seen
last_seen
event_count

23.2 IMEI → numara

IMEI → {MSISDN1, MSISDN2, ...}

23.3 Ortak IMEI

|Users(imei)|ge2

ise ortak cihaz adayı vardır.

Fakat zaman ayrımı kritiktir:

eşzamanlı kullanım
ardışık kullanım

aynı anlamı taşımaz.

23.4 IMEI timeline

t1 A → IMEI-X
t2 A → IMEI-Y
t3 B → IMEI-X

aggregate tablodan daha açıklayıcı olabilir.


24. Olası aynı kullanıcı / Multi-SIM

Telekom araştırmalarında aynı kullanıcının birden fazla SIM'ini tahmin etmek için sosyal ağ ve davranış benzerliği ölçümleri kullanılmaktadır.[15]

Özellikler:

shared_imei
contact_jaccard
cell_jaccard
district_jaccard
temporal_complementarity
same-time contradiction

Açıklanabilir model:

S=w_1I_{imei}+w_2J_{contact}+w_3J_{cell}+w_4J_{district}-w_5C_{contradiction}

Çıktı:

aynı kullanıcı hipotezi bakımından incelenecek aday hat çifti

olmalıdır; "aynı kişidir" hükmü değil.


25. Sahiplik belirsizliği ve "patates hat" kavramı

"Patates hat" teknik veya hukuki standart terim değildir. Uygulamada abonelik sahibi ile fiilî kullanıcı arasında güvenilir bağ kurulamadığı veya kimlik/kullanım örüntüsünün sahipliği sorgulattığı hatlar için argo biçimde kullanılabilir.

Olası sinyaller:

kimlik alanı eksik/tutarsız
isim var, güvenilir kimlik yok
çok sık cihaz/SIM değişimi
çok sayıda hatla ortak IMEI
çok kısa yaşam döngüsü
olay çevresinde açılma/kapanma
çok dar irtibat kümesi
tek yönlü/düşük hacimli kullanım

Hiçbiri tek başına yeterli değildir.

R=w_1IdentityRisk+w_2DeviceSharing+w_3EphemeralUse+w_4NetworkPattern

Bu bir ranking score olabilir; delil puanı değildir.


26. Baz analizi

Her baz için:

count
first_seen
last_seen
distinct_days
province
district
coordinate

hesaplanır.

Mümkünse teknik anahtar:

operator + LAC/TAC + Cell ID/ECGI + sector

kullanılır. Sadece adres metni kırılgandır.


27. Haversine mesafesi

İki koordinat için:

a=sin^2(Deltavarphi/2)+cosvarphi_1cosvarphi_2sin^2(Deltalambda/2)
d=2Rarcsin(sqrt a)

Bu iki baz koordinatı arasındaki geometrik mesafedir; cihazların gerçek uzaklığı veya RF kapsama mesafesi değildir.


28. Ortak baz analizi

İki hedef:

A={(t,cell)}
B={(t,cell)}

Temporal koşul:

|t_A-t_B|leDelta t

Spatial koşul:

same_cell

veya:

distance(cell_A,cell_B)le R

olabilir.

Two-pointer

i = j = 0
while i < len(A) and j < len(B):
    dt = A[i].time - B[j].time
    if abs(dt) <= tolerance:
        evaluate spatial match
    elif dt < 0:
        i += 1
    else:
        j += 1

Çoklu hedef

PARTITION BY cell
ORDER BY time
SLIDING WINDOW Δt
EMIT distinct user pairs
AGGREGATE

Bu yaklaşım tüm kullanıcı çiftlerini naif biçimde karşılaştırmaktan daha ölçeklenebilirdir.


29. "Aynı baz"ın seviyeleri

1. aynı Cell ID / sektör
2. aynı fiziksel site, farklı sektör
3. yakın fiziksel siteler

aynı şey değildir.

Raporda "aynı baz"ın teknik tanımı açıkça yazılmalıdır.


30. Görüşme anı baz

Çağrı A → B, t0.

Hedef baz doğrudan kayıtlı olabilir. Karşı taraf için ayrı kayıt gerekiyorsa:

candidate=argmin|t_B-t_0|

ve:

|t_B-t_0|leDelta t

aranmalıdır.

"En yakın kayıt" ile "aynı anda kayıt" aynı değildir.


31. Şehir değişimi

Zaman dizisi:

Ankara
Ankara
Bolu
Bolu
İstanbul

sıkıştırılır:

Ankara → Bolu → İstanbul

Her transition:

from
to
last_seen_from
first_seen_to
Δt
distance

ile tutulabilir.


32. Rota ve hareket

HTS'den GPS rotası çıkarılmaz. Üretilen şey zaman sıralı hücre kullanım izidir:

(t1,cell1)
(t2,cell2)
...

Görünür hız:

v=frac{distance(cell_i,cell_{i+1})}{t_{i+1}-t_i}

çok yüksekse veri hatası, hücre oscillation, saat farkı veya şebeke davranışı araştırılmalıdır.

CDR tabanlı hareket araştırmaları konum belirsizliği ve hücre oscillation'ının işlenmemesinin hareket düzenliliğini olduğundan yüksek gösterebildiğini ortaya koymaktadır.[16]


33. Yaşam rutini

Özellikler:

hour_of_day
weekday/weekend
cell
distinct_days
event_count

Örnek:

gece → Cell A → 24 farklı gün
mesai → Cell B → 19 farklı hafta içi gün

Doğru yorum:

Cell A gece zaman diliminde tekrarlanan dominant hücredir.

Yanlış kesinlik:

Cell A kişinin evidir.


34. Olay yeri ve kritik nokta yakınlığı

Olay yeri P0:

d_i=distance(P_i,P_0)

d_i ≤ R ise hücre sitesi coğrafi adaydır.

Bu hücre sitesi yakınlığıdır, cihazın olay yerinde olduğunun ölçümü değildir.

POI analizi de:

havalimanı
otogar
otel
hastane
sınır kapısı
özel nokta

gibi kümelerle metinsel veya coğrafi yapılabilir.


35. "Şahıs o an nerede?" sorusunun teknik karşılığı

Doğru algoritma:

candidates =
    records where |event_time - t0| <= tolerance

nearest =
    argmin |event_time - t0|

Çıktı:

t0
en yakın kayıt zamanı
Δt
cell/sector
coordinate

Doğru cümle:

t0 zamanına en yakın HTS kaydı X hücresidir.

SWGDE'nin kesin konum uyarısı burada özellikle geçerlidir.[6]


36. Konferans görüşmesi adayları

Açık session ID yoksa çağrılar interval olarak modellenebilir:

I(c) = [start, start + duration]

Sweep-line:

call start/end events oluştur
time'a göre sırala
active call set tut
eşzamanlı ilgili call sayısı eşiği aşarsa candidate üret

Bu yalnız zaman çakışmasıdır; operatör semantiği doğrulanmadan kesin konferans sonucu değildir.


37. Anomali tespiti

Anomali "normal modele göre beklenmeyen" demektir; "suç" demek değildir.

37.1 Z-score

z=(x-mu)/(sigma)

37.2 Robust MAD

MAD=median(|x_i-median(x)|)
z_r=0.6745(x-median(x))/(MAD)

37.3 Örnek anomaly feature'ları

beklenmeyen saat
ani günlük yoğunluk
yeni baz
yeni IMEI
uzun sessizlik
olağandışı şehir geçişi

CDR trafik anomalilerinde zaman serisi, clustering ve tahmin yöntemleri akademik literatürde kullanılmaktadır.[17]

anomaly ≠ malicious
anomaly ≠ criminal
anomaly ≠ intentional

38. GPRS, IP ve CGNAT

Mobil internet analizinde yalnız public IP çoğu zaman yeterli değildir.

CGNAT bağlamında:

public_ip
source_port
timestamp
subscriber/private context

birlikte değerlendirilir.

AYM/AİHM dosyalarında CGNAT, HTS, IMEI ve diğer teknik verilerin birlikte değerlendirildiği örnekler bulunmaktadır.[18]

IP geolocation:

IP → kesin fiziksel adres

değildir.

ASN/ISP, tahsis ve coğrafi tahmin farklı bilgi katmanlarıdır.


39. Abonelik sahibi ile fiilî kullanıcı

Abonelik:

subscriber(number)=X

gösterebilir.

Fiilî kullanıcı:

user(number,t)=X

için ek korelasyon gerekir.

Sinyaller:

  • cihaz ilişkisi,
  • uzun dönem kullanım,
  • rutin,
  • doğrulanmış diğer hatlarla ilişki,
  • cihaz adli incelemesi,
  • başka dijital artefact,
  • tanık/ifade.

SWGDE CDR'nin cihazı kullanan kişiyi kesin olarak göstermediğini belirtir.[6]


40. Kaynak--türev--yorum ayrımı

Katman Örnek --------------------- ----------------------------------------- Kaynak 14:05'te Cell X kaydı Deterministik türev Cell X--olay yeri mesafesi 1,8 km Algoritmik çıkarım olay yeri yakınlık adayı Uzman yorumu diğer bulgularla birlikte değerlendirme

Algoritma yorum yerine geçmemelidir.


41. False positive ve false negative

False Positive:
algoritma işaretledi, bağlamda anlamlı değil

False Negative:
anlamlı örüntü var, algoritma işaretlemedi

Ortak bazda şehir merkezi yoğunluğu false-positive, seyrek kayıt false-negative riskini artırabilir.

Sonuç ekranı eşleşmeyle birlikte veri kapsamını göstermelidir.


42. Güven skoru

Açıklanabilir örnek:

Confidence=TemporalQualitytimes SpatialQualitytimes DataCompleteness

Zaman:

T=e^{-|Delta t|/tau}

Spatial sınıf:

aynı sektör
aynı site
yakın site

Bu değerler ancak tanımlanmış metodolojinin ranking parametreleridir; evrensel delil ağırlığı değildir.


43. Büyük veri ve performans

Milyonlarca kayıt için veri mimarisi algoritma kadar önemlidir.

İndeksler:

(target,event_time)
(peer,event_time)
(imei,event_time)
(cell,event_time)
(event_time)

Ön hesap:

contact_stats
imei_usage
cell_usage
daily_activity
hour_profile

Columnar storage, vectorized execution, predicate pushdown ve projection büyük CDR kümelerinde gereksiz veri taşınmasını azaltır.

Temel ilke:

Hesaplamayı verinin bulunduğu yerde yap; gereksiz veriyi taşıma.


44. Graph centrality ve community detection

Degree, weighted degree, betweenness veya PageRank benzeri ölçüler graph yapısındaki önemi ölçebilir.

yüksek centrality ≠ hukuki/sosyal liderlik

Louvain/Leiden gibi community detection algoritmaları yoğun bağlantı kümeleri üretebilir. Çıktı yalnız graph topluluğudur; aile, işyeri, servis veya başka bir bağlam olabilir.

Adli kullanım:

candidate cluster → contextual/manual review

45. Makine öğrenmesi

Uygun alanlar:

  • anomaly ranking,
  • entity resolution,
  • graph embedding,
  • davranış kümeleme,
  • kalite sınıflandırması.

Ancak:

model prediction ≠ source observation

Adli sistemde explainable-first yaklaşım çoğu durumda avantajlıdır:

SQL
set intersection
Jaccard
Haversine
sliding window
simple statistics

ISO/IEC 27042'nin yeniden üretilebilirlik ve bağımsız inceleme ilkeleri bu yaklaşımı destekler.[2]


46. Doğrulama ve teknik review

SWGDE historical cell-site analizinde sonuçların örnek veri üzerinde manuel haritalama veya farklı metodoloji kullanan araçla doğrulanabilmesini ve teknik review yapılmasını önerir.[6]

Genel HTS doğrulama akışı:

1. algoritmik sonuç üret
2. örneklem seç
3. kaynak satıra dön
4. elle yeniden hesapla
5. alternatif yöntemle karşılaştır
6. tutarsızlığı incele

47. Reproducibility paketi

source_hashes.json
analysis_config.json
normalization_rules.md
software_version.txt
queries/
derived/
report/

Örnek parametre:

{
  "time_tolerance_seconds": 120,
  "distance_radius_meters": 1000,
  "analysis_mode": "deduplicated",
  "timezone": "Europe/Istanbul"
}

Parametre sonucu etkiliyorsa raporda görünmelidir.


48. Raporlama dili

Kötü:

Şahıs olay yerindedir.

Daha doğru:

Olay zamanına yakın zaman diliminde hedef hat için X hücresinin kullanıldığı görülmüştür. Hücre kaydı cihazın kesin fiziksel konumunu tek başına göstermediğinden bulgu diğer konum ve soruşturma verileriyle birlikte değerlendirilmelidir.

Kötü:

İki şahıs birlikte hareket etmiştir.

Daha doğru:

İki hatta ait kayıtlarda belirtilen zaman toleransı içinde aynı hücre/sektör eşleşmeleri tespit edilmiştir. Bu teknik korelasyon cihaz kullanıcılarının kimliğini ve fiziksel birlikteliğini tek başına belirlemez.


49. Raporun minimum içeriği

1. İnceleme görevi
2. Teslim edilen materyal
3. Hash / bütünlük
4. Veri kaynağı ve kapsam
5. Araç ve sürüm
6. Normalizasyon
7. Ham/dedup modu
8. Parametre/eşikler
9. Bulgular
10. Kaynak satır referansları
11. Harita/grafik açıklamaları
12. Sınırlılıklar
13. Sonuç

50. Harita ve RF sunumu

Haritada:

  • ölçek,
  • kuzey,
  • koordinat sistemi,
  • baz/sektör,
  • zaman,
  • tolerans,
  • sembol anlamı

görünmelidir.

Bir hücreyi sabit yarıçaplı daireyle çizmek gerçek RF kapsamasının o daire olduğu anlamına gelmez.

HTS geçmiş şebeke kaydıdır; RF survey belirli zamanda yapılan saha ölçümüdür. Aynı şey değildir.[6]


51. Çoklu veri korelasyonu

HTS şu kaynaklarla birlikte değerlendirilebilir:

mobil cihaz adli imajı
SIM artefact
uygulama kayıtları
CGNAT
kamera
araç verisi
erişim kontrol logları
tanık/ifade

NIST SP 800-101 mobil cihaz adli bilişimini cihaz üzerindeki dijital delilin forensically sound edinimi ve incelenmesi olarak ele alır.[19]

Cihaz forensics → endpoint artefact
HTS/CDR          → network/operator artefact

Çelişki varsa biri otomatik olarak yok sayılmamalıdır.


52. Hipotez ve karşı hipotez

Örnek:

H1: Hat A ve B aynı kullanıcı tarafından dönüşümlü kullanılmış olabilir.

Test:

ortak IMEI?
contact Jaccard?
baz rutini?
aynı anda uzak konum çelişkisi?
abonelik?
cihaz artefact'ı?

Karşı hipotez:

H0: Hatlar farklı kullanıcılarındır; benzerlik ortak sosyal/iş çevresinden kaynaklanmaktadır.

İyi analiz yalnız destekleyen bulguyu değil çelişkiyi de arar.


53. Veri minimizasyonu ve güvenlik

HTS kayıtları ilgisiz kişilere ait veriler de içerebilir.

Sistem:

  • role-based access,
  • audit,
  • proje izolasyonu,
  • export kontrolü,
  • amaçla sınırlı işleme,
  • retention

uygulamalıdır.

BTK/KVKK çerçevesindeki amaçla bağlantılı, sınırlı ve ölçülü işleme ilkeleri bu noktada önemlidir.[12][13]


54. Uçtan uca HTS algoritması

INPUT:
    source files
    legal scope
    event context

1. PRESERVE
    hash originals
    create working copies
    record provenance

2. DETECT
    identify provider/file type
    validate workbook structure

3. PARSE
    map source columns
    preserve source row identity

4. NORMALIZE
    MSISDN
    IMEI
    timestamp
    event type
    cell

5. VALIDATE
    missing/invalid/outlier fields
    duplicate candidates

6. ENRICH
    subscriber
    TAC
    cell coordinates
    province/district

7. BASELINE
    counts
    active days
    quality metrics

8. SINGLE-TARGET
    contacts
    time
    device
    cell
    route/routine

9. MULTI-TARGET
    common contacts
    common IMEI
    common cells
    internal graph

10. EVENT-CENTRIC
    before/after
    location proximity
    temporal windows

11. CANDIDATE GENERATION
    anomaly
    possible same user
    ownership uncertainty
    social proximity

12. VERIFY
    source sampling
    alternate method
    technical review

13. REPORT
    observation
    deterministic derivation
    algorithmic candidate
    expert interpretation
    limitations

55. Sentetik örnek vaka

Hat A: 05xx...101
Hat B: 05xx...102
Hat C: 05xx...103
Olay: 28.08.2026 21:30
Yer: P0

Kayıtlar:

A → Cell X, 21:17
B → Cell X, 21:19
C → Cell Y, 21:21

A ve B ortak IMEI-X'i farklı günlerde kullanmış.
A ve B contact Jaccard = 0.68
A ve B cell Jaccard = 0.54

Yanlış:

A ve B olay yerindeydi ve aynı kişidir.

Teknik değerlendirme:

  1. A ve B'nin aynı hücreyi yakın zamanlarda kullanması temporal-spatial

korelasyondur.

  1. Cell X'in olay yerine mesafesi ayrıca ölçülmelidir.
  2. Hücre kullanımı kesin cihaz konumu değildir.
  3. Ortak IMEI cihaz ilişkisidir.
  4. Jaccard davranış benzerliğidir.
  5. Aynı kullanıcı hipotezine karşı aynı anda farklı yerlerde kullanım

aranmalıdır.

  1. Sonuç diğer delillerle değerlendirilmelidir.

Daha az iddialı ifade daha zayıf değildir; daha denetlenebilir olduğu için daha güçlüdür.


56. Sık yapılan hatalar

  1. Baz kaydını GPS sanmak.
  2. Abonelik sahibini otomatik fiilî kullanıcı kabul etmek.
  3. Ortak IMEI'yi aynı kişi kararı saymak.
  4. Çok görüşmeyi ilişkinin niteliği saymak.
  5. Ortak irtibatı doğrudan örgütsel bağ saymak.
  6. Algoritmik skoru delil puanı sanmak.
  7. Dedup sırasında provenance kaybetmek.
  8. Haritayı ölçümden daha kesin göstermek.
  9. Yalnız hipotezi destekleyen bulguyu raporlamak.
  10. Δt, R ve threshold gibi parametreleri gizlemek.
  11. Eksik veri oranını hesaba katmamak.
  12. Kaynak gözlem ile model/uzman yorumunu aynı cümlede eritmek.

57. Uzman kontrol listesi

Kaynak

  • [ ] Özgün dosya korundu mu?
  • [ ] Hash alındı mı?
  • [ ] Chain of custody kayıtlı mı?
  • [ ] Sağlayıcı ve format belli mi?

Normalizasyon

  • [ ] MSISDN kuralları belgeli mi?
  • [ ] IMEI identifier olarak korunuyor mu?
  • [ ] Timestamp semantiği belli mi?
  • [ ] Event mapping doğrulandı mı?
  • [ ] Baz anahtarı teknik olarak doğru mu?

Analiz

  • [ ] Ham/dedup ayrımı belli mi?
  • [ ] Zaman toleransı raporlu mu?
  • [ ] Mesafe eşiği raporlu mu?
  • [ ] Eksik veri oranı biliniyor mu?
  • [ ] Karşı hipotez test edildi mi?

Rapor

  • [ ] Kaynak gözlem ile yorum ayrıldı mı?
  • [ ] Harita sınırlılığı yazıldı mı?
  • [ ] Algoritma açıklanabilir mi?
  • [ ] Sonuç kaynak satıra geri izlenebilir mi?
  • [ ] Teknik review yapılabilir mi?

58. Sade ve kanıta dayalı yaklaşım

HTS analizinde amaç daha az analiz yapmak değildir. Gereksiz iddiayı azaltıp kanıt zincirini güçlendirmektir.

Az varsayım.
Açık veri.
Açık dönüşüm.
Açık parametre.
Açık hata sınırı.
Tekrarlanabilir sonuç.

İyi bir sistem yüzlerce grafik üretebilir. İyi bir adli bilişim uzmanı hangi grafiğin sorulan teknik soruya cevap verdiğini bilir.

Bir milyon satır içinde önemli olan her satırı göstermek değil, sonucu üreten zinciri gösterebilmektir.


59. Sonuç

HTS kaydı tek başına bir hikâye değildir. Şebekenin belirli olaylar sırasında ürettiği teknik izlerin zaman, cihaz, hat ve hücre ekseninde tutulmuş bir bölümüdür.

Adli bilişim uzmanının görevi bu izleri önceden kurulmuş bir anlatıya zorlamak değil, şu zinciri korumaktır:

Kaynak
 ↓
Bütünlük
 ↓
Normalizasyon
 ↓
Doğrulama
 ↓
Korelasyon
 ↓
Algoritmik aday
 ↓
Karşı hipotez
 ↓
Uzman yorumu
 ↓
Sınırlılık

Bir kayıt bir hücrenin kullanıldığını söyleyebilir; kesin adresi söylemeyebilir. Bir IMEI iki hattı bağlayabilir; iki kişinin aynı kişi olduğunu söylemeyebilir. Graph ortak irtibatı gösterebilir; ilişkinin hukuki niteliğini belirleyemez. Anomali alışılmadık davranışı gösterebilir; suç kastını göstermez.

Bu nedenle iyi HTS analizi daha çok kesin hüküm üreten analiz değildir. Kaynağa geri dönebilen, algoritması açıklanabilen, parametreleri görülebilen, alternatif açıklamaları sınayan ve sonucunun sınırlarını açıkça söyleyen analizdir.

Adli bilişimde teknik yeterlilik yalnız veriden sonuç çıkarmak değildir; hangi sonucun veriden çıkarılamayacağını da bilmektir.


Kaynakça

  1. NIST, Digital Forensics -- Glossary.

https://csrc.nist.gov/glossary/term/digital_forensics

  1. ISO/IEC 27042:2015, *Guidelines for the analysis and interpretation

of digital evidence*. https://www.iso.org/standard/44406.html

  1. ISO/IEC 27037:2012, *Guidelines for identification, collection,

acquisition and preservation of digital evidence*. https://www.iso.org/standard/44381.html

  1. 3GPP TS 32.298, Charging Data Record parameter description.

https://portal.3gpp.org/

  1. 3GPP TS 32.297, Charging Data Record file format and transfer.

https://portal.3gpp.org/

  1. SWGDE, *Recommendations / Best Practices for Historical Cell Site

Analysis*. https://www.swgde.org/documents/published-complete-listing/17-f-001-recommendations-for-historical-cell-site-analysis/

  1. European Parliament and Council, Directive 2002/58/EC.

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32002L0058

  1. GSMA Open Gateway, Device Identifier / IMEI and TAC.

https://open-gateway.gsma.com/docs/device-identifier/api-reference

  1. 5271 sayılı Ceza Muhakemesi Kanunu, m.135.
  2. T.C. Adalet Bakanlığı, Ceza Muhakemesi Hukuku eğitim materyali.

https://edb.adalet.gov.tr/

  1. T.C. Anayasa Mahkemesi, *Telekomünikasyon Yoluyla Yapılan İletişimin

Tespitine İlişkin Kayıtların Elde Edilme Yöntemi İtibarıyla Adil Yargılanma Hakkının İhlal Edilmediği*. https://anayasa.gov.tr/

  1. Bilgi Teknolojileri ve İletişim Kurumu, *Kişisel Verilerin

Korunması*. https://tuketici.btk.gov.tr/kisisel-verilerin-korunmasi

  1. BTK, *Elektronik Haberleşme Sektöründe Kişisel Verilerin İşlenmesi

ve Gizliliğin Korunmasına İlişkin Yönetmelik*. https://btk.gov.tr/yonetmelikler

  1. SWGDE, Best Practices for Digital Evidence Collection.

https://www.swgde.org/documents/published-complete-listing/18-f-002-2-0/

  1. Springer, Social network analysis in Telecom data, Journal of Big

Data. https://link.springer.com/article/10.1186/s40537-019-0264-6

  1. *On data processing required to derive mobility patterns from

passively-generated mobile phone data*. https://pmc.ncbi.nlm.nih.gov/articles/PMC5789780/

  1. Mokhtari et al., *Aggregated Traffic Anomaly Detection Using Time

Series Forecasting on Call Detail Records*. https://onlinelibrary.wiley.com/doi/10.1155/2022/1182315

  1. European Court of Human Rights / HUDOC, telecommunications metadata,

CGNAT, IMEI and HTS case materials. https://hudoc.echr.coe.int/

  1. NIST SP 800-101 Rev.1, Guidelines on Mobile Device Forensics.

https://csrc.nist.gov/pubs/sp/800/101/r1/final

  1. NIST/OSAC, SWGDE Recommendations for Cell Site Analysis.

https://www.nist.gov/osac/standards-library/swgde-17-f-001-20

  1. NIST, Evidence Management.

https://www.nist.gov/forensic-science/interdisciplinary-topics/evidence-management

  1. 3GPP TS 23.003, Numbering, addressing and identification.

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729

  1. KVKK, konum verisinin işlenmesine ilişkin kamuoyu duyurusu.

https://www.kvkk.gov.tr/Icerik/6726/

  1. RFC 5737, IPv4 Address Blocks Reserved for Documentation.

https://www.rfc-editor.org/rfc/rfc5737.html

  1. ScienceDirect, *Development of multiple mobile networks call

detailed records and its forensic analysis*. https://www.sciencedirect.com/science/article/pii/S235286481830124X

  1. PLOS One, *Temporal social network modeling of mobile connectivity

data with graph neural networks*. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0335267


HTS/CDR verisinin hukuki nitelendirmesi somut olay, güncel mevzuat ve yargı kararları çerçevesinde ayrıca değerlendirilmelidir.

Bu sayfanın QR kodu