กรณีการใช้งานผิดวิธี (Misuse case)เป็น เครื่องมือ สร้างแบบจำลองกระบวนการทางธุรกิจที่ใช้ในอุตสาหกรรมการพัฒนาซอฟต์แวร์ คำว่าMisuse Caseหรือmis-use caseมาจากและเป็นคำตรงข้ามของUse Case [ ^{1 ] คำ}นี้ถูกใช้ครั้งแรกในช่วงทศวรรษ 1990 โดย Guttorm Sindre จากมหาวิทยาลัยวิทยาศาสตร์และเทคโนโลยีแห่งนอร์เวย์และAndreas L. Opdahlจากมหาวิทยาลัยเบอร์เกน ประเทศนอร์เวย์ คำนี้อธิบายถึงกระบวนการดำเนินการที่เป็นอันตรายต่อระบบ ในขณะที่ Use Case สามารถใช้เพื่ออธิบายการกระทำใดๆ ที่ระบบดำเนินการได้^{[ 2 ]}

กรณีการใช้งาน (Use Case) ระบุพฤติกรรมที่ต้องการของซอฟต์แวร์และผลิตภัณฑ์อื่นๆ ที่กำลังพัฒนา โดยพื้นฐานแล้วเป็นเรื่องราวหรือสถานการณ์ ที่มีโครงสร้าง ซึ่งอธิบายรายละเอียดพฤติกรรมและการใช้งานปกติของซอฟต์แวร์ ในทางกลับกัน กรณีการใช้งานผิดวิธี (Misuse Case) เน้นสิ่งที่ไม่ควรเกิดขึ้น (เช่น สถานการณ์เชิงลบ) และภัยคุกคามที่ระบุได้นั้นจะช่วยในการกำหนดข้อกำหนดใหม่ ซึ่งแสดงออกมาในรูปของกรณีการใช้งานใหม่

เครื่องมือสร้างแบบจำลองนี้มีจุดแข็งหลายประการ:

• เครื่องมือนี้ช่วยให้สามารถกำหนดน้ำหนักที่เท่าเทียมกันให้กับข้อกำหนดด้านฟังก์ชันการทำงานและข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (เช่น ข้อกำหนดด้านความปลอดภัย ข้อกำหนดของแพลตฟอร์ม เป็นต้น) ซึ่งอาจเป็นไปไม่ได้ในเครื่องมืออื่นๆ
• แนวคิดนี้ให้ความสำคัญกับความปลอดภัยตั้งแต่เริ่มต้นกระบวนการออกแบบ และช่วยหลีกเลี่ยงการตัดสินใจออกแบบที่เร่งรีบ
• เป็นเครื่องมือสำหรับปรับปรุงการสื่อสารระหว่างนักพัฒนาและผู้มีส่วนได้ส่วนเสีย และมีคุณค่าในการรับประกันว่าทั้งสองฝ่ายเห็นพ้องต้องกันในโซลูชันระบบที่สำคัญและการวิเคราะห์การแลกเปลี่ยน^{[ 3 ]}
• การสร้างกรณีการใช้งานที่ไม่ถูกต้องมักจะก่อให้เกิดปฏิกิริยาลูกโซ่ซึ่งทำให้การระบุข้อกำหนดด้านฟังก์ชันและไม่ใช่ฟังก์ชันทำได้ง่ายขึ้น การค้นพบกรณีการใช้งานที่ไม่ถูกต้องมักจะนำไปสู่การสร้างกรณีการใช้งานใหม่ที่ทำหน้าที่เป็นมาตรการตอบโต้ ซึ่งในทางกลับกันอาจเป็นหัวข้อของกรณีการใช้งานที่ไม่ถูกต้องใหม่^{[ 4 ]}
• เมื่อเปรียบเทียบกับเครื่องมืออื่นๆ เครื่องมือนี้สอดคล้องกับกรณีการใช้งานและUML ได้ดีกว่า และช่วยให้การนำแบบจำลองไปใช้เป็นไปอย่างราบรื่น

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

