ความกลัวและความชิงชังของ DevSecOps

เรามีเครื่องวิเคราะห์โค้ด 2 เครื่อง เครื่องมือทดสอบไดนามิก 4 เครื่อง งานฝีมือของเราเอง และสคริปต์ 250 ตัว ไม่ใช่ว่าทั้งหมดนี้เป็นสิ่งจำเป็นในกระบวนการปัจจุบัน แต่เมื่อคุณเริ่มใช้งาน DevSecOps แล้ว คุณจะต้องดำเนินการให้เสร็จสิ้น

Источник. ผู้สร้างตัวละคร: Justin Roiland และ Dan Harmon

SecDevOps คืออะไร? แล้ว DevSecOps ล่ะ? อะไรคือความแตกต่าง? ความปลอดภัยของแอปพลิเคชัน - มันเกี่ยวกับอะไร? เหตุใดวิธีการแบบคลาสสิกจึงไม่ทำงานอีกต่อไป รู้คำตอบสำหรับคำถามเหล่านี้ทั้งหมด ยูริ ชาบาลิน ของ ความปลอดภัยของนาก ยูริจะตอบทุกอย่างอย่างละเอียดและวิเคราะห์ปัญหาของการเปลี่ยนจากโมเดล Application Security แบบคลาสสิกไปเป็นกระบวนการ DevSecOps: วิธีเข้าถึงการรวมกระบวนการพัฒนาที่ปลอดภัยเข้ากับกระบวนการ DevOps อย่างเหมาะสมและไม่ทำลายสิ่งใด ๆ จะผ่านขั้นตอนหลักได้อย่างไร ของการทดสอบความปลอดภัย เครื่องมือใดบ้างที่สามารถใช้ได้ และเครื่องมือที่แตกต่างกัน และวิธีกำหนดค่าให้ถูกต้องเพื่อหลีกเลี่ยงข้อผิดพลาด

เกี่ยวกับวิทยากร: ยูริ ชาบาลิน - หัวหน้าสถาปนิกรักษาความปลอดภัยของบริษัท ความปลอดภัยของนาก. รับผิดชอบในการใช้งาน SSDL สำหรับการบูรณาการโดยรวมของเครื่องมือวิเคราะห์แอปพลิเคชันเข้ากับระบบนิเวศการพัฒนาและการทดสอบแบบครบวงจร มีประสบการณ์ 7 ปีในด้านความปลอดภัยของข้อมูล ทำงานที่ Alfa-Bank, Sberbank และ Positive Technologies ซึ่งพัฒนาซอฟต์แวร์และให้บริการ วิทยากรในการประชุมระดับนานาชาติ ZeroNights, PHDays, RISSPA, OWASP

ความปลอดภัยของแอปพลิเคชัน: มันเกี่ยวกับอะไร?

ความปลอดภัยของแอพพลิเคชั่น - นี่คือส่วนความปลอดภัยที่รับผิดชอบด้านความปลอดภัยของแอปพลิเคชัน สิ่งนี้ใช้ไม่ได้กับโครงสร้างพื้นฐานหรือความปลอดภัยของเครือข่าย แต่ใช้กับสิ่งที่เราเขียนและสิ่งที่นักพัฒนาทำงานอยู่ - สิ่งเหล่านี้คือข้อบกพร่องและช่องโหว่ของแอปพลิเคชันเอง

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

ความปลอดภัยของแอปพลิเคชันและ SSDL ไม่ได้มุ่งเป้าไปที่การตรวจจับช่องโหว่ตามที่เชื่อกันโดยทั่วไป แต่เพื่อป้องกันการเกิดช่องโหว่เหล่านั้น เมื่อเวลาผ่านไป แนวทาง Canonical ของ Microsoft ได้รับการปรับปรุง พัฒนา และนำมาใช้ในการเจาะลึกและมีรายละเอียดมากขึ้น

Canonical SDLC มีรายละเอียดสูงในวิธีการต่างๆ - OpenSAMM, BSIMM, OWASP วิธีการจะแตกต่างกัน แต่โดยทั่วไปจะคล้ายกัน

การสร้างความปลอดภัยในโมเดลการเจริญเติบโต

ฉันชอบมันมากที่สุด บีซิมม์ - การสร้างความปลอดภัยในโมเดลการเจริญเติบโต. พื้นฐานของระเบียบวิธีคือการแบ่งกระบวนการรักษาความปลอดภัยแอปพลิเคชันออกเป็น 4 โดเมน ได้แก่ การกำกับดูแล ระบบอัจฉริยะ จุดสัมผัส SSDL และการปรับใช้ แต่ละโดเมนมี 12 แนวปฏิบัติ ซึ่งแสดงเป็น 112 กิจกรรม

แต่ละกิจกรรมมีทั้งหมด 112 กิจกรรม วุฒิภาวะ 3 ระดับ: ระดับเริ่มต้น ระดับกลาง และขั้นสูง คุณสามารถศึกษาแนวทางปฏิบัติทั้ง 12 ข้อทีละส่วน เลือกสิ่งที่สำคัญสำหรับคุณ หาวิธีนำไปใช้และค่อยๆ เพิ่มองค์ประกอบ เช่น การวิเคราะห์โค้ดแบบสแตติกและไดนามิก หรือการตรวจสอบโค้ด คุณเขียนแผนและทำงานอย่างใจเย็นตามแผนซึ่งเป็นส่วนหนึ่งของการดำเนินกิจกรรมที่เลือก

