Information Technology Risk Assessment Guidelines for Modern IT Auditors
by A.Pinya Hom-anek,
GCFW, CISSP, CISA, (ISC)2 Asian Advisory Board
President, ACIS Professional Center
เทคโนโลยีสารสนเทศ หรือ “Information Technology” ที่เรานิยมเรียกสั้นๆว่า “IT” หรือ “ICT” ที่รวมถึง “C” คือ “Communication” หรือ “การสื่อสาร” เข้ามาด้วย ซึ่งในปัจจุบัน “IT” หรือ “ICT” นั้น มีความสำคัญอย่างยิ่งกับทุกองค์กร ในยุคที่เทคโนโลยีสารสนเทศ กลายเป็นส่วนสำคัญในการขับเคลื่อนองค์กรสมัยใหม่ได้อย่างมีประสิทธิภาพ ระบบเครือข่ายและระบบอินเทอร์เน็ต ได้เข้ามามีบทบาทสำคัญและเปลี่ยนแปลงโลกเทคโนโลยีสารสนเทศอย่างสิ้นเชิง โดยระบบอินเทอร์เน็ตนั้นทำให้โลกไร้พรมแดน และ ในขณะเดียวกันก็เปิดช่องทางให้แฮกเกอร์ และไวรัสจากทั่วโลกสามารถเข้ามาโจมตีเครื่องคอมพิวเตอร์ของเรา และขององค์กรได้เช่นกัน ดังนั้นเทคโนโลยีสารสนเทศสมัยใหม่ที่ทำงานร่วมกันโดยผ่านระบบอินเทอร์เน็ตถือว่ามีความเสี่ยงที่องค์กรควรจะประเมินความเสี่ยงเทคโนโลยีสารสนเทศ เป็นระยะๆ เพื่อให้แน่ใจได้ว่าเทคโนโลยีสารสนเทศ และ ระบบอินเทอร์เน็ตที่องค์กรใช้อยู่นั้นปลอดภัยจาก Malware และ ภัยอินเทอร์เน็ตต่างๆ ที่สามารถโจมตีระบบเราได้จากทั่วโลก
ความเสี่ยงตามยุคสมัยของเทคโนโลยีสารสนเทศทั้ง 5 ยุค
กล่าวถึงยุคสมัยของเทคโนโลยีสารสนเทศ ถ้าเริ่มนับจากมีคอมพิวเตอร์ส่วนบุคคล หรือ “Personal Computer” เครื่องแรกในโลกนั้น แบ่งออกได้เป็น 5 ยุค ซึ่งแต่ละยุคมีแนวทางในการประเมินความเสี่ยงที่แตกต่างกัน ดังนั้นผู้ตรวจสอบระบบสารสนเทศ หรือ “IT Auditor” ควรศึกษาเทคโนโลยีสารสนเทศในแต่ละยุคเพื่อให้เกิดความเข้าใจความเสี่ยงของเทคโนโลยีสารสนเทศในแต่ละยุค และ สามารถนำความรู้ความเข้าใจไปประยุกต์ใช้ในการตรวจสอบประเมินความเสี่ยงระบบสารสนเทศให้มีประสิทธิภาพเพิ่มขึ้นต่อไป
ยุคที่ 1 ยุคเริ่มต้นของระบบเครือข่าย Local Area Network (LAN) และ เป็นที่มาของยุคระบบ File-Based
ระบบ LAN ที่เรารู้จักกันดีนั้น เริ่มนิยมใช้ในเมืองไทย ตั้งแต่ปี พ.ศ. 2532 ในยุคนั้นระบบเครือข่ายของ Novell NetWare มีส่วนแบ่งการตลาดมากที่สุด แต่ในปัจจุบันระบบ Windows 2000 Server หรือ Windows Server 2003 ของบริษัทไมโครซอฟต์กลับมีส่วนแบ่งการตลาดมากเป็นอันดับหนึ่ง และได้รับความนิยมอย่างแพร่หลายในองค์กรทั้งภาครัฐและเอกชน การเข้าถึงข้อมูลในระบบเครือข่ายทำได้โดยการติดต่อไปยัง File Server ที่ทำหน้าที่ “Share” ไฟล์ข้อมูลให้ทุกคนในระบบเครือข่ายสามารถเข้าถึงได้โดยการ “Map Network Drive” เช่น จากเครื่องลูกข่าย (Client) ไปยังเครื่องแม่ข่าย เหตุผลที่ระบบ “File-Based” เป็นที่นิยมก็เพราะความง่ายในการเก็บและเรียกใช้ File ข้อมูลต่างๆ โดยมีการจัดเก็บแบบ “Directory” ที่เราคุ้นเคยบนเครื่องแม่ข่าย
ความเสี่ยงของระบบ “File-Based” ก็คือ ปัญหาเรื่องไวรัสและเวอร์มต่างๆ ที่มุ่งเน้นไปในทางการโจมตีผ่านทาง พอร์ต “TCP” ที่ใช้ในการ “Share File”เช่น โปรโตคอล “SMB” ของไมโครซอฟต์ ใช้พอร์ต “TCP” หมายเลข 139 (NetBIOS Session) และ 445 (Microsoft Direct-host) ทำให้เครื่องลูกข่ายหลายเครื่องที่มีพฤติกรรมชอบแชร์ไฟล์ในระบบเครือข่ายสามารถติดไวรัสและเวอร์มได้อย่างง่ายดายจากการกระจายตัวของไวรัสและเวอร์มผ่านทางระบบ “File-Based” ดังกล่าว ข้อเสียของระบบ “File-Based” นอกจากเรื่องของไวรัสและเวอร์มแล้วก็คือ ปัญหาเรื่องการใช้ “Bandwidth” ของระบบเครือข่าย โดยเฉพาะถ้าเป็นระบบ Wide Area Network (WAN)มักจะเกิดปัญหาความล่าช้าในการเข้าถึงไฟล์ข้อมูลข้ามระบบผ่านทางอุปกรณ์ Router เป็นต้น
สำหรับแนวทางในการประเมินความเสี่ยงระบบ “File-Based” เราต้องมุ่งเน้นไปที่ช่องโหว่ของการ “Share File” โดยไม่ระมัดระวังว่า หลายครั้งที่ผู้ใช้คอมพิวเตอร์ทั่วไปในองค์กร ชอบ “Share-File” ให้กับผู้ใช้คนอื่นโดยไม่มีความตระหนักถึงภัยจากไวรัสและเวอร์มซึ่งอาจเข้ามาทางระบบเครือข่าย ดังนั้นผู้ตรวจสอบระบบสารสนเทศสามารถใช้ “Security Assessment Tool” ที่สามารถเข้าถึง “Share File and Folder” ต่างๆ ที่อยู่ในระบบเครือข่าย เพื่อแสดงให้ผู้ใช้คอมพิวเตอร์เห็นว่า การ “Share File” โดยไม่ระมัดระวังกลายเป็นจุดโหว่สำคัญของระบบที่แฮกเกอร์และไวรัสสามารถโจมตีได้โดยง่าย ตลอดจนองค์กรควรกำหนด “นโยบาย” หรือ “Policy” เพื่อป้องกันความเสี่ยงที่อาจเกิดขึ้นจากภัยดังกล่าว โดยประกาศให้ผู้ใช้คอมพิวเตอร์เลิกพฤติกรรมการ “Share File” ที่เครื่องลูกข่าย และ ให้ผู้ดูแลระบบ (System Administration) ทำการ “Harden” เครื่องแม่ข่ายตามมาตรฐานสากล และมีหน้าที่รับผิดชอบในการติดตั้ง “Patch” ให้กับเครื่องแม่ข่ายอย่างสม่ำเสมอเพื่อป้องกันไม่ให้เครื่องแม่ข่ายมีช่องโหว่ให้แฮกเกอร์หรือไวรัสเข้ามาโจมตีระบบได้
ยุคที่ 2 ยุค Distributed Computing หรือ ยุค Client/Server Technology
หลังจากยุค “File-Based” ซึ่งมีข้อเสียเรื่องของความล่าช้าในการรับ-ส่ง ข้อมูลผ่าน Wide Area Network (WAN) ทำให้ระบบเครือข่ายมี “Bandwidth Overhead” จำนวนมาก เกิดปัญหา Bandwidth ไม่เพียงพอ จึงทำให้เทคโนโลยี “Client/Server” ได้รับความนิยมเพิ่มขึ้น ข้อดีของระบบ Client/Server ที่ชัดเจนก็คือ เครื่องลูกข่ายและเครื่องแม่ข่ายไม่จำเป็นต้อง “Map Network Drive” และ ไม่ต้องใช้ โปรโตคอล SMB, NCP หรือ NFS ในการ “Share File” แต่จะติดต่อกันด้วย RPC หรือ “Remote Procedure Call” แทน โดยปกติระบบ Microsoft Windows จะใช้พอร์ต TCP หมายเลข 135 หรือ พอร์ต DCE End-Point Mapping (epmap) และ ระบบ UNIX/LINUX จะใช้พอร์ต TCP หมายเลข 111 หรือ พอร์ต SUNRPC ในการเริ่มต้นการติดต่อแบบ Client/Server ระหว่างเครื่องคอมพิวเตอร์ สองเครื่องขึ้นไป หลังจากการเริ่มการเชื่อมต่อแล้ว เครื่องจะทำการเปิดพอร์ตในลักษณะเป็น “Dynamic.Port ” อีกหลายพอร์ต เพื่อรับส่งข้อมูลซึ่งกันและกัน
ความเสี่ยงของระบบ Client/ Server ก็คือการเปิดพอร์ต TCP หมายเลข 135 ใน Microsoft Windows และ พอร์ต TCP หมายเลข 111 ใน UNIX/LINUX ซึ่งปกติจะมีช่องโหว่แบบ Buffer Overflow อยู่เป็นประจำ (ดูรายละเอียดได้ใน SANS Top20 www.sans.org/top20) หากเครื่องคอมพิวเตอร์ขาดการติดตั้ง Patch อย่างสม่ำเสมอ โอกาสที่จะถูกโจมตีโดยไวรัสหรือแฮกเกอร์ผ่านทางพอร์ต RRC มีโอกาสค่อนข้างสูงที่จะประสบความสำเร็จ นอกเหนือจากปัญหาเรื่องช่องโหว่ที่พอร์ต RRC แล้ว ยังมีปัญหาเรื่องการเปิดพอร์ตแบบ “Dynamic Port” จำนวนมากซึ่งทำให้ควบคุมพอร์ตที่ไฟร์วอลล์ได้ยาก เพราะ RPC ไม่ได้ใช้เพียงพอร์ตเดียว แต่เปิดพอร์ตพร้อมกันทีเดียวได้หลายๆพอร์ต
แนวทางในการประเมินความเสี่ยงระบบ Client/Server ก็คือ ต้องทำการ Assessment ที่พอร์ต RRC ของเครื่องคอมพิวเตอร์ว่ามีช่องโหว่ที่ยังไม่ได้รับการแก้ไขหรือยังไม่ได้ “Patch” หรือไม่ ถ้าพบก็ให้รีบติดตั้ง “Patch” เพื่อปิดช่องโหว่ดังกล่าวซึ่ง ในบางครั้งเครื่องแม่ข่ายที่ใช้ระบบ Microsoft Windows หรือ UNIX /Linux มีปัญหาเรื่องการติดตั้ง Patch เราสามารถแก้ปัญหาได้โดยการติดตั้งไฟล์วอลล์ภายใน หรือ “Inner Firewall” เพื่อปิดพอร์ต RRC ดังกล่าวสำหรับเครื่องคอมพิวเตอร์อื่นๆ ที่ไม่มีความจำเป็นต้องติดต่อกับเครื่องแม่ข่ายที่เปิดพอร์ต RRC อยู่
การป้องกันไวรัสที่ Gateway ก็เป็นเรื่องสำคัญ เพราะไวรัสรุ่นใหม่ๆ มักจะโจมตีที่พอร์ต RRC เช่นกัน ในปัจจุบันระบบอิเล็กทรอนิกส์เมล์ที่เราใช้กันอยู่เป็นประจำ เช่น Microsoft Outlook กับ Microsoft Exchange และ Lotus Note Client กับ Notes Server ก็ติดต่อกันด้วยเทคโนโลยี Client/Server เช่นกัน ซึ่งก็จะมีช่องโหว่ที่พอร์ต RRC ดังกล่าวมาแล้วในตอนต้น ตลอดจนมีข้อจำกัดด้าน Bandwidth ในการใช้งานเมื่อมีการใช้งานข้อมูลปริมาณมากๆ ซึ่งปกติแล้วเทคโนโลยี “Client/Server”จะเร็วกว่าเทคโนโลยี “File-Based” แต่ยังช้ากว่าเทคโนโลยี “Web-Based” ในบางกรณี ซึ่งเป็นที่มาของเทคโนโลยีในยุคที่สามต่อไป
ยุคที่ 3 ยุค “Web-Based”
จากข้อจำกัดของเทคโนโลยี “File-Based” และ “Client/Server” ดังที่กล่าวมาแล้ว ทำให้เทคโนโลยี “Web -Based” ที่ใช้โปรโตคอล HTTP ได้รับความนิยมอย่างสูงในปัจจุบัน โปรแกรมประยุกต์ต่างๆ ล้วนหันมาใช้เทคโนโลยี “Web-Based” ในการพัฒนาโปรแกรม เพื่อให้เกิดความสะดวกสบายกับการใช้งานเครื่องลูกข่าย ซึ่งมีเพียง “Web Browser” ก็สามารถเข้าใช้งานเครื่องแม่ข่ายได้ผ่านทางจากพอร์ต TCP หมายเลข 80 หรือ พอร์ต HTTP ปัญหาของระบบ “Web-Based” ส่วนใหญ่ก็คือ ข้อมูลที่รับ-ส่งกันด้วยโปรโตคอล HTTP นั้นเป็นข้อมูลที่ไม่ได้เข้ารหัส ซึ่งสามารถถูกแฮกเกอร์เข้ามาแอบดูหรือ “Sniff” ได้ง่าย โดยเฉพาะ Username และ Password ที่ใช้ Login เข้ามาในระบบ Web Application นอกจากนี้ ยังมีปัญหาที่ตัว Web Server เองก็มักจะมีช่องโหว่ Buffer Overflow ออกมาเป็นระยะๆ ไม่ว่าจะเป็น Web Server IIS หรือ Web Server Apache รวมถึง SSL Module ก็มีช่องโหว่เช่นกัน ล่าสุดยังมีปัญหาช่องโหว่ที่ Web Application เองไม่ว่าจะเป็นค่าย ASP, PHP, JAVA ก็ล้วนมีช่องโหว่ตามที่ OWASP (Open Web Application Security Project) ได้กล่าวไว้สิบช่องโหว่ (ดูรายละเอียดได้ที่ www.owasp.org) ทำให้โปรแกรมเมอร์ต้องมีความระมัดระวังในการเขียน “Code” ให้ปลอดภัยจากการโจมตีในลักษณะดังกล่าวด้วย
สำหรับแนวทางในการประเมินความเสี่ยงระบบ “Web-Based” นั้น ควรเน้นไปที่ “Web Application Security” ตาม OWASP กล่าวคือควรมีการทำ “Penetration Testing” ระบบ Web Application ก่อนการใช้งานจริง ตาม Top 10 Web Hacking Checklist เพื่อให้แน่ใจว่าไม่มีช่องโหว่ให้แฮกเกอร์สามารถฉวยโอกาสโจมตี Web Application ของเราได้ ผู้ตรวจสอบระบบสารสนเทศจึงจำเป็นต้องมีความรู้ในด้านการเจาะระบบ Web Application พอสมควร (Ethical Hacking or Web Application Pen-test) ตลอดจน ผู้ตรวจสอบระบบสารสนเทศควรจะประเมินความเสี่ยงช่องโหว่ที่ Web Server ด้วยวิธีดังกล่าว และ ควรแนะนำให้ใช้โปรโตคอล HTTPS (SSL) ที่เป็น Cipher or Encrypted Text แทน โปรโตคอล HTTP ธรรมดาที่เป็น Plain Text เพื่อป้องกันการดักจับข้อมูลโดยใช้โปรแกรมจำพวก “Packet Sniffer” อีกด้วย
ยุคที่ 4 ยุค “Web Services”
เรื่องของ XML และ Web Services ไม่ใช่เรื่องใหม่ แต่ในประเทศไทยขณะนี้ (พ.ศ. 2549) ยังนิยมใช้เทคโนโลยี “Web-Based” เป็นส่วนใหญ่ เนื่องจากผู้พัฒนาระบบจำนวนมากมีศักยภาพในการพัฒนาซอฟต์แวร์ทำงานในแบบ “Web-Based” มากกว่า “Web Services” โดยเทคโนโลยี “Web Services” เป็นการพัฒนาต่อยอดมาจากเทคโนโลยี “Web-Based” อีกที่หนึ่ง กล่าวคือ มีการนำโครงสร้างข้อมูลแบบ XML และการเชื่อมต่อโปรแกรมประยุกต์โดยใช้เทคโนโลยี SOAP มาเชื่อมต่อระบบคอมพิวเตอร์ที่หลากหลาย Platform และ หลากหลาย Vendor ให้สามารถทำงานร่วมกันและสามารถแลกเปลี่ยนข้อมูลกันได้ ในรูปแบบของ XML Format
ปัญหาของเทคโนโลยี Web Service ก็คือ การรับส่งข้อมูลที่เป็น XML Format นั้น ส่วนใหญ่เป็น Plain Text ที่แฮกเกอร์สามารถดักจับข้อมูลได้ อีกทั้งยังมีปัญหาเหมือนกับเทคโนโลยี Web-Based คือที่ Web Server และ Web Application โดยถ้าทำงานในลักษณะ 3 Tiers ก็จะมีปัญหาช่องโหว่ทั้งของ Application Server เช่น IBM WebSphere หรือ BEA Weblogic และ ปัญหาช่องโหว่ใน RDBMS เอง เช่น Oracle หรือ Microsoft SQL Server
ซึ่งแนวทางในการประเมินความเสี่ยงระบบ Web Service นั้น ควรเริ่มจากตรวจดูว่ามีการเข้ารหัสข้อมูลที่ส่งกันในรูปแบบ XML Format หรือไม่ ซึ่งถ้ายังเป็น Plain Text อยู่ก็ควรแนะนำให้เข้ารหัสข้อมูล เช่น ใช้ SSL (HTTPS) หรือใช้เทคโนโลยี SAML หรือ WS-Security เป็นต้น
การประเมินความเสี่ยงควรทำทั้ง Web Server, Application Server และ RDBMS Server ตลอดจนตรวจสอบ Web Application ถึงช่องโหว่ทั้ง 10 แบบของ OWASP ด้วย (see http://www.owasp.org)
ยุคที่ 5 ยุค SOA (Service Oriented Architecture)
เทคโนโลยี “SOA” เป็นการต่อยอดจากเทคโนโลยี “Web Services” อีกทีหนึ่ง โดยมุ่งเน้น Concept ของการ Outsource บริการต่างๆ ที่เป็น “Module” ย่อยๆ ทำงานร่วมกันผ่านระบบเครือข่าย TCP/IP ดังนั้นจะเห็นว่าเสถียรภาพของระบบเครือข่ายกลายเป็นประเด็นสำคัญของ “SOA” เพราะต้องติดต่อกันผ่านทาง SOA Enterprise Service Bus (ESB) อยู่ตลอดเวลาในแบบ Real Time โดยใช้เทคโนโลยี Message Queue เข้ามาเกี่ยวข้องเพื่อจัดระเบียบการติดต่อกันระหว่าง Module ต่างๆ
ปัญหาของเทคโนโลยี SOA ก็คือ เริ่มตั้งแต่การออกแบบ SOA ให้เกิดความปลอดภัยและปัญหาเรื่องเสถียรภาพของระบบเครือข่าย ซึ่งถือเป็น “Infrastructure” หลักของ “SOA” เพราะถ้าหากระบบเครือข่ายเกิดปัญหา ย่อมส่งผลกระทบกับ”SOA” ทั้งระบบได้ การติดต่อรับส่งข้อมูลแบบ Plain Text ก็เป็นปัญหาใหญ่เหมือนกับเทคโนโลยี Web Service เช่นกัน
แนวทางในการประเมินความเสี่ยงระบบที่ใช้สถาปัตยกรรม SOA จะคล้ายกับแนวทางในการประเมินความเสี่ยงระบบที่ใช้เทคโนโลยี “Web Service” แต่ควรเพิ่มเรื่องการประเมินความเสี่ยงตั้งแต่การออกแบบ SOA ในช่วงแรกว่ามีความเหมาะสมกับองค์กรและมีความปลอดภัยในการรับส่งข้อมูลหรือไม่ ตลอดจนควรประเมินความเสี่ยง ระบบเครือข่ายว่ามีความเสถียรภาพและปลอดภัยเพียงพอที่จะเป็นกระดูกสันหลังให้กับ SOA ทั้งระบบได้หรือไม่ ซึ่งระบบควรจะมีความสามารถในการรองรับการโจมตีแบบ DoS attack หรือ DDoS attack ได้เป็นอย่างดี
กล่าวโดยสรุปจะเห็นว่า การประเมินความเสี่ยงระบบสารสนเทศในองค์กรนั้น ต้องอาศัยความรู้ความเข้าใจในระบบที่ใช้เทคโนโลยีสารสนเทศแตกต่างกันตามยุคสมัยทั้ง 5 ยุคดังที่กล่าวมา หลายองค์กรในปัจจุบันมีการใช้งานระบบสารสนเทศมากกว่าหนึ่งยุค เช่น ใช้ทั้งเทคโนโลยี Client/Server และเทคโนโลยี Web-Based และกำลังเตรียมเข้าสู่ Web Service และ SOA ในที่สุด
ดังนั้นมุมมองผู้ตรวจสอบระบบสารสนเทศต้องมองในมุมกว้างในภาพรวม หรือ “Holistic View” และ ประยุกต์ใช้เทคนิคต่างๆในการตรวจสอบระบบสารสนเทศให้เหมาะสมกับยุคสมัยต่างๆ ของเทคโนโลยีดังที่กล่าวมาแล้วทั้งห้ายุค เพื่อที่จะให้ได้ผลการประเมินความเสี่ยงที่มีคุณค่าสอดคล้องกับความเป็นจริงในการใช้งานระบบสารสนเทศขององค์กรและเพื่อเป็นแนวทางที่ถูกต้องในการแก้ปัญหาและป้องกันระบบสารสนเทศให้มีเสถียรภาพต่อไป
จาก : หนังสือ eWeek Thailand
ปักษ์แรก ประจำ เดือนตุลาคม 2549
Update Information : 30 พฤศจิกายน 2549