Secured Software Development Lifecycle(SSDLC) คืออะไร
SSDLC(Secured Software Development Lifecycle) คือกระบวนการพัฒนา Software ให้มีความปลอดภัย ซึ่งจะมีการกำหนดกิจกรรมต่างๆที่จะช่วยให้ Software ที่เราได้ออกมามีความปลอดภัยมากขึ้น
ซึ่งก่อนจะมี SDLC เราจะต้องมี SDLC(Software Development Life Cycle) ซึ่งจะมีขึ้นตอนหลักๆ ดังนี้
- Planning ขั้นตอนของการวางแผนการทำงาน งานนี้ก็จะมี Project Manager เป็นแกนหลัก
- Define requirements ขั้นตอนนี้จะต้องจัดเก็บ requirements ซึ่งจะมี Business Analyst เป็นคนที่ดูแลในส่วนนี้
- Design ขั้นตอนการออกแบบ ที่จะมี System Analyst เป็นผู้ดูแลในส่วนนี้ ซึ่งสามารถแยกออกเป็น 2 level ดังนี้
- Architectural Design คือการออกแบบระบบแบบกว้างๆ ยังไม่ต้องระบถึงวิธีการ implement บางที่ก็อาจเรียกว่าเป็น High-level design
- Detail Design คือการออกแบบที่ลงรายละเอียด เพื่ีอเป็น guideline ในการพัฒนา บางทีก็จะเรียกว่า Low-Level Design
- Develop ขั้นตอนของการพัฒนา program ซึ่งแน่นอนมี developer หรือ programmer เป็นผู้รับผิดชอบ
- Testing ขั้นตอนการทดสอบซึ่งจะตรวจสอบว่าระบบนั้นใช้งานได้และเป็นไปตาม requirement ที่ระบุไว้หรือไม่
- Deploy ขั้นตอนที่นำเอา software ที่ได้ไปติดตั้งลงบน server เพื่อให้ใช้งานได้จริง
ซึ่งการทำงานในปัจจุบันเราไม่ควรทำงานแบบ Waterfall ที่จะทำให้เสร็จทีละขั้นตอน แต่เราจะทำงานแบบ Agile คือทำทุกๆขั้นตอนให้เสร็จกับ software ชิ้นเล็กๆ
โดยเฉพาะเรื่องของ Security เราไม่สามารถทำงานแบบ Waterfall ได้เพราะมันจะสายเกินไปที่จะแก้ไข
ปัญหาที่ทำให้ Software ไม่มี Security
-
Changing Requirements เรื่องของการเปลี่ยนแปลง requirement อันนี้เป็นปัญหาที่ Common problems อยู่แล้วยังไงเราก็ต้องเจอ การเปลี่ยนแปลง requirement มีปัญหามากๆ ในมุมของ Security มากกว่า functional เพราะ Security ถามใครก็ไม่มีใครรู้ ฟังก์ชันคุณยังเดินไปถาม User เดินไปถาม Business Analyst ก็จะให้คำตอบได้ว่า requirement มีอะไรบ้าง แต่ถ้าเกิดว่ามันเป็น Security เมื่อมีคำถามก็ไม่รู้จะถามใคร แล้วคนที่ให้คำตอบมาก็ไม่รู้ว่าให้คำตอบถูกไหม ดังนั้นปัญหาแรกเลยที่เราจะเจอก็คือเรื่องของ requirements
-
Unproven Technology Project ส่วนใหญ่จะมีเทคโนโลยีที่นำเข้ามาใช้เยอะมากๆโดยเฉพาะยุคในใหม่ๆ เนี่ย มันเป็นยุคของการเปลี่ยนแปลงของเทคโนโลยี ดังนั้นเมื่อมันเป็นการเปลี่ยนแปลงของเทคโนโลยีเราก็หลีกเลี่ยงการเปลี่ยนแปลงไม่ได้ และเมื่อการเปลี่ยนแปลงมันเกิดขึ้นเร็วมาก เทคโนโลยีใหม่ๆ ที่เรานำมาใช้เข้ามา เราไม่ได้เชี่ยวชาญ เราอาจจะไม่ได้รู้ซึ้งกับมันจริง ๆ มันก็เลยอาจจะทำให้เกิดปัญหาตรงนั้นได้ อันนี้ก็เป็นอีกจุดหนึ่ง แต่แน่นอนผมก็ไม่ได้หมายความว่า จะต้องหลีกหนีการเปลี่ยนแปลงนะ เรายังคงจะต้องรับการเปลี่ยนแปลงนั้นอยู่ แต่ว่าก่อนที่จะนำเทคโนโลยีต่างๆมาใช้ ก็อาจจะต้องทำความเข้าใจและวิเคราะห์ถึงจุดแข็งและจุดอ่อนของเทคโนโลยีนั้นๆ
-
Unrealistic expectations ในเรื่อง Security จะปัญหานี้เกิดขึ้นเยอะมาก เพราะว่าความหมายของ Security แต่ละคนไม่เหมือนกัน เราไปถาม User ก็จะอยากได้ Security แบบหนึ่ง ไปถามผู้บริหารอาจจะได้คำตอบอีกแบบนึง ดังนั้นแต่ละคนอาจจะมีความคาดหวังที่แตกต่างกัน และบางคนก็ไม่ได้เข้าใจว่าจริงๆ แล้ว Security มันไม่สามารถ protect ได้ 100% ยังไงก็ตามมันก็ยังคงต้องมีปัญหาอยู่ ดังนั้นบางคนก็อาจจะคาดหวังว่าแบบฉันได้ซอฟต์แวร์ที่ secure นะ จะต้องไม่ถูกแฮกนะ ซึ่งมันเป็นเรื่องที่อาจจะเป็นไปไม่ได้
-
Staff Exprience หรือ ประสบการณ์ของ programmer เนื่องจากเราคุยกันในเรื่อง Security น้อยมาก ตอนที่เราเริ่มต้นเขียนโปรแกรม แทบจะไม่มีใครพูดถึงเรื่องของ Security เลย มีน้อยมาก มีแค่ authentication authorization แค่นี้ แต่ว่าหลังจากนี้ไม่มี ไม่มีใครพูดถึง Security ในมุมมองอื่นๆ ดังนั้นตัวนี้มันก็เลยเป็นปัญหาว่า เราเพิ่งมาใส่ Security เข้ามาให้กับ developer ภายหลัง ซึ่งก็ทำให้ developer แต่ละคนมีประสบการณ์ที่อาจจะยังไม่มากเพียงพอ
และนี่คือปัญหาต่างๆ ที่เกิดขึ้น ซึ่งปัจจับต่างๆเหล่านี้จะทำให้ software ของเราไม่มี Security ที่ดี
Security เป็นหน้าที่ของทุกคน
สิ่งที่ทุกคนจะต้องเข้าใจตรงกันตรงนี้ก็คือ Security เป็นหน้าที่ของทุกๆคน ทุกคนมีหน้าที่ ที่ทำให้เกิด Security เกิดขึ้น ดังนั้นเราต้องทำให้ทุกคนมีความสนใจ รู้ว่าแต่ละคนมีหน้าที่ทำอะไร และทำให้ Security เกิดขึ้นจากบทบาทของทุกคน นี่คือปัจจัยที่สำคัญที่สุด ดังนั้น Culture จะเป็นสิ่งที่สำคัญที่สุด Culture ขององค์กร ทุกอย่างที่เกิดขึ้น จะต้องมี Security อยู่ในนั้น Culture คือสิ่งที่คุณทำวันนี้คุณทำอะไร คุณใส่ Security ลงไปในนั้น มันไม่ใช่การพยายามไปเอา process ของคนอื่นมาใช้ การนำขั้นตอนหรือกระบวนการต่างๆ ของคนอื่นมาใช้ส่วนใหญ่มันจะไม่ work ดังนั้นเราจะทำ Security โดยการใส่ Security เข้าไปในขั้นตอนการทำงานที่ทำอยู่ในปัจจุบัน
และนอกจากนี้ทุกคนในองค์กรต้องรู้ว่าอะไรคือ assets ที่มีความสำคัญ อะไรสำคัญ อะไรไม่สำคัญ ถ้าเรารู้ว่าอันไหนมีค่า อันไหนไม่มีค่า มันจะดูแลรักษาได้ง่าย แต่ถ้าเราไม่รู้เลยว่าของในบ้านแบบไหนมีค่า แบบไหนไม่มีค่า อันนั้นเราก็จะดูแลรักษามันไม่ได้
รับมือกับ Attack Serface
Attack Surface คือ พื้นที่ในการโจมตี ยิ่ง Software นั้นมี Features หรือความซับซ้อนมากเท่าไหร่ ยิ่งทีความเสี่ยงมาก
หรือใช้งาน technical service เช่น มี database, message queue และอื่นๆมากเท่าไหร่ ก็ยิ่งมีความเสี่ยงมากขึ้น
ดังนั้นคุณต้องมีการ Analyze Attack Serface ในขั้นตอนการออกแบบ และ Review Attack Serface ก่อนที่จะทำการ Deploy
Security มันอยู่ทั้ง Lifecycle ตั้งแต่เป็นไอเดียจนไปถึงเป็น product แล้วเลิกใช้งาน ดังนั้นคุณต้องพยายามลด Attack Surface ในทุกๆขั้นตอน
เราจะใส่ Security เข้าไปยังไง?
-
Planning เวลาเริ่มต้นทำ Software เราจะเริ่มจากการวางแผนก่อน ดังนั้นคนที่จะเข้ามาช่วยดูตรงนี้คือ Project manager
Project manager จะต้องทำการวางแผนว่า Software เริ่มต้นเมื่อไหร่ เสร็จเมื่อไหร่ และต้นทุนของ Software อยู่ตรงไหน PM จะมีความสำคัญสูงมาก หลายๆ องค์กรผิดพลาดตรงนี้ ก็คือตอน Planning ไม่ได้ Plan ถึงเรื่อง Security ซึ่ง Security มันไม่ได้ฟรี แต่เรามี Cost ที่จ่ายลงไปตรงนั้น ถึงเวลาทำทำไม่ทัน Security ก็จะหายไป นั่นคือปัญหา -
Define requirements คุณต้องนิยามกันให้ชัด ว่าซอฟต์แวร์ที่ Secure ของคุณหมายความว่าอะไร คุณต้องกำหนดเป็น requirements ขึ้นมา ความต้องการขึ้นมา ว่าจริงๆ แล้วเนี่ยซอฟต์แวร์ของคุณต้องการ Security แบบไหน ซึ่งมันขึ้นอยู่กับความเสี่ยง แต่ละ project ไม่เหมือนกัน แต่ละซอฟต์แวร์แต่ละประเภทไม่เหมือนกัน ดังนั้นคุณต้องมีการนิยามให้ชัด ว่า requirement ที่คุณต้องการในแต่ละ project นั้นคืออะไร
-
Design ในการออกแบบ คุณจะต้องนำ security requirements ต่างๆ มาทำการออกแบบ มาทำการ design ระบบ ซึ่งก็ต้องทำการดีไซน์ระบบให้มีความปลอดภัย ออกแบบระบบเริ่มต้นให้มันง่าย และ complexity ก็เป็นสิ่งที่ทำให้ Security ลดลง การออกแบบเลยต้องทำให้มันง่ายที่สุดเท่าที่เป็นไปได้ หลีกเลี่ยงความซับซ้อนให้มากที่สุดเท่าที่เป็นไปได้
-
Develop ตอน build ต้องมี practice หรือ guideline ที่บอกได้ว่า developer ต้องเขียน code ยังไง ต้องให้ developer ทุกคนมานั่งคุยกันว่า แล้วซอฟต์แวร์แบบไหนที่เขียนแล้วมันจะมีความปลอดภัย เขียนแบบนี้ดี เขียนแบบนี้ไม่ดี ต้องมี Coding standard ต้องมี Coding guideline
-
Testing หลังจากเราเขียนเสร็จแล้วก็จะทำการทดสอบ ซึ่ง Security Testing จะแบ่งออกเป็นหลายประเภท ดังนี้
- Static Application Security Testing(SAST) การตรวจสอบคุณภาพของ code ที่เขียน เป็นการตรวจสอบวิธีการเขียนโดยที่ไม่ต้อง run service นั้นขึ้นมา
- Dynamic Application SEcurity Testing(DAST) การค้นหาช่องโหว่(Vulnerability) โดยที่เราต้อง run application นั้นขึ้นมาก่อน
- Interactive Application Security Testing(IAST) เป็นการค้นหาช่องโหว่เหมือนกับ DAST แต่ IAST นั้นจะ run เป็น background service ตลอดเวลาที่ใช้งาน เหมือนเป็น DAST ที่ run ตลอดเวลาที่มีการใช้งาน
ซึ่งในการทำงานในปัจจุบันเราจะเน้นที่การทำ Automated Test และใส่เข้าไปใน CI/CD Pipeline มากกว่าการทดสอบแบบ Manual Test ที่ต้องทำด้วยคน
-
Deploy เมื่อเข้าสู่กระบวนการ deployment ทำการ deploy ก็ต้องทำการ deploy ลงบน infrastructure ที่มีความปลอดภัย ต้องมีการ Hardening Network, Hardening Operating System, Hardening container และอื่นๆ ต้องความปลอดภัยในทุกๆอย่างที่นำมาประกอบกันเป็น environment
5 Secured SDLC Best Practices
ในบทความของ Snyk ตาม Link ด้านล่างได้ให้ best practices มา 5 ข้อสำหรับการทำให้ Software ที่เราได้มีความปลอดภัยมากขึ้น
- Educate Your Developers
- Have Clear Requirements
- Maintain a Growth Mindset
- Tie Implementation to Other Initiatives
- Tackle the Big Problems First
SSDLC และ DevSecOps
ในปัจจุบันเราพูดถึงคำว่า DevSecOps หรือ Security in DevOps กันมากขึ้น ซึ่งบางคนคิดว่าคำว่า DevSecOps นั้นมาแทนที่ SSDLC แต่จริงๆแล้วทั้ง 2 คำนี้จะแตกต่างกัน โดยที่ SSDLC จะสนใจที่กระบวนการหรือ process ที่จะได้มาซึ่ง software ที่มีความปลอดภัย ในขณะที่ DevSecOps นั้นจะเน้นตั้งแต่วิธีคิด วิธีการทำงาน รวมทั้งการทำ Automation ซึ่งจะเป็นแกนหลักของการทำ DevSecOps Developer ดังนั้นทั้ง SSDLC และ DevSecOps นั้นต่างก็มีส่วนร่วมในการปรับปรุงกระบวนการของเรา ช่วยให้เราพัฒนา software ที่มีความปลอดภัยออกมาด้วยเวลาที่รวดเร็ว