ทำไมต้อง DevSecOps

DevOps เป็นกระบวนการทั่วไปขนาดใหญ่ที่ต้องคำนึงถึงความปลอดภัย

ในขั้นต้น DevOps การตรวจสอบความปลอดภัยที่เกี่ยวข้อง ในทางปฏิบัติ จำนวนทีมรักษาความปลอดภัยยังน้อยกว่าตอนนี้มาก และพวกเขาไม่ได้ทำหน้าที่เป็นผู้เข้าร่วมในกระบวนการ แต่เป็นหน่วยงานควบคุมและกำกับดูแลที่กำหนดข้อกำหนดและตรวจสอบคุณภาพของผลิตภัณฑ์เมื่อสิ้นสุดการเปิดตัว นี่เป็นแนวทางคลาสสิกที่ทีมรักษาความปลอดภัยอยู่เบื้องหลังตั้งแต่การพัฒนาและไม่ได้มีส่วนร่วมในกระบวนการนี้

ปัญหาหลักคือความปลอดภัยของข้อมูลแยกจากการพัฒนา โดยปกติแล้วนี่คือวงจรรักษาความปลอดภัยข้อมูลบางประเภทและมีเครื่องมือขนาดใหญ่และมีราคาแพง 2-3 ชิ้น ซอร์สโค้ดหรือแอปพลิเคชันที่ต้องตรวจสอบทุกๆ หกเดือนจะมาถึง และจะมีการสร้างซอร์สโค้ดหรือแอปพลิเคชันปีละครั้ง เพนเทสต์. ทั้งหมดนี้นำไปสู่ความจริงที่ว่าวันวางจำหน่ายสำหรับอุตสาหกรรมเกิดความล่าช้า และนักพัฒนาก็เผชิญกับช่องโหว่จำนวนมากจากเครื่องมืออัตโนมัติ ทั้งหมดนี้เป็นไปไม่ได้ที่จะแยกชิ้นส่วนและซ่อมแซมเนื่องจากผลลัพธ์ในช่วงหกเดือนที่ผ่านมาไม่ได้ถูกแยกออก แต่นี่คือชุดใหม่

ในการทำงานของบริษัทเรา เราเห็นว่าการรักษาความปลอดภัยในทุกพื้นที่และอุตสาหกรรม เข้าใจดีว่าถึงเวลาที่ต้องตามทันและหมุนไปพร้อมกับการพัฒนาบนวงล้อเดียวกัน-ใน คล่องแคล่ว. กระบวนทัศน์ DevSecOps เข้ากันได้อย่างสมบูรณ์แบบกับวิธีการพัฒนาแบบ Agile การนำไปปฏิบัติ การสนับสนุน และการมีส่วนร่วมในทุกการเปิดตัวและการวนซ้ำ

การเปลี่ยนไปใช้ DevSecOps

คำที่สำคัญที่สุดในวงจรการพัฒนาความปลอดภัยคือ "กระบวนการ". คุณต้องเข้าใจสิ่งนี้ก่อนที่จะคิดจะซื้อเครื่องมือ

การรวมเครื่องมือเข้ากับกระบวนการ DevOps นั้นไม่เพียงพอ การสื่อสารและความเข้าใจระหว่างผู้เข้าร่วมกระบวนการเป็นสิ่งสำคัญ

คนมีความสำคัญมากกว่า ไม่ใช่เครื่องมือ

บ่อยครั้งที่การวางแผนสำหรับกระบวนการพัฒนาที่ปลอดภัยเริ่มต้นด้วยการเลือกและซื้อเครื่องมือ และจบลงด้วยความพยายามที่จะรวมเครื่องมือเข้ากับกระบวนการปัจจุบัน ซึ่งยังคงเป็นความพยายามอยู่ สิ่งนี้นำไปสู่ผลลัพธ์ที่ไม่พึงประสงค์ เนื่องจากเครื่องมือทั้งหมดมีลักษณะและข้อจำกัดของตัวเอง

กรณีทั่วไปคือเมื่อแผนกรักษาความปลอดภัยเลือกเครื่องมือที่ดีและมีราคาแพงและมีความสามารถมากมาย และมาหานักพัฒนาเพื่อรวมเข้ากับกระบวนการ แต่มันไม่ได้ผล - กระบวนการนี้มีโครงสร้างในลักษณะที่ข้อจำกัดของเครื่องมือที่ซื้อไปแล้วไม่สอดคล้องกับกระบวนทัศน์ปัจจุบัน

ขั้นแรก อธิบายว่าคุณต้องการผลลัพธ์อะไร และกระบวนการจะเป็นอย่างไร ซึ่งจะช่วยให้เข้าใจบทบาทของเครื่องมือและความปลอดภัยในกระบวนการ

เริ่มจากของที่มีอยู่แล้ว

