AXIS-โลโก้

ซอฟต์แวร์รุ่นพัฒนาระบบรักษาความปลอดภัย AXIS

ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 1

การแนะนำ

วัตถุประสงค์ของ ASDM
Axis Security Development Model (ASDM) เป็นกรอบงานที่กำหนดกระบวนการและเครื่องมือที่ Axis ใช้ในการสร้างซอฟต์แวร์ที่มีระบบความปลอดภัยในตัวตลอดวงจรชีวิต ตั้งแต่เริ่มต้นจนถึงการเลิกใช้งาน

วัตถุประสงค์หลักในการขับเคลื่อนความพยายามของ ASDM คือ

  • ทำให้การรักษาความปลอดภัยซอฟต์แวร์เป็นส่วนหนึ่งที่รวมอยู่ในกิจกรรมการพัฒนาซอฟต์แวร์ของ Axis
  • ลดความเสี่ยงทางธุรกิจที่เกี่ยวข้องกับความปลอดภัยสำหรับลูกค้า Axis
  • Meet increasing awareness of security considerations by customers and partners.
  • สร้างศักยภาพในการลดต้นทุนเนื่องจากการตรวจจับและแก้ไขปัญหาได้ตั้งแต่เนิ่นๆ
    ขอบเขตของ ASDM คือซอฟต์แวร์ Axis ที่รวมอยู่ในผลิตภัณฑ์และโซลูชันของ Axis Software Security Group (SSG) เป็นเจ้าของและผู้ดูแล ASDM

คำศัพท์

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

ASDM จบแล้วview

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

ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 3

The SSG is responsible for governing the ASDM and evolving the toolbox over time. There is an ASDM roadmap and a rollout plan for implementing new activities and increasing ASDM maturity across the development organization. Both the roadmap and rollout plan are owned by the SSG, but the responsibility for actual implementation in practice (i.e., performing activities related to development phases) is delegated to the R&D teams.

กลุ่มความปลอดภัยซอฟต์แวร์ (SSG)

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

ดาวเทียม
ดาวเทียมเป็นสมาชิกขององค์กรพัฒนาที่ใช้เวลาส่วนหนึ่งในการทำงานด้านความปลอดภัยของซอฟต์แวร์ เหตุผลที่ต้องมีดาวเทียมมีดังนี้:

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

การเปิดตัวกิจกรรม ASDM
การเปิดตัวกิจกรรม ASDM ให้กับทีมพัฒนามีดังนี้tagกระบวนการแก้ไข:

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

    ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 4

คำจำกัดความของ SSG ของคำว่า “เสร็จสิ้น” สำหรับการส่งมอบคือ:

  • การฝึกอบรมเฉพาะบทบาทที่ดำเนินการ
  • ดาวเทียมที่ได้รับมอบหมาย
  • ทีมงานพร้อมดำเนินกิจกรรม ASDM
  • การประชุมสถานะ ASDM ที่เกิดขึ้นซ้ำๆ ได้รับการจัดตั้งขึ้น
    SSG ใช้ข้อมูลจากทีมเพื่อรวบรวมรายงานสถานะไปยังผู้บริหารระดับสูง

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

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

บทบาท/ตัวตน ส่วนหนึ่งของ ความรับผิดชอบ ความคิดเห็น
ผู้เชี่ยวชาญด้านความปลอดภัย สสส. บริหาร ASDM พัฒนาเครื่องมือและขับเคลื่อนการเปิดตัว ASDM มอบหมายให้ SSG 100%
ดาวเทียม สายพัฒนา ช่วยให้ SSG นำ ASDM มาใช้ในครั้งแรก ฝึกสอนทีม จัดการฝึกอบรม และให้แน่ใจว่าทีมสามารถใช้ Toolbox ต่อไปได้ในฐานะส่วนหนึ่งของงานประจำวัน โดยไม่ต้องพึ่ง SSG ความรับผิดชอบร่วมกันของทีม (หลายทีม) จำเป็นต้องจำกัดจำนวนดาวเทียมทั้งหมด นักพัฒนา สถาปนิก ผู้จัดการ นักทดสอบ และผู้ที่มีบทบาทคล้ายคลึงกันที่สนใจและมีส่วนร่วมซึ่งมีความสัมพันธ์ตามธรรมชาติกับความปลอดภัยของซอฟต์แวร์ ดาวเทียมจัดสรรเวลาอย่างน้อย 20% ให้กับงานที่เกี่ยวข้องกับ ASDM
ผู้จัดการ สายพัฒนา จัดหาทรัพยากรสำหรับการนำแนวทางปฏิบัติ ASDM ไปปฏิบัติ ติดตามและรายงานสถานะและความครอบคลุมของ ASDM ทีมพัฒนาเป็นเจ้าของการนำ ASDM ไปใช้ โดยมี SSG เป็นแหล่งทรัพยากรสนับสนุน
กลุ่มควบคุมเฟิร์มแวร์ (FW SG) การจัดการวิจัยและพัฒนา ตัดสินใจเกี่ยวกับกลยุทธ์ด้านความปลอดภัยและทำหน้าที่เป็นช่องทางการรายงานหลักของ SSG SSG รายงานต่อ FW SG เป็นประจำ

การกำกับดูแล ASDM

ระบบการกำกับดูแลประกอบด้วยส่วนต่าง ๆ ดังต่อไปนี้:

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

