ยังไม่ได้บันทึก เก็บในเบราว์เซอร์นี้เท่านั้น — หายเมื่อล้าง site data

CVSS 3.1 Calculator

คำนวณคะแนน CVSS 3.1 ตาม FIRST specification. ทำงานในเบราว์เซอร์ ไม่ส่งข้อมูลออก

สมมติฐานและข้อจำกัด: คะแนน CVSS ไม่ใช่ความน่าจะเป็นถูกโจมตี และไม่ใช่คำแนะนำจัดลำดับ patch อย่างเดียว ต้องพิจารณา threat, control, environment ประกอบ เครื่องมือนี้ implement สูตรจาก FIRST §7.1–7.3 และผ่านการทดสอบ parity กับ NVD 93/93 vectors

วาง CVSS 3.1 vector:

Base metrics (จำเป็น)

AV — Attack Vector (ช่องทางโจมตี)

ผู้โจมตีต้องเข้าถึงระบบด้วยวิธีใด — ยิ่งเข้าถึงง่าย ยิ่งได้คะแนนสูง

AV:N — Network

ช่องโหว่ถูกโจมตีผ่านเครือข่าย layer 3 (เช่น TCP/IP) จากที่ใดก็ได้บนอินเทอร์เน็ต

เลือกเมื่อ: ผู้โจมตีที่ไม่มีสิทธิ์ใด ๆ ในเครือข่ายภายในสามารถส่ง exploit ได้จากอินเทอร์เน็ต

อย่าเลือกเพียงเพราะ: ระบบมี URL สาธารณะ — ต้องยืนยันว่า attack surface ของช่องโหว่นั้นเปิดจากอินเทอร์เน็ตจริง ไม่ใช่ห่อ VPN

ตัวอย่าง: SQL injection ใน login page ที่เปิดให้ผู้ใช้ทั่วโลกเข้าใช้งาน

ที่มา: CVSS v3.1 §2.1.1 (bullet 1) · อ่านเพิ่ม

AV:A — Adjacent

โจมตีได้จากเครือข่ายที่ใกล้กัน (broadcast domain, Wi-Fi, Bluetooth, CAN bus, MPLS ที่ปิดไว้)

เลือกเมื่อ: ต้องอยู่ใน collision domain / L2 subnet เดียวกันจึงจะยิงได้

อย่าเลือกเพียงเพราะ: แค่เห็นว่า 'อยู่ในเครือข่ายภายใน' — ถ้าโจมตีข้ามได้ผ่าน routing ปกติ ให้เลือก Network แทน

ตัวอย่าง: ARP spoofing บน LAN, การใช้ช่องโหว่ Bluetooth Blueborne

ที่มา: CVSS v3.1 §2.1.1 (bullet 2) · อ่านเพิ่ม

AV:L — Local

โจมตีต้องเข้าถึงเครื่องหรือระบบก่อน เช่น login shell, terminal, GUI

เลือกเมื่อ: ต้องเป็น local user บนเครื่อง หรือหลอกให้ user เปิดไฟล์อันตราย

อย่าเลือกเพียงเพราะ: ระบบเป็น local application — ต้องพิจารณาว่าถ้าโดนผ่านเครือข่ายด้วยได้ ให้เลือก Network แทน

ตัวอย่าง: Privilege escalation ผ่าน setuid binary, การเปิดไฟล์ Office ที่มี macro

ที่มา: CVSS v3.1 §2.1.1 (bullet 3) · อ่านเพิ่ม

AV:P — Physical

ต้องสัมผัสอุปกรณ์ทางกายภาพ

เลือกเมื่อ: ต้องเสียบ USB, ถอดฝา case, เข้าถึง console port

อย่าเลือกเพียงเพราะ: อุปกรณ์อยู่ในสถานที่จำกัด — ถ้ายิงผ่าน remote management port ได้ ใช้ Network

ตัวอย่าง: Cold boot attack, การขโมย storage เข้ารหัสด้วยกุญแจใน RAM

ที่มา: CVSS v3.1 §2.1.1 (bullet 4) · อ่านเพิ่ม

⚠️ ข้อควรระวัง: ผู้ใช้จำนวนมากเลือก Network เมื่อระบบ 'อยู่บนอินเทอร์เน็ต' โดยไม่คำนึงว่าการโจมตีที่นับจริง ต้องเป็นการโจมตี network layer ไม่ใช่ social engineering

