แนวทางการประเมินความเสี่ยงระบบสารสนเทศเพื่อให้สอดคล้องกับยุคสมัยที่เปลี่ยนแปลงของเทคโนโลยี
Information Technology Risk Assessment Guidelines for
Modern IT Auditors
ปริญญา
หอมเอนก , CISSP, CISA , SANS GIAC
GCFW
ACIS Professional Center
ตุลาคม 2549
เทคโนโลยีสารสนเทศ หรือ 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
ปัญหาของเทคโนโลยี 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 และ ประยุกต์ใช้เทคนิคต่างๆในการตรวจสอบระบบสารสนเทศให้เหมาะสมกับยุคสมัยต่างๆ
ของเทคโนโลยีดังที่กล่าวมาแล้วทั้งห้ายุค
เพื่อที่จะให้ได้ผลการประเมินความเสี่ยงที่มีคุณค่าสอดคล้องกับความเป็นจริงในการใช้งานระบบสารสนเทศขององค์กรและเพื่อเป็นแนวทางที่ถูกต้องในการแก้ปัญหาและป้องกันระบบสารสนเทศให้มีเสถียรภาพต่อไป