ก่อนที่จะซื้อเครื่องมือราคาแพง ให้พิจารณาสิ่งที่คุณมีอยู่แล้วก่อน ทุกบริษัทมีข้อกำหนดด้านความปลอดภัยสำหรับการพัฒนา มีการตรวจสอบ การทดสอบ - ทำไมไม่แปลงทั้งหมดนี้ให้เป็นรูปแบบที่เข้าใจได้และสะดวกสำหรับทุกคน?

โดยปกติแล้วข้อกำหนดคือกระดาษทัลมุดที่วางอยู่บนชั้นวาง มีกรณีหนึ่งเมื่อเรามาที่บริษัทแห่งหนึ่งเพื่อดูกระบวนการและขอดูข้อกำหนดด้านความปลอดภัยสำหรับซอฟต์แวร์ ผู้เชี่ยวชาญที่จัดการกับเรื่องนี้ใช้เวลานานในการค้นหา:

- ตอนนี้ มีเส้นทางที่เอกสารนี้อยู่บางแห่งในบันทึกย่อ

เป็นผลให้เราได้รับเอกสารในอีกหนึ่งสัปดาห์ต่อมา

สำหรับข้อกำหนด การตรวจสอบ และอื่นๆ ให้สร้างเพจเกี่ยวกับ เช่น ที่บรรจบกัน - สะดวกสำหรับทุกคน

การฟอร์แมตสิ่งที่คุณมีอยู่แล้วนั้นง่ายกว่าและใช้เพื่อเริ่มต้นใช้งาน

ใช้แชมป์การรักษาความปลอดภัย

โดยทั่วไปแล้ว ในบริษัทโดยเฉลี่ยที่มีนักพัฒนา 100-200 คน จะมีผู้เชี่ยวชาญด้านความปลอดภัยหนึ่งคนที่ทำหน้าที่หลายอย่างและไม่มีเวลาตรวจสอบทุกอย่างโดยทางกายภาพ แม้ว่าเขาจะพยายามอย่างเต็มที่ แต่เขาคนเดียวจะไม่ตรวจสอบโค้ดทั้งหมดที่การพัฒนาสร้างขึ้น ในกรณีดังกล่าว ได้มีการพัฒนาแนวคิด - แชมป์ด้านความปลอดภัย.

Security Champions คือบุคคลในทีมพัฒนาที่สนใจด้านความปลอดภัยของผลิตภัณฑ์ของคุณ

Security Champion เป็นจุดเริ่มต้นในทีมพัฒนาและผู้เผยแพร่ด้านความปลอดภัยที่รวมเป็นหนึ่งเดียว

โดยปกติแล้ว เมื่อผู้เชี่ยวชาญด้านความปลอดภัยมาที่ทีมพัฒนาและชี้ให้เห็นข้อผิดพลาดในโค้ด เขาจะได้รับคำตอบที่น่าประหลาดใจ:

- แล้วคุณเป็นใคร? ฉันได้พบคุณเป็นครั้งแรก ทุกอย่างเรียบร้อยดีสำหรับฉัน - เพื่อนรุ่นพี่ให้ฉัน "สมัคร" ในการตรวจสอบโค้ด เราก็เดินหน้าต่อไป!

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

นอกจากนี้นักพัฒนายังรู้รหัสของตนดีกว่าผู้เชี่ยวชาญด้านความปลอดภัยใดๆ สำหรับผู้ที่มีอย่างน้อย 5 โปรเจ็กต์ในเครื่องมือวิเคราะห์แบบคงที่ มักจะจำความแตกต่างทั้งหมดได้ยาก ผู้เชี่ยวชาญด้านความปลอดภัยรู้จักผลิตภัณฑ์ของตน: อะไรโต้ตอบกับอะไรและสิ่งที่ควรพิจารณาเป็นอันดับแรก - สิ่งเหล่านี้มีประสิทธิภาพมากกว่า

ดังนั้นให้พิจารณาใช้ Security Champions และขยายอิทธิพลของทีมรักษาความปลอดภัยของคุณ สิ่งนี้ยังมีประโยชน์สำหรับตัวแชมป์เองด้วย: การพัฒนาทางวิชาชีพในสาขาใหม่ การขยายขอบเขตทางเทคนิคของเขา การยกระดับทักษะด้านเทคนิค การจัดการและความเป็นผู้นำ การเพิ่มมูลค่าตลาด นี่คือองค์ประกอบบางส่วนของวิศวกรรมสังคม ซึ่งเป็น "สายตา" ของคุณในทีมพัฒนา

ขั้นตอนการทดสอบ

รูปแบบที่ 20 ถึง 80 กล่าวว่าความพยายาม 20% ก่อให้เกิดผลลัพธ์ 80% 20% นี้เป็นแนวทางปฏิบัติในการวิเคราะห์แอปพลิเคชันที่สามารถและควรเป็นแบบอัตโนมัติ ตัวอย่างของกิจกรรมดังกล่าว ได้แก่ การวิเคราะห์แบบคงที่ - SAST, การวิเคราะห์แบบไดนามิก - DAST и การควบคุมโอเพ่นซอร์ส. ฉันจะบอกคุณเพิ่มเติมเกี่ยวกับกิจกรรมต่างๆ รวมถึงเครื่องมือต่างๆ คุณสมบัติที่เรามักจะพบเมื่อแนะนำพวกเขาเข้าสู่กระบวนการ และวิธีดำเนินการอย่างถูกต้อง