AC — Attack Complexity (ความซับซ้อนของการโจมตี)

ผู้โจมตีต้องเตรียมเงื่อนไขอะไรเพิ่มหรือไม่ นอกเหนือจากการเข้าถึงตาม Attack Vector

AC:L — Low

ไม่ต้องการเงื่อนไขพิเศษ ยิงได้เสถียร

เลือกเมื่อ: exploit ทำซ้ำได้ทันทีในทุก target

อย่าเลือกเพียงเพราะ: exploit หายากในตลาด — CVSS ไม่วัดความ 'พร้อมของ exploit'

ตัวอย่าง: SQL injection คลาสสิก, XSS reflected ทั่วไป

ที่มา: CVSS v3.1 §2.1.2 (Low) · อ่านเพิ่ม

AC:H — High

ต้องอาศัยเงื่อนไขนอกเหนือควบคุม เช่น race window, memory layout, MITM ที่มี position เฉพาะ

เลือกเมื่อ: ต้องมีการทำ target recon เชิงลึก, ต้องรอ event เกิดในเวลาเฉพาะ, หรือต้องชนะ race condition

อย่าเลือกเพียงเพราะ: เพิ่งเจอ exploit ครั้งเดียว — ต้องยืนยันว่า condition นอกเหนือการควบคุม attacker

ตัวอย่าง: Race condition ใน filesystem, การโจมตีที่ต้องอยู่ในตำแหน่ง network เฉพาะเพื่อ MITM

ที่มา: CVSS v3.1 §2.1.2 (High) · อ่านเพิ่ม

⚠️ ข้อควรระวัง: AC ไม่ได้วัด 'skill ผู้โจมตี' แต่วัดเงื่อนไขนอกเหนือการควบคุมของผู้โจมตี (เช่น race condition, target-specific)

PR — Privileges Required (สิทธิ์ที่ต้องมี)

ก่อนโจมตี ผู้โจมตีต้องมีสิทธิ์ระดับใดในระบบก่อน

PR:N — None

ไม่ต้อง authenticate ก่อน

เลือกเมื่อ: endpoint เปิดให้ทุกคนใช้ (public API, unauthenticated login form)

อย่าเลือกเพียงเพราะ: endpoint มี /public ในเส้นทาง — ต้องยืนยันว่าไม่มี authentication check ทำจริง

ตัวอย่าง: SQL injection ในหน้า login page ก่อน authenticate

ที่มา: CVSS v3.1 §2.1.3 (None) · อ่านเพิ่ม

PR:L — Low

ต้องเป็นผู้ใช้ทั่วไปที่ยืนยันตัวตนแล้ว มีสิทธิ์ระดับพื้นฐาน

เลือกเมื่อ: ต้อง login ด้วยบัญชีผู้ใช้ปกติ ไม่ต้องเป็น admin

อย่าเลือกเพียงเพราะ: user ต้องกรอกรหัสผ่าน — ถ้ารหัสสร้างเองได้ในระบบ ใช้ Low, ถ้า admin อนุมัติ ใช้ High

ตัวอย่าง: IDOR ที่ผู้ใช้ทั่วไปเข้าถึงข้อมูลของผู้อื่นได้

ที่มา: CVSS v3.1 §2.1.3 (Low) · อ่านเพิ่ม

PR:H — High

ต้องเป็น admin หรือ role พิเศษที่มีสิทธิ์กว้าง

เลือกเมื่อ: ต้องมีสิทธิ์ที่ปกติจำกัดเฉพาะ operator/admin (เช่น root, database admin)

อย่าเลือกเพียงเพราะ: ผู้ใช้ต้องได้รับสิทธิ์เพิ่ม — ถ้าสิทธิ์นั้นได้หลัง signup ให้ใช้ Low

ตัวอย่าง: Command injection ที่ต้องมีสิทธิ์ config server

ที่มา: CVSS v3.1 §2.1.3 (High) · อ่านเพิ่ม

⚠️ ข้อควรระวัง: PR ไม่ใช่ 'สิทธิ์ที่ได้หลังโจมตี' แต่คือ 'สิทธิ์ที่ต้องมีก่อน' — ผู้ใช้ทั่วไป (authenticated user) ให้เลือก Low ไม่ใช่ None

