ตัวอย่างอุบัติเหตุและเหตุการณ์การบิน คำอธิบายของกระบวนการจัดการบริการไอทีที่สำคัญ การจัดการระดับการบริการ

ถูกต้อง บทบรรณาธิการจาก 27.12.2007

ชื่อเอกสาร	"มาตรฐานแห่งชาติของสหพันธรัฐรัสเซีย เทคโนโลยีสารสนเทศ วิธีการและวิธีการรักษาความปลอดภัย การจัดการเหตุการณ์ด้านความปลอดภัยของข้อมูล GOST R ISO/IEC ถึง 18044-2007" (อนุมัติโดยคำสั่งของ Rostekhregulirovaniya ลงวันที่ 27 .12.2007 N 513-st)
ประเภทเอกสาร	คำสั่งมาตรฐาน gost
การรับมอบอำนาจ	Rostekhregulirovanie
หมายเลขเอกสาร	18044-2007
วันที่รับ	01.01.1970
วันที่แก้ไข	27.12.2007
วันที่จดทะเบียนกับกระทรวงยุติธรรม	01.01.1970
สถานะ	ถูกต้อง
สิ่งตีพิมพ์	ในขณะที่รวมไว้ในฐานข้อมูล เอกสารดังกล่าวไม่ได้รับการเผยแพร่
นาวิเกเตอร์	หมายเหตุ

"มาตรฐานแห่งชาติของสหพันธรัฐรัสเซีย เทคโนโลยีสารสนเทศ วิธีการและวิธีการรักษาความปลอดภัย การจัดการเหตุการณ์ด้านความปลอดภัยของข้อมูล GOST R ISO/IEC ถึง 18044-2007" (อนุมัติโดยคำสั่งของ Rostekhregulirovaniya ลงวันที่ 27 .12.2007 N 513-st)

6 ตัวอย่างเหตุการณ์ ความปลอดภัยของข้อมูลและเหตุผลของพวกเขา

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

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

6.1 การปฏิเสธการให้บริการ

การปฏิเสธการให้บริการเป็นเหตุการณ์ด้านความปลอดภัยของข้อมูลประเภทกว้าง ๆ ที่มีสิ่งหนึ่งที่เหมือนกัน

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

เหตุการณ์ความปลอดภัยของข้อมูลมีสองประเภทหลักที่เกี่ยวข้องกับการปฏิเสธการให้บริการที่เกิดจากวิธีการทางเทคนิค: การทำลายทรัพยากรและการสูญเสียทรัพยากร

ตัวอย่างทั่วไปของเหตุการณ์ "การปฏิเสธการให้บริการ" ด้านความปลอดภัยของข้อมูลทางเทคนิคโดยเจตนา ได้แก่:

การตรวจสอบที่อยู่การออกอากาศเครือข่ายเพื่อเติมเต็มแบนด์วิดท์เครือข่ายด้วยการรับส่งข้อมูลข้อความตอบกลับ

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

การเปิดหลายเซสชันพร้อมกันไปยังระบบ บริการ หรือเครือข่ายเฉพาะเพื่อพยายามใช้ทรัพยากรจนหมด (เช่น ทำให้ช้าลง บล็อก หรือทำลาย)

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

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

เหตุการณ์ “การปฏิเสธการให้บริการ” ของ IS ที่สร้างขึ้นโดยวิธีการที่ไม่ใช่ทางเทคนิค และนำไปสู่การสูญเสียข้อมูล บริการ และ (หรือ) อุปกรณ์ประมวลผลข้อมูลอาจเกิดขึ้นได้ เช่น จากปัจจัยต่อไปนี้:

การละเมิดระบบรักษาความปลอดภัยทางกายภาพที่นำไปสู่การโจรกรรม ความเสียหายโดยเจตนา หรือการทำลายอุปกรณ์

ความเสียหายโดยอุบัติเหตุต่ออุปกรณ์และ (หรือ) ตำแหน่งของอุปกรณ์จากไฟไหม้หรือน้ำ/น้ำท่วม

สภาวะสุดขั้ว สิ่งแวดล้อมเช่น อุณหภูมิสูง (เนื่องจากระบบปรับอากาศขัดข้อง)

การทำงานไม่ถูกต้องหรือการโอเวอร์โหลดของระบบ

การเปลี่ยนแปลงที่ไม่สามารถควบคุมได้ในระบบ

การทำงานของซอฟต์แวร์หรือฮาร์ดแวร์ไม่ถูกต้อง

6.2 การรวบรวมข้อมูล

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

การมีอยู่ของเป้าหมาย การทำความเข้าใจเกี่ยวกับโทโพโลยีเครือข่ายโดยรอบ และผู้ที่เป้าหมายนี้มักจะเชื่อมโยงกันด้วยการแลกเปลี่ยนข้อมูล

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

ตัวอย่างการโจมตีทั่วไปที่มุ่งรวบรวมข้อมูลด้วยวิธีทางเทคนิค ได้แก่:

การรีเซ็ตระเบียน DNS (Domain Name System) สำหรับโดเมนอินเทอร์เน็ตเป้าหมาย (การถ่ายโอนโซน DNS)

การส่งคำขอทดสอบไปยังที่อยู่เครือข่ายแบบสุ่มเพื่อค้นหาระบบการทำงาน

การตรวจสอบระบบเพื่อระบุระบบปฏิบัติการโฮสต์ (เช่น ตามผลรวมไฟล์)

การสแกนพอร์ตเครือข่ายที่มีอยู่สำหรับระบบโปรโตคอลการถ่ายโอนไฟล์เพื่อระบุบริการที่เกี่ยวข้อง (เช่น อีเมล FTP เครือข่าย ฯลฯ) และเวอร์ชันซอฟต์แวร์ของบริการเหล่านี้

การสแกนบริการหนึ่งรายการขึ้นไปที่มีช่องโหว่ที่ทราบทั่วช่วงที่อยู่เครือข่าย (การสแกนแนวนอน)

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

เหตุการณ์การรวบรวมข่าวกรองที่สร้างขึ้นโดยวิธีการที่ไม่ใช่ด้านเทคนิคส่งผลให้:

การเปิดเผยหรือแก้ไขข้อมูลโดยตรงหรือโดยอ้อม;

