การเก็บ Log ตามพรบ. คอมพิวเตอร์

จริงๆแล้วถ้าจะยกพรบ. คอมพิวเตอร์ฉบับเต็มๆมามันก็คงยาวเกิน ก็เลยยกจาก iLaw ที่เค้าทำสรุปไว้ให้แล้วละกัน โดยจาก ภาคผนวก ก. แนบท้ายประกาศกระทรวงไอซีทีเรื่อง หลักเกณฑ์การเก็บรักษาข้อมูลจราจราคอมพิวเตอร์ พ.ศ. 2550 ผู้ให้บริการซึ่งมีหน้าที่ต้องเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์แบ่งได้ ดังนี้

1.1 ผู้ให้บริการแก่บุคคลทั่วไปในการเข้าสู่อินเทอร์เน็ต โดยจะแบ่งกลุ่มคนที่มีหน้าที่ออกเป็น

ก. ผู้ประกอบกิจการโทรคมนาคมและการกระจายภาพและเสียง (Telecommunication and Broadcast Carrier)

ข. ผู้ให้บริการการเข้าถึงระบบเครือข่ายคอมพิวเตอร์ (Access Service Provider)

ค. ผู้ให้บริการเช่าระบบคอมพิวเตอร์ หรือให้เช่าบริการโปรแกรมประยุกต์ต่างๆ (Host Service Provider)

ง. ผู้ให้บริการร้านอินเทอร์เน็ต

1.2 ผู้ให้บริการในการเก็บรักษาข้อมูลคอมพิวเตอร์เพื่อประโยชน์ของบุคคล (Content Service Provider)

จากภาคผนวกและประกาศของกระทรวง จะเห็นว่า ไม่ว่าจะเป็นฝั่ง “server” , ฝั่ง “ฝั่งผู้ให้บริการ internet” หรือฝั่งองค์กรที่ให้พนักงานในบริษัทใช้งาน internet ล้วนจำเป็นต้องเก็บ log ทั้งสิ้น ไม่สามารถหลีกเลี่ยงได้

ถามว่าทำไมบริษัทต้องเก็บ log การใช้งานของ user ด้วยล่ะ ก็เพราะเมื่อเวลาเกิดเหตุการณ์ใดๆขึ้นมา เช่น พนักงานของเราไปโพสต์หมิ่นในเว็บไซด์ใดๆ หรือการใช้ internet ขององค์กรใดๆนั้นไปโจมตีคนอื่น เราก็จะสามารถยืนยันว่าบุคคลคนนั้นเป็นคนทำได้นั่นเอง เป็นต้น โดยการจะย้อนกลับไปหาว่าจะทำยังไงให้ทราบได้ว่าเป็นบุคคลนั้นๆจริงๆ ก็จำเป็นที่จะต้องมีการบังคับให้ user ทำ authentication (ยืนยันตัวตน) ก่อนเข้าสู่ระบบเน็ตเวิร์คขององค์กรได้นั่นเอง

ส่วนฝั่ง Server ก็เก็บ log การโพสต์หรือใช้งานใดๆใน Server ของเราพร้อมกับ IP เพื่อจะระบุตัวตนคนกระทำ activity นั้นๆได้นั่นเอง ซึ่ง log ดังกล่าวไม่ได้เกิดขึ้นจากตัวเว็บเซอร์เวอร์ แต่เป็น Web Application ของเราเองต่างหากที่ stamp การกระทำนั้นๆลงไปเพิ่มเติม (เดี๋ยวจะอธิบายเพิ่มเติมว่าทำไม)

ซึ่งแน่นอนว่า log พวกนี้สำคัญมาก ดังนั้นการเก็บรักษาก็จำเป็นจะต้องสำคัญเช่นกัน นั่นคือทำไมจะต้องมีการเก็บ log มายัง Centralized Log Server และจำเป็นต้องมีผู้ดูแลแยกต่างหากจากระบบอื่นๆครับ (จริงๆคุณสมบัติของเครื่องที่เก็บนั้นมีอีกเยอะมาก สามารถอ่านเพิ่มเติมได้ที่ Link นี้ครับ)

