ตรวจสอบความปลอดภัยของโค้ด

penetration test แบบ black-box มองเห็นได้แค่สิ่งที่แอปพลิเคชันเปิดเผยออกมาตอนรันเท่านั้น ผู้ทดสอบส่ง request เข้าไป ดูว่าตอบอะไรกลับมา แล้วเดาว่าข้างในน่าจะทำงานยังไง แต่จุดอ่อนบางอย่างไม่เคยโผล่มาถึงขอบระบบเลย crypto ที่อ่อนแอซ่อนอยู่ใน utility class สักตัว การเช็ค authorization ที่หายไปลึกสามชั้นใน code path การ deserialization ที่ไม่ปลอดภัยของข้อความที่ผู้ใช้ภายนอกปั้นขึ้นมาเองไม่ได้ง่าย ๆ หรือ hardcoded credential ที่รออยู่ใน config loader ทั้งหมดนี้คือช่องโหว่จริง และทั้งหมดนี้ซ่อนตัวอยู่หลัง HTTP interface หน้าตาธรรมดาที่สุดได้สบาย ๆ Secure code review ตัดการเดาทิ้งไป แทนที่จะไปงัดแอปพลิเคชันจากข้างนอก เราอ่าน source code ตรง ๆ เลย นี่คือ white-box โดยนิยาม ทุก branch ทุก dependency ทุกการตัดสินใจเรื่องความไว้ใจที่ทีมพัฒนาของคุณวางไว้ อยู่บนโต๊ะหมด ไม่ว่าวันนี้ผู้โจมตีจะกระตุ้นมันจากข้างนอกได้ง่ายหรือไม่ก็ตาม สองแนวทางนี้ตอบคนละคำถาม และยิ่งใช้คู่กันยิ่งแข็งแรง code review ทำงานจากข้างในออกนอก penetration test ทำงานจากข้างนอกเข้าใน จุดที่สองอย่างทับกันนั่นแหละ คือที่มาของความมั่นใจจริง ๆ

วิธีการทำงานของเรา

ทุกงานตรวจสอบเดินตามสี่ขั้นตอนเดียวกันเสมอ คุณจะรู้ตลอดว่างานอยู่ตรงไหน และขั้นถัดไปคืออะไร

1. Application profiling — เราเริ่มจากตั้งวงกับทีมของคุณ ทำความเข้าใจว่าแอปพลิเคชันทำงานจริงยังไง ทั้งสถาปัตยกรรม framework และภาษาที่ใช้ จุดที่ input เข้าสู่ระบบ ตำแหน่งของ trust boundary และ component ไหนสำคัญต่อธุรกิจมากที่สุด ขั้นนี้เป็นตัวกำหนดว่าจะทุ่มแรงตรวจสอบไปตรงไหน โมดูลจ่ายเงินกับแบนเนอร์การตลาดไม่ควรได้ความสำคัญเท่ากัน ขอบเขต ภาษาและ framework ที่ครอบคลุม กับระดับความลึกของการตรวจสอบ ตกลงร่วมกับคุณตรงนี้หมด และ toolchain จะปรับตามเทคโนโลยีของคุณ ไม่ใช่ให้คุณปรับตาม
2. Static analysis — เรารันเครื่องมือ static analysis (SAST) ที่เหมาะกับแต่ละภาษาใน codebase static analysis คือสิ่งที่ทำให้ครอบคลุมทั้ง codebase ได้จริง มันไล่ data flow จาก source ที่ไม่น่าเชื่อถือไปจนถึง sink ที่อันตราย จับ tainted input ที่วิ่งไปถึง query หรือ command และงัดปัญหาที่น่าสงสัยขึ้นมาจากไฟล์ที่ไม่มีใครคิดจะเปิด ผลลัพธ์ของขั้นนี้คือรายการที่ต้องสงสัย ตั้งใจให้กว้างไว้ก่อน และยังไม่ใช่ finding ที่ยืนยันแล้ว
3. Manual analysis — นักวิเคราะห์ไล่ดูรายการที่ต้องสงสัยด้วยมือทีละตัว ทุกประเด็นที่ถูกจับขึ้นมาจะถูกไล่ตามไปตาม code path จริง เพื่อดูว่ามัน exploit ได้จริงในบริบทนั้นไหม หรือเป็นแค่ false positive คือ pattern ที่ดูอันตรายแต่โดน validation ที่เครื่องมือตามไม่ทันปิดไปแล้ว ที่สำคัญไม่แพ้กัน นักวิเคราะห์อ่านเพื่อหาสิ่งที่เครื่องมือมองข้าม ทั้ง false negative และเหนืออื่นใดคือ logic flaw เช่น authorization check ที่หายไป หรือการตัดสินใจเรื่อง crypto ที่ถูกต้องตาม syntax แต่ผิดหลัก crypto เพราะไม่มี pattern matcher ตัวไหนเข้าใจว่าแอปพลิเคชันของคุณตั้งใจจะอนุญาตอะไร รายงาน SAST ดิบ ๆ ไม่ใช่สิ่งที่เราส่งมอบ ขั้นตอน manual นี่แหละคือที่มาของคุณค่า
4. Recommendation — ทุกช่องโหว่ที่ยืนยันแล้ว เราชี้ให้เห็นตำแหน่งที่มันอยู่ในโค้ดแบบเป๊ะ ๆ ทั้งไฟล์ ฟังก์ชัน และบรรทัด พร้อมวิธีแก้ที่เขียนสำหรับภาษาและ framework ที่คุณใช้อยู่จริง คำแนะนำที่บอกแค่ว่า "sanitise input" ไม่ช่วยอะไรใครเลย แต่คำแนะนำที่ระบุชื่อ API ตัวที่ทำงานนี้ได้ถูกต้องใน framework ของคุณ จะได้ถูกแก้ใน sprint ถัดไป

