โปรแกรมเมอร์ที่ บริษัท รักษาความปลอดภัยทำอะไร?


10

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


1
รู้สึกฟรีเพื่อค้นหา security.stackexchange.com สำหรับผู้ชมกลุ่มรักษาความปลอดภัยอีกมากมาย!
Rory Alsop

1
สิ่งที่เขาพูดเราเป็นทั้งผู้ดูแลมืออาชีพ

คำตอบ:


12

ตรงไปตรงมาเราพยายามไม่ให้ผ่าน codebase ของคุณเราพยายามเขียนเครื่องมือเพื่อทำสิ่งนั้นเพื่อเรา

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

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

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

ตกลงมากสำหรับทฤษฎี ในทางปฏิบัติสำหรับเหตุผลที่อธิบายได้ดีมาก (ถึงแม้ว่าจะไม่ใช่ในเชิงเทคนิค ) ในGeekonomicsและส่วนใหญ่เป็นเพราะพวกเขามีวิธีที่ บริษัท ซอฟต์แวร์มีแรงจูงใจสิ่งต่าง ๆ ข้างต้นส่วนใหญ่ไม่ได้เกิดขึ้น เราได้สิ่งนี้มาแทน นักพัฒนาจะ:

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

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

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

** คำเตือน: อะไรคือความเห็นส่วนตัวและการเก็งกำไร **

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

คุณในฐานะนักพัฒนาซอฟต์แวร์สามารถทำอะไรได้บ้าง เล่นเกมตามกฎดั้งเดิม ค้นหาใครบางคนในทีมของคุณ (โดยเฉพาะอย่างยิ่งในทีมของคุณมากกว่าผู้รับเหมาเพื่อให้พวกเขามีแรงจูงใจที่จะให้ผลลัพธ์ระยะยาวมากกว่าการชนะอย่างรวดเร็ว) ที่เข้าใจถึงความสำคัญของการรักษาความปลอดภัยและฝึกฝน bejeezus จากพวกเขา ให้ความรับผิดชอบแก่บุคคลนั้นในการกำหนดทีมงานในการจัดหาการรักษาความปลอดภัยแบบ end-to-end ตามที่อธิบายไว้ในตอนต้นของคำตอบของฉัน

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

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

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


สำหรับคนที่อยู่ในตำแหน่งของคุณฉันประหลาดใจที่คุณไม่สามารถเสนอการสนทนาได้มากขึ้น ฉันสนใจที่จะได้ยินสิ่งที่คุณพูด
Steven Evers

คุณพูดถูกฉันเหนื่อย (ล้าหลัง) เมื่อฉันเขียนคำตอบ ฉันจะพยายามเติมให้เต็ม

@snorfus ฉันควรขอโทษที่ไม่ตอบคำถาม ฉันขอโทษจริงๆ

@ Graham Lee: ฉันสงสัยว่าคุณมีคำตอบที่ดีซ่อนอยู่จากเรา :) การแก้ไขของคุณพิสูจน์แล้ว ขอบคุณ!
Steven Evers

@snorfus ฉันควรคิดก่อนโพสต์ และถ้าฉันไม่มีความคิดฉันก็ไม่ควรโพสต์ ...

5

จาก 15 ปีของการรันโปรแกรมรับประกันความปลอดภัยกับแอพขนาดเล็กและใหญ่มาก, สภาพแวดล้อม, ระบบ ฯลฯ ฉันอยากจะบอกว่ามีทุกอย่างเล็กน้อย ในทีมของฉันฉันมักจะมีไม่กี่คนที่เป็นนักเขียนแบบไม่ยอมใครง่ายๆ

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

(เป็นที่ยอมรับจากนั้นฉันส่งมอบให้กับนักพัฒนาซอฟต์แวร์เพื่อแก้ไขหรืออธิบายให้ฉันฟังว่าทำไมปัญหานี้จึงไม่มีความเสี่ยง)

แต่นี่คือการมีส่วนร่วมที่เฉพาะเจาะจงซึ่งความเสี่ยงนั้นเหมาะสมที่จะใช้ทรัพยากรประเภทนี้มาก

