22
INFORMATION SECURITY IS EVERYONE'S JOB EVERY DAY (ความปลอดภัยของข้อมูลคืองานของทุกคน ทุกวัน)
ห นึ่งในข้อโต้แย้งที่สำคัญที่สุดในการนำหลักการและแนวทางของ DevOps ไปปฏิบัติก็คือ "ฝ่าย Information Security และ Compliance ไม่อนุญาตให้เราทำ" แต่ทว่า DevOps อาจเป็นหนึ่งในวิธีที่ดีที่สุดในการบูรณาการความปลอดภัยของข้อมูลเข้าไปในงานประจำวัน ของทุกคนใน value stream ด้านเทคโนโลยี
เมื่อ Infosec ถูกจัดเป็นแผนกที่แยกตัวออกจาก Development และ Operations ก็เกิดปัญหามากมาย James Wicket หนึ่งใน ผู้สร้างเครื่องมือรักษาความปลอดภัย Gauntlt และผู้จัดงาน DevOpsDays Austin และ Lonestar Application Security Conference ได้กล่าวไว้ว่า:
หนึ่งในมุมมองเกี่ยวกับ DevOps คือว่ามันเกิดจากความจำเป็นในการเพิ่ม productivity ของนักพัฒนา เพราะเมื่อจำนวนนักพัฒนา เพิ่มมากขึ้น ก็ไม่มีฝ่าย Ops ที่มากพอจะจัดการกับงาน deployment ที่เกิดขึ้น อัตราการขาดแคลนนี้ยิ่งแย่ลงไปอีกในสายงาน Infosec — โดยทั่วไปอัตราส่วนของวิศวกรใน Development, Operations และ Infosec ในองค์กรเทคโนโลยีทั่วไปอยู่ที่ 100:10:1 เมื่อ Infosec มีจำนวนน้อยกว่ามากขนาดนั้น หากไม่มี automation และการบูรณาการความปลอดภัยของข้อมูลเข้าไปในงานประจำวัน ของ Dev และ Ops แล้ว Infosec ก็ทำได้แค่การตรวจสอบ compliance ซึ่งตรงกันข้ามกับการเป็นวิศวกรรมความปลอดภัย— และที่แย่กว่านั้น มันยังทำให้ทุกคนเกลียดเราด้วย 1
James Wickett และ Josh Corman อดีต CTO ของ Sonatype และนักวิจัยด้านความปลอดภัยที่ได้รับการยอมรับ ได้เขียนเกี่ยวกับ การนำวัตถุประสงค์ด้านความปลอดภัยของข้อมูลมาผสานเข้ากับ DevOps ซึ่งเป็นชุดของแนวปฏิบัติและหลักการที่เรียกว่า Rugged DevOps . 2 *
ตลอดทั้งเล่มของ The DevOps Handbook เราได้สำรวจวิธีการบูรณาการวัตถุประสงค์ของ QA และ Operations เข้ากับ value stream ด้านเทคโนโลยีทั้งหมดของเรา ในบทนี้ เราจะอธิบายวิธีการบูรณาการวัตถุประสงค์ของ Infosec เข้าไปในงานประจำวันของเราในลักษณะเดียวกัน ซึ่งจะช่วยเพิ่ม ความปลอดภัยในขณะที่ยังคงรักษา productivity ของนักพัฒนาและฝ่ายปฏิบัติการไว้ได้
Integrate Security into Development Iteration Demonstrations (ผสานความปลอดภัยเข้าสู่การสาธิตในแต่ละ Iteration ของการพัฒนา)
เป้าหมายหนึ่งของเราคือการให้ทีม feature ได้มีส่วนร่วมกับ Infosec ตั้งแต่ช่วงแรกที่สุด แทนที่จะเข้ามามีส่วนร่วม หลักๆ เฉพาะช่วงท้ายของโปรเจกต์ วิธีหนึ่งที่ทำได้คือการเชิญ Infosec เข้าร่วมการสาธิตผลิตภัณฑ์เมื่อสิ้นสุด development interval แต่ละครั้ง เพื่อให้พวกเขาเข้าใจเป้าหมายของทีมในบริบทของเป้าหมายขององค์กรได้ดีขึ้น สังเกตการ Implementations ที่กำลังถูกสร้างขึ้น และให้คำแนะนำและ feedback ตั้งแต่ช่วงแรกที่สุดของ โปรเจกต์ ซึ่งเป็นช่วงที่มีเวลาและอิสระมากที่สุดในการแก้ไข
Justin Arbuckle อดีต Chief Architect ที่ GE Capital กล่าวไว้ว่า
เมื่อพูดถึงความปลอดภัยของข้อมูลและ compliance เราพบว่าการติดขัดช่วงท้ายของโปรเจกต์มีต้นทุนแพงกว่าช่วงเริ่มต้นมาก— และการติดขัดจาก Infosec ก็เป็นหนึ่งในปัญหาที่ร้ายแรงที่สุด 'Compliance by demonstration' กลายเป็นหนึ่งในพิธีกรรม ที่เราใช้เพื่อย้ายความซับซ้อนทั้งหมดนี้ไปไว้ในช่วงต้นของกระบวนการ . . . 4
โดยการให้ Infosec มีส่วนร่วมตลอดกระบวนการสร้างความสามารถใหม่ๆ เราสามารถลดการใช้ checklists แบบตายตัวลงได้อย่างมาก และพึ่งพาความเชี่ยวชาญของพวกเขามากขึ้นตลอดกระบวนการพัฒนาซอฟต์แวร์ทั้งหมด 5
สิ่งนี้ช่วยให้องค์กรบรรลุเป้าหมาย Snehal Antani อดีต CIO ของ Enterprise Architecture ที่ GE Capital Americas ได้อธิบายตัวชี้วัดทางธุรกิจที่สำคัญสามอันดับแรกของพวกเขาว่า "ความเร็วในการพัฒนา (development velocity) (เช่น ความเร็วในการส่งมอบฟีเจอร์สู่ตลาด), ความล้มเหลวในการโต้ตอบกับลูกค้า (failed customer interactions) (เช่น การหยุดทำงาน, ข้อผิดพลาด), และระยะเวลาในการตอบสนองต่อ compliance (compliance response time) (เช่น lead time ตั้งแต่คำขอ audit ไปจนถึงการส่งมอบข้อมูลเชิงปริมาณและคุณภาพทั้งหมดที่จำเป็นในการดำเนินการตามคำขอ)" 6
เมื่อ Infosec เป็นส่วนหนึ่งของทีมที่ได้รับมอบหมาย แม้ว่าพวกเขาจะเพียงแค่รับทราบข้อมูลและสังเกตการณ์กระบวนการ พวกเขาก็จะได้รับบริบททางธุรกิจที่จำเป็นในการตัดสินใจโดยใช้ความเสี่ยงเป็นฐานได้ดีขึ้น ยิ่งไปกว่านั้น Infosec ยังสามารถ ช่วยให้ทีม feature เรียนรู้สิ่งที่ต้องทำเพื่อให้บรรลุวัตถุประสงค์ด้านความปลอดภัยและ compliance
Integrate Security into Defect Tracking and Post-Mortems (ผสานความปลอดภัยเข้ากับการติดตามข้อบกพร่องและการตรวจสอบหลังเหตุการณ์)
เมื่อเป็นไปได้ เราต้องการติดตามปัญหาด้านความปลอดภัยที่ยังเปิดอยู่ทั้งหมดในระบบติดตามงานเดียวกับที่ Development และ Operations ใช้อยู่ เพื่อให้แน่ใจว่างานนั้นมองเห็นได้และสามารถจัดลำดับความสำคัญเทียบกับงานอื่นๆ ได้ ซึ่งแตกต่างอย่างมากจากวิธีการทำงานดั้งเดิมของ Infosec ที่ช่องโหว่ด้านความปลอดภัยทั้งหมดถูกเก็บไว้ในเครื่องมือ GRC (governance, risk, and compliance) ที่มีเฉพาะ Infosec เท่านั้นที่เข้าถึงได้ แต่เราจะนำงานที่ต้องทำทั้งหมดไปไว้ในระบบ ที่ Dev และ Ops ใช้แทน
ในการนำเสนอที่งาน Austin DevOpsDays 2012 Nick Galbreath ซึ่งดูแลฝ่าย Information Security ที่ Etsy มาหลายปี ได้อธิบายว่าทีมของเขาจัดการกับปัญหาด้านความปลอดภัยอย่างไร: "เราใส่ปัญหาด้านความปลอดภัยทั้งหมดลงใน JIRA ซึ่งวิศวกรทุกคนใช้ ในงานประจำวันของพวกเขา และปัญหาทั้งหมดจะเป็น 'P1' หรือ 'P2' หมายความว่าต้องแก้ไขทันทีหรือภายในสิ้นสัปดาห์ แม้ว่าปัญหาจะเป็นแค่แอปพลิเคชันที่ใช้ภายในก็ตาม" 7
ยิ่งไปกว่านั้น เขากล่าวว่า "ทุกครั้งที่มีปัญหาด้านความปลอดภัย เราจะทำ post-mortem เพราะมันช่วยให้วิศวกรของเรา ได้เรียนรู้วิธีป้องกันไม่ให้เกิดปัญหาซ้ำในอนาคต และยังเป็นกลไกที่ยอดเยี่ยมในการถ่ายทอดความรู้ด้านความปลอดภัย ให้กับทีมวิศวกรของเรา" 8
Integrate Preventive Security Controls into Shared Source Code Repositories and Shared Services (ผสานการควบคุมความปลอดภัยเชิงป้องกันเข้าไปใน Shared Source Code Repositories และ Shared Services)
ใน Chapter 20 เราได้สร้าง shared source code repository ที่ทำให้ทุกคนสามารถค้นหาและใช้ความรู้รวมขององค์กรได้ง่าย ไม่เพียงแค่โค้ดของเรา แต่รวมถึง toolchains, deployment pipeline, มาตรฐานต่างๆ และอื่นๆ การทำเช่นนี้ทำให้ทุกคนได้รับประโยชน์จากประสบการณ์สะสมของทุกคนในองค์กร
ตอนนี้เราจะเพิ่มกลไกหรือเครื่องมือที่ช่วยให้เรามั่นใจได้ว่าแอปพลิเคชันและสภาพแวดล้อมของเราปลอดภัย ลงใน shared source code repository ของเรา เราจะเพิ่ม libraries ที่ผ่านการรับรองจากฝ่ายความปลอดภัย เพื่อตอบสนองวัตถุประสงค์ของ Infosec เฉพาะด้าน เช่น libraries และ services สำหรับการ authentication และ encryption
เพราะทุกคนใน DevOps value stream ใช้ version control สำหรับทุกสิ่งที่พวกเขาสร้างหรือดูแล การใส่ toolchain ด้านความปลอดภัยของข้อมูลและ libraries ที่ได้รับอนุมัติลงไปจึงทำให้มีอิทธิพลต่องานประจำวันของ Dev และ Ops ได้ง่ายขึ้น เพราะทุกสิ่งที่เราสร้างสามารถเข้าถึงได้ ค้นหาได้ และนำกลับมาใช้ใหม่ได้ Version control ยังทำหน้าที่เป็นกลไกการสื่อสารแบบรอบทิศทางเพื่อให้ทุกฝ่ายทราบถึงการเปลี่ยนแปลงที่เกิดขึ้น
ถ้าเรามีองค์กร shared services แบบรวมศูนย์ เราอาจร่วมมือกับพวกเขาเพื่อสร้างและดำเนินการแพลตฟอร์มที่เกี่ยวข้องกับ ความปลอดภัย เช่น authentication, authorization, logging และ services ด้านความปลอดภัยและการตรวจสอบอื่นๆ ที่ Dev และ Ops ต้องการ เมื่อวิศวกรใช้ libraries หรือ services ที่กำหนดไว้ล่วงหน้าเหล่านี้ พวกเขาจะไม่ต้องจัดตารางการตรวจสอบการออกแบบด้านความปลอดภัยแยกต่างหากสำหรับโมดูลนั้น พวกเขาจะใช้แนวทางที่เราสร้างไว้เกี่ยวกับการปรับแต่งการตั้งค่า (configuration hardening), การตั้งค่าความปลอดภัยของฐานข้อมูล (database security settings), ความยาวของคีย์ (key lengths) และอื่นๆ
เพื่อเพิ่มโอกาสที่ services และ libraries ที่เราจัดหาจะถูกใช้อย่างถูกต้อง เราสามารถจัดการฝึกอบรม ด้านความปลอดภัยให้กับ Dev และ Ops รวมถึงตรวจสอบสิ่งที่พวกเขาสร้างขึ้นเพื่อช่วยให้แน่ใจว่าวัตถุประสงค์ ด้านความปลอดภัยถูกนำไปปฏิบัติอย่างถูกต้อง โดยเฉพาะสำหรับทีมที่ใช้เครื่องมือเหล่านี้เป็นครั้งแรก
ท้ายที่สุดแล้ว เป้าหมายของเราคือการจัดหา security libraries หรือ services ที่แอปพลิเคชันหรือสภาพแวดล้อมสมัยใหม่ทุกแห่ง ต้องการ เช่น การเปิดใช้งาน user authentication, authorization, password management, data encryption และอื่นๆ นอกจากนี้ เรายังสามารถจัดเตรียมการตั้งค่า configuration ที่เฉพาะเจาะจงด้านความปลอดภัยที่มีประสิทธิภาพ ให้กับ Dev และ Ops สำหรับคอมโพเนนต์ที่พวกเขาใช้ใน application stacks เช่น logging, authentication และ encryption ซึ่งอาจรวมถึง:
• code libraries และการตั้งค่าที่แนะนำ (เช่น 2FA [two-factor authentication library], bcrypt password hashing, logging)
• การจัดการ secret (secret management) (เช่น connection settings, encryption keys) โดยใช้เครื่องมือเช่น Vault, sneaker, Keywhiz, credstash, Trousseau, Red October ฯลฯ †
• OS packages และ builds (เช่น NTP สำหรับการ sync เวลา, OpenSSL เวอร์ชันที่ปลอดภัยพร้อมการตั้งค่าที่ถูกต้อง, OSSEC หรือ Tripwire สำหรับการตรวจสอบความสมบูรณ์ของไฟล์, การตั้งค่า syslog เพื่อบันทึกข้อมูลความปลอดภัยที่สำคัญ ไปยัง centralized ELK stack ของเรา)
โดยการใส่ทั้งหมดนี้ลงใน shared source code repository ของเรา ทำให้วิศวกรทุกคนสามารถสร้างและใช้มาตรฐาน การบันทึก log และการเข้ารหัสในแอปพลิเคชันและสภาพแวดล้อมของตนได้อย่างถูกต้อง โดยไม่ต้องให้เราทำงานเพิ่มเติม
เราควรทำงานร่วมกับทีม Ops เพื่อสร้าง base cookbook หรือ base image ของ OS, ฐานข้อมูล และโครงสร้างพื้นฐานอื่นๆ (เช่น NGINX, Apache, Tomcat) เพื่อแสดงว่าอยู่ในสถานะที่ปลอดภัยและลดความเสี่ยง repository ที่ใช้ร่วมกันของเรา ไม่เพียงแต่เป็นที่ที่เราสามารถรับเวอร์ชันล่าสุดได้เท่านั้น แต่ยังเป็นที่ที่เราสามารถทำงานร่วมกับวิศวกรคนอื่นๆ และตรวจสอบและแจ้งเตือนเกี่ยวกับการเปลี่ยนแปลงที่เกิดขึ้นกับโมดูลที่ละเอียดอ่อนด้านความปลอดภัย
ปัจจุบันที่ระบบที่ใช้ Docker แพร่หลาย องค์กรควรใช้ container registry เพื่อเก็บ base images ทั้งหมด เพื่อรักษาความปลอดภัยของซอฟต์แวร์ supply chain source versions เหล่านี้ควรถูกเก็บไว้พร้อมกับ secure hash ของ image ที่สร้างขึ้น hash นี้จะต้องถูกตรวจสอบทุกครั้งที่มีการใช้หรือ deploy image
Integrate Security into Our Deployment Pipeline (ผสานความปลอดภัยเข้าไปใน Deployment Pipeline ของเรา)
ในยุคก่อน การจะทำให้แอปพลิเคชันของเราแข็งแกร่งและปลอดภัย เราจะเริ่มการตรวจสอบความปลอดภัยหลังจากที่การพัฒนาเสร็จสิ้น ซึ่งผลลัพธ์ของการตรวจสอบนี้มักจะเป็นรายงาน PDF หลายร้อยหน้าที่เต็มไปด้วยช่องโหว่ ซึ่งเราจะส่งให้ Development และ Operations และมักจะไม่ได้รับการแก้ไขเลยเพราะแรงกดดันจากกำหนดส่งหรือเพราะปัญหาถูกพบช้าเกินไป ในวงจรชีวิตของซอฟต์แวร์จนแก้ไขได้ยาก
ในขั้นตอนนี้ เราจะ automate การทดสอบความปลอดภัยของข้อมูลให้มากที่สุดเท่าที่จะทำได้ เพื่อให้มันทำงานควบคู่ไปกับการทดสอบอัตโนมัติอื่นๆ ทั้งหมดใน deployment pipeline ของเรา โดยดำเนินการ (ในอุดมคติแล้ว) ทุกครั้งที่มีการ commit โค้ดโดย Dev หรือ Ops และแม้แต่ในช่วงแรกที่สุดของโปรเจกต์ซอฟต์แวร์
เป้าหมายของเราคือการให้ feedback ที่รวดเร็วแก่ทั้ง Dev และ Ops เกี่ยวกับงานของพวกเขา เพื่อให้พวกเขาได้รับการแจ้งเตือนทุกครั้งที่ commit การเปลี่ยนแปลงที่อาจไม่ปลอดภัย การทำเช่นนี้ทำให้พวกเขาสามารถตรวจจับและแก้ไขปัญหาด้านความปลอดภัยได้อย่างรวดเร็ว ซึ่งเป็นส่วนหนึ่งของงานประจำวัน ช่วยให้เกิดการเรียนรู้และป้องกันข้อผิดพลาดในอนาคต
ในอุดมคติแล้ว การทดสอบความปลอดภัยอัตโนมัติเหล่านี้จะถูกเรียกใช้ใน deployment pipeline ของเรา ควบคู่ไปกับเครื่องมือ static code analysis อื่นๆ
เครื่องมือเช่น Gauntlt ถูกออกแบบมาให้ผสานเข้ากับ deployment pipelines ซึ่งจะรันการทดสอบความปลอดภัย อัตโนมัติบนแอปพลิเคชันของเรา, dependencies ของแอปพลิเคชัน, สภาพแวดล้อมของเรา ฯลฯ ที่น่าสนใจคือ Gauntlt ยังเขียนการทดสอบความปลอดภัยทั้งหมดในรูปแบบ Gherkin syntax test scripts ซึ่งนักพัฒนาใช้กันอย่างแพร่หลายสำหรับ unit และ functional testing การทำเช่นนี้ทำให้การทดสอบความปลอดภัยอยู่ใน framework ที่พวกเขาอาจคุ้นเคยอยู่แล้ว อีกทั้งยังช่วยให้การทดสอบความปลอดภัยสามารถทำงานได้ง่ายใน deployment pipeline ทุกครั้งที่มีการเปลี่ยนแปลง เช่น static code analysis, การตรวจสอบ dependencies ที่มีช่องโหว่, หรือ dynamic testing
ด้วยวิธีนี้ เรามอบ feedback ที่เร็วที่สุดเท่าที่เป็นไปได้เกี่ยวกับความปลอดภัยของสิ่งที่พวกเขากำลังสร้าง ให้กับทุกคนใน value stream ซึ่งช่วยให้วิศวกร Dev และ Ops สามารถค้นหาและแก้ไขปัญหาได้อย่างรวดเร็ว
Figure 22.1: Jenkins Running Automated Security Testing (Jenkins รันการทดสอบความปลอดภัยอัตโนมัติ)
ที่มา: James Wicket และ Gareth Rushgrove, "Battle-tested code without the battle," การนำเสนอในงานประชุม Velocity 2014, โพสต์บน Speakerdeck.com , 24 มิถุนายน 2014, https://speakerdeck.com/garethr/battle-tested-code-without-the-battle .
Ensure Security of the Application (มั่นใจในความปลอดภัยของแอปพลิเคชัน)
โดยทั่วไปแล้ว การทดสอบของ Development จะมุ่งเน้นที่ความถูกต้องของฟังก์ชันการทำงาน โดยดูที่ positive logic flows การทดสอบประเภทนี้มักเรียกว่า happy path ซึ่งตรวจสอบการเดินทางของผู้ใช้ (และบางครั้งก็ตรวจสอบเส้นทางอื่น) ที่ทุกอย่างเป็นไปตามที่คาดหวัง โดยไม่มีข้อยกเว้นหรือเงื่อนไขข้อผิดพลาด
ในทางกลับกัน ผู้ปฏิบัติงานด้าน QA, Infosec และ fraud ที่มีประสิทธิภาพมักจะมุ่งเน้นที่ sad paths ซึ่งเกิดขึ้นเมื่อสิ่งต่างๆ ผิดพลาด โดยเฉพาะอย่างยิ่งในเงื่อนไขข้อผิดพลาดที่เกี่ยวข้องกับความปลอดภัย (เงื่อนไขเฉพาะด้านความปลอดภัยเหล่านี้มักถูกเรียกติดตลกว่า bad paths )
ตัวอย่างเช่น สมมติว่าเรามีเว็บไซต์ e-commerce ที่มีแบบฟอร์มรับข้อมูลจากลูกค้าที่รับหมายเลขบัตรเครดิต เพื่อสร้างคำสั่งซื้อ เราต้องการกำหนด sad paths และ bad paths ทั้งหมดที่จำเป็นเพื่อให้แน่ใจว่า บัตรเครดิตที่ไม่ถูกต้องถูกปฏิเสธอย่างเหมาะสม เพื่อป้องกัน fraud และ security exploits เช่น SQL injections, buffer overruns และผลลัพธ์ที่ไม่พึงประสงค์อื่นๆ
แทนที่จะทำการทดสอบเหล่านี้ด้วยตนเอง เราควรสร้างมันเป็นส่วนหนึ่งของ unit tests หรือ functional tests อัตโนมัติของเรา เพื่อให้สามารถรันได้อย่างต่อเนื่องใน deployment pipeline ของเรา
ในการทดสอบของเรา เราจะต้องการรวมสิ่งต่อไปนี้:
Static analysis: คือการทดสอบที่เราทำในสภาพแวดล้อมที่ไม่ใช่ runtime (ในอุดมคติคือใน deployment pipeline) โดยทั่วไปแล้ว เครื่องมือ static analysis จะตรวจสอบโค้ดโปรแกรมสำหรับพฤติกรรมที่เป็นไปได้ทั้งหมดใน runtime และค้นหาจุดบกพร่องของโค้ด, back doors และโค้ดที่อาจเป็นอันตราย (บางครั้งเรียกว่า "การทดสอบจากภายในสู่ภายนอก") ตัวอย่างของเครื่องมือ ได้แก่ Brakeman, Code Climate และการค้นหาฟังก์ชันโค้ดที่ถูกแบน (เช่น "exec()")
Dynamic analysis: ตรงกันข้ามกับการทดสอบแบบ static การวิเคราะห์แบบ dynamic ประกอบด้วยการทดสอบที่ดำเนินการในขณะที่โปรแกรมกำลังทำงาน การทดสอบแบบ dynamic จะตรวจสอบสิ่งต่างๆ เช่น หน่วยความจำของระบบ, พฤติกรรมเชิงฟังก์ชัน, เวลาตอบสนอง และประสิทธิภาพโดยรวมของระบบ วิธีนี้ (บางครั้งเรียกว่า "การทดสอบจากภายนอกสู่ภายใน") คล้ายกับวิธีที่บุคคลที่สามที่เป็นอันตรายอาจโต้ตอบกับแอปพลิเคชัน ตัวอย่างได้แก่ Arachni และ OWASP ZAP (Zed Attack Proxy) ‡ การทดสอบ penetration บางประเภทก็สามารถดำเนินการในรูปแบบอัตโนมัติได้และควรรวมเป็นส่วนหนึ่งของ dynamic analysis โดยใช้เครื่องมือเช่น Nmap และ Metasploit ในอุดมคติแล้ว เราควรทำการทดสอบแบบ dynamic อัตโนมัติในช่วงของการทดสอบ functional testing ใน deployment pipeline ของเรา หรือแม้แต่กับ services ของเรา ขณะที่อยู่ใน production เพื่อให้แน่ใจว่ามีการจัดการความปลอดภัยที่ถูกต้อง เครื่องมืออย่าง OWASP ZAP สามารถกำหนดค่าให้โจมตี services ของเราผ่าน web browser proxy และตรวจสอบ traffic ในเครือข่าย ภายใน test harness ของเรา
Dependency scanning: การทดสอบแบบ static อีกประเภทหนึ่งที่เรามักจะทำในระหว่าง build time ภายใน deployment pipeline คือการสำรวจ dependencies ทั้งหมดของเราสำหรับ binaries และ executables และทำให้แน่ใจว่า dependencies เหล่านี้ซึ่งเรามักไม่สามารถควบคุมได้ ปราศจากช่องโหว่หรือ binaries ที่เป็นอันตราย ตัวอย่างได้แก่ Gemnasium และ bundler audit สำหรับ Ruby, Maven สำหรับ Java และ OWASP Dependency-Check
Source code integrity and code signing: นักพัฒนาทุกคนควรมี PGP key ของตัวเอง ซึ่งอาจสร้างและจัดการในระบบเช่น keybase.io commits ทั้งหมดไปยัง version control ควรได้รับการเซ็นต์ — ซึ่งสามารถกำหนดค่าได้ง่ายโดยใช้เครื่องมือ open-source อย่าง gpg และ git นอกจากนี้ packages ทั้งหมดที่สร้างโดย CI process ควรได้รับการเซ็นต์ และ hash ของพวกเขาควรถูกบันทึกใน centralized logging service เพื่อการตรวจสอบ
ยิ่งไปกว่านั้น เราควรกำหนด design patterns เพื่อช่วยให้นักพัฒนาเขียนโค้ดเพื่อป้องกันการใช้งานในทางที่ผิด เช่น การกำหนด rate limits สำหรับ services ของเรา และการทำให้ปุ่ม submit เป็นสีเทาหลังจากถูกกด
OWASP เผยแพร่คำแนะนำที่มีประโยชน์มากมาย เช่น ชุด Cheat Sheet ซึ่งรวมถึง: 9
• วิธีจัดเก็บรหัสผ่าน
• วิธีจัดการกับรหัสผ่านที่ถูกลืม
• วิธีจัดการ logging
• วิธีป้องกันช่องโหว่ cross-site scripting (XSS)
CASE STUDY (กรณีศึกษา)
Static Security Testing at Twitter (2009) (การทดสอบความปลอดภัยแบบ Static ที่ Twitter ปี 2009)
การนำเสนอ "10 Deploys per Day: Dev and Ops Cooperation at Flickr" โดย John Allspaw และ Paul Hammond มีชื่อเสียงในการกระตุ้นชุมชน Dev และ Ops ในปี 2009 สิ่งที่เทียบเท่าได้กับชุมชนความปลอดภัยของข้อมูลน่าจะเป็น การนำเสนอที่ Justin Collins, Alex Smolen และ Neil Matatall ให้ไว้เกี่ยวกับงานเปลี่ยนแปลงด้านความปลอดภัย ของข้อมูลที่ Twitter ในงานประชุม AppSecUSA ปี 2012
Twitter เผชิญกับความท้าทายมากมายเนื่องจากการเติบโตแบบก้าวกระโดด เป็นเวลาหลายปีที่หน้า Fail Whale ข้อผิดพลาดอันโด่งดังจะปรากฏขึ้นเมื่อ Twitter ไม่มีขีดความสามารถเพียงพอที่จะรองรับความต้องการของผู้ใช้ โดยแสดงภาพวาฬถูกยกขึ้นโดยนกแปดตัว ขนาดของการเติบโตของผู้ใช้นั้นน่าทึ่ง— ระหว่างเดือนมกราคมถึงมีนาคม 2009 จำนวนผู้ใช้ Twitter ที่ใช้งานอยู่เพิ่มขึ้นจาก 2.5 ล้านเป็น 10 ล้านคน 10
Twitter ยังมีปัญหาด้านความปลอดภัยในช่วงเวลานี้ ในช่วงต้นปี 2009 เกิดการละเมิดความปลอดภัยร้ายแรงสองครั้ง ครั้งแรก ในเดือนมกราคม บัญชี Twitter ของ @BarackObama ถูกแฮ็ก จากนั้นในเดือนเมษายน บัญชีผู้ดูแลระบบของ Twitter ถูกบุกรุกผ่านการโจมตีแบบ brute-force dictionary attack เหตุการณ์เหล่านี้ทำให้ Federal Trade Commission ตัดสินว่า Twitter ทำให้ผู้ใช้เข้าใจผิด ว่าบัญชีของพวกเขาปลอดภัย และออกคำสั่งยินยอมของ FTC (FTC consent order) 11
คำสั่งยินยอมกำหนดให้ Twitter ปฏิบัติตามภายในหกสิบวันโดยการกำหนดชุดกระบวนการที่จะต้อง บังคับใช้ต่อไปอีกยี่สิบปีข้างหน้า และจะต้องดำเนินการดังต่อไปนี้: 12
• กำหนดพนักงานหนึ่งคนหรือมากกว่าให้รับผิดชอบแผนความปลอดภัยของข้อมูลของ Twitter
• ระบุความเสี่ยงที่คาดการณ์ได้อย่างสมเหตุสมผล ทั้งภายในและภายนอก ที่อาจนำไปสู่เหตุการณ์การบุกรุก และสร้างและดำเนินการตามแผนเพื่อจัดการกับความเสี่ยงเหล่านี้ §
• รักษาความเป็นส่วนตัวของข้อมูลผู้ใช้ ไม่เพียงแต่จากแหล่งภายนอกแต่ยังรวมถึงภายในด้วย พร้อมโครงร่างของแหล่งที่มาที่เป็นไปได้สำหรับการตรวจสอบและทดสอบความปลอดภัยและความถูกต้อง ของการ Implementations เหล่านี้
กลุ่มวิศวกรที่ได้รับมอบหมายให้แก้ไขปัญหานี้ต้องบูรณาการความปลอดภัยเข้ากับงานประจำวันของ Dev และ Ops และปิดช่องโหว่ด้านความปลอดภัยที่ทำให้เกิดการละเมิดตั้งแต่แรก
ในการนำเสนอที่กล่าวถึงก่อนหน้านี้ Collins, Smolen และ Matatall ระบุปัญหาหลายประการที่ต้องจัดการ: 13
• ป้องกันไม่ให้เกิดข้อผิดพลาดด้านความปลอดภัยซ้ำ: พวกเขาพบว่ากำลังแก้ไขข้อบกพร่องและช่องโหว่เดียวกันซ้ำแล้วซ้ำเล่า พวกเขาจำเป็นต้องปรับเปลี่ยนระบบการทำงานและเครื่องมือ automation เพื่อป้องกันไม่ให้ปัญหาเกิดขึ้นอีก
• บูรณาการวัตถุประสงค์ด้านความปลอดภัยเข้ากับเครื่องมือที่มีอยู่ของนักพัฒนา: พวกเขาตระหนักตั้งแต่เนิ่นๆ ว่าแหล่งที่มาหลักของช่องโหว่คือปัญหาในโค้ด พวกเขาไม่สามารถรันเครื่องมือที่สร้างรายงาน PDF ขนาดใหญ่แล้วส่งอีเมลให้ใครสักคนใน Development หรือ Operations แต่พวกเขาจำเป็นต้องให้ข้อมูลที่แน่นอนแก่นักพัฒนาที่สร้างช่องโหว่เพื่อใช้ในการแก้ไข
• รักษาความไว้วางใจของ Development: พวกเขาจำเป็นต้องได้รับและรักษาความไว้วางใจของ Development นั่นหมายความว่าพวกเขาต้องรู้ว่าเมื่อใดที่ส่ง false positives ไปให้ Development เพื่อจะได้แก้ไขข้อผิดพลาดที่ทำให้เกิด false positive และไม่เสียเวลาของ Development
• รักษาการไหลที่รวดเร็วผ่าน Infosec ด้วย automation: แม้ว่าการสแกนช่องโหว่ของโค้ดจะเป็นอัตโนมัติแล้ว Infosec ก็ยังต้องทำงานด้วยมือและรอคอยเป็นจำนวนมาก พวกเขาต้องรอให้การสแกนเสร็จ รับรายงานกองโต ตีความรายงาน แล้วค้นหาผู้รับผิดชอบในการแก้ไข และเมื่อโค้ดเปลี่ยนแปลง ก็ต้องทำทุกอย่างใหม่ทั้งหมด การ automate งานที่ทำด้วยมือช่วยลดงาน "การกดปุ่ม" ประหยัดเวลา และช่วยให้พวกเขาใช้ความคิดสร้างสรรค์และการตัดสินใจมากขึ้น เพื่อแก้ไขปัญหาใหม่ๆ
• ทำให้ทุกอย่างที่เกี่ยวข้องกับความปลอดภัยเป็น self-service ถ้าเป็นไปได้: พวกเขาเชื่อว่าคนส่วนใหญ่ต้องการทำสิ่งที่ถูกต้อง ดังนั้นจึงจำเป็นต้องให้บริบทและข้อมูลทั้งหมด ที่พวกเขาต้องการในการแก้ไขปัญหาใดๆ
• ใช้แนวทางแบบองค์รวมเพื่อบรรลุวัตถุประสงค์ของ Infosec: เป้าหมายของพวกเขาคือการวิเคราะห์จากทุกมุม: source code, สภาพแวดล้อมการทำงานจริง (production) และแม้แต่สิ่งที่ลูกค้ากำลังเห็น
ความก้าวหน้าครั้งใหญ่ครั้งแรกเกิดขึ้นระหว่างสัปดาห์ hackathon ทั่วทั้งบริษัทเมื่อพวกเขาบูรณาการ static code analysis เข้ากับกระบวนการ build ของ Twitter ทีมงานใช้ Brakeman ซึ่งสแกน แอปพลิเคชัน Ruby on Rails เพื่อหาช่องโหว่ เป้าหมายคือการบูรณาการการสแกนความปลอดภัย เข้าไปในขั้นตอนแรกสุดของกระบวนการ Development ไม่ใช่แค่เมื่อโค้ดถูก commit ลงใน source code repo 14
ผลลัพธ์ของการบูรณาการการทดสอบความปลอดภัยเข้ากับกระบวนการพัฒนานั้นน่าทึ่งมาก ตลอดหลายปีที่ผ่านมา โดยการสร้าง feedback ที่รวดเร็วสำหรับนักพัฒนาเมื่อพวกเขาเขียนโค้ดที่ไม่ปลอดภัย และแสดงวิธีแก้ไขช่องโหว่ Brakeman ได้ลดอัตราช่องโหว่ที่พบลง 60% 15 ดังที่แสดงใน Figure 22.2 (จุดสูงสุดมักเกี่ยวข้องกับการปล่อยเวอร์ชันใหม่ของ Brakeman)
Figure 22.2: Number of Brakeman Security Vulnerabilities Detected (จำนวนช่องโหว่ด้านความปลอดภัยที่ Brakeman ตรวจพบ)
กรณีศึกษานี้แสดงให้เห็นว่าการบูรณาการความปลอดภัยเข้ากับงานประจำวันและเครื่องมือของ DevOps นั้นจำเป็นเพียงใด และมันสามารถทำงานได้อย่างมีประสิทธิภาพเพียงใด การทำเช่นนี้ช่วยลดความเสี่ยง ด้านความปลอดภัย ลดความน่าจะเป็นของช่องโหว่ในระบบ และช่วยสอนนักพัฒนาให้เขียนโค้ดที่ปลอดภัยยิ่งขึ้น
Ensure Security of Our Software Supply Chain (มั่นใจในความปลอดภัยของ Software Supply Chain ของเรา)
Josh Corman ตั้งข้อสังเกตว่าในฐานะนักพัฒนา "เราไม่ได้เขียนซอฟต์แวร์ที่ปรับแต่งเองอีกต่อไป— แต่เราประกอบสิ่งที่เราต้องการจากชิ้นส่วน open-source ซึ่งกลายเป็น software supply chain ที่เราพึ่งพาอย่างมาก" 16 กล่าวอีกนัยหนึ่ง เมื่อเราใช้คอมโพเนนต์หรือ libraries—ไม่ว่าจะเป็นเชิงพาณิชย์หรือ open-source— ในซอฟต์แวร์ของเรา เราไม่เพียงได้รับฟังก์ชันการทำงานของพวกเขา แต่ยังรวมถึงช่องโหว่ด้านความปลอดภัย ที่มีอยู่ในนั้นด้วย
Continuous Learning (การเรียนรู้ต่อเนื่อง)
ในรายงาน 2020 State of the Octoverse ดร. Nicole Forsgren และทีมของเธอได้ทำการวิเคราะห์เชิงลึกเกี่ยวกับ open-source และ dependencies ของพวกเขาในส่วน Securing Software ของรายงาน พวกเขาพบว่าการใช้ open-source dependencies ที่พบบ่อยที่สุดคือใน JavaScript (94%), Ruby (90%) และ .NET (90%) 17
งานวิจัยของพวกเขายังพบว่าเมื่อทีมใช้ automation เพื่อสร้าง pull request patch สำหรับช่องโหว่ที่ตรวจพบ มันช่วยเร่งความปลอดภัยของ supply chain ได้เร็วขึ้นสิบสามวัน หรือเร็วกว่าถึง 1.4 เท่า เมื่อเทียบกับทีมที่ไม่ได้ใช้ นี่แสดงให้เห็นถึงประสิทธิภาพ ของการ shift left และการบูรณาการความปลอดภัยเข้ากับเวิร์กโฟลว์การพัฒนาและปฏิบัติการของเรา 18
เมื่อเลือกซอฟต์แวร์ เราจะตรวจจับเมื่อโปรเจกต์ซอฟต์แวร์ของเราพึ่งพาคอมโพเนนต์หรือ libraries ที่มีช่องโหว่ที่ทราบแล้ว และช่วยให้นักพัฒนาเลือกคอมโพเนนต์ที่พวกเขาใช้อย่างระมัดระวังและรอบคอบ โดยเลือกคอมโพเนนต์เหล่านั้น (เช่น โปรเจกต์ open-source) ที่มีประวัติที่แสดงให้เห็นถึงการแก้ไข ช่องโหว่ซอฟต์แวร์อย่างรวดเร็ว นอกจากนี้เรายังมองหาการใช้ library เดียวกันหลายเวอร์ชัน ใน production landscape ของเรา โดยเฉพาะอย่างยิ่งการมี library เวอร์ชันเก่าที่มีช่องโหว่ที่ทราบแล้ว
การตรวจสอบการละเมิดข้อมูลบัตรเครดิตแสดงให้เห็นว่าความปลอดภัยของคอมโพเนนต์ open-source ที่เราเลือกนั้นสำคัญเพียงใด ตั้งแต่ปี 2008 รายงาน Verizon PCI Data Breach Investigation Report (DBIR) ประจำปีเป็นแหล่งข้อมูลที่น่าเชื่อถือที่สุดเกี่ยวกับการละเมิดข้อมูลที่ข้อมูลบัตรเครดิตสูญหายหรือถูกขโมย รายงานปี 2014 ศึกษาการละเมิดมากกว่าแปดหมื่นห้าพันครั้งเพื่อทำความเข้าใจว่าการโจมตีมาจากไหน ข้อมูลบัตรเครดิตถูกขโมยอย่างไร และปัจจัยที่นำไปสู่การละเมิด
DBIR ปี 2014 พบว่าช่องโหว่สิบรายการ (CVEs) คิดเป็นเกือบ 97% ของการโจมตีที่ใช้ในการละเมิด ข้อมูลบัตรเครดิตที่ศึกษาในปี 2014 จากช่องโหว่สิบรายการนี้ แปดรายการมีอายุมากกว่าสิบปี 19
Continuous Learning (การเรียนรู้ต่อเนื่อง)
ในปี 2021 ผู้เขียน DBIR วิเคราะห์ช่องโหว่บน assets ทั้งหมดที่เชื่อมต่ออินเทอร์เน็ตขององค์กร แปดสิบห้าแห่งและพบว่าส่วนใหญ่มีช่องโหว่ตั้งแต่ปี 2010 หรือก่อนหน้านั้น พวกเขาเขียนว่า "ใครๆ ก็คิดว่าช่องโหว่ที่ใหม่กว่าจะพบได้บ่อยกว่า อย่างไรก็ตาม อย่างที่เราเห็นในปีที่แล้ว จริงๆ แล้วเป็นช่องโหว่ที่เก่ากว่าที่เป็นผู้นำ" 20
รายงาน Sonatype State of the Software Supply Chain Report ปี 2019 ซึ่งร่วมเขียนโดย ดร. Stephen Magill และ Gene Kim อธิบายการวิเคราะห์ Maven Central repository ซึ่งเก็บคอมโพเนนต์ซอฟต์แวร์สำหรับระบบนิเวศ Java (คล้ายกับที่ NPM ทำสำหรับ JavaScript, PyPi สำหรับ Python หรือ Gems สำหรับ Ruby) ในปี 2019 Maven Central มีมากกว่าสี่ล้านเวอร์ชัน ของ 310,000 คอมโพเนนต์ ให้บริการคำขอดาวน์โหลดมากกว่า 146 พันล้านครั้ง (เติบโต 68% เมื่อเทียบกับปีก่อนหน้า) ในการศึกษา ผู้เขียนวิเคราะห์ JAR artifacts 4.2 ล้านรายการ (ไฟล์ Java archive) และ 6,952 โปรเจกต์ GitHub ที่ artifacts เหล่านี้อยู่ 21
รายงานรวมถึงผลการค้นพบที่น่าตกใจเหล่านี้: 22
• 9% ของคอมโพเนนต์มีช่องโหว่อย่างน้อยหนึ่งรายการ
• เมื่อวิเคราะห์คอมโพเนนต์และ transitive dependencies ทั้งหมด 47% ของคอมโพเนนต์มีช่องโหว่อย่างน้อยหนึ่งรายการ
• ค่ามัธยฐานของเวลาที่คอมโพเนนต์ซอฟต์แวร์ใช้ในการแก้ไขช่องโหว่คือ 326 วัน
Figure 22.3: Time to Remediate vs. Time to Update Dependencies (TTU) (เวลาในการแก้ไขเทียบกับเวลาในการอัปเดต Dependencies)
ที่มา: Sonatype, 2019 Software Supply Chain Report .
รายงานปี 2019 ยังแสดงให้เห็นว่าเมื่อวิเคราะห์คอมโพเนนต์ซอฟต์แวร์ เวลาที่โปรเจกต์เหล่านี้ใช้ ในการแก้ไขช่องโหว่ด้านความปลอดภัย (TTR) มีความสัมพันธ์กับเวลาที่ใช้ในการอัปเดต dependencies ใดๆ ของพวกเขา (TTU) 23 กล่าวอีกนัยหนึ่ง โปรเจกต์ที่อัปเดตบ่อยกว่ามักจะแก้ไขช่องโหว่ด้านความปลอดภัยได้เร็วกว่า
ข้อเท็จจริงนี้เป็นแรงจูงใจให้ Jeremy Long ผู้ก่อตั้งโครงการ OWASP Dependency Check แนะนำว่ากลยุทธ์การแพตช์ความปลอดภัยที่ดีที่สุดคือการคงความทันสมัยอยู่เสมอกับ dependencies ทั้งหมด 24 เขาคาดการณ์ว่า "มีเพียง 25% ขององค์กรที่รายงานช่องโหว่ให้ผู้ใช้ทราบ และมีเพียง 10% ของช่องโหว่ ที่ถูกรายงานเป็น Common Vulnerabilities and Exposures (CVE)" 25 ยิ่งไปกว่านั้น การเผยแพร่ CVE มักเป็นช่องโหว่ที่ได้รับการแก้ไขในเวอร์ชันก่อนหน้าของคอมโพเนนต์
ตัวอย่างเช่น PrimeFaces CVE-2017-1000486 ถูกเผยแพร่ในวันที่ 3 มกราคม 2018 ซึ่ง cryptominers เริ่มใช้ประโยชน์จากช่องโหว่นี้ แต่ที่จริงแล้วช่องโหว่ได้รับการแก้ไขตั้งแต่ กุมภาพันธ์ 2016 ผู้ที่อัปเดตเป็นเวอร์ชันใหม่กว่าแล้วจะไม่ได้รับผลกระทบ 26
การศึกษาในปี 2019 ยังพบว่า "ความนิยม" ของโปรเจกต์ซอฟต์แวร์ (เช่น จำนวน GitHub stars หรือ forks หรือจำนวนดาวน์โหลดจาก Maven Central) ไม่ได้มีความสัมพันธ์กับลักษณะความปลอดภัยที่ดีกว่า 27 ซึ่งเป็นปัญหาเพราะวิศวกรจำนวนมากเลือกคอมโพเนนต์ open-source โดยพิจารณาจากความนิยมของโปรเจกต์ อย่างไรก็ตาม ความนิยมของโปรเจกต์ไม่ได้รับการพิสูจน์ว่ามีความสัมพันธ์กับ TTU ของพวกเขา (เวลาในการอัปเดต dependencies) 28
การศึกษาของ Sonatype ปี 2019 พบกลุ่มพฤติกรรมห้ากลุ่มสำหรับโปรเจกต์ open-source: 29
• Small exemplar (ตัวอย่างขนาดเล็ก): ทีมพัฒนาขนาดเล็ก (นักพัฒนา 1.6 คน), MTTU ที่เป็นแบบอย่าง
• Large exemplar (ตัวอย่างขนาดใหญ่): ทีมพัฒนาขนาดใหญ่ (นักพัฒนา 8.9 คน), MTTU ที่เป็นแบบอย่าง, มีแนวโน้มสูงที่จะได้รับการสนับสนุนจากมูลนิธิ, ได้รับความนิยมมากกว่า 11 เท่า
• Laggards (กลุ่มที่ล้าหลัง): MTTU แย่, จำนวน stale dependencies สูง, มีแนวโน้มที่จะได้รับการสนับสนุนเชิงพาณิชย์มากกว่า
• Features first (ให้ความสำคัญกับฟีเจอร์ก่อน): ปล่อยเวอร์ชันบ่อยแต่ TTU แย่, ยังคงได้รับความนิยมพอสมควร
• Cautious (กลุ่มที่ระมัดระวัง): TTU ดีแต่แทบไม่อัปเดตจนทันสมัยสมบูรณ์
Figure 22.4: Five Behavioral Clusters for Open-Source Projects (กลุ่มพฤติกรรมห้ากลุ่มสำหรับโปรเจกต์ Open-Source)
ที่มา: Sonatype, 2019 Software Supply Chain Report .
รายงาน State of the Software Supply Chain Report ปี 2020 สำรวจนักพัฒนาเพื่อพิจารณาว่าแนวปฏิบัติใดช่วยบรรลุเป้าหมายด้าน productivity และความปลอดภัยของนักพัฒนา เมื่อเปรียบเทียบกลุ่มที่มีประสิทธิภาพสูงกับกลุ่มที่มีประสิทธิภาพต่ำ (วัดจากผลลัพธ์ด้าน productivity และความปลอดภัยของนักพัฒนา) พวกเขาพบว่ากลุ่มที่มีประสิทธิภาพสูง มีคุณสมบัติเหล่านี้: 30
Confidence of Changes (ความมั่นใจในการเปลี่ยนแปลง):
• Deploy ถี่ขึ้น 15 เท่า
• มีโอกาสน้อยกว่า 4.9 เท่าที่ dependencies จะทำให้ฟังก์ชันการทำงานของแอปพลิเคชันเสียหาย
• มีโอกาสมากกว่า 3.8 เท่าที่จะอธิบายว่าการอัปเดต dependencies เป็นเรื่องง่าย (ไม่เจ็บปวด)
Security of Components (ความปลอดภัยของคอมโพเนนต์):
• ตรวจจับและแก้ไขคอมโพเนนต์ OSS ที่มีช่องโหว่ได้เร็วขึ้น 26 เท่า
• มีความมั่นใจมากกว่า 33 เท่า ว่า OSS dependencies ปลอดภัย (ไม่มีช่องโหว่ที่ทราบ)
• มีความมั่นใจมากกว่า 4.6 เท่า ว่าใบอนุญาต OSS ของ dependencies สอดคล้องกับข้อกำหนดภายใน
• มีโอกาสมากกว่า 2.1 เท่า ที่จะเข้าถึงคอมโพเนนต์ OSS เวอร์ชันใหม่กว่าที่แก้ไขข้อบกพร่องก่อนหน้านี้แล้ว
Productivity (ประสิทธิภาพการทำงาน):
• ใช้เวลาน้อยกว่า 5.7 เท่า สำหรับนักพัฒนาในการทำงานได้อย่างมีประสิทธิภาพเมื่อย้ายทีม
• ใช้เวลาน้อยกว่า 26 เท่า ในการอนุมัติ OSS dependency ใหม่เพื่อนำมาใช้
• มีโอกาสมากกว่า 1.5 เท่า ที่พนักงานจะแนะนำองค์กรของตนเป็นสถานที่ทำงานที่ดี
เมื่อเปรียบเทียบแนวปฏิบัติระหว่างกลุ่มเหล่านี้ ความแตกต่างของประสิทธิภาพสามารถอธิบายได้ จากระดับที่วัตถุประสงค์ด้านการกำกับดูแล (governance) ถูก automate และบูรณาการเข้ากับกระบวนการ ที่นักพัฒนาใช้ในงานประจำวัน กลุ่มที่มีประสิทธิภาพสูงมีแนวโน้ม: 31
• มีโอกาสมากกว่า 77% ที่จะ automate การอนุมัติ การจัดการ และการวิเคราะห์ dependencies
• มีโอกาสมากกว่า 59% ที่จะใช้เครื่องมือ software composition analysis (SCA)
• มีโอกาสมากกว่า 28% ที่จะบังคับใช้ governance policies ใน Continuous Integration (CI)
• มีโอกาสมากกว่า 56% ที่จะมีโครงสร้างพื้นฐาน CI ที่จัดการแบบรวมศูนย์ (ซึ่งสามารถบังคับใช้นโยบาย governance ด้านความปลอดภัยของข้อมูลได้)
• มีโอกาสมากกว่า 51% ที่จะรักษาบันทึกแบบรวมศูนย์ของ artifacts ที่ deploy ทั้งหมด เพื่อสนับสนุนการรวบรวม Software Bill of Materials (SBOM) สำหรับแต่ละแอปพลิเคชัน
• มีโอกาสมากกว่า 96% ที่จะสามารถสแกน artifacts ที่ deploy ทั้งหมดแบบรวมศูนย์ เพื่อความปลอดภัยและความสอดคล้องของใบอนุญาต
การศึกษาอีกชิ้นที่ยืนยันสถิติเหล่านี้คือโดย ดร. Dan Geer และ Josh Corman ซึ่งแสดงให้เห็นว่า จากโปรเจกต์ open-source ที่มีช่องโหว่ที่ทราบซึ่งลงทะเบียนใน National Vulnerability Database มีเพียง 41% เท่านั้นที่ได้รับการแก้ไข และใช้เวลาเฉลี่ย 390 วันในการเผยแพร่การแก้ไข สำหรับช่องโหว่ที่ถูกระบุว่ารุนแรงที่สุด (คือช่องโหว่ที่ได้คะแนน CVSS ระดับ 10) การแก้ไขใช้เวลา 224 วัน 32 ¶
Continuous Learning (การเรียนรู้ต่อเนื่อง)
รายงาน State of the Octoverse ปี 2020 แสดงไทม์ไลน์ของช่องโหว่ใน open-source: ใน GitHub โดยทั่วไปช่องโหว่จะใช้เวลา 218 สัปดาห์ (กว่าสี่ปี) ก่อนที่จะถูกเปิดเผย จากนั้นใช้เวลาประมาณ 4.4 สัปดาห์สำหรับชุมชน ในการระบุและเผยแพร่การแก้ไข จากนั้นใช้เวลาสิบสัปดาห์ในการแจ้งเตือนเกี่ยวกับความพร้อมของการแก้ไข สำหรับ repos ที่ทำการแก้ไข โดยทั่วไปจะใช้เวลาหนึ่งสัปดาห์ในการแก้ไข 33
การละเมิดความปลอดภัยที่โดดเด่นสองครั้งในปีที่ผ่านมา SolarWinds และ Codecov เกี่ยวข้องกับการโจมตีซอฟต์แวร์ supply chain ในฤดูใบไม้ผลิปี 2020 มีการเพิ่ม payload ที่เป็นอันตรายในการอัปเดตซอฟต์แวร์ SolarWinds Orion network management ซึ่งส่งผลกระทบต่อลูกค้ามากกว่า 18,000 ราย payload ใช้บัญชีที่มีสิทธิพิเศษ สำหรับโครงสร้างพื้นฐานเครือข่ายขององค์กรเพื่อเข้าถึงโดยไม่ได้รับอนุญาต ตั้งแต่การอ่านอีเมลไปจนถึงการปลูกสิ่งที่ทำลายล้างมากกว่า 34
ในเดือนเมษายน 2021 มีการค้นพบ "CI poisoning attack" ใน Codecov ซึ่งเป็นเครื่องมือ วิเคราะห์ coverage ของโค้ด payload ที่เป็นอันตรายถูกเพิ่มลงใน Docker image และ bash uploader ของ Codecov ซึ่งขโมย credentials จากสภาพแวดล้อม CI ซึ่งน่าจะส่งผลกระทบต่อลูกค้าจำนวนมากจาก 29,000 รายที่รายงาน 35
การโจมตีทั้งสองครั้งนี้แสดงให้เห็นว่าองค์กรพึ่งพาการอัปเดตอัตโนมัติมากเพียงใด CI/CD pipeline ใดๆ ก็สามารถถูกบุกรุกเพื่อแทรก payload ที่เป็นอันตรายได้อย่างไร (ซึ่งจะกล่าวถึงในภายหลังในหนังสือ) และความเสี่ยงใหม่ๆ สามารถเกิดขึ้นได้อย่างไร เมื่อมีการนำแนวปฏิบัติการพัฒนาใหม่ๆ มาใช้ นี่เป็นอีกตัวอย่างหนึ่งที่แสดงให้เห็นว่า ความปลอดภัยของข้อมูลต้องตรวจสอบภัยคุกคามที่เกิดจาก adversary ที่มีความคิดอย่างต่อเนื่อง
Ensure Security of the Environment (มั่นใจในความปลอดภัยของสภาพแวดล้อม)
ในขั้นตอนนี้ เราควรทำทุกอย่างที่จำเป็นเพื่อช่วยให้แน่ใจว่าสภาพแวดล้อมอยู่ในสถานะที่แข็งแกร่งและ ลดความเสี่ยง แม้ว่าเราอาจได้สร้างการตั้งค่าที่ดีและทราบแล้ว แต่เราต้องวางระบบ monitoring controls เพื่อให้แน่ใจว่า instances ใน production ทั้งหมดตรงกับสถานะที่ดีที่ทราบเหล่านี้
เราทำสิ่งนี้โดยการสร้างการทดสอบอัตโนมัติเพื่อให้แน่ใจว่าการตั้งค่าที่เหมาะสมทั้งหมดถูกนำไปใช้ อย่างถูกต้องสำหรับการปรับแต่งการตั้งค่า (configuration hardening), การตั้งค่าความปลอดภัยของฐานข้อมูล (database security settings), ความยาวของคีย์ (key lengths) และอื่นๆ ยิ่งไปกว่านั้น เราจะใช้การทดสอบ เพื่อสแกนสภาพแวดล้อมของเราหาช่องโหว่ที่ทราบ **
การตรวจสอบความปลอดภัยอีกประเภทหนึ่งคือการทำความเข้าใจสภาพแวดล้อมจริง (เช่น "ตามที่มันเป็นจริง") ตัวอย่างของเครื่องมือสำหรับสิ่งนี้รวมถึง Nmap เพื่อให้แน่ใจว่าเฉพาะพอร์ตที่คาดหวังเท่านั้นที่เปิด และ Metasploit เพื่อให้แน่ใจว่าเราได้ปรับแต่งสภาพแวดล้อมของเราอย่างเพียงพอต่อช่องโหว่ที่ทราบ เช่น การสแกนด้วย SQL injection attacks ผลลัพธ์ของเครื่องมือเหล่านี้ควรถูกใส่ลงใน artifact repository ของเราและเปรียบเทียบกับเวอร์ชันก่อนหน้าเป็นส่วนหนึ่งของกระบวนการ functional testing การทำเช่นนี้จะช่วยให้เราตรวจจับการเปลี่ยนแปลงที่ไม่พึงประสงค์ได้ทันทีที่เกิดขึ้น
CASE STUDY (กรณีศึกษา)
18F Automating Compliance for the Federal Government with Compliance Masonry (2016) (18F ทำให้ Compliance สำหรับรัฐบาลกลางเป็นอัตโนมัติด้วย Compliance Masonry ปี 2016)
หน่วยงานรัฐบาลกลางสหรัฐฯ คาดว่าจะใช้จ่ายเกือบ 80 พันล้านดอลลาร์ด้าน IT ในปี 2016 เพื่อสนับสนุนภารกิจของหน่วยงานในฝ่ายบริหารทั้งหมด
ไม่ว่าหน่วยงานใดก็ตาม การนำระบบจาก "dev complete" ไปสู่ "live in production" จำเป็นต้องได้รับ authority to operate (ATO) จาก designated approving authority (DAA)
กฎหมายและนโยบายที่ควบคุม compliance ในหน่วยงานรัฐบาลประกอบด้วยเอกสารหลายสิบฉบับ ซึ่งรวมกันมีมากกว่าสี่พันหน้า เต็มไปด้วยตัวย่อเช่น FISMA, FedRAMP และ FITARA แม้แต่กับระบบที่ต้องการระดับการรักษาความลับ ความถูกต้อง และความพร้อมใช้งานในระดับต่ำ ก็ยังต้อง implement, document และทดสอบการควบคุมมากกว่าหนึ่งร้อยรายการ โดยปกติจะใช้เวลาแปดถึงสิบสี่เดือนในการได้รับ ATO หลังจาก "dev complete" 36
ทีม 18F ใน General Services Administration ของรัฐบาลกลางได้ใช้แนวทางหลายด้าน ในการแก้ไขปัญหานี้ Mike Bland อธิบายว่า "18F ถูกสร้างขึ้นภายใน General Services Administration เพื่อใช้ประโยชน์จากแรงผลักดันที่เกิดจากการกู้คืน Healthcare.gov เพื่อปฏิรูปวิธีการที่รัฐบาลสร้างและซื้อซอฟต์แวร์" 37
ความพยายามหนึ่งของ 18F คือแพลตฟอร์มในรูปแบบ platform as a service ที่ชื่อ Cloud.gov ซึ่งสร้างขึ้นจากคอมโพเนนต์ open-source Cloud.gov ทำงานบน AWS GovCloud ในปี 2016 แพลตฟอร์มนี้ไม่เพียงแต่จัดการปัญหาด้านการปฏิบัติการ ที่ทีมส่งมอบอาจต้องจัดการเอง เช่น logging, monitoring, alerting และ service life cycle management แต่ยังจัดการกับปัญหาด้าน compliance ส่วนใหญ่ด้วย
โดยการทำงานบนแพลตฟอร์มนี้ การควบคุมส่วนใหญ่ที่ระบบของรัฐบาลต้อง implement สามารถจัดการได้ในระดับโครงสร้างพื้นฐานและแพลตฟอร์ม จากนั้น เฉพาะการควบคุมที่เหลือ ที่อยู่ในขอบเขตของ application layer เท่านั้นที่ต้องถูกบันทึกและทดสอบ ซึ่งช่วยลดภาระด้าน compliance และเวลาที่ใช้ในการรับ ATO ลงอย่างมาก 38
AWS GovCloud ได้รับการอนุมัติให้ใช้สำหรับระบบรัฐบาลกลางทุกประเภท รวมถึงระบบที่ต้องการ ระดับการรักษาความลับ ความถูกต้อง และความพร้อมใช้งานในระดับสูง Cloud.gov ได้รับการอนุมัติสำหรับทุกระบบที่ต้องการระดับการรักษาความลับ ความถูกต้อง และความพร้อมใช้งานในระดับปานกลาง ††
ยิ่งไปกว่านั้น ทีม Cloud.gov ได้สร้าง framework เพื่อ automate การสร้าง system security plans (SSPs) ซึ่งเป็น "คำอธิบายที่ครอบคลุมเกี่ยวกับสถาปัตยกรรมของระบบ การควบคุมที่ implemented และท่าทีด้านความปลอดภัยโดยรวม . . . [ซึ่ง] มักจะซับซ้อนอย่างไม่น่าเชื่อ มีความยาวหลายร้อยหน้า" 39 พวกเขาพัฒนาเครื่องมือต้นแบบที่ชื่อ compliance masonry เพื่อให้ข้อมูล SSP ถูกจัดเก็บในรูปแบบ YAML ที่เครื่องอ่านได้ แล้วแปลงเป็น GitBooks และ PDF โดยอัตโนมัติ
18F ทุ่มเทให้กับการทำงานในแบบเปิด (working in the open) และเผยแพร่ผลงานเป็น open-source ในสาธารณสมบัติ คุณสามารถหา compliance masonry และคอมโพเนนต์ที่ประกอบเป็น Cloud.gov ได้ใน GitHub repositories ของ 18F—คุณสามารถติดตั้ง instance ของ Cloud.gov ของคุณเองได้ งานเกี่ยวกับเอกสารแบบเปิดสำหรับ SSPs กำลังดำเนินการอย่างใกล้ชิด กับชุมชน OpenControl
กรณีศึกษานี้แสดงให้เห็นว่าองค์กร—แม้แต่องค์กรที่ใหญ่เท่ารัฐบาลกลาง— สามารถใช้ PaaS เพื่อสร้างการทดสอบอัตโนมัติและยังคงบรรลุ compliance ได้
Integrate Information Security into Production Telemetry (บูรณาการความปลอดภัยของข้อมูลเข้าไปใน Production Telemetry)
Marcus Sachs ตั้งข้อสังเกตในปี 2010 ว่า
ปีแล้วปีเล่า ในการละเมิดข้อมูลบัตรเครดิตส่วนใหญ่ องค์กรตรวจพบการละเมิดความปลอดภัย เป็นเดือนหรือไตรมาสหลังจากที่การละเมิดเกิดขึ้น ที่แย่กว่านั้น วิธีที่ตรวจพบการละเมิด ไม่ใช่การควบคุมการตรวจสอบภายใน แต่มีแนวโน้มมากกว่าว่าเป็นคนนอกองค์กร มักจะเป็นพันธมิตรทางธุรกิจหรือลูกค้าที่สังเกตเห็นธุรกรรมที่ฉ้อโกง สาเหตุหลักประการหนึ่ง คือไม่มีใครในองค์กรตรวจสอบไฟล์ log อย่างสม่ำเสมอ 40
กล่าวอีกนัยหนึ่ง การควบคุมความปลอดภัยภายในมักไม่มีประสิทธิภาพในการตรวจจับการละเมิด ได้ทันเวลา ไม่ว่าจะเป็นเพราะจุดบอดในการตรวจสอบของเรา หรือเพราะไม่มีใครในองค์กรของเรา ที่ตรวจสอบ telemetry ที่เกี่ยวข้องในงานประจำวันของพวกเขา
ใน Chapter 14 เราได้พูดถึงการสร้างวัฒนธรรมใน Dev และ Ops ที่ทุกคนใน value stream สร้าง production telemetry และ metrics ทำให้พวกเขามองเห็นได้ในที่สาธารณะที่โดดเด่นเพื่อให้ทุกคนเห็นว่า services ของเรา ทำงานใน production อย่างไร นอกจากนี้ เราได้สำรวจความจำเป็นในการค้นหาสัญญาณความล้มเหลว ที่อ่อนแอลงเรื่อยๆ อย่างไม่ลดละ เพื่อที่เราจะได้ค้นหาและแก้ไขปัญหาก่อนที่มันจะนำไปสู่ ความล้มเหลวที่ร้ายแรง
ในที่นี้ เราปรับใช้ monitoring, logging และ alerting ที่จำเป็นเพื่อบรรลุวัตถุประสงค์ ด้านความปลอดภัยของข้อมูลของเราทั่วทั้งแอปพลิเคชันและสภาพแวดล้อมของเรา รวมถึงทำให้แน่ใจว่ามีการรวมศูนย์อย่างเพียงพอเพื่ออำนวยความสะดวกในการวิเคราะห์ และตอบสนองที่ง่ายและมีความหมาย
เราทำสิ่งนี้โดยการบูรณาการ security telemetry ของเราเข้ากับเครื่องมือเดียวกับที่ Development, QA และ Operations ใช้อยู่ เพื่อให้ทุกคนใน value stream มองเห็นว่า แอปพลิเคชันและสภาพแวดล้อมของพวกเขาทำงานอย่างไรในสภาพแวดล้อมที่มีภัยคุกคาม ที่ผู้โจมตีพยายามใช้ประโยชน์จากช่องโหว่ เข้าถึงโดยไม่ได้รับอนุญาต ปลูก backdoors กระทำการฉ้อโกง ทำ denial of service และอื่นๆ อยู่ตลอดเวลา
โดยการเผยแพร่ข้อมูลว่า services ของเราถูกโจมตีในสภาพแวดล้อมการทำงานจริงอย่างไร เราจะตอกย้ำว่าทุกคนต้องคิดเกี่ยวกับความเสี่ยงด้านความปลอดภัยและออกแบบมาตรการตอบโต้ ในงานประจำวันของพวกเขา
Creating Security Telemetry in Our Applications (การสร้าง Security Telemetry ในแอปพลิเคชันของเรา)
เพื่อตรวจจับพฤติกรรมผู้ใช้ที่เป็นปัญหาซึ่งอาจเป็นตัวบ่งชี้หรือปัจจัยที่เอื้อต่อการฉ้อโกง และการเข้าถึงโดยไม่ได้รับอนุญาต เราต้องสร้าง telemetry ที่เกี่ยวข้องในแอปพลิเคชันของเรา ตัวอย่างอาจรวมถึง:
• การเข้าสู่ระบบที่สำเร็จและไม่สำเร็จของผู้ใช้
• การรีเซ็ตรหัสผ่านของผู้ใช้
• การรีเซ็ตที่อยู่อีเมลของผู้ใช้
• การเปลี่ยนบัตรเครดิตของผู้ใช้
ตัวอย่างเช่น เมื่อเป็นตัวบ่งชี้เบื้องต้นของความพยายาม brute-force login เพื่อเข้าถึงโดยไม่ได้รับอนุญาต เราอาจแสดงอัตราส่วนของความพยายามเข้าสู่ระบบที่ไม่สำเร็จ ต่อการเข้าสู่ระบบที่สำเร็จ และแน่นอน เราควรสร้างการแจ้งเตือนเกี่ยวกับเหตุการณ์สำคัญ เพื่อให้แน่ใจว่าเราสามารถตรวจจับและแก้ไขปัญหาได้อย่างรวดเร็ว
Creating Security Telemetry in Our Environment (การสร้าง Security Telemetry ในสภาพแวดล้อมของเรา)
นอกเหนือจากการ instrumenting แอปพลิเคชันของเราแล้ว เรายังต้องสร้าง telemetry ที่เพียงพอในสภาพแวดล้อมของเราเพื่อให้เราสามารถตรวจจับตัวบ่งชี้เบื้องต้นของการเข้าถึง โดยไม่ได้รับอนุญาต โดยเฉพาะอย่างยิ่งในคอมโพเนนต์ที่ทำงานบนโครงสร้างพื้นฐาน ที่เราไม่ได้ควบคุม (เช่น สภาพแวดล้อมโฮสติ้ง ในคลาวด์)
เราจำเป็นต้องตรวจสอบและอาจแจ้งเตือนเกี่ยวกับรายการต่างๆ รวมถึงต่อไปนี้: 41
• การเปลี่ยนแปลง OS (เช่น ใน production, ในโครงสร้างพื้นฐาน build ของเรา)
• การเปลี่ยนแปลง security group
• การเปลี่ยนแปลงการตั้งค่า production ทั้งหมดของเรา (เช่น OSSEC, Puppet, Chef, Tripwire, Kubernetes, โครงสร้างพื้นฐานเครือข่าย, middleware)
• การเปลี่ยนแปลงโครงสร้างพื้นฐานคลาวด์ (เช่น VPC, security groups, ผู้ใช้และสิทธิ์)
• ความพยายาม XSS (การโจมตี cross-site scripting)
• ความพยายาม SQLi (การโจมตี SQL injection)
• ข้อผิดพลาดของเว็บเซิร์ฟเวอร์ (เช่น ข้อผิดพลาด 4XX และ 5XX)
เรายังต้องการยืนยันว่าเราได้กำหนดค่า logging อย่างถูกต้องเพื่อให้ telemetry ทั้งหมด ถูกส่งไปยังที่ที่ถูกต้อง เมื่อเราตรวจจับการโจมตี นอกเหนือจากการบันทึกว่ามันเกิดขึ้นแล้ว เราอาจเลือกที่จะบล็อกการเข้าถึงและจัดเก็บข้อมูลเกี่ยวกับแหล่งที่มาเพื่อช่วยเรา ในการเลือกมาตรการบรรเทาที่ดีที่สุด
CASE STUDY (กรณีศึกษา)
Instrumenting the Environment at Etsy (2010) (การ Instrument สภาพแวดล้อมที่ Etsy ปี 2010)
ในปี 2010 Nick Galbreath เป็น director of engineering ที่ Etsy และรับผิดชอบด้านความปลอดภัยของข้อมูล การควบคุมการฉ้อโกง และความเป็นส่วนตัว Galbreath นิยาม fraud ว่าเมื่อ "ระบบทำงานไม่ถูกต้อง ทำให้เกิด input ที่ไม่ถูกต้องหรือไม่ผ่านการตรวจสอบเข้าสู่ระบบ ทำให้เกิดความสูญเสียทางการเงิน การสูญเสีย/การขโมยข้อมูล การหยุดทำงานของระบบ การทำลายทรัพย์สิน หรือการโจมตีระบบอื่น" 42
เพื่อให้บรรลุเป้าหมายเหล่านี้ Galbreath ไม่ได้สร้างแผนกควบคุมการฉ้อโกงหรือความปลอดภัย ของข้อมูลแยกต่างหาก แต่เขาฝังความรับผิดชอบเหล่านี้ไว้ทั่วทั้ง DevOps value stream
Galbreath สร้าง telemetry ที่เกี่ยวข้องกับความปลอดภัยซึ่งแสดงควบคู่ไปกับ metrics อื่นๆ ที่เน้น Dev และ Ops ที่วิศวกร Etsy ทุกคนเห็นเป็นประจำ: 43
• การยุติโปรแกรม production ที่ผิดปกติ (เช่น segmentation faults, core dumps ฯลฯ): "สิ่งที่น่ากังวลเป็นพิเศษคือเหตุใดกระบวนการบางอย่างจึง dump core ซ้ำแล้วซ้ำเล่า ทั่วสภาพแวดล้อม production ทั้งหมดของเรา ซึ่งถูกกระตุ้นจาก traffic ที่มาจากที่อยู่ IP เดียว ซ้ำแล้วซ้ำเล่า สิ่งที่น่ากังวลไม่แพ้กันคือ HTTP '500 Internal Server Errors' เหล่านี้เป็นตัวบ่งชี้ว่ากำลังมีการใช้ประโยชน์จากช่องโหว่เพื่อเข้าถึงระบบของเราโดยไม่ได้รับอนุญาต และจำเป็นต้องใช้แพตช์อย่างเร่งด่วน" 44
• Database syntax error (ข้อผิดพลาดไวยากรณ์ฐานข้อมูล): "เรามองหาข้อผิดพลาดไวยากรณ์ของฐานข้อมูลภายในโค้ดของเราเสมอ—ไม่ว่าจะเป็นการเปิดทาง ให้ SQL injection attacks หรือเป็นการโจมตีที่กำลังเกิดขึ้นจริง ด้วยเหตุนี้ เราจึงมีนโยบายไม่ยอมรับข้อผิดพลาดไวยากรณ์ของฐานข้อมูลในโค้ดของเราเลย เพราะมันยังคงเป็นหนึ่งในเวกเตอร์การโจมตีหลักที่ใช้ในการบุกรุกระบบ" 45
• สิ่งบ่งชี้ของการโจมตี SQL injection: "นี่เป็นการทดสอบที่ง่ายอย่างไม่น่าเชื่อ—เราเพียงแค่แจ้งเตือนเมื่อ 'UNION ALL' ปรากฏในฟิลด์ input ของผู้ใช้ เพราะมันเกือบจะบ่งบอกถึงการโจมตี SQL injection เสมอ นอกจากนี้เรายังเพิ่ม unit tests เพื่อให้แน่ใจว่า input ของผู้ใช้ที่ไม่ได้รับการควบคุมประเภทนี้ จะไม่ถูกอนุญาตให้เข้าไปในคำสั่ง查询ฐานข้อมูลของเรา" 46
Figure 22.5 เป็นตัวอย่างของกราฟที่นักพัฒนาทุกคนจะเห็น ซึ่งแสดงจำนวนของการโจมตี SQL injection ที่อาจเกิดขึ้นที่พยายามในสภาพแวดล้อม production
Figure 22.5: Developers See SQL Injection Attempts in Graphite at Etsy (นักพัฒนาเห็นความพยายาม SQL Injection ใน Graphite ที่ Etsy)
ที่มา: "DevOpsSec: Applying DevOps Principles to Security, DevOpsDays Austin 2012," SlideShare.net , โพสต์โดย Nick Galbreath, 12 เมษายน 2012, http://www.slideshare.net/nickgsuperstar/devopssec-apply-devops-principles-to-security .
ดังที่ Galbreath ตั้งข้อสังเกต "ไม่มีอะไรช่วยให้นักพัฒนาเข้าใจว่าสภาพแวดล้อมการปฏิบัติงาน เป็นศัตรูเพียงใดเท่ากับการเห็นโค้ดของพวกเขาถูกโจมตีแบบเรียลไทม์" 47 Galbreath กล่าวต่อ "ผลลัพธ์อย่างหนึ่งของการแสดงกราฟนี้คือนักพัฒนาตระหนักว่าพวกเขา ถูกโจมตีตลอดเวลา! และนั่นยอดเยี่ยมมาก เพราะมันเปลี่ยนวิธีที่นักพัฒนาคิดเกี่ยวกับ ความปลอดภัยของโค้ดของพวกเขาในขณะที่พวกเขากำลังเขียนโค้ด" 48
การนำเสนอ telemetry ที่เกี่ยวข้องกับความปลอดภัยนำความปลอดภัยเข้ามาสู่งานประจำวัน ของนักพัฒนา และทำให้ช่องโหว่มองเห็นได้ชัดเจนยิ่งขึ้นสำหรับทุกคน
Protect Our Deployment Pipeline (ปกป้อง Deployment Pipeline ของเรา)
โครงสร้างพื้นฐานที่สนับสนุนกระบวนการ continuous integration และ continuous deployment ของเรายังนำเสนอพื้นผิวใหม่ที่เสี่ยงต่อการถูกโจมตี ตัวอย่างเช่น ถ้ามีคนบุกรุกเซิร์ฟเวอร์ ที่รัน deployment pipeline ซึ่งมี credentials สำหรับ version control system ของเรา อาจทำให้ใครบางคนขโมย source code ได้ ที่แย่กว่านั้น ถ้า deployment pipeline มีสิทธิ์เขียน ผู้โจมตีก็สามารถแทรกการเปลี่ยนแปลงที่เป็นอันตรายลงใน version control repository ของเรา และดังนั้นจึงแทรกการเปลี่ยนแปลงที่เป็นอันตรายลงในแอปพลิเคชันและ services ของเราได้
ดังที่ Jonathan Claudius อดีต Senior Security Tester ที่ TrustWave SpiderLabs ตั้งข้อสังเกต "Continuous build and test servers นั้นยอดเยี่ยม และผมใช้มันด้วยตัวเอง แต่ผมเริ่มคิดถึงวิธีการใช้ CI/CD เป็นช่องทางในการ inject โค้ดที่เป็นอันตราย ซึ่งนำไปสู่คำถาม: ที่ไหนจะเป็นที่ที่ดีในการซ่อนโค้ดที่เป็นอันตราย? คำตอบนั้นชัดเจน: ใน unit tests ไม่มีใครดู unit tests จริงๆ และมันถูกรันทุกครั้งที่ใครบางคน commit โค้ดไปยัง repo" 49
นี่แสดงให้เห็นว่าเพื่อปกป้องความสมบูรณ์ของแอปพลิเคชันและสภาพแวดล้อมของเราอย่างเพียงพอ เราต้องลดทอนเวกเตอร์การโจมตีบน deployment pipeline ของเราด้วย ความเสี่ยงรวมถึงนักพัฒนาที่แนะนำ โค้ดที่เปิดทางให้เข้าถึงโดยไม่ได้รับอนุญาต (ซึ่งเราลดทอนผ่านการควบคุมเช่นการทดสอบโค้ด การตรวจสอบโค้ด และการทดสอบ penetration) และผู้ใช้ที่ไม่ได้รับอนุญาตที่เข้าถึงโค้ดหรือ สภาพแวดล้อมของเรา (ซึ่งเราลดทอนผ่านการควบคุมเช่นการทำให้แน่ใจว่าการตั้งค่าตรงกับสถานะที่ดี ที่ทราบและการแพตช์ที่มีประสิทธิภาพ)
อย่างไรก็ตาม เพื่อปกป้อง continuous build, integration หรือ deployment pipeline ของเรา กลยุทธ์การลดทอนของเราอาจรวมถึง:
• การปรับแต่งความแข็งแกร่งให้เซิร์ฟเวอร์ continuous build และ integration และทำให้แน่ใจว่า เราสามารถสร้างมันขึ้นมาใหม่ได้ในลักษณะอัตโนมัติ เช่นเดียวกับที่เราทำกับโครงสร้างพื้นฐาน ที่สนับสนุน services ใน production ที่ลูกค้าใช้ เพื่อป้องกันไม่ให้เซิร์ฟเวอร์ continuous build และ integration ของเราถูกบุกรุก
• การตรวจสอบการเปลี่ยนแปลงทั้งหมดที่นำเข้าสู่ version control ไม่ว่าจะผ่าน pair programming ในเวลาที่ commit หรือโดยกระบวนการตรวจสอบโค้ดระหว่าง commit และ merge เข้าสู่ trunk เพื่อป้องกันไม่ให้เซิร์ฟเวอร์ continuous integration รันโค้ดที่ไม่ถูกควบคุม (เช่น unit tests อาจมีโค้ดที่เป็นอันตรายที่อนุญาตหรือเปิดทางให้เข้าถึงโดยไม่ได้รับอนุญาต)
• การ instrumenting repository ของเราเพื่อตรวจจับเมื่อ test code ที่มีการเรียก API ที่น่าสงสัย (เช่น unit tests ที่เข้าถึง filesystem หรือ network) ถูกเช็คอินเข้าสู่ repository อาจจะกักกันมันไว้และเรียกใช้การตรวจสอบโค้ดทันที
• ทำให้แน่ใจว่า CI process ทุกตัวรันบน container หรือ VM ที่แยกเป็นอิสระของตัวเอง และทำให้แน่ใจว่าสิ่งนี้ถูกสร้างขึ้นใหม่จาก base image ที่ทราบว่าดีและผ่านการตรวจสอบแล้ว ในตอนเริ่มต้นของทุก build
• ทำให้แน่ใจว่า credentials ของ version control ที่ใช้โดย CI system เป็นแบบอ่านอย่างเดียว (read-only)
CASE STUDY: NEW TO THE SECOND EDITION (กรณีศึกษา: ใหม่ในฉบับพิมพ์ครั้งที่สอง)
Shifting Security Left at Fannie Mae (2020) (การ Shift Security Left ที่ Fannie Mae ปี 2020)
Fannie Mae มีงบดุลมากกว่า 3 พันล้านดอลลาร์และช่วยจัดหาเงินทุนสำหรับประมาณหนึ่งในสี่ของบ้าน ในสหรัฐฯ ณ ปี 2020 50 ที่ Fannie Mae ความปลอดภัยและความถูกต้อง (safety and soundness) เป็นส่วนหนึ่งของภารกิจของพวกเขา
พวกเขาเคยเผชิญวิกฤตมาก่อน ด้วยการยอมรับความเสี่ยงที่ต่ำ ความท้าทายของพวกเขาคือการทำให้แน่ใจว่า ความปลอดภัยเสริมสร้างทุกสิ่งที่พวกเขาทำ DevOps เป็นทางออกสำหรับการเรียนรู้จาก chaos engineering เพื่อปรับปรุงความปลอดภัย ใส่ความปลอดภัยใน pipeline และถักทอความปลอดภัยอย่างโปร่งใส เข้าไปในโครงสร้างของทุกสิ่งที่พวกเขาทำ
Chris Porter CISO ของ Fannie Mae และ Kimberly Johnson Executive Vice President และ COO พูดถึงวิวัฒนาการของพวกเขาในงาน DevOps Enterprise Summit 2020 มันสรุปลงมาที่การเปลี่ยนแปลงสำคัญสองประการ: การเปลี่ยนแปลงวัฒนธรรม และการเปลี่ยนแปลงวิธีที่ฝ่ายความปลอดภัยสื่อสารกับทีม Dev และวิธีที่พวกเขาบูรณาการเครื่องมือด้านความปลอดภัย 51
ในแบบเดิม Dev จะส่งมอบโค้ดที่พร้อมสำหรับ production ฝ่ายความปลอดภัยจะทำการทดสอบของตัวเอง และส่งกลับรายการช่องโหว่ที่ทีม Dev ต้องแก้ไข มันไม่มีประสิทธิภาพและไม่มีใครชอบ พวกเขาจำเป็นต้องเรียนรู้ที่จะ shift security left
พวกเขาทำสิ่งนี้โดยการสละการควบคุมเครื่องมือด้านความปลอดภัย ทำให้พวกเขาเป็น self-service มากขึ้น ทำให้พวกเขาเป็น API-based และบูรณาการกับ Jira และ Jenkins พวกเขาฝึกอบรมนักพัฒนาให้รันเครื่องมือ และเรียนรู้ว่าผลลัพธ์หมายถึงอะไร และพวกเขาต้องเปลี่ยนคำศัพท์ของตัวเอง (แทนที่จะพูดถึงช่องโหว่ พวกเขาพูดถึงข้อบกพร่อง) 52
พวกเขายังต้องบูรณาการการทดสอบความปลอดภัยทั้งหมดอย่างสมบูรณ์ภายใน CI/CD pipeline เพื่อให้ทุกครั้งที่มีการเช็คอินโค้ด พวกเขาจะรันการทดสอบ ท้ายที่สุดแล้ว สิ่งนี้ทำให้นักพัฒนารู้ได้ง่ายขึ้นว่าต้องทำอย่างไร พวกเขาสามารถเห็นการทดสอบล้มเหลว เข้าใจสาเหตุ และแก้ไขปัญหา 53
"ฉันเรียกสิ่งนี้ว่าถนนลาดยาง (the paved road) ถ้าคุณเดินตามถนนลาดยางและใช้ CI/CD pipeline ซึ่งมีการตรวจสอบทั้งหมดบูรณาการอยู่ใน pipeline แล้วมันจะง่ายขึ้นสำหรับคุณในการ deploy โค้ด" Chris Porter กล่าว 54
สิ่งนี้ถูกปฏิบัติเหมือน Andon cord ถ้าการทดสอบไม่ผ่าน มันจะหยุดสายการผลิตและต้องได้รับการแก้ไข ก่อนที่สายการผลิตจะดำเนินการต่อได้ ถ้าคุณไม่ใช้ถนนลาดยาง มันจะเป็นเส้นทางที่ช้ากว่า และขรุขระกว่ามาก
จากข้อมูลของ Porter จำเป็นต้องมีการเปลี่ยนแปลง mindset จากทั้งฝ่ายพัฒนาและฝ่ายความปลอดภัย ในอดีต mindset ของฝ่ายความปลอดภัยคือการปกป้องนักพัฒนาจากตัวพวกเขาเอง แต่ในแบบจำลอง DevOps งานได้เปลี่ยนไปเป็น "คุณสร้างมัน คุณเป็นเจ้าของมัน (you build it, you own it)" 55 ทุกคนมีความรับผิดชอบร่วมกัน และความปลอดภัยถูกฝังอยู่ในโค้ดแทนที่จะถูกเพิ่มเข้ามาทีหลัง
ดังที่ Kimberly Johnson กล่าวไว้:
ในแบบเดิม ที่ Dev ส่งมอบโค้ดที่พร้อมสำหรับ production ให้ฝ่ายความปลอดภัยทำการทดสอบ เรามีคอขวดใหญ่ในปริมาณงานของทีม Security สำหรับองค์กรขนาดใหญ่ที่ทำงานในระดับ scale มันอาจยากมากที่จะหาบุคลากรด้าน Security ที่เพียงพอที่จะทดสอบทุกอย่างที่พัฒนาขึ้นอย่างต่อเนื่อง การสร้างการทดสอบความปลอดภัยใน development pipeline ปลดล็อก productivity ให้กับเรามากขึ้น และลดการพึ่งพาบุคลากรด้าน Security สำหรับการทดสอบมาตรฐานและการ deploy ประจำ
นอกเหนือจากการลดการพึ่งพาทีม Information Security แล้ว การ shift left และ automate การทดสอบของเราให้ผลลัพธ์ทางธุรกิจที่ดีขึ้น ความถี่ในการ deploy ของเราเพิ่มขึ้น 25% ในปีที่แล้ว และอัตราความล้มเหลวในการ deploy ลดลงในปริมาณที่ใกล้เคียงกัน เราสามารถนำการเปลี่ยนแปลงทางธุรกิจที่สำคัญเข้าสู่ production ได้เร็วขึ้นมาก มีข้อผิดพลาดน้อยลง ใช้ทรัพยากรน้อยลง และสร้างงานซ่อมน้อยลง การย้ายไปสู่ DevSecOps เป็น win-win-win สำหรับเรา 56
โดยการ shift security left Fannie Mae สามารถรักษาความปลอดภัยและความถูกต้องของโค้ด โดยไม่ต้องเสียสละความเร็ว ประสิทธิภาพ และความสุขของทีมของพวกเขา
Conclusion (บทสรุป)
ตลอดทั้งบทนี้ เราได้อธิบายวิธีการบูรณาการวัตถุประสงค์ด้านความปลอดภัยของข้อมูลเข้าไปในทุกขั้นตอน ของงานประจำวันของเรา เราทำสิ่งนี้โดยการผสานการควบคุมความปลอดภัยเข้ากับกลไกที่เราสร้างไว้แล้ว เพื่อให้แน่ใจว่าสภาพแวดล้อม on-demand ทั้งหมดอยู่ในสถานะที่แข็งแกร่งและลดความเสี่ยง— โดยการบูรณาการการทดสอบความปลอดภัยเข้าไปใน deployment pipeline และทำให้แน่ใจว่ามีการสร้าง security telemetry ในสภาพแวดล้อม pre-production และ production การทำเช่นนี้ช่วยให้ productivity ของนักพัฒนาและฝ่ายปฏิบัติการเพิ่มขึ้นพร้อมๆ กับการเพิ่มความปลอดภัยโดยรวมของเรา ขั้นตอนต่อไปของเราคือการปกป้อง deployment pipeline