UI — User Interaction (การมีส่วนร่วมของผู้ใช้)

ต้องมีเหยื่อคลิก/เปิดไฟล์/interact อะไรบางอย่างเพื่อให้ exploit ทำงานหรือไม่

UI:N — None

exploit ทำงานได้เอง ไม่ต้องมี user คนอื่นมาช่วย

เลือกเมื่อ: attacker ส่ง payload แล้วรอผลได้เลย

อย่าเลือกเพียงเพราะ: attacker เป็นคนกด — ผู้กระทำที่พิจารณาคือ 'อีกคน' นอก attacker

ตัวอย่าง: RCE ผ่าน network service ที่ไม่ต้อง user คลิก

ที่มา: CVSS v3.1 §2.1.4 (None) · อ่านเพิ่ม

UI:R — Required

ต้องมีเหยื่อคลิกลิงก์, เปิดไฟล์, หรือ approve prompt

เลือกเมื่อ: exploit อาศัย social engineering หรือ user action

อย่าเลือกเพียงเพราะ: user เห็นหน้าจอ warning — ถ้า warning ไม่ได้ปิด attack ให้เลือก N

ตัวอย่าง: Phishing ที่เหยื่อคลิกลิงก์แล้วเปิดหน้าปลอม, macro ในไฟล์ Office

ที่มา: CVSS v3.1 §2.1.4 (Required) · อ่านเพิ่ม

⚠️ ข้อควรระวัง: UI:R ใช้ต่อเมื่อผู้ใช้ 'อีกคน' ต้อง interact — ถ้า attacker เป็นคน interact เอง ให้ N

S — Scope (ขอบเขต)

ช่องโหว่ทำให้ผลกระทบข้ามไปยัง 'component อื่น' ที่มี security authority ต่างกันหรือไม่

S:U — Unchanged

ผลกระทบยังอยู่ใน security authority เดียวกัน

เลือกเมื่อ: ช่องโหว่แค่ทำให้ระบบเดียวกันเสียหาย ไม่แตะ component อื่น

อย่าเลือกเพียงเพราะ: ยังใช้ระบบเดิม — ต้องดูว่า authority ที่รับผิดชอบยังคงเดิม

ตัวอย่าง: XSS ใน single-page app ที่กระทบเฉพาะ user session ของ app นั้น

ที่มา: CVSS v3.1 §2.2 (Unchanged) · อ่านเพิ่ม

S:C — Changed

ช่องโหว่ทำให้ผลกระทบข้าม authority boundary

เลือกเมื่อ: VM escape, container escape, XSS ที่ทะลุ same-origin, sandbox escape

อย่าเลือกเพียงเพราะ: ผลกระทบใหญ่ — Scope วัด boundary crossing เท่านั้น

ตัวอย่าง: Guest OS escape ใน hypervisor ที่ทำให้เข้าถึง Host OS ได้

ที่มา: CVSS v3.1 §2.2 (Changed) · อ่านเพิ่ม

⚠️ ข้อควรระวัง: Scope ไม่ได้วัด 'อันตรายมากขึ้น' แต่วัดว่ามี boundary ข้าม security authority หรือไม่ — VM escape (Guest→Host) = Changed

C — Confidentiality (ผลกระทบต่อความลับ)

ข้อมูลรั่วไหลจากการโจมตีมีผลกระทบระดับใด

C:N — None

ไม่มีข้อมูลใดถูกเปิดเผย

เลือกเมื่อ: ช่องโหว่ไม่ขโมย/อ่านข้อมูล

อย่าเลือกเพียงเพราะ: ข้อมูลไม่สำคัญ — ถ้า attacker อ่านได้ต้องมีอย่างน้อย Low

ตัวอย่าง: DoS ที่ไม่รั่วข้อมูลออกมา

ที่มา: CVSS v3.1 §2.3.1 (None) · อ่านเพิ่ม

C:L — Low

รั่วข้อมูลบางส่วน หรือ attacker ไม่สามารถควบคุมว่าอ่านอะไรได้

เลือกเมื่อ: อ่านได้แต่ไม่เลือก, หรืออ่านได้เฉพาะข้อมูลที่ไม่สำคัญ