ในอุตสาหกรรม การอธิบายพฤติกรรมของระบบเมื่อตอบสนองต่อคำขอที่มาจากภายนอกเป็นสิ่งสำคัญ: กรณีการใช้งาน^{[ 5 ]}ได้รับความนิยมสำหรับข้อกำหนด^{[ 1 ]}ระหว่างวิศวกรเนื่องจากคุณสมบัติเช่นเทคนิคการสร้างแบบจำลองภาพ โดยจะอธิบายระบบจากมุมมองของผู้ใช้งาน และรูปแบบจะสื่อถึงเป้าหมายของผู้ใช้งานแต่ละรายและขั้นตอนที่ระบบต้องดำเนินการเพื่อให้บรรลุเป้าหมายเหล่านั้นอย่างชัดเจน^{[ 6 ]}

ระดับนามธรรมของแบบจำลองกรณีการใช้งานทำให้มันเป็นจุดเริ่มต้นที่เหมาะสมสำหรับกิจกรรมการออกแบบ ด้วยการใช้ แผนภาพกรณีการใช้งาน UMLและภาษาของผู้ใช้ปลายทางหรือผู้เชี่ยวชาญในสาขา แต่สำหรับการวิเคราะห์ความปลอดภัยของซอฟต์แวร์ นักพัฒนาควรให้ความสนใจกับสถานการณ์เชิงลบและทำความเข้าใจมัน นั่นคือเหตุผลที่ในทศวรรษ 1990 แนวคิดของ "กรณีการใช้งานผกผัน" จึงถือกำเนิดขึ้นใน นอร์เวย์

ความแตกต่างระหว่างกรณีการใช้งานผิดวิธีและกรณีการใช้งานปกติอยู่ที่เป้าหมาย: กรณีการใช้งานผิดวิธีอธิบายถึงพฤติกรรมของระบบที่อาจเกิดขึ้นซึ่งผู้มีส่วนได้ส่วนเสียของระบบพิจารณาว่ายอมรับไม่ได้ หรือตามที่ Guttorm Sindre และ Andreas L. Opdahl กล่าวไว้ว่า "เป็นฟังก์ชันที่ระบบไม่ควรอนุญาต" ^{[ 1 ]} ความแตกต่างนี้ยังอยู่ที่สถานการณ์ด้วย: สถานการณ์ "เชิงบวก" คือลำดับของการกระทำที่นำไปสู่เป้าหมายที่บุคคลหรือองค์กรต้องการ ในขณะที่สถานการณ์ "เชิงลบ" คือสถานการณ์ที่เป้าหมายนั้นไม่ต้องการให้เกิดขึ้นโดยองค์กรที่เกี่ยวข้อง หรือโดยตัวแทนที่เป็นศัตรู (ไม่จำเป็นต้องเป็นมนุษย์) ^{[ 7 ]}

คำอธิบายความแตกต่างอีกประการหนึ่งคือ^{[ 8 ]}ซึ่งกำหนดกรณีการใช้งานเป็นลำดับการกระทำที่เสร็จสมบูรณ์ซึ่งให้คุณค่าเพิ่มขึ้นแก่ผู้ใช้ เราอาจกำหนดกรณีการใช้งานที่ผิดพลาดเป็นลำดับการกระทำที่เสร็จสมบูรณ์ซึ่งส่งผลให้เกิดความสูญเสียต่อองค์กรหรือผู้มีส่วนได้ส่วนเสียเฉพาะรายใดรายหนึ่ง

ระหว่างกรณี "ดี" และ "ไม่ดี" ภาษาที่ใช้ในการแสดงสถานการณ์นั้นเหมือนกัน: แผนภาพกรณีการใช้งานถูกรวมไว้ในภาษาการสร้างแบบจำลองสองภาษาที่กำหนดโดยOMG อย่างเป็นทางการ ได้แก่Unified Modeling Language (UML) และSystems Modeling Language (SysML) และการใช้การวาดตัวแทนและกรณีการใช้งานที่ไม่ถูกต้องของสถานการณ์อย่างชัดเจนนี้ช่วยให้สามารถมุ่งเน้นความสนใจไปที่สถานการณ์นั้นได้^{[ 9 ]}

