พูดง่ายๆ: ระบบของคุณที่อยู่บน Internet ทุกตัวมีโอกาสถูกโจมตี — แต่องค์กรส่วนใหญ่บอกไม่ได้แม่นๆ ว่าตัวเองมีระบบอะไรบ้างอยู่บนนั้น Attack Surface Management (ASM) คือกระบวนการค้นหาให้ครบ รวมถึงตัวที่ไม่มีใครเคยจดไว้ บทความนี้อธิบายว่า Discovery ทำงานยังไง AI ช่วยอะไรได้จริง และทำไม Governance ภายใต้ ISO 27001 ถึงสำคัญต่อการจัดการสิ่งที่ค้นพบ
ทีม Security ส่วนใหญ่บอกได้ว่า Server ไหนอยู่ใน CMDB (Configuration Management Database — ฐานข้อมูลกลางที่บันทึก IT Asset ทุกชิ้นที่ลงทะเบียนผ่านขั้นตอน Change Management ขององค์กร) แต่ถามว่า DNS ขององค์กรมี Subdomain อะไรบ้างที่ยังรับการเชื่อมต่อ — หรือ Vendor Portal ที่ติดตั้งตอนทำ M&A เมื่อ 2 ปีก่อนยังออนไลน์ไหม — คำตอบมักเป็น "ไม่รู้" ช่องว่างระหว่างสิ่งที่เรารู้ว่ามีกับสิ่งที่ Attacker เข้าถึงได้ คือ Attack Surface และในองค์กรที่รัน Multi-cloud หรือผ่านการซื้อกิจการมา ช่องว่างนี้กว้างกว่าที่คาดมาก
Attack Surface Management (ASM) คือกระบวนการค้นหา จัดทำรายการ และจัดลำดับความเสี่ยงของทุก Asset ที่หันหน้าออก Internet — ไม่ว่าจะอยู่ใน Registry ภายในหรือไม่ ASM ไม่ใช่การสแกน Vulnerability จาก List ที่มีอยู่แล้ว แต่เป็นการมองจากมุมของ Attacker แล้วค่อยเดินย้อนกลับมาหาเจ้าของ ตัวเลขที่เห็นซ้ำๆ ใน Engagement ASM ขั้นสูงคือ วันแรกของการค้นหามักพบ Asset ที่เปิดรับการเชื่อมต่อมากกว่า CMDB บันทึกไว้ถึง 30–60 เปอร์เซ็นต์
CMDB ดริฟต์ยังไง — และทำไมเป็นเรื่อง PDPA
CMDB ดริฟต์เพราะคนทำงานภายใต้ Deadline ทีม Marketing สร้าง Subdomain สำหรับแคมเปญบน Landing Page Builder ของ Vendor แล้วไม่ยื่น Change Ticket บริษัทที่ถูกซื้อมายังคงรัน Billing Portal เก่าไว้เพราะยังไม่มีใครสั่ง Decommission อย่างเป็นทางการ Vendor เปิด Admin Portal สำหรับ Integration กับ Core Banking แล้วลงทะเบียนภายใต้ Domain ของตัวเอง — รับ Traffic ได้ ยืนยันตัวตนได้ แต่ไม่ปรากฏในรายการ Asset ขององค์กรคุณแม้แต่บรรทัดเดียว
GDPR ในยุโรป, UK Data Protection Act, กฎหมายระดับ State ในสหรัฐ (เช่น CCPA) รวมถึง PDPA ของไทยและกฎหมายเทียบเท่าในมาเลเซีย, อินโดนีเซีย, สิงคโปร์ — ล้วนกำหนดให้แจ้งเหตุข้อมูลรั่วไหลโดยไม่คำนึงว่าระบบที่ถูกโจมตีจะอยู่ใน CMDB หรือไม่ Regulator ไม่รับคำชี้แจงว่า "เราไม่รู้ว่ามันมีอยู่" เป็นข้อแก้ตัวเมื่อข้อมูลส่วนบุคคลรั่วออกไปแล้ว สี่เส้นทางหลักที่ทำให้ CMDB ดริฟต์ได้แก่:
- Marketing Subdomains — หน้าแคมเปญและ Microsite ที่สร้างนอกขั้นตอน IT Change Control มักมี TLS Certificate หมดอายุหรือ Dependency เก่า
- M&A Integration Endpoints — API และพอร์ทัลที่รับมาจากการซื้อกิจการ มักรัน Software Version ที่ไม่เคยอยู่ใน Patch Cycle ขององค์กรหลัก
- บริการเก่าที่ยัง Resolve — DNS Record ที่ยังชี้ไปยัง Cloud Instance ที่ถูกปิดแล้ว หรือ Storage Bucket ที่ยังเปิดสาธารณะหลังจาก Application หยุดให้บริการไปแล้ว
- Vendor-published Portals — พอร์ทัลปฏิบัติการของ Vendor สำหรับ Core Banking, Core Insurance หรือ Core Telco ที่ยังผูกกับ Credential ของ Production Environment ขององค์กรคุณ
ASM Discovery ทำงานยังไง
ASM ไม่ได้สแกน IP Range ที่รู้อยู่แล้ว — วิธีนั้นสมมติว่าคุณรู้ขอบเขตแล้ว Discovery ที่ดีเริ่มจาก Anchor ไม่กี่จุด เช่น Domain หลัก, ASN Block ที่รู้จัก, เครื่องหมายการค้า แล้ว Fan-out แบบ Passive ผ่าน 4 แหล่งข้อมูลหลักพร้อมกัน
Passive DNS ดึงข้อมูล Resolution ย้อนหลังเพื่อหา Subdomain และ IP ที่เคยใช้งานแต่อาจไม่อยู่ใน Authoritative Record แล้ว Certificate Transparency Log คือบันทึกสาธารณะของ TLS Certificate ทุกใบ — Subdomain จะถูกเปิดเผยทันทีที่ขอ Certificate โดยไม่ต้องรอ Change Ticket ASN Ownership Data แมป Autonomous System Number ที่ลงทะเบียนในชื่อองค์กร เผย IP Range ที่อาจ Host Asset ที่ไม่ผูกกับ Domain ใดเลย Credential Leak Feeds ติดตามการรั่วไหลของ Email บริษัทและ Service Account ใน Breach Dataset — เตือนตั้งแต่ Asset กลายเป็นเป้าหมายผ่าน Credential ก่อนที่ Software Vulnerability จะถูกใช้
Asset ที่อันตรายที่สุดคือตัวที่ไม่เคยอยู่ใน CMDB — เพราะไม่มีใครยื่น Ticket, Vendor เปิดพอร์ทัลเอง, หรือทำ M&A เสร็จแล้วแต่ Handover ไม่เคยเกิดขึ้น
AI ช่วย Triage ได้จริงยังไง
ASM สำหรับองค์กรขนาดใหญ่อาจพบ Asset หลายพันรายการในวันแรก ถ้าไม่มี Triage ผลลัพธ์คือ Noise ทั้งนั้น นี่คือจุดที่ AI ให้คุณค่าจริงๆ — ไม่ใช่ตอน Discovery ซึ่งเป็นปัญหา Data Collection แบบ Deterministic แต่ใน 3 ขั้นตอนที่กำหนดว่าวิศวกรจะทำอะไรต่อ
ขั้นแรกคือ Clustering AI จัดกลุ่ม Asset ตาม Tech Stack, รูปแบบ Subdomain, ผู้ออก Certificate, Hosting Provider และ Metadata การลงทะเบียน Clustering ทำให้เห็นว่า Asset นั้นน่าจะเป็นของทีมไหน — Cluster ของ Payment Gateway Subdomain น่าจะเป็นของทีม FinTech Integration ไม่ใช่ทีม IT กลาง — ทำให้ผลลัพธ์อ่านง่ายสำหรับคนที่จะต้องรับผิดชอบ
ขั้นที่สองคือ Scoring แต่ละ Finding ถูกประเมินด้วย EPSS (Exploit Prediction Scoring System) ซึ่งให้ความน่าจะเป็นว่า CVE นั้นจะถูกโจมตีจริงใน 30 วัน และ CISA Known Exploited Vulnerabilities (KEV) ซึ่งคือรายชื่อ CVE ที่ยืนยันแล้วว่ามีการโจมตีจริง Finding ที่มี EPSS สูงและปรากฏใน CISA KEV คือความเสี่ยงคนละระดับกับ CVE ที่มี CVSS 9.8 แต่ไม่เคยเห็นใน Attack Chain จริง
ขั้นที่สามคือ Remediation Drafting AI สร้าง Brief สำหรับแต่ละ Finding ที่มีความเสี่ยงสูง: Version หรือ Configuration ที่ต้องเปลี่ยน, ทีมที่น่าจะเป็นเจ้าของ, งานประมาณกี่ชั่วโมง และ Compensating Control ที่ทำได้ระหว่างรอ Patch Brief นี้ไม่ได้แทนการตัดสินใจของวิศวกร — แต่ทำให้ Human-in-the-Loop Review ทำงานได้เร็วพอที่จะใช้งานจริง ไม่ใช่แค่ Formality
ASM ต่างจาก Vulnerability Scanning ยังไง
Vulnerability Scanning ต้องการ Asset List เป็น Input ASM คือสิ่งที่สร้าง Asset List นั้น สองอย่างนี้เสริมกัน ไม่ใช่ทดแทนกัน — Pentest รายครึ่งปีหรือ Nessus Scan รายสัปดาห์ดีแค่ไหนก็ดีแค่ Scope ที่ได้รับ ถ้า Asset ไม่อยู่ใน Scope ก็ไม่มีทาง Finding ASM ปิดช่องว่างของ Scope อย่างต่อเนื่อง ทำให้ Vulnerability Management ทำงานกับ Perimeter จริงๆ ไม่ใช่ตัวที่ถ่ายภาพไว้ใน Spreadsheet เมื่อสองไตรมาสก่อน — และนั่นคือสิ่งที่ ISO 27001 ISMS Control หมวด Asset Management ต้องการจริงๆ
ISO 27001 ISMS ในฐานะ Governance Anchor
ISO 27001 Annex A กำหนดให้องค์กรจัดทำ Inventory ของ Asset (A.8.1), จัดชั้นความลับ (A.8.2) และบริหาร Technical Vulnerability อย่างเป็นระบบ (A.12.6) ผลลัพธ์ของ ASM โดยเฉพาะ Asset ที่อยู่นอก CMDB ตรงกับ Control เหล่านี้โดยตรง ยิ่งกว่านั้น ASM Finding มักมีข้อมูลละเอียดอ่อน — Credential ที่รั่ว, CVE ใน Production ที่ยังไม่ Patch หรือหลักฐานว่าถูกเจาะไปแล้ว ถ้าไม่มีขั้นตอน ISMS รองรับ — จำแนกชั้นความลับ, แจกเฉพาะเจ้าของ Asset, ติดตามการแก้ไข, ยืนยันปิดเคส — Finding เหล่านั้นอาจสร้างความเสี่ยงทางกฎหมายมากกว่า Vulnerability เสียเอง
HarmonyX รัน ASM ภายใต้ ISMS Framework ที่ได้ ISO 27001 ทุก Finding ถูกจัดชั้นก่อนออกจาก Discovery Pipeline, แจกจ่าย Under NDA เฉพาะเจ้าของ Asset, ติดตามในทะเบียน Remediation และยืนยันปิดก่อนจะปิด Finding Record สำหรับลูกค้าในภาคที่กำกับดูแล — FinTech และธนาคารภายใต้ Prudential Regulator (เช่น Federal Reserve, EBA, FCA, MAS, ธปท.), โทรคมนาคมภายใต้ Sector Authority หรือองค์กรข้ามพรมแดนที่อยู่ภายใต้ Supervisor หลายประเทศ — Governance Layer นี้ไม่ใช่ Optional แต่เป็นสิ่งที่ทำให้ Engagement นี้อธิบาย Auditor ได้
Shadow IT และปัญหา Attack Surface ที่ขยายจาก M&A
Shadow IT ไม่ใช่ปัญหาวัฒนธรรม แต่เป็นปัญหาความเร็ว ทีมวิศวกรและธุรกิจสร้าง Cloud Resource, SaaS Integration และบริการภายนอกเพราะ Procurement รอนาน M&A ทำให้หนักขึ้น — Due Diligence ไม่ค่อย Include ASM Scan ของเป้าหมาย และ Shadow IT ของบริษัทที่ถูกซื้อกลายเป็นปัญหาของผู้ซื้อทันทีที่ Deal ปิด
ASM Engagement ใน 90 วันหลัง Close หรือจะดีกว่าถ้าทำเป็นส่วนหนึ่งของ Technical Due Diligence ก่อน Close มักพบ Finding ที่ Severity สูงที่สุดในทุกขั้นตอนของ M&A Security Integration — Legacy Stack ที่ไม่ได้ Patch, Credential ที่ใช้ซ้ำจากทีม Engineering ก่อนถูกซื้อ, Cloud Storage ที่ Config ผิดจาก Startup ที่ไม่มี Security Programme — สิ่งเหล่านี้คือ Finding ที่ขึ้นหน้าข่าว และแทบไม่เคยปรากฏในการสแกนที่ใช้ CMDB เป็น Scope
สิ่งที่ HarmonyX ASM Engagement ส่งมอบ
บริการ ASM ของเรารันเป็น Structured Engagement ไม่ใช่ SaaS Subscription ที่ต้องดูแลแพลตฟอร์มใหม่ ผลลัพธ์ออกแบบมาเพื่อป้อนเข้า Vulnerability Management, ITSM และ ISMS ที่มีอยู่โดยตรง
- External Asset Inventory ครบถ้วน — ค้นพบจาก Passive DNS, Certificate Transparency, ASN Data และ Credential Leak Feed แล้ว Cross-reference กับ CMDB ที่มีเพื่อหาส่วนต่าง
- Finding Report ที่จัดกลุ่มด้วย AI และให้คะแนนด้วย EPSS + CISA KEV — เรียงลำดับตามความเป็นไปได้ที่จะถูกโจมตีจริง ไม่ใช่ Severity เชิงทฤษฎี
- Remediation Briefs — คำแนะนำเชิง Structured ต่อ Finding ที่ Team Lead อ่านแล้วมอบหมายงานใน Sprint Planning ได้เลย ไม่ใช่ CSV Dump ที่ต้องใช้เวลาหลายวันตีความ
- Findings Handling ภายใต้ ISMS — จัดชั้นความลับ, แจกจ่ายเฉพาะเจ้าของ, ติดตาม Remediation Register และยืนยันปิด ตาม ISO 27001 A.8 และ A.12
เริ่มก่อน Breach จะคุ้มกว่าเสมอ
ASM Finding เสื่อมค่าเร็ว Subdomain ที่วันนี้ดูเป็น Low Severity อาจกลายเป็น Critical ในสัปดาห์ที่ Proof-of-concept Exploit ของ Framework นั้นออกมา CISA KEV เพิ่มรายการใหม่สัปดาห์ละ 2–5 รายการ และ Entry ใดก็ได้อาจตรงกับ Asset ในจุดอับของคุณ ค่าใช้จ่ายหลัง Breach — Forensic, PDPA Notification, ตอบ Regulator, ฟื้นฟูชื่อเสียง — สูงกว่าค่า ASM Engagement เชิงรับมากลำดับ องค์กรที่มอง Attack Surface Visibility เป็น Operational Function ต่อเนื่อง ไม่ใช่ Deliverable ของ Audit รายปี รับมือ Incident ได้เร็วกว่า จำกัด Blast Radius ได้ดีกว่า และแสดงให้ Auditor กับ Insurer เห็น Posture ที่แข็งแกร่งกว่าได้เสมอ
คุยกับเราเรื่อง Exposure ขององค์กรคุณ
HarmonyX รัน ASM Engagement แบบมีโครงสร้างภายใต้ ISO 27001 ISMS — ตั้งแต่ Discovery Sprint ไปจนถึง Remediation Register ที่ทีม Security ส่งให้ Auditor ได้เลย ถ้าองค์กรคุณรันหลาย Cloud, ผ่าน M&A ใน 24 เดือนที่ผ่านมา หรืออยู่ภายใต้การกำกับของ Financial-sector หรือ Critical-infrastructure Regulator ใน Jurisdiction หลัก — ช่องว่างระหว่าง CMDB กับ Attack Surface จริงๆ ควรรู้ก่อนที่คนอื่นจะรู้แทนคุณ ดูรายละเอียดบริการ Attack Surface Management ของเราที่ /services/attack-surface-management หรือติดต่อมาคุยว่า Discovery Sprint ของคุณควรเริ่มจากจุดไหน
