Post cover image

August 11, 2026

Cara Saya Memahami Security Solutions dan Membaca Log dengan PowerShell

Panduan praktis untuk pemula memahami fungsi security tools dan menganalisis log tanpa sekadar menghafal field

By Dhimas Lanang Nugroho

14 min read

Panduan praktis untuk pemula memahami fungsi security tools dan menganalisis log tanpa sekadar menghafal field

Ketika pertama kali belajar menjadi SOC Analyst, salah satu hal yang terasa membingungkan adalah banyaknya security product yang digunakan di sebuah organisasi.

Ada firewall, IDS, IPS, EDR, antivirus, sandbox, WAF, proxy, DLP, sampai email security. Semuanya berkaitan dengan keamanan, tetapi masing-masing melihat aktivitas dari sudut yang berbeda.

Kesalahan yang cukup umum ketika baru belajar adalah berusaha menghafal definisi setiap produk.

Menurut saya, cara yang lebih mudah adalah memahami tiga hal:

Apa yang dilindungi?

Data apa yang bisa kita lihat dari log-nya?

Bagaimana menentukan apakah aktivitas tersebut normal atau mencurigakan?

Artikel ini membahas konsep tersebut dari sudut pandang pemula, kemudian dilanjutkan dengan cara membaca log menggunakan PowerShell.

Catatan:_ Artikel ini adalah catatan pembelajaran independen. Contoh log, domain, IP address, username, hash, filename, dan indikator lainnya dibuat khusus untuk tujuan edukasi. Artikel ini tidak mereproduksi soal, jawaban hands-on, atau materi proprietary dari platform training tertentu._

Mengapa Kita Membutuhkan Banyak Security Solutions?

Tidak ada satu security product yang dapat melihat seluruh aktivitas dalam sebuah organisasi.

Bayangkan sebuah perusahaan memiliki:

  • laptop karyawan,
  • server,
  • aplikasi web,
  • koneksi internet,
  • email,
  • database,
  • cloud infrastructure,
  • dan berbagai perangkat jaringan.

Firewall mungkin bisa melihat koneksi antar-host, tetapi belum tentu mengetahui proses Windows apa yang membuat koneksi tersebut.

EDR bisa mengetahui bahwa powershell.exe berjalan, tetapi belum tentu memiliki konteks lengkap tentang serangan terhadap aplikasi web sebelum request mencapai endpoint.

WAF dapat mendeteksi SQL Injection pada HTTP request, tetapi tidak berfungsi sebagai antivirus untuk file yang tersimpan di laptop.

Itulah mengapa pendekatan keamanan biasanya menggunakan layered security.

Secara sederhana saya membaginya menjadi empat area:

Network Security IDS, IPS, firewall, proxy, dan network monitoring.

Endpoint Security EDR dan antivirus.

Application dan Cloud Security WAF dan load balancer logs.

Data dan Content Security DLP, sandbox, dan email security.

Saat semua telemetry ini dikumpulkan, SOC Analyst dapat menghubungkan kejadian yang awalnya terlihat terpisah menjadi sebuah incident.

1. Intrusion Detection System — IDS

IDS atau Intrusion Detection System digunakan untuk mengamati aktivitas dan mencari pola yang dianggap mencurigakan.

Konsep terpentingnya adalah:

_IDS berfokus pada _detection

Jika traffic sesuai dengan rule tertentu, IDS dapat menghasilkan alert agar analyst melakukan investigasi lebih lanjut.

Pada network monitoring, sebuah IDS biasanya melihat informasi seperti:

Source IP
Destination IP
Source Port
Destination Port
Protocol
Signature
Timestamp
Payload metadata

Suricata, misalnya, merupakan engine yang dapat digunakan sebagai IDS, IPS, sekaligus Network Security Monitoring. (Suricata Documentation)

Contoh alert sintetis:

2026-08-11 10:21:42
SRC=192.0.2.40
DST=198.51.100.20
PROTO=TCP
DPT=443
ALERT="Possible TLS Anomaly"

Cara membacanya jangan langsung:

"IP tersebut adalah attacker."

Yang lebih tepat:

"Sistem mendeteksi traffic dari 192.0.2.40 ke 198.51.100.20:443 yang cocok dengan sebuah detection rule."

Selanjutnya baru kita mencari konteks lain.

Apakah host tersebut memang melakukan scanning?

Apakah ada koneksi berulang?

Apakah firewall memblokir traffic?

Apakah endpoint tujuan menjalankan proses baru?

