Arista เตือน VeloCloud ช่องโหว่ 9.9 บัญชีดูอย่างเดียวก็ยึดสิทธิ์คุมระบบได้

ช่องโหว่ VeloCloud Orchestrator ได้คะแนนความรุนแรง CVSS 3.1 สูงถึง 9.9 และ Arista ยืนยันว่าพบการโจมตีจริงแล้ว โดยบัญชีที่มีสิทธิ์เพียงอ่านข้อมูลก็สามารถถูกใช้ยกระดับเป็นผู้ควบคุมระบบได้ บริษัทระบุว่าเป็นผู้ตรวจพบปัญหานี้เอง และออกประกาศเมื่อวันที่ 22 ตุลาคม 2026 (Arista)

เรื่องนี้เกี่ยวกับระบบบริหารเครือข่ายส่วนกลางที่ใช้ตั้งค่าและดูแลอุปกรณ์ตามสาขา จึงควรอยู่ในรายการตรวจของคนที่รับผิดชอบให้หลายสำนักงานทำงานต่อเนื่อง ไม่ใช่รอให้เครื่องพนักงานมีอาการก่อน เพราะจุดที่มีช่องโหว่คือหน้าบริหารระบบ VCO แบบติดตั้งเอง หรือ On-Prem (BleepingComputer)

สำหรับเจ้าของกิจการหรือคนทำงานทั่วไป สิ่งที่ควรทำกับข่าวนี้คือส่งให้คนดูแลเครือข่ายตรวจชื่อผลิตภัณฑ์ รูปแบบติดตั้ง และรุ่นที่ใช้อยู่ให้ตรงกันก่อน ส่วนทีมไอทีควรให้ความสำคัญกับบัญชีที่เคยคิดว่า “ดูได้อย่างเดียวคงไม่มีอะไร” เพราะสิทธิ์ต่ำสุดที่เข้าเงื่อนไขโจมตีคือ Enterprise Read Only ซึ่งเป็นบทบาทลูกค้าที่มีสิทธิ์ต่ำที่สุดในตัวระบบ (Arista)

สรุป 30 วินาที: เกิดอะไรขึ้น

ช่องโหว่รหัส CVE-2026-114625 กระทบ VeloCloud Orchestrator หรือ VCO แบบติดตั้งเอง ผู้โจมตีต้องเข้าถึงหน้าเว็บบริหารและมีสถานะเข้าสู่ระบบที่ถูกต้องอยู่ก่อน จึงไม่ใช่กรณีที่ใครก็โจมตีได้โดยไม่ต้องมีบัญชี (Arista)
บัญชีที่ผ่านการเข้าสู่ระบบแล้ว แม้เป็น Enterprise Read Only ก็สามารถได้สิทธิ์ operator หรือผู้ควบคุมระบบ และสวมสิทธิ์ผู้ควบคุมระดับสูงในเครื่องได้ ผลกระทบอาจถึงข้อมูลและเครื่องที่รัน VCO (Arista)
รุ่นแก้ไขคือ 5.2.3.18, 6.1.3.10 และ 6.4.2.12 หรือรุ่นใหม่กว่าในสายรุ่นเดียวกัน ส่วนบริการ Hosted รวมถึง Dedicated ที่ผู้ให้บริการดูแลให้ ได้รับการแก้ไขแล้ว (Arista)
VeloCloud Edge, VeloCloud Gateway และผลิตภัณฑ์ที่ใช้ Arista EOS ไม่ได้รับผลกระทบจากช่องโหว่นี้ แต่รุ่นที่หมดระยะสนับสนุนยังไม่ได้รับการประเมิน จึงห้ามอ่านว่า “ไม่อยู่ในรายการแล้วปลอดภัยแน่” (Arista)

คำว่า zero-day ในข่าวนี้หมายถึงช่องโหว่ที่มีการโจมตีเกิดขึ้นแล้วในช่วงก่อนการแก้ไขจะพร้อมให้ผู้ใช้รับมือ ประเด็นที่ยืนยันได้สำหรับเหตุการณ์นี้คือ Arista ระบุว่ามีการใช้โจมตีจริง และปล่อยอัปเดตแก้ไขแล้ว ไม่ใช่เพียงการทดลองให้เห็นว่าอาจทำได้ (BleepingComputer)

ทำไมเรื่องนี้เกี่ยวกับคุณ