การโจรกรรมทรัพย์สินทางปัญญาที่จัดเก็บในรูปแบบอิเล็กทรอนิกส์

การละเมิดบันทึก เช่น เมื่อลงทะเบียนบัญชี

การใช้ระบบข้อมูลในทางที่ผิด (เช่น ละเมิดกฎหมายหรือนโยบายองค์กร)

เหตุการณ์อาจมีสาเหตุ เช่น จากปัจจัยต่อไปนี้:

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

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

6.3 การเข้าถึงโดยไม่ได้รับอนุญาต

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

ความพยายามที่จะแยกไฟล์ด้วยรหัสผ่าน

การโจมตีบัฟเฟอร์ล้นเพื่อให้ได้รับสิทธิพิเศษ (เช่น ในระดับผู้ดูแลระบบ) เข้าถึงเครือข่าย

การใช้ประโยชน์จากช่องโหว่ของโปรโตคอลเพื่อสกัดกั้นการเชื่อมต่อหรือเปลี่ยนเส้นทางการเชื่อมต่อเครือข่ายที่ถูกต้องตามกฎหมาย;

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

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

การทำลายอุปกรณ์ป้องกันทางกายภาพพร้อมการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาตในภายหลัง

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

เหตุการณ์ (เหตุการณ์หรือ อิงค์) – เหตุการณ์ใดๆ (ความล้มเหลว การขอคำปรึกษา ฯลฯ) ที่ไม่ได้เป็นส่วนหนึ่งของการดำเนินงานปกติของบริการ ซึ่งนำไปสู่/อาจนำไปสู่การหยุดให้บริการหรือทำให้ระดับคุณภาพลดลง

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

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

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

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

มีการยกระดับการทำงานและลำดับชั้น:

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

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

การกำหนดเส้นทางเหตุการณ์ หรือการยกระดับการทำงาน ถูกกำหนดโดยระดับความรู้ อำนาจ และความเร่งด่วนที่ต้องการ การสนับสนุนบรรทัดแรก(เรียกอีกอย่างว่าการสนับสนุนระดับ 1) โดยปกติแล้ว โต๊ะบริการ, บรรทัดที่สอง– หน่วยงานที่รับผิดชอบด้านการจัดการโครงสร้างพื้นฐานด้านไอที ที่สาม- แผนกพัฒนาซอฟต์แวร์และสถาปัตยกรรม และซัพพลายเออร์รายที่สี่ ยิ่งองค์กรเล็กก็ยิ่งน้อย ระดับที่เพิ่มขึ้น- ในองค์กรขนาดใหญ่ ผู้จัดการกระบวนการจัดการเหตุการณ์อาจแต่งตั้ง ผู้ประสานงานเหตุการณ์ในหน่วยงานที่เกี่ยวข้องเพื่อสนับสนุนกิจกรรมของตน ตัวอย่างเช่น ผู้ประสานงานสามารถทำหน้าที่เป็นอินเทอร์เฟซระหว่างกิจกรรมกระบวนการและผู้จัดการสายงานได้ หน่วยขององค์กร- แต่ละคนประสานงานกิจกรรมของกลุ่มสนับสนุนของตนเอง

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

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

แฮงค์ มาร์ควิสข้อเสนอ 6 ประเด็นสำคัญของกระบวนการจัดการเหตุการณ์:

1. การสร้างฐานข้อมูลบันทึกเหตุการณ์ทั้งหมด- มีความจำเป็นต้องบันทึกเหตุการณ์ทั้งหมดที่เกิดขึ้น โดยไม่คำนึงถึงวิธีการรับ (อีเมล โทรศัพท์, แฟกซ์ ฯลฯ) ข้อมูลทั้งหมดเกี่ยวกับความคืบหน้าในการแก้ไขเหตุการณ์ควรถูกบันทึกไว้ในฐานข้อมูลด้วย
2. การสร้างฐานความรู้มันจะถูกเก็บไว้ที่ไหน ข้อมูลเพิ่มเติมเพื่อแก้ไขเหตุการณ์ที่เกิดขึ้น ยิ่งมีข้อมูลมากเท่าไรก็ยิ่งดีเท่านั้น ใน ITIL สิ่งเหล่านี้คือฐานข้อมูลการจัดการการกำหนดค่า (CMDB) และ/หรือระบบการจัดการการกำหนดค่า (CMS)
3. พัฒนาและอนุมัติอย่างชัดเจน คำแนะนำและกฎเกณฑ์ในการจัดการเหตุการณ์(การลงทะเบียน การจำแนกประเภท การจัดลำดับความสำคัญ การวิเคราะห์ ฯลฯ)
4. กำหนดที่เกี่ยวข้องกับ SLA ขั้นตอนที่จะช่วยให้คุณจัดการผลกระทบของเหตุการณ์ต่อธุรกิจของคุณได้
5. สร้าง แบบจำลอง "เหตุการณ์สำคัญ"– ชุดกฎเกณฑ์ที่อธิบายเหตุการณ์ที่ร้ายแรงมากอย่างชัดเจน เหตุการณ์สำคัญคือเหตุการณ์ที่ส่งผลกระทบต่อบริการทางธุรกิจที่สำคัญและ/หรือ จำนวนมากลูกค้าและผู้ใช้ ไม่ว่าในกรณีใด เหตุการณ์ที่เกิดขึ้นจำเป็นต้องได้รับการยกระดับทันที การแจ้งเตือนลูกค้า และการจัดการพิเศษอื่น ๆ ประเด็นทั้งหมดก็คือเหตุการณ์ดังกล่าวต้องการการตอบสนองสูงสุดจากองค์กรไอที
6. แจ้งผู้ที่รายงานเหตุการณ์นี้ให้คุณทราบ เกี่ยวกับสถานะของงาน- คุณจำเป็นต้องรู้ว่าคุณต้องส่งข้อมูลให้ใครและบ่อยเพียงใด ตัวอย่างเช่น คุณสามารถแจ้งให้ลูกค้าและผู้ใช้ทราบเกี่ยวกับเหตุการณ์ดังกล่าวได้ คุณต้องแจ้งให้ทราบด้วยว่าจะไม่สามารถคืนระดับการบริการที่ให้ไว้ตามพารามิเตอร์ที่ตกลงกันในเวลาที่ตกลงกันไว้ได้