มาตรฐานที่มากขึ้นและคุ้มค่ากว่านั้นคือพยายามเข้าใจถึงความเสี่ยงขององค์กรและมุ่งเน้นไปที่ความเสี่ยงจากบนลงล่างเช่น:

  • Risk Appetite - ส่งผลกระทบต่อธุรกิจสร้างแบบจำลองการคุกคาม
  • ธรรมาภิบาล - การปฏิบัติตามกฎระเบียบการรายงาน ฯลฯ
  • นโยบาย - คำจำกัดความเพื่อให้แน่ใจว่ากรอบการกำกับดูแลมีประสิทธิภาพ
  • กระบวนการ - เทคนิคและมนุษย์
  • มาตรฐาน - คำจำกัดความสำหรับการควบคุมความปลอดภัยแต่ละรายการ
  • การดำเนินการ - วิธีการ

ด้านการเขียนโปรแกรมเข้ามาในสองล่าสุดเท่านั้นที่มีการตรวจสอบรหัสและการทดสอบการเจาะที่กำหนดเอง สำหรับบางองค์กรมีความสำคัญต่ำมากตัวอย่างเช่นถ้าคุณมีการควบคุมความปลอดภัยแบบเลเยอร์ที่ได้รับการตรวจสอบอย่างกว้างขวาง (การเข้ารหัสประเภทต่าง ๆ ) แล้วในขณะที่คุณอาจตรวจสอบการใช้งานของคุณคุณจะไม่ตรวจสอบทั้งหมด รหัสตามที่เคยทำมาก่อน


2
ฉัน +1 แต่ระวัง "หรืออธิบายให้ฉันฟังว่าทำไมปัญหานี้จึงไม่ก่อให้เกิดความเสี่ยง" นักพัฒนามักจะหาเหตุผลเพื่อหลีกเลี่ยงการเปลี่ยนแปลงสิ่งที่พวกเขาทำ (พูดในฐานะนักพัฒนา) และนอกจากนี้อาจไม่เข้าใจความเสี่ยงของลูกค้า

@ Graham - คุณบอกว่าไม่ควรตั้งชื่อ :-) และฉันชอบคำตอบเวอร์ชันใหม่ที่ยาวกว่าของคุณ! +1
Rory Alsop

โอ้ใช่. ฉันตั้งใจพูดอย่างนั้นเพราะฉันไม่ต้องการตั้งชื่อ windows 98- แต่ - สาม - สาม - ปีก่อน

1

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

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

ฉันจินตนาการว่ามีบางอย่างที่ใช้เวลาในการตรวจสอบโค้ดและทำการทดสอบการตรวจทาน / การทดสอบกล่องขาว แต่ฉันยังไม่ได้พบพวกเขาในชีวิตจริง


ดูเหมือนว่า บริษัท ที่คุณทำงานด้วยราคาถูกอย่างต่อเนื่องและรับแฮ็กที่พูดคุยกับเกมที่ดี แต่ไม่ได้รับจุด นอกเหนือจากตัวฉันเองและผู้ตอบคำถามอื่น ๆ ที่นี่ฉันได้ทำงานด้วยและได้รับการฝึกฝนมากมายที่ทำได้ถูกต้อง เป็นที่ยอมรับว่าฉันอาจได้พบกับประเภทที่คุณมีอีกด้วย ...
AviD

@ เนื่องจากฉันไม่ได้หมายความว่าเป็นลบ ฉันมั่นใจว่าถ้าคุณจ่ายเงินให้คุณคุณสามารถหา บริษัท คู่แข่งได้พอสมควร แต่ถึงแม้ว่าคุณจะมีข้อเสนอแนะเพิ่มเติมให้ซื้อสินค้ามากกว่าที่คุณจะให้คำแนะนำในการปรับปรุง / ดำเนินการบางอย่าง นั่นไม่ใช่สิ่งที่ไม่ดีที่ใช้ผลิตภัณฑ์ที่รู้จักพร้อมกับบันทึกความปลอดภัยที่ดีจะดีกว่าเมื่อเหมาะสมกับพื้นที่ที่มีปัญหา การตรวจสอบที่กล่าวถึง OP โดยเฉพาะและในช่วงที่คุณชำระเงินสำหรับการตรวจสอบบุคคลที่สามประจำปีของคุณคุณจะได้รับคะแนน 2, 3 และ 1/2 ของคะแนน Rory
บิล
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.