กรณีการใช้งานในทางที่ผิดมักพบได้บ่อยในด้านความปลอดภัย^{[ 10 ]}ด้วยความสำคัญของระบบไอทีที่เพิ่มมากขึ้นเรื่อยๆ จึงจำเป็นอย่างยิ่งที่ทุกบริษัทจะต้องพัฒนาความสามารถในการปกป้องข้อมูลของตน^{[ 11 ]}

ดังนั้น ตัวอย่างเช่น กรณีการใช้งานที่ไม่เหมาะสมอาจใช้เพื่อกำหนดสิ่งที่แฮ็กเกอร์ต้องการทำกับระบบและกำหนดข้อกำหนดของเขาหรือเธอ จากนั้นนักพัฒนาหรือนักออกแบบสามารถกำหนดข้อกำหนดของผู้ใช้และแฮ็กเกอร์ในแผนภาพ UML เดียวกัน ซึ่งจะช่วยระบุความเสี่ยงด้านความปลอดภัยของระบบได้^{[ 12 ]}

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

• กรณีการใช้งานในทางที่ผิด  : ลำดับของการกระทำที่บุคคลหรือหน่วยงานใดๆ สามารถกระทำได้เพื่อก่อให้เกิดความเสียหายต่อระบบ
• ผู้ใช้ในทางที่ผิด  : บุคคลที่ก่อให้เกิดกรณีการใช้งานในทางที่ผิด ซึ่งอาจกระทำโดยเจตนาหรือโดยไม่เจตนา

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

บรรเทา

กรณีการใช้งานสามารถลดโอกาสที่กรณีการใช้งานที่ไม่ถูกต้องจะสำเร็จลุล่วงได้

คุกคาม

กรณีการใช้งานที่ไม่เหมาะสมอาจเป็นภัยคุกคามต่อกรณีการใช้งานหลัก เช่น การใช้ประโยชน์จากช่องโหว่ หรือขัดขวางไม่ให้บรรลุเป้าหมายที่ตั้งไว้

แนวคิดใหม่เหล่านี้ร่วมกับแนวคิดที่มีอยู่จากกรณีการใช้งานทำให้เกิดแบบจำลองเมตาต่อไปนี้ ซึ่งพบได้ในรูปที่ 2 ใน Sindre และ Opdahl (2004) ^{[ 2 ]}

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

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

• ชื่อกรณีการใช้งานที่ไม่ถูกต้อง
• สรุป
• ผู้เขียน
• วันที่
• เส้นทางพื้นฐาน
• เส้นทางทางเลือก
• จุดบรรเทาผลกระทบ
• จุดต่อขยาย
• ตัวกระตุ้น
• เงื่อนไขเบื้องต้น
• ข้อสมมติฐาน
• การรับประกันการบรรเทา
• กฎธุรกิจที่เกี่ยวข้อง
• โปรไฟล์ผู้ใช้ที่อาจถูกนำไปใช้ในทางที่ผิด
• ผู้มีส่วนได้ส่วนเสียและภัยคุกคาม
• คำศัพท์และคำอธิบาย
• ขอบเขต
• ระดับนามธรรม
• ระดับความแม่นยำ

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

Sindre และ Opdahl เสนอ 5 ขั้นตอนต่อไปนี้สำหรับการใช้กรณีการใช้งานที่ไม่เหมาะสมเพื่อระบุข้อกำหนดด้านความปลอดภัย:

1. ระบุสินทรัพย์ที่สำคัญในระบบ
2. กำหนดเป้าหมายด้านความปลอดภัยสำหรับสินทรัพย์แต่ละรายการ
3. ระบุภัยคุกคามต่อเป้าหมายด้านความปลอดภัยแต่ละข้อ โดยระบุผู้มีส่วนได้ส่วนเสียที่อาจต้องการก่อให้เกิดอันตรายต่อระบบ
4. ระบุและวิเคราะห์ความเสี่ยงจากภัยคุกคาม โดยใช้เทคนิคต่างๆ เช่นการประเมินความเสี่ยง
5. กำหนดข้อกำหนดด้านความปลอดภัยสำหรับความเสี่ยงต่างๆ

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

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