หากคุณไม่ได้ดำเนินการอย่างน้อยหนึ่งใน 6 ประเด็นเหล่านี้ คุณสามารถปรับปรุงคุณภาพการบริการได้ตามมาตรฐาน ISO/IEC 20000-1 (การจัดการบริการ) หากคุณนำประเด็นทั้งหมดไปใช้แล้ว เป็นไปได้มากว่าคุณไม่จำเป็นต้องใช้เวลามากมายในการนำกระบวนการจัดการเหตุการณ์ไปใช้อีกต่อไป - มุ่งเน้นไปที่ด้านอื่นๆ ของ ITIL เช่น การจัดการปัญหา (การจัดการปัญหา) หรือ การจัดการการเปลี่ยนแปลง (การจัดการการเปลี่ยนแปลง).

ในบริบท ห้องสมุด ITILเหตุการณ์ต่างๆ ไม่เพียงแต่รวมถึงข้อผิดพลาดด้านฮาร์ดแวร์หรือซอฟต์แวร์เท่านั้น แต่ยังรวมถึงข้อผิดพลาดด้วย คำขอบริการ.

คำขอบริการเป็นการร้องขอจากผู้ใช้บริการเพื่อขอรับการสนับสนุน ข้อมูล คำปรึกษา หรือเอกสาร ซึ่งไม่ใช่ความล้มเหลวของโครงสร้างพื้นฐานด้านไอที

ตัวอย่างการร้องขอบริการ:

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

เพื่อให้สามารถแยกแยะได้” เหตุการณ์จริง" จาก " เหตุการณ์-คำขอบริการ“ ขอแนะนำให้กำหนดหมวดหมู่พิเศษให้กับคำขอบริการ

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

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

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

5.3.1 การประมวลผลเหตุการณ์

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

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

รูปที่ 5.2 แสดงกระบวนการที่เกิดขึ้นระหว่าง วงจรชีวิตเหตุการณ์. ภาคผนวก 5D นำเสนอกระบวนการเหล่านี้จากมุมมองที่แตกต่างกัน

รูปที่ 5.2 - วงจรชีวิตของเหตุการณ์

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

■ ใหม่;.

■ ยอมรับ;.

■ กำหนดเส้นตาย;

■ มอบหมาย/โอนไปยังผู้เชี่ยวชาญ;.

■ กำลังทำงาน (งานระหว่างดำเนินการ, WIP);

■ รอ;.

■ อนุญาต;.

■ ปิดแล้ว.

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

■ ปรับปรุงข้อมูลทางประวัติศาสตร์ ;.

■ เปลี่ยนสถานะ (เช่น จากสถานะ "ใหม่" เป็นสถานะ "อยู่ระหว่างดำเนินการ" หรือ "รอดำเนินการ")

■การเปลี่ยนแปลงผลกระทบทางธุรกิจและลำดับความสำคัญ ;.

■ป้อนเวลาที่ใช้และค่าใช้จ่าย ;.

■ติดตามสถานะการยกระดับ

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

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

■ ชื่อของบุคคลที่ทำการเปลี่ยนแปลงในรายการ;.

■ วันที่และเวลาของการเปลี่ยนแปลง ;.

■ จริงๆ แล้วบุคคลนี้เปลี่ยนแปลงอะไรไปบ้าง (เช่น ลำดับความสำคัญ สถานะ ประวัติศาสตร์)

■ เหตุใดจึงมีการเปลี่ยนแปลง;.

■ เสียเวลา.

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

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

5.3.2 แนวสนับสนุนที่หนึ่ง สอง และสาม

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

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

รูปที่ 5.3 ~ เส้นแนวรับที่หนึ่ง สอง และสาม

5.3.3 การเปรียบเทียบการยกระดับการทำงานและลำดับชั้น

“การยกระดับ” เป็นกลไกที่ช่วยอำนวยความสะดวกในการแก้ไขเหตุการณ์อย่างทันท่วงที สามารถถูกกระตุ้นได้ในขั้นตอนใดก็ได้ของกระบวนการอนุญาต

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

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

5.3.4 ลำดับความสำคัญ

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

ส่วนให้บริการมีบทบาทสำคัญในกระบวนการจัดการเหตุการณ์:

■ เหตุการณ์ทั้งหมดจะถูกรายงานไปยังส่วนให้บริการ และพนักงานจะลงทะเบียนเหตุการณ์ ในกรณีที่เหตุการณ์ถูกสร้างขึ้นโดยอัตโนมัติ กระบวนการยังต้องรวมการลงทะเบียนผ่านทางส่วนให้บริการ

■ เหตุการณ์จำนวนมาก (อาจมากถึง 85% ที่มีทักษะของพนักงานในระดับสูง) จะได้รับการแก้ไขโดยฝ่ายบริการ

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

ด้านล่างนี้คือรายการการดำเนินการหลักที่ดำเนินการโดยส่วนให้บริการหลังจากได้รับการแจ้งเตือนเหตุการณ์:

■ บันทึกข้อมูลพื้นฐาน - รวมถึงเวลาและรายละเอียดของอาการที่ได้รับ;

■ หากมีการร้องขอบริการ คำร้องขอจะได้รับการประมวลผลตามขั้นตอนมาตรฐานในองค์กรนี้

■ เพื่อเสริมบันทึกเหตุการณ์ตาม CMDB องค์ประกอบทางบัญชี (ECs) ที่รายงานว่าเป็นสาเหตุของเหตุการณ์จะถูกเลือก

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

■ ประเมินเหตุการณ์ และหากเป็นไปได้ ให้คำแนะนำในการแก้ไข: ซึ่งมักจะเป็นไปได้สำหรับเหตุการณ์มาตรฐานหรือเมื่อเกิดจากปัญหา/ข้อผิดพลาดที่ทราบ

■ การปิดบันทึกเหตุการณ์หลังจากการแก้ไขสำเร็จ: การเพิ่มข้อมูลเกี่ยวกับการดำเนินการที่เกี่ยวข้องกับการแก้ไขและการตั้งค่ารหัสหมวดหมู่ที่เหมาะสม;.

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