คนที่ต้องเช็กโดยตรงคือองค์กรที่ใช้ VCO แบบติดตั้งเอง หากธุรกิจในไทยใช้ระบบนี้ก็ควรตรวจ แต่แหล่งข่าวที่ให้มายังไม่ได้ระบุว่ามีองค์กรไทยได้รับผลกระทบหรือไม่ ส่วนชื่อ VeloCloud อาจปรากฏในเอกสารเก่าภายใต้ Broadcom หรือ VMware เพราะ The Hacker News ระบุว่า Arista ประกาศซื้อสายผลิตภัณฑ์ VeloCloud SD-WAN จาก Broadcom ในเดือนกรกฎาคม 2025 และก่อนหน้านั้นใช้ชื่อ VMware SD-WAN by VeloCloud (The Hacker News)

ในมุมการตรวจทรัพย์สิน ผมแนะนำให้ค้นทั้งชื่อปัจจุบันและชื่อเดิมในรายการระบบหรือสัญญาที่มีอยู่ อย่าจบที่การถามว่า “เราใช้ Arista ไหม” เพราะคนละทีมอาจคุ้นกับชื่อผลิตภัณฑ์คนละช่วง การจับคู่ชื่อให้ตรงจะช่วยให้คำตอบเรื่องรุ่นและผู้รับผิดชอบชัดขึ้น โดยไม่ต้องเดาว่าอุปกรณ์ทุกชิ้นจากผู้ผลิตเดียวกันอยู่ในความเสี่ยงเดียวกัน

สำหรับธุรกิจหลายสาขา เช่น ร้านค้าปลีกหรือธนาคาร ประเด็นที่ควรคิดคือการดูแลเครือข่ายจากส่วนกลาง ไม่ใช่การอ้างว่าธุรกิจกลุ่มใดถูกโจมตีแล้ว VCO เป็นหน้าบริหารผ่านเว็บที่ใช้ตั้งค่า ติดตามสถานะ และจัดการเครือข่าย VeloCloud SD-WAN รวมถึงอุปกรณ์ปลายทางที่เกี่ยวข้อง (BleepingComputer)

อีกกลุ่มที่ควรสนใจคือคนดูแลบัญชีคู่ค้า ผู้รับจ้าง และผู้ให้บริการดูแลระบบให้หลายองค์กร หรือ MSP ผมแนะนำให้ตรวจบัญชีเหล่านี้ รวมถึงบัญชีเก่าที่ไม่มีคนใช้งานแล้ว เพราะเงื่อนไขช่องโหว่ยอมรับแม้บัญชีสิทธิ์ต่ำสุด ไม่ได้มีหลักฐานในข่าวว่าคู่ค้าหรือ MSP เป็นผู้ก่อเหตุ ในระบบ VCO ผู้ควบคุมสร้างบัญชีลูกค้าและคู่ค้าได้ และคู่ค้าสามารถดูแลกลุ่มลูกค้าได้ตามที่ The Hacker News อธิบายไว้ (The Hacker News)

ทำงานยังไง

SD-WAN ย่อมาจาก Software-Defined Wide Area Network อธิบายง่าย ๆ คือเครือข่ายเชื่อมสถานที่หลายแห่งที่บริหารด้วยซอฟต์แวร์ ส่วน orchestrator ในกรณีนี้คือศูนย์บัญชาการที่ใช้สั่งตั้งค่าและติดตามเราเตอร์ตามสาขาผ่านหน้าเว็บ VCO จึงเป็นจุดที่ผู้ดูแลใช้มองและจัดการเครือข่ายส่วนกลาง (BleepingComputer)

ให้นึกถึงคีย์การ์ดพนักงานที่อนุญาตให้เข้ามาดูข้อมูลได้ แต่มีข้อผิดพลาดทำให้บัตรใบนั้นถูกใช้รับอำนาจของผู้ดูแลอาคาร ปัญหาไม่ได้อยู่ที่ชื่อบนบัตรเขียนว่า “ดูอย่างเดียว” แต่อยู่ที่ระบบรักษาขอบเขตสิทธิ์นั้นไว้ไม่ได้ ใน VCO ที่ได้รับผลกระทบ บัญชีที่เข้าสู่ระบบแล้วสามารถยกระดับเป็น operator และสวมสิทธิ์ผู้ควบคุมระดับสูงในเครื่อง รวมถึงเข้าถึงความสามารถภายในที่ไม่ควรเปิดให้เข้าจากระยะไกล (Arista)

