Coding ให้ Secure ต้องเริ่มตั้งแต่ Process
ทุกคนรู้ไหมครับการ Coding ให้ Secure ไม่ได้ขึ้นอยู่กับแค่ Engineer เท่านั้นนะ…
ย้อนกลับไปในช่วงที่ที่ผมเริ่มทำงานครั้งแรก ผมเป็น Software Engineer อยู่ Bank แห่งหนึ่งในประเทศไทย ซึ่ง Product ส่วนใหญ่จะ Relate กับ Financial business (ก็แหงละทำงาน Bank นิหว่า 55555+) จึงทำให้ Working process ค่อนข้างมีความ Strict สูงมาก และการจะทำ Product ซักตัวนึงใน Ecosystem ของ Bank เนี่ยจะต้อง Spend ทั้งเวลา ทั้ง Effort ค่อนข้างมาก ไม่ว่าจะเป็นการ Define Requirement, Legalization, Reporting , Researching, Planning, Decision, Approval และอื่นๆ มากมาย กว่าจะกลายมาเป็น Business Requirment ที่พร้อมจะส่งให้ Engineer Team รับช่วงต่อ
พอมาถึงจุดนี้ก็ใช่ว่าจะเริ่มทำได้เลยนะ…
ทุกๆ Requirement หรือ Product ที่ถูก Feed เข้ามาต้องผ่าน Process ทั้งหลายแหล่ของฝั่ง Engineer อีกหรือก็คือ SDLC (Software Development Lifecycle)
ซึ่ง Process เหล่านี้ก็จะต้องถูกตรวจสอบโดยเหล่า Audit ทั้งหลาย เพื่อการันตีถึงคุณภาพให้เป็นไปตาม Regulation ของ BOT (ก็ด้วยความ Bank อะเนอะ)
จากที่ผมเล่าไปข้างต้น แสดงให้เห็นถึง Process ที่มีความ Strict มีความ Consistentcy อย่างมากซึ่งเกิดจากการร่วมมือกันของหลายๆ ฝ่ายโดยสิ่งเหล่านี้มันช่วยการันตีว่า Organization จะ Delivery Product ที่มีคุณภาพออกไปสู่ตลาดอย่างแน่นอน (ถึงแม้ว่ามันจะเสียเวลาเยอะก็ตาม 😫) ซึ่งหนึ่งใน Metric ที่สำคัญมากที่จะเป็นตัวบ่งบอกได้ว่า Product ของเรามีคุณภาพหรือเปล่าก็คือ Security โดยเฉพาะ Financial Product ทั้งหลายที่ User จะ Mindful กับเรื่องนี้เป็นอย่างมาก
ถึงแม้ว่า Product ของเราจะใช้งานง่าย มี User Interface ที่สวยงาม มี Journey ที่ยอดเยี่ยมหรือ Useful เพียงใดก็ตาม Once ที่ System ไม่ปลอดภัย มีช่องโหว่
โดน Attack โดน Hack ขึ้นมามันอาจจะสร้างความเสียหายให้อย่างมหาศาล และแน่นอน User ก็หนีหมด 😢
ในทางกลับกัน ถ้าเอาแต่ Focus เรื่อง Security โดยไม่ Care เรื่อง Usability หรือ User Experience มันก็อาจจะทำให้ไม่มีใครสนใจจะมาใช้ Product ของเราเลยก็ได้ 😑
องค์พระสัมมาสัมพุทธเจ้าทรงตรัสเอาไว้ว่า “ตึงเกินไป สายพิณก็จะขาด หย่อนเกินไป เสียงพิณก็จะไม่ไพเราะ เมื่อปรับสายให้พอดี เสียงก็จะไพเราะ” ทุกอย่างมีตรงกลางของมันเรื่องนี้ก็เช่นกัน 🙏
อย่างไรก็ตามการจะทำให้ Product มีคุณภาพตอบโจทย์ User ทั้งในด้านของ Functional และ Non-Functional มันจะต้องถูกเกลามาตั้งแต่ต้นน้ำ ไม่ว่าจะเป็นเรื่องของ Business Requirement, Risk Management, Policy Management, Development และอื่นๆ เช่นเดียวกันกับการทำให้ Product ของเรามี Security ที่ดีมันก็ต้องเริ่มตั้งแต่ Process เช่นกัน
เพราะฉะนั้นครับใน Topic นี้ผมจะมา Explain ถึง Pratices ที่มีความสำคัญต่อการทำ Software Development ให้ Secure ใน Process ต่างๆ
เมื่อเร็วๆนี้ TokenX ได้มีการจัด Internal Session ขึ้นในเรื่องของ Secure Coding ซึ่งหนึ่งใน Topic ที่สำคัญของ Session นี้ก็คือ SDL (Security Development Lifecycle) โดยมี Reference มาจาก SDL Practices ของทาง Microsoft ซึ่งเป็นการพูดถึง Practices ต่างๆ ที่ช่วยในการ Support Security Assurance และ Compliance Requirements นอกจากนั้นยังช่วยให้ Engineer สามารถสร้าง Software ที่มีความปลอดภัยสูง ลดช่องโหว่และความเสี่ยงต่างๆ อีกทั้งยังช่วยลด Cost ในการพัฒนาได้อีกด้วย (Security มันมี Cost นะ) โดยจะมีทั้งหมด
12 Practices หลักๆ ที่ผมสรุปมาดังนี้
แวะขายของสักนิด… TokenX เป็นบริษัทภายใต้กลุ่ม SCBX ที่ให้บริการเกี่ยวกับ Token Digital ได้อย่างครบวงจร โดย Base on Label ที่ว่า Tokenization Success Partner ไม่ว่าจะเป็น
ICO Portal (regulated by the SEC), TKX Enterprise Solutions, TKX Chain และ อื่นๆอีกมากมายที่ On Pipeline
1.) Provide Training
การ Training เป็นการสร้าง Awareness และ Perception ให้กับทีม (ทุก Role ที่มีส่วนเกี่ยวข้องในการพัฒนา Product ไม่ใช่แค่ Engineer) ไม่ว่าจะเป็นเรื่องของ Policies, Practices, Standards และ Requirements ซึ่ง Goal ของการ Training ไม่จำเป็นต้องไปถึง Expert Level หรือ เทียบเท่า Penetration Tester
สิ่งสำคัญคือ ทุกคนเข้าใจ Security Best Practices หรือเปล่า เข้าใจมุมมองของ Attacker เข้าใจ Target ของ Attacker หรือเปล่า
แวะอีกสักหน่อย… TokenX มีการจัด Training ให้กับพนักงานอยู่ตลอดเวลา ทั้งแบบ Official (ส่งพนักงานไป Train กับสถาบันภายนอก, เชิญวิทยากรมาให้ความรู้)และ Unofficial (Knowleage Sharing Session, Tech Solution Session, Podcast, etc)และยังมีการแจกคอร์สอย่าง Udemy เพื่อให้พนักงานโดยเฉพาะ Engineer อย่างเราๆ หาความรู้ได้ตลอดเวลาด้วย
2.) Define Security Requirements
เมื่อ Trend ของสังคมเปลี่ยนไปก็มักจะเกิด Business ในรูปแบบใหม่เกิดขึ้นมามากมาย และ เช่นเดียวกันครับเมื่อมี Business ใหม่ก็มักจะตามมาด้วยปัญหา หรือ ช่องโหว่ต่างๆ ไม่ว่าจะในทาง Technical หรือ ในทาง Pratical ก็ตาม เพราะฉะนั้น ในทุกๆ ครั้งที่มีการ Define Business Requirements ขึ้นมาเราจะต้องพิจารณาถึง Security และ Privacy ใน Requirement ด้วย และที่สำคัญ Security Requirement จะต้องได้รับการ Observe และ Update อยู่เสมอเพื่อให้สอดคล้องกับ Trend ของสังคม, System Change (เมื่อมีการ Add-on Feature ใหม่ หรือ Business ใหม่), Threat หรือการโจมตีในรูปแบบใหม่ (อาจจะเป็น Pattern ใหม่)
3.) Define Metrics and Compliance Reporting
ในทุกๆ ครั้งที่พัฒนา Product เราจะรู้ได้อย่างไรว่า Product นี้มี Security Level ที่เพียงพอหรือยัง? ฉะนั้นเราจึงจำเป็นต้องมีการทำ Define Metrics เพื่อใช้ในการ Evaluate Security Quality โดยต้องมีการ Define the minimum acceptable levels and risks เพื่อเป็น Guidelines ให้ Engineer ทำตาม Criteria ได้
ซึ่งการ Define สิ่งเหล่านี้จะช่วยให้ทีมเข้าใจถึง Risks ที่อาจจะทำให้เกิด Security Issues ได้ และ ยังสามารถ Identify Security Defects และ ซ่อมได้ในทันทีระหว่างการพัฒนาด้วย
4.) Perform Threat Modeling
เป็นสิ่งที่จะช่วยให้เรามองเห็นภาพรวม เห็น Risk หรือ มีจุดอ่อนตรงไหน ใน Level ขององค์กร, Level ของ System หรือ Application ได้ ซึ่งทำได้หลากหลายรูปแบบ เช่น DFD (Data Flow Diagram) นอกจากนั้นยังช่วยให้เราสามารถวางแผนรับมือ คิดหาวิธีการป้องกัน และ Recovery System กลับมาได้
5.) Establish Design Requirements
ในการ Design Requirement มักจะมีการนำ Secure feature เข้ามาเป็นส่วนประกอบด้วย ซึ่งเราอาจจะต้องคำนึงถึงความเหมาะสมก่อน ทั้งในความเหมาะสมต่อการนำมาใช้งานร่วมกับ Business Requirement (อาจจะทำให้ System เรามีความ Complex มากขึ้น) หรือ ความ Expertise ของ Engineer ต่อ Secure feature นั้นด้วย เพราะ ถ้าเลือกใช้อย่างไม่เหมาะสม หรือ Engineer ไม่เชี่ยวชาญพอก็อาจจะทำให้เกิดช่องโหว่ที่ไม่คาดคิดขึ้นมาได้
6.) Define and Use Cryptography Standards
Cryptography เป็นหนึ่งใน Secure feature ที่แทบจะทุก System ต้องใช้ ฉะนั้นเราควรที่จะ Educate และเลือกใช้ Standard อย่างถูกต้องและเหมาะสมกับ Business Requirement ด้วย
7.) Manage the Security Risk of Using Third-Party Components
ในปัจจุบันการพัฒนา Software หรือ System ส่วนใหญ่มีการนำ Third-Party Components มาใช้กันอย่างแพร่หลาย ซึ่งในการนำมาใช้สิ่งที่สำคัญมากๆ คือ ควรจะตรวจสอบ หรือ ทำ Security Check ก่อนนำมาใช้งานเสมอ และที่สำคัญต้องคอย Observe Update และ วางแผนจัดการ Risk ที่อาจจะเกิดขึ้น จากการนำ Third-Party Components มาใช้งาน เช่น Check Integrity ทุกครั้งที่มีการใช้งาน หรือ Build Artifact Server ที่เป็น Internal ขึ้นมาเพื่อเก็บ Third-Party Components ต่างๆ แล้ว Internal Party ก็ทำการเรียกใช้งาน หรือ Install จาก Artifact Server นี้แทนโดยไม่ดึงจาก Public เป็นต้น
การ Check integrity เป็นการ Check ว่า Source ถูกแอบแก้ไขหรือเปล่า โดย Check จาก Hash signature โดยปกติถ้ามีการแก้ไขจะมีการ Bumb version ขึ้นมาใหม่ แต่การที่ถูกแก้ไขใน Version เดิมมันเป็นเรื่องที่ผิดปกติ ! (อาจจะโดน Hack)
ขอแชร์สักนิด ผมมีโอกาสได้คุยกับ Engineer Lead ใน Topic นี้ว่า “องค์กรที่มี Tech Stack ระดับแนวหน้าเค้าจัดการกับเรื่องนี้ยังไง?” คำตอบที่ได้คือ เค้าเอา Process มาครอบ เช่น มีการทำเรื่อง Request ว่าจะใช้ Component อะไรบ้าง, ทำ Security Check, Validate, Review แล้วก็ดึงเข้าไปเก็บไว้ใน Artifact Server และทุกๆปีจะมีการ Annouce ตัว Whitelist ของ Component ที่อนุญาติให้ใช้ได้ในปีนั้นๆ และที่สำคัญจะต้องคอย Update อยู่เสมอไม่ให้มันเป็น Legacy โดยมีการทำ Canary Release เผื่อเวลาเกิดปัญหาจะได้ไม่ Impact กับลูกค้าส่วนใหญ่ด้วย
8.) Use Approved Tools
เช่นเดียวกันกับหัวข้อที่แล้ว ในการนำ Tool ต่างๆเข้ามาใช้ไม่ว่าจะในทางตรง หรือ ทางอ้อมก็ควรจะมีการตรวจสอบก่อน หรือ ทำ Security Check ก่อนนำมาใช้งานเสมอ และต้องคอย Observe Update ด้วยโดยเฉพาะ Tool จำพวก Security Check ทั้งหลายที่ควรจะทำอย่างสม่ำเสมอ
9.) Perform Static Analysis Security Testing (SAST)
เป็นการ Analysis source code ก่อนการ Complied ยกตัวอย่างเช่น Review source code โดยปกติแล้วการ Review source code นอกจากเราจะ Review code standard และ Business logic แล้วในทาง Security ก็ควรจะต้องดูครอบคลุมไปถึงจุดที่อาจจะเกิด Risk หรือ ช่องโหว่ด้วย เช่น การใช้ Function ที่ Unsafe หรือ การมีอยู่ของ Logic ที่ทำให้เกิด Risk หรือ ทำให้เกิด DOS (Denial of Service) ได้เป็นต้น
หรืออาจจะใช้ Tool มาช่วยในการ Scan source code เช่น SonarQube หรือ CodeQL เป็นต้น
10.) Perform Dynamic Analysis Security Testing (DAST)
เป็นการทดสอบ Source code ใน Run-time Environment พร้อมใช้งานโดยอาจจะมีการเตรียม Automate script หรือ Tool ที่ใช้ในการทำ Security Testing ไว้เพื่อการทดสอบซึ่งเราอาจจะทำหลังจาก CI/CD เรียบร้อยแล้ว (เป็นอีก Job นึงใน CI/CD เลยก็ได้) เช่นเดียวกัน พวก Security Scanner ทั้งหลายก็สามารถ Integrated กับ CI/CD ไปด้วยเลย
11.) Perform Penetration Testing
เป็นการทดสอบและวิเคราะห์ความปลอดภัยของ System โดยการ Attack เพื่อหาช่องโหว่หรือจุดอ่อนของ System เราหรือที่เรารู้จักกันดีคือ ทำ Pentest ซึ่งการทำ Pentest ควรจะมีการทำ Internal ด้วย (External ต้องทำอยู่แล้ว) เพราะเราสามารถที่จะตรวจสอบ System ตรวจสอบ Source code ของเราได้ละเอียดกว่า มีความเข้าใจใน Busniess logic และใน Infrastructure มากกว่าส่งผลให้การทดสอบมีประสิทธิผลมากกว่า
12.) Establish a Standard Incident Response Process
และสุดท้ายบนโลกนี้ไม่มีอะไรที่แน่นอน อะไรจะเกิดมันก็ต้องเกิด ไม่มีอะไรที่ป้องกันได้ 100% ต่อให้เราทำทุกอย่างจนสุดแล้วก็มิอาจต่อต้านกระแสของเวลาได้ 😆
แต่สิ่งที่สำคัญที่สุดคือ เมื่อเกิดปัญหาแล้วเราจะรับมือกับมันอย่างไรจึงเป็นที่มาของข้อสุดท้าย การเตรียมแผนรับมือสำหรับ Support Incident ที่เกิดขึ้น ซึ่งในส่วนนี้ก็อาจจะขึ้นอยู่กับ Structure ของแต่ละองค์กรที่ไม่เหมือนกัน Business ของแต่ละองค์กรที่แตกต่างกัน ก็จะมีแผนรับมือที่แตกต่างกันไปตามความเหมาะสม
ในบางครั้งการวางแผนรับมือก็อาจจะไม่ได้ช่วย Solve ปัญหาที่เกิดขึ้นได้ However ครับการยอมรับและเผชิญหน้ารับมือกับปัญหาเกิดขึ้นอย่างมีประสิทธิภาพจะช่วยให้เราและองค์กรได้รับประสบการณ์ที่ดีในการเติบโตไปข้างหน้าพร้อมที่จะฟันฝ่าอุปสรรคได้เช่นกัน 😎
จบไปแล้วกับ 12 Pratices ที่มีความสำคัญต่อการทำ Software Development ให้ Secure สรุปสั้นๆก็คือ นอกจากการ Coding ที่ดีแล้วการมี Process หรือ Pratices ที่ดีก็จะเป็นส่วนช่วยให้ Software หรือ System ของเรานั้นมีความ Secure มากขึ้น และที่สำคัญไม่จำเป็นต้อง Follow ให้ได้ทุกข้อ Weight ให้เหมาะสมกับทีมกับองค์กรของเราก็พอ (บทความหน้าอาจจะมาแชร์ว่าที่ TokenX มี SDLC Process เป็นอย่างไร 😆)
และสุดท้ายครับ… ตอนนี้ TokenX กำลังต้องการคนใหม่ไฟแรงมาร่วมทีมเพิ่มในตำแหน่ง IT Security Manager/Analyst ถ้าใครสนใจงานสาย Financial อันแสนท้าทายที่ขับเคลื่อนด้วย Blockchain Technology พร้อมทั้งสวัสดิการและบรรยากาศที่เรียกได้ว่า แจ่มๆ ทั้งนั้น 😳
หากคุณกำลังมองหาสิ่งเหล่านี้อยู่ละก็ รออะไรละครับ ส่ง CV มาโลด หรือเข้าไปดูรายละเอียดก่อนได้ที่ https://tokenx.finance/career
(มีอีกหลาย Role ที่รับนะครับเชิญดูก่อนได้เลยย Software Engineer ก็รับน้าา)
Content ที่เล่ามาทั้งหมดมาอาจจะช่วยยกระดับ Security ให้กับ Product ไม่มากก็น้อย ถ้าผิดพลาดประการใด ขออภัยไว้ ณ ที่นี้ด้วยครับ หรือ มีข้อคิดเห็นแนะนำ เพิ่มเติมใดก็ Comment ไว้ได้เลยครับ
Reference
https://www.microsoft.com/en-us/securityengineering/sdl/practices#practice8