ปัญหาหลักของเครื่องมือ

ฉันจะเน้นปัญหาที่เกี่ยวข้องกับเครื่องมือทั้งหมดและต้องได้รับการดูแล ฉันจะวิเคราะห์รายละเอียดเพิ่มเติมเพื่อไม่ให้เกิดซ้ำอีก

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

ผลลบลวงระดับสูงหรือผลบวกลวง ผลิตภัณฑ์ทั้งหมดมีความแตกต่างกัน ทั้งหมดใช้เฟรมเวิร์กที่แตกต่างกันและสไตล์การเขียนโค้ดของตัวเอง บนโค้ดเบสและเทคโนโลยีที่แตกต่างกัน เครื่องมืออาจแสดงระดับ False Negative และ False Positive ที่แตกต่างกัน ดังนั้นดูว่ามีอะไรอยู่ในนั้นบ้าง ของคุณ บริษัทและเพื่อ ของคุณ แอปพลิเคชันจะแสดงผลลัพธ์ที่ดีและเชื่อถือได้

ไม่มีการผสานรวมกับเครื่องมือที่มีอยู่. ดูเครื่องมือในแง่ของการบูรณาการกับสิ่งที่คุณใช้อยู่แล้ว ตัวอย่างเช่น หากคุณมี Jenkins หรือ TeamCity ให้ตรวจสอบการรวมเครื่องมือเข้ากับซอฟต์แวร์นี้ ไม่ใช่กับ GitLab CI ที่คุณไม่ได้ใช้

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

ไม่มีแผนงานการพัฒนาผลิตภัณฑ์ การพัฒนาไม่หยุดนิ่ง เราใช้เฟรมเวิร์กและฟังก์ชันใหม่อยู่เสมอ เขียนโค้ดเก่าเป็นภาษาใหม่อยู่เสมอ เราต้องการให้แน่ใจว่าเครื่องมือที่เราซื้อจะรองรับเฟรมเวิร์กและเทคโนโลยีใหม่ๆ ดังนั้นสิ่งสำคัญคือต้องรู้ว่าสินค้ามีจริงและถูกต้อง แผนงาน การพัฒนา.

คุณสมบัติกระบวนการ

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

เพื่อไม่ให้พลาดกำหนดเวลาการพัฒนาและการเปิดตัว ให้สร้าง กฎที่แตกต่างกัน และแตกต่าง แสดงสิ่งกีดขวาง — เกณฑ์ในการหยุดกระบวนการสร้างเมื่อมีช่องโหว่ — สำหรับสภาพแวดล้อมที่แตกต่างกัน. ตัวอย่างเช่น เราเข้าใจว่าสาขาปัจจุบันไปที่จุดพัฒนาหรือ UAT ซึ่งหมายความว่าเราจะไม่หยุดและพูดว่า:

“ คุณมีช่องโหว่ที่นี่ คุณจะไม่ไปไหนอีกแล้ว!”

ณ จุดนี้ สิ่งสำคัญคือต้องแจ้งนักพัฒนาว่ามีปัญหาด้านความปลอดภัยที่ต้องดำเนินการ

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

- พวกคุณมีปัญหาโปรดใส่ใจพวกเขาด้วย

ในขั้นตอน UAT เราจะแสดงคำเตือนเกี่ยวกับช่องโหว่อีกครั้ง และในขั้นตอนการเผยแพร่เราจะพูดว่า:

- พวกคุณ เราเตือนคุณหลายครั้งแล้ว คุณไม่ได้ทำอะไรเลย - เราจะไม่ปล่อยให้คุณทำสิ่งนี้

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

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

ปัญหาคุณภาพของซอฟต์แวร์ไม่ใช่ปัญหาด้านความปลอดภัยทั้งหมด แต่ปัญหาด้านความปลอดภัยทั้งหมดเกี่ยวข้องกับคุณภาพของซอฟต์แวร์ เชอรีฟ มานซูร์, เอ็กซ์พีเดีย

เนื่องจากช่องโหว่ทั้งหมดมีข้อบกพร่องเหมือนกัน จึงควรอยู่ในตำแหน่งเดียวกับข้อบกพร่องในการพัฒนาทั้งหมด ดังนั้น ลืมรายงานและ PDF ที่น่ากลัวที่ไม่มีใครอ่านได้เลย

ตอนที่ฉันทำงานที่บริษัทพัฒนา ฉันได้รับรายงานจากเครื่องมือวิเคราะห์แบบคงที่ ฉันเปิดมัน ตกใจมาก ชงกาแฟ พลิกไป 350 หน้า ปิดแล้วทำงานต่อ รายงานใหญ่คือรายงานที่ตายแล้ว. โดยปกติแล้วพวกเขาจะไม่ไปไหน จดหมายจะถูกลบ ลืม สูญหาย หรือธุรกิจบอกว่ายอมรับความเสี่ยง

จะทำอย่างไร? เราเพียงแค่แปลงข้อบกพร่องที่ยืนยันแล้วที่เราพบเป็นรูปแบบที่สะดวกสำหรับการพัฒนา เช่น เราใส่ไว้ใน Backlog ใน Jira เราจัดลำดับความสำคัญของข้อบกพร่องและกำจัดตามลำดับความสำคัญ ควบคู่ไปกับข้อบกพร่องด้านการทำงานและข้อบกพร่องในการทดสอบ