SQL injection คือข้อผิดพลาดที่ทำให้ระบบนำข้อมูลที่รับเข้ามาไปตีความเป็นคำสั่งฐานข้อมูลโดยไม่ควรเป็นเช่นนั้น ซึ่ง Arista ระบุว่าเป็นชนิดของช่องโหว่ครั้งนี้ (Arista)

ขอบเขตที่ต้องเข้าใจมีสองชั้น ผู้โจมตีต้องเข้าถึงหน้าเว็บ VCO ทางเครือข่ายได้ และต้องมีการเข้าสู่ระบบที่ถูกต้อง เงื่อนไขนี้ทำให้การจำกัดคนที่เข้าถึงหน้าเว็บกับการตรวจบัญชีผู้ใช้มีความหมายพร้อมกัน แต่ไม่ได้เปลี่ยนความจำเป็นที่จะต้องติดตั้งรุ่นแก้ไข เพราะผู้ผลิตระบุว่าไม่มีการตั้งค่าภายใน VCO ที่ป้องกันการเปิดรับช่องโหว่นี้ได้ (Arista)

จุดสังเกต: อ่านอย่างเดียวไม่ได้แปลว่าความเสี่ยงต่ำเสมอ

สิ่งที่สะดุดตาคือบัญชีไม่จำเป็นต้องเป็นผู้ดูแลตั้งแต่แรก บทบาท Enterprise Read Only ซึ่งตามหน้าที่ควรอ่านข้อมูลได้อย่างเดียวก็เข้าเงื่อนไขได้ ขณะเดียวกัน The Hacker News ระบุว่าช่องโหว่ VCO ที่มีการโจมตีในเดือนกรกฎาคมและกันยายนไม่ต้องเข้าสู่ระบบ แต่ช่องโหว่ครั้งนี้ต้องมีบัญชี (The Hacker News)

ผมจึงแนะนำให้ทีมไอทีขยายการทบทวนจากรายชื่อแอดมินไปถึงบัญชีสิทธิ์ต่ำด้วย ลองตรวจว่าบัญชีไหนยังมีเจ้าของ ใครอนุมัติให้ใช้งาน และยังต้องเข้าระบบอยู่หรือไม่ การมีชื่อบทบาทดูปลอดภัยไม่ควรเป็นเหตุให้ข้ามการตรวจ ส่วนบัญชีคู่ค้าและบัญชีเก่าควรตรวจด้วยหลักเดียวกัน โดยไม่เหมารวมว่าบัญชีเหล่านั้นเป็นอันตราย

อีกจุดคือการเคยอัปเดตแล้วไม่ได้ตอบว่าแก้เรื่องนี้แล้ว The Hacker News ระบุว่ารุ่นที่ใช้แก้ช่องโหว่ VCO ในเดือนกรกฎาคมและกันยายนยังเก่ากว่ารุ่นแก้ไขรอบนี้ จึงยังได้รับผลกระทบจาก CVE-2026-114625 ได้ ทีมงานต้องเทียบเลขรุ่นปัจจุบันกับประกาศใหม่ให้ตรง (The Hacker News)

เรื่องเงิน / ผลกระทบ

Arista ระบุว่าการโจมตีสำเร็จอาจกระทบความลับ ความถูกต้อง และความพร้อมใช้งานของ orchestrator กับข้อมูลที่ระบบดูแล แปลเป็นภาษางานคือมีความเสี่ยงที่ข้อมูลจะถูกเปิดดู ถูกแก้ไข หรือระบบใช้งานไม่ได้ตามปกติ รวมถึงอาจกระทบเครื่องที่รัน VCO เอง แต่ประกาศไม่ได้ให้ตัวเลขความเสียหายทางการเงิน (Arista)

ผมมองว่าคนอนุมัติงบควรถามทีมงานเรื่องเวลาที่ต้องใช้ตรวจระบบ ช่วงเวลาที่เหมาะกับการอัปเดต และแผนรับมือหากพบความผิดปกติ มากกว่ารอประมาณการความเสียหายที่ข่าวยังไม่มีให้ ค่าแรงตรวจหลักฐานและเวลาประสานผู้ให้บริการเป็นเรื่องที่ควรนำมาวางแผน แต่บทความนี้ไม่มีข้อมูลพอจะคำนวณเป็นเงินบาทหรือบอกว่ากิจการใดจะหยุดทำงานนานเท่าไร

