Security Center:Praktik terbaik untuk mendeteksi login dari akun tidak aktif

Definisikan aktivitas terbaru

(
  select
    user_id,
    src_ip,
    username,
    uuid,
    start_time
  from
    log
  where
    cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 20 * 60
    and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint)
) a

• Analisis sintaks:

  • from log: Mengkueri data dari tabel log.

  • to_unixtime(current_timestamp): Mengembalikan Unix timestamp saat ini dalam satuan detik.

  • cast(... as bigint): Mengonversi timestamp ke tipe data bigint (bilangan bulat panjang) untuk operasi matematika dan perbandingan.

  • where ...: Menentukan jendela waktu geser selama 20 menit yang berakhir pada waktu saat ini.

    • >= ... - 20 * 60: Waktu mulai log (start_time) harus lebih besar atau sama dengan "waktu saat ini – 20 menit".

    • < ...: Waktu mulai log harus kurang dari "waktu saat ini".

• Analisis semantik:

  • Tujuan: Mendefinisikan set bernama a untuk "aktivitas terbaru" guna membatasi objek analisis utama.

  • Hasil: Set hasil sementara berisi pengguna yang aktif dalam 20 menit terakhir, seperti user_id dan src_ip.

  • Poin penting: Periode "terbaru" didefinisikan secara tepat sebagai jendela waktu 20 menit yang dihitung mundur dari waktu saat ini.

Definisikan garis dasar historis

(
  select
    user_id,
    username,
    uuid
  from
    log
  where
    schema='HOST_LOGIN_ACTIVITY' and
    cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 24 * 3600
    and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint) - 20 * 60
) b

• Analisis sintaks:

  • schema='HOST_LOGIN_ACTIVITY': Hanya mengkueri log aktivitas login host, sehingga garis dasar historis menjadi lebih akurat.

  • where ...: Menentukan rentang waktu dari 24 jam lalu hingga 20 menit lalu.

    • >= ... - 24 * 3600: Waktu mulai log harus lebih besar atau sama dengan "waktu saat ini – 24 jam".

    • < ... - 20 * 60: Waktu mulai log harus kurang dari "waktu saat ini – 20 menit".

• Analisis semantik:

  • Tujuan: Membangun set "garis dasar historis" bernama b sebagai referensi untuk menentukan apakah suatu aktivitas bersifat abnormal.

  • Hasil: Set hasil sementara berisi pengguna yang pernah login dalam sehari terakhir, mengecualikan 20 menit terakhir.

  • Poin penting: Jendela waktu ini ditetapkan dari 24 jam lalu hingga 20 menit lalu. Hal ini memastikan bahwa data garis dasar historis tidak tumpang tindih dengan data aktivitas terbaru, sehingga mencegah kesalahan logika akibat perbandingan diri sendiri.

Gunakan LEFT JOIN untuk perbandingan selisih

... a
left join
... b on a.username = b.username and a.uuid = b.uuid and a.user_id = b.user_id

• Analisis sintaks:

  • LEFT JOIN: Menggunakan Tabel Kiri (a, pengguna terbaru) sebagai basis dan mencocokkan setiap record-nya dengan record di Tabel Kanan (b, pengguna historis).

  • on a.username = b.username and a.uuid = b.uuid and a.user_id=b.user_id: Menentukan kondisi join. Field username, uuid, dan user_id digunakan bersama untuk mengidentifikasi entitas pengguna secara unik, memastikan pencocokan yang akurat.

• Analisis semantik:

  • Tujuan: Menghubungkan "aktivitas terbaru" (a) dengan "garis dasar historis" (b) untuk menemukan catatan login historis yang sesuai untuk setiap aktivitas pengguna terbaru.

  • Hasil: Menghasilkan set hasil gabungan yang mencakup semua record dari tabel a dan record dari tabel b yang berhasil dicocokkan berdasarkan field identitas pengguna.

  • Poin penting: Kueri ini memanfaatkan sifat asimetris dari LEFT JOIN: jika pengguna dari tabel a tidak ada di tabel b, semua kolom dari tabel b akan bernilai NULL dalam hasilnya. Inilah mekanisme inti untuk mengidentifikasi aktivitas baru.

Filter hasil akhir

where
  (
    b.username is null
    or b.username = ''
  )

• Analisis sintaks:

  • b.username is null: Ini adalah kunci pemanfaatan karakteristik LEFT JOIN. Ketika pengguna yang baru saja login (di tabel a) tidak ditemukan dalam garis dasar historis (tabel b), b.username akan bernilai NULL.

  • or b.username = '': Ini adalah kondisi defensif untuk menangani kasus di mana field log mungkin berupa string kosong '' alih-alih NULL.

• Analisis semantik:

  • Tujuan: Untuk memfilter hasil join, mengisolasi aktivitas yang muncul baru-baru ini tetapi tidak memiliki catatan historis.

  • Hasil: Setelah filter ini diterapkan, set hasil hanya berisi record yang gagal dicocokkan dalam LEFT JOIN—yaitu event abnormal yang Anda cari.

  • Poin penting: b.username is null adalah titik keputusan inti dari seluruh logika deteksi. Nilai NULL yang dihasilkan pada langkah sebelumnya digunakan untuk memisahkan record "ada di data terbaru, tidak ada di data historis" dari dataset yang besar.