5.3.5 ความสัมพันธ์ระหว่างเหตุการณ์ ปัญหา ข้อผิดพลาดที่ทราบ และการร้องขอการเปลี่ยนแปลง (RFC)

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

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

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

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

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

รูปที่ 5.4 - ความสัมพันธ์ระหว่างเหตุการณ์ ปัญหา ข้อผิดพลาดที่ทราบ และคำขอเปลี่ยนแปลง (RFC)

ดังนั้นเราจึงมีคำจำกัดความดังต่อไปนี้:.

■ ปัญหา: ไม่ทราบสาเหตุที่แท้จริงของเหตุการณ์หนึ่งเหตุการณ์ขึ้นไป

■ ข้อผิดพลาดที่ทราบ: ปัญหาที่ได้รับการวินิจฉัยสำเร็จแล้วและทราบวิธีแก้ปัญหา

■ RFC: การร้องขอการเปลี่ยนแปลงส่วนประกอบใด ๆ ของโครงสร้างพื้นฐานด้านไอทีหรือด้านใด ๆ ของบริการด้านไอที

ปัญหาอาจนำไปสู่เหตุการณ์มากมาย อาจเป็นไปได้ว่าปัญหาจะไม่ได้รับการวินิจฉัยจนกว่าเหตุการณ์ต่างๆ จะเกิดขึ้นในช่วงเวลาหนึ่ง การจัดการปัญหาแตกต่างอย่างมากจากการจัดการเหตุการณ์ ดังนั้นจึงอธิบายไว้ในกระบวนการจัดการปัญหา

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

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

รูปที่ 5.5 - การประมวลผลวิธีแก้ปัญหาและการแก้ไขเหตุการณ์

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

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

11 ตุลาคม 2555 เวลา 10:58 น

การจัดการกับเหตุการณ์ด้านความปลอดภัยของข้อมูล

• ความปลอดภัยของข้อมูล

สวัสดีตอนบ่ายฮับราฮาเบอร์ที่รัก!

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

การรายงานเหตุการณ์

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

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

2. ข้อความโดยตรงจากผู้ใช้
จัดระเบียบจุดติดต่อจุดเดียวและสื่อสารสิ่งนี้ในการฝึกอบรมความปลอดภัยของข้อมูลสำหรับพนักงาน ปัจจุบันแผนกรักษาความปลอดภัยข้อมูลในองค์กรโดยทั่วไปมีขนาดไม่ใหญ่มากนัก มักประกอบด้วย 1-2 คน ดังนั้น การมอบหมายบุคคลที่รับผิดชอบในการรับเหตุการณ์จึงไม่ใช่เรื่องยาก คุณไม่จำเป็นต้องกังวลเรื่องการจัดสรรที่อยู่อีเมลสำหรับความต้องการของ IS Helpdesk

3. เหตุการณ์ที่เจ้าหน้าที่รักษาความปลอดภัยสารสนเทศตรวจพบ
ที่นี่ทุกอย่างเรียบง่ายและไม่จำเป็นต้องเคลื่อนไหวร่างกายเพื่อจัดระเบียบช่องรับสัญญาณดังกล่าว

4. บันทึกระบบและการแจ้งเตือน
กำหนดค่าการแจ้งเตือนในคอนโซลของโปรแกรมป้องกันไวรัส, IDS, DLP และระบบรักษาความปลอดภัยอื่นๆ จะสะดวกกว่าในการใช้ตัวรวบรวมข้อมูลที่รวบรวมข้อมูลจากบันทึกของโปรแกรมและระบบที่ติดตั้งในองค์กรของคุณด้วย ความสนใจเป็นพิเศษจำเป็นต้องให้ความสนใจกับจุดติดต่อกับเครือข่ายภายนอกและสถานที่ที่จัดเก็บข้อมูลที่ละเอียดอ่อน

แม้ว่าเหตุการณ์ด้านความปลอดภัยจะมีความหลากหลายและหลากหลาย แต่ก็ค่อนข้างง่ายที่จะแบ่งออกเป็นหลายประเภท ซึ่งง่ายต่อการเก็บสถิติ

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

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

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

4. การโจมตีของไวรัส
ในกรณีนี้ คุณต้องเข้าใจสิ่งต่อไปนี้: การติดไวรัสคอมพิวเตอร์ของพนักงานเพียงครั้งเดียวไม่ควรนำไปสู่การดำเนินคดี เนื่องจากอาจเกิดจากข้อผิดพลาดหรือปัจจัยมนุษย์ที่ฉาวโฉ่ หากคอมพิวเตอร์ขององค์กรติดไวรัสในเปอร์เซ็นต์ที่มีนัยสำคัญ (ที่นี่เราดำเนินการจากจำนวนเครื่องทั้งหมด การแจกจ่าย การแบ่งส่วน ฯลฯ) จำเป็นต้องเริ่มการสอบสวนเหตุการณ์ด้านความปลอดภัยอย่างเต็มรูปแบบพร้อมการค้นหาที่จำเป็น แหล่งที่มาของการติดเชื้อ สาเหตุ ฯลฯ

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

การจำแนกเหตุการณ์

ประเด็นนี้ในการทำงานกับเหตุการณ์นี้สามารถจัดการได้ 2 วิธี: ง่ายและซับซ้อน
วิธีง่ายๆ คือการจัดทำข้อตกลงระดับการให้บริการด้านไอทีและปรับแต่งให้ตรงกับความต้องการของคุณ
วิธีที่ยาก: ขึ้นอยู่กับการวิเคราะห์ความเสี่ยง ระบุกลุ่มของเหตุการณ์และ/หรือทรัพย์สินที่ต้องแก้ไขหรือกำจัดสาเหตุของเหตุการณ์โดยทันที
วิธีง่ายๆ ทำงานได้ดีในองค์กรขนาดเล็กที่ไม่มีข้อมูลที่เป็นกรรมสิทธิ์มากนักและไม่มีเลย จำนวนมากพนักงาน. แต่ก็คุ้มค่าที่จะเข้าใจว่าบริการด้านไอทียึด SLA ตามความเสี่ยงและสถิติเหตุการณ์ของตนเอง ค่อนข้างเป็นไปได้ที่เครื่องพิมพ์ที่ติดกระดาษอยู่บนโต๊ะ ผู้อำนวยการทั่วไปจะมีลำดับความสำคัญสูงมากหากการประนีประนอมของรหัสผ่านผู้ดูแลระบบฐานข้อมูลองค์กรมีความสำคัญต่อคุณมากกว่า