อย่าเลือกเพียงเพราะ: ปริมาณข้อมูลน้อย — พิจารณา sensitivity ก่อน

ตัวอย่าง: Server ตอบ error message ที่มี stack trace

ที่มา: CVSS v3.1 §2.3.1 (Low) · อ่านเพิ่ม

C:H — High

ข้อมูลสำคัญรั่ว หรือรั่วทั้งหมด

เลือกเมื่อ: ได้ข้อมูลที่ถ้ารั่วไปแล้วส่งผลกระทบร้ายแรง (credentials, PII, secrets)

อย่าเลือกเพียงเพราะ: ได้ข้อมูลมาก — ต้องดู sensitivity ประกอบ

ตัวอย่าง: Dump credentials database, อ่าน SSL private key

ที่มา: CVSS v3.1 §2.3.1 (High) · อ่านเพิ่ม

I — Integrity (ผลกระทบต่อความถูกต้อง)

attacker แก้ไข/ทำลายข้อมูลหรือระบบได้แค่ไหน

I:N — None

ไม่มีการแก้ไขข้อมูล

เลือกเมื่อ: ช่องโหว่ไม่ให้ write access

อย่าเลือกเพียงเพราะ: ยังไม่เห็นการแก้ไขจริง — ถ้ามี write path ต้องประเมิน

ตัวอย่าง: Read-only information disclosure

ที่มา: CVSS v3.1 §2.3.2 (None) · อ่านเพิ่ม

I:L — Low

แก้ไขได้บ้าง หรือแก้ไขได้แต่ควบคุมไม่ได้ว่าแก้อะไร

เลือกเมื่อ: attacker เขียนได้บางส่วน หรือทำลายข้อมูลได้แต่ไม่เลือก target

อย่าเลือกเพียงเพราะ: แก้แค่ 1 field — ถ้า field นั้นสำคัญ ให้ High

ตัวอย่าง: Attacker แก้ preference user ได้ ไม่แตะ admin config

ที่มา: CVSS v3.1 §2.3.2 (Low) · อ่านเพิ่ม

I:H — High

แก้ไขระบบหรือข้อมูลสำคัญได้ทั้งหมด

เลือกเมื่อ: attacker แก้ config, code, หรือข้อมูลระดับสำคัญได้ครบ

อย่าเลือกเพียงเพราะ: แก้ได้จำนวนมาก — ต้องดู criticality ประกอบ

ตัวอย่าง: Attacker rewrite backend code ผ่าน upload endpoint

ที่มา: CVSS v3.1 §2.3.2 (High) · อ่านเพิ่ม

A — Availability (ผลกระทบต่อความพร้อมใช้)

ช่องโหว่ทำให้ระบบ/บริการไม่พร้อมใช้ได้แค่ไหน

A:N — None

บริการยังทำงานปกติ

เลือกเมื่อ: ช่องโหว่ไม่ทำให้ระบบขัดข้อง

อย่าเลือกเพียงเพราะ: ยังไม่เจอ crash — ถ้ามีทางทำ ให้ประเมิน

ตัวอย่าง: Information leak ที่ไม่กระทบ service uptime

ที่มา: CVSS v3.1 §2.3.3 (None) · อ่านเพิ่ม

A:L — Low

ระบบช้าหรือขัดข้องบางส่วน

เลือกเมื่อ: performance degradation หรือ partial outage

อย่าเลือกเพียงเพราะ: response ช้า — ถ้า service ยังตอบทัน SLA ให้ N

ตัวอย่าง: Slowloris ที่ทำ throughput ลดลง 30%

ที่มา: CVSS v3.1 §2.3.3 (Low) · อ่านเพิ่ม

A:H — High

บริการหยุดทำงานทั้งหมด

เลือกเมื่อ: attacker ทำ complete DoS ได้

อย่าเลือกเพียงเพราะ: เกิด crash ครั้งเดียว — ต้อง repeatable

ตัวอย่าง: Amplification DDoS, Ping of Death ที่ทำระบบดับ

ที่มา: CVSS v3.1 §2.3.3 (High) · อ่านเพิ่ม

Temporal metrics (optional)

E — Exploit Code Maturity (ความพร้อมของ exploit)

ตอนนี้มี exploit ระดับใดหมุนเวียนในโลก

