ການສະແກນຄວາມສ່ຽງ ແລະການພັດທະນາທີ່ປອດໄພ. ພາກທີ 1

ເປັນສ່ວນຫນຶ່ງຂອງກິດຈະກໍາທີ່ເປັນມືອາຊີບຂອງພວກເຂົາ, ຜູ້ພັດທະນາ, pentesters, ແລະຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພຕ້ອງຈັດການກັບຂະບວນການຕ່າງໆເຊັ່ນ: Vulnerability Management (VM), (Secure) SDLC.
ພາຍໃຕ້ປະໂຫຍກເຫຼົ່ານີ້ນອນຢູ່ໃນຊຸດການປະຕິບັດທີ່ແຕກຕ່າງກັນແລະເຄື່ອງມືທີ່ໃຊ້ທີ່ຕິດກັນ, ເຖິງແມ່ນວ່າຜູ້ໃຊ້ຂອງພວກເຂົາແຕກຕ່າງກັນ.

ຄວາມຄືບຫນ້າທາງດ້ານເຕັກນິກຍັງບໍ່ທັນຮອດຈຸດທີ່ເຄື່ອງມືຫນຶ່ງສາມາດທົດແທນບຸກຄົນໃນການວິເຄາະຄວາມປອດໄພຂອງໂຄງສ້າງພື້ນຖານແລະຊອບແວ.
ເປັນທີ່ໜ້າສົນໃຈທີ່ຈະເຂົ້າໃຈວ່າເປັນຫຍັງເປັນເຊັ່ນນັ້ນ ແລະບັນຫາໃດທີ່ຄົນເຮົາປະເຊີນ.

ຂະບວນການຕ່າງໆ

ຂະບວນການຄຸ້ມຄອງຊ່ອງໂຫວ່ໄດ້ຖືກອອກແບບມາສໍາລັບການຕິດຕາມຢ່າງຕໍ່ເນື່ອງຂອງຄວາມປອດໄພຂອງໂຄງສ້າງພື້ນຖານແລະການຄຸ້ມຄອງ patch.
ຂະບວນການ SDLC ທີ່ປອດໄພ ("ວົງຈອນການພັດທະນາທີ່ປອດໄພ") ຖືກອອກແບບມາເພື່ອຮັກສາຄວາມປອດໄພຂອງແອັບພລິເຄຊັນໃນລະຫວ່າງການພັດທະນາ ແລະການດໍາເນີນງານ.

ພາກສ່ວນທີ່ຄ້າຍຄືກັນຂອງຂະບວນການເຫຼົ່ານີ້ແມ່ນຂະບວນການປະເມີນຄວາມສ່ຽງ - ການປະເມີນຄວາມອ່ອນແອ, ການສະແກນຊ່ອງໂຫວ່.
ຄວາມແຕກຕ່າງຕົ້ນຕໍລະຫວ່າງການສະແກນ VM ແລະ SDLC ແມ່ນວ່າໃນກໍລະນີທໍາອິດເປົ້າຫມາຍແມ່ນເພື່ອກວດພົບຈຸດອ່ອນທີ່ຮູ້ຈັກໃນຊອບແວພາກສ່ວນທີສາມຫຼືການຕັ້ງຄ່າ. ຕົວຢ່າງເຊັ່ນ Windows ເວີຊັນທີ່ລ້າສະໄຫມຫຼືສາຍຊຸມຊົນເລີ່ມຕົ້ນສໍາລັບ SNMP.
ໃນກໍລະນີທີສອງ, ເປົ້າຫມາຍແມ່ນເພື່ອກວດພົບຄວາມອ່ອນແອບໍ່ພຽງແຕ່ຢູ່ໃນອົງປະກອບຂອງພາກສ່ວນທີສາມ (ການເພິ່ງພາອາໄສ), ແຕ່ຕົ້ນຕໍແມ່ນຢູ່ໃນລະຫັດຂອງຜະລິດຕະພັນໃຫມ່.

