Okta บริษัทจัดการข้อมูลประจำตัว และการเข้าถึงข้อมูล ออกมาแจ้งเตือนการโจมตีรูปแบบ Social Engineering ที่มีการกำหนดเป้าหมายไปที่ฝ่าย IT service desk ในสหรัฐอเมริกา โดยมีการพยายามหลอกให้พวกเขารีเซ็ต multi-factor authentication (MFA) ของผู้ใช้งานที่มีสิทธิ์สูง ซึ่งเป้าหมายของผู้โจมตีคือขโมย Super Administrator ที่มีสิทธิ์สูง เพื่อเข้าถึง และใช้ข้อมูลส่วนตัวของผู้ที่ถูกโจมตีมาแอบอ้าง (more…)

Okta ผู้ให้บริการด้าน Identity and Access Management (IAM) ได้ออกอีเมลที่ระบุว่า "เป็นความลับ" แจ้งเตือนเหตุการณ์ Security Incident ถึงกรณีที่ Private GitHub ของตนถูกแฮ็กในเดือนธันวาคมที่ผ่านมา โดยทาง BleepingComputer ได้รับการยืนยันว่าเกิดเหตุการณ์นี้เกิดขึ้นจริง

รายละเอียดเหตุการณ์

เมื่อต้นเดือนธันวาถาม GitHub ได้แจ้งเตือน Okta เกี่ยวกับการตรวจพบพฤติกรรมน่าสงสัยเกี่ยวกับการเข้าถึงที่เก็บ Source Code ของ Okta
จากการตรวจสอบ พบว่าเป้าหมายในการโจมตีครั้งนี้คือการคัดลอกโฟลเดอร์ Repository ที่เป็นที่เก็บข้อมูลของ Okta
อย่างไรก็ตาม Okta ยืนยันว่า แม้ผู้โจมตีจะขโมย Source Code ของ Okta ได้สำเร็จ แต่ก็ไม่สามารถเข้าถึงบริการ หรือข้อมูลลูกค้าของ Okta ได้ ดังนั้นลูกค้าที่อยู่ภายใต้มาตรฐาน HIPAA, FedRAMP หรือ DoD ของ Okta จะไม่ได้รับผลกระทบ เนื่องจากบริษัทไม่มีการใส่ข้อมูลของลูกค้าที่เป็นความลับบน Source Code ด้วยเหตุนี้ลูกค้าจึงไม่จำเป็นต้องดำเนินการใด ๆ
ทันทีที่ Okta ทราบเกี่ยวกับพฤติกรรมที่น่าสงสัย จึงได้ทำการจำกัดการเข้าถึงไฟล์ Repository ชั่วคราว นอกจากนี้ยังยกเลิกการ Integration จาก third-party applications ทั้งหมดบน GitHub
จากนั้นได้ตรวจสอบการเข้าถึงทั้งหมดที่ไปยัง Repository บน GitHub รวมถึงทดสอบการเข้าถึงไฟล์ด้วย Environment อื่น ๆ เพื่อให้แน่ใจว่าไม่มีใครสามารถเข้าถึงไฟล์ได้ พร้อมกับชี้แจงว่าเหตุการณ์ครั้งนี้กระทบกับ Okta Workforce Identity Cloud (WIC) code repositories เท่านั้น แต่ไม่กระทบกับ Auth0 Customer Identity Cloud product

สรุปเหตุการณ์ Cybersecurity Incident ของ Okta ในปี 2565

ช่วงปลายเดือนมกราคม 2565 Okta ก็ได้มายอมรับว่ามีข้อมูลรั่วไหล และอาจส่งผลกระทบต่อลูกค้า 2.5% หรือประมาณ 375 องค์กรในเวลานั้น โดยพิจารณาจากฐานลูกค้าของ Okta มากกว่า 15,000 รายในเดือนนี้
เดือนมีนาคม พบว่ากลุ่ม Lapsus$ อ้างว่าได้สิทธิ์เข้าถึง Admin Console และข้อมูลลูกค้าของ Okta โดยการโพสต์ภาพหน้าจอที่มีข้อมูลที่ถูกขโมยบน Telegram
ในเดือนเมษายน พบว่า Okta มีข้อมูลรั่วไหลเป็นระยะเวลา 25 นาที ก่อนที่เหตุการณ์นั้นจะหยุดลง
เดือนกันยายน Auth0 ของ Okta ได้เคยเกิดเหตุการณ์ในลักษณะเดียวกันคือมีการเข้าถึงแหล่งเก็บ Source Code จาก Third Party ภายนอก

ที่มา : bleepingcomputer

บทเรียนจากเหตุการณ์ข้อมูลรั่วไหลของ Okta