การวิเคราะห์แบบคงที่ - SAST

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

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

cons - นี่คือการขาดการรองรับภาษาที่จำเป็น

การบูรณาการที่จำเป็น ซึ่งควรอยู่ในเครื่องมือตามความเห็นส่วนตัวของฉัน:

• เครื่องมือบูรณาการ: Jenkins, TeamCity และ Gitlab CI
• สภาพแวดล้อมการพัฒนา: Intellij IDEA, Visual Studio จะสะดวกกว่าสำหรับนักพัฒนาที่จะไม่สำรวจอินเทอร์เฟซที่เข้าใจยากซึ่งยังต้องจดจำ แต่เพื่อดูการบูรณาการและช่องโหว่ที่จำเป็นทั้งหมดที่เขาพบในที่ทำงานในสภาพแวดล้อมการพัฒนาของเขาเอง
• การตรวจสอบโค้ด: SonarQube และการตรวจสอบด้วยตนเอง
• ตัวติดตามข้อบกพร่อง: จิราและบักซิลล่า

รูปภาพแสดงตัวแทนที่ดีที่สุดของการวิเคราะห์แบบคงที่

ไม่ใช่เครื่องมือที่สำคัญ แต่เป็นกระบวนการ ดังนั้นจึงมีโซลูชัน Open Source ที่ดีสำหรับการทดสอบกระบวนการด้วย

SAST Open Source จะไม่พบช่องโหว่หรือ DataFlows ที่ซับซ้อนจำนวนมาก แต่สามารถและควรใช้เมื่อสร้างกระบวนการ ช่วยให้เข้าใจว่ากระบวนการจะถูกสร้างขึ้นอย่างไร ใครจะตอบสนองต่อจุดบกพร่อง ใครจะรายงาน และใครจะรายงาน หากคุณต้องการดำเนินการในระยะเริ่มแรกของการสร้างความปลอดภัยของโค้ดของคุณ ให้ใช้โซลูชัน Open Source

สิ่งนี้จะบูรณาการได้อย่างไร หากคุณอยู่ที่จุดเริ่มต้นของการเดินทางและไม่มีอะไรเลย: ไม่มี CI, ไม่มี Jenkins, ไม่มี TeamCity ลองพิจารณาบูรณาการเข้าสู่กระบวนการ

การบูรณาการระดับ CVS

หากคุณมี Bitbucket หรือ GitLab คุณสามารถบูรณาการในระดับนั้นได้ ระบบเวอร์ชันพร้อมกัน.

ตามเหตุการณ์ - ดึงคำขอ, กระทำ คุณสแกนโค้ดและสถานะบิลด์จะแสดงว่าการตรวจสอบความปลอดภัยผ่านหรือล้มเหลว

ข้อเสนอแนะ. แน่นอนว่าจำเป็นต้องมีคำติชมอยู่เสมอ หากคุณเพิ่งรักษาความปลอดภัยด้านข้างให้ใส่มันลงในกล่องและไม่ได้บอกใครเกี่ยวกับเรื่องนี้เลย จากนั้นเมื่อสิ้นเดือนก็ทิ้งข้อบกพร่องมากมาย - นี่ไม่ถูกต้องและไม่ดี

บูรณาการกับระบบตรวจสอบรหัส

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

บูรณาการกับ SonarQube

หลายคนมี ประตูคุณภาพ ในแง่ของคุณภาพของรหัส ที่นี่ก็เหมือนกัน - คุณสามารถสร้างเกตเดียวกันได้สำหรับเครื่องมือ SAST เท่านั้น จะมีอินเทอร์เฟซเดียวกัน ประตูคุณภาพเดียวกัน เพียงแต่จะถูกเรียกเท่านั้น ประตูรักษาความปลอดภัย. นอกจากนี้ หากคุณมีกระบวนการที่ใช้ SonarQube คุณสามารถรวมทุกอย่างเข้าด้วยกันได้อย่างง่ายดาย

บูรณาการในระดับ CI

ทุกอย่างที่นี่ค่อนข้างง่ายเช่นกัน:

• เทียบเท่ากับการทดสอบอัตโนมัติ, การทดสอบหน่วย
• แบ่งตามขั้นตอนการพัฒนา: dev, ทดสอบ, ผลิตภัณฑ์ อาจมีชุดกฎที่แตกต่างกันหรือเงื่อนไขความล้มเหลวที่แตกต่างกัน: หยุดการชุมนุม อย่าหยุดการชุมนุม
• การเปิดตัวแบบซิงโครนัส/อะซิงโครนัส. เรากำลังรอการสิ้นสุดการทดสอบความปลอดภัยหรือไม่ นั่นคือเราเพิ่งเปิดตัวและเดินหน้าต่อไป จากนั้นเราก็ได้รับสถานะว่าทุกอย่างดีหรือไม่ดี

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