ดังนั้นระบบ ASDM จึงได้รับการสนับสนุนจากทั้งมุมมองเชิงยุทธวิธี/ปฏิบัติการ และมุมมองเชิงกลยุทธ์/ฝ่ายบริหาร
คำแนะนำของผู้บริหารทางด้านขวาของภาพเน้นที่วิธีการพัฒนาองค์กรให้มีประสิทธิภาพสูงสุดตามเป้าหมายทางธุรกิจของ Axis ข้อมูลสำคัญที่นำมาใช้ในเรื่องนี้ก็คือการรายงานสถานะ ASDM ที่ดำเนินการโดย SSG ต่อกลุ่มกำกับดูแลเฟิร์มแวร์ CTO และการจัดการผลิตภัณฑ์

ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 5

โครงสร้างสถานะ ASDM

โครงสร้างสถานะ ASDM มีมุมมองสองแบบ: มุมมองหนึ่งเน้นไปที่ทีมงานซึ่งเลียนแบบโครงสร้างทีมและแผนกของเรา และอีกมุมมองหนึ่งเน้นไปที่โซลูชันซึ่งมุ่งเน้นไปที่โซลูชันที่เรานำเสนอสู่ตลาด
ภาพด้านล่างแสดงโครงสร้างสถานะ ASDM

สถานะทีม
สถานะทีมมีองค์ประกอบของการประเมินตนเองของทีมเกี่ยวกับความพร้อมของ ASDM เมตริกที่เกี่ยวข้องกับกิจกรรมการวิเคราะห์ความปลอดภัย ตลอดจนการรวบรวมสถานะความปลอดภัยของส่วนประกอบที่พวกเขารับผิดชอบ

ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 6

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

เวอร์ชัน ASDM กิจกรรมใหม่ ๆ
ASDM1.0 การประเมินความเสี่ยงและการสร้างแบบจำลองภัยคุกคาม
ASDM2.0 รหัสคงที่view
ASDM2.1 ความเป็นส่วนตัวโดยการออกแบบ
ASDM2.2 การวิเคราะห์องค์ประกอบของซอฟต์แวร์
ASDM2.3 การทดสอบการเจาะทะลุภายนอก
ASDM2.4 การสแกนช่องโหว่และการฝึกซ้อมดับเพลิง
ASDM2.5 สถานะความปลอดภัยของผลิตภัณฑ์/โซลูชัน

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

สถานะส่วนประกอบ

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

เราเรียกการคุ้มครองทรัพย์สินนี้ว่า และได้กำหนดระดับการคุ้มครองดังต่อไปนี้:

ความครอบคลุม คำอธิบาย
การวิเคราะห์ไม่ได้ทำ ส่วนประกอบยังไม่ได้รับการวิเคราะห์
การวิเคราะห์กำลังดำเนินอยู่ กำลังวิเคราะห์ส่วนประกอบ
วิเคราะห์เสร็จแล้ว ส่วนประกอบได้รับการวิเคราะห์แล้ว

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

สถานะโซลูชัน

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

กิจกรรม ASDM

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

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

  • ปฏิบัติตามภาระผูกพันทางกฎหมาย
  • ปฏิบัติตามภาระผูกพันตามสัญญา
  • ช่วยให้ลูกค้าปฏิบัติตามภาระผูกพันของตน

เราแบ่งกิจกรรมความเป็นส่วนตัวของข้อมูลออกเป็นสองกิจกรรมย่อย:

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

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

ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 7

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

    ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 8

การสร้างแบบจำลองภัยคุกคามมีสามขั้นตอนที่สามารถทำซ้ำได้ตามที่ทีมเห็นว่าเหมาะสม:

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

    ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 9

การวิเคราะห์โค้ดแบบคงที่
ใน ASDM ทีมสามารถใช้การวิเคราะห์โค้ดคงที่ได้สามวิธี:

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

    ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 10

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

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

การจัดการความเสี่ยง
ตั้งแต่ปี 2021 Axis ได้เป็นหน่วยงานที่จดทะเบียนชื่อ CVE (CNA) และสามารถเผยแพร่รายงาน CVE มาตรฐานไปยังฐานข้อมูล MITRE เพื่อให้โปรแกรมสแกนช่องโหว่ของบุคคลที่สามและเครื่องมืออื่นๆ ใช้งานได้ กระดานช่องโหว่ (VB) คือจุดติดต่อภายในของ Axis สำหรับช่องโหว่ที่นักวิจัยภายนอกค้นพบ การรายงาน
ช่องโหว่ที่ค้นพบและแผนการแก้ไขที่ตามมาจะได้รับการสื่อสารผ่าน ผลิตภัณฑ์-ความปลอดภัย@axis.com ที่อยู่อีเมล
ความรับผิดชอบหลักของคณะกรรมการด้านความเสี่ยงคือการวิเคราะห์และจัดลำดับความสำคัญของความเสี่ยงที่รายงานจากมุมมองทางธุรกิจโดยอิงจาก

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

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

ซอฟต์แวร์โมเดลการพัฒนาระบบรักษาความปลอดภัย AXIS-รูปที่ 11

แบบจำลองการพัฒนาระบบรักษาความปลอดภัยของ Axis © Axis Communications AB, 2022

เอกสาร / แหล่งข้อมูล

ซอฟต์แวร์รุ่นพัฒนาระบบรักษาความปลอดภัย AXIS [พีดีเอฟ] คู่มือการใช้งาน
โมเดลการพัฒนาระบบรักษาความปลอดภัย ซอฟต์แวร์ โมเดลการพัฒนาระบบรักษาความปลอดภัย

อ้างอิง

ฝากความคิดเห็น

ที่อยู่อีเมลของคุณจะไม่ถูกเผยแพร่ ช่องที่ต้องกรอกข้อมูลมีเครื่องหมาย *