E:X — Not Defined

ยังไม่ประเมิน — engine จะใช้ค่าที่ปลอดภัยที่สุด (H)

เลือกเมื่อ: ยังไม่มีข้อมูลว่ามี exploit หรือไม่

อย่าเลือกเพียงเพราะ: อยากให้คะแนนต่ำ — X ใช้ H ในการคำนวณ ไม่ได้ลดคะแนน

ตัวอย่าง: ช่องโหว่เพิ่งเปิดเผย ยังไม่มี PoC สาธารณะ

ที่มา: CVSS v3.1 §3.1.1 (X) · อ่านเพิ่ม

E:H — High

มี exploit ที่ใช้งานได้จริงและ automated tool ใช้อยู่

เลือกเมื่อ: มี exploit ใน Metasploit / commodity malware

อย่าเลือกเพียงเพราะ: เห็นข่าว — ต้องยืนยันว่าใช้จริงในภาคสนาม

ตัวอย่าง: EternalBlue, Log4Shell ในช่วงหลังเปิดเผยหลายเดือน

ที่มา: CVSS v3.1 §3.1.1 (High) · อ่านเพิ่ม

E:F — Functional

PoC ทำงานได้ในหลายสภาพแวดล้อม แต่ยังไม่ automated

เลือกเมื่อ: มี exploit script ที่พร้อมรัน

อย่าเลือกเพียงเพราะ: มี PoC ครั้งเดียว — ต้องทำงานได้หลาย target

ตัวอย่าง: GitHub PoC ที่ยิงได้ทั้ง 3 major versions

ที่มา: CVSS v3.1 §3.1.1 (Functional) · อ่านเพิ่ม

E:P — Proof-of-Concept

PoC ทำงานเฉพาะสภาพแวดล้อมทดสอบ

เลือกเมื่อ: PoC ที่รันได้ครั้งเดียวในห้องแล็บ

อย่าเลือกเพียงเพราะ: มี screenshot — ต้องมี code ที่ rerun ได้

ตัวอย่าง: Video demo ที่ต้อง setup เฉพาะ

ที่มา: CVSS v3.1 §3.1.1 (Proof-of-Concept) · อ่านเพิ่ม

E:U — Unproven

ยังไม่มี exploit ที่ใช้งานได้ — theoretical only

เลือกเมื่อ: รู้ว่าเสี่ยงจาก code review แต่ยังไม่มี working PoC

อย่าเลือกเพียงเพราะ: ยังไม่เจอในสาธารณะ — ถ้ามี PoC ใช้ P

ตัวอย่าง: Vendor แจ้งช่องโหว่แต่ยังไม่ปล่อย PoC

ที่มา: CVSS v3.1 §3.1.1 (Unproven) · อ่านเพิ่ม

RL — Remediation Level (ระดับการแก้ไข)

ตอนนี้มีวิธีแก้ระดับใด

RL:X — Not Defined

ยังไม่ประเมิน — ใช้ U (worst case) ในการคำนวณ

เลือกเมื่อ: ไม่ทราบสถานะ patch

อย่าเลือกเพียงเพราะ: ยังไม่ตรวจ — ควรตรวจแล้วเลือกค่าจริง

ตัวอย่าง: รอ vendor confirm

ที่มา: CVSS v3.1 §3.1.2 (X) · อ่านเพิ่ม

RL:U — Unavailable

ยังไม่มีวิธีแก้

เลือกเมื่อ: vendor ยังไม่ปล่อย patch หรือ workaround

อย่าเลือกเพียงเพราะ: ยังไม่ได้ติดตั้ง — ต้องดูว่ามี patch มีขายไหม

ตัวอย่าง: 0-day ที่เพิ่งเปิดเผย vendor ยังไม่ตอบ

ที่มา: CVSS v3.1 §3.1.2 (Unavailable) · อ่านเพิ่ม

RL:W — Workaround

มี workaround จาก community/consultant

เลือกเมื่อ: มีวิธีปิดชั่วคราวที่ไม่ใช่ official

อย่าเลือกเพียงเพราะ: อ่านเจอใน blog — ต้องเป็น workaround ที่พิสูจน์แล้ว

ตัวอย่าง: Community rule สำหรับ WAF ที่ block ช่องโหว่