ขอบเขตผลิตภัณฑ์ก็ช่วยไม่ให้แก้ผิดจุด Arista ระบุว่า VeloCloud Edge และ Gateway ไม่ได้รับผลกระทบจากช่องโหว่นี้ เช่นเดียวกับผลิตภัณฑ์ EOS, CloudVision และอุปกรณ์ Wi-Fi AP ของบริษัท ดังนั้นการมีอุปกรณ์ชื่อ VeloCloud อยู่ไม่ได้ยืนยันว่าตัวอุปกรณ์นั้นมีช่องโหว่นี้ ต้องตรวจ VCO ที่ใช้บริหารด้วย (Arista)

ส่วนบริการ Hosted และ Dedicated เคยได้รับผลกระทบแต่ได้รับการแพตช์แล้วตามประกาศ คำว่า “แก้แล้ว” จึงต่างจาก “ไม่เคยมีช่องโหว่” สำหรับผู้ใช้บริการ ผมแนะนำให้ยืนยันรูปแบบบริการที่ตนใช้อยู่กับผู้ดูแล และขอคำตอบให้ชัดว่าศูนย์บริหารขององค์กรอยู่ในกลุ่มใด (Arista)

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ข้อมูลหลักเรื่องรหัสช่องโหว่ เงื่อนไขต้องเข้าสู่ระบบ และรุ่นแก้ไขสอดคล้องกันระหว่างประกาศผู้ผลิตกับข่าวทั้งสองแห่ง อย่างไรก็ตาม ประกาศยังไม่บอกว่าเริ่มโจมตีเมื่อไร ระบบใดถูกโจมตี และผู้โจมตีทำอะไรหลังได้สิทธิ์แล้วตามที่ The Hacker News ตั้งข้อสังเกต จึงยังสรุปขนาดเหตุการณ์ จำนวนผู้เสียหาย หรือการได้รับผลกระทบในไทยไม่ได้ (The Hacker News)

คะแนน 9.9 ที่พบในข่าวคือคะแนนตาม CVSS 3.1 ซึ่งเป็นเกณฑ์ประเมินความรุนแรงของช่องโหว่ ส่วน Arista ให้คะแนนตามเกณฑ์ CVSS 4.0 เป็น 9.4 ด้วย ตัวเลขสองชุดนี้ใช้เกณฑ์คนละรุ่น ไม่ใช่หลักฐานว่าความรุนแรงลดลงระหว่างวัน และไม่ได้แปลเป็นโอกาสถูกโจมตีของแต่ละองค์กรโดยตรง (Arista)

เรื่องรุ่นเก่ามีข้อควรอ่านให้ครบ The Hacker News กล่าวว่าสายรุ่น 7.0 ไม่อยู่ในรายการได้รับผลกระทบ และอ้างว่ารุ่นที่ไม่อยู่ในรายการไม่เปราะบาง แต่ประกาศ Arista ระบุชัดว่ารุ่นหมดระยะสนับสนุนยังไม่ได้รับการประเมิน ผมจึงไม่ใช้การหาชื่อรุ่นไม่เจอเป็นหลักฐานรับรองความปลอดภัยของรุ่นที่หมดการสนับสนุน ผู้ใช้กลุ่มนี้ควรติดต่อ TAC หรือศูนย์ช่วยเหลือทางเทคนิคของ Arista (The Hacker News, Arista)

อีกเรื่องที่ยังสรุปไม่ได้คือรุ่น 6.1.3.10 แก้ช่องโหว่เดือนกันยายนด้วยหรือไม่ The Hacker News ระบุว่าประกาศที่เกี่ยวข้องยังไม่ได้ยืนยันเรื่องนี้ การยืนยันว่ารุ่นดังกล่าวแก้ CVE-2026-114625 จึงไม่ควรถูกขยายเป็นคำรับรองว่าแก้ช่องโหว่ก่อนหน้าทั้งหมดแล้ว (The Hacker News)