การเก็บ Log เปลี่ยนแปลงไปหมดเมื่อมี SSL จริงหรือ

ฝั่ง Server Side

ตามข้อมูลข้างต้น จะเห็นว่าไม่ว่าเราจะเป็นใครที่ไหนก็ต้องเก็บ log นะครับ ถ้าจะให้ผ่านตาม พรบ. คอมพิวเตอร์น่ะครับ ตามตัวบทกฏหมายแล้ว “ข้อมูลการจราจรทางคอมพิวเตอร์” ที่ต้องเก็บนั้นคือข้อมูลที่เป็น source, destination, time, type of usage, etc. ซึ่งจริงๆแล้วการใช้งาน ไม่ว่าจะผ่าน proxy หรือว่าเข้าไปยัง server จริงๆโดยตรงแล้วมันไม่สามารถระบุแน่ชัดได้ 100% อยู่แล้ว คำว่าไม่ได้ 100% หมายความว่า

  • หากนาย A มีการโพสต์ข้อความด่านาย B ในเวลา 12:00:00 จาก IP 192.168.1.1 [example] โดยใช้ URL www.xxx.com/post.php
  • แล้วพร้อมกันนั้นนาย C โพสต์ชมนาย D ในเวลา 12:00:00 จาก IP 192.168.1.2 [example] โดยใช้ URL www.xxx.com/post.php

ถ้า Web Application นั้นไม่มีการเก็บ IP Address และเวลาของผู้โพสต์ไปยัง Database พร้อมกับ Post สิ่งที่เกิดขึ้นคือ [ตัวอย่างด้านล่างเป็น Log ของ Apache]

192.168.1.1 – – [28/Jul/2006:12:00:00 -0300] “POST /post.php HTTP/1.1” 200 3395
192.168.1.2 – – [28/Jul/2006:12:00:00 -0300] “POST /post.php HTTP/1.1” 200 3395

จะเห็นว่าเราไม่สามารถ identify ได้เลยว่าการโพสต์นั้นถูกกระทำโดยใคร ใครด่าใคร ถ้าไม่มีการ stamp time และ IP เข้าไปด้วย ดังนั้นสิ่งที่เกิดขึ้นคือ Application จำเป็นต้องเอา IP ของผู้โพสต์ไปแปะไว้ในข้อมูลการโพสต์ด้วยเพื่อจะได้แยกได้ว่าใครเป็นคนโพสต์กันแน่

คือถ้าเป็นมุมมองของ Server นั้นต่อให้เราจะใช้ HTTP, HTTPS เราก็มีปัญหาได้ ถ้าเราไม่ได้ log มันอย่างถูกต้องที่ Application มิหนำซ้ำการที่ใช้ HTTP, HTTPS ไม่ได้มีความหมายแต่อย่างใดต่อการจัดการ access.log, error.log ของ Web Server

ถ้าหาก server มีการเก็บ log time และ IP ไปกับโพสต์ก็เอามาผนวกกับข้อมูลของผู้ให้บริการ internet และ log การใช้งานของทางฝั่งผู้ให้บริการ (บริษัท) อีกที โดยผู้ให้บริการต้องไล่กลับไปดูว่ามีการใช้งานเว็บไซด์ดังกล่าวโดย user อะไร ณ เวลานั้นอีกที (นั่นคือทำไมถึงต้องมีการ authentication ก่อนเข้าใช้งาน network ครับ)

ฝั่งการวิเคราะห์ IPS/IDS, Packet Inspection และการป้องกันทางด้าน security อื่นๆ

