ในช่วงชั่วโมงแรกของเหตุการณ์ด้านความปลอดภัย คุณยังไม่สามารถเข้าใจภาพรวมทางเทคนิคของสิ่งที่เกิดขึ้นได้ทั้งหมด ทีมของคุณอาจยังพยายามหาว่าบัญชีใดถูกโจมตี ข้อมูลใดถูกเข้าถึง ผู้โจมตีเข้าไปได้ไกลแค่ไหน หรือเหตุการณ์ยังดำเนินอยู่หรือไม่
ควบคู่ไปกับการสืบสวน ความกดดันที่ต้องลงมือทำก็เริ่มขึ้นทันที พนักงานได้ยินข้อมูลเป็นบางส่วนและจำเป็นต้องรู้ว่าควรทำอะไร ขณะเดียวกันลูกค้าอาจสังเกตเห็นบริการขัดข้อง มีกิจกรรมที่น่าสงสัย หรือมีคำขอรีเซ็ตรหัสผ่านที่ผิดปกติ คู่ค้าทางธุรกิจอาจถามว่าระบบหรือข้อมูลของตนเกี่ยวข้องด้วยหรือไม่ และผู้บริหารต้องตัดสินใจว่าใครเป็นผู้พูด อะไรที่ยืนยันได้ และเมื่อใดที่ความเงียบกลายเป็นความเสี่ยงในตัวเอง
การสื่อสารในเหตุการณ์ด้านความปลอดภัยเป็นเรื่องยาก เพราะธุรกิจต้องโปร่งใสก่อนที่จะมีคำตอบครบทุกข้อ แต่ต้องมีข้อมูลเพียงพอที่จะไม่ต้องเดา การสื่อสารที่ส่งเร็วเกินไปอาจสร้างความสับสน แต่ถ้าส่งช้าเกินไปอาจทำลายความไว้วางใจ ทำให้การดำเนินการป้องกันล่าช้า และก่อให้เกิดคำถามจากหน่วยงานกำกับดูแล
เป็นไปได้น้อยที่ธุรกิจขนาดเล็กและขนาดกลางจะได้จัดทำหรือซ้อมแผนรับมือเหตุการณ์ไว้ และสิ่งนี้อาจก่อให้เกิดความวุ่นวายเพิ่มเติม แม้แต่ธุรกิจขนาดใหญ่ที่มีแผนอยู่แล้ว ขั้นตอนทางเทคนิคอาจถูกบันทึกไว้ เช่น ควบคุมเหตุการณ์ รีเซ็ตการเข้าถึง เก็บรักษาหลักฐาน กู้คืนระบบ ส่วนการสื่อสารอาจถูกเลื่อนออกไป จนกระทั่งเหตุการณ์ทวีความรุนแรงหรือเปลี่ยนแปลงกะทันหัน
ส่วนหนึ่งของการเตรียมพร้อมรับมือเหตุการณ์คือการรู้ว่าใครต้องการรับฟังจากคุณ ใครต้องการรู้อะไร ใครอนุมัติข้อความ และจะสื่อสารข้อเท็จจริงอย่างชัดเจนได้อย่างไรในขณะที่การสืบสวนยังดำเนินอยู่
การวางแผนการสื่อสารเป็นส่วนหนึ่งของการรับมือเหตุการณ์
โครงสร้างสองแนวทางสำหรับการรับมือของคุณ
เริ่มจากกลุ่มเป้าหมาย ไม่ใช่จากประกาศ
วิธีแจ้งลูกค้าเกี่ยวกับการละเมิดข้อมูล
เมื่อใดควรแจ้งหน่วยงานกำกับดูแล
เตรียมข้อความไว้ล่วงหน้าก่อนที่จำเป็นต้องใช้
Proton Pass for Business ช่วยได้อย่างไร
การวางแผนการสื่อสารเป็นส่วนหนึ่งของการรับมือเหตุการณ์
การรับมือเหตุการณ์มักถูกอธิบายว่าเป็นกระบวนการทางเทคนิค แต่เหตุการณ์จริงกลายเป็นงานข้ามฝ่ายอย่างรวดเร็ว ทีมไอทีอาจควบคุมภัยคุกคามได้ แต่ผู้บริหาร ฝ่ายกฎหมาย ฝ่ายสนับสนุนลูกค้า ฝ่ายทรัพยากรบุคคล ฝ่ายสื่อสาร และฝ่ายปฏิบัติการ ต่างต้องรู้ว่าเกิดอะไรขึ้นและตนได้รับอนุญาตให้พูดอะไรได้บ้าง
คำแนะนำของ NCSC เกี่ยวกับการสื่อสารที่มีประสิทธิผลในเหตุการณ์ไซเบอร์(หน้าต่างใหม่) ซึ่งเป็นแนวปฏิบัติที่ดีทั่วไปที่นำไปใช้ได้ไกลเกินสหราชอาณาจักร ชี้ประเด็นนี้อย่างชัดเจนว่า องค์กรมักให้ความสำคัญกับการรับมือทางเทคนิคและผลักการสื่อสารไปอยู่เบื้องหลัง แม้ว่าการสื่อสารจะเป็นตัวกำหนดว่าพนักงาน ลูกค้า ผู้มีส่วนได้ส่วนเสีย และสื่อมององค์กรอย่างไรในช่วงวิกฤต
ไม่ใช่ทุกเหตุการณ์ที่ต้องมีแถลงการณ์ต่อสาธารณะ แต่ธุรกิจควรรู้ล่วงหน้าว่าใครเป็นผู้ตัดสินใจว่าจะสื่อสารอะไร ใครอนุมัติข้อความภายนอก ใครพูดกับลูกค้า และใครรับผิดชอบการรายงานต่อหน่วยงานกำกับดูแล
แผนรับมือการละเมิดข้อมูลที่แข็งแกร่งจำเป็นต้องมีชั้นของการสื่อสาร ซึ่งควรรวมรายละเอียดในทางปฏิบัติไว้ด้วย
- รายชื่อผู้ติดต่อ
- เทมเพลตฉบับร่าง
- เส้นทางการอนุมัติ
- การทบทวนทางกฎหมาย
- ประเด็นพูดคุยสำหรับฝ่ายสนับสนุนลูกค้า
- ความรับผิดชอบในการแจ้งหน่วยงานกำกับดูแล
- บันทึกว่าส่งอะไร เมื่อใด และถึงใคร
โครงสร้างสองแนวทางสำหรับการรับมือของคุณ
การรับมือเหตุการณ์ต้องมีสองแนวทาง คือการรับมือทางเทคนิคและการรับมือด้านการสื่อสาร ทั้งสองดำเนินไปคู่ขนานกัน และหัวหน้าทีมรับมือเหตุการณ์หรือเจ้าของงานรับมือจะเป็นผู้เชื่อมโยงทั้งสองเข้าด้วยกัน
| แนวทางซ้าย: การรับมือทางเทคนิค | แนวทางขวา: การรับมือด้านการสื่อสาร |
| ควบคุมเหตุการณ์ | อัปเดตทีมภายใน |
| ปกป้องบัญชีที่ได้รับผลกระทบ | แจ้งลูกค้าหรือคู่ค้าที่ได้รับผลกระทบ |
| เก็บรักษาหลักฐาน | ประเมินการแจ้งหน่วยงานกำกับดูแล |
| กู้คืนระบบ | รักษาความสอดคล้องของข้อความเมื่อข้อเท็จจริงเปลี่ยนไป |
สิ่งนี้ช่วยให้คุณจัดโครงสร้างการรับมือและมั่นใจว่าการทำงานร่วมกันยังดำเนินต่อไปเมื่อสมาชิกในทีมรับงานที่แตกต่างกัน
เริ่มจากกลุ่มเป้าหมาย ไม่ใช่จากประกาศ
การสื่อสารในเหตุการณ์ด้านความปลอดภัยล้มเหลวเมื่อข้อความเดียวพยายามตอบโจทย์ทุกคน พนักงาน ลูกค้า คู่ค้า และหน่วยงานกำกับดูแลต้องการรายละเอียดในระดับที่ต่างกัน เพราะพวกเขามีการตัดสินใจที่ต่างกัน
ทีมภายในของคุณต้องการความชัดเจนก่อนเป็นอันดับแรก
พวกเขาไม่จำเป็นต้องรู้ทุกอย่าง โดยเฉพาะในขณะที่การสืบสวนยังดำเนินอยู่ แต่พวกเขาต้องการความชัดเจนว่าอะไรที่ยืนยันได้แล้ว ควรทำอะไรในตอนนี้ และใครเป็นผู้นำการรับมือ ซึ่งหมายถึงการรู้ว่าระบบหรือบัญชีใดที่ควรหลีกเลี่ยง ต้องดำเนินการอะไรทันที และคำถามใดที่ยังไม่มีคำตอบ
พนักงานยังต้องรู้ด้วยว่าสิ่งใดไม่ควรทำ ตัวอย่างเช่น
- อย่าพูดคุยเรื่องเหตุการณ์ต่อสาธารณะ
- อย่ารีเซ็ตข้อมูลยืนยันตัวตนนอกกระบวนการที่ได้รับอนุมัติ
- อย่าติดต่อลูกค้าด้วยคำอธิบายที่คิดขึ้นเองเฉพาะหน้า
- อย่าส่งต่อข้อความที่น่าสงสัยโดยไม่มีคำแนะนำ
ลูกค้าและคู่ค้าต้องรู้ว่าตนได้รับผลกระทบอย่างไร
พวกเขาต้องการรู้ว่าข้อมูล การเข้าถึง การชำระเงิน บริการ หรือการดำเนินงานของตนได้รับผลกระทบหรือไม่ การแจ้งลูกค้าที่ดีควรอธิบายว่า
- สิ่งที่ทราบแล้ว
- ข้อมูลประเภทใดที่อาจเกี่ยวข้อง
- ธุรกิจกำลังดำเนินการอะไรอยู่
- ลูกค้าควรทำอะไรตอนนี้ หากมี
- พวกเขาสามารถรับอัปเดตได้ที่ไหน
โทนควรเรียบง่ายและตรงไปตรงมา ลูกค้าไม่จำเป็นต้องทราบรายละเอียดเชิงลึก พวกเขาต้องการเพียงข้อมูลที่พอจะปกป้องตัวเองได้
หน่วยงานกำกับดูแลต้องการบันทึกที่เป็นข้อเท็จจริง
การแจ้งเตือนการละเมิดข้อมูลตาม GDPR ต่อหน่วยงานกำกับดูแลที่เกี่ยวข้อง (ICO(หน้าต่างใหม่) ในสหราชอาณาจักร หน่วยงานคุ้มครองข้อมูลระดับชาติในแต่ละประเทศสมาชิกสหภาพยุโรป) ไม่ใช่ข้อความทางการตลาดหรือบันทึกสร้างความมั่นใจให้ลูกค้า แต่ต้องเป็นบันทึกข้อเท็จจริงถึงสิ่งที่เกิดขึ้น ใครได้รับผลกระทบ และสิ่งที่คุณกำลังดำเนินการ เราอธิบายรายละเอียดว่าต้องรวมอะไรบ้างในหัวข้อเกี่ยวกับการแจ้งเตือนหน่วยงานกำกับดูแลด้านล่างนี้
สิ่งที่ต้องสื่อสารภายในองค์กร
พนักงานของคุณเป็นส่วนหนึ่งของการรับมือ แม้จะไม่ได้อยู่ในทีมจัดการเหตุการณ์ ทีมที่สับสนอาจสร้างความวุ่นวายโดยไม่ตั้งใจ แชร์ข้อมูลที่ไม่ถูกต้อง หรือทำให้การควบคุมสถานการณ์ช้าลง ในทางกลับกัน ทีมที่ได้รับข้อมูลครบถ้วนสามารถช่วยปกป้องบัญชี แนะนำลูกค้าไปยังช่องทางที่ถูกต้อง และหลีกเลี่ยงการเกิดกระแสคาดเดา
ประกาศเหตุการณ์ความปลอดภัยภายในองค์กรควรครอบคลุม:
- สรุปสิ่งที่ยืนยันได้จนถึงตอนนี้อย่างชัดเจน ด้วยภาษาที่เข้าใจง่าย
- ระบบ บัญชี ทีม หรือข้อมูลใดที่อาจได้รับผลกระทบ
- ธุรกิจกำลังดำเนินการอะไรอยู่ในตอนนี้
- พนักงานควรทำอะไรทันที
- ใครได้รับอนุญาตให้สื่อสารภายนอก
- อัปเดตจะถูกโพสต์ที่ไหน
- วิธีรายงานกิจกรรมที่น่าสงสัยที่เกี่ยวข้อง
มีบางแง่มุมที่ไม่ควรเปิดเผย ทั้งช่องทางโจมตี การวิเคราะห์สาเหตุราก และช่องโหว่เฉพาะเจาะจง โดยทั่วไปจะไม่แชร์ภายในองค์กรขณะเหตุการณ์ยังดำเนินอยู่ และมักจะไม่แชร์ภายหลังด้วย เพราะรายละเอียดเหล่านั้นอาจช่วยผู้โจมตีรายอื่นได้ ก่อให้เกิดความเสี่ยงทางกฎหมาย หรือเปิดเผยช่องว่างที่ยังไม่ได้ปิด
ข้อความภายในฉบับแรกไม่จำเป็นต้องตอบทุกคำถาม แต่ต้องสร้างความเป็นระเบียบ ตัวอย่างเช่น พนักงานอาจต้องรีเซ็ตรหัสผ่านผ่านกระบวนการที่ได้รับอนุมัติเท่านั้น หลีกเลี่ยงการใช้ระบบเฉพาะ เก็บรักษาอีเมลที่น่าสงสัย หรือหยุดใช้ข้อมูลยืนยันตัวตนที่แชร์ไว้จนกว่าทีมรับมือจะตรวจสอบเสร็จ
การประเมินการควบคุมการเข้าถึงที่มีอยู่เทียบกับแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการรหัสผ่านก็เป็นสิ่งจำเป็นเช่นกัน ในระหว่างเกิดเหตุการณ์ การแชร์ข้อมูลยืนยันตัวตนที่ล้าสมัยหรือไม่เป็นทางการอาจทำให้เข้าใจได้ยากขึ้นว่าอะไรถูกเปิดเผย
คู่มือของ Proton เกี่ยวกับการป้องกันการละเมิดข้อมูล และการป้องกันการละเมิดข้อมูลสำหรับธุรกิจ อธิบายว่าการควบคุมแบบหลายชั้นช่วยลดความเสี่ยงก่อนเกิดการละเมิดได้อย่างไร การจัดการข้อมูลยืนยันตัวตนอย่างปลอดภัยเป็นหนึ่งในชั้นเหล่านั้น เพราะช่วยให้ธุรกิจรู้ว่ามีบัญชีใดบ้าง ใครเข้าถึงได้ และอะไรที่ต้องเปลี่ยนแปลงอย่างรวดเร็ว
วิธีแจ้งเตือนลูกค้าเกี่ยวกับการละเมิดข้อมูล
การแจ้งเตือนการละเมิดข้อมูลต่อลูกค้าเป็นเรื่องยากกว่า เพราะมีน้ำหนักด้านชื่อเสียงและกฎหมาย ผู้คนอาจกังวลเกี่ยวกับการโจรกรรมข้อมูลระบุตัวตน การยึดบัญชี การฉ้อโกงทางการเงิน หรือการเปิดเผยข้อมูลส่วนตัว พวกเขาอาจรู้สึกหงุดหงิดที่บริษัทไม่สามารถป้องกันเหตุการณ์ได้
ข้อความถึงลูกค้าที่ดีควรซื่อสัตย์โดยไม่ทำให้ตื่นตระหนก ควรหลีกเลี่ยงศัพท์เทคนิคแต่ชัดเจน ลูกค้าต้องเข้าใจว่าข้อมูลใดเกี่ยวข้อง ความเสี่ยงที่เกิดขึ้นคืออะไร และพวกเขาควรทำอะไรต่อไป
โครงสร้างที่มีประโยชน์คือ:
- เกิดอะไรขึ้น ในระดับรายละเอียดที่เหมาะสมกับลูกค้า
- ธุรกิจทราบเรื่องเมื่อใด
- ข้อมูลหรือบริการใดที่อาจได้รับผลกระทบ
- ธุรกิจได้ดำเนินการอะไรไปแล้วบ้าง
- ลูกค้าควรทำอะไรตอนนี้
- ธุรกิจจะให้อัปเดตอย่างไร
- ลูกค้าสามารถติดต่อใครได้หากมีคำถาม
หากการสอบสวนยังดำเนินอยู่ ควรเปิดเผยเรื่องนี้ ความถูกต้องและความโปร่งใสช่วยกู้คืนความไว้วางใจ การเปิดกว้างเกี่ยวกับผลกระทบไม่จำเป็นต้องเปิดเผยรายละเอียดทางเทคนิคที่จะช่วยให้ผู้อื่นโจมตีซ้ำได้
สำหรับเหตุการณ์ร้ายแรง ลูกค้าอาจต้องการคำแนะนำที่นำไปปฏิบัติได้จริง เช่น เปลี่ยนรหัสผ่าน เปิดใช้งาน MFA ระวังอีเมลฟิชชิ่ง ติดต่อธนาคาร และเพิกเฉยต่อข้อความที่อ้างว่ามาจากบริษัทเว้นแต่将通过ช่องทางที่เป็นทางการ การแจ้งเตือนควรทำให้ขั้นตอนเหล่านั้นเข้าใจได้ง่าย
เมื่อใดและอย่างไรจึงควรแจ้งหน่วยงานกำกับดูแล
ไม่ใช่ทุกเหตุการณ์ความปลอดภัยที่ต้องรายงานต่อหน่วยงานกำกับดูแล การละเมิดข้อมูลที่ต้องรายงานตาม GDPR ของสหราชอาณาจักรและสหภาพยุโรป ขึ้นอยู่กับว่าการละเมิดข้อมูลส่วนบุคคลมีแนวโน้มจะก่อให้เกิดความเสี่ยงต่อสิทธิและเสรีภาพของผู้คนหรือไม่
คำแนะนำเกี่ยวกับการละเมิดข้อมูลส่วนบุคคล(หน้าต่างใหม่)ของ ICO สะท้อนข้อกำหนดที่เหมือนกันทั้ง GDPR ของสหราชอาณาจักรและสหภาพยุโรป: องค์กรต้องรายงานการละเมิดที่ต้องแจ้งโดยไม่ชักช้าและไม่เกิน 72 ชั่วโมงหลังจากทราบเรื่อง การรายงานล่าช้าต้องมีเหตุผลประกอบ
กรอบเวลา 72 ชั่วโมงนั้นอาจสร้างความกดดัน โดยเฉพาะเมื่อการสอบสวนยังไม่เสร็จสมบูรณ์ GDPR ตระหนักว่าองค์กรอาจไม่มีรายละเอียดครบทุกอย่างภายใน 72 ชั่วโมงแรก จึงสามารถให้ข้อมูลเป็นระยะได้ ตราบใดที่มีการอัปเดตเพิ่มเติมโดยไม่ชักช้า
การแจ้งเตือนต่อหน่วยงานกำกับดูแลที่เกี่ยวข้อง (ICO ในสหราชอาณาจักร หรือหน่วยงานคุ้มครองข้อมูลระดับชาติในสหภาพยุโรป) โดยปกติควรรวมถึง:
- ลักษณะของการละเมิดข้อมูลส่วนบุคคล
- หมวดหมู่และจำนวนโดยประมาณของบุคคลที่ได้รับผลกระทบ
- หมวดหมู่และจำนวนโดยประมาณของบันทึกข้อมูลส่วนบุคคลที่ได้รับผลกระทบ
- ชื่อและรายละเอียดผู้ติดต่อของ DPO หรือจุดติดต่ออื่น
- ผลที่อาจเกิดขึ้นจากการละเมิด
- มาตรการที่ดำเนินการหรือเสนอเพื่อแก้ไข
ICO ยังมีหน้าศูนย์กลางสำหรับรายงานการละเมิด(หน้าต่างใหม่)และนำทางองค์กรไปสู่กระบวนการรายงานที่เหมาะสม
สำหรับบุคคลที่ได้รับผลกระทบ เกณฑ์จะแตกต่างออกไป หากการละเมิดข้อมูลส่วนบุคคลมีแนวโน้มจะก่อให้เกิดความเสี่ยงสูงต่อสิทธิและเสรีภาพของผู้คน พวกเขาต้องได้รับแจ้งโดยไม่ชักช้า นี่เป็นสถานการณ์ที่ทีมกฎหมาย ความเป็นส่วนตัว และผู้บริหารควรเข้ามาเกี่ยวข้องตั้งแต่เนิ่นๆ แม้ในธุรกิจขนาดเล็ก
เตรียมข้อความไว้ล่วงหน้าก่อนที่คุณจะต้องใช้
เวลาที่แย่ที่สุดในการออกแบบกระบวนการสื่อสารคือระหว่างเกิดเหตุการณ์ การออกแถลงการณ์หรือคำแนะนำที่ต้องอัปเดตและเปลี่ยนแปลงไม่เป็นประโยชน์
นั่นคือเหตุผลว่าทำไมการเตรียมโครงสร้างข้อความไว้ล่วงหน้าก่อนที่คุณจะต้องใช้จึงเป็นประโยชน์ ไม่ใช่ถ้อยคำสุดท้าย เพราะทุกเหตุการณ์จะแตกต่างกัน แต่เป็นโครงสร้าง: ใครต้องอนุมัติข้อความ รายละเอียดใดต้องรวมไว้ อัปเดตจะถูกบันทึกที่ไหน และใครรับผิดชอบกลุ่มเป้าหมายแต่ละกลุ่ม
ชุดสื่อสารง่าย ๆ ก็เพียงพอที่จะทำให้ชั่วโมงแรกวุ่นวายน้อยลง โดยอาจประกอบด้วย
- เทมเพลตประกาศเหตุการณ์ภายใน
- เทมเพลตการแจ้งเตือนลูกค้า
- เทมเพลตอัปเดตสำหรับพาร์ตเนอร์หรือผู้ขาย
- ประเด็นพูดคุยสำหรับฝ่ายสนับสนุนลูกค้า
- รายการตรวจสอบการแจ้งเตือนหน่วยงานกำกับดูแล
- รายชื่อโฆษกที่ได้รับอนุมัติ
- รายชื่อผู้ติดต่อสำหรับการส่งต่อเรื่องในด้านกฎหมาย ไอที ความเป็นส่วนตัว ผู้บริหาร และการสื่อสาร
- พื้นที่สำหรับบันทึกอัปเดตและการตัดสินใจทั้งหมด
การเตรียมพร้อมช่วยให้ทีมมีจุดเริ่มต้นที่ปลอดภัยเมื่อความรวดเร็วและความแม่นยำสำคัญพอ ๆ กัน เทมเพลตที่เตรียมไว้จะช่วยให้มีสมาธิกับข้อเท็จจริงของเหตุการณ์มากขึ้น เช่น เกิดอะไรขึ้น ใครได้รับผลกระทบ มีการดำเนินการอะไรไปแล้ว และผู้คนต้องทำอะไรต่อไป
Proton Pass for Business ช่วยได้อย่างไร
การสื่อสารในเหตุการณ์ด้านความปลอดภัยต้องอิงกับข้อเท็จจริง ยิ่งธุรกิจจัดการการเข้าถึงได้ชัดเจนก่อนเกิดเหตุการณ์มากเท่าไร ก็ยิ่งอธิบายได้ง่ายขึ้นว่าเกิดอะไรขึ้น อะไรอาจได้รับผลกระทบ และมีการเปลี่ยนแปลงอะไรไปแล้ว
โปรแกรมจัดการรหัสผ่านสำหรับธุรกิจอย่าง Proton Pass for Business ช่วยให้ทีมลดความเสี่ยงที่เกี่ยวข้องกับข้อมูลยืนยันตัวตน พนักงานสามารถสร้างรหัสผ่านที่แข็งแกร่ง จัดเก็บไว้ในห้องนิรภัยรหัสผ่านที่เข้ารหัส ใช้การป้อนอัตโนมัติ แชร์ข้อมูลยืนยันตัวตนอย่างปลอดภัย จัดการพาสคีย์ และใช้การยืนยันตัวตนผ่านสองขั้นตอนที่มีมาให้ ส่วนผู้ดูแลระบบสามารถนำนโยบายรหัสผ่านไปใช้ ตรวจสอบบันทึกกิจกรรม จัดการการเข้าถึงด้วยการควบคุมตามบทบาท และรองรับการจัดเตรียมบัญชีผ่านการผสานรวม SCIM และ SSO
ระหว่างเกิดเหตุการณ์ คุณสมบัติเหล่านี้ช่วยให้ธุรกิจดำเนินการได้อย่างมั่นใจมากขึ้น หากบัญชีของพนักงานถูกโจมตี ผู้ดูแลระบบสามารถตรวจสอบการเข้าถึง ระบุข้อมูลยืนยันตัวตนที่แชร์กันซึ่งอาจต้องเปลี่ยน บังคับใช้การยืนยันตัวตนที่แข็งแกร่งขึ้น และลดการพึ่งพารหัสผ่านที่คัดลอกผ่านแชตหรือตารางคำนวณ
เตรียมพร้อมตอบสนองก่อนเกิดการละเมิดข้อมูลด้วยโปรแกรมจัดการรหัสผ่านสำหรับธุรกิจ