ทำไม manual analysis ถึงสำคัญ

เครื่องมือ static analysis เก่งเรื่องความครอบคลุม แต่แย่มากเรื่องการใช้วิจารณญาณ ถ้าปล่อยผล SAST scan ทิ้งไว้โดยไม่มีคนรีวิว มันจะพังพร้อมกันสองแบบ แบบแรกคือ false positive เครื่องมือจับ data flow ว่า tainted เพราะมันมองไม่เห็นชั้น validation ไม่เห็น encoding ที่ framework มีมาให้ในตัว หรือไม่เห็น business rule ที่ทำให้เส้นทางนั้นไปไม่ถึง พอรายงานเต็มไปด้วยของพวกนี้ ทีมพัฒนาของคุณก็ถูกฝึกให้เมินมันไปเลย แบบที่สองเงียบกว่าและร้ายกว่า นั่นคือ false negative เครื่องมือแค่ match pattern มันไม่เข้าใจเจตนา มันจะไม่สังเกตว่า endpoint เช็คแค่ว่า user ล็อกอินอยู่ไหม แต่ไม่เคยเช็คว่า user คนไหนเป็นเจ้าของ record นั้น หรือฟังก์ชัน signing ใช้ key ที่มาจากค่าที่เดาได้ เพราะไม่มีอะไรในบรรทัดพวกนั้น match กับ signature ที่รู้กันว่าอันตราย ขั้นตอน manual analysis มีไว้แก้ทั้งสองปัญหานี้ ตัด noise ให้เหลือแต่ประเด็นที่ยืนยันแล้วว่า exploit ได้จริง แล้วเติม finding ระดับ logic ที่ระบบอัตโนมัติสร้างไม่ได้เชิงโครงสร้างกลับเข้ามา สิ่งที่ไปถึงรายงานของคุณคือชุดช่องโหว่จริง ทุกข้อผ่านการยืนยันโดยคนที่อ่านโค้ดมากับตา

สิ่งที่คุณได้รับ

ทุกรายงานมีอย่างน้อยดังนี้

• Executive summary — ภาพความเสี่ยงระดับธุรกิจ เหมาะสำหรับผู้บริหารและ auditor
• Finding จัดตาม Risk Level — ทุกช่องโหว่ได้ระดับ Critical, High, Medium หรือ Low เพื่อจัดลำดับการแก้ได้อย่างเป็นกลาง
• ตำแหน่งโค้ดที่เป๊ะสำหรับทุก finding — ไฟล์ ฟังก์ชัน และบรรทัดที่ปัญหาอยู่ ทีมพัฒนาของคุณไม่ต้องมานั่งไล่หาว่าเราเจออะไรตรงไหน
• คำแนะนำการแก้ไข — วิธีแก้ที่เขียนสำหรับภาษาและ framework ของคุณ ไม่ใช่คำพูดกว้าง ๆ เรื่องการเขียนโค้ดให้ปลอดภัย
• Retest ยืนยันผล — หลังทีมของคุณแก้ตามแล้ว เราตรวจซ้ำโค้ดส่วนที่ได้รับผลกระทบ แล้วอัปเดตรายงานให้สะท้อนรายการที่ปิดไปแล้ว

ทีมและใบรับรอง

งานตรวจสอบทุกชิ้นทำโดยทีมภายในของเราที่ถือใบรับรองในวงการอย่าง OSCP, OSCE, CREST CRT, CREST CPSA และ GIAC GREM ที่ต้องผ่านการสอบภาคปฏิบัติอย่างเข้มข้นกว่าจะได้มา พื้นฐานสาย offensive security ตัวเดียวกับที่ขับเคลื่อน penetration test ของเรา คือสิ่งที่กำหนดวิธีอ่านโค้ดของเรา ไม่ใช่อ่านแบบ auditor ที่ไล่ติ๊ก checklist แต่อ่านแบบผู้โจมตีที่ถามว่าโค้ดแต่ละบรรทัดเปิดให้เขาทำอะไรได้บ้าง ดูใบรับรองทั้งหมดที่ทีมถือ

มาตรฐานที่ใช้

เราจัดประเภทและรายงาน finding อิงกับ framework ที่ทีมพัฒนาและ auditor ของคุณใช้งานอยู่แล้ว

• OWASP ASVS (Application Security Verification Standard) — ชุดข้อกำหนดที่เราใช้ตรวจโค้ด ทำให้ทุก finding ผูกกับ control ที่มันละเมิดชัด ๆ
• OWASP Top 10 — หมวดความเสี่ยงที่ backlog การแก้ไขของคุณน่าจะจัดเรียงตามอยู่แล้ว
• CWE — ระบบจัดหมวดจุดอ่อนมาตรฐาน ทำให้ทุก finding มีการจัดประเภทที่แม่นยำและเป็นกลางต่อผู้ผลิต

Secure code review บอกคุณว่าอะไรผิดอยู่ข้างในโค้ด ส่วน penetration test พิสูจน์ว่าผู้โจมตีเข้าถึงอะไรได้จากข้างนอก เอาการตรวจสอบนี้ไปจับคู่กับ penetration test ฝั่ง เว็บแอปพลิเคชัน หรือ แอปพลิเคชันมือถือ แล้วคุณจะได้ทั้งสองทิศทางพร้อมกัน ทั้งจากข้างในออกนอก และจากข้างนอกเข้าใน แล้ว finding จากแต่ละฝั่งก็ช่วยลับอีกฝั่งให้คมขึ้น