เมื่อมีการใช้งาน HTTPS แล้วนั้นส่วนการทำงานของ IPS/IDS, Packet Inspection นั้นได้รับผลกระทบจริงคืออ่านข้อมูลที่ user ใช้งานไม่ได้ แต่เราทราบกันดีว่าภัยคุกคามในปัจจุบันมันไม่ได้มากันแบบโต้งๆแบบนั้นอีกต่อไปแล้ว มันมีวิธีสารพัดรูปแบบที่จะทำให้ malware ตรวจจับไม่ได้ด้วยวิธีต่างๆ ซึ่งพวก IPS/IDS มันจะเน้นเรื่องของ Pattern ของ packet ที่มันรู้อยู่แล้ว ดังนั้นเมื่อเจอการทำ obfuscate ทำให้สามารถ bypass พวกนี้ได้อยู่แล้ว หรือก็คือไม่จำเป็นต้องมี HTTPS มาเกี่ยวข้องมันก็สามารถ bypass ได้เยอะแยะมากมายอยู่แล้วนั่นเอง

ส่วน Firewall ไม่ได้รับผลกระทบอะไร ยังไงก็เป็นอย่างนั้น กล่าวคือ Firewall ปกติมันก็แค่ Log การใช้งาน TCP/IP Layer 4 อยู่แล้ว (Source IP, Source Port, Destination IP, Destination Port) ดังนั้นมี SSL หรือไม่มี SSL ก็ไม่มีผลอะไรเช่นกัน log ที่เกิดขึ้นก็เกิดปกติครับ

พอมาเป็น Next Generation Firewall (NGFW) มันก็แตกต่างกันหน่อย คือพวกนี้จะมีพวก IPS/IDS feature ผนวกเข้าไปพร้อมกับ Sandbox ต่างๆ พร้อมกับการตรวจสอบร่วมกับ IOC (Indicator of Compromise) อีก ซึ่งแน่นอนว่า feature IPS/IDS อาจจะได้รับผลกระทบแต่ก็ไม่ใช่ว่ามันจะง่อยกระรอกซะทีเดียว เพราะ feature อื่นๆ เช่น IOC, Sandbox เป็นต้น จะไม่ได้รับผลกระทบแต่อย่างใด เพราะยังไงมันก็ดู source ของต้นทางอยู่ดีว่ามันโอเคมั้ย มีประวัติเป็นอย่างไร หรือลองไปรันใน Sandbox แล้วเป็น malware หรือไม่ ไม่ใช่พึ่งแค่ feature IPS/IDS เพียงอย่างเดียว

ส่วน Web Application Firewall (WAF) นั้นไม่จำเป็นต้องเป็น module แยกเสมอไป มันมีหลายๆตัวที่มี plugin ของ web server อยู่แล้ว เช่น Apache มี mod_security, Nginx มี naxsi, wallarm เป็นต้น ไม่ต้อง export cert เพื่อไปติดที่ WAF ที่อื่น ใช้งานได้เลย

อีกเรื่องที่สำคัญคือ SIEM ที่เป็น Open Source มีตั้งมากมาย (ทำไมไม่ยอมเลือก) ยกตัวอย่างเช่น OSSIM, HELK เป็นต้น ตลาดในโลกของ security มันเยอะมากมายเลย ดังนั้นอย่ายึดติดกับว่าต้องเป็น Enterprise Product ครับ เพราะผมเห็นมาเยอะแล้ว ไอ้ซื้อ SIEM ระดับเป็น 5-10 ล้านแต่เอาไปวางเฉยๆไม่ได้ทำอะไรเนี่ย

Security Product ไม่มีอะไรที่มัน the best นะครับ ขึ้นอยู่กับคนปรับจูนว่าทำได้ดีขนาดไหนมากกว่าครับ

สรุปคือ

ถ้าเป็นมุมมองของการวิเคราะห์การใช้งานของ user นั้นแทบจะทำอะไรไม่ได้เลย (ก็ encryption protocol มันถูกออกมาให้เป็นแบบนั้นนี่นา =_=”) แต่ถ้าเป็นในมุมมองทางด้านการสืบคดีในเชิงจากฝั่ง server site มายัง client site นั้นไม่แตกต่างจากเดิมครับ

Resource::

  • https://ilaw.or.th/node/77
  • https://www.etda.or.th/files/1/files/06.pdf