รวบรวมหลักฐานเหตุการณ์ที่เกิดขึ้น

มีวิทยาศาสตร์ประยุกต์พิเศษ - นิติเวชซึ่งเกี่ยวข้องกับประเด็นทางนิติเวชในสาขาอาชญากรรมคอมพิวเตอร์ และมีหนังสือที่ยอดเยี่ยมของ N.N. Fedotov "นิติเวช - นิติคอมพิวเตอร์" ฉันจะไม่อธิบายรายละเอียดเกี่ยวกับแง่มุมต่างๆ ของนิติเวชในตอนนี้ ฉันจะเน้นเพียง 2 ประเด็นหลักในการเก็บรักษาและให้หลักฐานที่ต้องปฏิบัติตาม

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

หลังจากเหตุการณ์คลี่คลายแล้ว

ดังนั้นเหตุการณ์นี้จึงจบลง ผลที่ตามมาก็หมดสิ้น และมีการสอบสวนอย่างเป็นทางการ
แต่งานไม่ควรจบเพียงแค่นั้น
การดำเนินการเพิ่มเติมหลังเกิดเหตุ:

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

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

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

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

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

จดหมายถึง:% [ป้องกันอีเมล]

[ป้องกันอีเมล]

นอกจากนี้ เมื่อวันที่ 26 พฤศจิกายน พ.ศ. 2547 ผู้ต้องสงสัยที่เหลืออีก 6 คนถูกควบคุมตัว รวมถึงพนักงาน 3 คนในแผนกบริการสมาชิกของบริษัท VimpelCom ด้วย ในระหว่างการสอบสวน ปรากฎว่าสถานที่ดังกล่าวสร้างขึ้นโดยอดีตนักศึกษามอสโก มหาวิทยาลัยของรัฐที่ไม่ได้ทำงานให้กับบริษัทนี้

เอกสารเกี่ยวกับเหตุการณ์นี้เกิดขึ้นได้เพราะคำตัดสินของศาลรัฐธรรมนูญเมื่อปี 2546 ซึ่งยอมรับว่ารายละเอียดการโทรเป็นความลับ การสนทนาทางโทรศัพท์ได้รับการคุ้มครองตามกฎหมาย

โอกาสภายใน

พนักงานของ VimpelCom สองคนที่ระบุว่าเป็นผู้เข้าร่วมในเหตุการณ์นั้นทำงานเป็นพนักงานในบริษัท และคนที่สามเป็นอดีตพนักงานและทำงานที่ตลาด Mitinsky ในขณะที่เกิดอาชญากรรม

การทำงานเป็นพนักงานบอกรับเงินในบริษัทบ่งชี้ว่าพนักงานเหล่านี้สามารถเข้าถึงข้อมูลที่เสนอขายบนเว็บไซต์ www.sherlok.ru ได้โดยตรง นอกจากนี้ตั้งแต่นั้นเป็นต้นมา อดีตพนักงานบริษัท กำลังทำงานในตลาด Mitinsky อยู่แล้ว สันนิษฐานได้ว่าเมื่อเวลาผ่านไปตลาดนี้อาจกลายเป็นหนึ่งในช่องทางการจัดจำหน่ายสำหรับข้อมูลนี้หรือข้อมูลอื่น ๆ จากฐานข้อมูล บริษัท VimpelCom

ผลที่ตามมา

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

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

ในเดือนมีนาคม พ.ศ. 2548 ศาลแขวง Ostankino แห่งกรุงมอสโกได้ตัดสินให้ผู้ต้องสงสัย รวมทั้งพนักงานสามคนของบริษัท VimpelCom ถูกปรับหลายค่า ดังนั้นผู้จัดกลุ่มจึงถูกปรับ 93,000 รูเบิล อย่างไรก็ตาม การดำเนินการของเว็บไซต์ www.sherlok.ru ถูกหยุดอย่างไม่มีกำหนดตั้งแต่วันที่ 1 มกราคม 2551 เท่านั้น

ข้อมูลส่วนบุคคลรั่วไหลครั้งใหญ่ที่สุดในประวัติศาสตร์ญี่ปุ่น

คำอธิบายประกอบ

ในฤดูร้อนปี 2549 ข้อมูลส่วนบุคคลรั่วไหลครั้งใหญ่ที่สุดในประวัติศาสตร์ของญี่ปุ่นเกิดขึ้น: พนักงานของ Dai Nippon Printing ยักษ์ใหญ่ด้านการพิมพ์และอิเล็กทรอนิกส์ขโมยดิสก์ที่มีข้อมูลส่วนตัวของพลเมืองเกือบเก้าล้านคน

คำอธิบายของเหตุการณ์

บริษัทญี่ปุ่น Dai Nippon Printing เชี่ยวชาญด้านการผลิต การพิมพ์ผลิตภัณฑ์ทำให้เกิดการรั่วไหลครั้งใหญ่ที่สุดในประวัติศาสตร์ของประเทศของตน ฮิโรฟูมิ โยโกยามะ อดีตพนักงานของบริษัทผู้รับเหมารายหนึ่งของบริษัท ได้คัดลอกข้อมูลส่วนบุคคลของลูกค้าของบริษัทลงในฮาร์ดไดรฟ์มือถือแล้วขโมยไป ผู้คนจำนวน 8.64 ล้านคนตกอยู่ในความเสี่ยงเนื่องจากข้อมูลที่ถูกขโมยมีทั้งชื่อ ที่อยู่ หมายเลขโทรศัพท์ และหมายเลขบัตรเครดิต ข้อมูลที่ถูกขโมยประกอบด้วยข้อมูลลูกค้าจากบริษัทต่างๆ 43 แห่ง เช่น ลูกค้า American Home Assurance 1,504,857 ราย ลูกค้า Aeon Co 581,293 ราย และลูกค้า NTT Finance 439,222 ราย

