Software Security Requirement Guideline กับการปล่อยไก่ของผม

เรื่องเล่ายามดึก

ตอนเข้ามาเกียรตินาคินใหม่ๆ ได้เขียน Software Security Requirement Guideline ฉบับหนึ่งเพื่อให้ทาง Development Team และ Vendor ทำตาม โดยอ้างอิงจากเอกสารของ OWASP ฉบับหนึ่ง (ซึ่งเดี๋ยวจะบอกทีหลัง) เป็นหลัก โดยมีการปรับแก้เพิ่มเติมบางอย่างตาม IT Policy ของธนาคาร และ Industrial Standard และ Regulation เช่น PCI-DSS หรือ Best Practice ของธนาคารแห่งประเทศไทยเข้าไป (ซึ่งไม่ได้มากมายเพราะส่วนใหญ่ของ OWASP จะดีกว่าอยู่แล้ว)

หลังจากนั้นเอกสารฉบับนี้ก็มีการรวมร่างกับ Software Architecture Requirement กลายเป็น Software Security and Architecture Guideline ล่าสุดคือ Version 4 และผมก็ไม่ได้เขียนเองแล้ว แต่เป็นคน Review

ตัดกลับมาเมื่อคืนวาน น้องในกลุ่ม OWASP บอกว่าหาคนไปพูดเรื่อง
ASVS ในงาน Thailand Security Day อะไรสักอย่างที่ ETDA วันที่ 26 มิถุนายน ผมก็บอกว่า ASVS คืออะไร ไม่เคยได้ยิน สักพักก็มีการส่ง Link ของเอกสารมาให้ เปิดไปดูก็เห็นเขียนว่า OWASP Application Security Verification Standard 3.0.1 (July 2016) เราก็อืม มันเป็นตัวย่อนี่เอง นั่งอ่านไปสักพักก็รู้สึกว่าคุ้นๆ แฮะ นึกไปนึกมาก็จำได้ว่าเราเคยใช้รายการในเอกสารฉบับนี้เขียน Software Security Guideline ของธนาคาร กลับไปเช็คดู เฮ้ย เราใช้ Version 2.0 เป็นต้นฉบับนี่นา

ด้วยอารมณ์ที่คิดว่าต้อง Update รายการให้ทันสมัยเลยส่ง Link ไปให้น้องในทีมที่ดูแลเอกสารต่อ บอกว่าเราต้อง Update ให้กับเอกสาร Software Security and Architecture Guideline แล้วล่ะ

วันนี้น้องในทีมมาบอกว่า พี่ ผมใช้เอกสารของ OWASP ฉบับนี้มาแก้เอกสารของเราในเวอร์ชันปัจจุบันแล้วนะ พี่เป็นคนรีวิวเองด้วย

ไก่วิ่งเต็มที่ทำงาน จับแทบไม่ทัน

Secure Software Design 101: Fail-Safe / Fail-Secure

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

ตัวอย่างที่แสดงให้เห็นความแตกต่างของทั้งสองแบบเช่น ในการออกแบบประตูบริเวณศูนย์ข้อมูล (Data Center) ซึ่งใช้ Access Control ในการควบคุมการเข้าออกศูนย์ข้อมูล ในกรณีที่เกิดเหตุฉุกเฉินเช่นเพลิงไหม้ ในบริเวณที่พนักงานนั่งทำงานจะต้องออกแบบให้ Fail-Safe คือหากไฟดับประตูต้องเปิดทันทีเพื่ออพยพคนออก แต่ห้องเครื่องศูนย์ข้อมูลจะต้องออกแบบให้ Fail-Secure คือเมื่อตัดไฟต้องปิดประตูเสมอเพื่อป้องกันคนเข้าถึงเครื่องแม่ข่ายหรืออุปกรณ์เครือข่ายโดยไม่ได้รับอนุญาต

หรือในกรณีอุปกรณ์ Security บนเครือข่าย อุปกรณ์ Firewall จะมีโครงสร้างเป็นแบบ Fail-Secure คือเมื่อมีการขัดข้อง จะแยกเครือข่ายที่เชื่อมกันออกจากกัน ไม่ยอมให้เครือข่ายข้ามถึงกัน แต่ IPS (Intrusion Prevention System) ซึ่งวางขวางระบบเครือข่ายเช่นกันจะทำในทางตรงกันข้าม คือหากขัดข้องจะมีการ Bypass เครือข่ายอัตโนมัติ ซึ่งเป็นแนวทาง Fail-Safe

แล้วในกรณีการออกแบบซอฟต์แวร์ เราจะใช้หลักการ Fail-Safe หรือ Fail-Secure อย่างไร ขอให้หลักการไว้คร่าวๆ ดังนี้

• หากอยู่ในเงื่อนไขที่ต้องการ Availability มากกว่า Confidentiality หรือ Integrity ให้ออกแบบส่วนนั้นเป็น Fail-Safe เช่นการออกแบบ User Interface ต่างๆ บน Web Application เมื่อเกิด Error 4xx หรือ 5xx ก็ควรจะมี Landing Page ให้คำแนะนำกับผู้ใช้ และมีลิ้งค์ไปยังหน้าแรกที่เป็น Static Page หรือหน้า Login เพื่อป้องกันไม่ให้ผู้ใช้ดำเนินการที่ทำให้ระบบมีปัญหาเพิ่มขึ้นเช่นกดปุ่ม Refresh ของ Web Page เพื่อทำงานซ้ำ
• หากอยู่ในเงื่อนไขที่ต้องการ Confidentiality หรือ Integrity มากกว่า Availability ให้ออกแบบส่วนนั้นเป็น Fail-Secure เช่นการทำ Financial Transaction หากเกิดข้อผิดพลาดทางใดทางหนึ่งเช่นการโอนเงินจากบัญชีหนึ่งไปยังอีกบัญชีหนึ่งของอีกธนาคาร สามารถตัดบัญชีต้นทางได้แต่ไม่สามารถเอาเข้าบัญชีปลายทางได้ไม่ว่าจะเกิดจากระบบที่ใช้โอน ผู้ให้บริการโอน (Switching) การสื่อสารขัดข้อง หรือกรณีใดก็แล้วแต่ จะต้องทำการย้อนกลับ (Rollback) ทันที