ท้ายที่สุด ยังไม่มีคำยืนยันในประกาศครั้งนี้ว่าการอัปเกรดเพียงอย่างเดียวจะลบช่องทางเข้าถึงที่ผู้โจมตีอาจสร้างไว้แล้วได้ หรือความเสี่ยงต่ออุปกรณ์ Edge หลังศูนย์บริหารถูกยึดเหมือนเหตุการณ์ก่อนหน้าหรือไม่ จึงควรแยกการปิดช่องโหว่ออกจากการตรวจว่าเคยถูกบุกรุกไปแล้วหรือยัง (The Hacker News)

แล้วเราควรทำอะไร

พนักงานทั่วไป เจ้าของกิจการ และผู้ประสานงานไอที

ส่งข่าวให้ผู้รับผิดชอบเครือข่าย พร้อมขอให้ยืนยันว่าองค์กรใช้ VCO หรือไม่ และเป็นแบบติดตั้งเองหรือบริการที่ผู้ให้บริการดูแลให้ ผมแนะนำให้ขอคำตอบที่ระบุชื่อระบบกับรูปแบบบริการชัดเจน
หากมีผู้รับจ้างดูแลระบบ ให้ขอชื่อผู้รับผิดชอบการตรวจรุ่น กำหนดดำเนินการ และสถานะหลังแก้ไข เพื่อให้ติดตามงานได้โดยไม่ต้องเข้าหน้าบริหารเอง
แจ้งทีมไอทีเมื่อพบว่าบัญชีของคนย้ายงานหรือคู่ค้าเดิมยังอยู่ในรายการที่ตนรับผิดชอบ ให้ทีมตรวจความจำเป็นก่อนดำเนินการกับบัญชี

ทีมดูแล VCO แบบติดตั้งเอง

เทียบรุ่นกับตารางนี้ แล้ววางแผนอัปเกรดไปยังรุ่นแก้ไขหรือใหม่กว่าในสายรุ่นเดียวกัน หากเป็นสายรุ่นหมดการสนับสนุนให้ติดต่อ TAC เรื่องทางเลือกอัปเกรด (Arista)

สายรุ่น	รุ่นที่ได้รับผลกระทบ	รุ่นแก้ไข
5.2.x	ก่อน 5.2.3.18	5.2.3.18 และใหม่กว่าในสาย 5.2
6.1.x	ก่อน 6.1.3.10	6.1.3.10 และใหม่กว่าในสาย 6.1
6.4.x	ก่อน 6.4.2.12	6.4.2.12 และใหม่กว่าในสาย 6.4

ตารางนี้อ้างอิงรุ่นที่ผู้ผลิตระบุสำหรับ CVE-2026-114625 โดยเฉพาะ (Arista)

ระหว่างรอติดตั้งรุ่นแก้ไข ให้จำกัดการเข้าถึงหน้าเว็บ VCO เฉพาะเครือข่ายผู้ดูแลที่เชื่อถือได้ นี่เป็นมาตรการลดความเสี่ยงตามคำแนะนำผู้ผลิต ไม่ควรใช้เป็นเหตุเลื่อนแพตช์โดยไม่มีกำหนด (Arista)
ทบทวนบัญชีทุกระดับ โดยเฉพาะ Enterprise Read Only บัญชีคู่ค้า ผู้ให้บริการ และบัญชีเก่า ผมแนะนำให้ตรวจเจ้าของกับความจำเป็นของแต่ละบัญชี เพราะบทบาทต่ำสุดก็เข้าเงื่อนไขช่องโหว่ได้ (Arista)
ตรวจการเปลี่ยนแปลงล่าสุดของผู้ดูแลและการเชื่อมต่อออกจากเครื่อง VCO ที่ผิดปกติ รวมถึงพิจารณาปิดช่องทางสื่อสารออกที่ระบบไม่จำเป็นต้องใช้ ผู้ผลิตยังแนะนำให้เฝ้าดูโปรแกรมที่อาจเปิดทางให้ผู้บุกรุกกลับเข้ามาควบคุมเครื่องได้ (Arista)

ทีมความปลอดภัยและผู้ให้บริการดูแลระบบ