ນີ້ສ້າງຄວາມແຕກຕ່າງໃນເຄື່ອງມືແລະວິທີການ. ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ຫນ້າທີ່ຊອກຫາຊ່ອງໂຫວ່ໃຫມ່ໃນແອັບພລິເຄຊັນແມ່ນຫນ້າສົນໃຈຫຼາຍ, ເພາະວ່າມັນບໍ່ໄດ້ລົງໄປໃນສະບັບ fingerprinting, ການລວບລວມປ້າຍໂຄສະນາ, ລະຫັດຜ່ານທີ່ບັງຄັບໃຊ້ brute, ແລະອື່ນໆ.
ສໍາລັບການສະແກນອັດຕະໂນມັດທີ່ມີຄຸນນະພາບສູງຂອງຊ່ອງໂຫວ່ຂອງແອັບພລິເຄຊັນ, algorithms ແມ່ນຕ້ອງການທີ່ຄໍານຶງເຖິງຄວາມຫມາຍຂອງແອັບພລິເຄຊັນ, ຈຸດປະສົງຂອງມັນ, ແລະໄພຂົ່ມຂູ່ສະເພາະ.

ເຄື່ອງສະແກນພື້ນຖານໂຄງລ່າງມັກຈະຖືກແທນທີ່ດ້ວຍເຄື່ອງຈັບເວລາ, ດັ່ງທີ່ຂ້ອຍວາງມັນໄວ້ avleonov. ຈຸດແມ່ນວ່າ, ຕາມສະຖິຕິຢ່າງດຽວ, ທ່ານສາມາດພິຈາລະນາໂຄງສ້າງພື້ນຖານຂອງທ່ານມີຄວາມສ່ຽງຖ້າທ່ານບໍ່ໄດ້ປັບປຸງມັນ, ເວົ້າວ່າ, ເປັນເວລາຫນຶ່ງເດືອນ.

ເຄື່ອງມື

ການສະແກນ, ເຊັ່ນການວິເຄາະຄວາມປອດໄພ, ສາມາດດໍາເນີນການໄດ້ໂດຍໃຊ້ກ່ອງດໍາຫຼືກ່ອງສີຂາວ.

ກ່ອງດໍາ

ເມື່ອການສະແກນ blackbox, ເຄື່ອງມືຈະຕ້ອງສາມາດເຮັດວຽກກັບການບໍລິການໂດຍຜ່ານການໂຕ້ຕອບດຽວກັນໂດຍຜ່ານທີ່ຜູ້ໃຊ້ເຮັດວຽກກັບມັນ.

ເຄື່ອງສະແກນໂຄງສ້າງພື້ນຖານ (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, ແລະອື່ນໆ) ຄົ້ນຫາພອດເຄືອຂ່າຍເປີດ, ເກັບກໍາ "ປ້າຍໂຄສະນາ," ກໍານົດສະບັບຂອງຊອບແວທີ່ຕິດຕັ້ງ, ແລະຄົ້ນຫາພື້ນຖານຄວາມຮູ້ຂອງເຂົາເຈົ້າສໍາລັບຂໍ້ມູນກ່ຽວກັບຄວາມອ່ອນແອໃນສະບັບເຫຼົ່ານີ້. ພວກເຂົາຍັງພະຍາຍາມກວດຫາຄວາມຜິດພາດໃນການຕັ້ງຄ່າເຊັ່ນ: ລະຫັດຜ່ານເລີ່ມຕົ້ນ ຫຼືການເຂົ້າເຖິງຂໍ້ມູນເປີດ, ລະຫັດລັບ SSL ທີ່ອ່ອນແອ, ແລະອື່ນໆ.

ເຄື່ອງສະແກນຄໍາຮ້ອງສະຫມັກເວັບ (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ແລະອື່ນໆ) ຍັງສາມາດກໍານົດອົງປະກອບທີ່ຮູ້ຈັກແລະຮຸ່ນຂອງພວກມັນ (ຕົວຢ່າງ, CMS, frameworks, JS libraries). ຂັ້ນຕອນຕົ້ນຕໍຂອງເຄື່ອງສະແກນແມ່ນການລວບລວມຂໍ້ມູນແລະ fuzzing.
ໃນລະຫວ່າງການລວບລວມຂໍ້ມູນ, ເຄື່ອງສະແກນເກັບກໍາຂໍ້ມູນກ່ຽວກັບການໂຕ້ຕອບຄໍາຮ້ອງສະຫມັກທີ່ມີຢູ່ແລະຕົວກໍານົດການ HTTP. ໃນ​ລະ​ຫວ່າງ​ການ fuzzing, ການ​ປ່ຽນ​ແປງ​ຫຼື​ຂໍ້​ມູນ​ທີ່​ຜະ​ລິດ​ໄດ້​ຖືກ​ໃສ່​ເຂົ້າ​ໄປ​ໃນ​ຕົວ​ກໍາ​ນົດ​ການ​ກວດ​ພົບ​ທັງ​ຫມົດ​ເພື່ອ​ເຮັດ​ໃຫ້​ເກີດ​ຄວາມ​ຜິດ​ພາດ​ແລະ​ກວດ​ພົບ​ຊ່ອງ​ໂຫວ່​ໄດ້​.

