Penetration Testing + Interest = Penetrest (My Journey)

ใครที่ยังไม่ได้อ่านตอนแรก สามารถอ่านได้ที่ Patch Management และ Hardening คืออะไร/ ยังไง พร้อมวิธีการ ตอนที่  1 4. การ Maintenance      หลังจากที่เราทำการ implement เสร็จแล้ว ไม่ใช่ว่าจะจบกันเท่านี้ มันแค่เริ่มต้น It's just the beginning. ก็ต้องมีขั้นตอนในการที่ดูแล และ up-to-date ให้อุปกรณ์ในระบบไม่มีช่องโหว่ต่อไป รวมถึงปรับปรุง template ในการ hardening เป็นประจำด้วย จะกล่าวถึงต่อไปนะ โดยปกติที่ผมเคยทำมา จะมีการกำหนดให้คนนึงที่อาจจะเป็น Security Consult ของแต่ละ platform แต่ละแผนก ในการทำ subscribe ไปยัง vendor ต่างๆ ตามอุปกรณ์ที่ดูแลอยู่เพื่อรับข่าวสาร และได้รับ notification เวลามี security update เพื่อจะนำมาวิเคราะห์ดูว่าระบบที่เราดูแลอยู่นั้นมีช่องโหว่ใหม่ๆ ที่เกี่ยวกับอุปกรณ์ของเราเกิดขึ้นหรือไม่ ถ้ามีก็ต้องนำมาเข้าสู่กระบวนการดังที่กล่าวไปข้างต้น มีคนแล้วก็ต้องมี policy องค์กรก็ต้องมีการกำหนด policy ขึ้นมาเพื่อใช้ควบคุมระยะเวลาที่องค์กรยอมรับความเสี่ยงต่อช่องโหว่ในระดับต่างๆได้ ยกตัวอย่างให้เห็นภาพ ที่ผู้เขียนเคยทำมา เช่น ถ้ามีช่องโหว่เกิดขึ้นใหม่ในระดับ - C

post นี้ก็เช่นเกียวกับโพสต์อื่นๆที่ ผู้เขียนเขียนขึ้นจากประสบการณ์การทำงานนะครับ ส่วนในเรื่องของ ISO27001 ทางผู้เขียนยังไม่รู้ครอบคลุมขนาดนั้น ขอยังไม่กล่าวถึง คงได้เขียนหลังจากสอบ CISSP ได้แล้ว (ตอนนี้ยังอยู่ในวงการ Pentest อยู่เลยจ้า) คืออะไร ? Patch Management และ Hardening  -  เป็นส่วนนึงของ configuration management process ใน ISO27001 และมาตรฐานทางด้านความปลอดถัยอื่นๆ ด้วย  ทำไมต้องมีการทำ patch และ hardening เรื่องของ Patch management จริงๆ ก็จะเกี่ยวข้องกับการทำ Hardening นะละ นั่นคือทำเพื่อปิดช่องโหว่ให้น้อยที่สุดเพื่อลดความเสี่ยงที่จะถูกโจมตีจากผู้ไม่ประสงค์ดี มันก็ไม่ดีใช่ไหมละ ถ้าระบบของเราโดนโจมตี ซึ่งอาจจะเป็นในแง่ของการขโมยข้อมูล หรือที่องค์กรส่วนใหญ่รับไม่ค่อยได้คือการโดน dos จนทำให้อุปกรณ์ไม่สามารถให้บริการต่อได้ ก็เรื่อง Availability ไง ในบางบริษัทที่มีการทำ transaction เกี่ยวกับเงินนี่ เขาคิดค่าเสียหายเป็นนาทีเลยนะ ล่มแค่ครึ่งชั่วโมงก็เสียหายหนักแล้ว กระบวนการการทำ Patch กับ hardening ก็จะมีดังนี้ คือ เขียน flow ให้ดูกันง่ายๆ อ่านคำอธิบายต่อได้ด้า

สามารถอ่าน version ภาษาไทยได้ด้านล่างเช่นเคยครับ ขอบคุณครับ Firewall audit is part of many IT security Standard audit and compliance.  From my experience, auditor can assess and audit something like following (maybe more) 1. Patch Level or OS version -- > Latest version, vulnerable version or not. 2. Configuration and parameter  --> must follow hardening document , recommend parameter which should be configured.                 Hardening document is establish from security baseline and must be approved by all related parties such as IT Security, Network Security, Management level of company before publish to use etc.   3. Audit firewall change request form (sometime this activity is in rule validate) --> If customer organization is complied with ISO27001 or other security standard eg. PCI-DSS. They will audit firewall request document , it must be as same as current rule.   Actual equal Approved. 4. Rules or ACLs revie