ที่มา: CVSS v3.1 §3.1.2 (Workaround) · อ่านเพิ่ม

RL:T — Temporary Fix

vendor ปล่อย hotfix ชั่วคราว รอ patch อย่างเป็นทางการ

เลือกเมื่อ: มี hotfix อย่างเป็นทางการ

อย่าเลือกเพียงเพราะ: vendor ยืนยันจะปล่อยเร็ว ๆ นี้ — ต้องมี hotfix ในมือ

ตัวอย่าง: Microsoft ปล่อย out-of-band update

ที่มา: CVSS v3.1 §3.1.2 (Temporary Fix) · อ่านเพิ่ม

RL:O — Official Fix

มี patch อย่างเป็นทางการ

เลือกเมื่อ: vendor ปล่อย patch เต็ม

อย่าเลือกเพียงเพราะ: patch ปล่อยแล้ว — ถ้าองค์กรยังไม่ได้ติดตั้ง ก็ยัง O เพราะ RL วัด availability ไม่ใช่ deployment

ตัวอย่าง: Microsoft Patch Tuesday ที่ปิดช่องโหว่

ที่มา: CVSS v3.1 §3.1.2 (Official Fix) · อ่านเพิ่ม

RC — Report Confidence (ความเชื่อมั่นของรายงาน)

รายงานช่องโหว่นี้เชื่อได้แค่ไหน

RC:X — Not Defined

ยังไม่ประเมิน — engine ใช้ C (worst case)

เลือกเมื่อ: รอข้อมูลเพิ่ม

อย่าเลือกเพียงเพราะ: ไม่แน่ใจ — เลือก U/R/C ตรง ๆ

ตัวอย่าง: รายงานเบื้องต้นยังไม่ตรวจสอบ

ที่มา: CVSS v3.1 §3.1.3 (X) · อ่านเพิ่ม

RC:C — Confirmed

vendor ยืนยันหรือมี technical detail ครบ

เลือกเมื่อ: มี CVE + vendor advisory ยืนยัน

อย่าเลือกเพียงเพราะ: มีข่าวเยอะ — ต้องมี vendor / researcher ยืนยัน

ตัวอย่าง: Microsoft ยืนยัน CVE ผ่าน MSRC

ที่มา: CVSS v3.1 §3.1.3 (Confirmed) · อ่านเพิ่ม

RC:R — Reasonable

รายงานมี detail พอสมควร แต่ยังไม่ยืนยัน

เลือกเมื่อ: researcher เผยแพร่รายละเอียดแต่ vendor ยังไม่ตอบ

อย่าเลือกเพียงเพราะ: เห็น GitHub issue — ต้องมี technical detail

ตัวอย่าง: รายงานจาก security researcher ที่มีชื่อเสียง

ที่มา: CVSS v3.1 §3.1.3 (Reasonable) · อ่านเพิ่ม

RC:U — Unknown

มีข่าวลือหรือ report ที่ไม่มี detail

เลือกเมื่อ: รายงานยังไม่มีหลักฐาน technical

อย่าเลือกเพียงเพราะ: ไม่รู้ — ถ้าไม่มีหลักฐานเลย U ถูก

ตัวอย่าง: Rumor ในฟอรัมไม่มี PoC

ที่มา: CVSS v3.1 §3.1.3 (Unknown) · อ่านเพิ่ม

Environmental metrics (optional)

CR — Confidentiality Requirement (ความสำคัญของความลับในองค์กร)

องค์กรให้ความสำคัญกับ confidentiality ของระบบนี้ระดับใด

CR:X — Not Defined

ยังไม่ประเมิน — ใช้ M (medium)

เลือกเมื่อ: ไม่ทราบ

อย่าเลือกเพียงเพราะ: ขี้เกียจกรอก — ควรมี value จริง

ตัวอย่าง: ระบบใหม่ยังไม่จัดระดับ

ที่มา: CVSS v3.1 §4.1 (X) · อ่านเพิ่ม

CR:H — High

ถ้าข้อมูลรั่ว จะเสียหายร้ายแรง

เลือกเมื่อ: ข้อมูล PII, credentials, secrets, trade secret

อย่าเลือกเพียงเพราะ: องค์กรใหญ่ — ต้องดู classification ของระบบเฉพาะ