ເຄື່ອງສະແກນແອັບພລິເຄຊັນດັ່ງກ່າວເປັນຂອງຫ້ອງຮຽນ DAST ແລະ IAST - ການທົດສອບຄວາມປອດໄພຂອງແອັບພລິເຄຊັນແບບໄດນາມິກ ແລະການໂຕ້ຕອບ, ຕາມລໍາດັບ.

ກ່ອງສີຂາວ

ມີຄວາມແຕກຕ່າງຫຼາຍຂຶ້ນກັບການສະແກນກ່ອງຂາວ.
ເປັນສ່ວນຫນຶ່ງຂອງຂະບວນການ VM, ເຄື່ອງສະແກນ (Vulners, Insecurity Couch, Vuls, Tenable Nessus, ແລະອື່ນໆ) ມັກຈະໄດ້ຮັບການເຂົ້າເຖິງລະບົບຕ່າງໆໂດຍການດໍາເນີນການສະແກນທີ່ມີຄວາມຖືກຕ້ອງ. ດັ່ງນັ້ນ, ເຄື່ອງສະແກນສາມາດດາວໂຫລດເວີຊັນແພັກເກັດທີ່ຕິດຕັ້ງແລະພາລາມິເຕີການຕັ້ງຄ່າໂດຍກົງຈາກລະບົບ, ໂດຍບໍ່ຕ້ອງຄາດເດົາພວກມັນຈາກປ້າຍໂຄສະນາເຄືອຂ່າຍ.
ການສະແກນແມ່ນຖືກຕ້ອງ ແລະຄົບຖ້ວນກວ່າ.

ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບການສະແກນ whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, ແລະອື່ນໆ) ຂອງຄໍາຮ້ອງສະຫມັກ, ຫຼັງຈາກນັ້ນພວກເຮົາມັກຈະເວົ້າກ່ຽວກັບການວິເຄາະລະຫັດສະຖິດແລະການນໍາໃຊ້ເຄື່ອງມືທີ່ເຫມາະສົມຂອງຊັ້ນ SAST - ການທົດສອບຄວາມປອດໄພຂອງຄໍາຮ້ອງສະຫມັກຄົງທີ່.

ບັນຫາ

ມີບັນຫາຫຼາຍກັບການສະແກນ! ຂ້າພະເຈົ້າຕ້ອງຈັດການກັບພວກເຂົາສ່ວນໃຫຍ່ເປັນສ່ວນບຸກຄົນເປັນສ່ວນຫນຶ່ງຂອງການສະຫນອງການບໍລິການສໍາລັບການສະແກນການກໍ່ສ້າງແລະຂະບວນການພັດທະນາທີ່ປອດໄພ, ເຊັ່ນດຽວກັນກັບໃນເວລາທີ່ດໍາເນີນວຽກງານການວິເຄາະຄວາມປອດໄພ.

ຂ້າພະເຈົ້າຈະຍົກໃຫ້ເຫັນ 3 ກຸ່ມຕົ້ນຕໍຂອງບັນຫາ, ເຊິ່ງໄດ້ຮັບການຢືນຢັນໂດຍການສົນທະນາກັບວິສະວະກອນແລະຫົວຫນ້າບໍລິການຄວາມປອດໄພຂໍ້ມູນໃນຫຼາຍໆບໍລິສັດ.

ບັນຫາການສະແກນແອັບພລິເຄຊັນເວັບ