ตัวอย่างเช่น เราทำโปรเจ็กต์ขนาดใหญ่และตัดสินใจว่าตอนนี้เราจะสแกนด้วย SAST - OK เราผลักดันโครงการนี้เข้าสู่ SAST ทำให้เรามีช่องโหว่ถึง 20 รายการ และด้วยการตัดสินใจอย่างเด็ดเดี่ยว เราจึงตัดสินใจว่าทุกอย่างเรียบร้อยดี ช่องโหว่ 000 รายการเป็นหนี้ทางเทคนิคของเรา เราจะใส่หนี้ลงในกล่อง เราจะค่อยๆ เคลียร์มันและเพิ่มข้อบกพร่องให้กับตัวติดตามข้อบกพร่อง มาจ้างบริษัท ทำทุกอย่างด้วยตัวเอง หรือให้ Security Champions ช่วยเรา แล้วหนี้ทางเทคนิคก็จะลดลง

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

ตัวอย่างของประตูรักษาความปลอดภัยคืออะนาล็อกของประตูคุณภาพ ในแง่ของการมีอยู่และจำนวนช่องโหว่ในโค้ด

เราผสานรวมกับ SonarQube - ติดตั้งปลั๊กอินแล้ว ทุกอย่างสะดวกและยอดเยี่ยมมาก

บูรณาการกับสภาพแวดล้อมการพัฒนา

ตัวเลือกการรวม:

• เรียกใช้การสแกนจากสภาพแวดล้อมการพัฒนาก่อนที่จะคอมมิต
• ดูผลลัพธ์
• การวิเคราะห์ผลลัพธ์
• การซิงโครไนซ์กับเซิร์ฟเวอร์

นี่คือลักษณะที่ดูเหมือนว่าจะได้รับผลลัพธ์จากเซิร์ฟเวอร์

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

โอเพนซอร์ส

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

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

การวิเคราะห์โอเพ่นซอร์ส - OSA

เครื่องมือนี้มีสามขั้นตอนใหญ่

ค้นหาช่องโหว่ในห้องสมุด ตัวอย่างเช่น เครื่องมือรู้ว่าเรากำลังใช้ไลบรารีอยู่ และในนั้น CVE หรือมีช่องโหว่ในตัวติดตามข้อบกพร่องที่เกี่ยวข้องกับไลบรารีเวอร์ชันนี้ เมื่อคุณพยายามใช้งาน เครื่องมือจะออกคำเตือนว่าไลบรารีมีช่องโหว่ และแนะนำให้คุณใช้เวอร์ชันอื่นที่ไม่มีช่องโหว่

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

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

คุณสมบัติ:

• นโยบายที่แตกต่างกันสำหรับขั้นตอนการพัฒนาที่แตกต่างกัน
• การตรวจสอบส่วนประกอบในสภาพแวดล้อมทางอุตสาหกรรม
• การควบคุมห้องสมุดภายในองค์กร
• รองรับระบบบิลด์และภาษาต่างๆ
• การวิเคราะห์ภาพนักเทียบท่า

ตัวอย่างบางส่วนของผู้นำในอุตสาหกรรมที่มีส่วนร่วมในการวิเคราะห์โอเพ่นซอร์ส

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

บูรณาการกระบวนการ

การควบคุมปริมณฑลของห้องสมุดซึ่งดาวน์โหลดจากแหล่งภายนอก เรามีที่เก็บข้อมูลภายนอกและภายใน ตัวอย่างเช่น Event Central ใช้งาน Nexus และเราต้องการให้แน่ใจว่าไม่มีช่องโหว่ภายในพื้นที่เก็บข้อมูลของเราที่มีสถานะ "วิกฤติ" หรือ "สูง" คุณสามารถกำหนดค่าพร็อกซีโดยใช้เครื่องมือ Nexus Firewall Lifecycle เพื่อให้ช่องโหว่ดังกล่าวถูกตัดออกและไม่ไปจบลงที่พื้นที่เก็บข้อมูลภายใน

บูรณาการเข้ากับ CI. ในระดับเดียวกันกับการทดสอบอัตโนมัติ การทดสอบหน่วย และแบ่งออกเป็นขั้นตอนการพัฒนา: dev, test, prod ในแต่ละขั้นตอนคุณสามารถดาวน์โหลดไลบรารีใด ๆ ใช้อะไรก็ได้ แต่หากมีบางสิ่งที่ยากในสถานะ "วิกฤติ" บางทีอาจคุ้มค่าที่จะดึงดูดความสนใจของนักพัฒนาให้มาถึงสิ่งนี้ในขั้นตอนของการเปิดตัวสู่การใช้งานจริง

บูรณาการกับสิ่งประดิษฐ์: เน็กซัส และ เจฟร็อก

บูรณาการเข้ากับสภาพแวดล้อมการพัฒนา เครื่องมือที่คุณเลือกควรมีการผสานรวมกับสภาพแวดล้อมการพัฒนา นักพัฒนาจะต้องสามารถเข้าถึงผลการสแกนจากที่ทำงานของเขา หรือความสามารถในการสแกนและตรวจสอบโค้ดเพื่อหาช่องโหว่ก่อนที่จะตัดสินใจ CVS

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