ตัวอย่าง: Database credit card

ที่มา: CVSS v3.1 §4.1 (H) · อ่านเพิ่ม

CR:M — Medium

ผลกระทบปานกลาง

เลือกเมื่อ: ข้อมูลภายในแต่ไม่ลับ

อย่าเลือกเพียงเพราะ: default — พิจารณา actual value

ตัวอย่าง: รายชื่อพนักงาน

ที่มา: CVSS v3.1 §4.1 (M) · อ่านเพิ่ม

CR:L — Low

ผลกระทบน้อย

เลือกเมื่อ: ข้อมูลสาธารณะอยู่แล้ว

อย่าเลือกเพียงเพราะ: อยากลด score — ต้องมีเหตุผลจริง

ตัวอย่าง: Marketing site content

ที่มา: CVSS v3.1 §4.1 (L) · อ่านเพิ่ม

IR — Integrity Requirement (ความสำคัญของความถูกต้องในองค์กร)

ผลกระทบถ้าข้อมูลถูกแก้ไขในระบบนี้

IR:X — Not Defined

ใช้ M (medium)

เลือกเมื่อ: ไม่ทราบ

อย่าเลือกเพียงเพราะ: ขี้เกียจกรอก

ตัวอย่าง: ระบบใหม่

ที่มา: CVSS v3.1 §4.1 (X) · อ่านเพิ่ม

IR:H — High

ถ้าข้อมูลถูกแก้ จะเกิดความเสียหายร้ายแรง

เลือกเมื่อ: ระบบธนาคาร, ระบบการแพทย์, DNS, critical config

อย่าเลือกเพียงเพราะ: ระบบใหญ่ — ดู criticality จริง

ตัวอย่าง: Bank ledger

ที่มา: CVSS v3.1 §4.1 (H) · อ่านเพิ่ม

IR:M — Medium

ผลกระทบปานกลาง

เลือกเมื่อ: ข้อมูลผู้ใช้ทั่วไป

อย่าเลือกเพียงเพราะ: default

ตัวอย่าง: User profile

ที่มา: CVSS v3.1 §4.1 (M) · อ่านเพิ่ม

IR:L — Low

การแก้ไขไม่กระทบธุรกิจ

เลือกเมื่อ: อ่านเท่านั้น หรือคืนสภาพได้ง่าย

อย่าเลือกเพียงเพราะ: อยากลด score

ตัวอย่าง: Log verbose

ที่มา: CVSS v3.1 §4.1 (L) · อ่านเพิ่ม

AR — Availability Requirement (ความสำคัญของความพร้อมใช้ในองค์กร)

ผลกระทบถ้าระบบนี้ล่ม

AR:X — Not Defined

ใช้ M (medium)

เลือกเมื่อ: ไม่ทราบ

อย่าเลือกเพียงเพราะ: ขี้เกียจกรอก

ตัวอย่าง: ระบบใหม่

ที่มา: CVSS v3.1 §4.1 (X) · อ่านเพิ่ม

AR:H — High

ระบบ mission-critical

เลือกเมื่อ: core banking, ระบบ 24/7, healthcare EMR

อย่าเลือกเพียงเพราะ: 24/7 uptime — ดู business criticality

ตัวอย่าง: ATM network

ที่มา: CVSS v3.1 §4.1 (H) · อ่านเพิ่ม

AR:M — Medium

downtime ยอมรับได้บ้าง

เลือกเมื่อ: internal tool ที่มี backup

อย่าเลือกเพียงเพราะ: default

ตัวอย่าง: HR system

ที่มา: CVSS v3.1 §4.1 (M) · อ่านเพิ่ม

AR:L — Low

downtime ไม่กระทบ

เลือกเมื่อ: reporting system ที่ใช้เดือนละครั้ง

อย่าเลือกเพียงเพราะ: อยากลด score

ตัวอย่าง: Batch report

ที่มา: CVSS v3.1 §4.1 (L) · อ่านเพิ่ม

ผลลัพธ์

เลือก Base metrics ให้ครบ 8 ตัว เพื่อดูคะแนน

Base Score-

Temporal Score-

Environmental Score-

Overall-

Vector:

รายละเอียดการคำนวณ

Impact: -
Exploitability: -
Modified Impact: -
Modified Exploitability: -