ตรวจบันทึกการเข้าหน้าเว็บ VCO หรือ web access logs เพื่อหากิจกรรมผิดปกติ และทบทวนการใช้งานของผู้ดูแล Arista เผยแพร่ที่อยู่ไอพีสำหรับบล็อกไว้ในประกาศแล้ว ให้ทีมที่รับผิดชอบใช้ข้อมูลจากต้นทางโดยตรง (Arista)
หากสงสัยว่าถูกบุกรุก ให้เก็บบันทึกการเข้าเว็บ บันทึกแอปพลิเคชันเบื้องหลัง บันทึกระบบ บันทึกฐานข้อมูล และข้อมูลเวลาที่เกี่ยวข้องกับไฟล์ ก่อนแก้ไขระบบเท่าที่สภาพงานเอื้ออำนวย เพื่อรักษาหลักฐานไว้ตรวจสอบ (BleepingComputer)
ประสาน TAC เมื่อต้องการความช่วยเหลือ โดยเฉพาะระบบที่ใช้สายรุ่นไม่รองรับ และบันทึกให้ชัดว่างานใดเป็นการติดตั้งแพตช์ งานใดเป็นการตรวจเหตุบุกรุก ผู้ผลิตมีคำแนะนำให้ลูกค้าติดต่อศูนย์ช่วยเหลือเพิ่มเติม (BleepingComputer)

ผมมองว่า…

ผมมองว่า บทเรียนของข่าวนี้ไม่ใช่การห้ามมีบัญชีอ่านอย่างเดียว แต่คือการไม่ฝากความปลอดภัยทั้งหมดไว้กับชื่อบทบาท นี่เป็นความเห็นของผมจากเงื่อนไขที่ผู้ผลิตเปิดเผย การแบ่งสิทธิ์ยังมีเหตุผลในการทำงาน แต่ต้องมีการดูแลบัญชี จำกัดทางเข้าหน้าบริหาร และติดตั้งรุ่นแก้ไขควบคู่กัน เมื่อข้อผิดพลาดทำให้ข้ามขอบเขตสิทธิ์ได้ คำว่า Read Only ก็ไม่ควรทำให้รายการตรวจของเราสั้นลง

ผมยังเห็นว่าการรายงานต่อผู้บริหารควรแยกคำตอบให้ชัดว่า “อยู่ในขอบเขตไหม” “อัปเดตแล้วหรือยัง” และ “ตรวจพบร่องรอยไหม” เพราะเป็นคนละเรื่องกัน การตอบว่าแพตช์แล้วมีประโยชน์ แต่ยังไม่ควรถูกใช้แทนผลตรวจหลักฐาน โดยเฉพาะเมื่อข้อมูลที่มีอยู่ยังไม่ยืนยันว่าการอัปเกรดจัดการช่องทางเข้าถึงเดิมของผู้โจมตีได้ทั้งหมด

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ต้องติดตามต่อคือ Arista จะเปิดเผยรายละเอียดขอบเขตการโจมตีเพิ่มหรือไม่ จะมีคำชี้แจงเรื่องการเข้าถึงที่หลงเหลือหลังอัปเกรดอย่างไร และสายรุ่นเก่าควรย้ายไปทางไหน ข้อมูลเหล่านี้ยังไม่ครบในแหล่งข่าวที่มี แต่สิ่งที่ทำได้ตอนนี้ชัดแล้ว: ตรวจรูปแบบติดตั้ง เทียบรุ่น จำกัดหน้าเว็บบริหาร และรักษาหลักฐานเมื่อสงสัยว่าระบบถูกบุกรุก ตามแนวทางของผู้ผลิต (Arista, The Hacker News)

Recap

ตรวจว่าองค์กรใช้ VeloCloud Orchestrator หรือไม่ รวมถึงชื่อเดิมในเอกสาร
แยกให้ชัดว่าใช้ On-Prem, Hosted หรือ Dedicated
เทียบรุ่นกับ 5.2.3.18, 6.1.3.10 หรือ 6.4.2.12 ตามสายรุ่น
จำกัดหน้าเว็บบริหารไว้ในเครือข่ายผู้ดูแลที่เชื่อถือได้
ทบทวนบัญชีอ่านอย่างเดียว บัญชีคู่ค้า และบัญชีเก่า
ตรวจบันทึกการใช้งาน การเปลี่ยนแปลงของผู้ดูแล และการเชื่อมต่อผิดปกติ
เก็บหลักฐานก่อนแก้ไขเมื่อสงสัยว่าถูกบุกรุก เท่าที่ดำเนินการได้
ติดต่อ TAC หากใช้สายรุ่นไม่รองรับหรือต้องการความช่วยเหลือ