เรามี ที่เก็บคอมโพเนนต์สาธารณะ — เครื่องมือบางอย่างภายนอก และที่เก็บข้อมูลภายในของเรา เราต้องการให้มีเพียงส่วนประกอบที่เชื่อถือได้เท่านั้น เมื่อพร็อกซีคำขอ เราจะตรวจสอบว่าไลบรารีที่ดาวน์โหลดไม่มีช่องโหว่ หากอยู่ภายใต้นโยบายบางอย่างที่เรากำหนดและจำเป็นต้องประสานงานกับการพัฒนา เราจะไม่อัปโหลดและได้รับแจ้งให้ใช้เวอร์ชันอื่น ดังนั้น หากมีบางสิ่งที่สำคัญและไม่ดีในไลบรารี นักพัฒนาจะไม่ได้รับไลบรารีในขั้นตอนการติดตั้ง - ให้เขาใช้เวอร์ชันที่สูงกว่าหรือต่ำกว่า

• เมื่อสร้าง เราตรวจสอบว่าไม่มีใครทำสิ่งที่ไม่ดีหลุดลอยไป ส่วนประกอบทั้งหมดปลอดภัย และไม่มีใครนำสิ่งที่เป็นอันตรายมาในแฟลชไดรฟ์
• เรามีเฉพาะส่วนประกอบที่เชื่อถือได้ในพื้นที่เก็บข้อมูลเท่านั้น
• เมื่อใช้งาน เราจะตรวจสอบแพ็คเกจอีกครั้ง: war, jar, DL หรืออิมเมจ Docker เพื่อให้แน่ใจว่าเป็นไปตามนโยบาย
• เมื่อเข้าสู่อุตสาหกรรม เราจะติดตามสิ่งที่เกิดขึ้นในสภาพแวดล้อมทางอุตสาหกรรม: ช่องโหว่ที่สำคัญปรากฏขึ้นหรือไม่ปรากฏ

การวิเคราะห์แบบไดนามิก - DAST

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

ระบบเดียวกันนี้ช่วยให้คุณตรวจสอบช่องโหว่ของเทมเพลตในโอเพ่นซอร์สได้ เนื่องจาก DAST ไม่ทราบว่าเราใช้โอเพ่นซอร์สใดอยู่ มันก็เพียงแค่ส่งรูปแบบ “ที่เป็นอันตราย” และวิเคราะห์การตอบสนองของเซิร์ฟเวอร์:

- ใช่ มีปัญหาการดีซีเรียลไลเซชันที่นี่ แต่ไม่ใช่ที่นี่

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

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

เรามีสถานการณ์เมื่อเราเปิดตัว AppScan ในที่สุด: เราใช้เวลานานในการพยายามเข้าถึงแอปพลิเคชัน มี 3 บัญชีและยินดีเป็นอย่างยิ่ง - ในที่สุดเราจะตรวจสอบทุกอย่าง! เราเปิดตัวการสแกน และสิ่งแรกที่ AppScan ทำคือเข้าไปในแผงผู้ดูแลระบบ เจาะปุ่มทั้งหมด เปลี่ยนข้อมูลครึ่งหนึ่ง จากนั้นจึงปิดเซิร์ฟเวอร์โดยสิ้นเชิงด้วย แบบฟอร์มไปรษณีย์-คำขอ การพัฒนาพร้อมการทดสอบกล่าวว่า:

- พวกคุณล้อเล่นฉันเหรอ! เราให้บัญชีแก่คุณแล้ว และคุณก็ตั้งจุดยืน!

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

การพิจารณาว่าคุณสามารถใช้สิ่งนี้เป็นการทดสอบโหลดแบบอะนาล็อกได้ ในระยะแรก คุณสามารถเปิดเครื่องสแกนแบบไดนามิกที่มี 10-15 เธรด และดูว่าเกิดอะไรขึ้น แต่โดยปกติแล้ว ดังที่แสดงให้เห็นในทางปฏิบัติ ไม่มีอะไรดีเลย

แหล่งข้อมูลบางส่วนที่เรามักจะใช้

คุ้มค่าที่จะเน้น เรอ สวีท คือ “มีดสวิส” สำหรับมืออาชีพด้านความปลอดภัย ใครๆ ก็ใช้และสะดวกมาก เวอร์ชันสาธิตใหม่ของรุ่น Enterprise ได้รับการเผยแพร่แล้ว หากก่อนหน้านี้เป็นเพียงยูทิลิตี้แบบสแตนด์อโลนที่มีปลั๊กอิน ตอนนี้นักพัฒนากำลังสร้างเซิร์ฟเวอร์ขนาดใหญ่ในที่สุด ซึ่งจะสามารถจัดการเอเจนต์หลายตัวได้ มันเจ๋งมาก ฉันขอแนะนำให้คุณลอง

บูรณาการกระบวนการ

การบูรณาการเกิดขึ้นได้ค่อนข้างดีและง่ายดาย: เริ่มการสแกนหลังจากการติดตั้งสำเร็จ แอปพลิเคชันสำหรับขาตั้งและ การสแกนหลังจากการทดสอบการบูรณาการสำเร็จ.

หากการบูรณาการใช้งานไม่ได้หรือมีฟังก์ชั่นสตับและจำลอง ก็ไม่มีประโยชน์และไม่มีประโยชน์ ไม่ว่าเราจะส่งรูปแบบใดก็ตาม เซิร์ฟเวอร์จะยังคงตอบสนองในลักษณะเดียวกัน