หลังจากการขโมยข้อมูลนี้ ฮิโรฟูมิได้เปิดการซื้อขายข้อมูลส่วนตัวในส่วนหนึ่งของบันทึก 100,000 รายการ ต้องขอบคุณรายได้ที่มั่นคง คนวงในถึงกับลาออกจากงานถาวรด้วยซ้ำ เมื่อถึงเวลาที่เขาถูกจับกุม ฮิโรฟูมิสามารถขายข้อมูลของลูกค้า 150,000 รายของบริษัทสินเชื่อที่ใหญ่ที่สุดให้กับกลุ่มผู้ฉ้อโกงที่เชี่ยวชาญด้านการซื้อออนไลน์ นอกจากนี้ข้อมูลบางส่วนยังถูกใช้เพื่อการฉ้อโกงบัตรเครดิตอีกด้วย

มากกว่าครึ่งหนึ่งขององค์กรที่ข้อมูลลูกค้าถูกขโมยไม่ได้รับคำเตือนเกี่ยวกับการรั่วไหลของข้อมูลด้วยซ้ำ

ผลที่ตามมา

จากเหตุการณ์นี้ ความสูญเสียของประชาชนที่ได้รับความเดือดร้อนเนื่องจากการฉ้อโกงบัตรเครดิต ซึ่งเกิดขึ้นได้เพียงผลจากการรั่วไหลครั้งนี้ มีมูลค่าหลายล้านดอลลาร์ โดยรวมแล้ว ลูกค้าของบริษัทต่างๆ 43 แห่งได้รับผลกระทบ รวมถึง Toyota Motor Corp., American Home Assurance, Aeon Co และ NTT Finance อย่างไรก็ตาม มากกว่าครึ่งหนึ่งขององค์กรไม่ได้รับคำเตือนเกี่ยวกับการรั่วไหลนี้ด้วยซ้ำ

ในปี 2003 ญี่ปุ่นได้ผ่านกฎหมายคุ้มครองข้อมูลส่วนบุคคลปี 2003 (PIPA) แต่อัยการไม่สามารถใช้กฎหมายดังกล่าวในการดำเนินคดีอาญาได้ กรณีนี้ในต้นปี 2550 การฟ้องร้องล้มเหลวในการตั้งข้อหาคนวงในว่าละเมิด PIPA เขาถูกกล่าวหาว่าขโมยฮาร์ดไดรฟ์มูลค่า 200 ดอลลาร์เท่านั้น

ไม่ได้รับการชื่นชม แฮกเกอร์ Zaporozhye กับธนาคารยูเครน

คำอธิบายประกอบ

อดีตผู้ดูแลระบบของธนาคารขนาดใหญ่แห่งหนึ่งในยูเครนโอนเงินประมาณ 5 ล้าน Hryvnia ผ่านธนาคารที่เขาเคยทำงานจากบัญชีของศุลกากรภูมิภาคไปยังบัญชีของบริษัท Dnepropetrovsk ที่ล้มละลายซึ่งไม่มีอยู่จริง

คำอธิบายของเหตุการณ์

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

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

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

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

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

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

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

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

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

ผลที่ตามมา

ธนาคารไม่ได้รับความสูญเสียใด ๆ เนื่องจากเงินถูกส่งคืนให้กับเจ้าของแล้ว และระบบคอมพิวเตอร์ได้รับความเสียหายเพียงเล็กน้อย ส่งผลให้ฝ่ายบริหารธนาคารปฏิเสธการเรียกร้องใด ๆ ต่อผู้ดูแลระบบคนเดิม

ในปี 2547 ตามคำสั่งของประธานาธิบดีแห่งยูเครน ความรับผิดทางอาญาสำหรับอาชญากรรมคอมพิวเตอร์มีความเข้มแข็งมากขึ้น: ค่าปรับขั้นต่ำปลอดภาษี 600 ถึง 1,000 ค่าปรับจำคุกตั้งแต่ 3 ถึง 6 ปี อย่างไรก็ตาม อดีตผู้ดูแลระบบได้ก่ออาชญากรรมก่อนที่คำสั่งประธานาธิบดีจะมีผลใช้บังคับ

เมื่อต้นปี พ.ศ. 2548 ผู้ดูแลระบบได้ทดลองใช้งานระบบ เขาถูกกล่าวหาว่าก่ออาชญากรรมภายใต้ส่วนที่ 2 ของมาตรา 361 แห่งประมวลกฎหมายอาญาของประเทศยูเครน - การแทรกแซงอย่างผิดกฎหมายต่อการทำงานของระบบคอมพิวเตอร์ที่ก่อให้เกิดอันตราย และภายใต้ส่วนที่ 5 ของมาตรา 185 - การโจรกรรมที่กระทำในวงกว้างโดยเฉพาะ แต่เนื่องจากฝ่ายบริหารของธนาคารปฏิเสธที่จะเรียกร้องใด ๆ กับเขา ข้อหาขโมยจึงถูกลบออกจากเขา และส่วนที่ 2 ของบทความ 361 ก็เปลี่ยนเป็นส่วนที่ 1 - การแทรกแซงที่ผิดกฎหมายในการทำงานของระบบคอมพิวเตอร์

การซื้อขายที่ไม่มีการควบคุมที่ธนาคาร Societe Generale

คำอธิบายประกอบ

เมื่อวันที่ 24 มกราคม พ.ศ. 2551 Societe Generale ได้ประกาศขาดทุนจำนวน 4.9 พันล้านยูโร เนื่องจากการดำเนินการของเทรดเดอร์ Jerome Kerviel จากการตรวจสอบภายในพบว่า เป็นเวลาหลายปีที่เทรดเดอร์เปิดตำแหน่งที่สูงกว่าขีดจำกัดในฟิวเจอร์สสำหรับดัชนีหุ้นยุโรป จำนวนตำแหน่งที่เปิดอยู่ทั้งหมดมีมูลค่า 50 พันล้านยูโร

คำอธิบายของเหตุการณ์

ตั้งแต่เดือนกรกฎาคม 2549 ถึงกันยายน 2550 ระบบควบคุมภายในของคอมพิวเตอร์ได้ออกคำเตือนเกี่ยวกับการละเมิดที่อาจเกิดขึ้น 75 ครั้ง (นั่นคือจำนวนครั้งที่ Jerome Kerviel ทำธุรกรรมโดยไม่ได้รับอนุญาตหรือตำแหน่งของเขาเกินขีดจำกัดที่อนุญาต) พนักงานแผนกติดตามความเสี่ยงของธนาคารไม่ได้ดำเนินการตรวจสอบคำเตือนเหล่านี้อย่างละเอียด