1. ຄວາມຫຍຸ້ງຍາກໃນການປະຕິບັດ. ເຄື່ອງສະແກນຈໍາເປັນຕ້ອງຖືກນໍາມາໃຊ້, ຕັ້ງຄ່າ, ປັບແຕ່ງສໍາລັບແຕ່ລະແອັບພລິເຄຊັນ, ຈັດສັນສະພາບແວດລ້ອມການທົດສອບສໍາລັບການສະແກນແລະປະຕິບັດໃນຂະບວນການ CI / CD ເພື່ອໃຫ້ມີປະສິດທິພາບ. ຖ້າບໍ່ດັ່ງນັ້ນ, ມັນຈະເປັນຂັ້ນຕອນທີ່ເປັນທາງການທີ່ບໍ່ມີປະໂຫຍດທີ່ຈະຜະລິດຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ
2. ໄລຍະເວລາສະແກນ. ເຖິງແມ່ນວ່າໃນປີ 2019, ເຄື່ອງສະແກນເຮັດວຽກທີ່ບໍ່ດີໃນການເຮັດຊ້ໍາການໂຕ້ຕອບແລະສາມາດໃຊ້ເວລາຫຼາຍມື້ເພື່ອສະແກນຫນ້າຫນຶ່ງພັນຫນ້າທີ່ມີ 10 ຕົວກໍານົດການໃນແຕ່ລະ, ພິຈາລະນາພວກເຂົາແຕກຕ່າງກັນ, ເຖິງແມ່ນວ່າລະຫັດດຽວກັນແມ່ນຮັບຜິດຊອບສໍາລັບພວກເຂົາ. ພ້ອມ​ກັນ​ນັ້ນ, ການ​ຕັດສິນ​ໃຈ​ນຳ​ໃຊ້​ເຂົ້າ​ໃນ​ການ​ຜະລິດ​ພາຍ​ໃນ​ວົງ​ຈອນ​ການ​ພັດທະນາ​ກໍ່​ຕ້ອງ​ດຳ​ເນີນ​ຢ່າງ​ວ່ອງ​ໄວ
3. ຄໍາແນະນໍາທີ່ບໍ່ດີ. ເຄື່ອງສະແກນໃຫ້ຄໍາແນະນໍາທົ່ວໄປທີ່ຂ້ອນຂ້າງ, ແລະຜູ້ພັດທະນາບໍ່ສາມາດເຂົ້າໃຈຢ່າງໄວວາຈາກພວກເຂົາວິທີການຫຼຸດຜ່ອນລະດັບຄວາມສ່ຽງ, ແລະສໍາຄັນທີ່ສຸດ, ມັນຈໍາເປັນຕ້ອງເຮັດໃນປັດຈຸບັນ, ຫຼືວ່າມັນຍັງບໍ່ຫນ້າຢ້ານ.
4. ຜົນກະທົບທາງລົບຕໍ່ຄໍາຮ້ອງສະຫມັກ. ເຄື່ອງສະແກນອາດຈະປະຕິບັດການໂຈມຕີ DoS ໃນແອັບພລິເຄຊັນໄດ້ດີ, ແລະຍັງສາມາດສ້າງຫນ່ວຍງານຈໍານວນຫລາຍຫຼືການປ່ຽນແປງທີ່ມີຢູ່ແລ້ວ (ຕົວຢ່າງ, ສ້າງຫລາຍສິບພັນຄໍາຄິດເຫັນໃນ blog), ດັ່ງນັ້ນທ່ານບໍ່ຄວນຄິດອອກ scan ໃນການຜະລິດ.
5. ຄຸນນະພາບຕໍ່າຂອງການກວດຫາຊ່ອງໂຫວ່. ໂດຍທົ່ວໄປແລ້ວເຄື່ອງສະແກນຈະໃຊ້ຊຸດ payloads ຄົງທີ່ ແລະສາມາດພາດຊ່ອງໂຫວ່ທີ່ບໍ່ເໝາະສົມກັບສະຖານະການທີ່ຮູ້ຈັກຂອງແອັບພລິເຄຊັນ.
6. ເຄື່ອງສະແກນບໍ່ເຂົ້າໃຈຫນ້າທີ່ຂອງແອັບພລິເຄຊັນ. ເຄື່ອງສະແກນຕົວເອງບໍ່ຮູ້ວ່າ "ທະນາຄານອິນເຕີເນັດ", "ການຈ່າຍເງິນ", "ຄໍາເຫັນ" ແມ່ນຫຍັງ. ສໍາລັບພວກເຂົາ, ມີພຽງແຕ່ການເຊື່ອມຕໍ່ແລະຕົວກໍານົດການ, ດັ່ງນັ້ນຊັ້ນອັນໃຫຍ່ຫຼວງຂອງຊ່ອງໂຫວ່ທາງເຫດຜົນທາງທຸລະກິດຍັງຖືກເປີດເຜີຍຢ່າງສິ້ນເຊີງ; ພວກເຂົາຈະບໍ່ຄິດທີ່ຈະຂຽນສອງຄັ້ງ, ສອດແນມກັບຂໍ້ມູນຂອງຄົນອື່ນໂດຍ ID, ຫຼືເພີ່ມຍອດເງິນໂດຍຜ່ານຮອບ.
7. ເຄື່ອງສະແກນບໍ່ເຂົ້າໃຈຄວາມຫມາຍຂອງຫນ້າ. ເຄື່ອງສະແກນບໍ່ສາມາດອ່ານ FAQs, ບໍ່ສາມາດຮັບຮູ້ captchas, ແລະດ້ວຍຕົວມັນເອງພວກເຂົາຈະບໍ່ຄິດວິທີການລົງທະບຽນແລະຫຼັງຈາກນັ້ນເຂົ້າສູ່ລະບົບໃຫມ່, ທີ່ທ່ານບໍ່ສາມາດຄລິກໃສ່ "ອອກຈາກລະບົບ," ແລະວິທີການເຊັນຄໍາຮ້ອງຂໍໃນເວລາທີ່ມີການປ່ຽນແປງພາລາມິເຕີ. ຄຸນຄ່າ. ດັ່ງນັ້ນ, ແອັບພລິເຄຊັນສ່ວນໃຫຍ່ອາດຈະບໍ່ຖືກສະແກນເລີຍ.

