Security Center：Praktik terbaik untuk mendeteksi login dari akun dorman

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 timestamp Unix saat ini dalam detik.

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

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

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

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

• Analisis Logika:

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

  • Hasil: Set hasil sementara dari 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 dimulai 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': Mengkueri hanya log aktivitas login host, yang membuat garis dasar historis lebih akurat.

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

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

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

• Analisis Logika:

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

  • Hasil: Set hasil sementara yang berisi pengguna yang telah login dalam sehari terakhir, tidak termasuk 20 menit terakhir.

  • Poin Penting: Jendela waktu ini disetel dari 24 jam yang lalu hingga 20 menit yang lalu. Ini memastikan bahwa data garis dasar historis tidak tumpang tindih dengan data aktivitas terbaru, mencegah kesalahan logis dari perbandingan diri sendiri.

Gunakan LEFT JOIN untuk perbandingan perbedaan

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

• Syntax Analysis:

  • LEFT JOIN: Menggunakan Tabel Kiri (a, pengguna terbaru) sebagai dasar dan mencocokkan setiap rekornya dengan rekaman 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 gabungan. Bidang username, uuid, dan user_id digunakan bersama untuk mengidentifikasi entitas pengguna secara unik, memastikan pencocokan yang akurat.

• Analisis Logika:

  • Tujuan: Mengkorelasikan "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 rekaman dari tabel a dan rekaman dari tabel b yang berhasil dicocokkan berdasarkan bidang 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 menjadi NULL dalam hasil. Ini adalah 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 untuk memanfaatkan karakteristik LEFT JOIN. Ketika pengguna yang baru saja login (di tabel a) tidak dapat ditemukan dalam garis dasar historis (tabel b), b.username akan menjadi NULL.

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

• Analisis Logika:

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

  • Hasil: Setelah filter ini diterapkan, set hasil hanya berisi rekaman yang gagal cocok dalam LEFT JOIN—peristiwa abnormal yang Anda cari.

  • Poin Penting: b.username is null adalah titik keputusan inti dari seluruh logika deteksi. Ini menggunakan nilai NULL yang dihasilkan pada langkah sebelumnya untuk memisahkan rekaman "ada di terbaru, tidak ada di historis" dari dataset besar.

Gunakan SELECT DISTINCT untuk mengeluarkan peringatan

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

• Analisis Sintaks:

  • SELECT DISTINCT: Memilih dan mengeluarkan bidang yang ditentukan, serta menghapus duplikat dari hasil. Ini memastikan hanya satu peringatan yang dihasilkan untuk satu peristiwa abnormal.

• Analisis Logika:

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

  • Hasil: Daftar peringatan yang bersih dan tanpa duplikat. Setiap rekaman berisi informasi inti yang diperlukan untuk melacak peristiwa abnormal, seperti ID pengguna dan IP Sumber.

  • Poin Penting: Penggunaan DISTINCT sangat penting. Ini menghapus duplikat hasil untuk memastikan bahwa 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 Beli dan aktifkan 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 Navigasikan ke Halaman Create Custom Rule

   1. Masuk ke .

   2. Di panel navigasi kiri, pilih Agentic SOC > Rule Management. 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 aturan dan deskripsi, lalu klik Next.

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

      Parameter	Nilai
      Tubuh Aturan	SQL
      Ruang Lingkup Log	Log Login - Log Keberhasilan Login Host.
      Kueri SQL	Salin kode dari bagian Kueri SQL Akhir.
      Interval Penjadwalan	Interval Tetap - 20 menit.
      Jendela Waktu SQL	24 jam.
      Waktu Mulai	Saat aturan diaktifkan.
      Struktur Generasi	Log Peringatan Lainnya.
      Metrik Alarm	Login Abnormal.
      Tingkat Keparahan Peringatan	Sedang.
      Taktik ATT&CK	Persistensi - T1136 Buat Akun.
      Pemetaan Entitas	Alamat Jaringan is_malware: 1 ip: $src_ip net_connect_dir: in Host is_asset: 1 uuid: $uuid

4. Konfigurasikan Aturan Pembuatan Insiden

   1. Pada halaman Alert Settings, setelah konfigurasi selesai, klik Next.

   2. Konfigurasikan aturan peristiwa. Lihat parameter berikut untuk pengaturan:

      • Generate Event: Yes.

      • Incident Generation Method: Agregasi berdasarkan jenis.

      • Aggregation Window: 20 minutes.

5. Validasi Aturan

   Aturan baru secara default dalam status Disabled. Anda dapat mengujinya untuk mengevaluasi efektivitasnya. Selama pengujian, sistem secara otomatis melakukan kalibrasi terhadap 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, ubah Enabling Status menjadi Enabled.

   Penting

   Kami merekomendasikan untuk menguji aturan sebelum Anda mengaktifkannya.