SELECT DISTINCT: Output peringatan

select distinct
     a.user_id,
     a.src_ip,
     a.username,
     a.uuid

• Analisis sintaks:

  • SELECT DISTINCT: Memilih dan mengeluarkan field yang ditentukan, serta menghapus duplikat dari hasilnya. Ini memastikan hanya satu peringatan yang dihasilkan untuk satu event abnormal.

• Analisis semantik:

  • Tujuan: Untuk memformat dan mengeluarkan daftar akhir event abnormal yang dapat langsung digunakan untuk peringatan.

  • Hasil: Daftar peringatan yang bersih dan telah dihapus duplikatnya. Setiap record berisi informasi inti yang diperlukan untuk melacak event abnormal, seperti ID pengguna dan IP Sumber.

  • Poin penting: Penggunaan DISTINCT sangat penting. Ini menghapus duplikat hasil agar perilaku abnormal yang sama dari pengguna yang sama dalam jendela deteksi (20 menit) hanya memicu satu peringatan.

Kueri SQL akhir

*|set session mode=scan;
select distinct
     a.user_id,
     a.src_ip,
     a.username,
     a.uuid
   from
     (
       select
         user_id,
         src_ip,
         username,
         uuid,
         start_time
       from
         log
       where
         cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) -20 * 60
         and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint)
     ) a
     left join (
       select
         user_id,
         username,
         uuid
       from
         log
       where
         schema='HOST_LOGIN_ACTIVITY' and
         cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 24 * 3600
         and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint) -20 * 60
     ) b on a.username = b.username
     and a.uuid = b.uuid
     and a.user_id=b.user_id
   where
     (
       b.username is null
       or b.username = ''
     )

Konfigurasikan aturan di Agentic SOC

1. Beli dan aktifkan Agentic SOC

   Lihat Purchase and enable untuk opsi pembelian. Untuk mengakses semua layanan deteksi ancaman kustom, kami merekomendasikan pembelian Log Ingestion Traffic dan Log Storage Capacity.

2. Masuk ke Konsol dan buka halaman Create Custom Rule.

   1. Login ke .

   2. Di panel navigasi kiri, pilih Agentic SOC > Detection Rules. Di pojok kiri atas Konsol, pilih Wilayah tempat aset Anda berada: Chinese Mainland atau Outside Chinese Mainland.

   3. Di tab Custom, klik Create Custom Rule.

3. Konfigurasikan aturan pembuatan peringatan

   1. Di panel Create Custom Rule, pada tab Basic Information, masukkan nama dan deskripsi aturan, lalu klik Next untuk menuju halaman Alert Settings.

   2. Konfigurasikan aturan deteksi SQL. Lihat pengaturan parameter berikut:

      Parameter	Nilai
      Rule Body	SQL
      Log Scope	Logon Logs - Host Logon Success Log.
      SQL Query	Salin kode dari bagian Final SQL query.
      Scheduling Interval	Fixed Interval - 20 minutes.
      SQL Time Window	24 hours.
      Start Time	When the rule is enabled.
      Generation Structure	Other Alert Logs.
      Alarm Metric	Abnormal Logon.
      Alert Severity	Medium.
      ATT&CK Tactic	Persistence - T1136 Create Account.
      Entity Mapping	Network Address is_malware: 1 ip: $src_ip net_connect_dir: in Host is_asset: 1 uuid: $uuid

4. Konfigurasikan aturan pembuatan insiden

   1. Di halaman Alert Settings, setelah konfigurasi selesai, klik Next untuk menuju halaman Incident Generation Settings.

   2. Konfigurasikan aturan waktu. Lihat pengaturan parameter berikut:

      • Generate Event: Yes.

      • Incident Generation Method: Aggregate by type.

      • Aggregation Window: 20 minutes.

5. Validasi aturan

   Aturan baru secara default berstatus Disabled. Anda dapat mengujinya untuk mengevaluasi efektivitasnya. Selama pengujian, sistem secara otomatis melakukan kalibrasi field peringatan. Gunakan saran kalibrasi yang dihasilkan untuk mengoptimalkan SQL atau playbook aturan guna memastikan akurasi dan standarisasi peringatan setelah aturan diaktifkan.

   1. Ubah Enabling Status aturan target menjadi Testing.

   2. Di kolom aksi untuk aturan target, klik View Alert Test Result.

   3. Di halaman detail hasil uji, lihat grafik tren peringatan dan daftar peringatan yang dihasilkan.

   4. Di kolom Aksi untuk suatu peringatan, klik Details untuk melihat hasil kalibrasinya.

6. Aktifkan aturan kustom

   Setelah aturan lolos pengujian, atur Enabling Status menjadi Enabled.

   Penting

   Kami merekomendasikan untuk menguji aturan sebelum mengaktifkannya.