ມີບັນຫາໃນການສະແກນລະຫັດແຫຼ່ງ

1. ບວກທີ່ບໍ່ຖືກຕ້ອງ. ການວິເຄາະແບບຄົງທີ່ແມ່ນວຽກງານທີ່ສັບສົນທີ່ກ່ຽວຂ້ອງກັບການຄ້າຫຼາຍ. ຄວາມຖືກຕ້ອງມັກຈະຕ້ອງເສຍສະລະ, ແລະແມ້ກະທັ້ງເຄື່ອງສະແກນວິສາຫະກິດລາຄາແພງກໍ່ຜະລິດຜົນບວກທີ່ບໍ່ຖືກຕ້ອງເປັນຈໍານວນຫຼວງຫຼາຍ
2. ຄວາມຫຍຸ້ງຍາກໃນການປະຕິບັດ. ເພື່ອເພີ່ມຄວາມຖືກຕ້ອງແລະຄວາມສົມບູນຂອງການວິເຄາະສະຖິດ, ມັນຈໍາເປັນຕ້ອງປັບປຸງກົດລະບຽບການສະແກນ, ແລະການຂຽນກົດລະບຽບເຫຼົ່ານີ້ສາມາດໃຊ້ແຮງງານຫຼາຍເກີນໄປ. ບາງຄັ້ງມັນງ່າຍທີ່ຈະຊອກຫາສະຖານທີ່ທັງຫມົດໃນລະຫັດທີ່ມີບາງປະເພດຂອງແມງໄມ້ແລະແກ້ໄຂໃຫ້ເຂົາເຈົ້າກ່ວາການຂຽນກົດລະບຽບເພື່ອກວດພົບກໍລະນີດັ່ງກ່າວ.
3. ຂາດການສະຫນັບສະຫນູນການເພິ່ງພາອາໄສ. ໂຄງການຂະຫນາດໃຫຍ່ແມ່ນຂຶ້ນກັບຫ້ອງສະຫມຸດແລະກອບຈໍານວນຫລາຍທີ່ຂະຫຍາຍຄວາມສາມາດຂອງພາສາການຂຽນໂປຼແກຼມ. ຖ້າພື້ນຖານຄວາມຮູ້ຂອງເຄື່ອງສະແກນບໍ່ມີຂໍ້ມູນກ່ຽວກັບ "ຈົມ" ໃນກອບເຫຼົ່ານີ້, ມັນຈະກາຍເປັນຈຸດບອດແລະເຄື່ອງສະແກນພຽງແຕ່ຈະບໍ່ເຂົ້າໃຈລະຫັດ.
4. ໄລຍະເວລາສະແກນ. ຊອກຫາຊ່ອງໂຫວ່ໃນລະຫັດແມ່ນເປັນວຽກທີ່ສັບສົນໃນແງ່ຂອງ algorithms. ດັ່ງນັ້ນ, ຂະບວນການອາດຈະໃຊ້ເວລາດົນ ແລະຕ້ອງການຊັບພະຍາກອນຄອມພິວເຕີທີ່ສໍາຄັນ.
5. ການຄຸ້ມຄອງຕໍ່າ. ເຖິງວ່າຈະມີການບໍລິໂພກຊັບພະຍາກອນແລະເວລາສະແກນ, ຜູ້ພັດທະນາເຄື່ອງມື SAST ຍັງຕ້ອງເຮັດການປະນີປະນອມແລະການວິເຄາະບໍ່ແມ່ນທຸກລັດທີ່ໂຄງການອາດຈະຢູ່ໃນ.
6. ການສືບພັນຂອງຜົນການຄົ້ນພົບ. ການຊີ້ໃຫ້ເຫັນເຖິງສາຍສະເພາະແລະການໂທ stack ທີ່ນໍາໄປສູ່ຊ່ອງໂຫວ່ແມ່ນຍິ່ງໃຫຍ່, ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ເລື້ອຍໆເຄື່ອງສະແກນບໍ່ໄດ້ໃຫ້ຂໍ້ມູນພຽງພໍເພື່ອກວດສອບການປະກົດຕົວຂອງຊ່ອງໂຫວ່ຈາກພາຍນອກ. ຫຼັງຈາກທີ່ທັງຫມົດ, ຂໍ້ບົກພ່ອງອາດຈະຢູ່ໃນລະຫັດຕາຍ, ເຊິ່ງບໍ່ສາມາດເຂົ້າຫາຜູ້ໂຈມຕີໄດ້