Inilah alasan alert IDS sebaiknya tidak dianalisis sendirian.

2. Intrusion Prevention System — IPS

IPS memiliki konsep yang mirip dengan IDS, tetapi biasanya ditempatkan sehingga dapat mengambil tindakan terhadap traffic.

Jadi sederhananya:

IDS = detect
IPS = detect + potentially prevent

Suricata sendiri dapat digunakan dalam kedua mode tersebut. (GitHub)

Pada IPS log, salah satu hal pertama yang perlu saya cari adalah:

alert
action
signature
source
destination
protocol

Misalnya:

{
  "src_ip": "192.0.2.55",
  "dest_ip": "198.51.100.8",
  "dest_port": 443,
  "alert": {
    "action": "blocked",
    "signature": "Synthetic Exploit Attempt"
  }
}

Dari sini kita mengetahui bahwa:

Activity detected : Yes
Action             : Blocked

Tetapi ada satu prinsip penting:

Alert mendeteksi aktivitas tidak selalu berarti serangan berhasil.

Misalnya terdapat signature:

Possible Remote Command Execution

Itu belum otomatis berarti command berhasil dijalankan.

Kita masih perlu mencari evidence seperti:

response dari server
child process
EDR telemetry
file creation
network callback
command output

Ini pola berpikir penting dalam pekerjaan SOC:

Detection ≠ Successful Exploitation

3. Firewall

Firewall bertugas mengontrol komunikasi berdasarkan rule.

Kalau saya mendapatkan firewall log, lima field pertama yang saya cari adalah:

Action
Protocol
Source IP
Destination IP
Destination Port

Contoh log sintetis:

2026-08-11 10:33:18 DENY TCP 192.0.2.44 198.51.100.25 53144 445

Saya akan membacanya sebagai:

Action           : DENY
Protocol         : TCP
Source IP        : 192.0.2.44
Destination IP   : 198.51.100.25
Source Port      : 53144
Destination Port : 445

Kemudian baru tanyakan:

Kenapa host tersebut mencoba mengakses port 445?

Port saja tidak cukup untuk menentukan malicious atau tidak. Tetapi port memberikan konteks mengenai service yang kemungkinan sedang dituju.

Membaca Windows Defender Firewall Log

Format Windows Firewall biasanya lebih mudah dianalisis jika kita memahami posisi field.

Microsoft menyediakan logging untuk dropped packets dan successful connections ketika opsi tersebut diaktifkan. (Microsoft Learn)

Contoh sederhana:

2026-08-11 10:40:12 DROP TCP 192.0.2.15 198.51.100.15 5421 443

Kita bisa membaca:

DROP
TCP
192.0.2.15
198.51.100.15
5421
443

Artinya ada TCP traffic dengan:

Source IP        = 192.0.2.15
Destination IP   = 198.51.100.15
Source Port      = 5421
Destination Port = 443
Action           = DROP

Kalau pertanyaannya:

IP mana yang mengirim TCP segment dengan source port 5421?

Tidak perlu menganalisis semuanya.

Cari saja:

Select-String -Path .\pfirewall.log -Pattern '5421'

Kemudian baca field source IP.

Teknik sederhana seperti ini akan sangat menghemat waktu.

4. Endpoint Detection and Response — EDR

Kalau firewall melihat komunikasi jaringan, EDR melihat aktivitas di endpoint.

Contohnya:

Process execution
Parent process
Command line
File creation
Registry modification
Network connection
User
File hash
Detection name
Severity
MITRE technique
Response action

EDR membantu analyst mendapatkan konteks yang jauh lebih detail mengenai apa yang terjadi pada workstation atau server. Microsoft, misalnya, menjelaskan EDR sebagai kemampuan yang memberikan visibility terhadap aktivitas endpoint serta membantu investigation dan response terhadap serangan. (Microsoft Learn)

Misalnya terdapat log sintetis:

{
  "Technique": "Command and Scripting Interpreter: PowerShell",
  "SeverityName": "High",
  "FileName": "powershell.exe",
  "UserName": "LAB\\analyst",
  "CommandLine": "powershell.exe -File C:\\Temp\\inventory.ps1",
  "PatternDispositionDescription": "Process blocked"
}

Pertama saya tidak membaca seluruh JSON dari kiri ke kanan.

Saya mencari:

Technique
SeverityName
FileName
CommandLine
UserName
PatternDispositionDescription

Hasilnya:

Technique : Command and Scripting Interpreter: PowerShell
Severity  : High
Process   : powershell.exe
Script    : inventory.ps1
User      : LAB\analyst
Action    : Process blocked