Kerviel เริ่มทดลองซื้อขายโดยไม่ได้รับอนุญาตครั้งแรกในปี 2548 จากนั้นเขาก็เข้าซื้อหุ้น Allianz โดยคาดว่าตลาดจะร่วงลง ในไม่ช้าตลาดก็ตกต่ำลงจริงๆ (หลังจากการโจมตีของผู้ก่อการร้ายในลอนดอน) ดังนั้นจึงได้รับเงิน 500,000 ยูโรแรก Kerviel เล่าให้ผู้ตรวจสอบทราบในเวลาต่อมาเกี่ยวกับความรู้สึกของเขาที่เขาได้รับจากความสำเร็จครั้งแรก: “ฉันรู้แล้วว่าจะปิดสถานะของตัวเองได้อย่างไร และฉันก็ภูมิใจกับผลลัพธ์ แต่ในขณะเดียวกันฉันก็ประหลาดใจ ความสำเร็จทำให้ฉันดำเนินต่อไป มันเหมือนกับก้อนหิมะ... ในเดือนกรกฎาคม พ.ศ. 2550 ฉันเสนอให้เข้าซื้อตำแหน่งสั้น ๆ โดยคาดหวังว่าตลาดจะตกต่ำ แต่ไม่ได้รับการสนับสนุนจากผู้จัดการของฉัน การคาดการณ์ของฉันเป็นจริง และเราทำกำไรได้ คราวนี้มันถูกกฎหมายโดยสิ้นเชิง ต่อจากนั้น ฉันยังคงดำเนินการดังกล่าวในตลาดต่อไป ไม่ว่าจะได้รับความยินยอมจากผู้บังคับบัญชาของฉันหรือในกรณีที่ไม่มีการคัดค้านอย่างชัดเจน... ภายในวันที่ 31 ธันวาคม 2550 กำไรของฉันสูงถึง 1.4 พันล้านยูโร ในขณะนั้น ฉันไม่รู้ว่าจะต้องแจ้งเรื่องนี้กับธนาคารของฉันอย่างไร เนื่องจากเป็นจำนวนเงินที่เยอะมากและไม่ได้แจ้งไว้ที่ใดเลย ฉันมีความสุขและภูมิใจ แต่ฉันไม่รู้ว่าจะอธิบายให้ฝ่ายบริหารของฉันทราบได้อย่างไรถึงการรับเงินจำนวนนี้ และไม่ต้องสงสัยว่าจะทำธุรกรรมที่ไม่ได้รับอนุญาต ดังนั้นฉันจึงตัดสินใจซ่อนผลกำไรของฉันและดำเนินการตรงกันข้ามกับการดำเนินการที่สมมติขึ้น…”

ในความเป็นจริง ในช่วงต้นเดือนมกราคมของปีนั้น Jerome Kerviel กลับเข้าสู่เกมอีกครั้งด้วยสัญญาซื้อขายล่วงหน้าสำหรับดัชนี Euro Stoxx 50 สามดัชนี DAX และ FTSE ซึ่งช่วยให้เขาเอาชนะตลาดได้ในช่วงปลายปี 2550 (แม้ว่าเขาจะชอบที่จะปิดการขายที่ เวลา). ตามการคำนวณ ในวันที่ 11 มกราคม พอร์ตโฟลิโอของเขามีฟิวเจอร์ส 707.9 พันฟิวเจอร์ส (แต่ละตัวมีมูลค่า 42.4 พันยูโร) บน Euro Stoxx 50, 93.3 พันฟิวเจอร์ส (192.8 พันยูโรต่อ 1 ชิ้น) บน DAX และ 24.2 พันฟิวเจอร์ส (82.7 พันยูโร) ต่อ 1 สัญญา) สำหรับดัชนี FTSE โดยรวมแล้วตำแหน่งเก็งกำไรของ Kerviel เท่ากับ 50 พันล้านยูโรนั่นคือมากกว่ามูลค่าของธนาคารที่เขาทำงานอยู่

เมื่อทราบจังหวะเวลาของเช็ค เขาจึงเปิดตำแหน่งป้องกันความเสี่ยงสมมติในเวลาที่เหมาะสม ซึ่งต่อมาเขาก็ปิด เป็นผลให้ผู้ตรวจสอบไม่เคยเห็นตำแหน่งเดียวที่อาจถือว่ามีความเสี่ยง พวกเขาไม่สามารถตื่นตระหนกกับธุรกรรมจำนวนมาก ซึ่งเป็นเรื่องปกติในตลาด สัญญาซื้อขายล่วงหน้าโดยดัชนี เขาผิดหวังกับธุรกรรมสมมติที่ดำเนินการจากบัญชีของลูกค้าธนาคาร การใช้บัญชีของลูกค้าธนาคารต่างๆ ไม่ได้นำไปสู่ปัญหาที่ผู้ควบคุมมองเห็นได้ อย่างไรก็ตาม เมื่อเวลาผ่านไป Kerviel เริ่มใช้บัญชีของลูกค้ารายเดิม ซึ่งนำไปสู่กิจกรรม "ผิดปกติ" ที่พบในบัญชีเหล่านี้ และดึงดูดความสนใจของผู้ควบคุมในทางกลับกัน นี่คือจุดสิ้นสุดของการหลอกลวง ปรากฎว่าหุ้นส่วนของ Kerviel ในข้อตกลงมูลค่าหลายพันล้านดอลลาร์นั้นเป็นธนาคารเยอรมันขนาดใหญ่ซึ่งถูกกล่าวหาว่ายืนยันธุรกรรมทางดาราศาสตร์ใน อีเมล- อย่างไรก็ตาม การยืนยันทางอิเล็กทรอนิกส์ทำให้เกิดความสงสัยในหมู่ผู้ตรวจสอบ และมีการจัดตั้งคณะกรรมการขึ้นที่ Societe Generale เพื่อตรวจสอบพวกเขา เมื่อวันที่ 19 มกราคม เพื่อตอบสนองต่อการร้องขอ ธนาคารเยอรมันไม่ยอมรับธุรกรรมนี้ หลังจากนั้นเทรดเดอร์ก็ตกลงที่จะรับสารภาพ