ບັນຫາການສະແກນພື້ນຖານໂຄງລ່າງ

1. ສິນຄ້າຄົງຄັງບໍ່ພຽງພໍ. ໃນໂຄງສ້າງພື້ນຖານຂະຫນາດໃຫຍ່, ໂດຍສະເພາະທີ່ແຍກອອກຕາມພູມສັນຖານ, ມັນມັກຈະເປັນການຍາກທີ່ສຸດທີ່ຈະຮູ້ວ່າເຈົ້າພາບໃດທີ່ຈະສະແກນ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ວຽກງານສະແກນແມ່ນກ່ຽວຂ້ອງຢ່າງໃກ້ຊິດກັບວຽກງານການຄຸ້ມຄອງຊັບສິນ
2. ການຈັດລໍາດັບຄວາມສໍາຄັນທີ່ບໍ່ດີ. ເຄື່ອງສະແກນເຄືອຂ່າຍມັກຈະຜະລິດຜົນໄດ້ຮັບຫຼາຍຢ່າງທີ່ມີຂໍ້ບົກພ່ອງທີ່ບໍ່ສາມາດຖືກຂູດຮີດໃນການປະຕິບັດ, ແຕ່ຢ່າງເປັນທາງການລະດັບຄວາມສ່ຽງຂອງພວກເຂົາແມ່ນສູງ. ຜູ້ບໍລິໂພກໄດ້ຮັບບົດລາຍງານທີ່ຍາກທີ່ຈະຕີຄວາມຫມາຍ, ແລະມັນບໍ່ຊັດເຈນວ່າສິ່ງທີ່ຕ້ອງໄດ້ຮັບການແກ້ໄຂກ່ອນ.
3. ຄໍາແນະນໍາທີ່ບໍ່ດີ. ພື້ນຖານຄວາມຮູ້ຂອງເຄື່ອງສະແກນມັກຈະມີພຽງແຕ່ຂໍ້ມູນທົ່ວໄປຫຼາຍກ່ຽວກັບຊ່ອງໂຫວ່ແລະວິທີການແກ້ໄຂມັນ, ດັ່ງນັ້ນຜູ້ເບິ່ງແຍງຈະຕ້ອງປະກອບອາວຸດກັບ Google. ສະຖານະການແມ່ນດີຂຶ້ນເລັກນ້ອຍກັບເຄື່ອງສະແກນ whitebox, ເຊິ່ງສາມາດອອກຄໍາສັ່ງສະເພາະເພື່ອແກ້ໄຂ
4. ເຮັດດ້ວຍມື. ໂຄງສ້າງພື້ນຖານສາມາດມີຫຼາຍຂໍ້, ຊຶ່ງຫມາຍຄວາມວ່າມີຂໍ້ບົກພ່ອງຫຼາຍ, ບົດລາຍງານທີ່ຕ້ອງໄດ້ຮັບການວິເຄາະແລະວິເຄາະດ້ວຍຕົນເອງໃນແຕ່ລະຄັ້ງ.
5. ການຄຸ້ມຄອງບໍ່ດີ. ຄຸນນະພາບຂອງການສະແກນພື້ນຖານໂຄງລ່າງໂດຍກົງແມ່ນຂຶ້ນກັບຂະຫນາດຂອງພື້ນຖານຄວາມຮູ້ກ່ຽວກັບຄວາມອ່ອນແອແລະສະບັບຊອບແວ. ໃນນັ້ນ, ມັນສະແດງອອກ, ເຖິງແມ່ນວ່າຜູ້ນໍາຕະຫຼາດບໍ່ມີພື້ນຖານຄວາມຮູ້ທີ່ສົມບູນແບບ, ແລະຖານຂໍ້ມູນຂອງການແກ້ໄຂຟຣີມີຂໍ້ມູນຈໍານວນຫລາຍທີ່ຜູ້ນໍາບໍ່ມີ.
6. ບັນຫາກ່ຽວກັບການ patching. ສ່ວນຫຼາຍແລ້ວ, ການແກ້ໄຂຄວາມອ່ອນແອຂອງໂຄງສ້າງພື້ນຖານກ່ຽວຂ້ອງກັບການອັບເດດຊຸດ ຫຼື ການປ່ຽນແປງໄຟລ໌ການຕັ້ງຄ່າ. ບັນຫາໃຫຍ່ຢູ່ນີ້ແມ່ນວ່າລະບົບ, ໂດຍສະເພາະແມ່ນລະບົບມໍລະດົກ, ສາມາດປະຕິບັດຫນ້າທີ່ບໍ່ໄດ້ຄາດເດົາຍ້ອນຜົນຂອງການປັບປຸງ. ໂດຍພື້ນຖານແລ້ວ, ທ່ານຈະຕ້ອງເຮັດການທົດສອບການເຊື່ອມໂຍງກ່ຽວກັບໂຄງສ້າງພື້ນຖານທີ່ມີຊີວິດໃນການຜະລິດ.