MITRE ATT&CK sendiri memetakan penyalahgunaan PowerShell sebagai sub-technique T1059.001.

Perlu diperhatikan bahwa PowerShell bukan malware.

PowerShell adalah tool administrasi yang legitimate.

Yang menentukan apakah aktivitas berbahaya adalah konteks seperti:

Siapa yang menjalankan?
Apa command-nya?
Dari process apa?
Mengunduh apa?
Mengakses credential atau tidak?
Apakah behavior cocok dengan attack technique tertentu?

5. Antivirus

Antivirus biasanya lebih berorientasi kepada file dan threat detection.

Ketika membaca antivirus log, saya fokus pada:

Filename
Threat Name
Category
Severity
Detection Path
Action

Contoh:

Filename    : updater-demo.exe
Threat Name : Trojan:Win32/Sample.A
Severity    : Severe
Category    : Trojan
Detect Path : C:\Users\demo\Downloads\updater-demo.exe
Action      : Quarantined

Kalau pertanyaannya:

Apa jenis malware-nya?

Tidak perlu menebak dari nama file.

Lihat:

Category : Trojan

Kalau ditanya apakah file sudah ditangani:

Action : Quarantined

Microsoft Defender Antivirus menyimpan hasil detection yang dapat direview bersama informasi mengenai threat yang ditemukan.

6. Sandbox

Sandbox adalah salah satu tool yang menurut saya paling menarik ketika mulai belajar malware analysis.

Idenya sederhana:

Jalankan file mencurigakan di environment terisolasi, kemudian lihat apa yang dilakukan file tersebut.

Tujuannya bukan hanya menentukan:

Malicious / Not malicious

Tetapi memahami behavior.

Ketika membuka sandbox report, saya biasanya membaca bagian ini secara berurutan:

Process tree
Files activity
Network connections
DNS requests
HTTP requests
Registry activity
Persistence
MITRE ATT&CK
Indicators of Compromise

Platform sandbox seperti ANY.RUN, misalnya, menampilkan process activity sekaligus informasi jaringan seperti HTTP requests, connections, DNS requests, serta detection terkait. (Any.run)

Misalnya sebuah sample:

setup-demo.exe

membuat:

C:\Users\demo\AppData\Local\Temp\setup-helper.dll

Kemudian setup-helper.dll membuka koneksi ke:

update-check.example

Maka jangan hanya fokus pada file pertama.

Pertanyaannya adalah:

File mana yang sebenarnya melakukan malicious behavior?

Itu bisa saja parent process, child process, DLL yang di-drop, atau executable lain yang dibuat setelah sample pertama dijalankan.

Cara Saya Membaca Sandbox Report

Saya biasanya mulai dari Process Tree.

Contoh:

setup-demo.exe
    |
    +--- rundll32.exe
             |
             +--- setup-helper.dll

Kemudian cek aktivitas process terakhir.

Apakah dia:

membuat file?
mengubah registry?
membuat scheduled task?
menghubungi domain?
mengunduh payload?

Setelah itu baru cek DNS.

Misalnya:

DNS Request
update-check.example

Lalu cek network connection.

203.0.113.50:443

Sekarang kita sudah mulai membangun cerita:

File executed
      ↓
Child process created
      ↓
DLL loaded
      ↓
DNS request
      ↓
Outbound connection

Analisis seperti ini jauh lebih berguna daripada sekadar menghafal nama malware.

7. Data Loss Prevention — DLP

DLP atau Data Loss Prevention berfokus pada perlindungan informasi sensitif.

Bukan hanya malware yang menjadi ancaman bagi organisasi.

Data dapat bocor karena:

Email
Cloud storage
USB/removable media
Browser upload
File sharing
Clipboard
Printing
Messaging application

DLP menggunakan policy untuk mendeteksi dan menangani data sensitif berdasarkan rule yang ditentukan organisasi. Microsoft Purview DLP, misalnya, menggunakan policy untuk mengidentifikasi, memonitor, dan melindungi sensitive information pada berbagai lokasi dan aktivitas pengguna. (Microsoft Learn)

Misalkan seorang employee mencoba mengirim dokumen:

customer-database.xlsx

ke alamat email eksternal.

DLP mungkin menghasilkan:

Policy       : Customer Data Protection
Action       : Block
User         : employee@example.com
Destination  : external-user@example
File         : customer-database.xlsx
Classification: Confidential

Analyst perlu menentukan:

Data apa?
Dikirim oleh siapa?
Ke mana?
Melalui channel apa?
Rule apa yang terpicu?
Apa tindakan DLP?

DLP tidak selalu berarti aktivitas malicious.

Bisa juga employee melakukan kesalahan.

Karena itu konteks bisnis sangat penting.

8. Asset Management

Asset management sering terlihat kurang menarik dibanding malware analysis atau incident response.

Padahal analyst tidak bisa melindungi sesuatu yang bahkan tidak diketahui keberadaannya.

Contoh asset:

Laptop
Server
Virtual Machine
Firewall
Router
Cloud instance
Database
Application
Software
IoT device

Informasi inventory biasanya meliputi:

Hostname
IP
Operating System
Owner
Department
Installed Software
Software Version
Criticality
Location
Last Seen

CISA juga menekankan pentingnya asset visibility dan inventory sebagai fondasi untuk mengelola cybersecurity risk. (CISA)

Misalnya muncul vulnerability baru pada:

WebServerX 4.2

Pertanyaan SOC atau vulnerability team bukan hanya:

"Apakah vulnerability ini berbahaya?"

Tetapi:

"Kita punya berapa server yang menjalankan WebServerX 4.2?"

Tanpa inventory yang baik, pertanyaan kedua jauh lebih sulit dijawab.

9. Web Application Firewall — WAF

Firewall biasa berfokus pada network traffic.

WAF lebih fokus kepada HTTP/HTTPS request yang menuju web application.

WAF dapat melihat informasi seperti:

Client IP
HTTP Method
Host
URI
Query
Headers
User-Agent
Matched Rule
Action

Contohnya:

{
  "action": "BLOCK",
  "terminatingRuleId": "Demo_SQLi",
  "terminatingRuleMatchDetails": [
    {
      "conditionType": "SQL_INJECTION"
    }
  ],
  "httpRequest": {
    "clientIp": "198.51.100.77",
    "country": "ID",
    "uri": "/products",
    "httpMethod": "GET"
  }
}

AWS WAF logs memang memiliki informasi mengenai action, rule yang matching, dan informasi request termasuk client IP. (AWS Documentation)

Dari contoh tersebut saya bisa menyederhanakannya menjadi:

Attack Type : SQL Injection
Action      : BLOCK
Source IP   : 198.51.100.77
Method      : GET
URI         : /products

Itulah tujuan parsing:

Mengubah log panjang menjadi informasi yang mudah dipahami manusia.

Cloudflare WAF

Konsep yang sama berlaku pada Cloudflare logs.

Misalnya:

{
  "action": "block",
  "clientIP": "203.0.113.41",
  "clientRequestHTTPHost": "portal.example",
  "clientRequestHTTPMethodName": "POST",
  "clientRequestHTTPProtocol": "HTTP/1.1",
  "clientRequestPath": "/login"
}

Cloudflare mendokumentasikan field request seperti client IP, request method, host dan path pada HTTP request logs. (Cloudflare Docs)

Tidak perlu membaca semuanya.

Kalau hanya ingin mengetahui method:

clientRequestHTTPMethodName : POST

Jawabannya sudah ditemukan.

10. Load Balancer

Load balancer berada di antara client dan backend server untuk mendistribusikan request.

Dari sudut pandang analyst, access log load balancer menarik karena kita bisa melihat:

Client IP
Backend
Request
HTTP method
Status code
Latency
TLS information
User-Agent

AWS Application Load Balancer access logs misalnya dapat menyimpan informasi request termasuk client IP, request path, latency, response, dan user-agent. (AWS Documentation)

Contoh sintetis:

https 2026-08-11T11:20:31Z
192.0.2.90:51421
198.51.100.10:443
"GET https://portal.example/ HTTP/1.1"
"curl/8.5.0"
200

Bagian pentingnya:

Request    : GET https://portal.example/
User-Agent : curl/8.5.0
Status     : 200

User-Agent dapat memberi petunjuk mengenai software yang mengirim request.

Tetapi sekali lagi:

curl ≠ attacker

curl juga digunakan oleh administrator, automation, health check, developer, dan script legitimate.

Konteks tetap menentukan.

11. Proxy Server

Proxy berada di antara client dan resource yang diakses.

Salah satu produk yang sering digunakan sebagai contoh adalah Squid.

Squid dapat menghasilkan access log untuk HTTP request yang melewati proxy. (Squid Cache)

Contoh:

1710000010.120 120 192.0.2.25 TCP_MISS/200 502 GET http://news.example/ - DIRECT/198.51.100.1 text/html
1710000012.410 88 192.0.2.25 TCP_MISS/301 402 GET http://portal.example/ - DIRECT/198.51.100.2 text/html
1710000015.850 32 192.0.2.25 TCP_TUNNEL/200 39 CONNECT secure.example:443 - DIRECT/203.0.113.5 -

Yang perlu diperhatikan:

GET http://news.example/
GET http://portal.example/
CONNECT secure.example:443

Untuk HTTPS proxying sering terlihat:

CONNECT hostname:443

Dari:

CONNECT secure.example:443

kita langsung tahu destination port-nya:

443

Menghitung Domain GET yang Berbeda

Misalkan file proxy sangat panjang dan kita ingin mencari berapa domain unik yang menerima HTTP GET.

Tidak perlu menghitung manual.

PowerShell bisa melakukannya.

Get-Content .\proxy.log |
Where-Object { $_ -match '\sGET\s' } |
ForEach-Object {
    if ($_ -match 'GET\s+https?://([^/\s]+)') {
        $matches[1]
    }
} |
Sort-Object -Unique

Misalnya hasilnya:

news.example
portal.example
research.example
status.example
updates.example

Untuk menghitung:

(
    Get-Content .\proxy.log |
    Where-Object { $_ -match '\sGET\s' } |
    ForEach-Object {
        if ($_ -match 'GET\s+https?://([^/\s]+)') {
            $matches[1]
        }
    } |
    Sort-Object -Unique
).Count

Output:

5

Teknik seperti ini jauh lebih scalable daripada membaca ratusan baris satu per satu.

12. Email Security

Email masih menjadi salah satu sumber telemetry penting bagi SOC.

Email security log dapat memberi informasi seperti:

Sender
Recipient
Sender IP
Subject
Attachment
URL
Threat classification
Spam score
Malware score
Action

Misalkan log-nya JSON:

{
  "senderIP": "192.0.2.81",
  "sender": "billing@sender.example",
  "recipient": [
    "analyst@example.com"
  ],
  "subject": "Updated Invoice",
  "eventType": "messagesBlocked",
  "threatsInfoMap": [
    {
      "classification": "malware",
      "threatType": "url",
      "threatStatus": "active",
      "threat": "download.example/update/"
    }
  ]
}

Dari log sepanjang itu sebenarnya informasi pentingnya hanya:

Sender         : billing@sender.example
Recipient      : analyst@example.com
Subject        : Updated Invoice
Action         : messagesBlocked
Classification : malware
Threat Type    : url

Ini salah satu alasan mengapa kemampuan parsing log jauh lebih penting dibanding menghafal posisi setiap field.

Workflow Analisis Log yang Saya Gunakan di PowerShell

Sekarang masuk ke bagian yang paling praktis.

Misalnya saya memiliki folder:

C:\Lab\SecurityLogs

yang berisi beberapa ZIP:

firewall.log.zip
waf.log.zip
edr.log.zip
proxy.log.zip
email.log.zip

Pertama masuk ke directory:

cd C:\Lab\SecurityLogs

Kemudian ekstrak semuanya:

Get-ChildItem *.zip | ForEach-Object {
    Expand-Archive -Path $_.FullName -DestinationPath $_.BaseName -Force
}

Perlu diperhatikan bahwa ZIP seperti:

firewall.log.zip

akan menghasilkan folder:

firewall.log

Jadi jangan langsung melakukan:

Get-Content .\firewall.log

karena firewall.log mungkin sebenarnya folder, bukan file.

Cek dahulu:

Get-ChildItem

Kemudian:

Get-ChildItem .\firewall.log -Recurse -File

Misalnya ditemukan:

C:\Lab\SecurityLogs\firewall.log\firewall.log

Barulah:

Get-Content .\firewall.log\firewall.log

Ini sederhana tetapi penting.

Cara Menentukan Log JSON atau Plain Text

Kalau isi log terlihat seperti:

{
    "action": "BLOCK",
    "clientIp": "198.51.100.12"
}

itu JSON.

Cara paling nyaman:

$log = Get-Content .\waf.log\waf.log -Raw | ConvertFrom-Json

Kemudian:

$log | Format-List

Daripada melihat:

{"action":"BLOCK","clientIp":"198.51.100.12","httpRequest":...

PowerShell dapat menampilkannya:

action      : BLOCK
clientIp    : 198.51.100.12
httpRequest : ...

Lebih mudah dibaca.

Mengakses Nested JSON

Misalkan:

{
  "action": "BLOCK",
  "httpRequest": {
    "clientIp": "198.51.100.77",
    "httpMethod": "POST",
    "uri": "/login"
  }
}

Kita bisa:

$log.action

Output:

BLOCK

Kemudian:

$log.httpRequest.clientIp

Output:

198.51.100.77

Dan:

$log.httpRequest.httpMethod

Output:

POST

Inilah salah satu teknik paling berguna ketika mengerjakan log berbentuk JSON.

Pilih Field yang Kita Perlukan Saja

Daripada:

$log | Format-List

kita bisa memilih field tertentu:

$log | Select-Object action, terminatingRuleId

Nested object:

$log.httpRequest |
Select-Object clientIp, country, uri, httpMethod

Output menjadi seperti:

clientIp        : 198.51.100.77
country         : ID
uri             : /login
httpMethod      : POST

Jauh lebih rapi.

Untuk Plain Text Gunakan Select-String

Misalnya firewall log:

DENY TCP SRC=192.0.2.44 DST=198.51.100.15 SPT=53122 DPT=445

Cari source IP:

Select-String -Path .\firewall.log -Pattern 'SRC='

Cari port:

Select-String -Path .\firewall.log -Pattern 'DPT='

Cari alamat tertentu:

Select-String -Path .\firewall.log -Pattern '192\.0\.2\.44'

Kenapa titik menggunakan:

\.

Karena Select-String menggunakan regular expression dan karakter . memiliki arti khusus di regex.

Gunakan Context Kalau Informasi Ada di Baris Berikutnya

Contoh antivirus log:

Filename    : updater-demo.exe
Threat Name : Trojan:Win32/Sample.A
Severity    : Severe
Category    : Trojan
Action      : Quarantined

Kita ingin mencari filename tetapi juga ingin melihat field setelahnya.

Gunakan:

Select-String `
-Path .\antivirus.log `
-Pattern 'updater-demo\.exe' `
-Context 0,10

Artinya:

0 baris sebelum match
10 baris setelah match

Ini sangat efektif untuk structured text log.

Jangan Membaca Semua Log dari Atas ke Bawah

Menurut saya ini adalah kebiasaan yang paling penting ketika mulai belajar log analysis.

Misalnya ada 50.000 baris log.

Pertanyaan:

HTTP request dari 203.0.113.41 menggunakan method apa?

Jangan baca 50.000 baris.

Cari:

Select-String -Path .\waf.log -Pattern '203\.0\.113\.41'

Kemudian cari method pada event tersebut.

Atau jika JSON sudah diparse:

$log |
Where-Object {
    $_.clientIP -eq "203.0.113.41"
} |
Select-Object clientIP, clientRequestHTTPMethodName

Cara berpikirnya:

Question
   ↓
Indicator
   ↓
Filter
   ↓
Relevant Event
   ↓
Field
   ↓
Conclusion

Bukan:

Open log
   ↓
Read everything
   ↓
Confused

Workflow Investigasi yang Lebih Terstruktur

Ketika mendapatkan sebuah log, saya menggunakan pola:

1. Identify

Cari apa yang menjadi fokus pertanyaan.

Contoh:

IP?
Port?
Domain?
Filename?
User-Agent?
Threat type?
Action?
MITRE technique?

2. Filter

Gunakan identifier paling spesifik.

Misalnya:

Select-String -Pattern '203\.0\.113\.41'

3. Extract

Ambil field yang dibutuhkan.

Contoh:

clientRequestHTTPMethodName

4. Validate

Pastikan field tersebut memang berasal dari event yang sama.

Jangan mengambil IP dari event A dan HTTP method dari event B.

5. Correlate

Kalau sedang melakukan incident investigation sungguhan, lanjutkan ke telemetry lain.

Contoh:

WAF
 ↓
Firewall
 ↓
Proxy
 ↓
EDR
 ↓
Antivirus
 ↓
Sandbox

Contoh Korelasi Sebuah Incident

Misalkan WAF menemukan:

Source IP : 198.51.100.77
Action    : BLOCK
Rule      : SQL Injection

Firewall kemudian menunjukkan:

198.51.100.77 → Web Server

Tidak ada koneksi yang berhasil melewati rule tertentu.

Tetapi EDR pada web server menunjukkan:

No suspicious child process
No new executable
No unusual PowerShell

Kesimpulan awal yang lebih masuk akal adalah:

Terjadi attempt yang terdeteksi dan diblokir, tetapi sejauh telemetry yang tersedia belum terdapat evidence bahwa exploitation berhasil.

Bandingkan jika EDR menunjukkan:

webserver.exe
   ↓
cmd.exe
   ↓
powershell.exe

kemudian:

powershell.exe → external IP

Sekarang tingkat kekhawatirannya jauh lebih tinggi.

Inilah manfaat correlation.

Belajar MITRE ATT&CK Tanpa Menghafal Semuanya

MITRE ATT&CK cukup besar sehingga menghafalkan seluruh technique tidak realistis untuk pemula.

Lebih baik belajar berdasarkan aktivitas yang ditemui.

Misalnya EDR menunjukkan credential dumping.

Kita cari:

Credential Dumping

MITRE ATT&CK memetakannya sebagai OS Credential Dumping, technique T1003. (MITRE ATT&CK)

Jika menemukan penggunaan PowerShell:

PowerShell

kita dapat menghubungkannya dengan:

Command and Scripting Interpreter: PowerShell
T1059.001

Dengan pendekatan ini, MITRE menjadi alat untuk memberikan konteks behavior, bukan sekadar daftar kode yang harus dihafal.

Hal yang Sering Membuat Pemula Salah Membaca Log

Ada beberapa pola yang menurut saya harus dihindari.

Pertama, menganggap setiap alert berarti compromised.

Alert adalah titik awal investigasi.

Kedua, melihat IP dan langsung menyebut attacker.

IP merupakan indicator, bukan identitas seseorang.

Ketiga, menganggap tool tertentu selalu malicious.

Contoh:

PowerShell
curl
rundll32
cmd.exe

semuanya memiliki penggunaan legitimate.

Keempat, hanya membaca severity.

High tidak otomatis berarti incident benar-benar terjadi.

Severity membantu prioritization, bukan menggantikan investigasi.

Kelima, tidak memperhatikan action.

Bandingkan:

Detected
Blocked
Allowed
Quarantined
Prevented
Dropped

Semua memiliki arti investigasi yang berbeda.

Keenam, tidak memeriksa timeline.

Urutan event sangat penting.

09:01 email received
09:03 user opens attachment
09:03 child process starts
09:04 DNS request
09:04 outbound connection
09:05 EDR alert

Timeline seperti itu jauh lebih bermakna dibanding melihat event secara terpisah.

Cheat Sheet: Field yang Pertama Kali Saya Cari

Untuk Firewall:

Action
Protocol
Source IP
Destination IP
Source Port
Destination Port

Untuk IDS/IPS:

Timestamp
Source
Destination
Signature
Category
Action
Protocol

Untuk EDR:

Hostname
Username
Process
Parent Process
CommandLine
Hash
Technique
Severity
Action

Untuk Antivirus:

Filename
Threat Name
Category
Severity
Path
Action

Untuk WAF:

Client IP
HTTP Method
Host
URI
User-Agent
Matched Rule
Action

Untuk Load Balancer:

Client
Backend
Request
Status
User-Agent
TLS
Latency

Untuk Proxy:

Client IP
Method
Domain
Port
Status
Destination IP

Untuk Email Security:

Sender
Recipient
Sender IP
Subject
URL
Attachment
Classification
Action

Untuk Sandbox:

Process Tree
Dropped Files
DNS
Connections
HTTP
Registry
Persistence
MITRE
IOC

Bonus: Melihat Semua File Hasil Ekstrak

Kalau folder lab berantakan, saya biasanya memakai:

Get-ChildItem -Recurse -File |
Select-Object FullName

Untuk mencari semua .log:

Get-ChildItem -Recurse -File -Filter *.log

Untuk mencari kata malware di seluruh log:

Get-ChildItem -Recurse -File |
Select-String -Pattern 'malware' -CaseSensitive:$false

Untuk mencari IP tertentu:

Get-ChildItem -Recurse -File |
Select-String -Pattern '198\.51\.100\.77'

Ini sangat berguna ketika kita bahkan belum tahu event tersebut berasal dari security product mana.

JSON Pretty Print di PowerShell

Kalau JSON terlalu panjang:

Get-Content .\sample.log -Raw |
ConvertFrom-Json |
ConvertTo-Json -Depth 20

Misalnya sebelumnya:

{"action":"BLOCK","httpRequest":{"clientIp":"198.51.100.77","httpMethod":"GET"}}

akan terlihat seperti:

{
  "action": "BLOCK",
  "httpRequest": {
    "clientIp": "198.51.100.77",
    "httpMethod": "GET"
  }
}

Perbedaannya sangat terasa ketika object memiliki banyak nested field.

Network Monitoring Tidak Selalu Berarti Alert

Selain IDS/IPS, ada juga tools yang sangat berguna untuk menghasilkan telemetry jaringan.

Zeek adalah contoh yang bagus.

Zeek dapat membuat berbagai log mengenai aktivitas jaringan, termasuk connection, HTTP, DNS, TLS/certificate, dan berbagai protocol lain.

Misalnya:

conn.log
dns.log
http.log
ssl.log
files.log

Ini berbeda dengan cara berpikir:

“Apakah ada alert?”

Zeek membantu kita menjawab:

“Apa yang sebenarnya terjadi di network?”

Keduanya saling melengkapi.

Suricata dapat memberikan:

Possible malicious activity detected

Zeek dapat membantu memberi konteks:

Host mana terhubung?
Ke mana?
Berapa lama?
Protocol apa?
DNS apa yang diminta?
HTTP request apa yang dilakukan?

Tools Bukan Pengganti Analyst

Semakin lama belajar SOC, saya semakin melihat bahwa security tools sebenarnya adalah sumber evidence.

Tool dapat mengatakan:

Malicious
High
Blocked
Trojan
SQL Injection
Suspicious

Tetapi analyst harus menjawab:

Apa yang terjadi?
Kapan?
Dari mana?
Ke mana?
Bagaimana?
Apakah berhasil?
Apa dampaknya?
Apa yang harus dilakukan berikutnya?

Sebuah alert hanyalah satu bagian dari cerita.

Kesimpulan

Belajar security solutions tidak harus dimulai dari menghafal definisi panjang.

Saya lebih suka mengingat fungsi utamanya:

IDS
→ mendeteksi aktivitas mencurigakan
IPS
→ mendeteksi dan dapat mencegah traffic
Firewall
→ mengontrol komunikasi jaringan
EDR
→ melihat dan merespons aktivitas endpoint
Antivirus
→ mendeteksi malicious file dan malware
Sandbox
→ mengamati behavior file dalam environment terisolasi
DLP
→ melindungi sensitive data
Asset Management
→ mengetahui aset apa yang dimiliki dan harus dilindungi
WAF
→ melindungi web application dari malicious HTTP request
Load Balancer
→ mendistribusikan request dan memberikan access telemetry
Proxy
→ menjadi perantara client dengan destination dan mencatat aktivitas web
Email Security
→ mendeteksi ancaman yang masuk atau keluar melalui email

Kemudian ketika membaca log gunakan pola:

Identify
   ↓
Filter
   ↓
Extract
   ↓
Validate
   ↓
Correlate
   ↓
Conclude

Jangan mencoba memahami seluruh log sekaligus.

Cari indicator yang relevan terlebih dahulu.

Jika log berbentuk JSON, gunakan:

ConvertFrom-Json

Jika plain text, gunakan:

Select-String

Jika perlu melihat file:

Get-Content

Jika ingin mencari file hasil ekstrak:

Get-ChildItem -Recurse -File

Dan yang paling penting:

Jangan hanya mencari jawaban. Cari evidence yang membuat kita bisa menjelaskan kenapa jawaban tersebut benar.

Skill SOC Analyst bukan kemampuan menghafal field.

Skill-nya adalah kemampuan mengubah log yang terlihat berantakan menjadi cerita yang masuk akal.

None

Penutup

Artikel ini saya tulis sebagai catatan pembelajaran untuk memahami security solutions dari perspektif seorang analyst pemula.

Tujuannya bukan menggantikan dokumentasi resmi atau training platform, tetapi membantu membangun pola pikir ketika berhadapan dengan log.

Kalau harus diringkas menjadi satu kalimat:

Kenali sumber log, tentukan indicator yang dicari, filter event yang relevan, baca field yang tepat, kemudian validasi dengan telemetry lain.

Setelah terbiasa dengan pola tersebut, log seperti JSON yang awalnya terlihat sangat panjang mulai terasa jauh lebih sederhana.

Dan pada akhirnya, itulah pekerjaan analyst:

bukan membaca semua data, tetapi menemukan data yang penting.

Referensi dan Catatan

Artikel ini sengaja menggunakan contoh sintetis dan bahasa orisinal. Terms of Use LetsDefend menyatakan bahwa konten situs merupakan proprietary content dan memberikan limited license untuk personal/non-commercial use; ketentuan mereka juga membatasi penyalinan atau republication konten tanpa izin sebagaimana diatur dalam Terms tersebut. (LetsDefend)