จากเหตุการณ์ที่ Okta ถูกแฮ็กโดยกลุ่ม Lapsus$ ในเดือนมกราคม ทำให้เกิดการตั้งคำถามเป็นจำนวนมากด้านความปลอดภัยของข้อมูลส่วนบุคคล

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

Identity providers (IdPs) ช่วยทำให้องค์กรต่างๆ บริหารจัดการ Identity directories, authentication services เช่น การใช้ single sign-on และ multifactor authentication (MFA) และโดยทั่วไปช่วยในการจัดการเกี่ยวกับการเข้า และออกจากงานของพนักงานในองค์กรให้ทำได้ง่ายขึ้น

ในสถานการณ์ปกติจะพบการเข้าถึงระบบผ่านทาง IdP หรือเครื่องมือ Identity governance and administration (IGA) เท่านั้น ซึ่งหาก IdP ถูกโจมตี จะมีมาตรการตรวจสอบความถูกต้องของข้อมูลได้อย่างไร

วิธีที่จะบรรลุเป้าหมายนี้คือการการเฝ้าระวังการเชื่อมต่อกับแอป และบริการทั้งหมดขององค์กรอย่างเข้มงวด ตัวอย่างเช่น การเฝ้าระวังข้อมูลใน AWS อย่างเดียวอาจไม่เพียงพอหาก User ยังมีการใช้ GitHub, Google Docs และบริการระบบคลาวด์อื่น ๆ สำหรับการทำงาน

การตรวจสอบมีความจำเป็นต้องเฝ้าระวังพฤติกรรมทั้งหมดที่เกิดขึ้น ไม่เฉพาะกับข้อมูลที่ใช้ระบุตัวตนเท่านั้น แต่ยังต้องดูจาก Asset ขององค์กรด้วย เช่น local IAM, external users, service principals ที่มีการเข้าถึง Asset ขององค์กร ซึ่งหากมีการตรวจสอบสิทธิ์การเข้าถึงอย่างเข้มงวด จะทำให้สามารถตรวจสอบเหตุการณ์ที่น่าสงสัย และลดความเสี่ยงในการถูกเข้าถึงข้อมูลที่สำคัญได้หากให้สิทธิ์กับผู้ใช้งานเท่าที่มีความจำเป็นเท่านั้น

3 วิธีที่สามารถจำกัดความเสียหาย และทำให้แฮ็กเกอร์ขโมยข้อมูลได้ยากขึ้น

1. ลดการเปิดเผยข้อมูล

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

2. ตรวจสอบเฝ้าระวังอย่างต่อเนื่อง

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

3. รักษาความปลอดภัยของ Supply Chain

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

ที่มา: www.

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

Okta: "ยอมรับความผิดพลาด" ของการ**ล่าช้าในการแจ้งเตือนข้อมูลรั่วไหล**

เมื่อวันศุกร์ที่ผ่านมา บริษัท Okta ได้แสดงความเสียใจที่ไม่ได้มีการเปิดเผยรายละเอียดเกี่ยวกับการถูกโจมตีจากกลุ่มแฮ็กเกอร์ Lapsus$ ให้เร็วกว่านี้ และได้มีการเปิดเผยข้อมูล timeline การถูกโจมตีโดยละเอียดดังนี้

การโจมตีจากกลุ่มแฮ็กเกอร์ Lapsus$ เกิดขึ้นที่บริษัท Sitel ซึ่งเป็น third-party ที่ให้บริการ Customer Support ให้กับ Okta

"ในวันที่ 20 มกราคม 2022 Security Team ของ Okta ได้รับการแจ้งเตือนว่ามีการเพิ่มข้อมูลใหม่บางอย่างใน Account ของ Okta ที่ถูกใช้โดย Engineer ของ Sitel ซึ่งพบว่าข้อมูลนี้คือ Password" Okta อธิบาย

"แม้ว่าจะทำไม่สำเร็จ แต่เราได้ reset account และแจ้งทาง Sitel ให้รับทราบ" ซึ่งทาง Sitel ได้ร่วมมือกับบริษัทผู้เชี่ยวชาญด้าน Forensic เพื่อดำเนินการ Investigate หาสาเหตุต่อไป

"ในวันที่ 21 มกราคม 2022 ทีม Security ของ Okta แจ้งเตือนเหตุการณ์ดังกล่าวเป็น Security Incident และ Okta Service Desk ทำการ Terminated account ที่เกี่ยวข้องไปก่อนจนกว่าจะได้ root cause จากผลการ Forensic และยังได้แชร์ข้อมูล IOC ที่พบกับ Sitel โดยทาง Sitel แจ้งว่าได้ให้บริษัทผู้เชี่ยวชาญด้าน Forensic ดำเนินการสืบสวนอยู่"

(more…)