• ตามหลักการแล้ว ควรมีแท่นทดสอบแยกต่างหาก
• ก่อนการทดสอบ ให้จดลำดับการเข้าสู่ระบบ
• การทดสอบระบบบริหารจัดการเป็นแบบแมนนวลเท่านั้น

กระบวนการ

อธิบายเล็กน้อยเกี่ยวกับกระบวนการโดยทั่วไปและเกี่ยวกับการทำงานของแต่ละเครื่องมือโดยเฉพาะ แอปพลิเคชันทั้งหมดแตกต่างกัน - แอปพลิเคชันหนึ่งทำงานได้ดีกว่ากับการวิเคราะห์แบบไดนามิก อีกแอปพลิเคชันหนึ่งใช้การวิเคราะห์แบบคงที่ แอปพลิเคชันที่สามด้วยการวิเคราะห์ OpenSource, Pentest หรืออย่างอื่นทั้งหมด เช่น เหตุการณ์ที่มี Waf.

ทุกกระบวนการต้องมีการควบคุม

เพื่อทำความเข้าใจวิธีการทำงานของกระบวนการและจุดที่สามารถปรับปรุงได้ คุณต้องรวบรวมตัวชี้วัดจากทุกสิ่งที่คุณสามารถทำได้ รวมถึงตัวชี้วัดการผลิต ตัวชี้วัดจากเครื่องมือ และจากตัวติดตามข้อบกพร่อง

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

เนื่องจากเครื่องวิเคราะห์แบบคงที่และไดนามิกทั้งหมดมี API ของตัวเอง วิธีการเปิดใช้งาน หลักการของตนเอง บางตัวมีตัวกำหนดเวลา ส่วนบางตัวไม่มี - เรากำลังเขียนเครื่องมือ AppSec Orchestratorซึ่งช่วยให้คุณสามารถสร้างจุดเริ่มต้นเดียวในกระบวนการทั้งหมดจากผลิตภัณฑ์และจัดการได้จากจุดเดียว

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

ประเด็นที่สำคัญ

เครื่องมือไม่ใช่สิ่งสำคัญ ขั้นแรกให้คิดตามกระบวนการ - จากนั้นจึงใช้เครื่องมือ เครื่องมือต่างๆ นั้นดีแต่มีราคาแพง ดังนั้นคุณจึงสามารถเริ่มต้นด้วยกระบวนการและสร้างการสื่อสารและความเข้าใจระหว่างการพัฒนาและความปลอดภัยได้ จากมุมมองด้านความปลอดภัย ไม่จำเป็นต้อง "หยุด" ทุกอย่าง จากมุมมองของการพัฒนา หากมีบางสิ่งที่มีความสำคัญอย่างยิ่งยวดขนาดใหญ่ก็จะต้องกำจัดออกไป และไม่เมินเฉยต่อปัญหา

คุณภาพของผลิตภัณฑ์ - เป้าหมายร่วมกัน ทั้งความปลอดภัยและการพัฒนา เราทำสิ่งหนึ่ง เราพยายามให้แน่ใจว่าทุกอย่างทำงานได้อย่างถูกต้อง และไม่มีความเสี่ยงด้านชื่อเสียงหรือการสูญเสียทางการเงิน นี่คือเหตุผลที่เราส่งเสริมแนวทาง DevSecOps, SecDevOps เพื่อปรับปรุงการสื่อสารและปรับปรุงคุณภาพของผลิตภัณฑ์

เริ่มจากสิ่งที่คุณมีอยู่แล้ว: ข้อกำหนด สถาปัตยกรรม การตรวจสอบบางส่วน การฝึกอบรม แนวปฏิบัติ ไม่จำเป็นที่จะต้องนำแนวทางปฏิบัติทั้งหมดไปใช้กับทุกโครงการในทันที - ย้ายซ้ำ. ไม่มีมาตรฐานเดียว - การทดลอง และลองใช้แนวทางและแนวทางแก้ไขที่แตกต่างกัน

มีสัญญาณที่เท่าเทียมกันระหว่างข้อบกพร่องด้านความปลอดภัยของข้อมูลและข้อบกพร่องในการทำงาน.

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

หากขนาดของทีม IS มีขนาดเล็ก - ใช้ Security Champions.

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

ข้อกำหนดสำหรับเครื่องมือ

• ผลบวกลวงระดับต่ำ
• เวลาวิเคราะห์ที่เพียงพอ
• ใช้งานง่าย
• ความพร้อมใช้งานของการบูรณาการ
• ทำความเข้าใจแผนงานการพัฒนาผลิตภัณฑ์
• ความเป็นไปได้ในการปรับแต่งเครื่องมือ

รายงานของ Yuri ได้รับเลือกให้เป็นหนึ่งในรายงานที่ดีที่สุดใน DevOpsConf 2018 หากต้องการทำความคุ้นเคยกับแนวคิดที่น่าสนใจและกรณีปฏิบัติเพิ่มเติม มาที่ Skolkovo ในวันที่ 27 และ 28 พฤษภาคม DevOpsConf ภายใน เทศกาล RIT++. ยังดีกว่าถ้าคุณพร้อมที่จะแบ่งปันประสบการณ์ของคุณแล้ว นำมาใช้ สำหรับรายงานจนถึงวันที่ 21 เมษายน

ที่มา: will.com