งานวิจัยอื่น ๆ มุ่งเน้นไปที่การปรับปรุงกรณีการใช้งานในทางที่ผิดเพื่อให้บรรลุเป้าหมายสุดท้าย: สำหรับ^{[ 13 ]} "มีการขาดแคลนในกระบวนการใช้งาน และผลลัพธ์นั้นทั่วไปเกินไปและอาจทำให้เกิดการกำหนดที่ไม่ชัดเจนหรือการตีความแนวคิดผิดพลาด" พวกเขายังแนะนำเพิ่มเติมว่า "ควรพิจารณากรณีการใช้งานในทางที่ผิดโดยอ้างอิงจากแบบจำลองอ้างอิงสำหรับการจัดการความเสี่ยงด้านความปลอดภัยของระบบสารสนเทศ (ISSRM)" เพื่อให้ได้กระบวนการจัดการความเสี่ยงด้านความปลอดภัย

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

ดังที่ Sindre และ Opdahl (ผู้ริเริ่มแนวคิดกรณีการใช้งานผิดวิธี) แนะนำว่า “เป้าหมายสำคัญอีกประการหนึ่งสำหรับการทำงานต่อไปคือการอำนวยความสะดวกในการนำกรณีการใช้งานผิดวิธีไปใช้ในอุตสาหกรรมในวงกว้าง” ^{[ 2 ]}ในบทความเดียวกัน พวกเขาเสนอให้ฝังกรณีการใช้งานผิดวิธีไว้ในเครื่องมือสร้างแบบจำลองกรณีการใช้งาน และสร้าง “ฐานข้อมูล” ของกรณีการใช้งานผิดวิธีมาตรฐานเพื่อช่วยสถาปนิกซอฟต์แวร์ ผู้มีส่วนได้ส่วนเสียของระบบควรสร้างแผนภูมิกรณีการใช้งานผิดวิธีของตนเองสำหรับข้อกำหนดที่เฉพาะเจาะจงกับโดเมนปัญหาของตนเอง เมื่อพัฒนาแล้ว ฐานข้อมูลความรู้สามารถลดจำนวนช่องโหว่ด้านความปลอดภัยมาตรฐานที่แฮกเกอร์ Lambda ใช้ได้

งานวิจัยอื่น ๆ มุ่งเน้นไปที่วิธีแก้ปัญหาที่เป็นรูปธรรมที่อาจขาดหายไปในกรณีการใช้งานในทางที่ผิด ดังที่^{[ 14 ]}เขียนไว้ว่า "แม้ว่าแนวทางนี้จะช่วยในการดึงข้อมูลข้อกำหนดด้านความปลอดภัยในระดับสูงได้ แต่ก็ไม่ได้แสดงวิธีการเชื่อมโยงกรณีการใช้งานในทางที่ผิดกับพฤติกรรมที่ถูกต้องตามกฎหมายและสินทรัพย์ที่เป็นรูปธรรม ดังนั้นจึงไม่ชัดเจนว่าควรพิจารณากรณีการใช้งานในทางที่ผิดใด หรือในบริบทใด" ข้อวิจารณ์เหล่านี้อาจได้รับการแก้ไขด้วยข้อเสนอแนะและการปรับปรุงที่นำเสนอในส่วนของแบบอย่าง

การกำหนดมาตรฐานกรณีการใช้งานที่ไม่เหมาะสมเป็นส่วนหนึ่งของสัญกรณ์ UML อาจทำให้กลายเป็นส่วนบังคับของการพัฒนาโครงการได้ “การสร้างสัญกรณ์เฉพาะสำหรับฟังก์ชันการรักษาความปลอดภัยหรือมาตรการตอบโต้ที่เพิ่มเข้ามาเพื่อลดช่องโหว่และภัยคุกคามอาจเป็นประโยชน์” ^{[ 15 ]}

• แผนภาพกรณีการใช้งาน
• ขั้นตอนสำหรับนักวิเคราะห์ธุรกิจในการรวบรวมข้อกำหนดด้านความปลอดภัยจากกรณีการใช้งานในทางที่ผิด[1]
• การจัดการข้อยกเว้น
• แบบจำลองภัยคุกคาม (ซอฟต์แวร์)