แนวทางที่ไม่ดีด้านความปลอดภัยของผลิตภัณฑ์
(cisa.gov)ในตัวผลิตภัณฑ์เอง
ภาษาที่ไม่ปลอดภัยต่อหน่วยความจำ (C, C++ เป็นต้น)
ควรใช้ภาษาที่ปลอดภัยต่อหน่วยความจำให้มากที่สุด และสำหรับโปรแกรมเดิมที่ไม่เป็นเช่นนั้น ควรค่อย ๆ แทนที่ไปจนถึงสิ้นปี 2025
การรันคำสั่ง SQL โดยตรง
ให้ใช้ parameterized query, prepared statement หรือ ORM
การรันคำสั่งระบบปฏิบัติการโดยตรง
อินพุตที่ผู้ใช้ป้อนไม่ควรเป็นตัวคำสั่งเอง แทนที่จะรันคำสั่งโดยตรง ควรใช้ฟังก์ชันไลบรารีที่มีมาในตัว หรือจำกัดให้อินพุตอนุญาตเฉพาะตัวอักษรภาษาอังกฤษ/ตัวเลข/ขีดล่างเท่านั้น
การใช้รหัสผ่านที่เป็นที่รู้จักอย่างแพร่หลาย
ควรทำให้หลีกเลี่ยงได้มากที่สุดด้วยวิธีต่อไปนี้
- จัดเตรียมรหัสผ่านที่ไม่ซ้ำกันตั้งแต่ต้น
- ระหว่างการติดตั้ง ให้บังคับให้ผู้ใช้สร้างรหัสผ่านที่แข็งแรง
- กำหนดข้อจำกัดด้านเวลาให้รหัสผ่าน เช่น MFA
- กำหนดให้ต้องมีการเข้าถึงทางกายภาพเพื่อให้ได้สิทธิ์ยืนยันตัวตนอย่างแน่นอน
- จัดทำแคมเปญหรือเปลี่ยนไปใช้วิธีการยืนยันตัวตนที่ปลอดภัยกว่าที่มีอยู่เดิม
การปล่อยช่องโหว่ที่เป็นที่รู้กันอยู่แล้วทิ้งไว้
ช่องโหว่ที่ระบุในหน้านั้นจะต้องได้รับการป้องกัน "ทั้งหมด" หากมีการรายงานช่องโหว่ใหม่ ต้องแก้ไขให้ทันท่วงที และควรแจ้งเตือนผู้ใช้ที่ยังไม่อัปเดตเป็นเวอร์ชันที่แก้ไขแล้ว
ไลบรารีโอเพนซอร์สที่มีช่องโหว่
ควรแจ้งและมีส่วนร่วมกับไลบรารีที่ใช้งานอยู่อย่างมีความรับผิดชอบในประเด็นดังกล่าว โดยรวมถึงมาตรการต่อไปนี้
- จัดทำ SBOM: เพื่อแสดงว่าซอฟต์แวร์ใช้ไลบรารีใดบ้าง
- ประเด็นที่ควรนำไปใช้กับไลบรารีโอเพนซอร์สที่พึ่งพาอยู่
- ดำเนินการตรวจสอบด้านความปลอดภัย
- เลือกโครงการคุณภาพดีที่ต่อเนื่อง ได้รับการปกป้องอย่างดี และได้รับการบำรุงรักษาอย่างเหมาะสม การยึดตามหลักการความปลอดภัยลักษณะนี้ก็เป็นเรื่องที่ดี
- ต้องตรวจสอบอย่างต่อเนื่องว่ามีช่องโหว่ที่เป็นที่รู้จักหรือไม่
- ผู้ผลิตควรมีสำเนาเก็บไว้ล่วงหน้า และไม่ควรอัปเดตจากแหล่งที่ไม่ผ่านการตรวจสอบ
- ต้องคำนึงถึงต้นทุนของการอัปเดตเป็น major version ใหม่หรือการรับ security patch
หากช่องโหว่ไม่ได้ส่งผลกระทบต่อผลิตภัณฑ์ ควรเปิดเผยต่อสาธารณะว่าทำไมช่องโหว่นั้นจึงไม่ส่งผลกระทบ
อัลกอริทึมเข้ารหัสที่มีช่องโหว่หรือไม่เป็นที่รู้จัก (TLS 1.0/1.1, DES, MD5 เป็นต้น)
ต้องใช้อัลกอริทึมสมัยใหม่ และเพิ่มเติมจากนั้น ควรเตรียมใช้อัลกอริทึมเข้ารหัสแบบควอนตัมที่ผ่านการทำให้เป็นมาตรฐานตามแนวทางของ NISTด้วย
คีย์ลับที่อยู่ในซอร์สโค้ด
ควรใช้ Secret Manager เพื่อให้โปรแกรมดึงคีย์ลับได้อย่างปลอดภัย นอกจากนี้ควรตรวจสอบด้วยว่ามีคีย์ลับอยู่ในซอร์สโค้ดหรือไม่
ในด้านฟังก์ชันความปลอดภัย
ไม่รองรับ MFA (รวมถึงรองรับแค่ passkey เท่านั้น)
ยกเว้นกรณีที่ความล่าช้าอาจเป็นอันตราย เช่น อุปกรณ์การแพทย์ในห้องฉุกเฉิน โดยพื้นฐานแล้วควรสร้าง MFA เองหรือใช้ตัวพิสูจน์ตัวตนภายนอก ควรกำหนดให้ผู้ดูแลระบบต้องใช้ และผู้ดูแลระบบก็ควรกำหนดให้ผู้ใช้ภายในองค์กรต้องใช้ต่อไป
ไม่มีหลักฐานการบุกรุกให้ตรวจสอบ
- ในฐานะฟังก์ชันพื้นฐานอย่างยิ่ง ควรสร้าง log ที่เกี่ยวข้องกับการเปลี่ยนแปลงหรือการดูการตั้งค่า, ประวัติการเข้าสู่ระบบ และการเข้าถึงข้อมูล
- ในกรณีของผู้ให้บริการคลาวด์ ควรเก็บ log เหล่านี้ไว้อย่างน้อย 6 เดือนโดยไม่มีค่าใช้จ่ายเพิ่มเติม และทำให้ผู้ใช้สามารถดูได้
ในด้านกระบวนการและนโยบายขององค์กร
ไม่เผยแพร่ CVE
ช่องโหว่ที่ร้ายแรงหรืออาจส่งผลกระทบมากควรถูกเปิดเผยทันที
ไม่เผยแพร่วิธีการเปิดเผยช่องโหว่ (VDP)
ควรเผยแพร่นโยบายดังต่อไปนี้
- อนุญาตให้สาธารณชนทดสอบได้
- ให้คำมั่นว่าจะไม่ดำเนินคดีทางกฎหมายกับผู้ที่กระทำโดยสุจริต
- มีช่องทางการรายงานที่ชัดเจน
- แนวปฏิบัติที่ดีของ CVD (Coordinated Vulnerability Disclosure) และมาตรฐานสากล
ต้องแก้ไขช่องโหว่ที่ถูกรายงานอย่างทันท่วงทีตามลำดับความเสี่ยง
(ในกรณี on-premise) ระยะเวลาการสนับสนุนไม่ชัดเจน
ต้องสื่อสารระยะเวลาการสนับสนุนอย่างชัดเจน และจัดส่งการอัปเดตความปลอดภัยตลอดช่วงเวลานั้น
- One-click exploit บน KakaoTalk
- GN⁺: NIST (สถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐฯ) ห้ามกำหนดข้อบังคับเรื่องชุดอักขระเฉพาะในรหัสผ่าน
- ทำเนียบขาวเรียกร้องให้นักพัฒนาหลีกเลี่ยง C และ C++ และใช้ภาษาที่ "ปลอดภัยต่อหน่วยความจำ"
- แฮ็กรถของฉัน: Hyundai Ioniq: พบข้อความเข้ารหัส RSA ที่ค้นหาเจอได้ผ่าน Google อยู่ในซอร์สโค้ด
7 ความคิดเห็น
ความปลอดภัยนี่ พอเผลอแป๊บเดียวก็พังแล้ว,,! (เหมือนเคยเห็นอะไรแบบนี้ในกองทัพนะ)
อย่ายอมแพ้แม้จะหักกลาง!
เหมือนจะกลับมามีการพูดกันอีกแล้วว่าอย่าใช้ ORM..
แค่ใช้ Prepared Statement แทน ORM ก็พอแล้ว
zzz
ยังไงก็ต้องมีหลักการอยู่แล้ว แค่ทำตามได้ยากเท่านั้น...
ชอบครับ เห็นด้วยครับ
การบังคับให้ผู้ใช้สร้างรหัสผ่านที่รัดกุม != ต้องมีอักขระพิเศษ ตัวพิมพ์ใหญ่-เล็กภาษาอังกฤษ และตัวเลขครบถ้วนเสมอ
จริง ๆ แค่ยาวพอเหมาะก็เป็นรหัสผ่านที่รัดกุมได้แล้ว