เมื่อเป็นไปได้ที่จะทราบขนาดทางดาราศาสตร์ของตำแหน่งเก็งกำไร Daniel Bouton ซีอีโอและประธานคณะกรรมการบริหารของ Societe Generale ได้ประกาศความตั้งใจที่จะปิดตำแหน่งที่มีความเสี่ยงที่เปิดโดย Kerviel การดำเนินการนี้ใช้เวลาสองวันและส่งผลให้ขาดทุน 4.9 พันล้านยูโร

โอกาสภายใน

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

ในปี 2548 Kerviel ได้รับการเลื่อนตำแหน่ง เขากลายเป็นเทรดเดอร์ตัวจริง ในความรับผิดชอบทันที ชายหนุ่มรวมถึงการดำเนินงานขั้นพื้นฐานเพื่อลดความเสี่ยง Jerome Kerviel ทำงานในตลาดฟิวเจอร์สสำหรับดัชนีหุ้นยุโรป โดยต้องติดตามดูการเปลี่ยนแปลงพอร์ตการลงทุนของธนาคาร และงานหลักของเขาดังที่ตัวแทนของ Societe Generale คนหนึ่งอธิบาย คือการลดความเสี่ยงโดยการเล่นในทิศทางตรงกันข้าม: “พูดโดยคร่าวๆ เมื่อเห็นว่าธนาคารเดิมพันสีแดง เขาจึงต้องเดิมพันสีดำ” เช่นเดียวกับเทรดเดอร์รุ่นเยาว์ทุกคน Kerviel มีขีดจำกัดที่เขาไม่สามารถเกินได้ ซึ่งสิ่งนี้ได้รับการตรวจสอบโดยเขา อดีตเพื่อนร่วมงานในสำนักงานด้านหลัง Societe Generale มีการป้องกันหลายชั้น เช่น เทรดเดอร์สามารถเปิดสถานะได้จากคอมพิวเตอร์ที่ทำงานเท่านั้น ข้อมูลทั้งหมดเกี่ยวกับตำแหน่งที่เปิดจะถูกส่งแบบเรียลไทม์ไปยังแบ็คออฟฟิศโดยอัตโนมัติ แต่อย่างที่พวกเขาพูดกันว่าผู้ลักลอบล่าสัตว์ที่ดีที่สุดคืออดีตป่าไม้ และธนาคารก็ทำผิดพลาดอย่างไม่อาจให้อภัยโดยให้อดีตคนป่าไม้อยู่ในตำแหน่งนักล่า Jérôme Kerviel ซึ่งมีประสบการณ์เกือบห้าปีในการติดตามเทรดเดอร์ พบว่าไม่ยากเลยที่จะข้ามระบบนี้ เขารู้รหัสผ่านของคนอื่น รู้เมื่อเช็คที่ธนาคารดำเนินการ และรอบรู้เป็นอย่างดี เทคโนโลยีสารสนเทศ.

เหตุผล

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

ผลที่ตามมา

ในตอนท้ายของปี 2550 กิจกรรมของธนาคารทำให้ธนาคารมีกำไรประมาณ 2 พันล้านยูโร ไม่ว่าในกรณีใด นี่คือสิ่งที่ Kerviel พูดเอง โดยอ้างว่าฝ่ายบริหารของธนาคารอาจรู้ว่าเขากำลังทำอะไรอยู่ แต่เลือกที่จะเมินเฉยตราบเท่าที่เขาทำกำไรได้

การปิดสถานะความเสี่ยงที่เปิดโดย Kerviel ส่งผลให้ขาดทุน 4.9 พันล้านยูโร

ในเดือนพฤษภาคม พ.ศ. 2551 Daniel Bouton ออกจากตำแหน่ง CEO ของ Societe Generale และ Frederic Oudea เข้ามารับตำแหน่งนี้แทน หนึ่งปีต่อมาเขาถูกบังคับให้ลาออกจากตำแหน่งประธานกรรมการธนาคาร เหตุผลในการจากไปของเขาคือการวิพากษ์วิจารณ์อย่างรุนแรงจากสื่อมวลชน: Bouton ถูกกล่าวหาว่าผู้จัดการระดับสูงของธนาคารภายใต้การควบคุมของเขาสนับสนุนการทำธุรกรรมทางการเงินที่มีความเสี่ยงที่ดำเนินการโดยพนักงานธนาคาร

แม้ว่าจะได้รับการสนับสนุนจากคณะกรรมการ แต่แรงกดดันต่อนายบูตันก็เพิ่มขึ้น ผู้ถือหุ้นของธนาคารและนักการเมืองชาวฝรั่งเศสจำนวนมากเรียกร้องให้เขาลาออก ประธานาธิบดี Nicolas Sarkozy แห่งฝรั่งเศสยังเรียกร้องให้ Daniel Bouton ลาออกหลังจากทราบว่าในช่วงหนึ่งปีครึ่งก่อนเกิดเรื่องอื้อฉาว ระบบคอมพิวเตอร์ควบคุมภายในของ Societe Generale ได้ออกคำเตือน 75 ครั้ง กล่าวคือ ทุกครั้งที่ Jerome Kerviel ทำธุรกรรมที่ไม่ได้รับอนุญาต .

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

รายงานผลการตรวจสอบของเทรดเดอร์ระบุว่าหลังจากผลการสอบสวน ได้มีการตัดสินใจที่จะ "เสริมสร้างกระบวนการกำกับดูแลภายในกิจกรรมของพนักงาน Societe Generale อย่างมีนัยสำคัญ" ซึ่งจะดำเนินการผ่านการจัดองค์กรที่เข้มงวดมากขึ้นในการทำงานของแผนกต่างๆ ของธนาคาร และการประสานงานปฏิสัมพันธ์ของพวกเขา มาตรการต่างๆ จะถูกนำไปใช้เพื่อติดตามและปรับแต่งการดำเนินการซื้อขายของพนักงานธนาคารโดย “เสริมสร้างระบบความปลอดภัยด้านไอทีและพัฒนาโซลูชั่นเทคโนโลยีขั้นสูงสำหรับการระบุตัวตนส่วนบุคคล (ไบโอเมตริกซ์)”