ວິທີການ

ເປັນແນວໃດ?
ຂ້າພະເຈົ້າຈະບອກທ່ານເພີ່ມເຕີມກ່ຽວກັບຕົວຢ່າງແລະວິທີການແກ້ໄຂບັນຫາຈໍານວນຫຼາຍທີ່ໄດ້ລະບຸໄວ້ໃນພາກສ່ວນດັ່ງຕໍ່ໄປນີ້, ແຕ່ສໍາລັບໃນປັດຈຸບັນຂ້າພະເຈົ້າຈະຊີ້ບອກທິດທາງຕົ້ນຕໍທີ່ທ່ານສາມາດເຮັດວຽກໄດ້:

1. ການລວບລວມເຄື່ອງມືສະແກນຕ່າງໆ. ດ້ວຍການນໍາໃຊ້ທີ່ຖືກຕ້ອງຂອງເຄື່ອງສະແກນຫຼາຍໆຄັ້ງ, ທ່ານສາມາດບັນລຸການເພີ່ມຂື້ນຢ່າງຫຼວງຫຼາຍໃນພື້ນຖານຄວາມຮູ້ແລະຄຸນນະພາບຂອງການກວດສອບ. ທ່ານສາມາດຊອກຫາຊ່ອງໂຫວ່ຫຼາຍກວ່າເຄື່ອງສະແກນທັງໝົດທີ່ເປີດຕົວແຍກຕ່າງຫາກ, ໃນຂະນະທີ່ທ່ານສາມາດປະເມີນລະດັບຄວາມສ່ຽງໄດ້ຢ່າງຖືກຕ້ອງ ແລະໃຫ້ຄຳແນະນຳເພີ່ມເຕີມ.
2. ການປະສົມປະສານຂອງ SAST ແລະ DAST. ມັນເປັນໄປໄດ້ທີ່ຈະເພີ່ມການຄຸ້ມຄອງຂອງ DAST ແລະຄວາມຖືກຕ້ອງຂອງ SAST ໂດຍການແລກປ່ຽນຂໍ້ມູນລະຫວ່າງພວກເຂົາ. ຈາກແຫຼ່ງຂໍ້ມູນທີ່ທ່ານສາມາດໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບເສັ້ນທາງທີ່ມີຢູ່, ແລະການນໍາໃຊ້ DAST ທ່ານສາມາດກວດເບິ່ງວ່າຊ່ອງໂຫວ່ແມ່ນເຫັນໄດ້ຈາກພາຍນອກ.
3. ການຮຽນຮູ້ເຄື່ອງຈັກ™. ໃນປີ 2015 I ບອກ (ແລະ ຫຼາຍ) ກ່ຽວກັບການນໍາໃຊ້ສະຖິຕິເພື່ອໃຫ້ເຄື່ອງສະແກນ intuition ຂອງແຮກເກີແລະເລັ່ງໃຫ້ເຂົາເຈົ້າ. ນີ້ແນ່ນອນເປັນອາຫານສໍາລັບການພັດທະນາການວິເຄາະຄວາມປອດໄພອັດຕະໂນມັດໃນອະນາຄົດ.
4. ການເຊື່ອມໂຍງຂອງ IAST ກັບ autotests ແລະ OpenAPI. ພາຍໃນທໍ່ CI/CD, ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງຂະບວນການສະແກນໂດຍອີງໃສ່ເຄື່ອງມືທີ່ເຮັດວຽກເປັນ HTTP proxy ແລະການທົດສອບທີ່ເປັນປະໂຫຍດທີ່ເຮັດວຽກຜ່ານ HTTP. ການທົດສອບແລະສັນຍາ OpenAPI/Swagger ຈະເຮັດໃຫ້ເຄື່ອງສະແກນຂໍ້ມູນຂາດຫາຍໄປກ່ຽວກັບການໄຫລຂອງຂໍ້ມູນແລະເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະສະແກນຄໍາຮ້ອງສະຫມັກໃນລັດຕ່າງໆ.
5. ການຕັ້ງຄ່າທີ່ຖືກຕ້ອງ. ສໍາລັບແຕ່ລະຄໍາຮ້ອງສະຫມັກແລະໂຄງສ້າງພື້ນຖານ, ທ່ານຈໍາເປັນຕ້ອງສ້າງໂປຣໄຟລ໌ສະແກນທີ່ເຫມາະສົມ, ຄໍານຶງເຖິງຈໍານວນແລະລັກສະນະຂອງການໂຕ້ຕອບແລະເຕັກໂນໂລຊີການນໍາໃຊ້.
6. ການປັບແຕ່ງເຄື່ອງສະແກນ. ປົກກະຕິແລ້ວ ແອັບພລິເຄຊັນບໍ່ສາມາດສະແກນໄດ້ ໂດຍບໍ່ມີການດັດແປງເຄື່ອງສະແກນ. ຕົວຢ່າງແມ່ນປະຕູການຈ່າຍເງິນ, ເຊິ່ງແຕ່ລະຄໍາຮ້ອງຂໍຕ້ອງຖືກເຊັນ. ໂດຍບໍ່ມີການຂຽນຕົວເຊື່ອມຕໍ່ໄປຫາໂປໂຕຄອນປະຕູ, ເຄື່ອງສະແກນຈະລະເບີດຄໍາຮ້ອງຂໍທີ່ມີລາຍເຊັນທີ່ບໍ່ຖືກຕ້ອງ. ມັນຍັງມີຄວາມຈໍາເປັນທີ່ຈະຂຽນເຄື່ອງສະແກນພິເສດສໍາລັບປະເພດຂອງຂໍ້ບົກພ່ອງສະເພາະ, ເຊັ່ນ: ການອ້າງອິງວັດຖຸໂດຍກົງທີ່ບໍ່ປອດໄພ
7. ຄຸ້ມ​ຄອງ​ຄວາມ​ສ່ຽງ. ການນໍາໃຊ້ເຄື່ອງສະແກນຕ່າງໆແລະການເຊື່ອມໂຍງກັບລະບົບພາຍນອກເຊັ່ນການຄຸ້ມຄອງຊັບສິນແລະການຄຸ້ມຄອງໄພຂົ່ມຂູ່ຈະຊ່ວຍໃຫ້ການນໍາໃຊ້ຕົວກໍານົດການຈໍານວນຫຼາຍເພື່ອປະເມີນລະດັບຄວາມສ່ຽງ, ດັ່ງນັ້ນການຄຸ້ມຄອງສາມາດໄດ້ຮັບຮູບພາບທີ່ພຽງພໍຂອງສະຖານະການຄວາມປອດໄພຂອງການພັດທະນາຫຼືໂຄງສ້າງພື້ນຖານໃນປະຈຸບັນ.

ຕິດຕາມ ແລະ ລົບກວນການສະແກນຊ່ອງໂຫວ່!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com