สร้างโปรแกรมความปลอดภัยจากศูนย์
บทความเชิงปฏิบัติเกี่ยวกับการสร้างหน้าที่ด้านความปลอดภัยขึ้นที่บริษัทที่ไม่มีระบบใด ครอบคลุมความสำคัญของ ตัวเลือกเครื่องมือ และช่วงชัยชนะที่รวดเร็ว
การถูกจ้างเป็นบุคคลด้านความปลอดภัยคนแรกของบริษัทเป็นเรื่องวุ่นวายประเภทหนึ่งที่เฉพาะเจาะจง ไม่มีคิว ticket ไม่มีเครื่องมือที่ก่อตั้งขึ้นแล้ว และโดยปกติไม่มีบัджเตอร์รอคุณ สิ่งต่อไปนี้คือแผนที่คร่าวๆ ของวิธีที่ 90-180 วันแรกโดยทั่วไปดำเนินไป และสิ่งที่สามารถเปลี่ยนสถานการณ์ได้จริงเปรียบเทียบกับสิ่งที่รู้สึกผลงานเพียงอย่างเดียว
ความหมายของ "ไม่มีอะไรเลย" โดยปกติ
เมื่อคนบอกว่าบริษัทไม่มีหน้าที่ด้านความปลอดภัย พวกเขาแทบจะไม่ได้หมายความว่าไม่มีการควบคุมเลย พวกเขาหมายความว่าไม่มีเจ้าของหน้าที่โดยเฉพาะ Engineering น่าจะเปิดใช้นโยบาย AWS IAM พื้นฐาน IT มีแอนตี้ไวรัสบางตัวที่ใช้งานได้ผ่านเครื่องมือ MDM และมีคนในแผนกการเงินที่มีความเห็นเกี่ยวกับ SOC 2 เพราะลูกค้าถามมา งานแรกของคุณคือสินค้าคงคลัง ไม่ใช่การดำเนินการ ก่อนเขียนนโยบายแม้แต่อย่างเดียว ตรวจสอบว่ามีอะไรทำงานอยู่แล้ว บัญชี cloud (และจำนวนที่ไม่มีใครจำได้ว่าสร้าง) เครื่องมือ SaaS ที่มีสิทธิ์ผู้ดูแลระบบในการเข้าถึงซอร์สโค้ด และว่ามี source of truth เพียงอันเดียวสำหรับการลาออกของพนักงาน Spreadsheet ก็พอได้ สแต่ดูแลระบบ GRC ไม่ใช่ความสำคัญเหลือเท่านี้
30 วันแรก: ความมองเห็นเหนือการควบคุม
ต้านทานความต้องการที่จะเขียนนโยบายการใช้งานที่ยอมรับได้ในสัปดาห์แรก ไม่มีใครจะอ่านมันและมันจะไม่หยุดความเสี่ยงที่แท้จริง แต่เพื่อให้ได้ความมองเห็นของสิ่งสามอย่าง:
- Identity: ดึงรายชื่อผู้ใช้แบบเต็มจากผู้ให้บริการ identity ของคุณ (Okta, Google Workspace, Azure AD) และอ้างอิงข้ามกับรายชื่อพนักงานที่ใช้งานอยู่ของ HR คุณจะพบบัญชี幽霊
- Cloud footprint: เรียกใช้สิ่งเช่น
aws organizations list-accountsถ้าคุณใช้ AWS หรือตรวจสอบ GCP's Asset Inventory เพื่อดูว่ามีสภาพแวดล้อมจำนวนเท่าใดกว่าจำนวนที่ใครคนหนึ่งสามารถตั้งชื่อจากหน่วยความจำ - Code and secrets exposure: เรียกใช้
gitleaks detectหรือtrufflehog filesystem .เทียบกับ repos หลักของคุณ การค้นหากุญแจ API hardcoded ในประวัติ commit จากสองปีที่แล้วแทบจะเป็นไปได้แน่นอนและเป็นวิธีที่รวดเร็วในการแสดงมูลค่า
จดเอกสารการค้นหา แต่ไม่ต้องเปลี่ยนสิ่งนี้เป็นรายงาน 40 หน้าที่ไม่มีใครเปิด สรุปความเสี่ยงหนึ่งหน้ากับห้าสัญพจน์ได้รับการอ่านโดย CTO รายงาน PDF ยาว ๆ ไม่ได้
เลือกการควบคุมสามอย่างแรกของคุณ
เมื่อไม่มีจำนวนพนักงานและไม่มีงบประมาณเครื่องมือ คุณไม่สามารถทำทุกอย่างในครั้งเดียว ลำดับการทำงานที่มักใช้ได้:
- MFA ทุกที่ที่มันยังไม่มี เริ่มต้นด้วยผู้ให้บริการตัวตน แล้ว GitHub/GitLab แล้ว cloud consoles หากเพียงสิ่งเดียวนี้ก็ปิดเส้นทางการเข้าครอบครัวของบัญชีที่พบบ่อยที่สุด
- Centralized logging สำหรับ cloud และ auth events. แม้แต่เสรีระดับของเครื่องมือ SIEM-adjacent หรือเพียงแค่ส่ง CloudTrail/GCP audit logs ไปยัง bucket ที่มีการเก็บไว้นั้นดีกว่าการไม่มีอะไรเมื่อเกิดเหตุการณ์
- แผนการตอบสนองต่อเหตุการณ์ที่เขียนไว้และสั้น แม้ว่ามันจะเป็นสองหน้า: ใครจะเรียก ใครพูดคุยกับลูกค้า ใครมีอำนาจที่จะปิดบางสิ่ง ไม่มีใครจำไว้ว่าจะสร้างนี้จนวันที่พวกเขาต้องการ และในขณะนั้นมันสายเกินไปแล้ว
สังเกตว่าไม่มีสิ่งใดเหล่านี้ต้องการสัญญาผู้ขายขนาดใหญ่ พวกเขาต้องการการตัดสินใจและการติดตามผล
รับความเห็นชอบโดยไม่มีบัดจเตะด้านความปลอดภัย
วิธีที่เร็วที่สุดที่จะสูญเสียความเชื่อถือได้เป็นการจ้างความปลอดภัยครั้งแรกคือการแสดงขึ้นมากับรายการต้องการเครื่องมือก่อนแสดงผลลัพธ์ใด ๆ แทนที่จะเชื่อมโยงทุกคำขอกับสิ่งที่เป็นรูปธรรม: "เราพบผู้ใช้ IAM สามคนที่มีกุญแจการเข้าถึงที่ไม่หมุนเวียนตั้งแต่ปี 2021" ลงจอดได้ดีกว่า "เราต้องการเครื่องมือ CSPM" เฟรมคำขอในแง่ที่ Engineering และการเงินเข้าใจแล้ว: ลดรัศมีระเบิด สนับสนุน audits เร็วขึ้น น้อยลง 2 หน้าวินาที ถ้าบริษัทกำลังไล่ตาม SOC 2 หรือ ISO 27001 เป้าหมายการปฏิบัติตามกฎระเบียบนั้นมักเป็นจุดบิดที่ดีที่สุดของคุณสำหรับการได้รับทรัพยากร แม้ว่าการปฏิบัติตามกฎระเบียบเองไม่ใช่เป้าหมาย
ความผิดพลาดทั่วไปในปีแรก
การซื้อแพลตฟอร์มแพง (SIEM, EDR, CSPM) ก่อนที่คุณจะมีกระบวนการหรือจำนวนพนักงานที่จะดำเนินการจริงคือการสูญเสียงบประมาณในช่วงต้นที่พบบ่อยที่สุด เครื่องมือ $ 50k ที่ไม่มีใครปรับแต่งสร้างเสียงรบกวน ไม่ใช่การตรวจจับ ในทำนองเดียวกัน การเขียนนโยบายที่คัดลอกมาจากเทมเพลตโดยไม่ปรับให้เข้ากับวิธีการทำงานของบริษัท รับประกันว่าจะถูกละเลยครั้งแรกที่มีคนต้องการข้อยกเว้น และพยายามเป็นเจ้าของทุกอย่างเพียงลำพังในหกเดือนแรกเป็นเส้นทางเอาไม่ไหว ช่วงเวลาที่มีจังหวะ การจ้างครั้งต่อไปควรเป็นคนที่สามารถเป็นเจ้าของการตรวจจับและการตอบสนองเพื่อให้คุณสามารถก่อสร้างโครงสร้างโปรแกรมต่อไป
ความปลอดภัยจากศูนย์ส่วนใหญ่เกี่ยวกับการจัดลำดับ: ดูว่ามีอะไรอยู่ ปิดช่องว่างที่ดังที่สุด สร้างกระบวนการเพียงพอที่การตัดสินใจไม่เชื่อพึ่งความจำของคุณ และขยายจากที่นั่น
ถ้าการสร้างโปรแกรมระดับพื้นดินประเภทนี้สนใจคุณ Korra Studio มีส่วนที่เกี่ยวข้องเกี่ยวกับพื้นฐานการตอบสนองต่อเหตุการณ์และ cloud security posture ที่จับคู่กันได้ดีกับอันนี้
เขียนด้วยความช่วยเหลือของ AI ตรวจสอบและเผยแพร่โดย Michal Pilch (CISSP), Korra Studio
นี่คือบันทึกหนึ่งจากฐานความรู้ของ Korra Studio — แพลตฟอร์มจับคู่หัวข้อแต่ละหัวข้อกับการฝึกสอนแบบ 1-to-1
เริ่มใช้งานฟรีarrow_forward