สิ่งหนึ่งที่สำคัญในการออกแบบซอฟต์แวร์ที่มีลักษณะ Fail-Safe/Fail-Secure ให้ได้ดีคือการจำลองกรณีผิดพลาดให้ได้มากที่สุดว่าเกิดจากอะไรได้บ้าง แล้วหาเส้นแบ่งในการตรวจสอบข้อผิดพลาดนั้นๆ (Threshold) เพื่อตัดสินใจว่าจะเข้าสู่กระบวนการจัดการความล้มเหลวของระบบ

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

ตอนที่เกี่ยวข้อง

Secure Software Design 101: Least Privilege

Secure Software Design 101: Need to Know

Secure Software Design 101: Need to Know

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

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

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

Need to Know มักจะถูกใช้สับสนกับ Least Privilege เนื่องจากเป็นเรื่องการควบคุมสิทธิ์เช่นเดียวกัน โดยข้อแตกต่างจะสรุปได้ดังนี้

ข้อเปรียบเทียบ	Need to Know	Least Privilege
การเข้าถึง	อ่านเท่านั้น	อ่าน เขียน สั่งให้ทำงาน เป็นต้น
Object	ข้อมูลเท่านั้น	ข้อมูล แฟ้ม บริการ กระบวนการ เป็นต้น
Security Foundation	Confidentiality	Confidentiality, Integrity
การควบคุมการเข้าถึงข้อมูล	ระดับ Record & Field	ระดับSchema (อาจถึงระดับ Field)
สิทธิ์	ตามที่ได้รับมอบหมาย(Assignment)	ตามบทบาท(Role)

จำไว้เสมอว่า Subject ควรได้รับข้อมูลเฉพาะที่จำเป็นต้องรู้เพื่อทำงานตามหน้าที่ที่ได้รับมอบหมายเท่านั้น

ตอนที่เกี่ยวข้อง

Secure Software Design 101: Least Privilege

Secure Software Design 101: Fail-Safe / Fail-Secure

Secure Software Design 101: Least Privilege

ในการออกแบบทางด้าน Security สิ่งหนึ่งที่มักจะพูดถึงก็คือเรื่องการให้สิทธิ (Authorization) เพื่อทำงานใดๆ ไม่ว่าจะเป็นระดับผู้ใช้ (User) หรือกระบวนการ (Process) ซึ่งเราเรียกรวมกันว่าประธานหรือผู้กระทำ (ขอใช้ทับศัพท์ว่า Subject or Actor) กระทำการใดๆ ต่อข้อมูล บริการ (Service) หรือแม้แต่กระบวนการ (Process) ด้วยกันเอง ซึ่งเรียกรวมๆ กันว่ากรรม (ขอใช้ทับศัพท์ว่า Object) ซึ่งสามารถเขียนเป็นตัวอย่างการรวมกันของ ประธาน กริยา กรรม ได้เช่น

ประธาน (Subject)	กริยา (Access)	กรรม (Object)
ผู้ใช้ (User) โปรแกรม (Program) กระบวนการ(Process)	อ่าน (Read) เขียน (Write) สั่งให้ทำงาน(Execute)	แฟ้มข้อมูล (File) ฐานข้อมูล(Database) บริการ (Service) กระบวนการ(Process) ทรัพยากร(Resource)

การออกแบบการให้สิทธินั้นมีแนวคิดเพื่อความมั่นคงปลอดภัยก็คือการให้สิทธิ Subject ดำเนินการต่อ Object น้อยที่สุดเท่าที่จะทำงานได้สำเร็จตามวัตถุประสงค์ หรือที่เรียกว่า Least Privilege เช่น Web Application ซึ่งทำงานกับ Database เพียงแค่ insert, select, update, delete ก็ควรจะสร้าง Database User ให้กับ Web Application นั้นให้มีสิทธิ์เท่าที่ทำงานดังกล่าวได้ ไม่ใช่ปล่อยให้ใช้ User ที่มีสิทธิ์สูงเช่น SA, root, SYS หรือ Schema Owner หรือ User ที่สามารถใช้คำสั่งจัดการ Schema ของข้อมูล (DDL: Data Definition Language) เช่น create, alter, drop เป็นต้น

สิทธิดังกล่าวข้างต้นเป็นสิทธิในเชิงวิธีการเข้าถึง แต่ยังมีในเชิงปริมาณที่ต้องคำนึงถึงคือจำนวนและชนิดของ Object ที่เข้าใช้งาน หลักการ Lease Privilege ก็ครอบคลุมในมิตินี้ด้วย กล่าวคือหาก Subject ไม่มีความจำเป็นที่ต้องทำงานกับ Object ใด ก็ควรห้ามการเข้าถึง Object นั้นๆ ด้วย

การให้สิทธิ์แก่ Subject มากเท่าไรก็เป็นการเพิ่มพื้นที่ในการโจมตี (Attack Surface) ต่อ Object มากเท่านั้นและเมื่อ Subject โดนยึดได้ (Compromised) Object ก็มีโอกาสถูกกระทำตามสิทธิที่ให้แก่ Subject ไว้

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

ตอนที่เกี่ยวข้อง

Secure Software Design 101: Least Privilege

Secure Software Design 101: Need to Know

Secure Software Design 101: Fail-Safe / Fail-Secure